TeaDrinker
Subject
boundary
CoffeDrinker
Pour hot water
Get coin in
return
Buy a cup of
coffe
Subject
Brew a can of
coffee
Collect coins
Add substances
Clean the
Machine
Porter
Service
Subject
name
Kristian Sandahl, IDA krisa@ida.liu.se
Slide no 4
CoffeeMachine
Use-case diagram for the
coffee-machine
Kristian Sandahl, IDA krisa@ida.liu.se
Slide no 1
UML is now the standard notation for modeling software.
Creating a model forces you to take necessary design decisions
Models support understanding, design, documentation
Models supplement natural language
Reduction of complexity
Visualization
Communication with customers
Testing a physical entity before building it
Modeling as a Design
Technique
extension use-case
”Reuse”
Kristian Sandahl, IDA krisa@ida.liu.se
Slide no 5
”Separating scenarious”
(often conditional)
Add change
<<include>>
Open machine
inclusion use-case
<<include>>
<<extend>>
Collect coins
Clean the
machine
Stereotype: extended
classification of meaning
Service
base use-case
Relations between use-cases
Please,
Please,keep
keepas
as
simple
simpleas
aspossible.
possible.
Kristian Sandahl, IDA krisa@ida.liu.se
Slide no 2
A use-case is:
“… a particular form or pattern or exemplar of
usage, a scenario that begins with some
user of the system initiating some
transaction of sequence of interrelated
events.”
Jacobson, m fl 1992: Object-oriented software
engineering. Addison-Wesley
Use-case modelling
Association
parent use-case
Pay with card
Use-case
child use-case
Kristian Sandahl, IDA krisa@ida.liu.se
Slide no 6
use-case generalisation
Pay with coins
Pay coffee
Please,
Please,keep
keepas
as
simple
simpleas
aspossible.
possible.
Kristian Sandahl, IDA krisa@ida.liu.se
Slide no 3
A CoffeeDrinker approaches the machine
with his cup and a coin of SEK 5. He
places the cup on the shelf just under the
pipe. He then inserts the coin, and press
the button for coffee to get coffee
according to default settings. Optionally
he might use other buttons to adjust the
strength and decide to add sugar and/or
whitener. The machine processes the
coffee and bell when it is ready. The
CoffeeDrinker takes his cup from the shelf.
Buy a cup of coffee
Use-case generalization
Description of use-case
Use-case name
CoffeeDrinker
Actor: a user of
the system in a
particular role.
Can be human
or system.
Use-case diagram
“is_
a”
1
•indicator – not discovered
0..*
consumer
multiplicity
CoffeCustomer
roles
0..*
consumables
CupOfCoffee
Kristian Sandahl, IDA krisa@ida.liu.se
Slide no 10
A multiplicity can be:
•an exact number 1
•a range of numbers 1..64
•unspecified number denoted by *
buys
association
Slide no 7
•cup of coffee – handled by the
system
Kristian Sandahl, IDA krisa@ida.liu.se
•whitener – detail of coffee
•sugar – detail of coffee
•button– handled by the system
•pipe – detail of machine
•shelf – detail of machine
•coin – detail of user and machine
•cup – unit for beverage
•machine – real noun handled
by the system
Associations between classes
A CoffeeDrinker approaches the machine
with his cup and a coin of SEK 5. He
places the cup on the shelf just under the
pipe. He then inserts the coin, and press
the button for coffee to get coffee
according to default settings. Optionally
he might use other buttons to adjust the
strength and decide to add sugar and/or
whitener. The machine processes the
coffee and bell when it is ready. The
CoffeeDrinker takes his cup from the shelf.
Identifying classes: noun
analysis
Porter
CoffeCustomer
0..*
0..*
0..*buys
buys
s
b uy
0..*
0..*
Extended class model
numberOfCoins() : Integer
buy(c:CupOfCoffee)
name: String
CoffeCustomer
The single class model
Kristian Sandahl, IDA krisa@ida.liu.se
Slide no 11
CanOfCoffee
0..*
CupOfCoffee
Kristian Sandahl, IDA krisa@ida.liu.se
Slide no 8
operations
attribute
class name
Porter
CoffeCustomer
buys
0..*
buys
Generalisation
association
0..*
0..*
0..*
Revised class model
-numberOfCoins() : Integer
+buy(c:CupOfCoffee)
#changeName(s:String)
+name: String
CoffeCustomer
Kristian Sandahl, IDA krisa@ida.liu.se
Slide no 12
CanOfCoffee
CupOfCoffee
Kristian Sandahl, IDA krisa@ida.liu.se
Slide no 9
#protected
-private
+public
Class model with visibility
2
Porte
r
getCan()
Kristian Sandahl, IDA krisa@ida.liu.se
Slide no 13
pay()
pay()method
methodisis
inherited
inheritedfrom
from
CoffeeCustomer
CoffeeCustomer
Abstract class
(cannot be instantiated,
only
extended/specialized)
Instrumentalist
Instrumentalist
1..*
1..*
conducts
conducts
1
X
1
Kristian Sandahl, IDA krisa@ida.liu.se
Slide no 16
Conductor
Conductor
Class model with navigability
getCup()
IndividualCustomer
pay( c: coin )
CoffeeCustomer
Class model with inheritance
and abstract classes
1
CoinHandler
1
1
derived
/teaches student
Student
1..*
Professor
is taking
1
Derived associations
Interface
1
1
Machine
Kristian Sandahl, IDA krisa@ida.liu.se
Slide no 17
direction
teaches course
Program
Kristian Sandahl, IDA krisa@ida.liu.se
Slide no 14
Brewer
1
Class model with aggregation
1
CoinHandler
byus
0..1 0..*
CheckStatus
SubmitJob
PrinterServer
CanOfCoffee
provided interface
Interfaces
Porter
*
1
TransmittData
Kristian Sandahl, IDA krisa@ida.liu.se
Slide no 15
Even
Evensmall
smallmodels
models
take
space.You
Youneed
need
takespace.
good
gooddrawing
drawingtools
tools
and
andlagre
lagresheet.
sheet.
s
1
machine
1 1
Brewer
Kristian Sandahl, IDA krisa@ida.liu.se
Slide no 18
required interface
0 ..
ke
ma
1
buys
CoffeeCustomer 0..1 0..* CupOfCoffee makes
0..* 1
1
Interface
The coffee machine class
model
3
is taking
is taking
1
marks: array of int
1..*
Kristian:
CoffeCustomer
Objects:
CoffeCustomer
Classes:
0..*
buys
buys
buys
0..*
Classes and objects
Student
Association class
Kristian Sandahl, IDA krisa@ida.liu.se
Slide no 22
c1: CupOfCoffee
c1: CupOfCoffee
CupOfCoffee
Kristian Sandahl, IDA krisa@ida.liu.se
Slide no 19
Program
1
Marks
is taking
1
marks: array of int
1..*
1..*
Kristian Sandahl, IDA krisa@ida.liu.se
Slide no 20
1
Program
: CoffeCustomer
...or simply like this:
aCoffeCustomer:
CoffeeCustomer
Like this:
buys
buys
Kristian Sandahl, IDA krisa@ida.liu.se
Slide no 23
: CupOfCoffee
theCupOfCoffee:
CupOfCoffee
Reasoning about an arbitrary
object
1
Student
An alternative
0..*
0..*
1..*
10..*
{xor}
is a copy of
1..*
1..*
is a copy of
row:{1,2,..8} 1
column:{1,2,..8}
1
1..*
1
Journal
Book
Square
Volume
Link
Kristian Sandahl, IDA krisa@ida.liu.se
Slide no 21
constraint
qualified association
composition
aggregation
Kristian Sandahl, IDA krisa@ida.liu.se
Slide no 24
this diagram? Do you see anything of your
program that you think should have been
done differently?
Reflection: Do you get a good overview with
operations of a program you have written.
Draw a class diagram with attributes and
Home assignment
Copy
Board
Encylopedia
Topic
More relations between classes
4
Kristian Sandahl, IDA krisa@ida.liu.se
Slide no 25
type
buyer: Company
role name
goods: Goods
connector
Goods sale
Kristian Sandahl, IDA krisa@ida.liu.se
Slide no 28
seller: Company
classes may collaborate to achieve
something, for example, a use-case
Provides a focused view of how instances of
Collaboration
Modeling the model, and extending UML itself
Model management view: Package Diagram
Profiles
Modeling physical structure of software
Deployment view: Deployment diagram
Modeling behavior of software:
Activity view: Activity diagram
State machine view: State machine diagram
Interaction view: Sequence diagram, communication diagram
Modeling (logical) structure of software:
Static view: Class diagram
Design view: Structure diagram, collaboration diagr., component d.
Use case view: Use case diagram
UML: Different diagram types
for different views of software
part name
1
class name
left: Wheel [2]
axle
Car
1
supplement
spell-check
right: Wheel [2]
connector
Kristian Sandahl, IDA krisa@ida.liu.se
Slide no 29
multiplicity
Kristian Sandahl, IDA krisa@ida.liu.se
Slide no 26
<<component>>
Alternative notation:
Structured classifier
Older notation:
Dictionary
Component diagram
<<manifest>>
<<artifact>>
electronics
mechanics
<<delegate>>
receiver
Signal
Car
Open the door with remote control
Kristian Sandahl, IDA krisa@ida.liu.se
Slide no 30
port
Signal
Kristian Sandahl, IDA krisa@ida.liu.se
Slide no 27
PurchaseOrder.jar
Structured classifier with port
PurchaseOrder
<<component>>
Different from UML 1.x
produced by software development
Artifacts are the pieces of information
system with well-defined interfaces
Components describe modular parts of the
Artifacts
5
<<use>>
<<LAN>>
Project
Lab 1
studying
fail
Final exam
course attempt
Lab 2
failed
pass
project done
lab1 done
Explicit exit points
<<artifact>>
august: Workstation
hardware
Deployment diagram
passed
Kristian Sandahl, IDA krisa@ida.liu.se
Slide no 34
lab2 done
Kristian Sandahl, IDA krisa@ida.liu.se
Slide no 31
<<artifact>>
lotta: PC
trigger event,
causing transition
Sequence diagram
Kristian Sandahl, IDA krisa@ida.liu.se
Slide no 35
Communication
diagram
Interaction diagram
Kristian Sandahl, IDA krisa@ida.liu.se
Slide no 32
action, reaction
to the event
insertCoin()/checkCoin(self)
idle
start state marker
this object
falseCoin()/returnCoin(self)
transiton
Interaction view
state
checking
For class
CoinHandler:
State machine diagram
Project
Lab 1
fail
Failed
pass
role
time
pourCoffee
pressButton(b1)
machineReady
insertCoin
: CoffeeCustomer
Kristian Sandahl, IDA krisa@ida.liu.se
Slide no 36
Procedure
is active
Life line
of object
Message
Kristian Sandahl, IDA krisa@ida.liu.se
Slide no 33
Passed
lab2 done
: Interface
Sequence diagram
orthogonal region
Lab 2
project done
lab1 done
orthogonal state
state machine
studying
Final exam
course attempt
Orthogonal, composite state
6
pourCoffee
pressButton(b1)
litIndicators
insertCoin
pourCoffee
makeOrder(o1)
coinAccepted
transport
alt
loop
:TicketDB
reject
add(seats)
[unavailable]
[available]
[get next item]
reserve(date,no)
:Order
: Brewer
Kristian Sandahl, IDA krisa@ida.liu.se
Slide no 37
warmUp
: CoinHandler
Kristian Sandahl, IDA krisa@ida.liu.se
Slide no 40
alternate branches
nested conditional
guard condition
More fragments of interaction
diagrams
C
{C-A < 5s}
A
: CoffeeCustomer
: Interface
Sequence diagram
with several objects
decision
fork
add sugar/whitener
brew coffee
Initial node
pour coffee
[yes]
coin accepted?
insert coin
final
[no] node
Kristian Sandahl, IDA krisa@ida.liu.se
Slide no 38
: Brewer
8: pourCoffee
Role
join
Kristian Sandahl, IDA krisa@ida.liu.se
Slide no 41
add hot water
to adjust strength
3: warmUp
4: coinAccepted
7: makeOrder(o1)
: CoinHandler
2: transport
5: litIndicators
9: pourCoffee
: Interface
Message flow
Activity diagram
: CoffeeCustomer
1: insertCoin
6: pressButton(b1)
Sequence nr
Communication diagram
add(seats)
answer
destruction
Kristian Sandahl, IDA krisa@ida.liu.se
Slide no 39
loop condition
loop
:Account
Get existing customer data
:TicketDB
[get next item]
reserve(date,no)
ref
:Order
Collect Order
Order [delivered]
Pay
Request service
Customer
Deliver order
Order [filled]
Object flow
Take order
Order [placed]
Sales
state
Kristian Sandahl, IDA krisa@ida.liu.se
Slide no 42
Fill order
Order [entered]
Class
Partition (swimline)
Stockroom
Partitions and object flows
loop
create
SD processOrder
Combining fragments of interaction
diagrams
7
Customize (specialize) UML elements, e.g. associations
Can introduce own symbols
Kristian Sandahl, IDA krisa@ida.liu.se
Slide no 43
MOF (Meta-Object Facility):
UML is specified in UML
Powerful mechanism for extending UML by adding new
language elements
e.g. Realtime-profile for UML
Profiles: Collections of stereotypes for specific domains,
Constraints in OCL (Object Constraint Language)
Comments
Other features…
Kristian Sandahl, IDA krisa@ida.liu.se
Slide no 44
Kristian Sandahl, IDA krisa@ida.liu.se
Slide no 45
At least 5 use-cases
At least 5 classes
A state-diagram with at least 5 states
A sequence diagram with at least 5 messages
An activity diagram with at least one synchronization
bar
A deployment diagram with at least two nodes
Imagine a theatre ticket booking system. The customer
can buy tickets on-line or at the ticket office. The
officer can sell tickets and plan the repertoire.
Draw UML views of the systems:
UML – the standard for modeling software
Modeling before/during design, precedes coding
Different diagrams for different views
Model a software system only partially,
focus on a certain aspect and/or part at a time
Problem: Maintaining consistency across diagrams
Tools
Trend towards more detailed modeling
Stepwise refinement
”executable UML”: UML 2 is almost a programming language…
UML is customizable and extendible: Profiles, MOF
Trend towards automatized partial generation of models and code from
models (MDA – model-driven architecture)
Home assignment
UML Summary
8