02 Modeling With UML UC AND CLASS
02 Modeling With UML UC AND CLASS
0
Use case
1
UML Use Case Diagrams
Used during requirements elicitation
and analysis to represent external
behavior (“visible from the outside of
the system”)
An Actor represents a role, that is, a type
of user of the system
Passenger
A use case represents a class of
functionality provided by the
system
Use case model:
The set of all use cases that
PurchaseTicket completely describe the
functionality of the system.
2
Actors
• An actor is a model for an external entity which
interacts (communicates) with the system:
• User
• External system (Another system)
• Physical environment (e.g. Weather)
• An actor has a unique name and an optional
Passenger description
• Examples: Optional
Description
• Passenger: A person in the train
• GPS satellite: An external system that provides the
system with GPS coordinates.
Name
3
Use Case
• A use case represents a class of functionality
provided by the system
• Use cases can be described textually, with a
focus on the event flow between actor and
system
• The textual use case description consists of 6
PurchaseTicket parts:
1. Unique name
2. Participating actors
3. Entry conditions
4. Exit conditions
5. Flow of events
6. Special requirements.
4
Textual Use Case
Description Example Passenger
PurchaseTicket
5
Uses Cases can be related
• Extends Relationship
• To represent seldom invoked use cases or exceptional functionality
• Includes Relationship
• To represent functional behavior common to more than one use case.
• Communicates (association)
• The behavioral relationship communicates is used to connect an actor
to a use case.
• Generalizes.
• The generalizes relationship implies that one thing is more typical
than the other thing.
6
Use Case Relationships
7
Includes
8
Extends
9
The <<extends>> Relationship
• <<extends>> relationships model
exceptional or seldom invoked cases
• The exceptional event flows are
factored out of the main event flow for
Passenger clarity
• The direction of an <<extends>>
relationship is to the extended use case
• Use cases representing exceptional
PurchaseTicket flows can extend more than one use
case.
<<extends>>
<<extends>>
<<extends>>
OutOfOrder <<extends>> TimeOut
Cancel NoChange
10
The <<includes>> Relationship
• <<includes>> relationship
represents common
functionality needed in more
Passenger
than one use case
• <<includes>> behavior is
PurchaseMultiCard
factored out for reuse, not
PurchaseSingleTicket because it is an exception
<<includes>>
<<includes>>
• The direction of a
<<includes>> relationship is
to the using use case (unlike
CollectMoney <<extends>> the direction of the
<<extends>>
<<extends>> <<extends>> relationship).
11
12
13
14
15
16
17
Class Diagrams
TarifSchedule Trip
Table zone2price
zone:Zone
Enumeration getZones()
Price getPrice(Zone)
* * Price: Price
18
Classes Type
TarifSchedule
Table zone2price
Enumeration getZones()
Name Price getPrice(Zone)
TarifSchedule
zone2price Attributes Signature
getZones()
getPrice()
Operations TarifSchedule
TarifSchedule TripLeg
Country 1 1 City
name:String name:String
1-to-1 association
Point
Polygon
* x: Integer
y: Integer
draw()
1-to-many association
22
Many-to-Many Associations
Company
StockExchange * * tickerSymbol
23
From Problem Statement To Object Model
Class Diagram:
StockExchange * * Company
Lists
tickerSymbol
24
From Problem Statement to Code
Problem Statement : A stock exchange lists many companies.
Each company is identified by a ticker symbol
Class Diagram:
StockExchange * * Company
Lists tickerSymbol
25
Aggregation
• An aggregation is a special case
of association denoting a Exhaust system
“consists-of” hierarchy
• The aggregate is the parent class, 1 0..2
the components are the children Muffler Tailpipe
classes diameter diameter
3
ZoneButton
26
Qualifiers
Without qualification
1 * File
Directory
filename
With qualification
1 0..1
Directory filename File
27
Qualification: Another Example
Company
* Lists
StockExchange * tickerSymbol
Lists
StockExchange
*
tickerSymbol *
1 Company
28
Inheritance
Button
CancelButton ZoneButton
Account
Bank Customer
30
31
32
Sequence Diagrams Focus on
Controlflow
33
Sequence Diagrams can also model
the Flow of Data
ZoneButton TarifSchedule Display
Passenger
selectZone()
lookupPrice(selection)
price
displayPrice(price)
Dataflow
…continued on next slide...
• The source of an arrow indicates the activation which sent the message
• Horizontal dashed arrows indicate data flow, for example return results
from a message
34
Sequence Diagrams: Iteration &
Condition
…continued from previous slide...
*insertChange(coin) lookupCoin(coin)
price
Iteration displayPrice(owedAmount)
[owedAmount<0] returnChange(-owedAmount)
Condition
…continued on next slide...
35
Creation and destruction
…continued from previous slide...
ChangeProcessor
Passenger
Creation of Ticket
createTicket(selection)
Ticket
print()
free()
Destruction of Ticket
36
Sequence Diagram Properties
37
Activity Diagrams
38
Activity Diagrams allow to model Decisions
Decision
[lowPriority]
Open Allocate
Incident Resources
Notify
Police Chief
39
Activity Diagrams can model Concurrency
• Synchronization of multiple activities
• Splitting the flow of control into multiple threads
Allocate
Splitting Resources Synchronization
Document
Incident
40
Activity Diagrams: Grouping of Activities
Allocate Dispatcher
Resources
FieldOfficer
Document
Incident
41
Activity Diagram vs. Statechart Diagram
Statechart Diagram for Incident
Focus on the set of attributes of a single abstraction (object, system)
Event causes
state transition
Triggerless
Completion of activity transition
causes state transition
42
UML Summary
43