UML Diagrams References

UML Diagrams References
Contents
Classification of UML 2.5 Diagrams ..................................................................................................................... 2
UML 2.5 Structure Diagrams ............................................................................................................................... 3
UML 2.5 Behavior Diagrams ................................................................................................................................ 4
Class Diagrams Reference .................................................................................................................. 6
Use Case Diagrams Reference .......................................................................................................... 16
Sequence Diagrams Reference ......................................................................................................... 22
Activity Diagrams Reference ............................................................................................................ 30
Communication Diagrams Reference ............................................................................................... 40
http://www.uml-diagrams.org
Copied-Pasted by Dip Thanh Nguyn, 2014
Page 1 of 41
Classification of UML 2.5 Diagrams

UML specification defines two major kinds of UML diagram: structure diagrams and behavior diagrams.
Structure diagrams show the static structure of the system and its parts on different abstraction and
implementation levels and how they are related to each other. The elements in a structure diagram represent the
meaningful concepts of a system, and may include abstract, real world and implementation concepts.
Behavior diagrams show the dynamic behavior of the objects in a system, which can be described as a series of
changes to the system over time.
UML 2.5 diagrams could be categorized hierarchically as shown below. Note, items shown in blue are not part of
official UML 2.5 taxonomy of diagrams.
UML 2.5 Diagrams Overview.

Note, items in blue are not part of official taxonomy of UML 2.5 diagrams.
Page 2 of 41
UML 2.5 Structure Diagrams

Structure diagrams show static structure of the system and its parts on different abstraction and
implementation levels and how those parts are related to each other. The elements in a structure diagram represent
the meaningful concepts of a system, and may include abstract, real world and implementation concepts.
Structure diagrams are not utilizing time related concepts, do not show the details of dynamic behavior. However,
they may show relationships to the behaviors of the classifiers exhibited in the structure diagrams.
Diagram
Class diagram
Purpose
Shows structure of the designed system, subsystem or component as
related classes and interfaces, with their features, constraints and
relationships - associations, generalizations, dependencies, etc.
Elements
class, interface, feature,co
nstraint, association,gene
ralization, dependency.
Object diagram
Instance level class diagram which shows instance specifications of

classes and interfaces (objects), slots with value specifications, and
links (instances of association).
Object diagram was defined in now obsolete UML 1.4.2
Specification as "a graph of instances, including objects and data
values. A static object diagram is an instance of a class diagram; it
shows a snapshot of the detailed state of a system at a point in
time." It also stated that object diagram is "a class diagram with
objects and no classes."
UML 2.5 specification simply provides no definition of object
diagram.
instance
specification,object, slot, l
ink.
Package diagram
Shows packages and relationships between the packages.
package, packageable
element, dependency,ele
ment import, package
import, package merge.
Model diagram
UML auxiliary structure diagram which shows some abstraction or

model, package, packagea
specific view of a system, to describe architectural, logical or behavioral ble element, dependency.
aspects of the system. It could show, for example, architecture of a
multi-layered (aka multi-tiered) application - see multi-layered
application model.
Composite
structure diagram
Diagram could be used to show:

Internal structure of a classifier
A behavior of a collaboration
Internal structure
diagram
Shows internal structure of a classifier - a decomposition of the

classifier into its properties, parts and relationships.
Collaboration use
diagram
Shows objects in a system cooperating with each other to produce some collaboration, property,co
behavior of the system.
nnector, part, dependency
.
Component
diagram
Shows components and dependencies between them. This type of

diagrams is used forComponent-Based Development (CBD), to
describe systems with Service-Oriented Architecture (SOA).
component, interface,pro
vided interface, required
interface, class, port,conn
ector, artifact,component
realization,usage.
Manifestation
diagram
While component diagrams show components and relationships

between components and classifiers, and deployment
diagrams - deployments of artifacts to deployment targets, some
missing intermediate diagram is manifestation diagram to be used
to showmanifestation (implementation)
of components by artifacts and internal structure of artifacts.
Because manifestation diagrams are not defined by UML 2.5
specification, manifestation of components by artifacts could be shown
using either component diagrams or deployment diagrams.
manifestation, component
,artifact.
Deployment
diagram
Shows architecture of the system as deployment (distribution) of

software artifacts todeployment targets.
Note, that components were directly deployed to nodes in UML 1.x
deployment diagrams. In UML 2.x artifacts are deployed to nodes,
and artifacts could manifest (implement) components. Components
are deployed to nodes indirectly through artifacts.
deployment, artifact,depl
oyment
target, node,device, execut
ion
environment,communicat
ion path,deployment
specification,
structured
class, property,part, port,
connector, usage.
Page 3 of 41
Specification level deployment diagram (also called type level)

shows some overview of deployment of artifacts to deployment
targets, without referencing specific instances of artifacts or nodes.
Instance level deployment diagram shows deployment of
instances of artifacts to specific instances of deployment targets. It
could be used for example to show differences in deployments to
development, staging or production environments with the names/ids
of specific build or deployment servers or devices.
Network
architecture
diagram
Deployment diagrams could be used to show logical or

physical network architecture of the system. This kind of
deployment diagrams - not formally defined in UML 2.5 - could be
called network architecture diagrams.
node, switch, router, load

balancer, firewall,commu
nication path,network
segment, backbone.
Profile diagram
Auxiliary UML diagram which allows to define custom stereotypes,

tagged values, and constraints as a lightweight extension
mechanism to the UML standard. Profiles allow to adapt the UML
metamodel for different
platforms (such as J2EE or .NET), or
domains (such as real-time or business process modeling).
Profile diagrams were first introduced in UML 2.0.
profile, metaclass,stereoty
pe, extension,reference, p
rofile application.
UML 2.5 Behavior Diagrams

Behavior diagrams show the dynamic behavior of the objects in a system, which can be described as a series of
changes to the system over time.
Diagram
Purpose
Elements
Use case diagram
Describes a set of actions (use cases) that some system or systems

(subject) should or can perform in collaboration with one or more
external users of the system (actors) to provide some observable and
valuable results to the actors or other stakeholders of the system(s).
Note, that UML 2.4.1 specification (see "16.4 Diagrams") stated
that Use Case Diagrams are a specialization of Class Diagrams such
that the classifiers shown are restricted to being either Actors or Use
Cases. Class diagrams are structure diagrams.
use
case, actor, subject,extend
, include, association.
Information flow
diagram
Shows exchange of information between system entities at some high

levels of abstraction. Information flows may be useful to describe
circulation of information through a system by representing aspects of
models not yet fully specified or with less details.
information
flow,information
item, actor,class.
Activity diagram
Shows sequence and conditions for coordinating lower-level behaviors,

rather than which classifiers own those behaviors. These are commonly
called control flow and object flowmodels.
activity, partition, action,o

bject, control, activity
edge.
State machine
diagram
Used for modeling discrete behavior through finite state transitions. In

addition to expressing the behavior of a part of the system, state
machines can also be used to express the usage protocol of part of a
system. These two kinds of state machines are referred to asbehavioral
state machines and protocol state machines.
Behavioral state
machine diagram
Shows discrete behavior of a part of designed system through finite

state transitions.
behavioral
state, behavioral
transition, pseudostate.
Protocol state
machine diagram
Shows usage protocol or a lifecycle of some classifier, e.g. which

operations of the classifier may be called in each state of the classifier,
under which specific conditions, and satisfying some optional
postconditions after the classifier transitions to a target state.
protocol state, protocol

transition, pseudostate.
Interaction
diagram
Interaction diagrams include several different types of diagrams:

sequence diagrams,
communication diagrams (known as collaboration diagrams in
UML 1.x),
timing diagrams,
interaction overview diagrams.
Sequence diagram Most common kind of interaction diagrams which focuses on the
message interchange between lifelines (objects).
lifeline, execution
specification, message,co
Page 4 of 41
mbined
fragment,interaction
use, state
invariant, destruction
occurrence.
Communication
diagram (a.k.a.Colla
boration
diagram in UML 1.x)
Focuses on the interaction between lifelines where the architecture of

the internal structure and how this corresponds with
the message passing is central. The sequencing of messages is given
through a sequence numbering scheme.
lifeline, message.
Timing diagram
Shows interactions when a primary purpose of the diagram is to reason

about time. Timing diagrams focus on conditions changing within and
among lifelines along a linear time axis.
lifeline, state or condition

timeline, destruction
event,duration
constraint, time
constraint.
Interaction
overview diagram
Defines interactions through a variant of activity diagrams in a way

that promotes overview of the control flow. Interaction overview
diagrams focus on the overview of the flow of control where the nodes
are interactions or interaction uses. The lifelines and the messages do
not appear at this overview level.
initial node, flow final

node,activity final
node, decision
node, merge node, fork
node,join
node, interaction,interacti
on use, duration
constraint, time
constraint.
Page 5 of 41
Class Diagrams Reference

Notation
Description
Class
o
o
o
Class Customer - details suppressed.
A class is a classifier which describes a set of objects that share the

same
features
constraints
semantics (meaning).
A class is shown as a solid-outline rectangle containing the class name,
and optionally with compartments separated by horizontal lines
containing features or other members of the classifier.
When class is shown with three compartments, the middle
compartment holds a list of attributes and the bottom compartment
holds a list of operations. Attributes and operations should be left
justified in plainface, with the first letter of the names in lower case.
Class SearchService - analysis level details

Middle compartment holds attributes and the bottom one holds
operations.
Class SearchService - implementation level details. The

createEngine is static operation.
Attributes or operations may be grouped by visibility. A visibility
keyword or symbol in this case can be given once for multiple features
with the same visibility.
Class SearchService - attributes and operations grouped by

visibility.
Utility is class that has only class scoped static attributes and
operations. As such, utility class usually has no instances.
Math is utility class - having static attributes and operations

(underlined)
Page 6 of 41
Abstract Class
Abstract class was defined in UML 1.4.2 as class that can't be
directly instantiated. No object may be a direct instance of an abstract
class.
UML 2.4 mentions abstract class but provides no definition. We may
assume that in UML 2.x abstract classdoes not have complete
declaration and "typically" can not be instantiated.
The name of an abstract class is shown in italics.
Class SearchRequest is abstract class.
Nested Classifiers
A class or interface could be used as a namespace for
various classifiers including other classes, interfaces, use cases, etc.
This nesting of classifier limits the visibility of the classifier defined
in the class to the scope of the namespace of the containing class or
interface.
In obsolete UML 1.4.2 a declaring class and a class in its namespace
may be shown connected by a line, with an "anchor" icon on the end
connected to a declaring class (namespace). An anchor icon is a cross
inside a circle.
UML 2.x specifications provide no explicit notation for the nesting by
classes. Note, that UML's 1.4 "anchor" notation is still used in one
example in UML 2.4.x for packages as an "alternative membership
notation".
Class LinkedList is nesting the Element interface. The Element is in
scope of the LinkedList namespace.
Class Template
UML classes could be templated or bound.
The example to the left shows bound class Customers with substitution
of the unconstrained parameter class T with class Customer and
boundary parameter n with the integer value 24.
Template class Array and bound class Customers. The Customers

class is an Array of 24 objects of Customer class.
Interface
An interface is a classifier that declares of a set of coherent public
features and obligations. An interface specifies a contract.
In UML 1.4 interface was formally equivalent to an abstract
class with no attributes and no methods and only abstract
operations.
An interface may be shown using a rectangle symbol with the
keyword interface preceding the name.
Interface SiteSearch.
The obligations that may be associated with an interface are in the form
of various kinds of constraints (such as pre- and postconditions) or
protocol specifications, which may impose ordering restrictions on
interactions through the interface.
Interface Pageable
Interface participating in the interface realization dependency is
shown as a circle or ball, labeled with the name of the interface and
attached by a solid line to the classifier that realizes this interface.
Interface SiteSearch is realized (implemented) by SearchService.
Page 7 of 41
The usage dependency from a classifier to an interface is shown by

representing the interface by a half-circle or socket, labeled with the
name of the interface, attached by a solid line to the classifier
that requires this interface.
Interface SiteSearch is used (required) by SearchController.
Object
Object is an instance of a class or an interface. Object is not a UML
element by itself. Objects are rendered asinstance specifications,
usually on object diagrams.
Class instance (object) could have no name, be anonymous.
Anonymous instance of the Customer class.
In some cases, class of the instance is unknown or not specified. When
instance name is also not provided, the notation for such an anonymous
instance of an unnamed classifier is simply underlined colon - :.
Instance newPatient of the unnamed or unknown class.
Interface instance (object) could have both name and associated
classifier.
Instance checkAcct of the Account interface.

Class instance (object) could have instance name, class and namespace
(package) specified.
Instance front-facing-cam of the Camera class from

android.hardware package.
If an instance has some value, the value specification is shown either
after an equal sign ('=') following the instance name, or without the
equal sign below the name.
Instance orderPaid of the Date class

has value July 31, 2011 3:00 pm.
Slots are shown as structural features with the feature name
followed by an equal sign ('=') and a value specification. Type
(classifier) of the feature could be also shown.
Instance newPatient of the Patient class

has slots with values specified.
Data Type
A data type is a classifier - similar to a class - whose instances are
identified only by their value.
A data type is shown using rectangle symbol with
keyword dataType.
DateTime data type
A data type may contain attributes and operations to support the
modeling of structured data types.
Structured data type Address
Page 8 of 41
When data type is referenced by, e.g., as the type of a class attribute, it
is shown simply as the name of the data type.
Attributes of the Patient class are of data types Name, Gender,

DateTime, Address and Visit.
Primitive Type
Primitive data type Weight.
A primitive type is a data type which represents atomic data values,

i.e. values having no parts or structure. A primitive data type may have
precise semantics and operations defined outside of UML, for example,
mathematically.
Standard UML primitive types include:
Boolean,
Integer,
UnlimitedNatural,
String.
A primitive type has the keyword primitive above or before the
name of the primitive type.
Enumeration
An enumeration is a data type whose values are enumerated in the
model as user-defined enumeration literals.
An enumeration may be shown using the classifier notation (a
rectangle) with the keyword enumeration. The name of the
enumeration is placed in the upper compartment.
A list of enumeration literals may be placed, one to a line, in the bottom
compartment. The attributes and operations compartments may be
suppressed, and typically are suppressed if they would be empty.
Enumeration AccountType.
Feature
Feature overview diagram
Association Qualifier
Given a company and a social security number (SSN) at most one

employee could be found.
A qualifier is a property which defines a partition of the set of

associated instances with respect to an instance at the qualified end.
Qualifiers are used to model hash maps in Java, dictionaries in
C#, index tables, etc. where fast access to linked object(s) is provided
using qualifier as a hash key, search argument or index.
A qualifier is shown as a small rectangle attached to the end of an
association between the final path segment and the symbol of the
classifier that it connects to. The qualifier rectangle is part of
the association, not part of the classifier. A qualifier may not be
suppressed.
Page 9 of 41
In the case in which the target multiplicity is 0..1, the qualifier value is
unique with respect to the qualified object, and designates at most one
associated object.
In the case of target multiplicity 0..*, the set of associated instances is
partitioned into possibly empty subsets, each selected by a given
qualifier instance.
Given a library and author name none to many books could be
found.
Given chessboard and specific rank and file we'll locate exactly 1
square. UML specification provides no lucid explanation of what
multiplicity 1 means for qualifier.
UML 2.4 specification is gibberish explaining multiplicity of qualifier:

The multiplicity of a qualifier is given assuming that the qualifier
value is supplied. The raw multiplicity without the qualifier is
assumed to be 0..*. This is not fully general but it is almost always
adequate, as a situation in which the raw multiplicity is 1 would best
be modeled without a qualifier.
Operation
Operation executeQuery is public, isPoolable - protected,

getQueryTimeout - with package visibility, and clearWarnings is
private.
Operation is a behavioral feature of a classifier that specifies the

name, type, parameters, and constraints for invoking an associated
behavior.
When operation is shown in a diagram, the text should conform to the
syntax defined in UML specification. Note, that UML 2.2 to 2.4
specifications seem to have wrong nesting for operation's properties,
making presence of the properties dependent on the presence of return
type. The syntax provided here is non-normative and different from the
one in the UML 2.4 specification:
operation ::= [ visibility ] signature [ oper-properties ]
Visibility of the operation is optional, and if present, it should be one
of:
visibility ::= '+' | '-' | '#' | '~'
Signature of the operation has optional parameter list and return

specification.
signature ::= name '(' [ parameter-list ] ')' [ ':' return-spec ]
Name is the name of the operation. Parameter-list is a list of parameters
of the operation in the following format:
parameter-list ::= parameter [ ',' parameter ]*
parameter ::= [ direction ] parm-name ':' typeexpression [ '[' multiplicity ']' ] [ '=' default ] [ parm-properties ]
Parm-name is the name of the parameter. Type-expression is an
File has two static operations - create and slashify. Create has two expression that specifies the type of the parameter. Multiplicity is the
multiplicity of the parameter. Default is an expression that defines the
parameters and returns File. Slashify is private operation.
Operation listFiles returns array of files. Operations getName and value specification for the default value of the parameter. Parameter list
listFiles either have no parameters or parameters were suppressed. can be suppressed.
Operation setDaemon has one input parameter, while single

parameter of changeName is both input and output parameter.
Static enumerate returns integer result while also having output
parameter - array of threads. Operation isDaemon is shown with
return type parameter. It is presentation option equivalent to
returning operation result as: +isDaemon(): Boolean.
Direction of parameter is described as one of:

direction ::= 'in' | 'out' | 'inout' | 'return'
and defaults to 'in' if omitted.
Optional parm-properties describe additional property values that
apply to the parameter.
parm-properties ::= '{' parm-property [ ',' parm-property ]* '}'
Optional return specification is defined as:
return-spec ::= [ return-type ] [ '[' multiplicity ']' ]
Return type is the type of the result, if it was defined for the operation.
Return specification also has optional multiplicity of the return type.
Properties of the operation are optional, and if present should follow

the rule:
oper-properties ::= '{' oper-property [ ',' oper-property ]* '}'
oper-property ::= 'redefines' opername | 'query' | 'ordered' | 'unique' | oper-constraint
Properties of operation describe operation in general or return
parameter, and are defined as:
redefines oper-name - operation redefines an inherited operation
identified by oper-name;
Operation check redefines inherited operation status from the
query - operation does not change the state of the system;
superclass. Operation getPublicKey does not change the state of the
system. Operation getCerts returns ordered array of Certificates
ordered - the values of the return parameter are ordered;
without duplicates.
unique - the values returned by the parameter have no duplicates;
Page 10 of 41
oper-constraint - is a constraint that applies to the operation.
Abstract Operation
Abstract operation in UML 1.4.2 was defined as operation without
implementation - "class does not implement the operation".
Implementation had to be supplied by a descendant of the class.
Abstract operation in UML 1.4.2 was shown with its signature
in italics or marked as {abstract}.
There is neither definition nor notion for abstract operation in UML
2.4.
Constraint
Constraint could have an optional name, though usually it is
anonymous. A constraint is shown as a text string in curly braces
according to the syntax:
constraint ::= '{' [ name ':' ] boolean-expression '}'
For an element whose notation is a text string (such as a
class attribute, etc.), the constraint string may follow the element text
string in curly braces.
Bank account attribute constraints - non empty owner and
positive balance.
For a Constraint that applies to two elements (such as two classes or
two associations), the constraint may be shown as a dashed
line between the elements labeled by the constraint string in curly
braces.
Account owner is either Person or Corporation, {xor} is predefined

UML constraint.
The constraint string may be placed in a note symbol and attached to
each of the symbols for the constrained elements by a dashed line.
Bank account constraints - non empty owner and positive

balance
Multiplicity
Multiplicity is a definition of an inclusive interval of non-negative
integers to specify the allowable number of instances of described
element.
Multiplicity could be described with the following non-normative syntax
rules:
multiplicity ::= multiplicity-range [ '{' multiplicityoptions '}' ]
Some typical examples of multiplicity bounds:
Multiplicity of Players for Soccer Team class.
Collection must be empty
Exactly one instance
Exactly 5 instances
Zero or more instances
0..1
No instances or one instance
1..1
Exactly one instance
0..*
Zero or more instances
1..*
At least one instance
Page 11 of 41
m..n
At least m but no more than n instances
Multiplicity options could also specify of whether the values in an

instantiation of the element should beunique and/or ordered:
multiplicity-options ::=
order-designator [ ',' uniqueness-designator ] |
uniqueness-designator [ ',' order-designator ]
order-designator ::= 'ordered' | 'unordered'
uniqueness-designator ::= 'unique' | 'nonunique'
If multiplicity element is multivalued and specified as ordered, then
the collection of values in an instantiation of this element is sequentially
ordered. By default, collections are not ordered.
If multiplicity element is multivalued and specified as unique, then
each value in the collection of values in an instantiation of this element
must be unique. By default, each value in collection is unique.
Customer has none to many purchases. Purchases are in specific

order and each one is unique (by default).
Data Source could have a Logger and has ordered pool of min to
max Connections. Each Connection is unique (by default).
Visibility
Operation executeQuery is public, isPoolable - protected,

getQueryTimeout - with package visibility, and clearWarnings is
private.
Visibility allows to constrain the usage of a named element, either

in namespaces or in access to the element. It is used
with classes, packages, generalizations, element
import, package import.
UML has the following types of visibility:
public (+)
package (~)
protected (#)
private (-)
If a named element is not owned by any namespace, then it does
not have a visibility.
Association
Association is a relationship between classifiers which is used to
show that instances of classifiers could be either linked to each other
or combined logically or physically into some aggregation.
It is normally drawn as a solid line connecting associated classifiers.
Binary association relates two typed instances. It is normally
rendered as a solid line connecting two classifiers, or a solid line
connecting a single classifier to itself (the two ends are distinct). The
line may consist of one or more connected segments.
Job is associated with Year.
Order of the ends and reading: Car - was designed in - Year
A small solid triangle could be placed next to or in place of the name

of binary association (drawn as a solid line) to show the order of
the ends of the association. The arrow points along the line in the
direction of the last end in the order of the association ends. This
notation also indicates that the association is to be read from the first
end to the last end.
Any association may be drawn as a diamond (larger than a terminator
on a line) with a solid line for each association end connecting the
diamond to the classifier that is the ends type. N-ary
association with more than two ends can only be drawn this way.
Ternary association Design relating three classifiers.
Aggregation
Aggregation (aka shared aggregation) is shown as binary
association decorated with a hollow diamond as a terminal
adornment at the aggregate end of the association line.
Search Service has a Query Builder using
sharedaggregation
Page 12 of 41
Composite Aggregation (Composition)

Composite aggregation (aka composition) is a "strong" form
of aggregation.
Composition is depicted as binary association decorated with a filled
black diamond at the aggregate (composite) end.
Folder could contain many files, while each File has exactly one
Folder parent. If Folder is deleted, all contained Files are deleted as
well.
Hospital has 1 or more Departments, and each Department belongs

to exactly one Hospital.
If Hospital is closed, so are all of its Departments.
When composition is used in domain models, both whole/part

relationship as well as event of composite "deletion" should be
interpreted figuratively, not necessarily as physical containment and/or
termination.
Multiplicity of the composite (whole) could be specified as 0..1 ("at

most one") which means that part is allowed to be a "stand alone", not
owned by any specific composite.
Each Department has some Staff, and each Staff could be a member
of one Department (or none). If Department is closed, its Staff is
relieved (but excluding the "stand alone" Staff).
Ownership of Association End
Association end query is owned by classifier QueryBuilderand

association end qbuilder is owned by association Buildsitself.
Association end qb is an attribute of SearchService class and

is owned by the class.
Ownership of association ends by an associated classifier may be

indicated graphically by a small filled circle (aka dot). The dot is
drawn at the point where line meets the classifier. It could be
interpreted as showing that the model includes a property of the type
represented by the classifier touched by the dot. This property
is owned by the classifier at the other end.
Attribute notation can be used for an association end owned by a
class, because an association end owned by a class is also
an attribute. This notation may be used in conjunction with the line
arrow notation to make it perfectly clear that the attribute is also
an association end.
Association Navigability
No adornment on the end of an association means unspecified
navigability.
Both ends of association have unspecified navigability.

Navigable end is indicated by an open arrowhead on the end of an
association.
A2 has unspecified navigability while B2 is navigablefrom

A2.
Not navigable end is indicated with a small x on the end of an
association.
A3 is not navigable from B3 while B3 has unspecified

navigability.
A4 is not navigable from B4 while B4 is navigable from A4.
A5 is navigable from B5 and B5 is navigable from A5.
Page 13 of 41
A6 is not navigable from B6 and B6 is not navigable from A6.
Generalization
A Generalization is shown as a line with a hollow triangle as an
arrowhead between the symbols representing the involved classifiers.
The arrowhead points to the symbol representing the general classifier.
This notation is referred to as the "separate target style."
Checking, Savings, and Credit Accounts are generalized by

Account.
Multiple Generalization relationships that reference the same general
classifier can also be connected together in the "shared target style."
Checking, Savings, and Credit Accounts are generalized by

Account.
Dependency
Dependency relationship is used on class diagrams to
show usage dependency or abstraction.
A dependency is generally shown as a dashed arrow between two model
elements. The model element at the tail of the arrow
(the client) depends on the model element at the arrowhead
(the supplier). The arrow may be labeled with an optional stereotype
and an optional name.
Data Access depends on Connection Pool
Usage
Usage is a dependency relationship in which one element (client)
requires another element (or set of elements) (supplier) for its
full implementation or operation.
For example, it could mean that some method(s) within a (client) class
uses objects (e.g. parameters) of the another (supplier) class.
A usage dependency is shown as a dependency with a use keyword
attached to it.
Search Controller uses Search Engine.
Create
Create is a usage dependency denoting that the client classifier
creates instances of the supplier classifier. It is denoted with the
standard stereotype create.
Data Source creates Connection
Create may relate an instance value to a constructor for a class,
describing the single value returned by the constructor operation. The
operation is the client, the created instance the supplier. The instance
value may reference parameters declared by the operation.
Account constructor creates new instance of Account
Required Interface
Interface SiteSearch is used (required) by SearchController.
Required interface specifies services that a classifier needs in order

to perform its function and fulfill its own obligations to its clients. It is
specified by a usage dependency between the classifier and the
correspondinginterface.
The usage dependency from a classifier to an interface is shown by
representing the interface by a half-circle or socket, labeled with the
name of the interface, attached by a solid line to the classifier that
requires this interface.
Page 14 of 41
If interface is represented using the rectangle notation, interface

usage dependency is denoted with dependency arrow. The classifier at
the tail of the arrow uses (requires) the interface at the head of the
arrow.
Interface SiteSearch is used (required) by Search Controller.
Interface Realization
The interface realization dependency from a classifier to an
interface is shown by representing the interface by a circle or ball,
labeled with the name of the interface and attached by a solid line to the
classifier that realizes this interface.
In cases where interfaces are represented using the rectangle
notation, interface realization dependency is denoted with interface
realization arrow. The classifier at the tail of the arrow implements the
interface at the head of the arrow.
Page 15 of 41
Use Case Diagrams Reference

Notation
Description
Subject
The subject (of use cases) is the system under design or
consideration to which a set of use cases apply. The subject could
be a physical system, software program, or smaller element that may
have behavior, e.g.subsystem, component, or even class.
Subject is presented by a rectangle with subject name in upper
corner with applicable use cases inside the rectangle
and actors - outside of the system boundaries.
Books Online (subject) with applicable use cases and Web Customer
actor.
Standard UML stereotypes and keywords for the subject are:

subsystem
process
service
component
Weather Service subject stereotyped as service.
Applicability of Use Cases

Use cases visually located inside the system boundaries are the use
cases applicable to the subject (but not necessarily owned by the
subject).
Use cases Browse Items and Buy Items are applicable to Retail
Website subject.
Ownership of Use Cases

The nesting (ownership) of a use case by a classifier is
represented using the standard notation for nested classifiers.
Retail Website subject owns use cases.
Page 16 of 41
Actor
Standard UML icon for actor is "stick man" icon with the name of
the actor above or below the icon. Actor names should follow the
capitalization and punctuation guidelines for classes. The names of
abstract actors should be shown in italics. All actors must have
names.
Student actor.
Custom icons that convey the kind of actor may also be used to
denote an actor, such as using a separate icon(s) for non-human
actors.
Custom icon for Web Client actor.
Custom icon for Bank actor.

A business actor (introduced in Rational Unified Process to
support Business Modeling) represents a role played by some person
or system external to the modeled business. Business actor is not
part of UML standard.
Business actor is shown as "stick man" icon with a line crossing
its head.
Business actor Passenger.
An actor may also be shown as a class rectangle with the
keyword actor, having usual notation for class compartments, if
needed.
Customer actor as Class.
Generalization between actors

Generalization between actors is rendered as a solid directed line
with a large arrowhead (the same as for generalization between
classes).
Web Client actor is abstract superclass for Administrator, Editor and

Customer.
Page 17 of 41
Use Case
Every use case must have a name. Use case is shown as an ellipse
containing the name of the use case.
User Registration Use Case.

A use case could be shown as an ellipse with the name of the use case
placed below the ellipse.
Transfer Funds Use Case.

Business use case was introduced in Rational Unified
Process to support Business Modeling - to represent business
function, process, or activity performed in the modeled business.
Business use case is represented in RUP with use case oval icon
and a line crossing it down right.
Business use case Individual Check-In.
An optional stereotype keyword may be placed above the name and a
list of properties - operations and attributes - included below the
name in a compartment.
Use Case User Sign-In stereotyped as authentication

Use case with extension points may be listed in a compartment of
the use case with the heading extension points.
Registration Use Case with extension points Registration Help and

User Agreement.
A use case can also be shown using the standard rectangle notation
for classifiers with an ellipse icon in the upper righthand corner of
the rectangle and with optional separate list compartments for its
features.
Registration Use Case shown using the standard rectangle notation

for classifiers.
Page 18 of 41
Use case could be rendered in the frame labeled as use case or in

abbreviated form as uc.
The content area of the frame could contain different kinds of UML
diagrams. For example, use case could be described with activity
diagram or state machine.
Use case Search Items rendered as frame with

associated Search Items activity diagram
Generalization between use cases

Generalization between use cases is similar to generalization
between classes child use case inherits properties and behavior of
the parent use case and may override the behavior of the parent.
It is rendered as a solid directed line with a large arrowhead, the
same as for generalization between classifiers.
Web User Authentication use case is abstract use casespecialized by

Login, Remember Me and Single Sign-On use cases.
Extend
Extend is a directed relationship that specifies how and when
the behavior defined in usually supplementary
(optional) extending use case can be inserted into the behavior
defined in the extended use case.
Extended use case is meaningful on its own, it is independent of
the extending use case. Extending use case typically
defines optional behavior that is not necessarily meaningful by
itself.
Registration use case is complete and meaningful on its own. It
Extend relationship between use cases is shown by a dashed arrow
could be extended with optional Get Help On Registrationuse case. with an open arrowhead from theextending use case to
the extended (base) use case. The arrow is labeled with the
keyword extend.
The condition of the extend relationship as well as the references to
the extension points are optionally shown in a comment note
attached to the corresponding extend relationship.
Registration use case is conditionally extended by Get Help On

Registration use case in extension point Registration Help.
Page 19 of 41
Extension Point
An extension point is a feature of a use case which identifies
(references) a point in the behavior of the use case where that
behavior can be extended by some other (extending) use case, as
specified by extendrelationship.
Extension points may be shown in a compartment of the use case
oval symbol under the heading extension points. Each extension
point must have a name, unique within a use case. Extension points
are shown as a text string according to the syntax:
extension point ::= name [: explanation ]
Registration Use Case with extension points Registration Help and
User Agreement.
Extension points may be shown in a compartment of the use case
rectangle with ellipse icon under the heading extension points.
Extension points of the Registration use case shown using the

rectangle notation.
Include
Deposit Funds and Withdraw Cash use cases includeCustomer

Authentication use case.
An include relationship is a directed relationship between

two use cases when required, not optional behavior of
the included use case is inserted into the behavior of
the including (base) use case.
The include relationship is analogous to a subroutine call or macro
and could be used:
when there are common parts of the behavior of two or more use
cases,
to simplify large use case by splitting it into several use cases.
An include relationship between use cases is shown by a dashed
arrow with an open arrowhead from the base use case to the
included use case. The arrow is labeled with the
keyword include.
Large and complex use case could be simplified by splitting it into
several use cases each describing some logical unit of behavior. Note,
that including use case becomes incomplete by itself and requires
included use cases to be complete.
Checkout use case includes several use cases - Scan Item,

Calculate Total and Tax, and Payment
Association
An association between an actor and a use case indicates that the
actor and the use case communicate with each other.
An actor could be associated to one or several use cases.
Actor Customer associated with two use cases.
Page 20 of 41
Use case may have one or several associated actors.

It may not be obvious from use case diagram which
actor initiates the use case, i.e. is "primary actor". (In nonstandard UML, primary actors are those using system services,
and supporting actors are actors providing services to the
system.)
Use case Manage Account associated with Customer and
Bank actors.
Actor Bank is involved in multiple Use cases Transfer Funds.
Two or more Player Actors are required to initiate Play GameUse

case.
When an actor has an association to a use case with

a multiplicity that is greater than one at the use caseend, it means
that a given actor can be involved in multiple use cases of that
type. The specific nature of this multiple involvement is not
defined in the UML 2.2.
Use case multiplicity could mean that an actor initiates multiple use
cases:
in parallel (concurrently), or
at different points in time, or
mutually exclusive in time.
When a use case has an association to an actor with a multiplicity
that is greater than one at the actor end, it means that more than
one actor instance is involved in initiating the use case. The
manner in whichmultiple actors participate in the use case is not
defined in the UML 2.2.
For instance, actor's multiplicity could mean that:
a particular use case might require simultaneous (concurrent)
action by two separate actors (e.g., in launching a nuclear missile),
or
it might require complementary and successive actions by the
actors (e.g., one actor starting something and the other one stopping
it).
Page 21 of 41
Sequence Diagrams Reference

Notation
Description
Lifeline
A Lifeline is shown using a symbol that consists of a rectangle
forming its head followed by a vertical line (which may be dashed)
that represents the lifetime of the participant.
Lifeline with name "data" of class Stock.

Anonymous lifeline has no name - arbitrary representative of
class.
Anonymous lifeline of class User.

Selector could be used to specify some lifeline from collection.
Lifeline "x" of class X is selected with selector [k].
Execution
Execution (full name - execution specification, informally

called activation) is interaction fragmentwhich represents a
period in the participant's lifetime when it is
executing a unit of behavior or action within the lifeline,
sending a signal to another participant,
waiting for a reply message from another participant.
The duration of an execution is represented by two execution
occurrences - the start occurrence and thefinish occurrence.
Execution is represented as a thin grey or white rectangle on the
lifeline.
Execution specification shown as grey rectangle on the Service

lifeline.
Execution can be represented by a wider labeled rectangle, where
the label usually identifies the action that was executed.
Execution represented as wider rectangle labeled as action.
Page 22 of 41
Overlapping executions on the same lifeline are represented by

overlapping rectangles.
Overlapping execution specifications on the same lifeline - message to

self.
Overlapping execution specifications on the same lifeline - callback

message.
Message
Message is a named element that defines one specific kind of
communication between lifelines of an interaction. The message
specifies not only the kind of communication, but also the sender
and the receiver. Sender and receiver are normally two occurrence
specifications (points at the ends of messages).
A message is shown as a line from the sender message end to the
receiver message end. The line must be such that every line fragment
is either horizontal or downwards when traversed from send event to
receive event. The send and receive events may both be on the same
lifeline. The form of the line or arrowhead reflects properties of the
message.
Messages by Action Type
Depending on the type of action that was used to generate the

message, message could be one of:
synchronous call
asynchronous call
asynchronous signal
create
delete
reply
Synchronous Call
Synchronous call typically represents operation call - send
message and suspend execution while waiting for response.
Synchronous Messages are shown with filled arrow head.
Web Client searches Online Bookshop and waits for results.
Page 23 of 41
Asynchronous Call
Asynchronous call - send message and proceed immediately
without waiting for return value. Asynchronous Messages have an
open arrow head.
Service starts Task and proceeds in parallel without waiting.
Asynchronous Signal
Asynchronous signal message corresponds to
asynchronous send signal action.
Create Message
Create message is sent to lifeline to create itself. Note, that it is
weird but common practice in OOAD to send create message to a
nonexisting object to create itself. In real life, create message is sent
to some runtime environment.
Create message is shown as a dashed line with open arrowhead
(same as reply), and pointing to created lifeline's head.
Online Bookshop creates Account.
Delete Message
Delete message (called stop in previous versions of UML) is sent to
terminate another lifeline. The lifeline usually ends with a cross in
the form of an X at the bottom denoting destruction occurrence.
UML 2.3 specification provides neither specific notation for delete
message nor a stereotype. Until they provide some notation, we can
use custom destroy stereotype.
Online Bookshop terminates Account.
Reply Message
Reply message to an operation call is shown as a dashed line with
open arrow head.
Web Client searches Online Bookshop and waits for results to be

returned.
Messages by Presence of Events
Depending on whether message send event and receive events are

present, message could be one of:
complete message
lost message
found message
unknown message (default)
Page 24 of 41
Lost Message
Lost Message is a message where the sending event is known, but there is no receiving
event. It is interpreted as if the message never reached its destination. Lost messages are
denoted with as a small black circle at the arrow end of the message.
Web Client sent search message which was lost.
Found Message
Found Message is a message where the receiving event is known, but
there is no (known) sending event. It is interpreted as if the origin of the
message is outside the scope of the description. This may for example be
noise or other activity that we do not want to describe in detail.
Found messages are denoted with a small black circle at the starting end
of the message.
Online Bookshop gets search message of unknown origin.
Destruction Occurrence
Destruction occurrence is a message occurrence which
represents the destruction of the instance described by the lifeline.
It may result in the subsequent destruction of other objects that this
object owns bycomposition. No other occurrence may appear
below the destruction on a given lifeline.
Complete UML name of the occurrence is destruction
occurrence specification. Until UML 2.4 it was
calleddestruction event, and earlier - stop.
The destruction of instance is depicted by a cross in the form of
an X at the bottom of a lifeline.
Account lifeline is terminated
State Invariant
A state invariant is an interaction fragment which represents a
runtime constraint on the participants of the interaction. It may be
used to specify different kinds of constraints, such as values of
attributes or variables, internal or external states, etc.
State invariant is usually shown as a constraint in curly braces on the
lifeline.
Attribute t of Task should be equal to complete.

It could also be shown as a state symbol representing the equivalent
of a constraint that checks the state of the object represented by the
lifeline. This could be either the internal state of the classifier
behavior of the corresponding classifier or some external state based
on a "black-box" view of the lifeline.
Task should be in Finished state.
Combined Fragment
Interaction operator could be one of:

alt - alternatives
opt - option
Page 25 of 41
loop - iteration
break - break
par - parallel
strict - strict sequencing
seq - weak sequencing
critical - critical region
ignore - ignore
consider - consider
assert - assertion
neg - negative
Alternatives
The interaction operator alt means that the combined fragment
represents a choice or alternatives of behavior. At most one of the
operands will be chosen. The chosen operand must have an explicit
or implicit guard expression that evaluates to true at this point in the
interaction.
Call accept() if balance > 0, call reject() otherwise.
Option
The interaction operator opt means that the combined fragment
represents a choice of behavior where either the (sole) operand
happens or nothing happens. An option is semantically equivalent to
an alternative combined fragment where there is one operand with
non-empty content and the second operand is empty.
Post comments if there were no errors.
Loop
If loop has no bounds specified, it means potentially infinite loop
with zero as lower bound and infinite upper bound.
Potentially infinite loop.

If only min-int is specified, it means that upper bound is equal to
the lower bound, and loop will be executed exactly the specified
number of times.
Loop to execute exactly 10 times.
Page 26 of 41
If both bounds are specified, loop will iterate minimum the minint number of times and at most the max-intnumber of times.
Besides iteration bounds loop could also have an interaction
constraint - a Boolean expression in square brackets. To add to the
other confusions, UML 2.3 also calls both of them guards.
UML tries to shuffle the simplest form of for loop and while
loop which causes weird UML 2.3 loop semantics on p.488: "after
the minimum number of iterations have executed and the Boolean
expression is false the loop will terminate". This is clarified - with
opposite meaning - on the next page as "the loop will only continue if
that specification evaluates to true during execution regardless of the
minimum number of iterations specified in the loop."
We may guess that as per UML 2.3, the loop is expected to execute
minimum 5 times and no more than 10 times. If guard condition
[size<0] becomes false loop terminates regardless of the minimum
number of iterations specified. (Then why do we need that min number
specified?!)
Break
The interaction operator break represents a breaking or
exceptional scenario that is performed instead of the remainder of
the enclosing interaction fragment.
Note, UML allows only one level - directly enclosing interaction
fragment - to be abandoned. This could become really annoying if
double loop or loop with other combined fragments should be
broken.
Break enclosing loop if y>0.
Parallel
The interaction operator par defines potentially parallel execution
of behaviors of the operands of the combined fragment. Different
operands can be interleaved in any way as long as the ordering
imposed by each operand is preserved.
Search Google, Bing and Ask in any order, possibly parallel.

Parallel combined fragment has a notational shorthand for the
common situations where the order of events on one lifeline is
insignificant. In a coregion area of a lifeline restricted by horizontal
square brackets all directly contained fragments are considered as
separate operands of a parallel combined fragment.
Coregion - search Google, Bing and Ask in any order, possibly parallel.
Page 27 of 41
Strict Sequencing
The interaction operator strict requires a strict sequencing (order)
of the operands on the first level within the combined fragment.
Search Google, Bing and Yahoo in the strict sequential order.
Weak Sequencing
Weak sequencing seq is defined by the set of traces with these

properties:
The ordering of occurrence specifications within each of the
operands are maintained in the result.
Occurrence specifications on different lifelines from different
operands may come in any order.
Occurrence specifications on the same lifeline from different
operands are ordered such that an occurrence specification of the
first operand comes before that of the second operand.
Thus weak sequencing seq reduces to a parallel merge when the
operands are on disjunct sets of participants. Weak sequencing
reduces to strict sequencing when the operands work on only one
participant.
Search Google possibly parallel with Bing and Yahoo, but search Bing
before Yahoo.
Critical Region
The interaction operator critical defines that the combined
fragment represents a critical region. A critical region is a region
with traces that cannot be interleaved by other occurrence
specifications (on the lifelines covered by the region). This means
that the region is treated atomically by the enclosing fragment and
can't be interleaved, e.g. by parallel operator.
Add() or remove() could be called in parallel, but each one should run
as a critical region.
Ignore
Interaction operator ignore means that there are some messages
that are not shown within this combined fragment. These message
types can be considered insignificant and are implicitly ignored if
they appear in a corresponding execution.
The list of ignored messages follows the operand enclosed in a pair
of curly braces "{" and "}". Ignore operation is typically combined
with other operations such as "assert ignore {m, s}."
Ignore get and set messages, if any.
Page 28 of 41
Consider
The interaction operator consider defines which messages should
be considered within this combined fragment, meaning that any
other message will be ignored.
The list of considered messages follows the operand enclosed in a
pair of curly braces "{" and "}". Consider operation is typically
combined with other operations such as "assert consider {m, s}."
Consider only add() or remove() messages, ignore any other.
Assert
The interaction operator assert means that the combined fragment
represents the assertion that the sequences of the assert operand are
the only valid continuations (must be satisfied by a correct design of
the system). All other continuations result in an invalid trace.
Commit() message should occur at this point, following with

evaluation of state invariant.
Negative
The interaction operator neg describes combined fragment of traces
that are defined to be negative (invalid). Negative traces are the
traces which occur when the system has failed. All interaction
fragments that are different from the negative are
considered positive, meaning that they describe traces that are
valid and should be possible.
Should we receive back timeout message, it means the system has

failed.
Interaction Use
Interaction use is interaction fragment which allows to use (or
call) another interaction. Large and complex sequence diagrams
could be simplified with interaction uses. It is also common reusing
some interaction between several other interactions.
The interaction use is shown as a combined fragment with
operator ref.
Web customer and Bookshop use (reference) interaction Checkout.

The syntax of the interaction use of the ref operator is:
interaction-use ::= [ attribute-name '=' ] [ collaboration-use '.'
] interaction-name [ io-arguments ] [ ':' return-value ]
io-arguments ::= '(' io-argument [ ',' io-argument ]* ')'
io-argument ::= in-argument | 'out' out-argument
Use Login interaction to authenticate user and assign result back to

the user attribute of Site Controller.
Page 29 of 41
Activity Diagrams Reference

Notation
Description
Activity
Activity is parameterized behavior represented as coordinated
flow of actions.
Activity could be rendered as round-cornered rectangle with activity
name in the upper left corner and nodes and edges of the activity
inside.
Online Shopping activity.

Activity parameters are displayed on the border and listed below the
activity name as:
parameter-name: parameter-type.
Authenticate User activity with two parameters - Login Id and

Password.
The round-cornered activity border may be replaced with the
diagram frame. The kind of the frame in this case
is activity or act in short form. Activity parameters if any are
displayed on the frame.
Authenticate User activity frame with two parameters - Login Id and

Password.
Partition
An activity partition is activity group for actions that have some
common characteristic.
Activity partition may be shown using a swimlane notation - with
two, usually parallel lines, either horizontal or vertical, and a name
labeling the partition in a box at one end.
Activity partitions Customer and Order Dept as horizontal swimlanes.
Page 30 of 41
Activity partitions Customer and Order Dept as vertical swimlanes.

Hierarchical partitioning is represented using swimlanes for
subpartitions.
Hierarchical partitioning with subpartitions.

When activities are considered to occur outside the domain of a
particular model, the partition can be labeled with the
keyword external.
Buy action occurs in external partition Customer.

In the situations when we can't use swimlanes to show partitions,
alternate text notation with qualified action name could be used
instead. In this case partition name is placed in parenthesis above
the action name. A comma-delimited list of partition names means
that the node is contained in more than one partition. A double
colon within a partition name indicates that the partition is nested,
with the larger partitions coming earlier in the name.
Action
Actions are notated as round-cornered rectangles. The name of the
action or other description of it may appear in the symbol.
The Process Order action

Action could be expressed in some application-dependent action
language.
Example of action expressed in some application-dependentaction

language.
Page 31 of 41
Local pre-conditions and local post-conditions are shown

as notes attached to the invocation with the keywords
localPrecondition and localPostcondition, respectively.
Local pre- and post-conditions shown as notes attached

to Process Order action.
In the situations when we can't use swimlanes to show partitions,
alternate text notation with qualified action name could be used
instead. In this case partition name is placed in parenthesis above
the action name. A comma-delimited list of partition names means
that the node is contained in more than one partition. A double
colon within a partition name indicates that the partition is nested,
with the larger partitions coming earlier in the name.
Object Action
Object actions include different actions on objects. Object action is

not present explicitly in UML standard, it is added here for clarity. In
the UML standard all object actions are direct subclasses of action.
Object actions:
create object action
destroy object action
test identity action
read self action
value specification action
start classifier behavior action
read is classified object action
reclassify object action
read extend action
Variable Action
Variable actions overview diagram
Page 32 of 41
Invocation Action
Invocation actions overview diagram
Call Behavior Action

Call behavior action is a call action that invokes
a behavior directly rather than invoking an operation that invokes
the behavior.
It is shown as action with the name of the behavior that is
performed by the action or description of the behavior placed inside
the action's round-cornered rectangle. If the node name is different
than the behavior name, then it appears in the symbol instead.
Note, that because it looks exactly the same way as the common
action, there is no way just looking at the diagram to say whether the
name is common action name, call behavior action name or some
behavior name.
Call behavior action for Checkout behavior
Call activity action is indicated by a rake-style symbol within the

action symbol. Note, that though UML 2.4 specification provides this
notation, there is no official call activity action in the UML
specification.
Call activity action for User Authentication activity
Send Signal Action
Notify Customer send signal action creates and sendsNotify

Customer signal
Send signal action is an invocation action that creates

a signal from its inputs, and transmits it to the
specified target object, where it may cause the firing of a state
machine transition or the execution of an activity.
When all the prerequisites of the action execution are satisfied, a
signal is generated from the arguments and is transmitted to the
identified target object. The sender of the signal (aka "requestor")
continues execution immediately, without waiting for any response.
Send signal action is notated as convex pentagon. Note, that
the name of the action corresponds to the name of signal class it
sends. Target object is not specified with this notation.
Page 33 of 41
Structural Feature Action
Structural feature actions overview diagram
Link Action
Link actions overview diagram.
Page 34 of 41
Event Action
Event actions overview diagram.
Accept Event Action

Accept event action is notated with a concave pentagon.
Acceptance of the Accept Order signal causes an invocation of

a Process Order action. The accept event action Accept Order is
enabled on entry to the activity containing it, thereforeno input
arrow is shown.
If an accept event action has no incoming edges, then the action

starts when the containing activity or structured node does,
whichever most immediately contains the action. In addition, an
accept event action with no incoming edges remains enabled after it
accepts an event. It does not terminate after accepting an event and
outputting a value, but continues to wait for other events.
An action whose trigger is a signal event is informally
called accept signal action. It corresponds to send signal
action.
Accept Event Action with incoming edges

Accept event action could have incoming edges. In this case the
action starts after the previous action completes.
Payment Requested signal is sent. The activity then waits to

receive Payment Confirmed signal. Acceptance of thePayment
Confirmed is enabled only after the request for payment is sent; no
confirmation is accepted until then.
Wait Time Action
The Every Hour accept time event action generates

an output every hour. There are no incoming edges
to this time event action, so it is enabled as long as its
containing activity or structured node is.
If the event is a time event occurrence, the result value contains

the time at which the occurrence happened. Such an action is
informally called a wait time action.
Accept time event action (aka informal: wait time action) is
notated with an hour glass.
Page 35 of 41
Control Nodes
Activity control nodes overview.
Initial Node
Initial node is a control node at which flow starts when the activity
is invoked. Activity may have more than one initial node. Initial
nodes are shown as a small solid circle.
Activity initial node.
Flow Final Node

Flow final node is a control final node that terminates a flow. The
notation for flow final node is small circle with X inside.
Flow final node.
Activity Final Node

Activity final node is a control final node that stops all flows in
an activity. Activity final is new in UML 2.0. Activity final nodes are
shown as a solid circle with a hollow circle inside. It can be thought
of as a goal notated as "bulls eye," or target.
Activity final node.
Decision
Decision node is a control node that accepts tokens on one or
two incoming edges and selects one outgoing edge from one or
more outgoing flows.
The notation for a decision node is a diamond-shaped symbol.
Decision node with two outgoing edges with guards.

For decision points, a predefined guard "else" may be defined for
at most one outgoing edge.
Decision node with three outgoing edges and [else] guard.
Page 36 of 41
Decision can have decision input behavior. Decision input

behaviors were introduced in UML to avoid redundant
recalculations in guards. In this case each data token is passed to
the behavior before guards are evaluated on the outgoing edges.
The output of the behavior is available to each guard.
Decision input behavior is specified by the
keyword decisionInput and some decision behavior or
condition placed in a note symbol, and attached to the appropriate
decision node.
Decision node with decision input behavior.

Decision may also have decision input flow. In this case the
tokens offered on the decision input flow that are made available to
the guard on each outgoing edge determine whether the offer on the
regular incoming edge is passed along that outgoing edge.
A decision input flow is specified by the
keyword decisionInputFlow annotating that flow.
Decision node with decision input flow.
Merge
Merge node is a control node that brings together multiple
incoming alternate flows to accept single outgoing flow. There is
no joining of tokens. Merge should not be used to
synchronize concurrent flows.
The notation for a merge node is a diamond-shaped symbol with two
or more edges entering it and a single activity edge leaving it.
Merge node with three incoming edges and a single outgoing edge.
Merge and decision combined

The functionality of merge node and decision node can be
combined by using the same node symbol.
Merge node and decision node combined.
Fork
Fork node with a single activity edge entering it, and three edges
leaving it.
Fork node is a control node that has one incoming edge and
multiple outgoing edges and is used to split incoming flow into
multiple concurrent flows.
The notation for a fork node is a line segment with a single activity
edge entering it, and two or more edges leaving it.
Join Node
Join node with three activity edges entering it, and a single edge
leaving it.
Join node is a control node that has multiple incoming edges and
one outgoing edge and is used to synchronize incoming concurrent
flows.
The notation for a join node is a line segment with several activity
edges entering it, and only one edge leaving it.
Join specifications are shown in curly braces near the join node
as joinSpec=....
Join node with join specification shown in curly braces.
Page 37 of 41
Join and fork combined

The functionality of join node and fork node can be combined by
using the same node symbol.
Combined join node and fork node.
Activity Edge
Activity edge could be control edge or data flow
edge (aka object flow edge). Both are notated by an open
arrowhead line connecting activity nodes.
Activity edge connects Fill Order and Review Order.
Activity edge can be named, however, edges are not required to
have unique names within an activity. If the edge has a name, it is
notated near the arrow.
Activity edge "updated" connects Update Order and Review Order.
The guard of the activity edge is shown in square brackets that
contain the guard. The guard must evaluate to true for every token
that is offered to pass along the edge.
Fill Order when priority is 1
An activity edge can be notated using a connector, which is a small
circle with a name (also called label) in it. Connectors are generally
used to avoid drawing a long edge. This is purely notational. Every
connector with a given label must be paired with exactly one other
with the same label on the same activity diagram. The circles and
lines involved map to a single activity edge in the model.
Connector A connects two edges between Fill Order and Review Order.
Object Flow Edge

Object flow edges are activity edges used to show data flow
between action nodes. Object flow edges have no specific notation.
Data flow of Orders between Fill Order and Review Order actions
The weight of the edge may be shown in curly braces that contain
the weight. The weight is a value specification, which may be a
constant, that evaluates to a non-zero unlimited natural value.
An unlimited weight is notated as "*".
Send Notification when number of Warnings reaches 6
Interrupting Edge
Interrupting edge is activity edge expressing interruption for
regions having interruptions. It is rendered as a lightning-bolt.
Cancel Request signal causes interruption resulting in Cancel Order.
Page 38 of 41
An option for notating an Interrupting edge is a zig zag

adornment on a straight line.
Cancel Request signal causes interruption resulting in Cancel Order.
Object Nodes
Activity object nodes include parameter, pin, central buffer, expansion nodes.
Pin
A pin is an object node for inputs and outputs to actions.
Pin is usually shown as a small rectangle attached to the action
rectangle. The name of the pin can be displayed near the pin.
Item is input pin to the Add to Shopping Cart action.
Invoice is output pin from the Create Invoice action.
Data Store
A data store is a central buffer node for non-transient
information.
The data store is notated as an object node with the keyword
datastore.
Incoming Patient token is stored by the Patients data store.
Page 39 of 41
Communication Diagrams Reference

Notation
Description
Frame
Communication diagrams could be shown within a
rectangular frame with the name in a compartment in the upper
left corner.
There is no specific long form name for communication diagrams
heading types. The long form nameinteraction (used
for interaction diagrams in general) could be used.
Interaction frame for communication diagram BuyItem.

There is also no specific short form name for Communication
Diagrams. Short form name sd (which is used for interaction
diagrams in general) could be used. This sd is bit confusing as it
looks like abbreviation ofsequence diagram.
Sd Frame for Communication Diagram BuyItem.
Lifeline
A lifeline is shown as a rectangle (corresponding to head in
sequence diagrams). Lifeline in sequence diagrams does have "tail"
representing the line of life whereas "lifeline" in communication
diagram has no line, just "head".
Lifeline with name "data" of class Stock.
Anonymous Lifeline
Anonymous lifeline has no name - arbitrary representative of class.
Anonymous lifeline of class User.
Lifeline with Selector

Selector could be used to specify some lifeline from collection.
Lifeline "x" of class X is selected with selector [k].
Sequential Messages
The sequence expression is a dot separated list of sequence
terms followed by a colon (":"). Message name follows the sequence
expression.
sequence-expression ::= sequence-term '.' . . . ':' messagename
sequence-term ::= [ integer [ name ] ] [ recurrence ]
The integer represents the sequential order of the message
within the next higher level of procedural calling (activation).
Instance of A sends draw() message to instance of B, and after that B

sends paint() to instance of C.
Page 40 of 41
Concurrent Messages
The name in sequence expression represents a concurrent
thread of control. Messages that differ in the final name are
concurrent at that level of nesting.
Instance of A sends draw() messages concurrently to instance of B and

to instance of C.
Conditional Messages
A guard specifies condition for the message to be sent (executed) at
the given nesting depth. UML does not specify guard syntax, so it
could be expressed in pseudocode, some programming language, or
something else.
sequence-term ::= [ integer [ name ] ] '[' guard ']'
Instance of class A will send message draw() to the instance of C, if x >
y.
Sequential Loop
Instance of class A will send search() message to instance of B n times,

one by one.
An iteration specifies a sequence of messages at the given nesting

depth. UML does not specify iteration-clause syntax, so it could
be expressed in pseudocode, some programming language, or
something else. Iteration clause may be omitted, in which case the
iteration conditions are unspecified.
sequence-term ::= [ integer [ name ] ] '*' [ '[' iteration-clause ']' ]
Concurrent Loop
Instance of class A will send n concurrent search() messages to

instance of B.
An iteration specifies a sequence of messages at the given nesting

depth. UML does not specify iteration-clause syntax, so it could
be expressed in pseudocode, some programming language, or
something else. Iteration clause may be omitted, in which case the
iteration conditions are unspecified.
The *|| (star followed by a double vertical line) iteration notation
specifies concurrent (parallel) execution of messages.
sequence-term ::= [ integer [ name ] ] '*||' [ '[' iteration-clause ']' ]
Page 41 of 41

UML Diagrams References

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

UML Diagrams References

Uploaded by

Copyright:

Available Formats

UML Diagrams References

Copied-Pasted by Dip Thanh Nguyn, 2014

Classification of UML 2.5 Diagrams

UML 2.5 Diagrams Overview.

Copied-Pasted by Dip Thanh Nguyn, 2014

UML 2.5 Structure Diagrams

Instance level class diagram which shows instance specifications of

Shows packages and relationships between the packages.

UML auxiliary structure diagram which shows some abstraction or

Diagram could be used to show:

Shows internal structure of a classifier - a decomposition of the

Shows components and dependencies between them. This type of

While component diagrams show components and relationships

Shows architecture of the system as deployment (distribution) of

Copied-Pasted by Dip Thanh Nguyn, 2014

Specification level deployment diagram (also called type level)

Deployment diagrams could be used to show logical or

node, switch, router, load

Auxiliary UML diagram which allows to define custom stereotypes,

UML 2.5 Behavior Diagrams

Describes a set of actions (use cases) that some system or systems

Shows exchange of information between system entities at some high

Shows sequence and conditions for coordinating lower-level behaviors,

activity, partition, action,o

Used for modeling discrete behavior through finite state transitions. In

Shows discrete behavior of a part of designed system through finite

Shows usage protocol or a lifecycle of some classifier, e.g. which

protocol state, protocol

Interaction diagrams include several different types of diagrams:

Copied-Pasted by Dip Thanh Nguyn, 2014

Focuses on the interaction between lifelines where the architecture of

Shows interactions when a primary purpose of the diagram is to reason

lifeline, state or condition

Defines interactions through a variant of activity diagrams in a way

initial node, flow final

Copied-Pasted by Dip Thanh Nguyn, 2014

Class Diagrams Reference

A class is a classifier which describes a set of objects that share the

Class SearchService - analysis level details

Class SearchService - implementation level details. The

Class SearchService - attributes and operations grouped by

Math is utility class - having static attributes and operations

Copied-Pasted by Dip Thanh Nguyn, 2014

Class SearchRequest is abstract class.

Template class Array and bound class Customers. The Customers

Copied-Pasted by Dip Thanh Nguyn, 2014

The usage dependency from a classifier to an interface is shown by

Instance checkAcct of the Account interface.

Instance front-facing-cam of the Camera class from

Instance orderPaid of the Date class

Instance newPatient of the Patient class

Structured data type Address

Copied-Pasted by Dip Thanh Nguyn, 2014

Attributes of the Patient class are of data types Name, Gender,

Primitive data type Weight.

A primitive type is a data type which represents atomic data values,

Feature overview diagram

Given a company and a social security number (SSN) at most one

A qualifier is a property which defines a partition of the set of

Copied-Pasted by Dip Thanh Nguyn, 2014

UML 2.4 specification is gibberish explaining multiplicity of qualifier:

Operation executeQuery is public, isPoolable - protected,

Operation is a behavioral feature of a classifier that specifies the

Signature of the operation has optional parameter list and return