Behavior Modeling with UML 2€¦ · Context model with UML1.x class diagrams with plain...
Transcript of Behavior Modeling with UML 2€¦ · Context model with UML1.x class diagrams with plain...
1-Feb-06 Haugen / Møller-Pedersen
INF 5120
1
Behavior Modeling with
UML 2.0
Øystein Haugen &Birger Møller-Pedersen
1-Feb-06 Haugen / Møller-Pedersen
INF 5120
2
UML standardization within OMG – for Ericsson
EricssonUML standardization
team
developersworld-wide
Requirements from
improved
contributing in cooperation
with tool vendors
issuing requirements in cooperation
with alllies
better tools
1-Feb-06 Haugen / Møller-Pedersen
INF 5120
3
U2 Partners
Submitters– Alcatel, CA, Ericsson, Fujitsu, HP, IBM, I-Logix, IONA, Kabira,
Motorola, Oracle, Rational, SOFTEAM, Telelogic, Unisys
Supporters– Advanced Concepts Center LLC, Ceira Technologies,
Commissariat à L'Energie Atomique, Compuware, DaimlerChrysler, Embarcadero Technologies, Enea Data, France Telecom, Fraunhofer FOKUS, Gentleware, Intellicorp, Jaczone, Kennedy Carter, Klasse Objecten, KLOCwork, Lockheed Martin, Mercury Computer, MSC.Software, Northeastern University, Popkin Software, Proforma, Sims Associates, Syntropy Ltd., Sun Microsystems, University of Kaiserslautern, University of Kent, VERIMAG, WebGain, and 88solutions
2P2P
1-Feb-06 Haugen / Møller-Pedersen
INF 5120
4
Why UML2.0?
for Ericsson, Motorola, Alcatel, Nokia (telecom, realtime) – SDL/MSC only one vendor– UML/ROOM (as by RoseRT) only one vendor
– UML2.0 combining features from these
for others– Scalability, modeling of large, complex systems– Improvement of existing concepts: activities, components,– Completeness: action semantics, formal/precise definition
in general– Experiences with UML1.x required an improvement– Model Based Development requires a good modeling language
1-Feb-06 Haugen / Møller-Pedersen
INF 5120
8
Example - ATM
Domain statement– An Automatic Teller Machine (ATM) is a system with mechanical as
well as electronic parts. Its purpose is to provide a bank user with cash provided that the user can authenticate herself and she hasadequate funds in her bank account.
– She authenticates herself by presenting a card to the ATM cardreader, and a personal identification number (PIN) through the ATM keyboard.
– The ATM is connected electronically and possibly through some kind of network to the bank such that the account status may be checked online.
– The ATM is refilled with cash notes regularly or when the number of specific notes is below some limit.
– The ATM may also provide foreign currency to the customer
1-Feb-06 Haugen / Møller-Pedersen
INF 5120
9
ATM: Domain Model I
CardAccount
User ATM Bank
1
*
1
*
* 1* *
myAccount
11
FromHaugen, Ø., B. Møller-Pedersen, and T. Weigert, Modeling Embedded Systems in UML 2.0, in The Embedded Systems Handbook, Richard Zurawski, Editor. 2005, CRC Press.
1-Feb-06 Haugen / Møller-Pedersen
INF 5120
10
Domain Model II
Keyboard CashDispenserCardReader Screen
ATM
1-Feb-06 Haugen / Møller-Pedersen
INF 5120
11
Use Case Model
ATM
«include»
«include»
UserBank
Withdrawal
CashRepository
Currency
Authentication
1-Feb-06 Haugen / Møller-Pedersen
INF 5120
12
Context model with UML1.x class diagrams
with plain composition and no encapsulation with only provided interfaces on classes
User Bank
Keyboard CashDispenserCardReader Screen
ATM
User-ATM ATM-Bank
1-Feb-06 Haugen / Møller-Pedersen
INF 5120
13
Composite class (incomplete)
with parts, ports and connectors
ATM
:CardReader
:CashDispenser:Keyboard
User-Reader
User-Keyboard
ATM-bank
User-Cash
:ScreenUser-Screen
part
port
connector
1-Feb-06 Haugen / Møller-Pedersen
INF 5120
14
Context Model in UML2.0 - I
composite structure as part of a Collaboration
BankContext
:User :ATM :Bank
User-Reader
User-Keyboard
ATM-bank
User-Cash
User-Screen
1-Feb-06 Haugen / Møller-Pedersen
INF 5120
15
Context Model in UML2.0 - II
Including multiplicities on parts
BankContext
:User[1..10000]
:ATM[1..100] :Bank
User-Reader
User-Keyboard
ATM-bank
User-Cash
User-Screen
multiplicity
1-Feb-06 Haugen / Møller-Pedersen
INF 5120
16
BankContext
… as part of Packages?
:User[1..10000]
:ATM[1..100] :Bank
User-Reader
User-Keyboard
ATM-bank
User-Cash
User-Screen
No
1-Feb-06 Haugen / Møller-Pedersen
INF 5120
17
Sequence Diagrams (Interactions)
Sequence Diagrams are– simple– powerful– readable– used to describe interaction sequences
History– Has been used for a number of years informally– Standardized 1992 in Z.120 (Message Sequence Charts - MSC)– Last major revision of MSC is from 1999 (called MSC-2000)– Formal semantics of MSC-96 is given in Z.120 Annex B
– Included in UML from 1999, but in a rather simple variant
1-Feb-06 Haugen / Møller-Pedersen
INF 5120
18
Purpose
Emphasizes the interaction between objects indicating that the interplay is the most important aspect
– Often only a small portion of the total variety of behavior is described improve the individual understanding of an interactionproblem
Sequence Diagrams are used to ...– document protocol situations,– illustrate behavior situations,– verify interaction properties relative to a specification,– describe test cases,– document simulation traces.
1-Feb-06 Haugen / Møller-Pedersen
INF 5120
19
(Simple) Sequence Diagram
Messages have one send event, and one receive event.– The send event must occur before the receive event.– The send event is the result of an Action
Events are strictly ordered along a lifeline from top to bottom
sd EnterPIN
:Bank:User :ATM
msg(”Give PIN”)
Digit
Digit
Digit
Digit
Code(cid, pin)
PIN OK
OK
The frame (UML 2)
The name of the interaction
Send Event
Receive Event
Message name
Continuation
1-Feb-06 Haugen / Møller-Pedersen
INF 5120
20
Combined fragment example
combined fragment frame
operator
operand separator
sd EnterPIN
:Bank:User :ATM
msg(”Give PIN”)
Digit
Digit
Digit
Digit
Code(cid, pin)
alt
PIN NOK
PIN OK
NOK
OK
1-Feb-06 Haugen / Møller-Pedersen
INF 5120
21
Combined fragments of Interaction
We want to express– choices: alternative, option, break– parallel merge– loops
We may also want to add other operators– negation– critical region– assertion
Other suggested operators that will not come in UML 2.0– interrupt– disrupt
1-Feb-06 Haugen / Møller-Pedersen
INF 5120
22
:Bank:User
sd Authenticate
EnterPINref
loop(0,3)
EnterPINref
Idle
Cardid(cid)
msg("Try again!")
:ATM
PIN NOK
References (Interaction Use / Occurrence)
reference
Continuation
1-Feb-06 Haugen / Møller-Pedersen
INF 5120
23
Nested combined fragments
:Bank:User
sd Withdrawal
Authenticateref
alt
PIN NOK
PIN OK
Withdrawal
msg("Give amount!")
ok
:ATM
amount(v) checkaccount(v)
alt money(v)
receipt(v)
nokmsg(”Amount too large”)
msg(”Illegal entry”)
card
card taken
Continuation
reference
combined fragment
nested fragment
1-Feb-06 Haugen / Møller-Pedersen
INF 5120
24
sd Withdrawal
Authenticateref
PIN NOKPIN OK
okmoney(v)
receipt(v)
:Bank:User :ATM
sd
nokmsg(”Amount too large”)
:Bank:User :ATM
sd
msg(”Illegal entry”)
:User :ATM
sd
card
card taken
:User :ATM
sd
Withdrawal
msg("Give amount!")
amount(v) checkaccount(v)
:Bank:User :ATM
sd
Interaction Overview Diagram
Continuation
reference
combined fragment
nested fragment
Inline diagram
1-Feb-06 Haugen / Møller-Pedersen
INF 5120
25
sm EnterPIN
enterDigit
send(msg(”Give PIN”)); n=1; PIN=0
waitOK
digit [n=4] / PIN=PIN+digitsend(Code(cid,PIN))
ok
digit [n<4]/n++;PIN= PIN+digit*10(3-n)
noknokok
EnterPIN state machine
n:integerPIN: integer
<<statemachine>>EnterPIN
definition of exit point
trigger
guard
effect
1-Feb-06 Haugen / Møller-Pedersen
INF 5120
26
Statemachine for the ATMsm ATM
:Withdrawal
entry: send(card)
CardOut
:EnterPIN/authN=0
Idle
CardId(cid)
[authN<3]/authN++;send(msg(”Try again”))
/authN=0
[authN==3]/authN=0
send(msg( ”illegal entry”));
nok
ok
cancelledok
:Status
:Service
statusWithdrawal
cardTaken
use of exit point
submachine state
1-Feb-06 Haugen / Møller-Pedersen
INF 5120
27
Attributes of the ATM
Statemachine is a Classifier (that is class-like):– Attributes– Operations (local actions)– Behaviors (e.g. state
machines)
authN number of triescid card idsa selected amount
sendMoney(a:Amount)
authN: integercid: integersa: Amount
<<statemachine>>ATM
1-Feb-06 Haugen / Møller-Pedersen
INF 5120
28
State machine Withdrawal
sm Withdrawal
:GetAmount cancelled
VerifyTransaction
send(CheckAccount(sa)) nok/send(msg(”Amount too large”))
ok
ok/sendMoney(sa);send(Receit(sa));
again
cancelled
use of entry point
1-Feb-06 Haugen / Møller-Pedersen
INF 5120
29
Simple GetAmount
sm GetAmount
:SelectAmount
Send(msg(”select amount”))
amount(sa);
cancelcancelled
again
Send(msg(”select another amount”))
definition of entry point
1-Feb-06 Haugen / Møller-Pedersen
INF 5120
30
sm GetAmount {extended}
:SelectAmount
:enterAmount
otherAmount/send(msg(”enter amount”))
cancel
again
cancelled
ok
Send(msg(”enter another amount”))
Extended GetAmount
inherited state
redefined transition
<<statemachine>>ATM
<<statemachine>>GetAmount
<<statemachine>>FlexibleATM
<<statemachine>>GetAmount {extended}
1-Feb-06 Haugen / Møller-Pedersen
INF 5120
31
A service similar to Withdrawal: Currency
:Bank:User
sd Currency
Authenticateref
alt
PIN NOK
PIN OK
Currency
msg("Give currency!")
ok
:ATM
amount(e) checkaccount(v(e))
altEUR(e)
receipt(v)
nokmsg(”Amount too large”)
msg(”Illegal entry”)
card
EUR
msg("Give amount!")
[enough on account]
[inadequate funds]
card taken
:Bank:User
sd Withdrawal
Authenticateref
alt
PIN NOK
PIN OK
Withdrawal
msg("Give amount!")
ok
:ATM
amount(v) checkaccount(v)
alt money(v)
receipt(v)
nokmsg(”Amount too large”)
msg(”Illegal entry”)
card
card taken
1-Feb-06 Haugen / Møller-Pedersen
INF 5120
32
Interactions are generalizable and redefinable
:Bank:User
sd GenWithdrawal
Authenticationref
alt
PIN NOK
PIN OK
ok
:ATM
checkaccount(v(e))
alt
receipt(v)
nokmsg(”Amount too large”)
msg(”Illegal entry”)
card
[enough on account]
[inadequate funds]
getAmount
ref
giveMoneyref
card taken
Currency
msg("Give currency!")
amount(e)
EUR
msg("Give amount!")
sd getAmount
:User :ATM
EUR(e)
sd giveMoney
:User :ATM
ok
sd getAmountsd giveMoney
GenWithdrawal
redefined getAmountredefined giveMoney
Withdrawal
redefined getAmountredefined giveMoney
Currency
formal gate
actual gate
1-Feb-06 Haugen / Møller-Pedersen
INF 5120
33
ATM revisited - generalisedsm ATM
entry: send(card)
CardOut
:EnterPIN/authN=0
Idle
CardId(cid)
[authN<3]/authN++;send(msg(”Try again”))
/authN=0
[authN==3]/authN=0
send(msg( ”illegal entry”));
nok
ok
:Status
:Service
status
cardTaken
1-Feb-06 Haugen / Møller-Pedersen
INF 5120
34
Extended state machinessm WithdrawalATM
:Withdrawal
CardOut
cancelledok
:Service{extended}
Withdrawal
sm CurrencyATM
:Currency
CardOut
cancelledok
:Service{extended}
Currency
1-Feb-06 Haugen / Møller-Pedersen
INF 5120
35
:Bank:User
sd Authenticate
EnterPINref
loop(0,3)
EnterPINref
Idle
Cardid(cid)
msg("Try again!")
:ATMref ATM_Authenticate
PIN NOK
Decomposing a Lifeline wrt an Interaction
we want to look into this lifeline
this is the name of the diagram
where we find the decomposition
1-Feb-06 Haugen / Møller-Pedersen
INF 5120
36
Decomposition
:Keyboard :Controller:CardReader
sd ATM_Authenticate
ATM_EnterPINref
loop(0,3)
ATM_EnterPINref
ATM_Idle
Cardid(cid)
msg("Try again!")
:CashDispenser
ATM_PIN NOK
msg("Try again!")
Cardid(cid)
:Screen
Code(cid, pin)
NOK
Code(cid, pin)
OK, NOK
:Bank:User
sd Authenticate
EnterPINref
loop(0,3)
EnterPINref
Idle
Cardid(cid)
msg("Try again!")
:ATMref ATM_Authenticate
PIN NOK
notice the correspondance!
notice the correspondance!
1-Feb-06 Haugen / Møller-Pedersen
INF 5120
37
Composite (design) class
ATM
:CardReader
:CashDispenser:Keyboard
:Controller
User-Reader
User-Keyboard
ATM-bank
User-Cash
:ScreenUser-Screen
1-Feb-06 Haugen / Møller-Pedersen
INF 5120
38
Structured Classes are like other Classes
Structured Classes may have– attributes & operations, interfaces, …
Internal structure is inherited, inherited parts may be redefined by extension
ATM
:CardReader
:CashDispenser:Keyboard
:Controller
User-Reader
User-Keyboard
ATM-bank
User-Cash
:ScreenUser-Screen
1-Feb-06 Haugen / Møller-Pedersen
INF 5120
39
What about Components?
Components have all the properties of structured classes
Note that these are just derived, that is they are also
defined for classes
1-Feb-06 Haugen / Møller-Pedersen
INF 5120
40
What is special for Components
Realization by a number of classes
1-Feb-06 Haugen / Møller-Pedersen
INF 5120
41
... and
may be kind of ‘package’, i.e. it may have model elements that you would not have for classes
A component may have e.g. use cases, sequence diagrams,
packages, dependencies, components
1-Feb-06 Haugen / Møller-Pedersen
INF 5120
42
Deployment of components
Artifacts, Nodes, Network of Nodes,...
1-Feb-06 Haugen / Møller-Pedersen
INF 5120
43
Must be profiled for actual component models
1-Feb-06 Haugen / Møller-Pedersen
INF 5120
44
Finally
Tools– IBM Rational Software Modeler (eller Architect)– Telelogic real-time, telecom, but moving towards general– I-Logix real-time, telecom, control systems– Softteam general, with emphasis on profiling– MagicDraw– Enterprise Architect
Books– Selic et al. (eds) UML for Real (Chapter 3)– Chonoles and Schardt: UML2.0 for Dummies– Fowler UML Distilled (Third Edition)– Rumbaugh: UML Reference Manual 2nd edition– Craig Larman: Applying UML and Patterns