CS F213 Object Oriented Programming

Unified Modelling Language

Aritra Mukherjee, Dept. of CSIS

Introduction
● The unified modeling language
(UML) is a general-purpose visual
modeling language that is
intended to provide a standard
way to visualize the design of a
system
● UML is not a programming
language, it is rather a visual
language.
History
● It was developed at Rational Software in 1994–1995, with further
development led by them through 1996.
● In 1997, UML was adopted as a standard by the Object Management
Group (OMG) and has been managed by this organization ever since.
● In 2005, UML was also published by the International Organization for
Standardization (ISO) and the International Electrotechnical Commission
(IEC) as the ISO/IEC 19501 standard. Since then the standard has been
periodically revised to cover the latest revision of UML
UML 2.x
● The Superstructure that defines the notation and semantics for diagrams
and their model elements
● The Infrastructure that defines the core metamodel on which the
Superstructure is based
● The Object Constraint Language (OCL) for defining rules for model
elements
● The UML Diagram Interchange that defines how UML 2 diagram layouts
are exchanged
UML family
Structure Diagrams
Structure diagrams represent the
static aspects of the system. It
emphasizes the things that must be
present in the system being modeled.
Since structure diagrams represent
the structure, they are used
extensively in documenting the
software architecture of software
systems. example: class diagram
Behaviour Diagrams
Behavior diagrams represent the
dynamic aspect of the system. It
emphasizes what must happen in the
system being modeled. Since
behavior diagrams illustrate the
behavior of a system, they are used
extensively to describe the
functionality of software
systems.example: use case diagram
Interaction Diagrams
Interaction diagrams, a subset of
behavior diagrams, emphasize the
flow of control and data among the
things in the system being modeled.
example: sequence diagram
Groups
Class Diagrams
Class is represented in a box where
The class diagram is the main
building block of object-oriented ● The top compartment contains the
name of the class printed in bold
modeling. It is used for general and centered, first letter is
conceptual modeling of the structure capitalized.
of the application, and for detailed ● The middle compartment contains
the attributes of the class,
modeling, translating the models into left-aligned, first letter is lowercase.
programming code. ● The bottom compartment contains
the operations the class can
execute, left-aligned, first letter is
lowercase.
Class Diagrams
Visibility Relationships Multiplicity
Component Diagrams
A component diagram component
depicts how components interface
ball and socket
are wired together to form
larger components or
software systems. They
are used to illustrate the
structure of arbitrarily
complex systems.
Composite Structure Diagrams
Composite structure diagram is a type of static structure diagram that shows
the internal structure of a class and the collaborations that this structure
makes possible. It uses parts, ports and connectors.
Deployment Diagrams
A deployment diagram “specifies
constructs that can be used to define
the execution architecture of
systems and the assignment of
software artifacts to system
elements”.
a deployment diagram would show
what hardware components
("nodes") exist, what software
components ("artifacts") run on each
node, and how the different pieces
are connected
Object Diagrams
An object diagram is a graph of
instances, including objects and data
values. A static object diagram is an
instance of a class diagram; it shows
a snapshot of the detailed state of a
system at a point in time. The use of
object diagrams is fairly limited,
namely to show examples of data
structure.

Rules are same as class diagram

Package Diagrams
Package diagrams can use packages
containing use cases to illustrate the
functionality of a software system.

Package diagrams can use packages

that represent the different layers of a
software system to illustrate the layered
architecture of a software system. The
dependencies between these packages
can be adorned with labels / stereotypes
to indicate the communication
mechanism between the layers.
Profile Diagrams
A profile diagram operates at the
metamodel level to show stereotypes
as classes with the «stereotype»
stereotype, and profiles as packages
with the «profile» stereotype. The
extension relation (solid line with
closed, filled arrowhead) indicates
what metamodel element a given
stereotype is extending.
Activity Diagrams
Activity diagrams are graphical
representations of workflows of
stepwise activities and actions with
support for choice, iteration, and
concurrency.

Activity diagrams primarily show the

overall control flow, they can also
include elements showing the data
flow between activities through one
or more data stores
State Machine Diagrams
The state machine diagram is also
called the Statechart or State
Transition diagram, which shows the
order of states underwent by an
object within the system. It captures
the software system's behavior. It
models the behavior of a class, a
subsystem, a package, and a
complete system.
Use case Diagrams
A use case diagram is a graphical
depiction of a user's possible
interactions with a system. A use
case diagram shows various use
cases and different types of users
the system has and will often be
accompanied by other types of
diagrams as well. The use cases are
represented by either circles or
ellipses. The actors are often shown
as stick figures
Communication Diagrams
A Communication diagram models
the interactions between objects or
parts in terms of sequenced
messages. Communication diagrams
represent a combination of
information taken from Class,
Sequence, and Use Case Diagrams
describing both the static structure
and dynamic behavior of a system.
Interaction Diagrams
The interaction overview diagram is
similar to the activity diagram, in that
both visualize a sequence of
activities. The difference is that, for
an interaction overview, each
individual activity is pictured as a
frame which can contain a nested
interaction diagram. This makes the
interaction overview diagram useful
to "deconstruct a complex scenario
that would otherwise require multiple
if-then-else paths to be illustrated as
a single sequence diagram"
Sequence Diagrams
A sequence diagram shows process
interactions arranged in time
sequence. This diagram depicts the
processes and objects involved and
the sequence of messages
exchanged as needed to carry out the
functionality.

Sequence diagrams are sometimes

called event diagrams or event
scenarios.
Timing Diagrams
Timing diagrams are used to explore
the behaviors of objects throughout a
given period of time. A timing
diagram is a special form of a
sequence diagram. The differences
between timing diagram and
sequence diagram are the axes are
reversed so that the time increases
from left to right and the lifelines are
shown in separate compartments
arranged vertically.
When to use what?
There is no specific order of using
different UML diagrams. Also you
may not need all the forms. The
usage and order completely depends
on the type of project being worked
on.