Chapter Two

Unified Modeling Language

(UML)
 Introduction
⚫ UML is a notation that resulted from the
unification of OMT(Object Modeling Technique).
⚫ The goal of UML is to provide a standard notation
that can be used by all object-oriented methods
and to select and integrate the best elements of
precursor notations(OMT & OOSE)
⚫ For example, UML includes the use case diagrams
introduced by OOSE and uses many features of the OMT
class diagrams.
⚫ UML also includes new concepts that were not
present in other major methods at the time, such
as extension mechanisms and a constraint
language.
⚫ Hence, UML provides constructs for a broad range of systems
and activities (e.g., distributed systems, analysis, system
design, deployment).
⚫ System development focuses on three different models of the
system.
⚫ The functional model, represented in UML with use case
diagrams, describes the functionality of the system from the
user’s point of view.
⚫ The object model, represented in UML with class
diagrams, describes the structure of the system in terms of
objects, attributes, associations, and operations.
⚫ The dynamic model, represented in UML with interaction
diagrams, state diagrams, and activity diagrams, describes
the internal behavior of the system.
⚫ UML focuses on standard modeling
language and not a standard process.
⚫ It focuses the concept of Booch,
Rambaugh and Jacobson.
⚫ The UML is a standard graphical design for
object oriented graphical design and a
medium for presenting important analysis
and design concepts.
 UML-Building Blocks
⚫ UML is composed of three main building blocks, i.e.
things, relationships, and diagrams.
⚫ Building blocks generate one complete UML model
diagram by rotating around several different blocks. It
plays an essential role in developing UML diagrams.
⚫ Things
⚫ Anything that is a real world entity or object is termed
as things. It can be divided into several different
categories:
− Structural things
− Behavioral things
− Grouping things
− Annotational things
⚫ Structural things
⚫ depict the static behavior of a model.
⚫ They display the physical and conceptual
components. They include class, object,
interface, node, collaboration, component,
and a use case.
⚫ Class: A Class is a set of identical things
that outlines the functionality and properties
of an object. It also represents the abstract
class whose functionalities are not defined.
⚫ Object: An individual that describes the
behavior and the functions of a system.
The notation of the object is similar to
that of the class; the only difference is
that the object name is always
underlined.
⚫ Interface: A set of operations that describes the
functionality of a class, which is implemented
whenever an interface is implemented.
⚫ Collaboration: It represents the interaction
between things that is done to meet the goal. It is
symbolized as a dotted ellipse with its name
written inside it.
⚫ Use case: Use case is the core concept of
object-oriented modeling. It portrays a set of
actions executed by a system to achieve the
goal.
➢ Actor: It comes under the use case
diagrams. It is an object that interacts with
the system, for example, a user.
⚫ Component: It represents the physical part of
the system.
⚫ Node: A physical element that exists at run
time.
⚫ Behavioral Things
⚫ They are the verbs that encompass the dynamic
parts of a model. It depicts the behavior of a
system. They involve state machine, activity
diagram, interaction diagram, grouping things,
annotation things
⚫ Grouping Things
It is a method that together binds the elements of
the UML model. In UML, the package is the only
thing, which is used for grouping.
⚫ Package: Package is the only thing that is
available for grouping behavioral and
structural things.
⚫ Annotation Things
⚫ It is a mechanism that captures the remarks,
descriptions, and comments of UML model
elements. In UML, a note is the only Annotational
thing.
⚫ Note: It is used to attach the constraints,
comments, and rules to the elements of the model.
It is a kind of yellow sticky note.
 UML Diagrams

⚫ Use Case Diagrams

⚫ Class Diagrams
⚫ Package Diagrams
⚫ Interaction Diagrams
− Sequence
− Collaboration
⚫ Activity Diagrams
⚫ State Transition Diagrams
⚫ Deployment Diagram
 USE CASE DIAGRAMS

⚫ Use-cases are descriptions of the functionality

of a system from a user perspective.
− Depict the behavior of the system,as it appears to
an outside user.
− Describe the functionality and users(actors) of the
system.
− Show the relationships between the actors that
use the relationship between different use cases.
 − Document the scope of the system.
− Illustrate the developer’s understanding
of the user’s requirements.
⚫ A use case diagram at its simplest is a
representation of a user's interaction with
the system that shows the relationship
between the user and the different use
cases.
 Components of use case diagram

1. Actor
2.Use case
3.System boundary
4. Relationship
⚫ Actor

⚫ An actor instance is someone or something outside

the system that interacts with the system.
⚫ An actor is anything that exchanges data with the
system.
⚫ An actor can be a user, external hardware, or
another system.
 Documenting Actor Characteristics
⚫ Brief Description:
⚫ What or who the actor represents?
⚫ Why the actor is needed?
⚫ What interests the actor has in the system?
⚫ Actor characteristics might influence how the
system is developed:
⚫ The actor's scope of responsibility.
⚫ The physical environment in which the actor will
be using the system.
⚫ The number of users represented by this actor.
 How to Find Use Cases

⚫ What are the system tasks for each actor you have
identified?
⚫ Does the actor need to be informed about certain
occurrences in the system?
⚫ Will the actor need to inform the system about sudden,
external changes?
⚫ Does the system supply the business with the correct
behavior?
⚫ Can all features be performed by the use cases you have
identified?
⚫ What use cases will support and maintain the system?
⚫ What information must be modified or created in the
system?
 System Boundary

⚫ It is shown as a rectangle.
⚫ It helps to identify what is external versus
internal, and what the responsibilities of the
system are.
⚫ The external environment is represented only
by actors.
 Relationship

⚫ Relationship is an association between use

case and actor.
⚫ There are several Use Case relationships:
⚫ Association
⚫ Extend
<<extend>>
------------------->
⚫ Generalization
⚫ Uses << uses >>

<<include>>
⚫ Include --------------------->
⚫ Association: communication between an
actor and a use case; Represented by a solid
line.
⚫ Generalization: relationship between one
general use case and a special use case
(used for defining special alternatives)
− Represented by a line with a triangular arrow
head toward the parent use case.
⚫ Include relationships insert additional behavior
into a base use case.
⚫ use cases that are included as parts of other
use cases.
⚫ Supports reuse of functionality.
⚫ The base use case is incomplete without the
included use case.
⚫ The included use case is mandatory not
optional.

⚫ The extended relationship is used to indicate

that use case completely consists of the
behavior of another use case at one or specific
point.
⚫ use cases that extend the behavior of other
core use cases.
⚫ Adds more functionality to the system.
⚫ The extending use case is dependent on the
extended (base) use case.
⚫ The extending use case is usually optional and
triggered conditionally.
⚫ It is shown as a dotted line with an arrow
pointing toward the base use case and labeled
<<extend>>
 Use case Description

⚫ :Each use case may include all or part of the following

− Title or Reference Name - meaningful name of the UC
− Author/Date - the author and creation date
− Modification/Date - last modification and its date
− Purpose - specifies the goal to be achieved
− Overview - short description of the processes
− Cross References - requirements references
− Actors - agents participating
− Pre Conditions - must be true to allow execution
− Post Conditions - will be set when completes normally
− Normal flow of events - regular flow of activities
− Alternative flow of events - other flow of activities
− Exceptional flow of events - unusual situations
⚫ Example- Money Withdraw
⚫ Use Case:Withdraw Money
⚫ Author: Group 3
⚫ Date: 20-03-2020
⚫ Purpose: To withdraw some cash from user’s bank account
⚫ Overview: The use case starts when the customer inserts his card into
the system. The system requests the user PIN. The system validates
the PIN. If the validation succeeded, the customer can choose the
withdraw operation else alternative 1 – validation failure is executed.
The customer enters the amount of cash to withdraw. The system
checks the amount of cash in the user account, its credit limit. If the
withdraw amount in the range between the current amount + credit
limit the system dispense the cash and prints a withdraw receipt, else
alternative 2 – amount exceeded is executed.
⚫ Cross References: R1.1, R1.2, R7
⚫ Actors: Customer
⚫ Pre Condition:
− The ATM must be in a state ready to accept transactions
− The ATM must have at least some cash on hand that it can
dispense
− The ATM must have enough paper to print a receipt for at
least one transaction
⚫ Post Condition:
− The current amount of cash in the user account is the
amount before the withdraw minus the withdraw amount
− A receipt was printed on the withdraw amount
− The withdraw transaction was audit in the System log file
⚫ Typical course of events
⚫
⚫ Alternative flow of events:
− Step 3: Customer authorization failed. Display an error
message, cancel the transaction and eject the card.
− Step 8: Customer has insufficient funds in its account.
Display an error message,and go to step6.
− Step 8: Customer exceeds its legal amount. Display
an error message, and go to step6.
⚫ Exceptional flow of events:
− Power failure in the process of the transaction before
step 9, cancel the transaction and eject the card
 Class diagram

⚫ Used for describing structure and behavior

in the use cases.
⚫ Provides a conceptual model of the system
in terms of entities and their relationships.
⚫ Used for requirement capture, end-user
interaction.
⚫ Detailed class diagrams are used for
developers.
 Class representation

⚫ Each class is represented by a rectangle subdivided into

three compartments
− Name
− Attributes
− Operations
⚫ Modifiers are used to indicate visibility of attributes and
operations.
− ‘+’ is used to denote Public visibility (everyone)
− ‘#’ is used to denote Protected visibility (friends and derived)
− ‘-’ is used to denote Private visibility (no one)
⚫ By default, attributes are hidden and operations are
visible.
 OO Relationships

⚫ There are two kinds of Relationships

− Generalization (parent-child relationship)
− Association (student enrolls in course)
⚫ Associations can be further classified as
− Aggregation
− Composition
 Generalization
⚫ Generalization expresses a parent/child relationship among related
classes.
⚫ Used for abstracting details in several layers.
 Association

⚫ Represent relationship between instances of

classes
− Student enrolls in a course
− Courses have students
− Courses have exams
⚫ Association has two ends
− Role names (e.g. enrolls)
− Multiplicity (e.g. One course can have many
students)
− Navigability (unidirectional, bidirectional)
Association: Multiplicity and Roles
⚫ Association: Model to Implementation

⚫ Class Student {
− Course enrolls[4];
⚫ }
⚫ Class Course {
− Student have[];
⚫ }
 OO Relationships: Composition

⚫ Composition: expresses a
relationship among instances of
related classes.
⚫ It is a specific kind of Whole-Part
relationship.
⚫ It expresses a relationship where
an instance of the Whole-class
has the responsibility to create
and initialize instances of each
Part class.
⚫ It may also be used to express a
relationship where instances of
the Part-classes have privileged
access or visibility to certain
attributes and/or behaviors
defined by the Whole-class.
 OO Relationships:Aggregation

⚫ Aggregation: expresses a
relationship among instances of
related classes.
⚫ It is a specific kind of Container –
Containee relationship
⚫ It expresses a relationship where an
instance of the Container-class has
the responsibility to hold and
maintain instances of each
Containee-class that have been
created outside the Container-class.
⚫ used to express a more informal
relationship than composition
expresses.
⚫ is appropriate when Container and
Containees have no special access
privileges to each other.
 Aggregation vs. Composition

⚫ Composition is really a strong form of aggregation

− components have only one owner
− components cannot exist independent of their owner
− components live or die with their owner
− e.g. Each car has an engine that can not be shared with
other cars.
⚫ Aggregations may form "part of" the aggregate, but
may not be essential to it. They may also exist
independent of the aggregate.
− e.g. Apples may exist independent of the bag.
 Sequence Diagram
⚫ Sequence diagram emphasizes on time
sequence of messages and collaboration
diagram emphasizes on the structural
organization of the objects that send and
receive messages.
⚫ The purposes of interaction diagram can be
describes as:
− To capture dynamic behavior of a system.
− To describe the message flow in the system.
− To describe structural organization of the objects.
− To describe interaction among objects.
⚫ The following factors are to be identified
clearly before drawing the interaction
diagram:
− Objects taking part in the interaction.
− Message flows among the objects.
− The sequence in which the messages are
flowing.
− Object organization.
Sequence Diagram
 Sequence Diagrams – Object
Life Spans
⚫ Creation
− Create message
− Object life starts at that
point
⚫ Activation
− Symbolized by rectangular
stripes
− Place on the lifeline where
object is activated.
− Rectangle also denotes
when object is deactivated.
⚫ Deletion
− Placing an ‘X’ on lifeline
− Object’s life ends at that
point
 Collaboration Diagram

⚫ A collaboration diagram also shows the passing

of messages between objects, but focuses on
the objects and messages and their order
instead of the time sequence.
⚫ The sequence of interactions and the concurrent
threads are identified using sequence numbers.
⚫ A collaboration diagram shows an interaction
the relationships among the objects playing the
different roles.
Phone call
 State chart Diagrams

⚫ A State chart diagram describes a state

machine.
⚫ State machine can be defined as a machine
which defines different states of an object
and these states are controlled by external
or internal events.
Purpose of State chart Diagrams

⚫ To model the dynamic aspect of a system.

⚫ To model the life time of a reactive system
(a system that responds to external or
internal events.).
⚫ To describe different states of an object
during its life time.
⚫ Define a state machine to model the states
of an object.
 How to Draw a State chart
Diagram?
⚫ Before drawing a State chart 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 State chart 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
 Activity Diagram
⚫ Activity diagram is basically a flow chart to represent the
flow form one activity to another activity.
⚫ The activity can be described as an operation of the
system.
⚫ So the control flow is drawn from one operation to
another.
⚫ This flow can be sequential, branched or concurrent.
⚫ Activity diagrams deals with all type of flow control by
using different elements like fork, join etc.
⚫ The basic purposes of activity diagrams are similar to
other four diagrams.
⚫ It captures the dynamic behavior of the system.
⚫ Other four diagrams are used to show the message
flow from one object to another but activity diagram
is used to show message flow from one activity to
another.
⚫ Activity diagrams are not only used for visualizing
dynamic nature of a system but they are also used
to construct the executable system by using
forward and reverse engineering techniques.
⚫ The only missing thing in activity diagram is the
message part.
 How to draw Activity Diagram?

⚫ Activity diagrams are mainly used as a flow

chart consists of activities performed by the
system.
⚫ So before drawing an activity diagram we
should identify the following elements:
− Activities
− Association
− Conditions
− Constraints
⚫ Example : order
management
system
− Send order by the
customer
− Receipt of the
order
− Confirm order
− Dispatch order
 Uses of Activity Diagrams

⚫ Modeling work flow by using activities.

⚫ Modeling business requirements.
⚫ High level understanding of the system's
functionalities.
⚫ Investigate business requirements at a
later stage.
Example: ATM system
 Component Diagram

⚫ Component diagrams are different in terms of

nature and behavior.
⚫ Component diagrams are used to model the
physical aspects of a system.
⚫ Physical aspects are the elements such as
executables, libraries, files, documents, etc. which
reside in a node.
⚫ Component diagrams are used to visualize the
organization and relationships among components
in a system. These diagrams are also used to
make executable systems.
 How to Draw a Component Diagram?

⚫ Component diagrams are used during the implementation

phase of an application. However, it is prepared well in
advance to visualize the implementation details.
⚫ Before drawing a component diagram, the following artifacts
are to be identified clearly
− Files used in the system.
− Libraries and other artifacts relevant to the application.
− Relationships among the artifacts.
⚫ After identifying the artifacts, the following points need to be
kept in mind.
− Use a meaningful name to identify the component for which the
diagram is to be drawn.
− Prepare a mental layout before producing the using tools.
− Use notes for clarifying important points.
⚫ 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.
⚫ In the following diagram, four files are
identified and their relationships are produced.
⚫ Component diagram cannot be matched
directly with other UML diagrams discussed
so far as it is drawn for completely different
purpose.
⚫ 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.
⚫ Deployment diagrams are used to describe the
static deployment view of a system. Deployment
diagrams consist of nodes and their relationships.
⚫ They are used for describing the hardware
components, where software components are
deployed. Component diagrams and deployment
diagrams are closely related.
⚫ 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 run time 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 control flows from the caching server to
the clustered environment.
⚫ 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.
⚫ 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.