A Brief Introduction into UML 2 (Draft)
October 28, 2009 · Robert Söding


For once, this article is draft and incomplete. – The justification for posting it though is that there is only few and often even worse gratis information on UML on the web. – There appears to be an analogy: There are few – if any, gratis or affordable, – high-level UML tools on the market – why should documentation be free?
Well, it just feels proprietary, and, admittedly, this time I haven't felt urged to complete my usual work cycle of learning, prototyping, and publishing.
UML has had been overestimated in the past. – A software architect, developer, or programmer, you definitely need to know the basic syntax and semantics in order to communicate patterns in software design. – This can be accomplished with a pencil only, and a peace of paper. Or a flipchart drawing. Or by using pseudo-languages. – And by talking, of course: This is all about general conceptual thinking, communications, and visualisations.
Nevertheless, UML had been "hyped" up to a code generation tool (which it – in contrast to DSLs (Domain Specific Languages) – definitely has never suited for). – Software developers had dreamed about round-trip engineering, where, i.e., Java, source code would update the corresponding UML diagrams, and backwards. – Code generation frameworks in general didn't make it through, but UML-based code generation frameworks (any survivors?) are dead because of reality mismatch.
Personally, I'm somewhat torn when hereby degrading UML. – That's because I to a large degree understand the impacts of SCM (Supply Chain Management) on the globalized world. – SCM (optimized logistic operations) has had been the key factor in industry and commerce since the industrial revolution, and evermore since then since the 1980's (when Mark Knopfler sang "Industrial Disease", BTW). – There's still a huge potential in BPM (Business Process Management) and its increasing, partial, automation for IT-related businesses – where BPM partially shares concepts with UML.
The – incomplete – article at hand is – only – missing about 20% of the diagram types and details that I wanted it to highlight. However, the most important issue is that the article doesn't yet categorize the different diagram types into the 4+1 Architectural View Model – thus, if you actually ought to bother studying the article at hand, would you please just take that as a first-order advice.
Please also note that this article has had never been reviewed of revised: There are as well spelling as grammatical as logical errors involved.
If you'd want to contact me though, you can do so by mailing to .

UML Tools

The criteria for selecting an UML tool - in the context of writing this article - have been primarily: More advanced features, including code generation and roundtripping, have not been considered at this stage.
Amongst others, I have checked out the following UML tools. Whenever I found a knock-out criteria, I stopped working with that tool.
In the end, I have decided for the Community Edition of Visual Paradigm for UML. In this context, Visual Paradigm's worst limitation is, it - heavily - prints watermarks on diagrams exported as images. On the other hand, its UML capabilities are still quite advanced, compared with Eclipse's or NetBeans', even using VP's Community Edition.

UML Use Cases


Diagram Types

Use Case Diagrams

Use case diagrams describe a system's usage requirements from the view point of the actors - or roles - involved.
Use cases are often presented to the management and / or project stakeholders. For actual development, they provide essential information about the "meat" of an application.


The following diagram shows some use cases related to bug tracking and fixing:
Use Case Diagram
There are three actors, all associated with a use case. These use cases a arranged within system boundaries (which is optional).


Actors are objects that interact with the system, but are not part of it. An actor might be a person, however, it could be a third party's system, as well. The application with which an actor interacts cannot change the actor.
Often there are more actors involved than a system designer primarily thinks of - apart from the system's end users, actors involved typically include, for instance, testers, installers, maintainers, etc.
Mostly, actors are displayed using a "stick man", however, they can also be drawn in box, using an <<actor>> stereotye or a symbol:
Use Case Diagram
Actors can derive from more generalized actors by using the generalization arrow:
Use Case Diagram

Use Case Descriptions

Any use case should be accompanied by a textual description.
According to Miles and Hamilton ("Learning UML 2.0"), use case descriptions should include the following types of information:

Use Case Relationships


When use cases extend other use cases, that is expressed by the generalization arrow:
Use Case Diagram

The <<include>> Relationship

Use cases can include other use cases, which are re-used in that case. Inclusion is expressed by the inclusion arrow, with its <<include>> stereotype.
Use Case Diagram

The <<extend>> Relationship

Use case extensions, expressed by the Extension arrow, with its <<extend>> stereotype, provide alternative or optional behavior:
Use Case Diagram
This is not to do with inheritance in programming languages (e.g., there is - unrelated - the Java keyword extends).

Activity Diagrams

Activity diagrams are used to model business processes at a higher level of abstraction.


The following diagram shows the process of registering or logging in:
Activity Diagram - Login or Register
The process starts with an initial node. The process' first action in this case is the one of visiting the Register-or-Login page.
Depending upon whether the user has registered before, she will either login or register. A decision node works similar to an if ... else ... statement. Its outcome is described by the contents of so-called guard conditions, which use to be enclosed by square brackets.
At a decision node, the activity flow gets splitted into two eges or paths - at merge node, the edges get joined again. Merge nodes are optional (we could have also let the edges point to another decision node or action), however, they are recommended for clarity.
Edges, BTW, can be differentiated into incoming and outgoing edges.
Next in the flow, there is a decision node again, but this time without a corresponding merge node.
The final activity node represents the endpoint of this process.

Actions and Activities

An action is a single step, or task, within a process.
An activity is a set of correlated actions. A process modeled by an activity diagram can consist of one or more activities.
The following image shows the process discussed in the previous example - this time, embedded in an activity frame:
Activity Diagram - Login or Register
Drawing actitities in activity diagrams is only really useful if the process being modeled is composed of multiple activities. In Eclipse, however, it is not possible to draw activity diagrams without activity frames.
The following diagram shows a process with multiple activity frames:
Activity Diagram - Login or Register

Calling External Activities

It is possible to call external activities by using a call activity node.
Based on the last sample, we are externalizing the "Register" activity into another diagram:
Activity Diagram - Register Activity
It is considered good practice to always use an activity frame with top-level activities.
The next diagram shows the call activity node:
Activity Diagram - Login or Register
The following screenshot shows the corresponding settings (Type, Behavior) in Visual Paradigm for UML:
The "Register" names are badly chosen in the above sample; the screenshot shows the calling action's properties dialog, where the Behavior property references the called activity by the same name.

Parallel Activities: Forking and Joining

Forking - using fork nodes - allows for processing multiple actions independently from another, i.e., concurrently or in parallel. Processes can be forked into two or more chains.
Before process chains can be joined again - using join nodes -, each chain's actions must have completed.
The following diagram shows a possible scenario of using fork and join nodes:
Activity Diagram - Forking & Joining

Passing Objects Between Actions and Activities

Objects in the UML language hold information - state - that is passed between actions. Objects may represent class instances, however, are not limited to represent software objects. Their corresponding shape is an object node:
Passing Objects
Objects usually change state between actions:
Passing Objects
An alternative notation shows action input pins and output pins. These emphasize that the corresponding object is required while object nodes rater emphasize the existance of that object:
Output and Input Pins
TODO: Objects as activities' start and end points

Interacting with External Participants

External participants may be external processes, systems, or people, interacting with an activity.
A receive signal "wakes up" an action that is "sleeping", a send signal is sent to an external participant.
In the following diagram, both a send and receive signal action are used. Note that the activity flow gets interrupted - gets into a wait state - until the bug fix notification is received. (If there was no receive signal action, however, the flow would just continue after executing the send signal action.)
Send and Receive Signal Actions
An activity may also start with a receive signal node:
Activity, starting with Receive Signal Action

Time Events

A time event models a wait period:
Time Event
An activity starting with a time event is launched periodically:
Time Event

Interrupting an Activity

Longer running processes can be interrupted by an event - an accept event action within an interruptable activity region.
Interruptable Activity

Ending a Flow

Reaching a flow final node ends a flow (not the activity). The following diagram models a scenario in which software is tested and bugs are fixed - until the release date is due:
Flow Final Node

Using Swimlanes

Processes or activities can be partitioned, using swimlanes for different application roles:

Iterating Over Collections

To iterate over a collection, an expansion node is used. The actions within a corresponding expansion region will be executed for each collection item:
Iterating Over Collections

TODO: Exception Handling, Containment, Connectors

Class Diagrams

Class diagrams describe the objects and classes within the system, and their relationship.


Classes (as well as interfaces and enumerations) are drawn by a rectangle with the class name, and, optionally, attributes and operations:
The following diagram already shows quite a few elements:
Basic Class Diagram
Looking at the AbstractActor class, there is its class name as well as attributes and operations. The + and - signs before those denote the attributes' and operations' visibility (which will be discussed below).
The notation for attributes is visibility attributeName : dataType, the notation for operations visibility operationName([arguments]) : returnType. Operations' arguments are - naturally - optional; their notation is argumentName : dataType. Multiple arguments are divided by commas.
Abstract classes and operations are drawn in italics.
Both Eclipse and Netbeans do not conform to these notation rules.
Looking at the Actor interface, it is annotated with the <<Interface>> stereotype.
The enumeration ActorType is annotated with the <<enumeration>> stereotype, its enumeration literals with <<Constant>> stereotypes.
There are also a number of relationships assigned: The relation between ActorType and Actor is a Containment, which means that ActorType is an inner class of Actor.
The AbstractActor class implements - which is the corresponding keyword in the Java language - the Actor interface - in the UML language that is called a realization. Most classes extend the AbstractActor class (inherit from it, subclass it) - that is called generalization in the UML language (AbstractActor is a more general, less specialized, class than its subclasses).
Most of these structures will be discussed further below.

Attributes' and Operations' Visibility

Attributes and operation names in UML class diagrams are prepended by a leading sign, denoting their visibility.
There are the following visibility classifications, with their corresponding notation:
Classes theirselves may have the very same visibility characteristics, however, their visibility is not shown, graphically.
In Java, protected parts of classes are also visible from other classes within the same package. That is not the case with UML semantics. TODO: see below


The notation for attributes (visibility attributeName : dataType) has already been addressed:

Attribute Properties

Attributes can be assigned an initial value as well as properties (which are drawn in curly brackets).
The probably most common property is readOnly (or final):
- copyright : string "Copyright (c) 2009, Robert Söding" {readOnly}
I have not been able to make Visual Paradigm draw attributes using the above, extended, notation.


In the above diagram, the attributes are drawn inline. Alternatively, attributes can be drawn by using associations:
Associations have the notion of multiplicity. For instance, an attribute may refer to one object instance, or multiple instances:
Possible multiplicity values include
An association that may point to more than one object instance could be represented by a java.util.Collection, Set, List or array (and other types) in Java. In UML, in contrast, the collection's type cannot be specified - that is up to the implementation, respectively, a code generation tool.
Furthermore, an association is navigable - in either one or both directions:
Corresponding Java code might look like the following code snippet:
class Bug { List messages; ... } class Message { Bug bug; ... }
Navigalibility can be resctricted, explicitly, as shown in the following diagram:
Collection attributes can be unique (which they are by default; no duplicates are allowed) and ordered (their items' order is defined).
TODO: - messages : Message [0..*]


The notation for operations (visibility operationName([parameters]) : returnType) has already been addressed:
Operations' properties (Operation Code Details in Visual Paradigm) may include final (the operation cannot be overwritten by subclasses), synchronized (the operation acquires a lock before it executes), and abstract (the operation is to be implemented by subclasses - only).

Static Parts

Static attributes and operations are drawn underlined:
Static Parts

Class Relationships

Dependency or Usage

An object is dependant on another object if it uses, works with, the latter.
In the sample above, the optional use stereotype is applied. Other related stereotypes include call and instantiate.


Associations - with their multiplicity and navigalibility - have already been discussed in chapter Associations.


An aggregation means that one object owns one or multiple related objects. If the owning object is destroyed, the owned objects will not be destroyed by that.


Similarly to the aggregation relationship, a composition means that one object owns one or multiple related objects. If, however, the owning object is destroyed, the owned objects will be destroyed by that.

Generalization, Realization, Interfaces, and Abstract Classes

The following diagram already shows quite a few elements:
Basic Class Diagram
An interface - Actor in this case - is annotated by the <<interface>> annotation. It defines abstract methods that need to be implemented.
The AbstractActor class realizes - implements in Java - the Actor interface, as indicated by the realization arrow.
The AbstractActor class implements several methods defined by the Actor interface. The method + getType() : ActorType, however, is defined as abstract, itself. "Abstract" means, that the method is not implemented within the class that contains, but has to be implemented (or, in turn, to be declared as abstract) by subclasses. Classes that contain abstract methods need to be declared as abstract, as well.
Abstract methods and classes are drawn in italics.
The Viewer class, for instance, inherits from - subclasses, specializes on, the AbstractActor class - indicated by the generalization arrow. Generalization is known as inheritance in programming languages, expressing an is-a relationsship.


Templates - also called parametrized classes - allow for postponing with which types of objects a class will work lateron. This is known as generics in Java.
Basically, one defines one or more template parameters at the class level.
From Visual Paradigm's documentation, I did not find out how to bind a class to that parameter.


TODO: OCL; p. 91
TODO: packages?

Object Diagrams

An object diagram focuses on a particular set of object instances, their attributes, and the links between the instances - at a particular time. In contrast to class diagrams, only aspects need to be shown that are relevant to the current interest.
An instance specification basically consists of an instance name and a classifier, where the latter often refers to a class defined in a class diagram. Both instance name and classifier are optional, however at least one of both needs to be set.
Optionally, attributes (from the corresponding class) and their values are defined using slots.
Links show relations between object instances; association, aggregation, and composition arrows can be used as well.
Object Diagram

Sequence Diagrams

Sequence diagrams model the flow of logic, showing the sequence of messages passed between objects using a vertical timeline.


The following diagram shows a part of the flow of reporting a bug:
Sequence Diagram
Sequence diagrams consist of participants and their associated lifelines, messages, and events:
Sequence Diagram

Participants and Lifelines

Participants, in general, are parts of the system that interact with each other in the context of the sequence. There are different types of participants, however, this article focuses on software objects.
Participant representations in sequence diagrams are always orientated horizontally.
Participant names are of the shape ...
partName [arrayIndex] : className ref diagramName
... where at least one of these elements must be given.
partName is an arbitrary identifier. arrayIndex is an integer, used to point to an array item. className specifies the type of the object. diagramName is the name of an additional interaction diagram that describes how the participant works, internally.
With every participant, a lifeline is associated. Lifelines represent time - not an amount of time (or duration) but an order in which message events occur.

Events and Messages

Messages are drawn between lifelines, using arrows:
Sequence Diagram
There are the events of sending and receiving a message. Optional activation bars indicate that the corresponding participant is busy.
Message signatures are of the shape ...
returnValue = messageName (arguments) : returnType
... where all elements except the message name are optional. Arguments can be passed in the name : type notation, multiple arguments separated by commas.
Displaying return messages is optional - and often just implied:
Sequence Diagram
Messages that result from other messages are called nested messages:
Sequence Diagram

Message Types

The following diagram lists some commonly used types of messages:
Sequence Diagram
Messages can be synchronous or asynchronous. When sending a synchronous message, the message sender is blocked until the message receiver has finished processing the message. Asynchronous messages, in programming code, are often implemented as threads, i.e., by using the Java Thread class.
With self messages, a participant sends a message to itself.
A participant can be created by using a create message. In Java, the new keyword is used to create an object instance.
A participant (not only partipants create by using a create message) can also be destroyed by using a destroy method. The use of the destruction cross is optional. In Java and other programming languages, object instances typically are not destroyed, explicitly. Destroying them will be handled by the garbage collector, at an unpredictable time. (Thus, using the destruction cross when modeling an interaction to be implemented in Java doesn't make sense.)

Interaction Fragments

Interaction fragments - or frames - are regions with a special purpose, as indicated by their interaction operand. Interaction fragments may contain any number of communications.
For example, a fragment with the ref operator refers to another interaction diagram - a diagram called "Login" in the following sample:
Sequence Diagram
An alt fragment, along with its guard conditions, acts like an if .. else .. statement:
Sequence Diagram

Fragment Types

The following overview describes a subset of UML fragment types:
Type Parameters Usage
ref -- Refers to another interaction diagram.
alt [guard_condition1]
Similar to an if .. else .. statement.
opt [guard_condition] Similar to an if .. statement.
par -- Communications within that fragment can run in parallel.
loop min_times
Similar to a for .. loop.
neg -- Communications within that fragment are not run at all.
region -- That fragment defines a critical region, i.e., where a software object is being updated (and should therefore not be accessed, concurrently).

Communication Diagrams

While sequence diagrams focus on the order of messages, communication diagrams emphasize communication links between participants.
Communication Diagram
As messages, in contrast to sequence diagrams, are not arranged in an ordered way, they get numbered. Nested messages (which are the result of other messages) are numbered with an additional number after a decimal point (1.1 in the sample above).
TODO Elaborate

Timing Diagrams

Timing diagrams show how objects behave over given periods of time, particularly, how long they are expected to be in a particular state.
In practice, they are used rarely, and some UML tools (i.e., MagicDraw 16.5) do support them.


The following timing diagram shows the simple flow of a cross-way traffic light:
Timing Diagram
As in every interaction diagram, there are participants with their lifelines. In timing diagrams, the participants' different states are explored. Over time, these states may change, which is indicated by a states line.
Please note (as the above diagram does not illustrate this), that status changes are regarded triggered by events.
Participant names are written in the name : type notation, where at most one of both declarations is optional.
The following diagram expands on the above one:
Timing Diagram
There are two participants and lifelines now, and there is a message (named signalTimeToStop) between them on the event of the traffic light becoming yellow. (Just like in the real life, our car driver reacts a little slow and just stops when the traffic light shows "orange".)
Time and duration constraints are discussed in the following section.

Time, Time Constraints and Duration Constraints

Time, in timing diagrams, can be specified in absolute or relative units.
Absolute measurement ...
Timing Diagram
... can be expressed in units such as days, hours, seconds, etc.
For relative measurement ...
Timing Diagram
... t is used as a variable.
Duration constraints define how long a state is expected to be in place - the duration of a state:
Timing Diagram
Time constraints define how long a status change event takes to trigger another status change event - the duration of an event:
Timing Diagram
In the above diagram, two different state lines are involved. However, a time constraint may also apply to a single state line, only.
The following table lists some possible ways of expressing a timing constraint (a duration or time constraint):
Constraint Description
{2s} The duration of the event or state should be exactly 2 seconds.
{>2s, <3s} The duration of the event or state should be longer than 2 seconds, and shorter than 3 seconds.
{t} The duration of the event or state should equal the value of the variable t.
{t..t*2} The duration of the event or state should be within t and two times t.
{t..t+2s} The duration of the event or state should be within t and t plus 2 seconds.

Compact Notation

The full view of a timing diagram ...
Timing Diagram
... can also be reduced to a compact view:
Timing Diagram
Using the compact notation should be considered when there are many participants and states.

Interaction Overview Diagrams

Interaction overview diagrams describe a higher-level flow of control of interactions.
The following diagrams provides an overview of the interactions involved in the process of reporting a bug:
Interaction Overview Diagram
Interaction overview diagrams contain other interaction diagrams - sequence, communication, and timing diagrams -, which - as indicated by the ref designator - usually refer to existing diagrams within the corresponding UML project.
It is optional to show a preview of those other diagrams.
Just like with sequence and communication diagrams, there is an initial node, an activity final node, there are control flows, and there may be merge and (not shown in the diagram above) fork nodes.

Composite Structure Diagrams

TODO: Description

Parts, Properties, Connectors and Multiplicity

The following class diagram shows the BugReport class with three class relationships:
Class Diagram
The relationship to the Actor class is an association, which means that instances of the BugReport class don't own an Actor instance. The same Actor instance can be used by other objects in the system, without even knowing of the BugReport class.
The relationship to the Message class, in contrast, is a composition: The BugReport instance does own the Messages; if it destroyed, the messages will be destroyed, too. (The status instance variable, too, is compositly related to the BugReport instance. It is just drawn using the inline notation.)
Converted to a composite structure diagram, these relationships would be expressed as in the following diagram:
Composite Structure Diagram
Composite - parts are drawn with a solid-border rectangle, while - associated - properties have a dashed (or dotted) border.
The parts' and properties' designators are composed of their name and type.
Actually, parts and portions should also display their multiplicity (however, Visual Paradigm does not seem to allow for that).
Multiplicity may be drawn in a corner of the corresponding rectangle (which has been "faked" in the following diagram):
Composite Structure Diagram
Alternatively, multiplicity can be drawn in square brackets, after name and type (again, Visual Paradigm does not seem to allow for that):
Composite Structure Diagram


All links retrieved at the date of publication.

UML Tools

Find below an - unqualified - list of "UML tools listings".
Valid XHTML 1.0 Transitional Valid CSS!