MCA & MAI-204: SE- UML UNIT-V

UNIT – V

Introduction to UML: Use Case Approach: Identification of Classes and Relationships, Identifying
State and Behavior, Use Case Diagram, Class Diagram – State Diagram - Sequence ‘Diagram –
Activity Diagram – Deployment Diagrams Case Study – LMS.

INTRODUCTION TO UML
A. UML, which stands for Unified Modeling Language, is a visual modeling language used for
designing, visualizing, and documenting software systems.

B. UML provides a standardized set of diagrams and notations that help communicate and understand
the structure, behavior, and interactions of complex systems.

C. UML serves as a common language for software developers, analysts, designers, and stakeholders
to collaborate and express system requirements, design decisions, and implementation details.

Unified Modeling Language (UML) is a general purpose modelling language. The main aim of UML
is to define a standard way to visualize the way a system has been designed. It is quite similar to
blueprints used in other fields of engineering.
UML is not a programming language, it is rather a visual language. We use UML diagrams to
portray the behavior and structure of a system. UML helps software engineers, businessmen and
system architects with modelling, design and analysis. The Object Management Group (OMG)
adopted Unified Modelling Language as a standard in 1997. Its been managed by OMG ever since.
International Organization for Standardization (ISO) published UML as an approved standard in 2005.
UML has been revised over the years and is reviewed periodically.

Do we really need UML?

• Complex applications need collaboration and planning from multiple teams and hence
require a clear and concise way to communicate amongst them.
• Businessmen do not understand code. So UML becomes essential to communicate with non
programmers essential requirements, functionalities and processes of the system.
• A lot of time is saved down the line when teams are able to visualize processes, user
interactions and static structure of the system.
UML is linked with object oriented design and analysis. UML makes the use of elements and forms
associations between them to form diagrams. Diagrams in UML can be broadly classified as:

1. Structural Diagrams – Capture static aspects or structure of a system. Structural Diagrams

include: Component Diagrams, Object Diagrams, Class Diagrams and Deployment
Diagrams.
2. Behavior Diagrams – Capture dynamic aspects or behavior of the system. Behavior
diagrams include: Use Case Diagrams, State Diagrams, Activity Diagrams and Interaction
Diagrams.
The image below shows the hierarchy of diagrams according to UML 2.2
Page No: [ 1 ] Dr. Virendra Kumar Tiwari
 MCA & MAI-204: SE- UML UNIT-V

Object Oriented Concepts Used in UML –

1. Class – A class defines the blue print i.e. structure and functions of an object.
2. Objects – Objects help us to decompose large systems and help us to modularize our
system. Modularity helps to divide our system into understandable components so that we
can build our system piece by piece. An object is the fundamental unit (building block) of a
system which is used to depict an entity.
3. Inheritance – Inheritance is a mechanism by which child classes inherit the properties of
their parent classes.
4. Abstraction – Mechanism by which implementation details are hidden from user.
5. Encapsulation – Binding data together and protecting it from the outer world is referred to
as encapsulation.
6. Polymorphism – Mechanism by which functions or entities are able to exist in different
forms.
Additions in UML 2.0 –
• Software development methodologies like agile have been incorporated and scope of
original UML specification has been broadened.
• Originally UML specified 9 diagrams. UML 2.x has increased the number of diagrams
from 9 to 13. The four diagrams that were added are : timing diagram, communication
diagram, interaction overview diagram and composite structure diagram. UML 2.x
renamed statechart diagrams to state machine diagrams.
• UML 2.x added the ability to decompose software system into components and sub-
components.

Page No: [ 2 ] Dr. Virendra Kumar Tiwari

 MCA & MAI-204: SE- UML UNIT-V

Structural UML Diagrams –

1. Class Diagram – The most widely use UML diagram is the class diagram. It is the
building block of all object oriented software systems. We use class diagrams to depict the
static structure of a system by showing system’s classes,their methods and attributes. Class
diagrams also help us identify relationship between different classes or objects.
2. Composite Structure Diagram – We use composite structure diagrams to represent the
internal structure of a class and its interaction points with other parts of the system. A
composite structure diagram represents relationship between parts and their configuration
which determine how the classifier (class, a component, or a deployment node) behaves.
They represent internal structure of a structured classifier making the use of parts, ports,
and connectors. We can also model collaborations using composite structure diagrams.
They are similar to class diagrams except they represent individual parts in detail as
compared to the entire class.
3. Object Diagram – An Object Diagram can be referred to as a screenshot of the instances
in a system and the relationship that exists between them. Since object diagrams depict
behaviour when objects have been instantiated, we are able to study the behaviour of the
system at a particular instant. An object diagram is similar to a class diagram except it
shows the instances of classes in the system. We depict actual classifiers and their
relationships making the use of class diagrams. On the other hand, an Object Diagram
represents specific instances of classes and relationships between them at a point of time.
4. Component Diagram – Component diagrams are used to represent how the physical
components in a system have been organized. We use them for modelling implementation
details. Component Diagrams depict the structural relationship between software system
elements and help us in understanding if functional requirements have been covered by
planned development. Component Diagrams become essential to use when we design and
build complex systems. Interfaces are used by components of the system to communicate
with each other.
5. Deployment Diagram – Deployment Diagrams are used to represent system hardware and
its software. It tells us what hardware components exist and what software components run
on them.We illustrate system architecture as distribution of software artifacts over
distributed targets. An artifact is the information that is generated by system software. They
are primarily used when a software is being used, distributed or deployed over multiple
machines with different configurations.
6. Package Diagram – We use Package Diagrams to depict how packages and their elements
have been organized. A package diagram simply shows us the dependencies between
different packages and internal composition of packages. Packages help us to organise
UML diagrams into meaningful groups and make the diagram easy to understand. They are
primarily used to organise class and use case diagrams.

Behavior Diagrams –

1. State Machine Diagrams – A state diagram is used to represent the condition of the
system or part of the system at finite instances of time. It’s a behavioral diagram and it

Page No: [ 3 ] Dr. Virendra Kumar Tiwari

 MCA & MAI-204: SE- UML UNIT-V

represents the behavior using finite state transitions. State diagrams are also referred to
as State machines and State-chart Diagrams . These terms are often used
interchangeably. So simply, a state diagram is used to model the dynamic behavior of a
class in response to time and changing external stimuli.
2. Activity Diagrams – We use Activity Diagrams to illustrate the flow of control in a
system. We can also use an activity diagram to refer to the steps involved in the execution
of a use case. We model sequential and concurrent activities using activity diagrams. So,
we basically depict workflows visually using an activity diagram. An activity diagram
focuses on condition of flow and the sequence in which it happens. We describe or depict
what causes a particular event using an activity diagram.
3. Use Case Diagrams – Use Case Diagrams are used to depict the functionality of a system
or a part of a system. They are widely used to illustrate the functional requirements of the
system and its interaction with external agents(actors). A use case is basically a diagram
representing different scenarios where the system can be used. A use case diagram gives us
a high level view of what the system or a part of the system does without going into
implementation details.
4. Sequence Diagram – A sequence diagram simply depicts interaction between objects in a
sequential order i.e. the order in which these interactions take place. We can also use the
terms event diagrams or event scenarios to refer to a sequence diagram. Sequence diagrams
describe how and in what order the objects in a system function. These diagrams are widely
used by businessmen and software developers to document and understand requirements
for new and existing systems.
5. Communication Diagram – A Communication Diagram (known as Collaboration
Diagram in UML 1.x) is used to show sequenced messages exchanged between objects. A
communication diagram focuses primarily on objects and their relationships. We can
represent similar information using Sequence diagrams, however, communication diagrams
represent objects and links in a free form.
6. Timing Diagram – Timing Diagram are a special form of Sequence diagrams which are
used to depict the behavior of objects over a time frame. We use them to show time and
duration constraints which govern changes in states and behavior of objects.
7. Interaction Overview Diagram – An Interaction Overview Diagram models a sequence of
actions and helps us simplify complex interactions into simpler occurrences. It is a mixture
of activity and sequence diagrams.

Page No: [ 4 ] Dr. Virendra Kumar Tiwari

 MCA & MAI-204: SE- UML UNIT-V

UML Class Diagram Relationships

Relationships depict a connection between several things, such as structural, behavioral, or grouping
things in the unified modeling language. Since it is termed as a link, it demonstrates how things are
interrelated to each other at the time of system execution. It constitutes four types of relationships,
i.e., dependency, association, generalization, and realization.

Dependency
Whenever there is a change in either the structure or the behavior of the class that affects the other class,
such a relationship is termed as a dependency. Or, simply, we can say a class contained in other class is
known as dependency. It is a unidirectional relationship.

Association
Association is a structural relationship that represents how two entities are linked or connected to each
other within a system. It can form several types of associations, such as one-to-one, one-to-many,
many-to-one, and many-to-many. A ternary association is one that constitutes three links. It portrays
the static relationship between the entities of two classes.

An association can be categorized into four types of associations, i.e., bi-directional, unidirectional,
aggregation (composition aggregation), and reflexive, such that an aggregation is a special form of
association and composition is a special form of aggregation. The mostly used associations are
unidirectional and bi-directional.

Aggregation
An aggregation is a special form of association. It portrays a part-of relationship. It forms a binary
relationship, which means it cannot include more than two classes. It is also known as Has-a
relationship. It specifies the direction of an object contained in another object. In aggregation, a child
can exist independent of the parent.

Composition
In a composition relationship, the child depends on the parent. It forms a two-way relationship. It is a
special case of aggregation. It is known as Part-of relationship.

Aggregation VS Composition relationship

Features Aggregation relationship Composition relationship

Dependency In an aggregation relationship, a child can exist In a composition relationship, the

independent of a parent. child cannot exist independent of the
parent.

Page No: [ 5 ] Dr. Virendra Kumar Tiwari

 MCA & MAI-204: SE- UML UNIT-V

Type of It constitutes a Has-a relationship. It constitutes Part-of relationship.

Relationship

Type of It forms a weak association. It forms a strong association.

Association

Examples A doctor has patients when the doctor gets A hospital and its wards. If the
transfer to another hospital, the patients do not hospital is destroyed, the wards also
accompany to a new workplace. get destroyed.

Generalization
The generalization relationship implements the object-oriented concept called inheritance or is-
a relationship. It exists between two objects (things or entities), such that one entity is a parent
(superclass or base class), and the other one is a child (subclass or derived class). These are represented
in terms of inheritance. Any child can access, update, or inherit the functionality, structure, and behavior
of the parent.

Realization
It is a kind of relationship in which one thing specifies the behavior or a responsibility to be carried out,
and the other thing carries out that behavior. It can be represented on a class diagram or component
diagrams. The realization relationship is constituted between interfaces, classes, packages, and
components to link a client element to the supplier element.

UML Association vs. Aggregation vs. Composition

In UML diagrams, relationships are used to link several things. It is a connection between structural,
behavioral, or grouping things. Following are the standard UML relationships enlisted below:

o Association
o Dependency
o Generalization
o Realization

Association
Association relationship is a structural relationship in which different objects are linked within the
system. It exhibits a binary relationship between the objects representing an activity. It depicts the
relationship between objects, such as a teacher, can be associated with multiple teachers.

It is represented by a line between the classes followed by an arrow that navigates the direction, and
when the arrow is on both sides, it is then called a bidirectional association. We can specify the
multiplicity of an association by adding the adornments on the line that will denote the association.

Page No: [ 6 ] Dr. Virendra Kumar Tiwari

 MCA & MAI-204: SE- UML UNIT-V

Example:

1) A single teacher has multiple students.

2) A single student can associate with many teachers.

The composition and aggregation are two subsets of association. In both of the cases, the object of one
class is owned by the object of another class; the only difference is that in composition, the child does
not exist independently of its parent, whereas in aggregation, the child is not dependent on its parent i.e.,
standalone. An aggregation is a special form of association, and composition is the special form of
aggregation.

Page No: [ 7 ] Dr. Virendra Kumar Tiwari

 MCA & MAI-204: SE- UML UNIT-V

Aggregation
Aggregation is a subset of association, is a collection of different things. It represents has a relationship.
It is more specific than an association. It describes a part-whole or part-of relationship. It is a binary
association, i.e., it only involves two classes. It is a kind of relationship in which the child is independent
of its parent.

For example:

Here we are considering a car and a wheel example. A car cannot move without a wheel. But the wheel
can be independently used with the bike, scooter, cycle, or any other vehicle. The wheel object can exist
without the car object, which proves to be an aggregation relationship.

Composition
The composition is a part of aggregation, and it portrays the whole-part relationship. It depicts
dependency between a composite (parent) and its parts (children), which means that if the composite is
discarded, so will its parts get deleted. It exists between similar objects.

As you can see from the example given below, the composition association relationship connects the
Person class with Brain class, Heart class, and Legs class. If the person is destroyed, the brain, heart, and
legs will also get discarded.

Page No: [ 8 ] Dr. Virendra Kumar Tiwari

 MCA & MAI-204: SE- UML UNIT-V

Association vs. Aggregation vs. Composition

Association Aggregation Composition

Association relationship is Aggregation relationship is The composition relationship is

represented using an arrow. represented by a straight line with represented by a straight line with a
an empty diamond at one end. black diamond at one end.

In UML, it can exist between It is a part of the association It is a part of the aggregation
two or more classes. relationship. relationship.

It incorporates one-to-one, It exhibits a kind of weak It exhibits a strong type of

one-to-many, many-to-one, relationship. relationship.
and many-to-many
association between the
classes.

It can associate one more In an aggregation relationship, the In a composition relationship, the
objects together. associated objects exist associated objects cannot exist
independently within the scope of independently within the scope of the
the system. system.

In this, objects are linked In this, the linked objects are Here the linked objects are dependent
together. independent of each other. on each other.

It may or may not affect the Deleting one element in the It affects the other element if one of
other associated element if aggregation relationship does not its associated element is deleted.
one element is deleted. affect other associated elements.

Example: A tutor can Example: A car needs a wheel for Example: If a file is placed in a folder
associate with multiple its proper functioning, but it may and that is folder is deleted. The file
students, or one student can not require the same wheel. It may residing inside that folder will also
associate with multiple function with another wheel as get deleted at the time of folder
teachers. well. deletion.

Page No: [ 9 ] Dr. Virendra Kumar Tiwari

 MCA & MAI-204: SE- UML UNIT-V

IDENTIFYING STATE AND BEHAVIOR

A state diagram is used to represent the condition of the system or part of the system at finite
instances of time. It’s a behavioral diagram and it represents the behavior using finite state
transitions. State diagrams are also referred to as State machines and State-chart Diagrams.
These terms are often used interchangeably. So simply, a state diagram is used to model the
dynamic behavior of a class in response to time and changing external stimuli. We can say that
each and every class has a state but we don’t model every class using State diagrams. We
prefer to model the states with three or more states.
Uses of statechart diagram –
• We use it to state the events responsible for change in state (we do not show what
processes cause those events).
• We use it to model the dynamic behavior of the system .
• To understand the reaction of objects/classes to internal or external stimuli.
Firstly let us understand what are Behavior diagrams? There are two types of diagrams in
UML :
1. Structure Diagrams – Used to model the static structure of a system, for example-
class diagram, package diagram, object diagram, deployment diagram etc.
2. Behavior diagram – Used to model the dynamic change in the system over time.
They are used to model and construct the functionality of a system. So, a behavior
diagram simply guides us through the functionality of the system using Use case
diagrams, Interaction diagrams, Activity diagrams and State diagrams.
Difference between state diagram and flowchart –
The basic purpose of a state diagram is to portray various changes in state of the class and not
the processes or commands causing the changes. However, a flowchart on the other hand
portrays the processes or commands that on execution change the state of class or an object of
the class.

Figure – a state diagram for user verification

The state diagram above shows the different states in which the verification sub-system or
class exist for a particular system.

Basic components of a state chart diagram –

Page No: [ 10 ] Dr. Virendra Kumar Tiwari

 MCA & MAI-204: SE- UML UNIT-V

1. Initial state – We use a black filled circle represent the initial state of a System or a
class.

Figure – initial state notation

2. Transition – We use a solid arrow to represent the transition or change of control
from one state to another. The arrow is labelled with the event which causes the
change in state.

Figure – transition
3. State – We use a rounded rectangle to represent a state. A state represents the
conditions or circumstances of an object of a class at an instant of time.

Figure – state notation

4. Fork – We use a rounded solid rectangular bar to represent a Fork notation with
incoming arrow from the parent state and outgoing arrows towards the newly
created states. We use the fork notation to represent a state splitting into two or more
concurrent states.

Figure – a diagram using the fork notation

5. Join – We use a rounded solid rectangular bar to represent a Join notation with
incoming arrows from the joining states and outgoing arrow towards the common
goal state. We use the join notation when two or more states concurrently converge
into one on the occurrence of an event or events.

Page No: [ 11 ] Dr. Virendra Kumar Tiwari

 MCA & MAI-204: SE- UML UNIT-V

Figure – a diagram using join notation

6. Self transition – We use a solid arrow pointing back to the state itself to represent a
self transition. There might be scenarios when the state of the object does not
change upon the occurrence of an event. We use self transitions to represent such
cases.

Figure – self transition notation

7. Composite state – We use a rounded rectangle to represent a composite state
also.We represent a state with internal activities using a composite state.

Figure – a state with internal activities

8. Final state – We use a filled circle within a circle notation to represent the final
state in a state machine diagram.

Figure – final state notation

Steps to draw a state diagram –

1. Identify the initial state and the final terminating states.

2. Identify the possible states in which the object can exist (boundary values
corresponding to different attributes guide us in identifying different states).

Page No: [ 12 ] Dr. Virendra Kumar Tiwari

 MCA & MAI-204: SE- UML UNIT-V

3. Label the events which trigger these transitions.

Example – state diagram for an online order –

Figure – state diagram for an online order

The UMl diagrams we draw depend on the system we aim to represent. Here is just an
example of how an online ordering system might look like :
1. On the event of an order being received, we transit from our initial state to
Unprocessed order state.
2. The unprocessed order is then checked.
3. If the order is rejected, we transit to the Rejected Order state.
4. If the order is accepted and we have the items available we transit to the fulfilled
order state.
5. However if the items are not available we transit to the Pending Order state.

Page No: [ 13 ] Dr. Virendra Kumar Tiwari

 MCA & MAI-204: SE- UML UNIT-V

6. After the order is fulfilled, we transit to the final state. In this example, we merge
the two states i.e. Fulfilled order and Rejected order into one final state.

Page No: [ 14 ] Dr. Virendra Kumar Tiwari

 MCA & MAI-204: SE- UML UNIT-V

UML Use Case Diagram

A use case diagram is used to represent the dynamic behavior of 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. 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 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.

How to draw a Use Case diagram?

It is essential to analyze the whole system before starting with drawing a use case diagram, and then the
system's functionalities are found. And once every single functionality is identified, they are then
transformed into the use cases to be used in the use case diagram.

After that, we will enlist the actors that will interact with the system. The actors are the person or a thing
that invokes the functionality of a system. It may be a system or a private entity, such that it requires an
entity to be pertinent to the functionalities of the system to which it is going to interact.

Once both the actors and use cases are enlisted, the relation between the actor and use case/ system is
inspected. It identifies the no of times an actor communicates with the system. Basically, an actor can
interact multiple times with a use case or system at a particular instance of time.

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

1. A pertinent and 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.

Page No: [ 15 ] Dr. Virendra Kumar Tiwari

 MCA & MAI-204: SE- UML UNIT-V

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.

Page No: [ 16 ] Dr. Virendra Kumar Tiwari

 MCA & MAI-204: SE- UML UNIT-V

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.

The Checkout use case involves Payment use case that can be done either by the credit card and external
credit payment services or with PayPal.

Page No: [ 17 ] Dr. Virendra Kumar Tiwari

 MCA & MAI-204: SE- UML UNIT-V

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.

Page No: [ 18 ] Dr. Virendra Kumar Tiwari

 MCA & MAI-204: SE- UML UNIT-V

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

Page No: [ 19 ] Dr. Virendra Kumar Tiwari

 MCA & MAI-204: SE- UML UNIT-V

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.

Page No: [ 20 ] Dr. Virendra Kumar Tiwari

 MCA & MAI-204: SE- UML UNIT-V

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.

Page No: [ 21 ] Dr. Virendra Kumar Tiwari

 MCA & MAI-204: SE- UML UNIT-V

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.

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.

Page No: [ 22 ] Dr. Virendra Kumar Tiwari

 MCA & MAI-204: SE- UML UNIT-V

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.

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.

Page No: [ 23 ] Dr. Virendra Kumar Tiwari

 MCA & MAI-204: SE- UML UNIT-V

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.

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.

Page No: [ 24 ] Dr. Virendra Kumar Tiwari

 MCA & MAI-204: SE- UML UNIT-V

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

Page No: [ 25 ] Dr. Virendra Kumar Tiwari

 MCA & MAI-204: SE- UML UNIT-V

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?

Page No: [ 26 ] Dr. Virendra Kumar Tiwari

 MCA & MAI-204: SE- UML UNIT-V

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.

Page No: [ 27 ] Dr. Virendra Kumar Tiwari