UML Diagrams

All the elements, relationships are used to make a complete UML diagram and the
diagram represents a system.

The visual effect of the UML diagram is the most important part of the entire
process. All the other elements are used to make it complete.

UML includes the following nine diagrams,

 Class diagram
 Object diagram
 Use case diagram
 Sequence diagram
 Collaboration diagram
 Activity diagram
 Statechart diagram
 Deployment diagram
 Component diagram

It is very important to distinguish between the UML model. Different

diagrams are used for different types of UML modeling. There are three
important types of UML modeling.

Structural Modeling
Structural modeling captures the static features of a system. They consist of the
following −

 Classes diagrams
 Objects diagrams
 Deployment diagrams
 Package diagrams
 Composite structure diagram
 Component diagram

Structural model represents the framework for the system and this framework is
the place where all other components exist.

Behavioural Modelling
Behavioral model describes the interaction in the system. It represents the
interaction among the structural diagrams. Behavioral modeling shows the
dynamic nature of the system. They consist of the following −

 Activity diagrams
 Interaction diagrams
 Use case diagrams

All the above show the dynamic sequence of flow in a system.

Architectural Modeling

Architectural model represents the overall framework of the system. It contains

both structural and behavioral elements of the system. Architectural model can be
defined as the blueprint of the entire system.

Class diagram
Class diagram is a static diagram. It represents the static view of an application.
Class diagram is not only used for visualizing, describing, and documenting
different aspects of a system but also for constructing executable code of the
software application

Purpose of Class Diagrams

The purpose of class diagram is to model the static view of an application.

Class diagrams are the only diagrams which can be directly mapped with object-
oriented languages and thus widely used at the time of construction.

It is the most popular UML diagram in the coder community.

The purpose of the class diagram can be summarized as −

 Analysis and design of the static view of an application.

 Describe responsibilities of a system.
 Base for component and deployment diagrams.
 Forward and reverse engineering.

How to Draw a Class Diagram:

 Class diagram is basically a graphical representation of the static
view of the system and represents different aspects of the application.

collection of class diagrams represent the whole system.

The following points should be remembered while drawing a class diagram −

 The name of the class diagram should be meaningful

 Each element and their relationships should be identified in advance.
 Responsibility (attributes and methods) of each class should be clearly
identified
 For each class, minimum number of properties should be specified, as
unnecessary properties will make the diagram complicated.
 Finally, before making the final version, the diagram should be drawn on
plain paper and reworked as many times as possible to make it correct.

The following diagram is an example of an Order System of an application. It

describes a particular aspect of the entire application.

Where to Use Class Diagrams?

Class diagrams are used for −

 Describing the static view of the system.

 Showing the collaboration among the elements of the static view.
 Describing the functionalities performed by the system.
 Construction of software applications using object oriented languages.
 Common Modeling Techniques

Modeling Simple Collaborations

To model simple collaborations,

1. Identify the function or behavior of the part of a system you would like to
model.
2. For each function or mechanism identify the classes, interfaces,
collaborations and relationships between them.
3. Use scenarios (sequence of activities) to walk through these things.

Modeling a Logical Database Schema

To model a schema,

1. Identify the classes whose state must be saved over the lifetime of the
application.
2. Create a class diagram and mark these classes as persistent by using tagged
values.
3. Provide the structural details for these classes like the attributes,
associations with other classes and the multiplicity.
4. Provide the behavior for these classes by listing out the operations that are
important for data access and integrity.
5. Wherever possible, use tools to convert the logical design to physical
design.
 Forward and Reverse Engineering

To forward engineer a class diagram,

1. Identify the rules for mapping the models to the implementation language
of your choice.
2. Depending on the semantics of the language, you may want to restrict the
information in your UML models. For example, UML supports multiple
inheritance. But some programming languages might not allow this.
3. Use tagged values to specify the target language.
4. Use tools to convert your models to code.

To reverse engineer the code,

1. Identify the rules for mapping the implementation language to a model.

2. Using a tool, navigate to the code that you want to reverse engineer. Use
the tool to generate a new model.

Object diagrams

An object diagram models the instances of classes in a class diagram. An object

diagram contains objects and links connecting the related objects.

Object diagrams allow us to model the static design view or static process view. It
involves modeling a snapshot of the system which contains objects (instances),
their state and links between objects.

An object diagram represents the static part of an interaction containing the objects
that communicate and the links between them without any messages.
Common Properties
An object diagram shares the same common properties like the rest of the
diagrams, a name which identifies the diagram and graphical content. What
distinguish an object diagram from the rest of the diagrams are its contents.

Contents

Object diagrams contain:

Objects

Links

Like all other diagrams, object diagrams may contain notes and constraints.

Object diagrams may also contain packages and subsystems which are used to
group the related elements in the model together. Sometimes we can also include
classes in the object diagrams. Generally, object diagrams are used to model the
object structures.

Common Modeling Techniques

Modeling Object Structures

To model an object structure,

 First, identify the function or behavior or part of a system you want to model as
collection of classes, interfaces and other things.
 For each function or mechanism identify the classes and interfaces that collaborate and
also identify the relationships between them.
 Consider a scenario (context) that walks through this mechanism and freeze at a moment
in time and identify the participating objects.
 Represent the state of objects by listing out the attributes and their values.
 Represent the links between objects which are instances of associations.

Forward and Reverse Engineering

Forward engineering a object diagram is theoretically possible but practically of limited value as
the objects are created and destroyed dynamically at runtime, we cannot represent them
statically.

To reverse engineer a object diagram,

1. Choose the target (context) you want to reverse engineer.

2. Use a tool to stop execution at a certain moment in time.
3. Identify the objects that collaborate with each other and represent them in an object diagram.
4. To understand their semantics, expose these object’s states.
5. Also identify the links between the objects to understand their semantics.

Collaboration Diagram
The collaboration diagram is used to show the relationship between the objects in a
system. Both the sequence and the collaboration diagrams represent the same
information but differently.
The collaboration diagram, which is also known as a communication diagram, is
used to portray the object's architecture in the system.

Notations of a Collaboration Diagram

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

1. Objects: The representation of an object is done by an object symbol with

its name and class underlined, separated by a colon.

2. Actors: In the collaboration diagram, the actor plays the main role as it
invokes the interaction. Each actor has its respective role and name.
3. Links: It portrays a relationship between the objects through which the
messages are sent. It is represented by a solid line.
4. Messages: It is a communication between objects which carries information
and includes a sequence number, so that the activity may take place. It is
represented by a labeled arrow, which is placed near a link. The messages
are sent from the sender to the receiver.

steps for creating a Collaboration Diagram

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

Example of a Collaboration Diagram

Benefits of a Collaboration Diagram

1. The collaboration diagram is also known as Communication Diagram.
2. It mainly puts emphasis on the structural aspect of an interaction diagram,
i.e., how lifelines are connected.
3. The syntax of a collaboration diagram is similar to the sequence diagram;
4.
 5. The collaboration diagram is semantically weak in comparison to the
sequence diagram.
6. The special case of a collaboration diagram is the object diagram.
7. It focuses on the elements and not the message flow, like sequence
diagrams.
8. Since the collaboration diagrams are not that expensive, the sequence
diagram can be directly converted to the collaboration diagram.
9. There may be a chance of losing some amount of information while
implementing a collaboration diagram with respect to the sequence diagram.

The drawback of a Collaboration Diagram

1. Multiple objects residing in the system can make a complex collaboration

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

Messages
Messages in collaboration diagrams are shown as arrows pointing from the Client
object to the Supplier object. Typically, messages represent a client invoking an
operation on a supplier object.

Message icons have one or more messages associated with them. Messages are
composed of message text prefixed by a sequence number. This sequence number
indicates the time-ordering of the message.

1. Enter Borrower ID

1.1 CalcAmtCanBorrow

1.1.1 <<create>>

1.1.2 CalcBorrowerFines

1.1.3 GetBorrowersCheckedOutMedia

Advertisement
1.1.4 IsMediaOverdue

1.1.5 Amt Can Borrow

1.2 Display Invalid User Msg

The first message in a collaboration diagram is always numbered 1, the second is

2, and so on.

You can indicate that a message is nested under a parent message by adding a
decimal point and incremental digits to the parent's sequence number.

For example, the "CalcAmtCanBorrow" message is the first nested message under
"Enter Borrower ID" and is given the sequence number 1.1. The second nested
message under "Enter Borrower ID" is "Display Invalid User Msg," so it's given a
sequence number of 1.2. As you can see, there are several messages nested under
"CalcAmtCanBorrow" and these are numbered 1.1.1 through 1.1.5.

In collaboration diagrams, a message icon can represent one or more messages.

Iterating and Conditional Messages

Collaboration diagrams use syntax similar to sequence diagrams to indicate that
either a message iterates (is run multiple times) or is run conditionally.

You can indicate that a particular message iterates by prefixing a message

sequence number with an iteration expression. You can simply use an asterisk (*)
to indicate that a message runs more than once.

To indicate that a message is run conditionally, you can prefix the message
sequence number with a conditional clause such as [ x = true ]. This indicates that
the message is sent only if the condition is met.
Sequence Diagram
What is a Sequence Diagram?
Sequence diagrams describe interactions among classes in terms of an exchange of
messages over time. They're also called event diagrams.
 These can help to predict how a system will behave and to discover responsibilities a
class may need to have in the process of modeling a new system.

Basic Sequence Diagram Notations

Class Roles or Participants
Class roles describe the way an object will behave in context. Use the UML object
symbol to illustrate class roles, but don't list object attributes.

Activation or Execution Occurrence

Activation boxes represent the time an object needs to complete a task.

Messages
Messages are arrows that represent communication between objects. Use half-arrowed
lines to represent asynchronous messages.
Asynchronous messages are sent from an object that will not wait for a response from
the receiver before continuing its tasks.

Lifelines
Lifelines are vertical dashed lines that indicate the object's presence over time.
.
Loops
A repetition or loop within a sequence diagram is depicted as a rectangle. Place the
condition for exiting the loop at the bottom left corner in square brackets [ ].
Types of Messages in Sequence Diagrams
Synchronous Message
A synchronous message requires a response before the interaction can continue. It's
usually drawn using a line with a solid arrowhead pointing from one object to another.

Asynchronous Message
Asynchronous messages don't need a reply for interaction to continue. Like synchronous
messages, they are drawn with an arrow connecting two lifelines; however, the
arrowhead is usually open and there's no return message depicted.

Reply or Return Message

A reply message is drawn with a dotted line and an open arrowhead pointing back to
the original lifeline.

Self Message
A message an object sends to itself, usually shown as a U shaped arrow pointing back to
itself.

Create Message
This is a message that creates a new object. Similar to a return message, it's depicted
with a dashed line and an open arrowhead that points to the rectangle representing the
object created.

Delete Message
This is a message that destroys an object. It can be shown by an arrow with an x at the
end.
 Found Message
A message sent from an unknown recipient, shown by an arrow from an endpoint to a
lifeline.

Lost Message
A message sent to an unknown recipient. It's shown by an arrow going from a lifeline to
an endpoint, a filled circle or an x.

Broadcast messages are messages that are sent by a single object but
received by more than one. Broadcast messages imply concurrency
(otherwise multiple messages would have to be sent).

I have the following code:

A->B: Hello

A->C:Hello

The problem is that the line is in two lines. I would like to have one line with many arrows
on each or some participants.

Could there be a possibility to add :

A->B and C: Hello // Multicast message

and

A->*:Hello //Broadcast message

Processes and Threads

 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.

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.
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.

UML Use Case Diagram

A use case diagram is used to represent the dynamic behaviour of a system.

It models the tasks, services, and functions required by a system/subsystem of an

application.

It depicts the high-level functionality of a system and also tells how the user handles a
system.

Purpose of Use Case Diagrams

The main purpose of a use case diagram is to portray the dynamic aspect of a system.

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.

How to draw a Use Case diagram?

Following are some rules that must be followed while drawing a use case diagram:

1. A meaningful name should be assigned to the actor or a use case of a system.

2. The communication of an actor with a use case must be defined in an
understandable way.
3. Specified notations to be used as and when required.
4. The most significant interactions should be represented among the multiple no
of interactions between the use case and actors.

Example of a Use Case Diagram

.
Important tips for drawing a Use Case diagram
Following are some important tips that are to be kept in mind while drawing a use case
diagram:

1. A simple and complete use case diagram should be articulated.

2. A use case diagram should represent the most significant interaction among the
multiple interactions.
3. At least one module of a system should be represented by the use case diagram.
4. If the use case diagram is large and more complex, then it should be drawn more
generalized.

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 is also termed as an object-oriented flowchart.

Components of an Activity Diagram

Following are the component of an activity diagram:

Activities

it can be said that an activity is a network of nodes that are connected by edges.
The edges depict the flow of execution

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.
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.

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

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?

It mainly models processes and workflows. It envisions the dynamic behavior of

the system

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.

UML State Machine Diagram

The state machine diagram is also called the Statechart or State Transition diagram,
which shows the order of states 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.

Following are the types of a state machine diagram that are given below:
 1. Behavioral state machine
The behavioral state machine diagram records the behavior of an object
within the system.
2. 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.

Notation of a State Machine Diagram

Following are the notations of a state machine diagram enlisted below:

1. Initial state: It defines the initial state (beginning) of a system, and it is

represented by a black filled circle.
2. Final state: It represents the final state (end) of a system. It is denoted by a
filled circle present within a circle.
3. Decision box: It is of diamond shape that represents the decisions to be
made on the basis of an evaluated guard.
4. 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.
 5. 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.

Events And signals

In state machines (sequence of states), we can use 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.

. 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.

4.
 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.

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.

UML Timing Diagram

It consists of a graph or waveform that depicts the state of a lifeline at a specific
point of time.

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 depicts a graphical representation of states of a lifeline per unit time.

Basic concepts of a Timing Diagram

, 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.

State or Condition Timeline

In UML, the state or condition is continuous.

Timeline showing the change in the state of virus between dormant, Propagation, Triggering,
Execution

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

1. It is hard to maintain and understand.

Interaction Diagram
From the term Interaction, it is clear that the diagram is used to describe some type
of interactions among the different elements in the model. This interaction is a part
of dynamic behavior of the system.

This interactive behavior is represented in UML by two diagrams known as

Sequence diagram and Collaboration diagram. The basic purpose of both the
diagrams are similar.

Sequence diagram emphasizes on time sequence of messages and collaboration

diagram emphasizes on the structural organization of the objects that send and
receive messages.

Purpose of Interaction Diagrams

The purpose of interaction diagrams is to visualize the interactive behavior of the
system. Visualizing the interaction is a difficult task. Hence, the solution is to use
different types of models to capture the different aspects of the interaction.
Sequence and collaboration diagrams are used to capture the dynamic nature but
from a different angle.

The purpose of interaction diagram is −

 To capture the dynamic behaviour of a system.

 To describe the message flow in the system.
 To describe the structural organization of the objects.
 To describe the interaction among objects.

Architectural Modeling
Architectural model represents the overall framework of the system. It contains both
structural and behavioral elements of the system. Architectural model can be defined
as the blueprint of the entire system. Package diagram comes under architectural
modeling.

Component diagrams are different in terms of nature and behavior.

Component diagrams are used to model the physical aspects of a system.
Component diagrams are used to visualize the organization and relationships among
components in a system. These diagrams are also used to make executable systems.

Purpose of Component Diagrams

It does not describe the functionality of the system but it describes the components
used to make those functionalities.

A single component diagram cannot represent the entire system but a collection of
diagrams is used to represent the whole.
The purpose of the component diagram can be summarized as −
 Visualize the components of a system.
 Construct executables by using forward and reverse engineering.
 Describe the organization and relationships of the components.

How to Draw a Component Diagram?

Component diagrams are used to describe the physical artifacts of a system. This
artifact includes files, executables, libraries, etc
The purpose of this diagram is different. Component diagrams are used during the
implementation phase of an application.
Initially, the system is designed using different UML diagrams and then when the
artifacts are ready, component diagrams are used to get an idea of the implementation.

Before drawing a component diagram, the following artifacts are to be identified clearl y
−
 Files used in the system.
 Libraries and other artifacts relevant to the application.
 Relationships among the artifacts.

Following is a component diagram for order management system. Here, the artifacts
are files. The diagram shows the files in the application and their relationships. In
actual, the component diagram also contains dlls, libraries, folders, etc.

Where to Use Component Diagrams?

These diagrams show the physical components of a system. To clarify it, we can say
that component diagrams describe the organization of the components in a system.
.
As we have already discussed, those components are libraries, files, executables, etc.
Before implementing the application, these components are to be organized. This
component organization is also designed separately as a part of project execution.
Component diagrams are very important from implementation perspective. Thus, the
implementation team of an application should have a proper knowledge of the
component details
Component diagrams can be used to −
 Model the components of a system.
 Model the database schema.
 Model the executables of an application.
 Model the system's source code.

 Deployment Diagrams

Deployment diagrams are used to visualize the topology of the physical components of
a system, where the software components are deployed.

Purpose of Deployment Diagrams

The term Deployment itself describes the purpose of the diagram. Deployment
diagrams are used for describing the hardware components, where software
components are deployed. Component diagrams and deployment diagrams are closely
related.
Component diagrams are used to describe the components and deployment diagrams
shows how they are deployed in hardware.
UML is mainly designed to focus on the software artifacts of a system. However, these
two diagrams are special diagrams used to focus on software and hardware
components.
The purpose of deployment diagrams can be described as −
 Visualize the hardware topology of a system.
 Describe the hardware components used to deploy software components.
 Describe the runtime processing nodes.

How to Draw a Deployment Diagram?

Deployment diagrams are useful for system engineers. An efficient deployment
diagram is very important as it controls the following parameters −
 Performance
 Scalability
 Maintainability
 Portability
Before drawing a deployment diagram, the following artifacts should be identified −
 Nodes
 Relationships among nodes
Following is a sample deployment diagram to provide an idea of the deployment view
of order management system. Here, we have shown nodes as −
 Monitor
 Modem
 Caching server
 Server
The application is assumed to be a web-based application, which is deployed in a
clustered environment using server 1, server 2, and server 3. The user connects to the
application using the Internet.
The following deployment diagram has been drawn considering all the points
mentioned above.
Where to Use Deployment Diagrams?
Deployment diagrams can be used −
 To model the hardware topology of a system.
 To model the embedded system.
 To model the hardware details for a client/server system.
 To model the hardware details of a distributed application.
 For Forward and Reverse engineering.

_if a caller sends a synchronous message, it must wait until the message is done, such as invoking a
subroutine. If a caller sends an asynchronous message, it can continue processing and doesn’t have to wait
for a response. You see asynchronous calls in multithreaded applications and in message-oriented
middleware. Asynchrony gives better responsiveness and reduces the temporal coupling but is harder to
debug.