Lecture 8 Modelling Using UML
Lecture 8 Modelling Using UML
Lecture 8
¨ What is modeling?
¨ What is UML?
¨ Use case diagrams
¨ Class diagrams
¨ Sequence diagrams
¨ Activity diagrams
What is modeling?
Actor
System boundary
Association
Class
Multiplicity
SimpleWatch
1 1 1 1
2 1 2 1
PushButton Display Battery Time
Association
Class
Multiplicity Watch
1 1 1 1
2
1 2 1
PushButton
state LCDDisplay Battery Time
blinkIdx Load Now
push() blinkSeconds()
release() blinkMinutes()
blinkHours()
stopBlinking()
Operations
Attribute referesh()
UML first pass: Sequence diagram
Transition button1Pressed
button1&2Pressed button2Pressed
Blink Increment
Minutes Minutes
State
button1Pressed
button2Pressed
Stop Blink Increment
Blinking Seconds Seconds
Final state
Name
Use Case
• A class of functionality provided by the
system
• Described textually, with a focus on the
event flow between actor and system
• The textual use case description consists of
6 parts:
1. Unique name
PurchaseTicket 2. Participating actors
3. Entry conditions
4. Exit conditions
5. Flow of events
6. Special requirements.
Textual Use Case Description Example
1. Name: Purchase ticket 5. Flow of events:
1. Passenger selects the
number of zones to be
2. Participating actor: traveled
Passenger 2. Ticket Distributor displays
the amount due
3. Entry condition: 3. Passenger inserts money, at
least the amount due
¨ Passenger stands in front of
4. Ticket Distributor returns
ticket distributor change
¨ Passenger has sufficient 5. Ticket Distributor issues
money to purchase ticket ticket
6. Special requirements: None
4. Exit condition:
¨ Passenger has ticket
Uses Cases can be related: <<extends>>
<<extends>> models exceptional
or seldom invoked cases
Exceptional event flows are
Passenger factored out of the main event
flow for clarity
Direction is to the extended use
case
PurchaseTicket Can extend more than one use
case.
<<extends>>
<<extends>>
<<extends>>
OutOfOrder <<extends>> TimeOut
Cancel NoChange
Uses Cases can be related: <<includes>>
<<includes>> represents
common functionality needed
in more than one use case
Passenger Behavior factored out for
reuse, not because it is an
exception
PurchaseMultiCard
Direction is to the using use
PurchaseSingleTicket case (unlike the direction of
<<includes>> the <<extends>> relationship).
<<includes>>
CollectMoney
<<extends>> <<extends>>
<<extends>>
TarifSchedule Trip
Table zone2price
zone:Zone
Enumeration getZones()
* * Price: Price
Price getPrice(Zone)
Classes Type
TarifSchedule
Table zone2price
Enumeration getZones()
Name Price getPrice(Zone)
TarifSchedule
zone2price Attributes Signature
getZones()
getPrice()
Operations TarifSchedule
¨ Actor
An entity outside the system to be modeled, interacting with the
system (“Passenger”)
¨ Class
An abstraction modeling an entity in the application or solution domain
The class is part of the system model (“User”, “Ticket distributor”,
“Server”)
¨ Object
A specific instance of a class (“Joe, the passenger who is purchasing a
ticket from the ticket distributor”).
Associations
TarifSchedule TripLeg
Country 1 1 City
name:String capitalname:String
1-to-1 association
Point
Polygon
* x: Integer
y: Integer
draw()
1-to-many association
Aggregation vs. Composition
¨ Aggregation (diamond): special case of association denoting a
“consists-of” hierarchy Exhaust system
¨ The aggregate is the parent class,
the components are the children classes
1 0..2
Muffler Tailpipe
TicketMachine diameter diameter
3
ZoneButton
Button
CancelButton ZoneButton
Account
Bank Customer
Foo
Amount
CustomerId
Deposit()
Withdraw()
GetBalance()
“Dada” Foo
Amount Amount
CustomerId CustomerId
Deposit() Deposit()
Withdraw() Withdraw()
GetBalance() GetBalance()
Account
Amount
CustomerId
Deposit()
Withdraw()
Is Foo the right name? GetBalance()
Object Modeling in Practice: More classes
Account
Amount Customer
Bank AccountId
Name
Name Deposit() CustomerId
Withdraw()
GetBalance()
Account
* Amount
AccountId * Customer
Bank CustomerId
AccountId owns
1..* Name
Name Deposit() CustomerId
Withdraw()
GetBalance()
selectZone()
¨ Used during analysis
to refine use case descriptions
to find additional objects
(“participating objects”)
insertCoins()
¨ Used during system design
to refine subsystem interfaces
¨ Instances are represented by
pickupChange() rectangles. Actors by sticky figures
¨ Lifelines are represented by dashed
lines
pickUpTicket() Messages are ¨ Messages are represented by arrows
Operations on ¨ Activations are represented by narrow
participating Object rectangles.
Sequence Diagrams can also model the Flow of Data
selectZone()
lookupPrice(selection)
price
displayPrice(price)
Dataflow
* insertChange(coin)
lookupCoin(coin)
price
Iteration displayPrice(owedAmount)
[owedAmount<0] returnChange(-owedAmount)
Condition
ChangeProcessor
Passenger Creation of Ticket
createTicket(selection)
Ticket
print()
free()
Destruction of Ticket
Decision
[lowPriority]
Open Allocate
Incident Resources
Notify
Police Chief
Activity Diagrams can model Concurrency
Allocate
Splitting Resources Synchronization
Document
Incident
Activity Diagrams: grouping
Allocate Dispatcher
Resources
FieldOfficer
Document
Incident