UML

The Unified Modeling Language™ (UML®) is a standard visual modeling language

intended to be used for

 modeling business and similar processes,

 analysis, design, and implementation of software-based systems

UML is a common language for business analysts, software architects and developers used to
describe, specify, design, and document existing or new business processes, structure and
behavior of artifacts of software systems.

UML can be applied to diverse application domains (e.g., banking, finance, internet,
aerospace, healthcare, etc.) It can be used with all major object and component software
development methods and for various implementation platforms (e.g., J2EE, .NET).

UML is a standard modeling language, not a software development process. UML 1.4.2
specification explains that process:

 provides guidance as to the order of a team’s activities,

 specifies what artifacts should be developed,
 directs the tasks of individual developers and the team as a whole, and
 offers criteria for monitoring and measuring a project’s products and activities.

UML is intentionally process independent and could be applied in the context of different
processes. Still, it is most suitable for use case driven, iterative and incremental development
processes. An example of such process is Rational Unified Process (RUP).

UML is not complete and it is not completely visual. Given some UML diagram, we can't be
sure to understand depicted part or behavior of the system from the diagram alone. Some
information could be intentionally omitted from the diagram, some information represented
on the diagram could have different interpretations, and some concepts of UML have no
graphical notation at all, so there is no way to depict those on diagrams.

For example, semantics of multiplicity of actors and multiplicity of use cases on use case
diagrams is not defined precisely in the UML specification and could mean either concurrent
or successive usage of use cases.

Name of an abstract classifier is shown in italics while final classifier has no specific
graphical notation, so there is no way to determine whether classifier is final or not from the
diagram.

UML 2.3 Diagrams Overview

A UML diagram is a partial graphical representation (view) of a model of a system under
design, implementation, or already in existence. UML diagram contains graphical elements
(symbols) - UML nodes connected with edges (also known as paths or flows) - that represent
elements in the UML model of the designed system. The UML model of the system might
also contain other documentation such as use cases written as templated texts.

The kind of the diagram is defined by the primary graphical symbols shown on the diagram.
For example, a diagram where the primary symbols in the contents area are classes is class
diagram. A diagram which shows use cases and actors is use case diagram. A sequence
diagram shows sequence of message exchanges between lifelines.

UML specification does not preclude mixing of different kinds of diagrams, e.g. to combine
structural and behavioral elements to show a state machine nested inside a use case.
Consequently, the boundaries between the various kinds of diagrams are not strictly enforced.
At the same time, some UML Tools do restrict set of available graphical elements which
could be used when working on specific type of diagram.

Classification of UML 2.3 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 it's 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.3 diagrams could be categorized hierarchically as shown below:

Structure Diagrams

Structure diagram shows 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.

Class diagram is static structure diagram describing structure of a system on the (lowest)
level of classifiers (classes, interfaces, etc.). It shows system's classifiers, their attributes, and
the relationships between classifiers.

Object diagram shows instances of classifiers and links (instances of associations) between
them.
Package diagram shows packages and dependencies between the packages. Models allow to
show different views of a system, for example, as multi-layered (aka multi-tiered) application
- see an example of multi-layered application model.

Component diagram shows components and dependencies between them. This type of
diagrams is used for Component-Based Development (CBD), to describe systems with
Service-Oriented Architecture (SOA).

Composite structure diagram could be used to show:

 Internal structure of a classifier

 A behavior of a collaboration

Internal Structure diagrams show 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 behavior of the system.

Deployment diagram shows execution architecture of a system that represents the assignment
(deployment) of software artifacts to deployment targets (usually nodes).

Profile diagram is auxiliary UML diagram which allows defining custom stereotypes, tagged
values, and constraints. The Profile mechanism has been defined in UML for providing 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.

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.

Use case diagrams are behavior diagrams used to describe 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.3 specification also defines use case diagrams as specialization of class
diagrams (which are structure diagrams). Use case diagrams could be considered as a special
case of class diagrams where classifiers are restricted to be either actors or use cases and the
most used relationship is association.

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 flow models.
State machine diagram is 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 as behavioral state machines and protocol state machines.

Interaction diagrams include several different types of diagrams:

 sequence diagrams,
 interaction overview diagrams,
 communication diagrams, (known as collaboration diagrams in UML 1.x)
 timing diagrams.

Sequence diagram is the most common kind of interaction diagrams, which focuses on the
message interchange between lifelines (objects).

Communication diagram (previously known as Collaboration Diagram) is a kind of

interaction diagram, which 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.

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.

Timing diagrams are used to show 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.

UML Element Frames

Each UML diagram has a contents area. As an option, some diagrams may also have a frame
(shown as rectangle) with frame heading. The frame could be used in the cases when the
diagrammed element has some owned elements that are attached to the border, like ports for
classes and components, and entry/exit points on state machines.

The heading of a frame represents the kind, name, and parameters of the element owning or
namespace enclosing the elements represented in the contents area. The following UML
elements and namespaces could have frames:

Short Kind Long Kind - Owning Element / Enclosing Namespace

class Class
pkg Package
cmp Component
dep Deployment
uc use case
act Activity
sd Interaction
stm state machine
Note, that it is the common mistake (that I am also guilty of) to assume that frame kind
specifies type of the depicted UML diagram. In fact, type of the diagram is defined by the
primary graphical elements shown in the contents area of the diagram. Frame kind specifies
the kind of UML element owning or namespace enclosing the elements in the frame contents
area.

For example, we may have class diagram of a package or composite structure diagram for a
class.

Class diagram of a package org.hibernate.jdbc frame

Use case could own activities or state machines. Example below shows activity owned by use
case.

Activity (diagram) enclosed in Search Items use case frame

Use Case Diagrams

Use case diagrams are behavior diagrams used to describe 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). Each use case should provide some observable and
valuable result to the actors or other stakeholders of the system.

Note, that UML 2.3 specification also describes use case diagrams as a specialization of
class diagrams, and class diagrams are structure diagrams.

Use case diagrams are in fact twofold - they are both behavior diagrams (because they
describe behavior of the system), and they are also structure diagrams - as a special case of
class diagrams where classifiers are restricted to be either actors or use cases related with
association.

Use case diagrams are used to specify:

 (external) requirements on a subject, required usages of a system - to capture what a

system under construction is supposed to do;
 the functionality offered by a subject – what system can do;
 requirements the specified subject poses on its environment - by defining how environment
should interact with the subject so that it will be able to perform its services.

You can find some examples of use case diagrams here:

 Business model - Airport check-in and security screening

 Business model - Restaurant
 Point of Sales Terminal
 Use cases for a retail website
 ATM use cases
 e-Library online public access catalog use cases

Read some FAQs - questions and answers related to use cases here - Use Case Diagrams
FAQ.

Subject

The subject (of use cases) is the system under analysis or design to which a set of use cases
apply. The subject could be a business or company, software system, physical system or
device, or a smaller subsystem having some behavior.

In UML terms, subject is a use case classifier playing the "subject" role. Use case classifier
is classifier extended with the capability to own use cases.

The required behavior of the subject is specified by one or more use cases, which in turn are
defined according to the needs of actors.

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.
Subject Retail Website with applicable use cases and Web Customer actor

Business Model Subject

Use cases could be used to model business to analyse business processes, recognize the
problems being experienced, determine the opportunities to better serve customers.

Subject of use cases in this case is business, enterprise, company or its division, department,
team.

Examples of business subjects:

 Department Store
 Airport
 Restaurant

UML provides no standard stereotypes to model business processes but we can use custom
stereotypes like «business» or «department», if needed for clarity.

Example below shows «business» Restaurant with business actors Customer, Advertiser and
Supplier and related business use cases.
Restaurant business subject with business actors and applicable use cases

Example below shows typical misconception for the «business» Restaurant with business
actors mistakenly including Waiter and Cashier. These are both working for the restaurant,
and are part of the business. They should not be shown as actors as actors are external users
of the system.

Mistake: Restaurant business should not have Waiter and Cashier as actors

Software System Subject

System use cases describe a system that automates some business use case(s) or process.
Subject in this case is software and/or hardware system, subsystem, component or device.

Examples of systems:

 Web Site
 Payment System
 Automated Teller Machine (ATM)
 Point of Sale (POS) Terminal

UML provides no standard stereotypes for subject (i.e. use case classifier) but UML 2.3
specification examples use the stereotypes from components:

 «subsystem»
 «process»
 «service»
 «component»
Weather Service subject stereotyped as «service»

Applicability of Use Cases

Use cases visually located inside the system boundaries are 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

It is possible for some use cases to be applicable to multiple subjects.

Ownership of Use Cases

In UML 2.3 subject could own some or all of applicable use cases. This owning (nesting) of
a use case is represented using the standard notation for nested classifier.

Retail Website subject owns use cases

Actor

An actor is behaviored classifier which specifies a role played by an external entity that
interacts with the subject (e.g., by exchanging signals and data), a human user of the designed
system, some other system or hardware using services of the subject.

The term "role" is used informally as some type, group or particular facet of users that
require specific services from the subject modeled with associated use cases. When an
external entity interacts with the subject, it plays the role of a specific actor. That single
physical entity may play several different roles, and a specific role may be played by single
or multiple different instances.

Since an actor is external to the subject, it is typically defined in the same classifier or
package that incorporates the subject.

All actors must have names according to the assumed role. Examples of actor names (user
roles):

 Customer
 Web Client
 Student
 Passenger
 Payment System

Standard UML notation for actor is "stick man" icon with the name of the actor above or
below of the icon. Actor names should follow the capitalization and punctuation guidelines
for classes. The names of abstract actors should be shown in italics.

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

An actor may also be shown as a class rectangle with the standard keyword «actor», having
usual notation for class compartments, if needed.

Customer actor as Class

An actor can only have binary associations to use cases, components, and classes.

Business 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.

Some typical examples of business actors are:

 Customer
 Supplier
 Patron
 Passenger
 Authority
 Bank

Each business actor represents something outside of the modeled business and should be
involved with at least one business use case.

Business actor is represented in RUP by "stick man" icon with a line crossing its head.

Business actor Passenger

Relationships Between Actors

We can define abstract or concrete actors and specialize them using generalization
relationship.

Generalization between actors is rendered as a solid directed line with a large arrowhead
(same as for generalization between classes).

Web Client actor is abstract superclass for Administrator, Editor and Customer

Associations Between Actors and Use Cases

Each use case specifies a unit of useful functionality that the subject provides to actors. This
functionality should be initiated by an actor. Actors may be connected to use cases only by
binary association relationship.

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

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 non-standard 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.

When an actor has an association to a use case with a multiplicity that is greater than one at
the use case end, it means that a given actor can be involved in multiple use cases of that
type. The specific nature of this multiple involvement depends on the case on hand and is not
defined in the UML 2.3 specification.

Thus, 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.

Actor Bank is involved in multiple Use cases Transfer Funds.

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 which multiple actors participate in the use case depends on the specific
situation on hand and is not defined in the UML 2.3 specification.

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).

Two or more Player Actors are required to initiate Play Game Use case.
Use Case

A use case is behaviored classifier which specifies behavior of a subject (system under
construction or consideration) by describing a set of sequences of actions performed by the
system to yield an observable result of some value to one or more actors or other
stakeholders of the system. In other words, each use case describes a unit of complete and
useful functionality that the subject provides to its users.

This functionality, which is initiated by an actor, must always be completed for the use
case to complete. It is considered complete if after its execution the subject will be in a state
in which no further inputs or actions are expected and the use case can be either initiated
again or is in an error state.

Each use case must have a name. Examples of use case names:

 Place Order
 Update Subscription
 Transfer Funds
 Hire Employee

Use case is usually shown as an ellipse containing the name of the use case.

User Registration use case

Name of the use case could also be placed below the ellipse.

Transfer Funds use case

If a subject (or system boundary) is displayed, the use case ellipse is visually located inside
the system boundary rectangle. Note, that this does not necessarily mean that the subject
classifier owns the contained use cases, but merely that the use case applies to that classifier.

Use cases have no standard keywords or stereotypes. Use case could be shown with a custom
stereotype above the name. As a classifier, use case has properties. A list of use case
properties - operations and attributes - could be shown in a compartment within the use case
oval below the use case name.
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 right-hand corner of the rectangle and with optional separate list
compartments for its features.

Registration Use Case shown using the standard rectangle notation for classifiers

The detailed behavior of a use case can be described by any means and techniques intended
to define behaviors, in a separate diagram or textual document such as

 interactions,
 activities,
 state machines,
 pre- and post-conditions
 natural language text

It may also be described indirectly through a Collaboration that uses the use case and its
actors as the classifiers that type its parts. Which of these techniques to use depends on the
nature of the use case behavior as well as on the intended reader. These descriptions can be
combined.
An execution of a use case is an occurrence of emergent behavior. Every instance of a
classifier realizing a use case must behave in the manner described by the use case.

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 Activity diagram

Business Use Case

Though support for business modeling is declared as a goal of UML, UML specification
provides no notion for business use cases.

Business use cases were introduced in Rational Unified Process (RUP) to support Business
Modeling to represent business function, process, or activity performed in the modeled
business. Business use case should produce a result of observable value to a business actor.

A business use case defines what happens in the business when the use case is requested by
business actor, it describes complete workflow or business process that produces results
required or in need of business actor.

Business use case is represented in RUP with use case oval and a line crossing it as shown
below.

Business use case Individual Check-In

There are two alternative approaches to name business use cases. Use case could be named
from the point of view of business actor - expressing goal or need of the actor - or from the
point of view of business itself - by giving names to business processes or services provided
to business actors.

Business use case - Candidate Applies for Job

The Apply for Job business use case expresses the goal of the Candidate business actor.
Alternative name from business view would be Hire Staff.

Business use case - Business Serves Meal to Customer

In this case, business use case is named according to the business process or service -
business Serves Meal to Customer. Alternative name from actor view would be Have Meal.

You can see other differences between these two approaches by comparing examples of
business use case diagrams for Restaurant.

Relationships Between Use Cases

Use cases could be organized using following relationships:

 generalization
 association
 extend
 include

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.

Generalization is shown as a solid directed line with a large hollow triangle arrowhead (the
same as for generalization between classes) directed from the more specific use case to the
general use case.
Generalization between use cases

Association Between Use Cases

Use cases can only be involved in binary associations.

Two use cases specifying the same subject cannot be associated since each of them
individually describes a complete usage of the system.

Extend Relationship

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. The extend relationship is owned by the extending use case. The same extending use
case can extend more than one use case, and extending use case may itself be extended.

The extension takes place at one or more extension points defined in the extended use case.

Extend relationship is shown as a dashed line with an open arrowhead directed from the
extending use case to the extended (base) use case. The arrow is labeled with the keyword
«extend».

Registration use case is meaningful on its own.

It could be extended with optional Get Help On Registration use case

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

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 extend relationship.

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 ]

The optional explanation is some description usually given as informal text. It could be in
other forms, such as the name of a state in a state machine, an activity in an activity diagram,
some precondition or postcondition.

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 Relationship

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. Including use case depends on the addition of the included use case.

Including use cases are usually not complete by themselves and require the included use
cases. Included use cases are required, not optional for the inclusion.

The include relationship 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.

Execution of the included use case is analogous to a subroutine call or macro command in
programming. All of the behavior of the included use case is executed at a single location in
the including use case before execution of the including use case is resumed.

Note, while UML 2.3 defines extension points for the extend relationship, there are no
"inclusion points" to specify location or condition of inclusion for the include.

Include relationship between use cases is shown by a dashed arrow with an open arrowhead
from the including (base) use case to the included (common part) use case. The arrow is
labeled with the keyword «include».

When two or more use cases have some common behavior, this common part could be
extracted into a separate use case to be included back by the use cases with include.

Both Deposit Funds and Withdraw Cash use cases

require (include) Customer Authentication use case.

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 (possibly several) Scan Item,
Calclulate Total and Tax, and Payment use cases

Timing Diagrams
Timing diagrams are UML interaction diagrams used to show 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. Timing diagrams describe
behavior of both individual classifiers and interactions of classifiers, focusing attention on
time of events causing changes in the modeled conditions of the lifelines.

The following nodes and edges are typically drawn in a UML timing diagram: lifeline, state
or condition timeline, destruction event, duration constraint, time constraint.

You can find some timing diagram examples here:

 Medical domain - Stages of Alzheimer’s Disease

 User Experience - Website Latency

Lifeline

Lifeline is a named element which represents an individual participant in the interaction.

While parts and structural features may have multiplicity greater than 1, lifelines represent
only one interacting entity. See lifeline from sequence diagrams for details.

Lifeline on the timing diagrams is represented by the name of classifier or the instance it
represents. It could be placed inside diagram frame or a "swimlane".
Lifelines representing instances of System and Virus

State or Condition Timeline

Timing diagram could show states of the participating classifier or attribute, or some testable
conditions, such as a discrete or enumerable value of an attribute.

Timeline shows Virus changing its state between Dormant, Propagation, Triggering and
Execution state

UML also allows the state/condition dimension be continuous. It could be used in scenarios
where entities undergo continuous state changes, such as temperature or density.

Duration Constraint

Duration constraint is an interval constraint that refers to a duration interval. The duration
interval is duration used to determine whether the constraint is satisfied.

The semantics of a duration constraint is inherited from constraints. If constraints are

violated, traces become negative which means that system is considered as failed.

Duration constraint is shown as some graphical association between a duration interval and
the constructs that it constrains.

Ice should melt into water in 1 to 6 minutes

Time Constraint

Time constraint is an interval constraint that refers to a time interval. The time interval is
time expression used to determine whether the constraint is satisfied.

The semantics of a time constraint is inherited from constraints. All traces where the
constraints are violated are negative traces, i.e., if they occur, the system is considered as
failed.

Time constraint is shown as graphical association between a time interval and the construct
that it constrains. Typically this graphical association is a small line, e.g., between an
occurrence specification and a time interval.

Person should wake up between 5:40 am and 6 am

Destruction Event

Destruction event is event 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 by
composition.

The destruction event is depicted by a cross in the form of an X at the end of a timeline.

Virus lifeline is terminated