UML - Object Diagrams

Object diagrams are derived from class diagrams so object diagrams are dependent upon class
diagrams.

Object diagrams represent an instance of a class diagram. The basic concepts are similar for class
diagrams and object diagrams. Object diagrams also represent the static view of a system but this
static view is a snapshot of the system at a particular moment.

Object diagrams are used to render a set of objects and their relationships as an instance.

Purpose of Object Diagrams

The purpose of a diagram should be understood clearly to implement it practically. The purposes
of object diagrams are similar to class diagrams.

The difference is that a class diagram represents an abstract model consisting of classes and their
relationships. However, an object diagram represents an instance at a particular moment, which
is concrete in nature.

It means the object diagram is closer to the actual system behavior. The purpose is to capture the
static view of a system at a particular moment.

The purpose of the object diagram can be summarized as −

 Forward and reverse engineering.

 Object relationships of a system
 Static view of an interaction.
 Understand object behaviour and their relationship from practical perspective

How to Draw an Object Diagram?

We have already discussed that an object diagram is an instance of a class diagram. It implies
that an object diagram consists of instances of things used in a class diagram.

So both diagrams are made of same basic elements but in different form. In class diagram
elements are in abstract form to represent the blue print and in object diagram the elements are in
concrete form to represent the real world object.

To capture a particular system, numbers of class diagrams are limited. However, if we consider
object diagrams then we can have unlimited number of instances, which are unique in nature.
Only those instances are considered, which have an impact on the system.
The difference is that a class diagram represents an abstract model consisting of classes and their
relationships. However, an object diagram represents an instance at a particular moment, which
is concrete in nature.

It means the object diagram is closer to the actual system behavior. The purpose is to capture the
static view of a system at a particular moment.

The purpose of the object diagram can be summarized as −

 Forward and reverse engineering.

 Object relationships of a system
 Static view of an interaction.
 Understand object behaviour and their relationship from practical perspective

How to Draw an Object Diagram?

We have already discussed that an object diagram is an instance of a class diagram. It implies
that an object diagram consists of instances of things used in a class diagram.

So both diagrams are made of same basic elements but in different form. In class diagram
elements are in abstract form to represent the blue print and in object diagram the elements are in
concrete form to represent the real world object.

To capture a particular system, numbers of class diagrams are limited. However, if we consider
object diagrams then we can have unlimited number of instances, which are unique in nature.
Only those instances are considered, which have an impact on the system.

The same is true for special order and normal order objects which have number of orders as 20,
30, and 60. If a different time of purchase is considered, then these values will change
accordingly.

The following object diagram has been drawn considering all the points mentioned above
UML - Activity Diagram
Activity Diagrams
In UML, an activity diagram is used to display the sequence of activities. Activity diagrams
show the workflow from a start point to the finish point detailing the many decision paths that
exist in the progression of events contained in the activity. They may be used to detail situations
where parallel processing may occur in the execution of some activities. Activity diagrams are
useful for business modelling where they are used for detailing the processes involved in
business activities.

An Example of an activity diagram is shown below.

The following sections describe the elements that constitute an activity diagram.

Activities

An activity is the specification of a parameterized sequence of behaviour. An activity is shown as

a round-cornered rectangle enclosing all the actions, control flows and other elements that make
up the activity.
Actions

An action represents a single step within an activity. Actions are denoted by round-cornered
rectangles.

Action Constraints

Constraints can be attached to an action. The following diagram shows an action with local pre-
and post-conditions.
Control Flow

A control flow shows the flow of control from one action to the next. Its notation is a line with
an arrowhead.

Initial Node

An initial or start node is depicted by a large black spot, as shown below.

Final Node

There are two types of final node: activity and flow final nodes. The activity final node is
depicted as a circle with a dot inside.

The flow final node is depicted as a circle with a cross inside.

The difference between the two node types is that the flow final node denotes the end of a single
control flow; the activity final node denotes the end of all control flows within the activity.
Objects and Object Flows

An object flow is a path along which objects or data can pass. An object is shown as a rectangle.

An object flow is shown as a connector with an arrowhead denoting the direction the object is
being passed.

An object flow must have an object on at least one of its ends. A shorthand notation for the
above diagram would be to use input and output pins.

A data store is shown as an object with the «datastore» keyword.

Decision and Merge Nodes

Decision nodes and merge nodes have the same notation: a diamond shape. They can both be
named. The control flows coming away from a decision node will have guard conditions which
will allow control to flow if the guard condition is met. The following diagram shows use of a
decision node and a merge node.

Fork and Join Nodes

Forks and joins have the same notation: either a horizontal or vertical bar (the orientation is
dependent on whether the control flow is running left to right or top to bottom). They indicate the
start and end of concurrent threads of control. The following diagram shows an example of their
use.

A join is different from a merge in that the join synchronizes two inflows and produces a single
outflow. The outflow from a join cannot execute until all inflows have been received. A merge
passes any control flows straight through it. If two or more inflows are received by a merge
symbol, the action pointed to by its outflow is executed two or more times.

Expansion Region

An expansion region is a structured activity region that executes multiple times. Input and output
expansion nodes are drawn as a group of three boxes representing a multiple selection of items.
The keyword "iterative", "parallel" or "stream" is shown in the top left corner of the region.
Exception Handlers

Exception Handlers can be modelled on activity diagrams as in the example below.

Interruptible Activity Region

An interruptible activity region surrounds a group of actions that can be interrupted. In the very
simple example below, the "Process Order" action will execute until completion, when it will
pass control to the "Close Order" action, unless a "Cancel Request" interrupt is received, which
will pass control to the "Cancel Order" action.
Partition

An activity partition is shown as either a horizontal or vertical swimlane. In the following

diagram, the partitions are used to separate actions within an activity into those performed by the
accounting department and those performed by the customer.

UML - Statechart Diagrams

How to Draw a Statechart Diagram?
Statechart diagram is used to describe the states of different objects in its life cycle. Emphasis is
placed on the state changes upon some internal or external events. These states of objects are
important to analyze and implement them accurately.

Statechart diagrams are very important for describing the states. States can be identified as the
condition of objects when a particular event occurs.
Before drawing a Statechart diagram we should clarify the following points −

 Identify the important objects to be analyzed.

 Identify the states.
 Identify the events.

Following is an example of a Statechart diagram where the state of Order object is analyzed

The first state is an idle state from where the process starts. The next states are arrived for events
like send request, confirm request, and dispatch order. These events are responsible for the state
changes of order object.

During the life cycle of an object (here order object) it goes through the following states and
there may be some abnormal exits. This abnormal exit may occur due to some problem in the
system. When the entire life cycle is complete, it is considered as a complete transaction as
shown in the following figure. The initial and final state of an object is also shown in the
following figure.

UML package diagrams

Basic components of a package diagram
The makeup of a package diagram is relatively simple. Each diagram includes only two symbols:

Symbol
Symbol Image Description
Name

Groups common elements based on

Package
data, behavior, or user interaction

Depicts the relationship between one

Dependency element (package, named element,
etc) and another

Using packages with other UML diagrams

As we’ve shown earlier in this guide, packages are UML constructs that can be used to organize
the elements within any UML classifier in a variety of UML diagrams. Package diagrams are
most commonly found used in:

 Use-case diagrams: Each use-case is depicted as an individual package

 Class diagrams: Classes are organized into into packages

Packages can also be used within other UML model types to organize and arrange elements such
as classes, data entities, and use cases. By fuzing the package diagram structure with other UML
diagrams, you can simplify any model type, making it easier to understand.

Package diagram example

Take a look at the following template to see how a package diagram models the packages within
a basic e-commerce web app. Click on the template to modify it and explore how you can show
the structure of any designed system at a package level.
UML Sequence Diagram
Basic symbols and components
To understand what a sequence diagram is, you should be familiar with its symbols and
components. Sequence diagrams are made up of the following icons and elements:

Symbol Name Description

Represents a class or object in UML. The object symbol demonstrates
Object
how an object will behave in the context of the system. Class attributes
symbol
should not be listed in this shape.
Activation Represents the time needed for an object to complete a task. The longer
box the task will take, the longer the activation box becomes.
Symbol Name Description
Actor symbol Shows entities that interact with or are external to the system.
Used in UML 2.0 notation to contain interactive elements of the diagram.
Package
Also known as a frame, this rectangular shape has a small inner rectangle
symbol
for labeling the diagram.
Represents the passage of time as it extends downward. This dashed
Lifeline vertical line shows the sequential events that occur to an object during the
symbol charted process. Lifelines may begin with a labeled rectangle shape or an
actor symbol.
Option loop Used to model if/then scenarios, i.e., a circumstance that will only occur
symbol under certain conditions.
Symbolizes a choice (that is usually mutually exclusive) between two or
Alternative
more message sequences. To represent alternatives, use the labeled
symbol
rectangle shape with a dashed line inside.

Common message symbols

Use the following arrows and message symbols to show how information is transmitted between
objects. These symbols may reflect the start and execution of an operation or the sending and
reception of a signal.

Symbol Name Description

Represented by a solid line with a solid arrowhead. This symbol is
Synchronous
used when a sender must wait for a response to a message before
message symbol
it continues. The diagram should show both the call and the reply.
Represented by a solid line with a lined arrowhead. Asynchronous
Asynchronous
messages don't require a response before the sender continues.
message symbol
Only the call should be included in the diagram.
Asynchronous return
Represented by a dashed line with a lined arrowhead.
message symbol
Asynchronous create Represented by a dashed line with a lined arrowhead. This
message symbol message creates a new object.
Reply message Represented by a dashed line with a lined arrowhead, these
symbol messages are replies to calls.
Delete message Represented by a solid line with a solid arrowhead, followed by
symbol an X. This message destroys an object.

Sequence diagram examples

Sequence diagram of a hospital management system
Technology has completely transformed the field of medicine, as it has with most industries. A
hospital information system, also known as a hospital information system, helps doctors,
administrators, and hospital staff managing all of the activities and information collected at a
hospital, including checkups, prescriptions, appointments, and information on the patients and
their caretakers. The diagram below provides a simple view of how the primary processes
operate with each other over time.
Sequence diagram for ATM systems

An ATM allows patrons to access their bank accounts through a completely automated process.
You can examine the steps of this process in a manageable way by drawing or viewing a
sequence diagram. The example below outlines the sequential order of the interactions in the
ATM system.