Sequence Diagram

The sequence diagram represents the flow of messages in the system and is also termed as
an event diagram. It helps in envisioning several dynamic scenarios. It portrays the
communication between any two lifelines as a time-ordered sequence of events, such that
these lifelines took part at the run time. In UML, the lifeline is represented by a vertical bar,
whereas the message flow is represented by a vertical dotted line that extends across the
bottom of the page. It incorporates the iterations as well as branching.
Purpose of a Sequence Diagram
1. To model high-level interaction among active objects within a system.
2. To model interaction among objects inside a collaboration realizing a use case.
3. It either models generic interactions or some certain instances of interaction.

Notations of a Sequence Diagram

Lifeline
An individual participant in the sequence diagram is represented by a lifeline. It is positioned
at the top of the diagram.

Actor
A role played by an entity that interacts with the subject is called as an actor. It is out of the
scope of the system. It represents the role, which involves human users and external
hardware or subjects. An actor may or may not represent a physical entity, but it purely
depicts the role of an entity. Several distinct roles can be played by an actor or vice versa.
Activation
It is represented by a thin rectangle on the lifeline. It describes that time period in which an
operation is performed by an element, such that the top and the bottom of the rectangle is
associated with the initiation and the completion time, each respectively.

Messages

The messages depict the interaction between the objects and are represented by arrows.
They are in the sequential order on the lifeline. The core of the sequence diagram is formed
by messages and lifelines.
Following are types of messages enlisted below:
o Call Message: It defines a particular communication between the lifelines of
an interaction, which represents that the target lifeline has invoked an operation.

o Return Message: It defines a particular communication between the lifelines

of interaction that represent the flow of information from the receiver of the
corresponding caller message.
o Self Message: It describes a communication, particularly between the lifelines
of an interaction that represents a message of the same lifeline, has been invoked.

o Recursive Message: A self message sent for recursive purpose is called

a recursive message. In other words, it can be said that the recursive
message is a special case of the self message as it represents the recursive
calls.

o Create Message: It describes a communication, particularly between the

lifelines of an interaction describing that the target (lifeline) has been
instantiated.
 o Destroy Message: It describes a communication, particularly between the
lifelines of an interaction that depicts a request to destroy the lifecycle of the
target.

o Duration Message: It describes a communication particularly between the

lifelines of an interaction, which portrays the time passage of the message while
modeling a system.

A note is the capability of attaching several remarks to the element. It basically carries useful
information for the modelers.

Sequence Fragments
1. Sequence fragments have been introduced by UML 2.0, which makes it quite
easy for the creation and maintenance of an accurate sequence diagram.
2. It is represented by a box called a combined fragment, encloses a part of
interaction inside a sequence diagram.
 3. The type of fragment is shown by a fragment operator.

Types of fragments
Following are the types of fragments enlisted below:
Example of a Sequence Diagram

An example of a high-level sequence diagram for online bookshop is given below.

Any online customer can search for a book catalog, view a description of a particular book,
add a book to its shopping cart, and do checkout.

Benefits of a Sequence Diagram

1. It explores the real-time application.
2. It depicts the message flow between the different objects.
3. It has easy maintenance.
4. It is easy to generate.
5. Implement both forward and reverse engineering.
6. It can easily update as per the new change in the system.
The drawback of a Sequence Diagram
1. In the case of too many lifelines, the sequence diagram can get more complex.
2. The incorrect result may be produced, if the order of the flow of messages
changes.
3. Since each sequence needs distinct notations for its representation, it may
make the diagram more complex.
 4. The type of sequence is decided by the type of message.

UML Use Case Diagram

A use case diagram is used to represent the dynamic behaviour of a system. It depicts the high-
level functionality of a system and also tells how the user handles a system. It encapsulates the
system's functionality by incorporating use cases, actors, and their relationships. It models the
tasks, services, and functions required by a system/subsystem of an application.
Intuitively, the use cases represent the different ways in which a system can be used by the
users.
Purpose of Use Case Diagrams
The main purpose of a use case diagram is to portray the dynamic aspect of a system. It
accumulates the system's requirement, which includes both internal as well as external
influences. It invokes persons, use cases, and several things that invoke the actors and elements
accountable for the implementation of use case diagrams. It represents how an entity from the
external environment can interact with a part of the system.
Following are the purposes of a use case diagram given below:
1. It gathers the system's needs.
2. It depicts the external view of the system.
3. It recognizes the internal as well as external factors that influence the system.
4. It represents the interaction between the actors
Why Use-Case diagram?
A Use Case consists of use cases, persons, or various things that are invoking the features called
as actors and the elements that are responsible for implementing the use cases. Use case
diagrams capture the dynamic behaviour of a live system. It models how an external entity
interacts with the system to make it work. Use case diagrams are responsible for visualizing
the external things that interact with the part of the system.
When to use a use-case diagram?
A use case is a unique functionality of a system which is accomplished by a user. A purpose of
use case diagram is to capture core functionalities of a system and visualize the interactions of
various things called as actors with the use case. This is the general use of a use case diagram.
The use case diagrams represent the core parts of a system and the workflow between them. In
use case, implementation details are hidden from the external use only the event flow is
represented.
With the help of use case diagrams, we can find out pre and post conditions after the interaction
with the actor. These conditions can be determined using various test cases.
In general use case diagrams are used for:
1. Analyzing the requirements of a system
2. High-level visual software designing
3. Capturing the functionalities of a system
4. Modeling the basic idea behind the system
5. Forward and reverse engineering of a system using various test cases.
Use cases are intended to convey desired functionality so the exact scope of a use case may
vary according to the system and the purpose of creating UML model.
Use-case diagram notations
Following are the common notations used in a use case diagram:
Use-case:
Use cases are used to represent high-level functionalities and how the user will handle the
system. A use case represents a distinct functionality of a system, a component, a package, or
a class. It is denoted by an oval shape with the name of a use case written inside the oval shape.
The notation of a use case in UML is given below:
UML UseCase Notation
Actor:
It is used inside use case diagrams. The actor is an entity that interacts with the system. A user
is the best example of an actor. An actor is an entity that initiates the use case from outside the
scope of a use case. It can be any element that can trigger an interaction with the use case. One
actor can be associated with multiple use cases in the system. The actor notation in UML is
given below.

UML Actor Notation

How to draw a Use Case diagram?

To draw a use case diagram in UML first one need to analyse the entire system carefully. You
have to find out every single function that is provided by the system. After all the functionalities
of a system are found out, then these functionalities are converted into various use cases which
will be used in the use case diagram.
A use case is nothing but a core functionality of any working system. After organizing the use
cases, we have to enlist the various actors or things that are going to interact with the system.
These actors are responsible for invoking the functionality of a system. Actors can be a person
or a thing. It can also be a private entity of a system. These actors must be relevant to the
functionality or a system they are interacting with.
After the actors and use cases are enlisted, then you have to explore the relationship of a
particular actor with the use case or a system. One must identify the total number of ways an
actor could interact with the system. A single actor can interact with multiple use cases at the
same time, or it can interact with numerous use cases simultaneously.
Following rules must be followed while drawing use-case for any system:
1. The name of an actor or a use case must be meaningful and relevant to the
system.
2. Interaction of an actor with the use case must be defined clearly and in an
understandable way.
 3. Annotations must be used wherever they are required.
4. If a use case or an actor has multiple relationships, then only significant
interactions must be displayed.
Following use case diagram represents the working of the student management system:

UML UseCase Diagram

In the above use case diagram, there are two actors named student and a teacher. There are a
total of five use cases that represent the specific functionality of a student management system.
Each actor interacts with a particular use case. A student actor can check attendance, timetable
as well as test marks on the application or a system. This actor can perform only these
interactions with the system even though other use cases are remaining in the system.
It is not necessary that each actor should interact with all the use cases, but it can happen.
The second actor named teacher can interact with all the functionalities or use cases of the
system. This actor can also update the attendance of a student and marks of the student. These
interactions of both student and a teacher actor together sums up the entire student management
application.
Includes
The includes relationship implies one use case includes the behaviour of another use case in its
sequence of events and actions. The includes relationship is appropriate when you have a chunk
of behaviour that is similar across a number of use cases. The factoring of such behaviour will
help in not repeating the specification and implementation across different use cases. Thus, the
includes relationship explores the issue of reuse by factoring out the commonality across use
cases.
the includes relationship is represented using a predefined stereotype <>. In the includes
relationship, a base use case compulsorily and automatically includes the behaviour of the
common use case.
Extends
The main idea behind the extends relationship among use cases is that it allows you show
optional system behaviour. An optional system behaviour is executed only if certain conditions
hold, otherwise the optional behaviour is not executed.

Example of a Use Case Diagram

A use case diagram depicting the Online Shopping website is given below.
Here the Web Customer actor makes use of any online shopping website to purchase online.
The top-level uses are as follows; View Items, Make Purchase, Checkout, Client Register. The
View Items use case is utilized by the customer who searches and view products. The Client
Register use case allows the customer to register itself with the website for availing gift
vouchers, coupons, or getting a private sale invitation. It is to be noted that the Checkout is an
included use case, which is part of Making Purchase, and it is not available by itself.

The View Items is further extended by several use cases such as; Search Items, Browse Items,
View Recommended Items, Add to Shopping Cart, Add to Wish list. All of these extended use
cases provide some functions to customers, which allows them to search for an item. The View
Items is further extended by several use cases such as; Search Items, Browse Items, View
Recommended Items, Add to Shopping Cart, Add to Wish list. All of these extended use cases
provide some functions to customers, which allows them to search for an item.
Both View Recommended Item and Add to Wish List include the Customer Authentication
use case, as they necessitate authenticated customers, and simultaneously item can be added to
the shopping cart without any user authentication.
Similarly, the Checkout use case also includes the following use cases, as shown below. It
requires an authenticated Web Customer, which can be done by login page, user authentication
cookie ("Remember me"), or Single Sign-On (SSO). SSO needs an external identity provider's
participation, while Web site authentication service is utilized in all these use cases.
UML Activity Diagram
In UML, the activity diagram is used to demonstrate the flow of control within the system
rather than the implementation. It models the concurrent and sequential activities.
The activity diagram helps in envisioning the workflow from one activity to another. It put
emphasis on the condition of flow and the order in which it occurs. The flow can be sequential,
branched, or concurrent, and to deal with such kinds of flows, the activity diagram has come
up with a fork, join, etc.
It is also termed as an object-oriented flowchart. It encompasses activities composed of a set
of actions or operations that are applied to model the behavioural diagram.
Components of an Activity Diagram
Following are the component of an activity diagram:
Activities
The categorization of behavior into one or more actions is termed as an activity. In other words,
it can be said that an activity is a network of nodes that are connected by edges. The edges
depict the flow of execution. It may contain action nodes, control nodes, or object nodes.
The control flow of activity is represented by control nodes and object nodes that illustrates the
objects used within an activity. The activities are initiated at the initial node and are terminated
at the final node.

Activity partition /swimlane

The swimlane is used to cluster all the related activities in one column or one row. It can be
either vertical or horizontal. It used to add modularity to the activity diagram. It is not necessary
to incorporate swimlane in the activity diagram. But it is used to add more transparency to the
activity diagram.

Forks
Forks and join nodes generate the concurrent flow inside the activity. A fork node consists of
one inward edge and several outward edges. It is the same as that of various decision
parameters. Whenever a data is received at an inward edge, it gets copied and split crossways
various outward edges. It split a single inward flow into multiple parallel flows.

Join Nodes
Join nodes are the opposite of fork nodes. A Logical AND operation is performed on all of the
inward edges as it synchronizes the flow of input across one single output (outward) edge.
Pins
It is a small rectangle, which is attached to the action rectangle. It clears out all the messy and
complicated thing to manage the execution flow of activities. It is an object node that precisely
represents one input to or output from the action.
Notation of an Activity diagram
Activity diagram constitutes following notations:
Initial State: It depicts the initial stage or beginning of the set of actions.
Final State: It is the stage where all the control flows and object flows end.
Decision Box: It makes sure that the control flow or object flow will follow only one path.
Action Box: It represents the set of actions that are to be performed.

Why use Activity Diagram?

An event is created as an activity diagram encompassing a group of nodes associated with
edges. To model the behavior of activities, they can be attached to any modeling element. It
can model use cases, classes, interfaces, components, and collaborations.
It mainly models processes and workflows. It envisions the dynamic behavior of the system as
well as constructs a runnable system that incorporates forward and reverse engineering. It does
not include the message part, which means message flow is not represented in an activity
diagram.
It is the same as that of a flowchart but not exactly a flowchart itself. It is used to depict the
flow between several activities.
When to use an Activity Diagram?
An activity diagram can be used to portray business processes and workflows. Also, it used for
modeling business as well as the software. An activity diagram is utilized for the followings:
1. To graphically model the workflow in an easier and understandable way.
2. To model the execution flow among several activities.
3. To model comprehensive information of a function or an algorithm employed
within the system.
4. To model the business process and its workflow.
5. To envision the dynamic aspect of a system.
6. To generate the top-level flowcharts for representing the workflow of an
application.
7. To represent a high-level view of a distributed or an object-oriented system.
How to draw an Activity Diagram?
An activity diagram is a flowchart of activities, as it represents the workflow among various
activities. They are identical to the flowcharts, but they themself are not exactly the flowchart.
In other words, it can be said that an activity diagram is an enhancement of the flowchart, which
encompasses several unique skills.
Since it incorporates swimlanes, branching, parallel flows, join nodes, control nodes, and forks,
it supports exception handling. A system must be explored as a whole before drawing an
activity diagram to provide a clearer view of the user. All of the activities are explored after
they are properly analyzed for finding out the constraints applied to the activities. Each and
every activity, condition, and association must be recognized.
After gathering all the essential information, an abstract or a prototype is built, which is then
transformed into the actual diagram.
Following are the rules that are to be followed for drawing an activity diagram:
1. A meaningful name should be given to each and every activity.
2. Identify all of the constraints.
3. Acknowledge the activity associations.
Example of an Activity Diagram
An example of an activity diagram showing the business flow activity of order processing is
given below.
Here the input parameter is the Requested order, and once the order is accepted, all of the
required information is then filled, payment is also accepted, and then the order is shipped. It
permits order shipment before an invoice is sent or payment is completed.
UML State Machine Diagram
The state machine diagram is also called the Statechart or State Transition diagram, which
shows the order of states underwent by an object within the system. It captures the software
system's behavior. It models the behavior of a class, a subsystem, a package, and a complete
system.
It tends out to be an efficient way of modeling the interactions and collaborations in the external
entities and the system. It models event-based systems to handle the state of an object. It also
defines several distinct states of a component within the system. Each object/component has a
specific state.
Following are the types of a state machine diagram that are given below:
Behavioral state machine
The behavioral state machine diagram records the behavior of an object within the system. It
depicts an implementation of a particular entity. It models the behavior of the system.
Protocol state machine
It captures the behavior of the protocol. The protocol state machine depicts the change in the
state of the protocol and parallel changes within the system. But it does not portray the
implementation of a particular component.
Why State Machine Diagram?
Since it records the dynamic view of a system, it portrays the behavior of a software application.
During a lifespan, an object underwent several states, such that the lifespan exist until the
program is executing. Each state depicts some useful information about the object.
It blueprints an interactive system that response back to either the internal events or the external
ones. The execution flow from one state to another is represented by a state machine diagram.
It visualizes an object state from its creation to its termination.
The main purpose is to depict each state of an individual object. It represents an interactive
system and the entities inside the system. It records the dynamic behavior of the system.
Notation of a State Machine Diagram
Following are the notations of a state machine diagram enlisted below:
 a. Initial state: It defines the initial state (beginning) of a system, and it is
represented by a black filled circle.
b. Final state: It represents the final state (end) of a system. It is denoted by a
filled circle present within a circle.
c. Decision box: It is of diamond shape that represents the decisions to be made
on the basis of an evaluated guard.
d. Transition: A change of control from one state to another due to the occurrence
of some event is termed as a transition. It is represented by an arrow labeled with
an event due to which the change has ensued.
e. State box: It depicts the conditions or circumstances of a particular object of a
class at a specific point of time. A rectangle with round corners is used to represent
the state box.
Types of State
The UML consist of three states:
1. Simple state: It does not constitute any substructure.
2. Composite state: It consists of nested states (substates), such that it does not
contain more than one initial state and one final state. It can be nested to any level.
3. Submachine state: The submachine state is semantically identical to the
composite state, but it can be reused.
How to Draw a State Machine Diagram?
The state machine diagram is used to portray various states underwent by an object. The change
in one state to another is due to the occurrence of some event. All of the possible states of a
particular component must be identified before drawing a state machine diagram.
The primary focus of the state machine diagram is to depict the states of a system. These states
are essential while drawing a state transition diagram. The objects, states, and events due to
which the state transition occurs must be acknowledged before the implementation of a state
machine diagram.
Following are the steps that are to be incorporated while drawing a state machine diagram:
1. A unique and understandable name should be assigned to the state transition
that describes the behavior of the system.
2. Out of multiple objects, only the essential objects are implemented.
 3. A proper name should be given to the events and the transitions.
When to use a State Machine Diagram?
The state machine diagram implements the real-world models as well as the object-oriented
systems. It records the dynamic behavior of the system, which is used to differentiate between
the dynamic and static behavior of a system.
It portrays the changes underwent by an object from the start to the end. It basically envisions
how triggering an event can cause a change within the system.
State machine diagram is used for:
1. For modeling the object states of a system.
2. For modeling the reactive system as it consists of reactive objects.
3. For pinpointing the events responsible for state transitions.
4. For implementing forward and reverse engineering.
Example of a State Machine Diagram
An example of a top-level state machine diagram showing Bank Automated Teller Machine
(ATM) is given below.
Initially, the ATM is turned off. After the power supply is turned on, the ATM starts performing
the startup action and enters into the Self Test state. If the test fails, the ATM will enter into
the Out Of Service state, or it will undergo a triggerless transition to the Idle state. This is
the state where the customer waits for the interaction.
Whenever the customer inserts the bank or credit card in the ATM's card reader, the ATM state
changes from Idle to Serving Customer, the entry action readCard is performed after
entering into Serving Customer state. Since the customer can cancel the transaction at any
instant, so the transition from Serving Customer state back to the Idle state could be triggered
by cancel event.
Here the Serving Customer is a composite state with sequential substates that are Customer
Authentication, Selecting Transaction, and Transaction.
Customer Authentication and Transaction are the composite states itself is displayed by a
hidden decomposition indication icon. After the transaction is finished, the Serving Customer
encompasses a triggerless transition back to the Idle state. On leaving the state, it undergoes
the exit action ejectCard that discharges the customer card.
State Machine vs. Flowchart
State Machine Flowchart
It portrays several states of a system. It demonstrates the execution flow of a
program.
It encompasses the concept of WAIT, i.e., It does not constitute the concept of WAIT.
wait for an event or an action.
It is for real-world modeling systems. It envisions the branching sequence of a
system.
It is a modeling diagram. It is a data flow diagram (DFD)
It is concerned with several states of a It focuses on control flow and path.
system.

Processes and Threads model

• A process is a heavyweight flow that can execute concurrently with other
processes.
 • A thread is a lightweight flow that can execute concurrently with other threads
within the same process.
• An active object is an object that owns a process or thread and can initiate
control activity.
• An active class is a class whose instances are active objects.
• Graphically, an active class is rendered as a rectangle with thick lines.
Processes and threads are rendered as stereotyped active classes.

Figure 1: Active Class

Flow of Control
In a sequential system, there is a single flow of control. i.e, one thing, and one thing only, can
take place at a time.
In a concurrent system, there is multiple simultaneous flow of control i.e, more than one thing
can take place at a time.
Classes and Events
• Active classes are just classes which represents an independent flow of control
• Active classes share the same properties as all other classes.
• When an active object is created, the associated flow of control is started; when
the active object is destroyed, the associated flow of control is terminated
• two standard stereotypes that apply to active classes are, <<process>> –
Specifies a heavyweight flow that can execute concurrently with other processes.
(heavyweight means, a thing known to the OS itself and runs in an independent
address space) <<thread>> – Specifies a lightweight flow that can execute
concurrently with other threads within the same process (lightweight means, known
to the OS itself.)
• All the threads that live in the context of a process are peers of one another
Communication
• In a system with both active and passive objects, there are four possible
combinations of interaction
• First, a message may be passed from one passive object to another
• Second, a message may be passed from one active object to another
• In inter-process communication there are two possible styles of communication.
First, one active object might synchronously call an operation of another. Second,
one active object might asynchronously send a signal or call an operation of another
object
• a synchronous message is rendered as a full arrow and an asynchronous message
is rendered as a half arrow
• Figure 2: shows Communication
• Third, a message may be passed from an active object to a passive object
• Fourth, a message may be passed from a passive object to an active one
 Figure 2: Communication
Synchronization
• synchronization means arranging the flow of controls of objects so that mutual
exclusion will be guaranteed.
• in object-oriented systems these objects are treated as a critical region
• Figure 3 Synchronization
• three approaches are there to handle synchronization:
• Sequential – Callers must coordinate outside the object so that only one flow is
in the object at a time
• Guarded – multiple flow of control is sequentialized with the help of object’s
guarded operations. in effect it becomes sequential.
• Concurrent – multiple flow of control is guaranteed by treating each operation
as atomic
• synchronization are rendered in the operations of active classes with the help of
constraints

Figure 3: Synchronization
Process Views
• The process view of a system encompasses the threads and processes that form
the system’s concurrency and synchronization mechanisms.
• This view primarily addresses the performance, scalability, and throughput of
the system.
Modeling Multiple Flows of Control
To model multiple flows of control,
• Identify the opportunities for concurrent action and reify each flow as an active
class. Generalize common sets of active objects into an active class. Be careful not
to overengineer the process view of your system by introducing too much
concurrency.
• Consider a balanced distribution of responsibilities among these active classes,
then examine the other active and passive classes with which each collaborates
statically. Ensure that each active class is both tightly cohesive and loosely coupled
relative to these neighboring classes and that each has the right set of attributes,
operations, and signals.
• Capture these static decisions in class diagrams, explicitly highlighting each
active class.
• Consider how each group of classes collaborates with one another dynamically.
Capture those decisions in interaction diagrams. Explicitly show active objects as
the root of such flows. Identify each related sequence by identifying it with the
name of the active object.
• Pay close attention to communication among active objects. Apply synchronous
and asynchronous messaging, as appropriate.
• Pay close attention to synchronization among these active objects and the
passive objects with which they collaborate. Apply sequential, guarded, or
concurrent operation semantics, as appropriate.
Figure 4 shows part of the process view of a trading system.

Figure 4: Modeling Flows of Control

Modeling Interprocess Communication
To model interprocess communication,
• Model the multiple flows of control.
• Consider which of these active objects represent processes and which represent
threads. Distinguish them using the appropriate stereotype.
• Model messaging using asynchronous communication; model remote procedure
calls using synchronous communication.
• Informally specify the underlying mechanism for communication by using
notes, or more formally by using collaborations.
Figure 5 shows a distributed reservation system with processes spread across four nodes.
 Figure 5: Modeling Interprocess Communication
Events and Signals Model
Introduction
In state machines (sequence of states), we use events to model the occurrence of a stimulus that
can trigger an object to move from one state to another state. Events may include signals, calls,
the passage of time or a change in state.

In UML, each thing that happens is modeled as an event. An event is the specification of a
significant occurrence that has a location in time and space. A signal, passing of time and
change in state are asynchronous events. Calls are generally synchronous events, representing
invocation of an operation.

UML allows us to represent events graphically as shown below. Signals may be represented as
stereotyped classes and other events are represented as messages associated with transitions
which cause an object to move from one state to another.

Types of Events
Events may be external or internal. Events passed between the system and its actors are external
events. For example, in an ATM system, pushing a button or inserting a card are external
events. Internal events are those that are passed among objects living inside the system. For
example, a overflow exception generated by an object is an internal event.
In UML, we can model four kinds of events namely: signals, calls, passing of time and change
in state.
Signals
A signal is a named object that is sent asynchronously by one object and then received by
another. Exceptions are the famous examples for signals. A signal may be sent as the action of
a state in a state machine or as a message in an interaction. The execution of an operation can
also send signals.
In UML, we model the relationship between an operation and the events using a dependency
stereotyped with “send”, which indicates that an operation sends a particular signal.

Call Events
A call event represents the dispatch of an operation from one object to another. A call event
may trigger a state change in a state machine. A call event, in general, is synchronous.
This means that the sender object must wait until it gets an acknowledgment from the
receiver object which receives the call event. For example, consider the states of a customer
in an ATM application:

Time and Change Events

A time event represents the passage of time. In UML, we model the time event using the “after”
keyword followed by an expression that evaluates a period of time.
A change event represents an event that represents a change in state or the satisfaction of some
condition. In UML, change event is modeled using the keyword “when” followed by some
Boolean expression.
Sending and Receiving Events
Any instance of a class can receive a call event or signal. If this is a synchronous call event,
the sender is in locked state with receiver. If this is a signal, then the sender is free to carry its
operations without any concern on the receiver.
In UML, call events are modeled as operations on the class of an object and signals that an
object can receive are stored in an extra component in the class as shown below:

Common Modeling Techniques

Modeling a family of signals

To model a family of signals,

1. Consider all the signals to which a set of objects can respond.
2. Arrange these signals in a hierarchy using generalization-specialization
relationship.
3. Look out for polymorphism in the state machine of the active objects. When
polymorphism is found, adjust the hierarchy by introducing intermediate abstract
signals.
Modeling Exceptions
To model exceptions,
1. For each class and interface and for each operation of such elements,
consider the exceptional conditions that might arise.
2. Arrange these exceptions in a hierarchy.
3. For each operation, specify the exceptions that it may rise.

UML Timing Diagram

In UML, the timing diagrams are a part of Interaction diagrams that do not incorporate similar
notations as that of sequence and collaboration diagram. It consists of a graph or waveform that
depicts the state of a lifeline at a specific point of time. It illustrates how conditions are altered
both inside and between lifelines alongside linear time axis.
The timing diagram describes how an object underwent a change from one form to another. A
waveform portrays the flow among the software programs at several instances of time.
Following are some important key points of a timing diagram:
1. It emphasizes at that particular time when the message has been sent among
objects.
2. It explains the time processing of an object in detail.
3. It is employed with distributed and embedded systems.
4. It also explains how an object undergoes changes in its form throughout its
lifeline.
5. As the lifelines are named on the left side of an edge, the timing diagrams are
read from left to right.
6. It depicts a graphical representation of states of a lifeline per unit time.
7. In UML, the timing diagram has come up with several notations to simplify the
transition state among two lifelines per unit time.
Basic concepts of a Timing Diagram
In UML, the timing diagram constitutes several major elements, which are as follows:
Lifeline
As the name suggests, the lifeline portrays an individual element in the interaction. It represents
a single entity, which is a part of the interaction. It is represented by the classifier's name that
it depicts. A lifeline can be placed within a "swimlane" or a diagram frame.

Lifelines representing instances of a System and Virus

State or Condition Timeline
The timing diagram represents the state of a classifier or attributes that are participating, or
some testable conditions, which is a discrete value of the classifier.
In UML, the state or condition is continuous. It is mainly used to show the temperature and
density where the entities endure a continuous state change.

Timeline showing the change in the state of virus between dormant, Propagation,
Triggering, Execution
Duration Constraint
The duration constraint is a constraint of an interval, which refers to duration interval. It is used to
determine if the constraint is satisfied for a duration or not. The duration constraint semantics inherits
from the constraints.
The negative trace defines the violated constraints, which means the system is failed. A graphical
association between duration interval and the construct, which it constrains, may represent a duration
constraint.
Ice should melt into the water in 1 to 6 mins.
Time Constraint
It is an interval constraint, which refers to the time interval. Since it is a time expression, it
depicts if the constraint is satisfied or not. The constraints dispense its time constraints
semantics.
The negative trace defines the violated constraints, which means the system is failed. The time
constraint is represented by a graphical association between the time interval and the construct
which it constrains.
The graphical association is mainly represented by a small line in between a time interval and
an occurrence specification.

A person should wakeup in between 5:40 am, and 6 am

Destruction Occurrence
The destruction occurrence refers to the occurrence of a message that represents the destruction
of an instance is defined by a lifeline. It may subsequently destruct other objects owned by the
composition of this object, such that nothing occurs after the destruction event on a given
lifeline. It is represented by a cross at the end of a timeline.

Virus lifeline is terminated

Example of a Timing Diagram
A timing diagram example of a medical domain
that depicts different stages of Alzheimer's disease (AD) is explained below.
Since Alzheimer's is a very progressive fatal brain disease, it leads to memory loss and
intellectual abilities. The reason behind this disease is yet to be discovered. It cannot be cured
as well as one of the main reasons for rising death rates in the United States.
The doctor may require a diagnostic framework with three to seven-stage, such that its
evolution may last for about 8 to 10 years. Also, in some cases, it lasts up to 20years from the
time neuron starts changing.
The example given below constitutes timing for a seven-stage framework. The given example
is just a UML diagram
and should not be considered as a reference to medical research. The medical details are provided for
you to better understand the UML diagram.
Following are the seven-stage Alzheimer disease framework explained below:
• No Impairment, Normal State
It is the stage where the memory and cognitive abilities look normal.
• Normal Aged Forgetfulness
It is mostly seen in people with an age group of 65 who experience subjective
complaints of cognitive and/or functional difficulties, which means they face
problems in recalling the name and past 5 to 10 years of history.
• Early Confusional, Mild Cognitive Impairment
It causes a problem in retrieving words, planning, organizing, objects misplacing as
well as forgetting fresh learning, which in turn affects the surrounding.
• Late Confusional, Mild Alzheimer's
In this, a person forgets the most recent events and conversations. The person
remembers himself and his family, but face problems while carrying out sequential
tasks such as cooking, driving, etc. Its duration is about two years,
• Early Dementia, Moderate Alzheimer's
In this, the person cannot manage independently. He faces difficulty in recalling the
past details and contact information. It lasts for about 1.5 years.
• Middle Dementia, Moderately Severe Alzheimer's
It leads to insufficient awareness about current events, and the person is unable to
recall the past. It causes an inability in people to take a bath and dress up
independently. It lasts for about 2.5 years approximately.
• Late or Severe Dementia, Failure to Thrive
It is severely limited intellectual ability. In this, a person either communicates
through short words or cries, which leads health to decline as it shut down the body
system. Its duration is 1 to 2.5 years.
Benefits of Timing Diagram
1. It depicts the state of an object at a particular point in time.
2. It implements forward and reverses engineering.
3. It keeps an eye on every single change that happens within the system.
Drawbacks of Timing Diagram
It is hard to maintain and understand.
UML Interaction Diagram
As the name suggests, the interaction diagram portrays the interactions between distinct entities
present in the model. It amalgamates both the activity and sequence diagrams. The
communication is nothing but units of the behavior of a classifier that provides context for
interactions.
A set of messages that are interchanged between the entities to achieve certain specified tasks
in the system is termed as interaction. It may incorporate any feature of the classifier of which
it has access. In the interaction diagram, the critical component is the messages and the lifeline.
In UML, the interaction overview diagram initiates the interaction between the objects utilizing
message passing. While drawing an interaction diagram, the entire focus is to represent the
relationship among different objects which are available within the system boundary and the
message exchanged by them to communicate with each other.
The message exchanged among objects is either to pass some information or to request some
information.
Notation of an Interaction Diagram

Purpose of an Interaction Diagram

The interaction diagram helps to envision the interactive (dynamic) behavior of any system. It
portrays how objects residing in the system communicates and connects to each other. It also
provides us with a context of communication between the lifelines inside the system.
Following are the purpose of an interaction diagram given below:
1. To visualize the dynamic behavior of the system.
2. To envision the interaction and the message flow in the system.
3. To portray the structural aspects of the entities within the system.
4. To represent the order of the sequenced interaction in the system.
5. To visualize the real-time data and represent the architecture of an object-
oriented system.
How to draw an Interaction Diagram?
Since the main purpose of an interaction diagram is to visualize the dynamic behavior of the
system, it is important to understand what a dynamic aspect really is and how we can visualize
it. The dynamic aspect is nothing but a screenshot of the system at the run time.
Before drawing an interaction diagram, the first step is to discover the scenario for which the
diagram will be made. Next, we will identify various lifelines that will be invoked in the
communication, and then we will classify each lifeline. After that, the connections are
investigated and how the lifelines are interrelated to each other.
Following are some things that are needed:
1. A total no of lifeline which will take part in the communication.
2. The sequence of the message flow among several entities within the system.
3. No operators used to ease out the functionality of the diagram.
4. Several distinct messages that depict the interactions in a precise and clear way.
5. The organization and structure of a system.
6. The order of the sequence of the flow of messages.
7. Total no of time constructs of an object.
There are two kinds of interaction diagrams—sequence diagrams and collaboration
diagrams. These two diagrams are equivalent in the sense that any one diagram can be derived
automatically from the other. However, they are both useful. These two actually portray
different perspectives of behaviour of a system and different types of inferences can be drawn
from them. The interaction diagrams play a major role in any effective object oriented design
process.
Package Diagram?
Package diagram, a kind of structural diagram, shows the arrangement and organization of
model elements in middle to large scale project. Package diagram can show both structure and
dependencies between sub-systems or modules, showing different views of a system, for
example, as multi-layered (aka multi-tiered) application - multi-layered application model.

Purpose of Package Diagrams

Package diagrams are used to structure high level system elements. Packages are used for
organizing large system which contains diagrams, documents and other key deliverables.
 • Package Diagram can be used to simplify complex class diagrams, it can group
classes into packages.
• A package is a collection of logically related UML elements.
• Packages are depicted as file folders and can be used on any of the UML
diagrams.
Package Diagram at a Glance
Package diagram is used to simplify complex class diagrams, you can group classes into
packages. A package is a collection of logically related UML elements.
The diagram below is a business model in which the classes are grouped into packages:
• Packages appear as rectangles with small tabs at the top.
• The package name is on the tab or inside the rectangle.
• The dotted arrows are dependencies.
• One package depends on another if changes in the other could possibly force
changes in the first.

Basic Concepts of Package Diagram

Package diagram follows hierarchal structure of nested packages. Atomic module for nested
package are usually class diagrams. There are few constraints while using package diagrams,
they are as follows.
• Package name should not be the same for a system, however classes inside
different packages could have the same name.
• Packages can include whole diagrams, name of components alone or no
components at all.
• Fully qualified name of a package has the following syntax.
Packages can be represented by the notations with some examples shown below:

Package Diagram - Dependency Notation

There are two sub-types involved in dependency. They are <<import>> & <<access>>. Though
there are two stereotypes users can use their own stereotype to represent the type of dependency
between two packages.
Package Diagram Example - Import
<<import>> - one package imports the functionality of other package

Package Diagram Example - Access

<<access>> - one package requires help from functions of other package.

Modeling Complex Grouping

A package diagram is often used to describe the hierarchical relationships (groupings) between
packages and other packages or objects. A package represents a namespace.
Package Diagram Example - Layering Structure
Package Diagram Example - Order Subsystem
Package Diagram Example - Order Processing System

Package Diagram Example - Order Processing System

Order Processing System - The Problem Description
We are going to design package diagram for "Track Order" scenario for an online shopping
store. Track Order module is responsible for providing tracking information for the products
ordered by customers. Customer types in the tracking serial number, Track Order modules
refers the system and updates the current shipping status to the customer.
Based on the project Description we should first identify the packages in the system and then
related them together according to the relationship:
Identify the packages of the system
• There is a track order module, it has to talk with other module to know about
the order details, let us call it "Order Details".
• Next after fetching Order Details it has to know about shipping details, let us
call that as "Shipping".
Identify the dependencies in the System
• Track order should get order details from "Order Details" and "Order Details"
has to know the tracking info given by the customer. Two modules are accessing
each other which suffices <<access>> dual dependency

• To know shipping information, "Shipping" can import "Track Order" to make

the navigation easier.

• Finally, Track Order dependency to UI Framework is also mapped which

completes our Package Diagram for Order Processing subsystem.
Component Diagram
A component diagram is used to break down a large object-oriented system into the smaller
components, so as to make them more manageable. It models the physical view of a system
such as executables, files, libraries, etc. that resides within the node.
It visualizes the relationships as well as the organization between the components present in
the system. It helps in forming an executable system. A component is a single unit of the
system, which is replaceable and executable. The implementation details of a component are
hidden, and it necessitates an interface to execute a function. It is like a black box whose
behavior is explained by the provided and required interfaces.

0
Purpose of a Component Diagram
Since it is a special kind of a UML diagram, it holds distinct purposes. It describes all the
individual components that are used to make the functionalities, but not the functionalities of
the system. It visualizes the physical components inside the system. The components can be a
library, packages, files, etc.
The component diagram also describes the static view of a system, which includes the
organization of components at a particular instant. The collection of component diagrams
represents a whole system.
The main purpose of the component diagram are enlisted below:
1. It envisions each component of a system.
2. It constructs the executable by incorporating forward and reverse engineering.
3. It depicts the relationships and organization of components.
When to use a Component Diagram?
It represents various physical components of a system at runtime. It is helpful in visualizing
the structure and the organization of a system. It describes how individual components can
together form a single system. Following are some reasons, which tells when to use component
diagram:
1. To divide a single system into multiple components according to the
functionality.
2. To represent the component organization of the system.
How to Draw a Component Diagram?
The component diagram is helpful in representing the physical aspects of a system, which are
files, executables, libraries, etc. The main purpose of a component diagram is different from
that of other diagrams. It is utilized in the implementation phase of any application.
Once the system is designed employing different UML diagrams, and the artifacts are prepared,
the component diagram is used to get an idea of implementation. It plays an essential role in
implementing applications efficiently.
Following are some artifacts that are needed to be identified before drawing a component
diagram:
1. What files are used inside the system?
2. What is the application of relevant libraries and artifacts?
3. What is the relationship between the artifacts?
Following are some points that are needed to be kept in mind after the artifacts are identified:
1. Using a meaningful name to ascertain the component for which the diagram is
about to be drawn.
2. Before producing the required tools, a mental layout is to be made.
3. To clarify the important points, notes can be incorporated.
Where to use Component Diagrams?
The component diagram is a special purpose diagram, which is used to visualize the static
implementation view of a system. It represents the physical components of a system, or we can
say it portrays the organization of the components inside a system. The components, such as
libraries, files, executables, etc. are first needed to be organized before the implementation.
The component diagram can be used for the followings:
1. To model the components of the system.
2. To model the schemas of a database.
3. To model the applications of an application.
4. To model the system's source code.
Basic Concepts of Component Diagram
A component represents a modular part of a system that encapsulates its contents and whose
manifestation is replaceable within its environment. In UML 2, a component is drawn as a
rectangle with optional compartments stacked vertically. A high-level, abstracted view of a
component in UML 2 can be modeled as:
1. A rectangle with the component's name
2. A rectangle with the component icon
3. A rectangle with the stereotype text and/or icon

Interface
In the example below shows two type of component interfaces:
Provided interface symbols with a complete circle at their end represent an interface that the
component provides - this "lollipop" symbol is shorthand for a realization relationship of an
interface classifier.
Required Interface symbols with only a half circle at their end (a.k.a. sockets) represent an
interface that the component requires (in both cases, the interface's name is placed near the
interface symbol itself).
Component Diagram Example - Using Interface (Order System)

Subsystems
The subsystem classifier is a specialized version of a component classifier. Because of this, the
subsystem notation element inherits all the same rules as the component notation element. The
only difference is that a subsystem notation element has the keyword of subsystem instead of
component.

Port
Ports are represented using a square along the edge of the system or a component. A port is
often used to help expose required and provided interfaces of a component.

Relationships
Graphically, a component diagram is a collection of vertices and arcs and commonly contain
components, interfaces and dependency, aggregation, constraint, generalization, association,
and realization relationships. It may also contain notes and constraints.
Relationships Notation
Association:
• An association specifies a
semantic relationship that can occur
between typed instances.
• It has at least two ends
represented by properties, each of
which is connected to the type of
the end. More than one end of the
association may have the same
type.
Composition:
• Composite aggregation is a
strong form of aggregation that
requires a part instance be included
in at most one composite at a time.
• If a composite is deleted, all of
its parts are normally deleted with
it.
Aggregation
• A kind of association that has
one of its end marked shared as
kind of aggregation, meaning that it
has a shared aggregation.
Constraint
• A condition or restriction
expressed in natural language text
or in a machine readable language
for the purpose of declaring some of
the semantics of an element.
Dependency
• A dependency is a relationship
that signifies that a single or a set of
model elements requires other
model elements for their
specification or implementation.
• This means that the complete
semantics of the depending
elements is either semantically or
structurally dependent on the
definition of the supplier
element(s).
Links:
• A generalization is a taxonomic
relationship between a more
general classifier and a more
specific classifier.
• Each instance of the specific
classifier is also an indirect instance
of the general classifier.
 • Thus, the specific classifier
inherits the features of the more
general classifier.

Modeling Source Code

• Either by forward or reverse engineering, identify the set of source code files of
interest and model them as components stereotyped as files.
• For larger systems, use packages to show groups of source code files.
• Consider exposing a tagged value indicating such information as the version
number of the source code file, its author, and the date it was last changed. Use tools
to manage the value of this tag.
• Model the compilation dependencies among these files using dependencies.
Again, use tools to help generate and manage these dependencies.

Component Example - Java Source Code

Component Diagram Example - C++ Code with versioning

Modeling an Executable Release

• Identify the set of components you'd like to model. Typically, this will involve
some or all the components that live on one node, or the distribution of these sets
of components across all the nodes in the system.
• Consider the stereotype of each component in this set. For most systems, you'll
find a small number of different kinds of components (such as executables, libraries,
tables, files, and documents). You can use the UML's extensibility mechanisms to
provide visual cues(clues) for these stereotypes.
• For each component in this set, consider its relationship to its neighbors. Most
often, this will involve interfaces that are exported (realized) by certain components
 and then imported (used) by others. If you want to expose the seams in your system,
model these interfaces explicitly. If you want your model at a higher level of
abstraction, elide these relationships by showing only dependencies among the
components.

Modeling a Physical Database

• Identify the classes in your model that represent your logical database schema.
• Select a strategy for mapping these classes to tables. You will also want to
consider the physical distribution of your databases. Your mapping strategy will be
affected by the location in which you want your data to live on your deployed
system.
• To visualize, specify, construct, and document your mapping, create a
component diagram that contains components stereotyped as tables.
• Where possible, use tools to help you transform your logical design into a
physical design.

Component Diagram at a Glance

A component diagram breaks down the actual system under development into various high
levels of functionality. Each component is responsible for one clear aim within the entire
system and only interacts with other essential elements on a need-to-know basis.
The example above shows the internal components of a larger component:
• The data (account and inspection ID) flows into the component via the port on
the right-hand side and is converted into a format the internal components can use.
The interfaces on the right are known as required interfaces, which represents the
services the component needed in order to carry out its duty.
• The data then passes to and through several other components via various
connections before it is output at the ports on the left. Those interfaces on the left
are known as provided interface, which represents the services to deliver by the
exhibiting component.
• It is important to note that the internal components are surrounded by a large
'box' which can be the overall system itself (in which case there would not be a
component symbol in the top right corner) or a subsystem or component of the
overall system (in this case the 'box' is a component itself).
One more Example of a Component Diagram
A component diagram for an online shopping system is given below:
UML Deployment Diagram
The deployment diagram visualizes the physical hardware on which the software will be
deployed. It portrays the static deployment view of a system. It involves the nodes and their
relationships.
It ascertains how software is deployed on the hardware. It maps the software architecture
created in design to the physical system architecture, where the software will be executed as a
node. Since it involves many nodes, the relationship is shown by utilizing communication
paths.
Purpose of Deployment Diagram
The main purpose of the deployment diagram is to represent how software is installed on the
hardware component. It depicts in what manner a software interacts with hardware to perform
its execution.
Both the deployment diagram and the component diagram are closely interrelated to each other
as they focus on software and hardware components. The component diagram represents the
components of a system, whereas the deployment diagram describes how they are actually
deployed on the hardware.
The deployment diagram does not focus on the logical components of the system, but it put its
attention on the hardware topology.
Following are the purposes of deployment diagram enlisted below:
1. To envision the hardware topology of the system.
2. To represent the hardware components on which the software components are
installed.
3. To describe the processing of nodes at the runtime.
Symbol and notation of Deployment diagram
The deployment diagram consist of the following notations:
 1. A component
2. An artifact
3. An interface
4. A node

How to draw a Deployment Diagram?

The deployment diagram portrays the deployment view of the system. It helps in visualizing
the topological view of a system. It incorporates nodes, which are physical hardware. The nodes
are used to execute the artifacts. The instances of artifacts can be deployed on the instances of
nodes.
Since it plays a critical role during the administrative process, it involves the following
parameters:
1. High performance
2. Scalability
3. Maintainability
4. Portability
5. Easily understandable
One of the essential elements of the deployment diagram is the nodes and artifacts. So it is
necessary to identify all of the nodes and the relationship between them. It becomes easier to
develop a deployment diagram if all of the nodes, artifacts, and their relationship is already
known.
Example of a Deployment diagram
A deployment diagram for the Apple iTunes application is given below.
The iTunes setup can be downloaded from the iTunes website, and also it can be installed on
the home computer. Once the installation and the registration are done, iTunes application can
easily interconnect with the Apple iTunes store. Users can purchase and download music,
video, TV serials, etc. and cache it in the media library.
Devices like Apple iPod Touch and Apple iPhone can update its own media library from the
computer with iTunes with the help of USB or simply by downloading media directly from the
Apple iTunes store using wireless protocols, for example; Wi-Fi, 3G, or EDGE.
When to use a Deployment Diagram?
The deployment diagram is mostly employed by network engineers, system administrators, etc.
with the purpose of representing the deployment of software on the hardware system. It
envisions the interaction of the software with the hardware to accomplish the execution. The
selected hardware must be of good quality so that the software can work more efficiently at a
faster rate by producing accurate results in no time.
The software applications are quite complex these days, as they are standalone, distributed,
web-based, etc. So, it is very necessary to design efficient software.
Deployment diagrams can be used for the followings:
1. To model the network and hardware topology of a system.
2. To model the distributed networks and systems.
3. Implement forwarding and reverse engineering processes.
4. To model the hardware details for a client/server system.
5. For modeling the embedded system.
Deployment Diagram at a Glance
Deployment diagrams are important for visualizing, specifying, and documenting embedded,
client/server, and distributed systems and also for managing executable systems through
forward and reverse engineering.
A deployment diagram is just a special kind of class diagram, which focuses on a system's
nodes. Graphically, a deployment diagram is a collection of vertices and arcs. Deployment
diagrams commonly contain:
Nodes
• 3-D box represents a node, either software or hardware
• HW node can be signified with <<stereotype>>
• Connections between nodes are represented with a line, with optional
<<stereotype>>
• Nodes can reside within a node
Other Notations
• Dependency
• Association relationships.
• May also contain notes and constraints.

Steps for Modeling an Embedded System

1. Identify the devices and nodes that are unique to your system.
2. Provide visual cues, especially for unusual devices, by using the UML's
extensibility mechanisms to define system-specific stereotypes with appropriate
icons. At the very least, you'll want to distinguish processors (which contain
software components) and devices (which, at that level of abstraction, don't directly
contain software).
3. Model the relationships among these processors and devices in a deployment
diagram. Similarly, specify the relationship between the components in your
system's implementation view and the nodes in your system's deployment view.
4. As necessary, expand on any intelligent devices by modeling their structure with
a more detailed deployment diagram.
Steps for Modeling a Client/Server System
1. Identify the nodes that represent your system's client and server processors.
2. Highlight those devices that are germane to the behavior of your system. For
example, you'll want to model special devices, such as credit card readers, badge
readers, and display devices other than monitors, because their placement in the
system's hardware topology are likely to be architecturally significant.
3. Provide visual cues for these processors and devices via stereotyping.
4. Model the topology of these nodes in a deployment diagram. Similarly, specify
the relationship between the components in your system's implementation view and
the nodes in your system's deployment view.
The example shows the topology of a human resources system, which follows a classical
client/server architecture.
TCP/IP Client / Server Example

Deployment Diagram Example - Modeling a Distributed System

1. Identify the system's devices and processors as for simpler client/server
systems.
2. If you need to reason about the performance of the system's network or the
impact of changes to the network, be sure to model these communication devices
to the level of detail sufficient to make these assessments.
3. Pay close attention to logical groupings of nodes, which you can specify by
using packages.
4. Model these devices and processors using deployment diagrams. Where
possible, use tools that discover the topology of your system by walking your
system's network.
5. If you need to focus on the dynamics of your system, introduce use case
diagrams to specify the kinds of behavior you are interested in, and expand on these
use cases with interaction diagrams.
6. When modeling a fully distributed system, it's common to reify the network
itself as an node. i.e. Internet, LAN, WAN as nodes
The Example shows the topology of a fully distributed system.
Deployment Diagram Example - Corporate Distributed System

Deployment Planning Checklist

When you are drafting a deployment planning for your company, you may find that you do
not know where to start or what you should focus on. The following checklist may give you
some ideas with planning for deployment:
How will your system be installed?
a. Who will install it? How long should it take to install?
b. Where the installation possibly fail?
c. How do you back out if the installation fails? How long does it take to
back out?
d. What is your installation window (during what time period can you
install your system)?
e. What backups do you need before installation?
f. Do you need to do a data conversion?
g. How do you know that the installation was successful?
I different versions of the system will be in production at the same time, how will you
resolve differences?