UML

[Unified Modeling Language]

 UML-Introduction
• This object-oriented system of notation has
evolved from the work of Grady Booch, James
Rumbaugh, Ivar Jacobson, and the Rational
Software Corporation.
• Today, UML is accepted by the Object
Management Group (OMG) as the standard
for modeling object oriented programs
• UML is a modeling language for Specifying,
Visualizing, Constructing and documenting
Object oriented Software
 UML Diagrams
• Classified based on Characteristics
– Static
• Usecase diagram[Scenario Based Element]
• Class diagram[Class Based Element]
– Dynamic
• Object diagram
• State diagram[Behavioral Element]
• Activity diagram[Scenario Based Element]
• Sequence diagram[Behavioral Element]
• Collaboration diagram[Class Based Element]
– Implementation
• Component diagram
• Deployment diagram
 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,
and Associations.
• Sequence diagrams
– Describe the dynamic behavior between actors and the system
and between objects of the system.
• Statechart diagrams
– Describe the dynamic behavior of an individual object as a
finite state machine.
• Activity diagrams
– Model the dynamic behavior of a system, in particular the
workflow, i.e. a flowchart. 4
 Use Case Diagram
Package
SimpleWatch

Actor
ReadTime

SetTime
WatchUser WatchRepairPerson

Use case
ChangeBattery

Use case diagrams represent the functionality of the system

from user’s point of view

5
 Class Diagram

Class

Multiplicity SimpleWatch Association

1 1 1 1
2 1 2 1
PushButton LCDDisplay Battery Time
state blinkIdx load() now()
push() blinkSeconds()
release() blinkMinutes()
blinkHours()
stopBlinking()
Attributes
referesh()

Operations

Class diagrams represent the structure of the system

6
 UML Core Conventions
• Rectangles are classes or instances
• Ovals are functions or use cases
• Instances are denoted with an underlined
names
– myWatch:SimpleWatch
– Joe:Firefighter

9
 UML Core Conventions
• Types are denoted with nonunderlined
names
– SimpleWatch
– Firefighter
• Diagrams are graphs
– Nodes are entities
– Arcs are relationships between entities

10
 Use Case Diagram

• Used during requirements elicitation to

represent external behavior
• Actors represent roles, that is, a 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 all use
cases. It is a complete description of the
functionality of the system & its environment

11
A Use Case Diagram

Passenger

PurchaseTicket

12
 Actor

• An actor models an external entity which communicates

with the system:
– User
– External system
– Physical environment
• 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

13
An Actor

Passenger

14
 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
– Entry conditions
– Flow of events
– Exit conditions
– Special requirements

15
A Use Case

PurchaseTicket

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

17
 The <<extend>> Relationship

• <<extend>> relationships represent exceptional or

seldom invoked cases.
• The exceptional event flows are factored out of
the main event flow for clarity.
• Use cases representing exceptional flows can
extend more than one use case.
• The direction of a <<extend>> relationship is to the
extended use case

18
 <<extend>> Relationships

Passenger

PurchaseTicket

<<extend>> <<extend>>

<<extend>> <<extend>>

OutOfOrder TimeOut

Cancel NoChange
19
The <<include>> Relationship

• An <<include>> relationship represents

behavior that is factored out of the use case.
• An <<include>> represents behavior that is
factored out for reuse, not because it is an
exception.
• The direction of a <<include>> relationship is to
the using use case (unlike <<extend>>
relationships).

20
 <<include>> Relationships

Passenger

PurchaseMultiCard

<<include>> PurchaseSingleTicket

<<include>>

CollectMoney
<<extend>>

<<extend>>
NoChange
Cancel
21
 Class Diagram

• Class diagrams represent the structure

of the system.
• Class diagrams are used
– during requirements analysis to model
problem domain concepts
– during system design to model subsystems
and interfaces
– during object design to model classes.

22
 A Class Diagram
TariffSchedule Trip
zone:Zone
Enumeration getZones() * price:Price
*
Price getPrice(Zone)

23
 Class
• A class represent a concept.
• A class encapsulates state (attributes)
& behavior (operations).
• Each attribute has a type.
• Each operation has a signature.
• The class name is the only mandatory
information.

24
 A Class

Name
TariffSchedule TariffSchedule
zone2price Table zone2price
Attributes
getZones() Enumeration getZones()
getPrice() Price getPrice(Zone)

Operations
Signature

25
 Instance

• An instance represents a phenomenon.

• The name of an instance is underlined
and can contain the class of the
instance.
• The attributes are represented with their
values.

26
 An Instance

tariff_1974:TarifSchedule
zone2price = {
{‘1’, .20},
{‘2’, .40},
{‘3’, .60}}

27
 Actor, Class, & Instance

• Actor:
– An entity outside the system to be modeled,
interacting with the system (“Pilot”)
• Class:
– An abstraction modeling an entity in the problem
domain, inside the system to be modeled (“Cockpit”)
• Object:
– A specific instance of a class (“Joe, the inspector”).

28
 Association

• Associations denote relationships between

classes.
• The multiplicity of an association end
denotes how many objects the source
object can legitimately reference.

29
 An Association
TarifSchedule TripLeg

Enumeration getZones() price

* *
Price getPrice(Zone) zone

30
 Associations
Has-capital
Country City
1 1
name:String name:String

1-to-1 association

Polygon 1 * Point
x:Integer
y:Integer
draw()

1-to-many association

31
 Aggregation

• An aggregation is a special case of

association denoting a “consists of”
hierarchy.
• The aggregate is the parent class, the
components are the children class.

32
Aggregations

Exhaust System

1 0..2
Muffler Tailpipe

33
 Composition

• A solid diamond denote composition,

• A strong form of aggregation
• Components cannot exist without the
aggregate.

34
 Composition

TicketMachine

3
ZoneButton

35
 Generalization

• Generalization relationships denote

inheritance between classes.
• The children classes inherit the
attributes and operations of the parent
class.
• Generalization simplifies the model by
eliminating redundancy.
36
 Generalization

Button

CancelButton ZoneButton

37
 From Problem Statement to
Code

Problem Statement

A stock exchange lists many companies. Each company is identified by a

ticker symbol

38
 From Problem Statement to
Code
Problem Statement:
A stock exchange lists many companies.
Each company is identified by a ticker
symbol

39
 From Problem Statement
to Code
Class Diagram

lists
StockExchange * * Company
tickerSymbol

Java Code
public class StockExchange {
public Vector m_Company = new Vector();
};
public class Company {
public int m_tickerSymbol;
public Vector m_StockExchange = new Vector();
};
40
 UML Sequence Diagram
• Used during requirements analysis
– To refine use case descriptions
– to find additional objects (“participating objects”)
• Used during system design
– to refine subsystem interfaces
• Classes are represented by columns
• Messages are represented by arrows
• Activations are represented by narrow
rectangles
• Lifelines are represented by dashed lines
41
A UML Sequence Diagram

TicketMachine
Passenger
selectZone()

insertCoins()

pickupChange()

pickUpTicket()

42
 UML Sequence Diagram
with Nested Messages

• The source of an arrow indicates the

activation which sent the message
• An activation is as long as all nested
activations

43
 A UML Sequence Diagram
with Nested Messages
selectZone()

price

ZoneButton TarifSchedule Display

Passenger

lookupPrice(selection)

displayPrice(price)
Dataflow

…to be continued...

44
 Sequence Diagram
Observations
• UML sequence diagram represent
behavior in terms of interactions.
• Complement the class diagrams which
represent structure.
• Useful to find participating objects.
• Time consuming to build but worth the
investment.

45
 Activity Diagram
• An activity diagram shows flow control within a system
• An activity diagram is a special case of a state chart
diagram in which states are activities (“functions”)
• Two types of states:
– Action state:
• Cannot be decomposed any further
• Happens “instantaneously” with respect to the level of abstraction
used in the model
– Activity state:
• Can be decomposed further
• The activity is modeled by another activity diagram

46
 An Activity Diagram

Handle Document Archive

Incident Incident Incident

47
 Activity Diagram:
Modeling Decisions

[lowPriority]
Open Allocate
Incident Resources

[fire & highPriority]

[not fire & highPriority]

Notify
Fire Chief

Notify
Police Chief

48
 Activity Diagram:
Modeling Concurrency

• Synchronization of multiple activities

• Splitting the flow of control into multiple
threads

49
 Activity Diagram:
Modeling Concurrency

Splitting Synchronization

Allocate
Resources

Open Coordinate Archive

Incident Resources Incident

Document
Incident

50
 Activity Diagrams: Swimlanes
• Actions may be grouped into swimlanes
• Denote the object or subsystem that
implements the actions.

51
Activity Diagrams: Swimlanes

Dispatcher
Allocate
Resources

Open Coordinate Archive

Incident Resources Incident

FieldOfficer
Document
Incident

52
 Summary
• UML provides a wide variety of notations for
representing many aspects of software
development
– Powerful, but complex language
– Can be misused to generate unreadable models
– Can be misunderstood when using too many exotic
features
• We concentrate only on a few notations:
– Functional model: use case diagram
– Object model: class diagram
– Dynamic model: sequence diagrams, statechart and
activity diagrams
53
 References
• M. Fowler, UML Distilled, 2nd edition, Addison
Wesley, 2000.
• G. Booch, J. Rumbaugh, and I. Jacobson, The
Unified Modeling Language User Guide,
Addison Wesley, 1999.
• B. Bruegge and A. Dutoit, Object-Oriented
Software Engineering Using UML, Patterns, and
Java, 2nd edition, Prentice Hall, 2004

54