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
