Static versus dynamic diagrams

Static diagrams describe the state of a system—like a snapshot of a system in motion. Dynamic
diagrams describe the system in motion. The figure below illustrates the organizational hierarchy
of UML diagrams. Notice that the dynamic diagrams have an organizational hierarchy that is
slightly different from static diagrams. The dynamic diagram type interaction does not represent
an actual diagram. Instead, it defines a subset of diagrams.

Types of dynamic diagrams

Dynamic UML diagrams describe the behavior of systems. A dynamic diagram describes the
operations, actions, and changes that occur in a system over time. A static diagram, on the other
hand, describes the characteristics of a system or part of a system.

UML specifies different types of dynamic diagrams:

• Activity
• Use case
• State machine
• Sequence
• Communication
• Interaction overview
• Timing
• Collaboration

The dynamic model is used to express and model the behaviour of the system over time. It
includes support for activity diagrams, state diagrams, sequence diagrams.
Sequence Diagrams
Sequence diagrams are used to display the interaction between users, screens, objects and entities
within the system. It provides a sequential map of message passing between objects over time.
Frequently these diagrams are placed under Use Cases in the model to illustrate the use case
scenario - how a user will interact with the system and what happens internally to get the work
done. Often, the objects are represented using special stereotyped icons, as in the example below.
The object labelled Login Screen is shown using the User Interface icon. The object labelled
Security Manager is shown using the Controller icon. The Object labelled users is shown using
the Entity icon.

Activity Diagrams
Activity diagrams are used to show how different workflows in the system are constructed, how
they start and the possibly many decision paths that can be taken from start to finish. They may
also illustrate the where parallel processing may occur in the execution of some activities.

Activity

An activity diagram describes the flow of actions in a system or subsystem. Also, an activity
diagram can describe simultaneous activities, decision points, and subsequent behavior based on
the decision's result. Activity diagrams are perfect for describing how a system operates on a
step-by-step, condition-by-condition basis.
Use case

A use case diagram describes, as its name implies, how an actor or artifact uses a system. A use
case diagram can also describe how one action or component uses another. A use case diagram is
very good for describing various behaviors in a system and who or what controls that behavior.

Use case example

The use case diagram in Figure 3 describes an instructional video system. The instructional video
system is the example scenario used throughout this article series.

The diagram illustrates two actors:

• Learner: A human
• Authentication server: A component

All cases in the system are displayed within a rectangle that describes the boundaries of the
system. Actors use the system. Thus, they are placed outside the rectangle, illustrating the system
boundary. The same is true of the

Authentication Server.

Use case diagrams have a symbol that describes a separate action required by a particular action.
This is the line that has the text <<include>>. In the use case below, the Login action needs to
use the Verify Login Credentials to execute its intended task.

Also, use case diagrams have a symbol that describes how an action can enhance the behavior of
another action. The line symbol describes this with the text <<extend>>. In the use case below,
displaying an error page extends the behavior of Login. While showing an informative error page
is a wise choice in application design, it's not essential to the Login action. One might use
another action. Hence, it's deemed an extended behavior.

The Play Training Video has two associated actions: Play from Beginning and Resume Play. In
UML terminology, Play Training Video is an abstract use; hence, its name is in italics. It needs
concrete behavior to be operational. Play from Beginning and Resume Play are the concrete
implementations of that abstraction. It's a subtle point, but readers sophisticated in object-
oriented programming details might find the distinction appropriate.
State machine

A state machine diagram describes the characteristics of a system as it changes in response to an

event. As a system changes, it moves from one state to another.

An example of a UML state machine diagram. The diagram describes the various states of a
Video Viewer system, showing four states: Ready, In Progress, Pause, and Finish. State change
is instigated by an event that's described as a line with an arrowhead pointing to the state that is
the event's target.

UML specifies that a state can have a set of internal actions that set system characteristics and
internal behavior accordingly. These internal actions are entry, do, and exit. Some
implementations of the UML state diagram use these internal actions; some do not. Or, some will
describe the entry and exit actions and omit the do action. Given the variety of implementations,
deciding whether to use entry, do, and exit actions seems to be a matter of style. The state
diagram in Figure 5 describes the entry, do, and exit actions for each state.

Regardless of whether the entry, do, and exit actions are illustrated, the most important thing
about a state diagram is that it describes the various states a system can be in.
Sequence

A UML sequence diagram describes the flow of tasks between particular actors or components
and their lifelines.
Communication

The UML communication diagram describes how messages get exchanged between components
in a system. A communication diagram also describes how one component is associated with
another component. Messages are described using lines with arrowheads. An association
between two components is described using a line without any arrowheads.

An example of a communication diagram that describes the messages sent to the components
that make up the InstructionalVideo scenario.

An interesting aspect of the communication diagram is the numbering convention that groups
together messages sent among components. The format used in the numbering convention is
#.#.n, where the period character is a delimiter that indicates a message is in a subordinate group
to another.

Notice in Figure 9 that messages are numbered as follows:

• 1 login(username, pwd)
• 1.1 validate(username=username, pwd=pwd)
• 1.2 validate(username=username, pwd=pwd)

Message 1 is sent by the User to the user interface (UI) component, most likely a browser. The
UI sends message 1.1 to the Application, and message 1.2 is sent by the Application to the
Authentication component. The important thing to notice is that all of the 1.X messages relate to
validation and behavior after validation. Thus they are labeled according to the extended
numbering convention.

Since the select Video(videoID) message never goes beyond the UI component, its number label
is 2 only. Yet, since the messages related to playing a video propagate from the User to the UI
and onto the VideoStreamer component, those messages are labeled using the extended
numbering convention, for instance 3 and 3.1.
Interaction overview

An interaction overview diagram describes the interaction between components in a system. An

interaction overview diagram describes two types of interaction frames. One interaction frame
indicates that the frame contains the details of an interaction. This type of interaction frame has
the label sd as a prefix to the component's name in the upper-left corner.

The other interaction frame indicates that the frame references an interaction with its details
described elsewhere. You name this type of interaction frame with the label ref in the upper-left
corner.

An interaction diagram supports describing decision points.

An example of an interaction overview diagram that describes interactions that are part of the
Instructional Video scenario. Notice that there are five points of interaction: Login, Display sign
up page, Get video catalogue, Select video, and View video. There is also one decision point,
Login OK?

The interaction for Login is defined with an sd prefix. Thus, it provides a good amount of details
about the Login process. The other interactions are defined with the ref label. These interaction
frames describe what the interaction does, but not how it does it. Those details are defined in
other diagrams.
Timing

A timing diagram describes how events in a process execute over time. A timing diagram is
similar to a sequence diagram, but it describes the time for events to execute in and among
components. You can describe timespans absolutely or relatively.

Timing diagrams help describe the actual or expected amount of time it takes for activities to
execute within and among processes. A timing diagram can help identify bottlenecks when
analyzing performance behavior, even at a conceptual level.

An example of a timing diagram for the high-level video viewing process that is part of the
Instructional Video system used throughout this article.

Notice that the diagram describes the process of viewing a catalog of videos, selecting a video to
view, and then viewing the video. The overall process is executed by a Web User and three
artifacts:

• Browser
• Web Server
• Media Server

The actor and the artifacts are each enclosed in their own swimlane.

The actor and the artifacts are each enclosed in their own swimlane.

At the bottom of the diagram are a series of vertical lines distributed equally along an x-axis.
These ticks on the x-axis represent the units of time against which you will measure activity.
Some timing diagrams use actual units of time, such as seconds, minutes, or hours. Others, such
as the diagram below, segment time according to a general, undefined unit.

The left side of a swimlane lists the activities executed by an actor or artifact, in ascending order,
from bottom to top. The right side of the swimlane shows each activity unfolding over time. A
horizontal line describes the length of time it takes for an activity to execute on the left side of
the swimlane.

The horizontal lines in the Web User and Browser swimlanes appear as parts of a step pattern.
The horizontal lines in the Web Server and Media Server swimlanes are part of an up and down
pattern. The Web User and Browser swimlanes describe a continuous activity, hence the
ascending step pattern. The activities in the Web Server and Media Server swimlanes are
episodic. The episodic patterns start, execute for some time, and then stop, hence the up and
down pattern.

Notice that each horizontal timespan line is assigned a label that describes the length of the
timespan. Also, notice that vertical lines have arrowheads that point from the timeline in one
swimlane to another timeline in another swimlane. A vertical line with an arrowhead describes a
correlation of one swimlane's timeline to another. For example, notice that the vertical line with
the arrowhead in the Browser swimlane for the Video playing action, at the timespan label, (t…
t+n) points to the Video streaming timespan in the Media Server swimlane at the same point of
execution. This means both the Browser and the Media Server are active simultaneously.

Timing symbols
Collaboration

The collaboration diagram is used to show the relationship between the objects in a system. Both
the sequence and the collaboration diagrams represent the same information but differently.
Instead of showing the flow of messages, it depicts the architecture of the object residing in the
system as it is based on object-oriented programming. An object consists of several features.
Multiple objects present in the system are connected to each other. The collaboration diagram,
which is also known as a communication diagram, is used to portray the object's architecture in
the system.
• Collaboration is a collection of named objects and actors with links connecting them.
They collaborate in performing some task.
• A Collaboration defines a set of participants and relationships that are meaningful for a
given set of purposes
• A Collaboration between objects working together provides emergent desirable
functionalities in Object-Oriented systems
• Each object (responsibility) partially supports emergent functionalities
• Objects are able to produce (usable) high-level functionalities by working together
• Objects collaborate by communicating (passing messages) with one another in order to
work together

Why Collaboration Diagram?

• Model collaborations between objects or roles that deliver the functionalities of use
cases and operations
• Model mechanisms within the architectural design of the system
• Capture interactions that show the messages passing between objects and roles within
the collaboration
• Model alternative scenarios within use cases or operations that involve the
collaboration of different objects and interactions
• Support the identification of objects (hence classes) that participate in use cases
• Each message in a collaboration diagram has a sequence number.
• The top-level message is numbered 1. Messages sent during the same call have the
same decimal prefix but suffixes of 1, 2, etc. according to when they occur.
Notations of a Collaboration Diagram

Following are the components of a component diagram that are enlisted below:

1. Objects: The representation of an object is done by an object symbol with its name and
class underlined, separated by a colon.
In the collaboration diagram, objects are utilized in the following ways:
o The object is represented by specifying their name and class.
o It is not mandatory for every class to appear.
o A class may constitute more than one object.
o In the collaboration diagram, firstly, the object is created, and then its class is
specified.
o To differentiate one object from another object, it is necessary to name them.
2. Actors: In the collaboration diagram, the actor plays the main role as it invokes the
interaction. Each actor has its respective role and name. In this, one actor initiates the use
case.
3. Links: The link is an instance of association, which associates the objects and actors. It
portrays a relationship between the objects through which the messages are sent. It is
represented by a solid line. The link helps an object to connect with or navigate to
another object, such that the message flows are attached to links.
4. Messages: It is a communication between objects which carries information and includes
a sequence number, so that the activity may take place. It is represented by a labeled
arrow, which is placed near a link. The messages are sent from the sender to the receiver,
and the direction must be navigable in that particular direction. The receiver must
understand the message.
When to use a Collaboration Diagram?

The collaborations are used when it is essential to depict the relationship between the object.
Both the sequence and collaboration diagrams represent the same information, but the way of
portraying it quite different. The collaboration diagrams are best suited for analyzing use cases.

Steps for creating a Collaboration Diagram

1. Determine the behavior for which the realization and implementation are specified.
2. Discover the structural elements that are class roles, objects, and subsystems for
performing the functionality of collaboration.
o Choose the context of an interaction: system, subsystem, use case, and operation.
3. Think through alternative situations that may be involved.
o Implementation of a collaboration diagram at an instance level, if needed.
o A specification level diagram may be made in the instance level sequence
diagram for summarizing alternative situations.
Benefits of a Collaboration Diagram

1. The collaboration diagram is also known as Communication Diagram.

2. It mainly puts emphasis on the structural aspect of an interaction diagram, i.e., how
lifelines are connected.
3. The syntax of a collaboration diagram is similar to the sequence diagram; just the
difference is that the lifeline does not consist of tails.
4. The messages transmitted over sequencing are represented by numbering each individual
message.
5. The collaboration diagram is semantically weak in comparison to the sequence diagram.
6. The special case of a collaboration diagram is the object diagram.
7. It focuses on the elements and not the message flow, like sequence diagrams.
8. Since the collaboration diagrams are not that expensive, the sequence diagram can be
directly converted to the collaboration diagram.
9. There may be a chance of losing some amount of information while implementing a
collaboration diagram with respect to the sequence diagram.

The drawback of a Collaboration Diagram

1. Multiple objects residing in the system can make a complex collaboration diagram, as it
becomes quite hard to explore the objects.
2. It is a time-consuming diagram.
3. After the program terminates, the object is destroyed.
4. As the object state changes momentarily, it becomes difficult to keep an eye on every
single that has occurred inside the object of a system.