OOAD 6 SEM CSE ANNAUNIVERSITY NOTES

UNIT 3 - Sequence Diagram

UML sequence diagrams are used to represent or model the flow of messages, events and actions
between the objects or components of a system. Time is represented in the vertical direction
showing the sequence of interactions of the header elements, which are displayed horizontally at
the top of the diagram.
Sequence Diagrams are used primarily to design, document and validate the architecture,
interfaces and logic of the system by describing the sequence of actions that need to be
performed to complete a task or scenario. UML sequence diagrams are useful design tools
because they provide a dynamic view of the system behavior which can be difficult to extract
from static diagrams or specifications.
Although UML sequence diagrams are typically used to describe object-oriented software
systems, they are also extremely useful as system engineering tools to design system
architectures, in business process engineering as process flow diagrams, as message sequence
charts and call flows for telecom/wireless system design, and for protocol stack design and
analysis.
Sequence Diagram Drawing Ele ments
This tutorial describes the basic drawing elements used in sequence diagrams and when they are
used. These are the diagram elements that are supported by the Sequence Diagram Editor tool.
Some are not part of the UML specification and may not be supported by other UML tools.
Sequence Diagram Header Ele ments
The header portion of the sequence diagram represents the components or objects of the system
being modeled and are laid out horizontally at the top of the diagram. See an example sequence
diagram here.
Actor Represents an external person or entity that interacts
with the system
Object Represents an object in the system or one of its
components

Unit Represents a subsystem, component, unit, or other

logical entity in the system (may or may not be
implemented by objects)
Separator Represents an interface or boundary between
subsystems, components or units (e.g., air interface,
Internet, network)
Group Groups related header elements into subsystems or
components

Sequence Diagram Body Ele ments

Action Represents an action taken by an actor, object or
unit
Asynchronous An asynchronous message between header
Message elements

Powered by www.technoscriptz.com Page 1

OOAD 6 SEM CSE ANNAUNIVERSITY NOTES

Block A block representing a loop or conditional for a

particular header element

Call Message A call (procedure) message between header

elements
Create Message A "create" message that creates a header element
(represented by lifeline going from dashed to
solid pattern)
Destroy Ele ment Represents the destruction of a header element

Destroy Message Represents the destruction of a header element as

a result of a call from another element
Diagram Link Represents a portion of a diagram being treated as
a functional block. Similar to a procedure or
function call that abstracts functionality or details
not shown at this level. Can optionally be linked
to another diagram for elaboration.
Else Block Represents an "else" block portion of a diagram
block

Flow Note Documentation note that is automatically

formatted to flow after previous elements
Free Note Documentation note that is free-flowing and can
be placed anywhere in the diagram (can also be
anchored relative to a flow element)
Message A simple message between header elements

Page Break A page break in the diagram

Return Message A return message between header elements

Scenario Start Start of a scenario (set of alternatives)

Scenario Case Start of an alternative or case in a scenario

Scenario End End of a scenario
State A state change for a header element

Steady State A steady state in the system

Time r Start Start of a timer for a particular header element

Powered by www.technoscriptz.com Page 2

OOAD 6 SEM CSE ANNAUNIVERSITY NOTES

Time r Stop Stop of a timer for a particular header element

Time r Expiration of a timer for a particular header

Expiration element
What can be modeled using sequence diagrams?
Sequence diagrams are particularly useful for modeling:
Complex interactions between components. Sequence diagrams are often used to
design the interactions between components of a system that need to work together to
accomplish a task. They are particularly useful when the components are being developed
in parallel by different teams (typical in wireless and telephony systems) because they
support the design of robust interfaces that cover multiple scenarios and special cases.
Use case elaboration. Usage scenarios describe a way the system may be used by its
actors. The UML sequence diagram can be used to flesh out the details of one or more
use cases by illustrating visually how the system will behave in a particular scenario. The
use cases along with their corresponding sequence diagrams describe the expected
behavior of the system and form a strong foundation for the development of system
architectures with robust interfaces.
Distributed & web-based systems. When a system consists of distributed components
(such as a client communicating with one or more servers over the Internet), sequence
diagrams can be used to document and validate the architecture, interfaces and logic of
each of these components for a set of usage scenarios.
Complex logic. UML sequence diagrams are often used to model the logic of a complex
feature by showing the interactions between the various objects that collaborate to
implement each scenario. Modeling multiple scenarios showing different aspects of the
feature helps developers take into account special cases during implementation.
State machines. Telecom, wireless and embedded systems make extensive use of state
machine based designs where one or more state machines communicate with each other
and with external entities to perform their work. For example, each task in the protocol
stack of a cellular phone goes through a series of states to perform actions such as setup
a call or register with a new base station. Similarly the call processing components of a
Mobile Switching Center use state machines to control the registration and transfer of
calls to roaming subscribers. Sequence diagrams (or call flows as they are commonly
referred to in the telecom and wireless industry) are useful for these types of applications
because they can visually depict the messages being exchanged between the components
and their associated state transitions.
Benefits of using UML sequence diagrams
These are some of the main benefits of using UML sequence diagrams.
1. Help you discover architectural, inte rface and logic proble ms early. Because they allow
you to flesh out details before having to implement anything, sequence diagrams are useful tools
to find architectural, interface and logic problems early on in the design process. You can
validate your architecture, interfaces, state machine and logic by seeing how the system
architecture would handle different basic scenarios and special cases.
This is particularly true for systems involving the interaction of components that are being
implemented in parallel by different teams. In the cell phone example, each task would typically
be implemented by a separate team. Having a set of sequence diagrams describing how the

Powered by www.technoscriptz.com Page 3

OOAD 6 SEM CSE ANNAUNIVERSITY NOTES

interfaces are actually used and what messages/actions are expected at different times gives each
team a consistent and robust implementation plan. You can also document how special cases
should be handled across the entire system.
The very act of creating the sequence diagrams and making them work with your architecture is
valuable because it forces you to think about details such as interfaces, states, message order,
assignment of responsibilities, timers/timeouts and special/error cases ahead of time.
2. Collaboration tool. Sequence diagrams are valuable collaboration tools during design
meetings because they allow you to discuss the design in concrete terms. You can see the
interactions between entities, various proposed state transitions and alternate courses/special
cases on paper as you discuss the design.
In our experience, having a concrete design proposal during design meetings greatly enhances
the productivity of these meetings even if the proposed design has problems. You can narrow
down the problems and then make corrections to solve them. The proposal serves as a concrete
starting point for the discussion and as a place to capture proposed changes.
Sequence diagram editor makes it so easy to edit your sequence diagrams that you could even
make the corrections in real time during the meeting and instantly see the result of the changes as
you make them.
3. Documentation. Sequence diagrams can be used to document the dynamic view of the system
design at various levels of abstraction, which is often difficult to extract from static diagrams or
even the complete source code. The diagrams can abstract much of the implementation detail and
provide a high level view of system behavior.
Below is a sequence diagram for making a hotel reservation. The object initiating the sequence
of messages is a Reservation window.

Powered by www.technoscriptz.com Page 4

OOAD 6 SEM CSE ANNAUNIVERSITY NOTES

The Reservation window sends a makeReservation() message to a HotelChain. The

HotelChain then sends a makeReservation() message to a Hotel. If the Hotel has available
rooms, then it makes a Reservation and a Confirmation.
Each vertical dotted line is a lifeline, representing the time that an object exists. Each arrow is a
message call. An arrow goes from the sender to the top of the activation bar of the message on
the receiver's lifeline. The activation bar represents the duration of execution of the message.
In our diagram, the Hotel issues a self call to determine if a room is available. If so, then the
Hotel creates a Reservation and a Confirmation. The asterisk on the self call means ite ration
(to make sure there is available room for each day of the stay in the hotel). The expression in
square brackets, [ ], is a condition.

The diagram has a clarifying note, which is text inside a dog-eared rectangle. Notes can be put
into any kind of UML diagram.

Powered by www.technoscriptz.com Page 5

OOAD 6 SEM CSE ANNAUNIVERSITY NOTES

Powered by www.technoscriptz.com Page 6

OOAD 6 SEM CSE ANNAUNIVERSITY NOTES

Logical Architecture

A package diagram is a UML diagram composed only of packages and the dependencies
between them. A package is a UML construct that enables you to organize model elements, such
as use cases or classes, into groups. Packages are depicted as file fo lders and can be applied on
any UML diagram. Create a package diagram to:
Depict a high- level overview of your requirements (overviewing a collection of UML
Use Case diagrams)
Depict a high- level overview of your architecture/design (overviewing a collection of
UML Class diagrams).
To logically modularize a complex diagram.
To organize Java source code.
There are guidelines for:
1. Class Package Diagrams
2. Use Case Package Diagrams
3. Packages

1. Class Package Diagrams

A class package diagram.

Powered by www.technoscriptz.com Page 7

OOAD 6 SEM CSE ANNAUNIVERSITY NOTES

1. Create UML Component Diagrams to Physically Organize Your Design.

2. Place Subpackages Below Parent Packages.
3. Vertically Layer Class Package Diagrams.
4. Create Class Package Diagrams to Logically Organize Your Design. Error! Reference
source not found.depicts a UML Class diagram organized into packages. In addition to
the package guidelines presented below, apply the following heuristics to organize UML
Class diagrams into package diagrams:
Place the classes of a framework in the same package.
Classes in the same inheritance hierarchy typically belong in the same package.
Classes related to one another via aggregation or composition often belong in the same
package.
Classes that collaborate with each other a lot, information that is reflected by your UML
Sequence diagrams and UML Collaboration diagrams, often belong in the same package.

2. Use Case Package Diagrams

Use cases are often a primary requirement artifact in object-oriented development
methodologies, this is particularly true of instantiations of the Unified Process, and for larger
projects package diagrams are often created to organize these usage requirements.

A UML Use Case diagram comprised mostly of packages.

Powered by www.technoscriptz.com Page 8
OOAD 6 SEM CSE ANNAUNIVERSITY NOTES

1. Create Use Case Package Diagrams to Organize Your Requirements

2. Include Actors on Use Case Package Diagrams
3. Horizontally Arrange Use Case Package Diagrams

3. Packages
The advice presented in this section is applicable to the application of packages on any UML
diagram, not just package diagrams.
1. Give Packages Simple, Descriptive Names
2. Apply Packages to Simplify Diagrams
3. Packages Should be Cohesive
4. Indicate Architectural Layers With Stereotypes on Packages
5. Avoid Cyclic Dependencies Between Packages
6. Package Dependencies Should Reflect Internal Relationships

Logical Architecture Refinement:

Powered by www.technoscriptz.com Page 9

OOAD 6 SEM CSE ANNAUNIVERSITY NOTES

UML Class diagrams:

Class diagrams are widely used to describe the types of objects in a system and their
relationships. Class diagrams model class structure and contents using design elements such as
classes, packages and objects. Class diagrams describe three different perspectives when
designing a system, conceptual, specification, and implementation. 1 These perspectives become
evident as the diagram is created and help solidify the design. This example is only meant as an
introduction to the UML and class diagrams. If you would like to learn more see the Resources
page for more detailed resources on UML.
Classes are composed of three things: a name, attributes, and operations. Below is an example of
a class.

Powered by www.technoscriptz.com Page 10

OOAD 6 SEM CSE ANNAUNIVERSITY NOTES

Class diagrams also display relationships such as containment, inheritance, associations and
others.2 Below is an example of an associative relationship:

The association relationship is the most common relationship in a class diagram. The association
shows the relationship between instances of classes. For example, the class Order is associated
with the class Customer. The multiplicity of the association denotes the number of objects that
can participate in then relationship.1 For example, an Order object can be associated to only one
customer, but a customer can be associated to many orders.
Another common relationship in class diagrams is a generalization. A generalization is used
when two classes are similar, but have some differences. Look at the generalization below:

In this example the classes Corporate Customer and Personal Customer have some similarities
such as name and address, but each class has some of its own attributes and operations. The

Powered by www.technoscriptz.com Page 11

OOAD 6 SEM CSE ANNAUNIVERSITY NOTES

class Customer is a general form of both the Corporate Customer and Personal Customer
classes.1 This allows the designers to just use the Customer class for modules and do not require
in-depth representation of each type of customer.
When to Use: Class Diagrams
Class diagrams are used in nearly all Object Oriented software designs. Use them to describe the
Classes of the system and their relationships to each other.
How to Draw: Class Diagrams
Class diagrams are some of the most difficult UML diagrams to draw. To draw detailed and
useful diagrams a person would have to study UML and Object Oriented principles for a long
time. Therefore, this page will give a very high level overview of the process. To find list of
where to find more information see the Resources page.
Before drawing a class diagram consider the three different perspectives of the syste m the
diagram will present; conceptual, specification, and implementation. Try not to focus on one
perspective and try see how they all work together.
When designing classes consider what attributes and operations it will have. Then try to
determine how instances of the classes will interact with each other. These are the very first steps
of many in developing a class diagram. However, using just these basic techniques one can
develop a complete view of the software system.

UML Interaction Diagram:

Overvie w:
From the name Interaction it is clear that the diagram is used to describe some type of
interactions among the different elements in the model. So this interaction is a part of dynamic
behaviour of the system.

Powered by www.technoscriptz.com Page 12

OOAD 6 SEM CSE ANNAUNIVERSITY NOTES

This interactive behaviour is represented in UML by two diagrams known as Sequence diagram
and Collaboration diagram. The basic purposes of both the diagrams are similar.
Sequence diagram emphasizes on time sequence of messages and collaboration diagram
emphasizes on the structural organization of the objects that send and receive messages.
Purpose:
The purposes of interaction diagrams are to visualize the interactive behaviour of the system.
Now visualizing interaction is a difficult task. So the solution is to use different types of models
to capture the different aspects of the interaction.
That is why sequence and collaboration diagrams are used to capture dynamic nature but from a
different angle.
So the purposes of interaction diagram can be describes as:
To capture dynamic behaviour of a system.
To describe the message flow in the system.
To describe structural organization of the objects.
To describe interaction among objects.
How to draw Component Diagram?
As we have already discussed that the purpose of interaction diagrams are to capture the dynamic
aspect of a system. So to capture the dynamic aspect we need to understand what a dynamic
aspect is and how it is visualized. Dynamic aspect can be defined as the snap shot of the running
system at a particular moment.
We have two types of interaction diagrams in UML. One is sequence diagram and the other is a
collaboration diagram. The sequence diagram captures the time sequence of message flow from
one object to another and the collaboration diagram describes the organization of objects in a
system taking part in the message flow.
So the following things are to identified clearly before drawing the interaction diagram:
Objects taking part in the interaction.
Message flows among the objects.
The sequence in which the messages are flowing.
Object organization.
Following are two interaction diagrams modeling order management system. The first diagram is
a sequence diagram and the second is a collaboration diagram.
The Sequence Diagram:
The sequence diagram is having four objects (Customer, Order, SpecialOrder and NormalOrder).
The following diagram has shown the message sequence for SpecialOrder object and the same
can be used in case of NormalOrder object. Now it is important to understand the time sequence
of message flows. The message flow is nothing but a method call of an object.
The first call is sendOrder () which is a method of Order object. The next call is confirm ()
which is a method of SpecialOrder object and the last call is Dispatch () which is a method of
SpecialOrder object. So here the diagram is mainly describing the method calls from one object
to another and this is also the actual scenario when the system is running.

Powered by www.technoscriptz.com Page 13

OOAD 6 SEM CSE ANNAUNIVERSITY NOTES

The Collaboration Diagram:

The second interaction diagram is collaboration diagram. It shows the object organization as
shown below. Here in collaboration diagram the method call sequence is indicated by some
numbering technique as shown below. The number indicates how the methods are called one
after another. We have taken the same order management system to describe the collaboration
diagram.
The method calls are similar to that of a sequence diagram. But the difference is that the
sequence diagram does not describe the object organization where as the collaboration diagram
shows the object organization.
Now to choose between these two diagrams the main emphasis is given on the type of
requirement. If the time sequence is important then sequence diagram is used and if organization
is required then collaboration diagram is used.

Where to use Interaction Diagrams?

We have already discussed that interaction diagrams are used to describe dynamic nature of a
system. Now we will look into the practical scenarios where these diagrams are used. To
understand the practical application we need to understand the basic nature of sequence and
collaboration diagram.
Powered by www.technoscriptz.com Page 14
OOAD 6 SEM CSE ANNAUNIVERSITY NOTES

The main purposes of both the diagrams are similar as they are used to capture the dynamic
behaviour of a system. But the specific purposes are more important to clarify and understood.
Sequence diagrams are used to capture the order of messages flowing from one object to another.
And the collaboration diagrams are used to describe the structural organizations of the objects
taking part in the interaction. A single diagram is not sufficient to describe the dynamic aspect of
an entire system so a set of diagrams are used to capture is as a whole.
The interaction diagrams are used when we want to understand the message flow and the
structural organization. Now message flow means the sequence of control flow from one object
to another and structural organization means the visual organization of the elements in a system.
In a brief the following are the usages of interaction diagrams:
To model flow of control by time sequence.
To model flow of control by structural organizations.
For forward engineering.
For reverse engineering.

Powered by www.technoscriptz.com Page 15