D

Unified Modeling
Language (UML)
Unified Modeling Language (UML) is a language used to model different types of applications, such as Web
applications and enterprise applications. Modeling refers to the process of creating and using business logic to
link the components of the application (for example, the pages of a Web application). UML helps to explore
potential designs as well as validate the architectural design of the applications. In other words, by using UML,
you can visualize, construct, and document the components of applications. UML is the most-used specification
of Object Management Group (OMG).
UML uses graphical notations to express the design and development processes of applications. These graphical
notations represent complex and sophisticated applications. You can use the extensible and specialized
mechanisms specified by UML to understand the structure of Web applications more clearly. Higher-level
software development features, such as collaborations, frameworks, patterns, and components are supported by
UML.
This appendix begins by exploring the new and enhanced features of UML 2.0. It then briefly describes the
different types of symbols used in UML diagrams before going into a detailed discussion of the various
categories of UML diagrams and their types. At the end of the chapter, you learn about some of the practices to
adopt while working with UML diagrams.
Lets start by discussing the new features and enhancements in UML 2.0.

New Features of UML 2.0

UML 2.0 has several new and enhanced features that have further improved the capabilities of UML. These
features are also a marked improvement from the earlier versions of UML. Some of the new features and
enhancements added to UML 2.0 are briefly described as follows:
Provides enhancements in component diagrams. You can learn about component diagrams under the
heading Structure Diagram of the appendix. Initially, component diagrams were considered detailed design
diagrams, which were particularly used for data and user interface modeling. According to UML 2.0,
components are either represented as simple boxes with a textual stereotype surrounded by <<>>, for
example <<cat>>, or as a bandaged box visual stereotype. Another difference of UML 2.0 from the earlier
versions of UML is in the representation of the required interfaces. In UML 2.0, required interfaces are
represented by using the socket notation, and provided interfaces are represented by the lollipop notation.
In Figure D.1, the Customer component needs the Access Control interface so it is the required
interface for the Customer component. However, the Access Control interface is provided by the
SecurityInfrastructure component and is therefore the provided interface for the SecurityInfrastructure
component. A combination of lollipop and socket notation is known as ball-and-socket notation. You learn

Appendix D

about the socket notation under the Interfaces heading of this appendix. Figure D.1 shows difference in the
representation of the required interface, Access Control, in UML versions before UML 2 and in UML 2:

Figure D.1: Showing the Difference in the Representation of the Access Control Interface

Adds robustness by introducing interaction frames. Interaction frames consist of one or more sections,
which are separated with the help of dashed line. The If/else conditional statement, the switch statement,
and the loop logic are modeled by using interaction frames. An asterisk (*) in a section of the interaction
frame implies iteration. Figure D.2 shows how to model the if/else statement and loop logic in UML 2.0:

Figure D.2: Showing the Implementation of the If/Else Statement and Loop Logic in UML 2.0

144

Unified Modeling Language (UML)

The use of the iteration marker (* with a message) to model a loop is shown in Figure D.2.
Provides a timing diagram to analyze the modifications in an objects state with time.
Provides composite structure diagrams to show the internal structure of a class and its interaction with
other application components.
Now its the time to explore the features of UML.
Lets now discuss the various symbols used in UML.

UML Symbols
Similar to a flowchart diagram, UML uses particular shapes and symbols, which represent different states,
elements, processes, or roles, to represent the design of a Web application. These UML symbols are used to
create diagrams modeling the Web application. Table D.1 briefly describes the important symbols used in UML,
with their descriptions:
Table D.1: Symbols used in UML
Symbol

Description

Note

Specifies a note in a UML

diagram

Use Case Set

Specifies a use case set

N-array association

Specifies an array association

with an entity in a UML diagram

Package Name

Specifies a package name for an

entity in a UML diagram

Active class

Specifies an active class in a UML

diagram

Object name

Specifies an object name of a class

in a UML diagram

Class

Specifies a class in a UML

diagram

Interface

Specifies an interface in a UML

diagram

Socket

Specifies a socket in a UML

diagram

Component

Specifies a component in a UML

diagram

Graphic Representation

145

Appendix D
Table D.1: Symbols used in UML
Symbol

Description

Graphic Representation

Node

Specifies a node in a UML

diagram

Template

Specifies a template in a UML

diagram

Lifeline

Specifies a lifeline in a UML

diagram

Coregion

Specifies coregion in a UML

diagram

Continuation

Specifies continuation of
process in a UML diagram

Message name

Specifies a message name in a

UML diagram

Concurrent substate

Specifies a concurrent substate in

a UML diagram

Interactor

Specifies an interactor in a UML

diagram

Frame

Specifies a frame in a UML

diagram

Initial state

Specifies the initial state of a

process in a UML diagram

Final state

Specifies the final state of a

process in a UML diagram

After getting a brief idea of the various symbols used in UML, lets discuss UML diagrams.

UML Diagrams
UML defines the standard modeling tools for large and complex Web applications by using different types of
diagrams. These diagrams help to represent the problems as well solutions of these Web applications. Table D.2
lists the various types of diagrams based on their categories in UML:

146

Unified Modeling Language (UML)

Table D.2: UML Diagrams and their Categories
Category

Diagram
Class diagrams

Structure diagrams

Component diagrams
Object diagrams
Composite structure diagrams
Deployment diagrams
Package diagrams

Behavior diagram

Activity diagrams
Use case diagrams
State diagrams

Interaction diagrams

Sequence diagrams
Collaboration diagrams
Interaction overview diagrams
Timing diagrams

Lets now discuss the various categories of UML diagrams in detail in the following sections.
You will find the following abbreviated forms used in UML diagrams:
Sequence diagrams (sd)
Collaboration diagrams (cd)
Timing diagrams (td)
Interaction overview diagrams (iod)

Structure Diagrams
A structure diagram shows the static structure of the Web application being modeled. These diagrams help
validate the design of the Web application and ensure proper communication between the individuals and
teams involved in developing the application. Structure diagrams give a complete overview of the software
development life cycle (SDLC) of the application. The different types of structure diagrams are as follows:
Class diagrams
Component diagrams
Object diagrams
Component structure diagrams
Deployment diagrams
Package diagrams

Class Diagrams
A class diagram is the basis on which a Web application is modeled. It is also called a blueprint of the objectoriented system. A class diagram generally depicts the behavior and structure of the classes and methods used in
the Web application. The methods interact with each other through objects, which are the instances of the
classes. In other words, we can say that a class diagram provides a complete description of the type of objects
and their relationship with each other in a Web application. These objects are used in all object-oriented software
systems.

147

Appendix D

We know that a class contains three vital components: a class name, attributes, and operations. A class may also
have four types of visibilities, which are public, private, protected, and package. All four types of visibilities are
represented in a class diagram. The following is a brief description of these visibility types:
Public visibilitySpecifies the type of visibility in which an element is visible to all elements that can
retrieve the content of the namespace that owns the element. This type of visibility is represented by the +
sign.
Protected visibilitySpecifies the type of visibility in which an element is visible to all elements possessing
a generalization relationship with the namespace that owns the element. This type of visibility is
represented by the # sign.
Private visibilitySpecifies the type of visibility in which an element is visible only within the namespace
that owns the element. This type of visibility is represented by the sign.
Package visibilitySpecifies the type of visibility in which an element is allowed to be owned by a
namespace, and is visible to elements that are in the same package as its owning namespace. An element
with package visibility is available to all the elements that are within the similar package where its owning
namespace resides. This type of visibility is represented by the ~ sign.
A class diagram generally represents the components and type of visibility of a class. Figure D.3 shows the
format of a class diagram:

Figure D.3: Showing the Format of a Class Diagram

Lets take an example to understand the format of a class diagram better. For this, we explore a class named
myBankAccount. This class contains the following components:
myBalanceRepresents an attribute of the number type having private visibility
my_nameRepresents an attribute of the String type having private visibility
debitRepresents an operation having public visibility
creditRepresents an operation having public visibility
Figure D.4 shows the BankAccount class diagram:

Figure D.4: Showing the myBankAccount Class Diagram

We use the italic font to indicate an abstract class in a class diagram. For example, italicizing BankAccount in Figure D.4 would
imply that BankAccount is an abstract class.

The class diagram represents the following elements by using UML symbols:
Composition
Inheritance
Association

148

Unified Modeling Language (UML)

Generalization
Dependency
Interfaces
Lets now discuss these elements in detail.

Composition
Composition implies that each instance of a class contains an instance of another class. For example, a school
building is composed of one or more class rooms. Figure D.5 shows the class diagram that demonstrates the
composition relationship between a school building and class rooms:

Figure D.5: Showing a Composition Relationship between a School Building and a Class Room

Inheritance
The properties of a class may be inherited by another class, a concept called inheritance. The inherited class is the
superclass and the class inheriting the properties of a superclass is called the subclass. For example, suppose you
have two classes named SavingAccount and CurrentAccount and these classes inherit the properties of a
superclass named BankAccount. In this case, the BankAccount class represents an entity called bank account,
and the SavingAccount and CurrentAccount classes represent the savings account and current account entities,
respectively. As savings account and current account are types of bank accounts, they inherit the properties of
the bank account.
A triangular arrowhead of an arrow is used to represent inheritance relationship in UML. Figure D.6 is an
example of inheritance:

Figure D.6: Showing an Inheritance Relationship

In Figure D.6, you can see that SavingAccount and CurrentAccount are the subclasses of the BankAccount class.

149

Appendix D

Association
The mutual dependence between two classes is called association. In this case, the objects of one class are
connected to the objects of another class. An association relationship is shown by a solid line between the classes
in the association relationship. For example, Figure D.7 shows an association between the Customer and
BankAccount classes:

Figure D.7: Showing an Association Relationship between Two Classes

Generalization
Generalization depicts the relationship between two classes in the object oriented paradigm, in which one class,
called a subtype, is a specialized form of other class, called as supertype. An object of subtype is also the object of
supertype. Generalization is represented in a class diagram by a triangular shape, which is defined by the lines
connecting the supertype with one or more subtypes.
Figure D.8 illustrates the concept of generalization, in which a general class, Customer, has two specialized
subclasses, CorporateCustomer and PersonalCustomer:

Figure D.8: Showing the Generalization of the Customer Class

Dependency
Sometimes, one class depends on another class in a weak relationship. For example, consider Figure D.9, which
demonstrates a dependency relationship between the Habit class and the AnimalContext class:

150

Unified Modeling Language (UML)

Figure D.9: Showing a Dependency Relationship

In Figure D.9, the Eat function of the Habit class relies on the AnimalContext class. If there is any modification in
the AnimalContext class, the Habit class is also affected. In Figure D.9, a dashed arrow starting from the Habit
class and ending at the AnimalContext class reveals a dependency relationship.

Interfaces
Interfaces contain declared methods, which are methods that are not defined. Implementing an interface allows a
class to define the behavior of the methods that are declared in the interfaces. Following this rule from Java,
special syntactic elements for interfaces have been developed in UML. The primary icon to denote an interface is
the same as that of a class, with the difference that the primary icon for the interface consists of a special
denotation called a stereotype.
Note that the <<type>> stereotype is positioned at the top of a class. The two characters << and >> are called
guillemets (pronounced as Gee-may). If the class name is written beneath the stereotype, it implies that this is a
special class that complies to a rigid specification. The <<type>> stereotype signifies that the class is an
interface, which has no member variable and all of its member functions are pure virtual.
In a UML diagram, an interface is either shown as a rectangle with the <<interface>> keyword in which the
name of the interface is italicized, or as a circle. Note that the circle notation of interface does not depict the
interface operations. Figure D.10 shows various ways to represent an interface:

Figure D.10: Showing Different Ways to Represent an Interface

When you want to represent interfaces within classes, they can be shown as exposed interfaces. An exposed
interface in an interface that contains the declared methods whose implementation is provided by an
implementation class.

151

Appendix D

An exposed interface may be either a provided interface or a required interface. Figure D.11 shows exposed
interfaces:

Figure D.11: Showing Exposed Interfaces

Figure D.11 depicts an exposed interface, which may be a required interface or a provided interface.
In the case of a required interface, a classifier, which is a UML element, may interact with another classifier that
supplies the implementation to all the methods defined by the interface. A provided interface is shown by
drawing a link between an implementation class and the interface.

Component Diagrams
A large application consists of numerous reusable code modules. A component represents a reusable code
module. A component diagram represents components and the relation they have with each other in an
application. Such diagrams help in modeling the object-oriented paradigm of an application, such as a Web
application. Software components include runtime components, executable components, and source code
components.
According to the UML 2.0 specification, a component may be drawn by using three different techniques, as
shown in Figure D.12:

Figure D.12: Showing Different Techniques to Represent Components

It is important to include the component stereotype text (the word component) inside double angle brackets
because a rectangle object without any stereotype classifier is interpreted as a class element in a UML diagram.
To represent a rectangle object in UML as a component object, the component stereotype (icon) is used.

Object Diagrams
An object is an instance of a class. Classes do not execute the business logic directly; instead, the business logic is
executed by the objects. An object diagram represents the relationship between the objects created at runtime.
An object diagram depicts the relationship of specific instances of a class with each other at runtime. The object
diagram contains the same elements as a class diagram; however, unlike the class diagram, in an object diagram
attributes and method parameters are initialized with values. In other words, attributes and methods are just
declared in a class diagram whereas in an object diagram, they are assigned values.
Consequently, object diagrams not only contain classes but also the links showing the relationship between the
classes at runtime. For example, in a banking application, the Bank class may have various attributes, and a

152

Unified Modeling Language (UML)

subclass Customer. In other words, a bank can have many customers. Figure D.13 shows a one-to-many
relationship between the Bank and Customer classes (shown by a dotted arrow):

Figure D.13: Showing a One-to-Many Relationship between the Bank and Customer Classes

When the banking application is executed, the instances of the Bank and Customer classes are created, with
the initialized values of the attributes of these classes. Figure D.14 shows the corresponding object diagram for
this scenario:

Figure D.14: Showing the Objects of the Bank and Customer Classes

In Figure D.14, each rectangle in the object diagram represents an instance of the corresponding class. As shown
in Figure D.14, AmericanBank is an instance of the Bank class, while Sam and Joseph are instances of the
Customer class. To separate an instantiated objects name from the class name, the : character is used. If the
object diagram clearly explains the class structure, then the names of the classes or its instances may be omitted.

Composite Structure Diagrams

A composite structure diagram depicts the internal structure of a class and its interaction with the other
components or parts of a Web application. It shows how these parts are configured and related to each other.
The behavior of the containing class depends on these parts. In other words, a composite structure diagram
displays classes as composite elements containing interfaces and ports. Figure D.15 depicts a composite structure
diagram:

Figure D.15: Showing a Composite Structure Diagram

153

Appendix D

The composite structure diagram represents the following elements by using UML symbols:
Part
Port
Interfaces
Delegate
Collaborations
Lets learn about these elements in the following sections. Interfaces have already been discussed earlier in the
appendix.

Part
A part represents one or more instances of a component owned by a container. Figure D.16 shows a part in a
composite structure diagram:

Figure D.16: Showing a Part in a Composite Structure Diagram

Port
Ports show the interaction between a classifier and its environment. A port is shown as a rectangle on the
boundary of a class or a composite structure in a UML diagram. Figure D.17 shows a port in a composite
structure diagram:

Figure D.17: Showing a Port in a Composite Structure Diagram

Delegate
The working of a components external ports and interfaces is demonstrated by a delegate connector. An arrow
with a <<delegate>> stereotype comprises a delegate connector. Figure D.18 shows a delegate connector of an
internal class:

154

Unified Modeling Language (UML)

Figure D.18: Showing a Delegate Connector

In Figure D.18, you can see a delegate connector that connects a class with a provided interface.

Collaborations
Collaboration depicts a set of roles and attributes used collectively to illustrate the association among various
components in a Web application. A pattern is often implemented by collaboration. Figure D.19 shows an
example of collaboration in UML, which is represented by an ellipse:

Figure D.19: Showing a Collaboration

Figure D.19 shows a collaboration between television components, screen, and TV remote, which are the
elements that make up a television system.

Deployment Diagrams
A deployment diagram depicts the deployment of the hardware and software components of a Web application
in the system environment. It shows how these components behave and communicate with each other at
runtime. Consider an example of a banking transaction system, which contains three components: bank ATM,
bank server, and database. The bank ATM is used as a device for transactions and the bank server is the

155

Appendix D

execution environment for the transaction performed with the bank ATM. All the transactions made to the bank
server are updated in a database. The results of the transactions are stored in the database. Figure D.20 shows
the deployment diagram for the banking transaction system:

Figure D.20: Showing the Deployment Diagram of a Bank Transaction System

Package Diagrams
Packages are collections of entities such as classes, use cases, activities, processes, and states grouped together.
For example, complex class diagrams containing many classes can be simplified by grouping the classes into
packages. A package diagram shows the breakdown of larger systems into logical groups of smaller systems.
A rectangle with small tabs at the top represents a package. The name of the package can be specified on the tab
or inside the rectangle. A package may depend on other packages that specify different types of relationships
with the packages. Such dependencies are shown by dotted arrows. Figure D.21 shows an example of a package
diagram:

Figure D.21: Showing a Package Diagram

Figure D.21 shows a package diagram that depicts the relationship between a school database, a student
database, and a teacher database.
Figure D.22 shows a way to reference a class in a different package by using a pathname for the class:
Banking:: CheckingAccount

Figure D.22: Referencing a Class in a Different Package

156

Unified Modeling Language (UML)

Lets now discuss the different types of diagrams in the behavior diagram category of UML diagrams.

Behavior Diagram
The workflow of business activities and functions within an application is shown in a behavior diagram.
Behavior diagrams in UML can be categorized as follows:
Activity diagrams
Use case diagrams
State diagrams
Lets now discuss these categories of behavior diagrams in detail in the following sections.

Activity Diagrams
An activity diagram displays a sequence of activities describing the workflow of a business process. It depicts
the behavior of a system and the way in which these behaviors are related in an overall flow of the system.
The following elements describe an activity diagram:
ActivityDescribes a logical unit of work
ActionRepresents the smallest unit of work
Control flowDepicts how the control flows from one action to the next
Initial nodeRepresents the start of the control flow within an activity
Final nodeRepresents the end of the control flow within an activity
Decision and Merge nodesDepict control flow statements starting from a decision node. In the decision
node, the guard conditions act on the statements. A guard condition is a condition that determines the flow
of control.
Fork and Join nodesDepict the start and end of a control flow in an activity diagram
An activity diagram has a starting point and one or more endpoints. Figure D.23 shows an example of an activity
diagram:

Figure D.23: Showing an Activity Diagram

Figure D.23 depicts the workflow of a sales order system. In the figure, you can see that on receiving a sales
order, the system either rejects or accepts the order, based on the decision made in the decision node A.
Lets now explore various elements of an activity diagram in detail.

157

Appendix D

Activity
Activity is a sequence of a behavior in a workflow. An activity is represented with a round-cornered rectangle
with an activity name on the top. Activity diagrams enclose the actions, control flows, and other elements that
comprise the activity. Figure D.24 shows an activity:

Figure D.24: Showing an Activity

Figure D.24 shows an activity, which is represented with the help of a round-cornered rectangle.

Action
A single step in an activity represents an action. Actions are depicted by round-cornered rectangles. Figure D.25
shows an action:

Figure D.25: Showing an Action

A Perform Action action is shown in Figure D.25.

Control Flow
Control flow depicts the flow of control from one action to the next in an activity and is represented by an arrow
that starts from one activity and ends at another activity. Figure D.26 shows the control flow from the Send
Payment action to the Accept Payment action:

158

Unified Modeling Language (UML)

Figure D.26: Showing Control Flow Diagram

Initial Node
An initial or start node, which represents the start of some action, is represented by a large dot. Figure D.27
shows an initial node:

Figure D.27: Showing the Initial Node

In Figure D.27, you can see the initial node that depicts the initialization of the Perform Action action.

Final Node
There are two types of final nodes:
Activity final nodeDenotes the end of a single control flow within an activity
Flow final nodeDepicts all control flow terminations in an activity
The activity final node is represented by a circle with a dark dot inside. Figure D.28 shows an activity final node:

Figure D.28: Showing an Activity Final Node

The flow final node is represented by a circle with a cross inside. Figure D.29 shows a flow final node:

159

Appendix D

Figure D.29: Showing a Flow Final Node

Decision and Merge Nodes

Decision and merge nodes are represented by a diamond shape. Control flow statements start from a decision
node where guard conditions act on these statements to determine the flow of control. Figure D.30 shows how to
use the decision and merge nodes:

Figure D.30: Showing the Use of Decision and Merge Nodes

Based on the decision taken in Decision Node (Figure D.30), the control either flows to the Action on True action
or to the Action on False action.

Fork and Join Nodes

A horizontal or vertical bar represents fork and join nodes. Fork and join nodes split the control flow into
concurrent control flows and merge the concurrent control flows into one. These nodes indicate the start and end
of a control flow in an activity diagram. Figure D.31 shows the use of the fork and join nodes to depict the start
and end of an activity:

Figure D.31: Showing Fork and Join Nodes

160

Unified Modeling Language (UML)

In Figure D.31, the first fork and join node splits the control into two actions, Concurrent Action 1 and
Concurrent Action 2, while the second fork and join node merges the control from the two actions into one.

Use Case Diagrams

A use case diagram describes the interactions between users and Web applications. It identifies the requirements
of a Web application and the mechanism in which the external entities interact with the application. A use case
diagram consists of the following elements:
Actors
Use cases

Actors
Actors are external entities that communicate with the Web application. Users, hardware, or other similar
entities represent actors in a Web application. Users are represented as a named stick figure or a rectangle with
the <<actor>> keyword. Figure D.32 shows different ways of representing an actor:

Figure D.32: Showing Ways to Represent Actors

Actors can have different properties and behaviors, which can result in their generalization. Figure D.33 shows
an example of the generalization of an actor:

Figure D.33: Showing Generalization between Two Actors

Figure D.33 shows an arrow that depicts the generalization from a commercial customer to a customer.

Use Cases
A use case is a single unit of functionality of a Web application and is represented by an ellipse. A line signifies
the connection between an actor and a use case, with an optional arrowhead demonstrating the direction of the
flow control. Figure D.34 shows a use case:

161

Appendix D

Figure D.34: Showing a Use Case

Figure D.34 shows the Customer actor using the Withdraw use case.

State Diagrams
A sequence of events occurs during the lifetime an object. A state diagram models the behavior of an object in
response to these events performed on the object. A round-cornered rectangle with the states name written
within it signifies a state. Figure D.35 shows a state diagram:

Figure D.35: Showing a State Diagram

A state diagram consists of the following elements:

Initial and final states
Transitions
Trigger (guard) effect

Initial and Final States

The initial state, which depicts the state of an object when it is created, is denoted by a filled black circle, labeled
with a name. The final state s denoted by a circle with a dot inside and labeled with a name. No transition can
lead out of a final state. Figure D.36 shows the initial state and final states of an object:

Figure D.36: Showing the Initial and Final States

Figure D.36 shows the initial and final states of an Alive object.

Transitions
A state has a source and a target. The transition from the source to the target is denoted by a line with an
arrowhead. A transition may consist of a trigger, a guard, and an effect. Figure D.37 shows a transaction between
a source state and a final state:

162

Unified Modeling Language (UML)

Figure D.37: Showing the Transition between States

Figure D.37 depicts the transition from the Source State to the Target State; this transition must satisfy the Guard
condition.

Trigger (Guard) Effect

A transition is caused when an action, such as a signal, an event, an alteration in some condition, or the passage
of time occurs. This action is called a trigger. A trigger is executed only when a specified condition is met. This
condition is called a guard. A transition results due to the action invoked on an object that triggers the event.
This action is called an effect. Figure D.38 shows a trigger (guard) effect:

Figure D.38: Showing the Trigger (Guard) Effect in a Bank Transaction Diagram

In the bank transaction diagram shown in Figure D.38, a user is asked to enter the PIN in order to process a
transaction. In case the PIN is valid, the user is allowed to proceed with the transaction; otherwise, the user is
asked to renter the PIN.
Lets now discuss the interaction diagram category of UML diagrams and its types.

Interaction Diagrams
Interaction diagrams are used to model the communication among users, screens, and object instances. They
show the way groups of objects interact to complete a particular task. In other words, interaction diagrams
demonstrate the collaboration of objects for a particular behavior. Interaction diagrams can be categorized as
follows:
Sequence diagrams
Collaboration diagrams
Interaction overview diagrams
Timing diagrams

163

Appendix D

Lets now discuss these categories of interaction diagram.

Sequence Diagrams
A sequence diagram shows the way objects interact in a particular scenario of a use case. It shows interactions in
the form of messages by using the lifeline symbols of UML. A lifeline is depicted by a symbol that consist of a
head, which usually depends on the classifier the lifeline represents, followed by a line, usually dashed, which
represents the lifeline of the classifier. An arrow starting from the source lifeline and terminating at the target
lifeline depicts a message. In other words, sequence diagrams model the communication of objects with each
other through messages. A sequence diagram consists of two dimensions:
The vertical dimensionDenotes the sequence in which messages or calls are transmitted in the sequence
they occur
The horizontal dimensionDenotes the object instances to which messages are sent
Figure D.39 shows a sequence diagram:

Figure D.39: Showing a Sequence Diagram

Figure D.39 shows a sequence diagram in which a class instance or objects are represented inside a box. If a class
instance delivers a message to another class instance, a line is drawn pointing to the recipient class instance. The
name of the message/method is labeled above the line. The messages returned are shown by a dotted line
having an arrowhead, which points back to the class instance from where the message started. Figure D.40
shows the flow of messages in a sequence diagram:

Figure D.40: Showing the Flow of Messages in a Sequence Diagram

164

Unified Modeling Language (UML)

A sequence diagram is composed of the following elements:

Self message
Lost and found messages
Lifeline start and end

Self Message
A method may call another method belonging to the same object. Such recursive calls of methods are
represented by self messages. In a sequence diagram, a self message is shown by creating a nested flow of
control. Figure D.41 illustrates a self message:

Figure D.41: Showing a Self Message

In Figure D.41, a recursive call is made to a method belonging to the same object.

Lost and Found Messages

Messages sent but not received by the targeted recipient, or messages delivered to a recipient not shown on a
diagram are termed as lost messages. Found messages are the messages that start from an unknown sender and
reach the target recipient. Figure D.42 shows lost and found messages:
sd Lost and Found

: Lifeline

lost_message

found_message

Figure D.42: Showing Lost and Found Messages

Figure D.42 shows the lost message that starts from the sender and does not reach the target recipient. It also
shows the found message that starts from an unknown sender and reaches the target recipient.

165

Appendix D

Lifeline Start and End

Timescale in a sequence diagram determines the creation or destruction of a lifeline. A lifeline represents an
object or the roles in a sequence of activities. Figure D.43 shows the structure of a lifeline, where an object is
being created and destroyed:
sd Start and End

Parent

new

Child

delete

x
Figure D.43: Showing the Lifeline Start and End UML Symbols

In the Figure D.43, an object of the parent class is created, which is depicted by a lifeline. When new method of
the child class is invoked, which is depicted by an arrow that starts from the parent class lifeline and ends at the
child class lifeline, a new object of the child class is created. Similarly when the delete method of the child class is
invoked, the newly created child object is deleted and is the end of the child lifeline, represented by the X at the
end of the child lifeline.

Collaboration Diagrams
Collaboration diagrams, also called communication diagrams in UML 2.0, are used to model the behavior of
objects in a use case diagram. The exchange of messages and connection (context) between objects is depicted by
a collaboration diagram. Similar to sequence diagrams, collaboration diagram show the association between
objects. You use a sequence diagram when you need to show the time or sequence of events. A collaboration
diagram should be used when the context has to be shown.
In a collaboration diagram, message arrow symbols are drawn to show the flow of messages between objects
and are placed on the messages that show the order in which the messages are sent. Figure D.44 shows the
sequence of flow of messages by a numbering scheme:
: Order

3: setStatus()

1: press()

: FillForm

: ProcessOrderControl

4: updateQuantity

: Product

2: fillOrder()
5: changeStatus()

: OrderDetail

Figure D.44: Showing a Collaboration Diagram of a Customer Filling an Order Form

166

Unified Modeling Language (UML)

Interaction Overview Diagrams

An interaction overview diagram is a form of activity diagram that shows a workflow as a sequence of steps. It
focuses on the flow of control of the interactions. Two types of frames are shown in an interaction overview
diagram:
Interaction frames
Interaction occurrences frames

Interaction Frames
Interaction frames are used to display UML Interaction diagrams. These frames signify four types of interaction
diagrams. The following are the notations used in interaction frames to depict the four types of interaction
diagrams:
sdSignifies sequence diagrams
cdSignifies collaboration diagrams
tdSignifies timing diagrams
iodSignifies interaction overview diagrams
Sometimes the name of a diagram may also be used to denote its type. Figure D.45 shows an interaction frame in
an interaction overview diagram:
sd Interaction Overview

ad Activity Diagram

Action

Figure D.45: Showing an Interaction Overview Diagram

Figure D.45 shows the sd notation in an interaction overview diagram.

Interaction Occurrence Frames

Interaction occurrences frames indicate an activity or operation to invoke. An interaction occurrence is shown as
a frame with ref in the top-left corner of the UML diagram. The name of the diagram being referenced is shown
in the center of the frame. Figure D.46 shows an interaction occurrence frame:
sd Interaction Overview

ref

Activity Diagram

Figure D.46: Showing an Interaction Occurrences Frame

Figure D.46 shows the ref reference in an interaction overview diagram. The activity diagram being referenced is
also shown in the center by using a round-cornered rectangle.

167

Appendix D

Figure D.47 shows a complete interaction overview diagram, which represents the workflow of a sales process:
sd Sale

Request Item

ref
Search for Item

Item not found

Item found
ref
Checkout

ref

No
Cancel Sale

Sale Finalized?
Yes

ref
Create Record

Figure D.47: Showing an Interaction Overview Diagram

In the sales process shown in Figure D.47, the sales order is finalized and executed if the requested item is found;
otherwise, the sale is cancelled.

Timing Diagram
Alteration in the state or behavior of elements with time is displayed by timing diagrams. These diagrams can
also show the interaction between objects and the duration constraints governing these objects, by using X-Y
coordinates. These coordinates represent the time spent in a process and the objects used in the process. A timing
diagram represents the following elements:
The state lifeline
The value lifeline

State Lifeline
A state lifeline shows the change of state of an object over time, and is represented through the X-Y coordinates.
The X-axis shows the time elapsed in the selected units, while the Y-axis shows the objects and their states.
Figure D.48 shows a state lifeline timing diagram:

168

Unified Modeling Language (UML)

TimeLine1

td State Lifeline

{Duration Constraint}

State 1
State 2

{Time Constraint}

State 3

Event

State 4
0

10

20

30

50

40

70

60

80

90 100

Figure D.48: Showing the State Lifeline Timing Diagram

Figure D.48 shows the timeline and duration constraints for different states of an object in an event.

Value Lifeline
The changes that occur in an objects value with respect to time is depicted by a value lifeline. The value lifeline
is also represented through the X-Y coordinates, where the X-axis shows the time elapsed and the Y-axis shows
the objects and their states. The value is shown between a pair of horizontal lines that crosses over at each
change in the value. Figure D.49 shows a value lifeline timing diagram:
td Value Lifeline

TimeLine2

{Duration Constraint}
2.5

0
{Time Constraint}

10

20

30

10

80

90 100

Event

40

50

60

70

Figure D.49: Showing the Value Lifeline Timing Diagram

In Figure D.49, you can see the variation in the value of an object with time.
After discussing the different types of UML diagrams, lets discuss some of the practices that you should adopt
while working with UML diagrams.

UML Best Practices

UML is used to design object-oriented software applications. A model provides solutions to the problems faced
in the software development process. The following are a few important guidelines that you must follow for
UML diagrams:
Diagrams make a complex application easier to understand. Therefore, they should completely represent
the problems and solutions of the application being modeled.
The presentation of the diagrams should be as simple as possible.
An application should be properly analyzed for requirements and enhancements before drawing its UML
diagram.

169

Appendix D

Each UML diagram is a software application that should permit its developers and users to analyze every
aspect of the application in varying degrees of abstraction.
To make a UML diagram simple and understandable, avoid:
Bubbles
Diagonal lines
Crossed lines
Curved lines
Cluttered or complex diagrams
With this we come to the end of this appendix.

170