Overview of the Unified Modeling Language

• UML is a standard language for specifying, visualizing,

constructing, and documenting the artifacts of software
systems.
• UML was created by Object Management Group and UML
1.0 specification draft was proposed to the OMG in January
1997.
• The Unified Modeling Language (UML) is a general-
purpose, developmental, modeling language in the field of
software engineering, that is intended to provide a standard
way to visualize the design of a system

Modeling with UML - KMU 1

• UML is a language that we use to model a reality. UML is a
language for
– Visualizing
– Specifying
– Constructing and
– Documenting the artifacts of a software system.

Modeling with UML - KMU 2

• UML as a Language for Visualizing - The vision for the system
being developed can be easily communicated through UML
and thus the software team has a unified vision of a system
that is only described in specification and requirement
documents.
– A picture is worth a thousand words; a graphical
notation articulates and unambiguously communicates
the overall view of the system (problem domain).
• UML as a Language for Specifying - the structure or behavior
of a system can be described with UML.
– i.e , UML provides the means to model precisely, unambiguously
and completely.

Modeling with UML - KMU 3

• UML as a Language for Constructing - UML’s models can be directly
connected or converted to a variety of programming languages like C++,
Java, or Visual Basic with no ambiguity. This facilitates forward
engineering.
– Models built with UML have a “design” dimension to it; these are
language independent and can be implemented in any programming
language.
• UML as a Language for Documenting - UML provides a language for
expressing requirements, tests, activities of project planning and release
management. Some of the artifacts that may need to be documented
are: Requirements, Architecture, Design, Source Code, Project Plan,
Tests, Prototypes, and Releases.
– Every software project involves a lot of documentation

Modeling with UML - KMU 4

Where can the UML be used?
• It has been used effectively for software intensive
domains such as –
1) Enterprise information systems
2) Banking and financial services
3) Telecommunications
4) Transportation
5) Defense / aerospace
6) Medical electronics
7) Distributed web-based services

Modeling with UML - KMU 5

Building Blocks of the UML
• The vocabulary of the UML encompasses three kinds of building
blocks:
1) Things
2) Relationships
3) Diagrams
• Things are the abstractions that are first-class citizens in a model
• Relationships tie these things together
• Diagrams group interesting collections of things.

Modeling with UML - KMU 6

Modeling with UML - KMU 7
 Things in the UML
• There are four kinds of things in the UML:
a) Structural things (static parts)
b) Behavioral things (dynamic parts)
c) Grouping things (Organizational parts of a model)
d) Annotational things (Explanatory parts of a model)

Modeling with UML - KMU 8

a) Structural Things
• Structural things are the nouns of the UML models. These are
mostly static parts of the model, representing conceptual or
physical elements.
• Structural things are called classifiers.
• Structural thing include classes, interfaces, collaborations, use
cases, components, and nodes.
• A class
– is a description of a set of objects that share the same
attributes, operations, relationships, and semantics.
– A class implements one or more interfaces. Graphically, a
class is rendered as a rectangle, usually including its name,
attributes, and operations

Modeling with UML - KMU 9

Class represents set of objects having similar responsibilities.

Modeling with UML - KMU 10

• Interface
– Interface defines a set of operations which specify the
responsibility of a class. Or
– is a collection of operations that specify a service of a class
or component.

Modeling with UML - KMU 11

• Collaboration:
– Collaboration defines interaction between elements.
– A given class or object might participate in several
collaborations
• A use case
– It’s a description of sequences of actions that a system
performs that yield observable results of value to a
particular actor.
– A use case is used to structure the behavioral things in a
model.

Modeling with UML - KMU 12

• Component
– Component describes physical part of a system.
– is a modular part of the system design that hides its
implementation behind a set of external interfaces.

Modeling with UML - KMU 13

• Node
– A node can be defined as a physical element that exists at
run time and represents a computational resource, generally
having at least some memory and, often, processing
capability.
– Examples: a server, network etc
– Graphically, a node is rendered as a cube, usually including
only its name as shown in the following figure

Modeling with UML - KMU 14

b) Behavioral Things

• Behavioral things are the dynamic parts of UML models.

• These are the verbs of a model , representing behavior over
time and space.
• There are three primary kinds of behavioral things:
– an interaction
– a state machine
– an activity
• An interaction is used to represent communication among the
components of a system.
• Interaction is basically message exchange between two UML
components.

Modeling with UML - KMU 15

• An interaction is a behavior that comprises a set of
messages exchanged among a set of objects or roles
within a particular context to accomplish a specific
purpose.
• Graphically, a message is rendered as a directed line,
including the name of its operation as shown below

Modeling with UML - KMU 16

• State machine describes the different states of a component in
its life cycle.
• The behavior of an individual class or a collaboration of classes
may be specified with a state machine.
• Graphically, a state is rendered as a rounded rectangle, usually
including its name and its substates

• A State machine is used to describe different states of a system

component.
• The state can be active, idle or any other depending upon the
situation.

Modeling with UML - KMU 17

• An activity is a behavior that specifies the sequence of
steps a computational process performs.
• In an interaction, the focus is on the set of objects that
interact.
• In a state machine, the focus is on the life cycle of one
object at a time.
• In an activity, the focus is on the flows among steps
without regard to which object performs each step.

Modeling with UML - KMU 18

c) Grouping Things

• Organizing the UML models are one of the most important

aspects of the design.
• Grouping things are the organizational parts of UML models.
• In UML there is only one element available for grouping and
that is package.
• Package
– A package is a general purpose mechanism for
organizing elements into groups. Structural things,
behavioral things, and even other grouping things may be
placed in a package.
– The packages are used to wrap the components of a system.

Modeling with UML - KMU 19

• Graphically a package is rendered as a tabbed folder,
usually including only its name and sometimes, its
contents.

Modeling with UML - KMU 20

d) Annotational things
• Annotational things are the explanatory parts of UML models.
• These are the comments you may apply to describe, illuminate,
and remark about any element in a model.
• There is one primary kind of annotational thing called a note.
• A note is simply a symbol for rendering constraints and
comments attached to an element or a collection of
elements
• Graphically, a note is rendered as a rectangle with a dog-eared
corner, together with a textual or graphical comment. It may be
anchored to an element with a dashed line.
The schedule can
MaintainSchedule be update

Modeling with UML - KMU 21

Relationships in the UML
• Objects do not exist in isolation, they exist in relationship to other
objects
• There are four kinds of relationships in the UML:
i. Dependency
ii. Associations
• Association
• Aggregation (special type of association)
• Composition(special type aggregation)
iii. Generalization
iv. Realization
• These relationships are the basic relational building blocks of the
UML.
• You use them to write well-formed models.

Modeling with UML - KMU 22

• Dependency relationship
– Dependency is an important aspect in UML elements. It
describes the dependent elements and the direction of
dependency.
– Dependency is a semantic relationship where a change in
one thing (the independent thing) causes a change in the
semantics of the other thing (the dependent thing).

Client class depends on the Supplier class.

Modeling with UML - KMU 23
– The notation used for dependency is a dashed line with an
arrowhead.
– The arrow head represents the independent element and
the other end the dependent element.

– Weakest class association. If something changes in

meeting then this would affect schedule but the reverse is
not true

Modeling with UML - KMU 24

Associations relation ships
• Association
– An association is a structural relationship that specifies
how objects (instances of classes) are connected to
other objects.
• describes how the elements in an UML diagrams are
associated.
– In simple word it describes how many elements are
taking part in an interaction.
– Association is represented by a line with (without)
arrows on both sides.

Modeling with UML - KMU 25

We can also indicate the behavior of an object in an
association (i.e., the role of an object) using role names.

Modeling with UML - KMU 26

• For example, as shown below, a Course Offering object
may have either zero or one Professor object related to it,
and conversely a Professor object may have zero or more
Course Offering objects related to it.

Modeling with UML - KMU 27

• Aggregation
– Aggregation indicates a relationship between a whole and its
parts
– Aggregation is a special kind of association, representing a
structural relationship between a whole and its parts.
– Has-a relationship
– The part can exist separately from the whole

Modeling with UML - KMU 28

• Composition
– Strong form of aggregation where the part can not exist
separately from the whole
– That means the construction and destruction of the part
depend on the whole

– A department is part of a company. The construction and

destruction of a department depends on the company

Modeling with UML - KMU 29

Generalization
• Generalization describes the inheritance relationship of the
object oriented world. It is parent and child relationship.
• A generalization is a specialization/generalization relationship in
which the specialized element (the child) builds on the
specification of the generalized element (the parent).
• Is -a kind-of relationship
• Relationship between a general thing and a more specific kind
of that thing (i.e super class and subclass)
• A child inherits + reuses the non private parent classes
attributes and operations.
• The child can have additional attributes and operation of its
own

Modeling with UML - KMU 30

Modeling with UML - KMU 31
Realization
• Realization can be defined as a relationship in which two
elements are connected.
• One element describes some responsibility which is not
implemented and the other one implements them.
• You'll encounter realization relationships in two places:
– between interfaces and the classes or components that
realize them,
– and between use cases and the collaborations that realize
them.
• Graphically, a realization relationship is rendered as a cross
between a generalization and a dependency relationship

Modeling with UML - KMU 32

Multiplicity
• Multiplicity is a definition of cardinality - i.e. number of
elements - of some collection of elements by providing an
inclusive interval of non-negative integers to specify the
allowable number of instances of described element.
Multiplicity interval has some lower bound and (possibly
infinite) upper bound
• Multiplicity allows us to specify how many objects are
participating in relationships
• It is the number of instances of one class that relate to one
instance of another class. For each association, there are two
multiplicity decisions to make, one for each end of the
association.
– How many objects are associated

Modeling with UML - KMU 33

Modeling with UML - KMU 34
As shown above, House has exactly one kitchen, one bath and one
bedroom
 kitchen, bath and bedroom exist only if the house exist(composition)
All kitchen, bath and bedroom are rooms(inheritance)

Modeling with UML - KMU 35

UML Diagrams
• Use case Diagrams
– Describe the functional behavior of the system as seen by
the user.
• Class diagrams
– Describe the static structure of the system: Objects,
Attributes, Associations
• Sequence diagrams
– Describe the dynamic behavior between actors and the
system and between objects of the system
• State chart diagrams
– Describe the dynamic behavior of an individual object
(essentially a finite state automaton)
• Activity Diagrams
– Model the dynamic behavior of a system, in particular the
workflow (essentially a flowchart)

Modeling with UML - KMU 36

UML: Use case diagrams
Package Use case
Watch

Actor
ReadTime

SetTime
WatchUser WatchRepairPerson

ChangeBattery

Use case diagrams represent the functionality of the system

from user’s point of view
Modeling with UML - KMU 37
 UML: Class diagrams
Class diagrams represent the structure of the system

Association
Class

Multiplicity Watch
1 1 1 1
2 1 2 1
PushButton LCDDisplay Battery Time
state blinkIdx load now
push() blinkSeconds(
release() )
blinkMinutes(
)
blinkHours()
stopBlinking(
)
Attribute referesh()
Operations

Modeling with UML - KMU 38

 UML: Sequence diagram
Actor Object

:Watch :LCDDisplay :Time

:WatchUser

pressButton1() blinkHours()
pressButton1() blinkMinutes()

Message pressButton2() incrementMinutes()

refresh()
pressButtons1And2()
commitNewTime()
stopBlinking()

Activation
Lifeline

Sequence diagrams represent the behavior as interactions

Modeling with UML - KMU 39
UML provide other notations
Implementation diagrams
– Component diagrams
– Deployment diagrams

Modeling with UML - KMU 40

Use Case Diagrams
• Used during requirements
elicitation to represent external
behavior
• Actors represent roles, that is, a
Passenger
type of user of the system
• Use cases represent a sequence
of interaction for a type of
functionality
• The use case model is the set of
PurchaseTicket
all use cases. It is a complete
description of the functionality of
the system and its environment

Modeling with UML - KMU 41

Actors • An actor models an external entity which
communicates with the system:
– User
– External system
– Physical environment
Passenger • An actor has a unique name and an optional
description.
• Examples:
– Passenger: A person in the train
– GPS satellite: Provides the system with GPS
coordinates

Modeling with UML - KMU 42

Use Case
A use case represents a class of functionality
provided by the system as an event flow.
A use case consists of:
• Unique name
• Participating actors
PurchaseTicket • Entry conditions
• Flow of events
• Exit conditions
• Special requirements

Modeling with UML - KMU 43

Use Case Diagram: Example
Name: Purchase ticket Event flow:
1. Passenger selects the number
Participating actor: Passenger of zones to be traveled.
2. Distributor displays the amount
Entry condition: due.
• Passenger standing in front of 3. Passenger inserts money, of at
ticket distributor. least the amount due.
• Passenger has sufficient 4. Distributor returns change.
money to purchase ticket. 5. Distributor issues ticket.

Exit condition:
• Passenger has ticket.
Anything missing ?

Exceptional cases!
Modeling with UML - KMU 44
 The <<extends>> Relationship
• <<extends>> relationships represent
exceptional or seldom invoked cases.
• The exceptional event flows are factored
Passenger
out of the main event flow for clarity.
• Use cases representing exceptional
flows can extend more than one use
case.
PurchaseTicket
• The direction of a <<extends>>
<<extends>>
relationship is to the extended use case

<<extends>>
<<extends>>

OutOfOrder <<extends>> TimeOut

Cancel NoChange
Modeling with UML - KMU 45
 The <<includes>> Relationship
• <<includes>> relationship
represents behavior that is
Passenger factored out of the use case.
• <<includes>> behavior is
factored out for reuse, not
PurchaseMultiCard because it is an exception.

PurchaseSingleTicket • The direction of a

<<includes>> <<includes>> relationship is
<<includes>> to the using use case (unlike
<<extends>> relationships).

CollectMoney
<<extends>> <<extends>>

NoChange Cancel
Modeling with UML - KMU 46
Class Diagrams

TarifSchedule
Trip
Enumeration getZones() zone:Zone
* *
Price getPrice(Zone) Price: Price

• Class diagrams represent the structure of the system.

• Used
– during requirements analysis to model problem domain
concepts
– during system design to model subsystems and interfaces
– during object design to model classes.

Modeling with UML - KMU 47