An object is any entity - person, place, event, or thing - that we want to model in software. Object Oriented Programming (OOP) is based on the idea that large programs work better if they are written as a collection of objects. These objects are kept relatively independent of one another, and can share characteristics in a way that makes programming quicker and more reliable.

Objected Oriented Programming is the most widespread methodology in use today. OOP languages include ActionScript (for Flash), C#, C++, Java, JavaScript, Objective-C, Perl, PHP, Python, Ruby, Smalltalk, Squeak, VB.Net, Visual FoxPro, and many others. However, the concept of OOP didn't gain adherents until the 1990s, so only a few languages designed before 1990 include object-oriented capability (notable exceptions being C++ and Smalltalk, which pioneered the technique).

The primary motivation for using OO Programming is to get control of complexity. Increasingly large and involved software projects in the mid to late 20th century resulted in longer development time and less reliability.

The central idea of OO, that software code modules should be kept relatively independent of one another, is an embodiment of the age-old "divide and conquer" philosophy. By keeping software "objects" small and isolated, they become easier to design, easier to test, and easier to fix or update.

Can the benefits of OOP be transfered to Object Oriented Analysis (OOA) and Design (OOD)?

• Object Oriented Design: Certainly. OOD is a logical and necessary precursor to OOP.
• Object Oriented Analysis: Partially. OO principles give the analyst a lens with which to view an existing system; a sort of "yardstick" to help measure where things are going wrong. But since existing, problematic systems are generally not "object oriented" to begin with, analysts need a more flexible way of understanding existing systems.

Object Oriented Programming is based on the concept of software code "objects" which:

• Contain data and techniques that are private to most other software code. This means other code cannot alter the object's private data, and does not have access to the specific ways in which the object manipulates the data. This is known as encapsulation because the object is protected and enclosed.
  How does this help? One of the major challenges of writing large programs in non-orbject fashion is when code in one part of the program interferes with code in another part. This might be unintentional, or it might be a misguided attempt to save effort. Encapsulation protects against this interference.
• Contact between the outside world and the software object is handled through messages passed between it and the external world. To query or manipulate data in an object, a request is sent in a message to the object, which then returns information or performs an action. This results in loose coupling.
  How does this help? Just like the modularization of automotive components, loose coupling makes it easier to swap malfunctioning components out without taking the system down (for long). It also makes it easier to re-use components in new systems.
• Developers create classes of objects: models which serve as templates for creating instances of similar objects and classes. These objects are said to inherit characteristics of parent object classes.
  How does this help? It enables another way of re-using software - that is, taking a general implementation and making it work in many different specific contexts. It also encourages programmers to think about re-usability from the very start.

This chart (which is itself a Component Diagram) illustrations the UML diagram types and their relation to one another:

(at Wikimedia: http://en.wikipedia.org/wiki/Image:Uml_hierarchie_des_diagrammes.png)

In this section, we'll briefly define and illustrate each type of UML diagram.

Most definitions and examples from Wikipedia (public domain or GPL) unless otherwise stated.

Use-Case Diagram

Probably the most widely used UML diagram, and arguably the starting place for modeling any system. "Use cases are stories about how someone or something uses the system to accomplish something useful." (Bittner & Spence 2002, Chapter 4)

Class Diagram

A type of static structure diagram that describes the structure of a system by showing the system's classes, their attributes, and the relationships between the classes.

(See also Visual Paradigm's examples of Class Diagrams.)

Component Diagram

(No public domain or GPL example readily available. See Visual Paradigm's examples of Component Diagrams.)

Object Diagram

Shows a complete or partial view of the structure of a modeled system at a specific time. This snapshot focuses on some particular set of object instances and attributes, and the links between the instances.

Composite Structure Diagram

Shows the internal structure of a class and the collaborations that this structure makes possible. This can include internal parts, ports through which the parts interact with each other or through which instances of the class interact with the parts and with the outside world, and connectors between parts or ports. A composite structure is a set of interconnected elements that collaborate at runtime to achieve some purpose. Each element has some defined role in the collaboration.

(See also Visual Paradigm's examples of Composite Structure Diagrams.)

Deployment Diagram

Serves to model the hardware used in system implementations, the components deployed on the hardware, and the associations between those components. The elements used in deployment diagrams are nodes (shown as a cube), components (shown as a rectangular box, with two rectangles protruding from the left side) and associations.

(No public domain or GPL example readily available; see the Deployment Diagram at The Vinci Organization's UML Primer;
See also Visual Paradigm's examples of Deployment Diagrams.)

Package Diagram

Depicts how a system is split up into logical groupings by showing the dependencies among these groupings. As a package is typically thought of as a directory, package diagrams provide a logical hierarchical decomposition of a system.

Activity Diagram

Represents the business and operational step-by-step workflows of components in a system. An Activity Diagram shows the overall flow of control.

(No public domain or GPL example readily available. See Visual Paradigm's UML examples of Activity Diagrams.)

State Machine Diagram

Used to graphically represent finite state machines. They can describe a lot of things, from computer programs to business processes.

(There are actually several types of "state diagram" used primarily by computer scientists and methematicians, in addition to the UML standard.)

(See also Visual Paradigm's examples of State Machine Diagrams.)

Interaction Diagrams

Sequence Diagram

Shows, as parallel vertical lines, different processes or objects that live simultaneously, and, as horizontal arrows, the messages exchanged between them, in the order in which they occur. This allows the specification of simple runtime scenarios in a graphical manner.

(See also Visual Paradigm's examples of Sequence Diagrams.)

Interaction Overview Diagram

A variant of Activity Diagram focusing on the overall flow of control among interactions.

(No public domain or GPL example readily available. See Visual Paradigm's examples of Interaction Overview Diagrams.)

Communication Diagram

Models the interactions between objects or parts in terms of sequenced messages. Communication diagrams represent a combination of information taken from Class, Sequence, and Use-Case Diagrams describing both the static structure and dynamic behavior of a system.

(Courtesy of Dr. Richard J. Botting, California State University, San Bernardino)

(See also Visual Paradigm's examples of Communication Diagrams.)

Timing Diagram

Explore the behaviors of objects throughout a given period of time. A timing diagram is a special form of a sequence diagram. The differences between timing diagram and sequence diagram are the axes are reversed so that the time are increase from left to right and the lifelines are shown in separate compartments arranged vertically.

(No public domain or GPL example readily available. See Visual Paradigm's UML examples of Timing Diagrams.)

General Analysis Phases

We can classify the various diagrams according to the phases of the analysis project in which they are useful. Recall that regardless of the methodology chosen ("waterfall", agile, object-oriented, etc.) analysis and design goes through four general types of activity:

1. Physical analysis asks, how does the system actually work?
2. Logical analysis tries to get to the logical pattern behind the current system
3. Logical design tries to correct problems in the current system by creating a logical (abstract) system that will solve the problems of the current system and achieve new goals.
4. Physical design takes the new abstract system and creates a physical system that makes it work as envisioned.

How UML Fits each Phase

(This chart is based on Marakas 2004.)

The primary UML diagram type used in analysis is the Use-Case Diagram.

The Use-Case Diagram is UML's MVP in Systems Analysis

Use-Case Diagrams are especially useful throughout all phases of a systems analysis and design project because:

• they are very general
• they are flexible enough to model systems that are not object oriented
• they do not require a detailed knowledge of the system to get started
• they can be used for analyzing current systems, and (with linked documentation) to specify new system requirements

More detail on Use-Case diagrams in systems analysis is in module U12.

Here's a list of UML diagram types and their use in phases of analysis and design

Diagram	Analysis		Design		Implement- ation
	Physical	Logical	Logical	Physical
Class	Maybe
Component		Maybe	Maybe
Composite structure
Deployment		Maybe	Maybe
Object	Maybe
Package	Maybe	Maybe	Maybe
Use-Case
Activity
State Machine
Communication
Interaction overview
Sequence
Timing

Marakas 2004
Systems Analysis & Design: An Active Approach
by George M. Marakas
Publisher: McGraw-Hill Irwin; ISBN: 0072976071 Edition: 2nd