UML Notation

This collection of notes on OOP was never meant to stand alone. It also represents a view of OO circa early to mid 1990s. Some people still find them useful, so here they are, caveat emptor. Special thanks to Gilbert Benabou for taking to time to compile the first printable version of this document and inspiring us to provide it.

[PDF]

Printable Version

Unified Modeling Language UML is a "method for specifying, visualizing, and documenting the artifacts of an object-oriented system under development." UML is Booch, Objectory, and OMT combined, extended, simplified. Started in 1994.

Four goals for UML effort:

To model systems (and not just software) using object-oriented concept
To establish an explicit coupling to conceptual as well as executable artifacts
To address the issues of scale inherent in complex, mission-critical systems
To create a method usable by both humans and machines

Targeted the modeling of concurrent, distributed systems

Focuses on a standard language, not a standard process: "Trying to get everyone to use the same methodology is a losing game. Different domains require different methodologies. Each developer and organization has different styles. UML started out as a methodology (the Unified Method) but evolved into something more abstract; a language for modeling."

The primary focus is developing a meta-model; second comes a standard notation to use it. The process isn't a goal, but Rational encourages an "architecture-driven, incremental, and iterative development process."

Developers using UMLdon't see much of the meta-model. Instead they create models of their designs using the notation. The meta-model is for developers of UML, and for developers of UML-aware tools. The artifacts created by a modeling effort are:

Use case diagrams (from Objectory)
Class diagrams (OMT)
Behavior diagrams
State diagram (Booch &OMT)
Activity diagram
Sequence diagram (Booch interaction diagrams)
Collaboration diagram (Booch object-message diagrams)Process diagrams (new idea)
Implementation diagrams
Component diagram (Booch Module diagrams)
Deployment diagram (Booch Network and Process diagrams)

A notation should reduce the cognitive load on the designer by being easy to use and consistent. This frees the designer for more important things, like concept development. A consistent notation also has the benefit that you can share your work with others. UML's notation is as widely agreed on as any.

There is a subset of UML notation that is useful in many applications; the details don't have to be mastered.

Large systems are too complicated for any single view or diagram to fully describe. UML uses the following diagrams to describe such systems:

Use case diagrams
Class diagrams
Object diagrams
Sequence diagram
Statechart diagrams
Collaboration diagrams
Component diagrams
Deployment diagrams

We use different diagrams at different stages of the project. In the analysis phase we use Object, Class and Statechart diagrams. In the design phase we supplement these with Component and Deployment diagrams, as well as the dynamic behavior diagrams, like Sequence and Statechart.

Since OO development tends to be iterative, the diagrams are not "write once and forget" drawings, they evolve with the development.

Class Diagrams

Classes are shown as blobs with dashed line edges. They have a class name and the most important (usually not complete) set of attributes and behavior of the class.

Attributes are described as follows:

A attribute name only
: C class name only
A : C attribute of class
A : C = E attribute of class with default value

Operations are the behavior of the class and are show as:

N() operation name only (preferred)
R N(args) operation with return class type and arguments

A marker {abstract} after the name of the class means it is abstract.

Class relationships

Associations are labeled with nouns, indicating the nature of the relationship. They can also be adorned with their cardinality at the target end:

1 exactly one
N unlimited
0..N zero or more
1..N one or more
X..Y range from X to Y

Inheritance relationships have arrows that point toward the superclass.

Hasa (composition) relationships are whole/part where the black diamond is on the whole or composite class.

Aggregation relationships use a clear diamond.

Class categories

Logical groupings of classes. No semantic meaning. Not supported by most OO languages.

Advanced class notation

Parameterized classes, metaclasses, class utilities (free member functions in C++), nesting, export control, properties (static, virtual, friend in C++), physical containment, roles and keys, constraints, notes.

Specification

Textual representation of the graphical symbol.

Could just be the header files, with comments.

Each class has at least this much:

Name identifier
Definition textual
Responsibilities textual
Attributes list
Operations list
Constraints list

Specifications also include textual description of the advanced class definition features above.

Statechart Diagrams

Classes have Statecharts if they exhibit interesting and important state-dependent behavior.

The state of an object is the collection of the attributes of the object with their current (usually dynamic) values. This state changes over time as the object sends and receives messages. The state of an object effects the way it reacts to messages.

When an object changes state it goes through a state transition. This is shown in STDs with an arrow. Transitions are unique, so that, given an object in a certain state, if a certain circumstance or event occurs, there is only one transition that can occur. There may however, be many transitions entering/leaving a single state.

Events can be viewed in several ways. Some options include looking at events as objects, messages, or the start/end of an activity. Consistency within a diagram is important.

STDs must have exactly one start state (with an unlabled transition from a filled circle to enter it).

STDs may have stop states, with dot within a circle, or they may not.

Advanced features

Actions and conditional transitions, nested states, history, orthogonal states.

Object Diagrams

Object diagrams are a snapshot in time showing the relationships between objects at some phase of the programs life. Object diagrams have a scope in which they live, since they represent actual, live objects, and not just abstract classes.

How are object diagrams different than class diagrams? How many elements will they have, compared to class diagrams?

An object name can be of the form:

A object name
: C class name
A : C object and class name

Relationships

A link can exist between two objects only if their corresponding classes have a relationship.

Links are shown by lines between objects.

Sequence Diagrams

A sequence diagram shows how objects exchange messages over time to achieve some particular end. Time moves vertically down the diagram.

Objects are drawn horizontally across the diagram.

Dashed lines (lifelines) below objects show the boundary of the object for messaging, and the life time of the object.

Activations are rectangles showing when an object is active.

Horizontal arrows show messages starting at the client and ending at the supplier object.

Advanced concepts

Scripts can be written beside the diagram to enhance the description of what is taking place.

Loops can be represented.

Focus of control can be used to show which objects initiate a string of messages. These vertical boxes show what object control flow returns to.

Component Diagrams

Mapping our class definitions to files is the concern of component diagrams.

We need to represent: interface files (.h), implementation files (.cpp), main program file (.cpp), and subsystems (collections of related classes).

The relationship we show between the file icons is a compilation dependency. In C and C++ this is done with the #include C pre-processor directive. An arrow from one file to another indicates the target of the arrow is included in the originator.