02291: System Integration
Week 6
Hubert Baumeister huba@dtu.dk
DTU Compute Technical University of Denmark
Spring 2018
Contents
UML State Machines Components (part II)
UML Behaviour Diagrams
I Activity Diagrams
I State Machines
I Interaction Diagrams (Sequence and Collaboration)
Example
I Task: Implement a control panel for a safe in a dungeon
I The safe should be visible only when a candle has been removed
I The safe door opens only when the key is turned after the candle has been replaced again
I If the key is turned without replacing the candle, a killer rabbit is released
Example
Example Execution (Secret Panel Controller)
Example Execution (Secret Panel Controller)
Example Execution (Secret Panel Controller)
Example Execution (Safe)
Example Execution (Safe)
Example Execution (Secret Panel Controler)
Example Execution (Secret Panel Controler)
Example Execution (Safe)
Example Execution (Safe)
Example Execution (Secret Panel Controler)
Example Execution (Secret Panel Controler)
Example Execution (Secret Panel Controler)
Example Execution (Secret Panel Controler)
Example Execution (Secret Panel Controler)
Example Execution (Secret Panel Controler)
Example Execution (Secret Panel Controler)
States 1
States 2
Transitions
UML User Manual 2nd edition
How to use State Machines
I In general:
I Focus on states and how a system reacts to events
I e.g. modal user interfaces
I Model the life of an object
→ Life cycle state machine (LSM)
→ From the creation of the object to its destruction
→ Methods are events
I Model the allowed interaction between components
I Communication protocols
→ Protocol state machines (PSM)
Life cycle state machine
Life cycle state machine (LSM)
Life cycle state machine: Possible implementation
public class SecretPanelController {
enum states { wait, lock, open, finalState };
states state = states.wait;
public void candleRemoved() { switch (state) {
case wait:
if (doorClosed()) { state = states.lock;
break;
} } }
public void keyTurned() { switch (state) { case lock:
if (candleIn()) { state = states.open;
safe.open();
} else {
state = states.finalState;
releaseRabbit();
} break;
} } ... }
Life Cycle State Machine of a counter
Counter c : int inc dec
Initial statec =0 and all the timec ≥0
Nonorthogonal sub states
Nonorthogonal sub states
Nonorthogonal sub states
Nonorthogonal sub states
Nonorthogonal sub states
Nonorthogonal sub states
Sub states II: Leaving sub states
Sub states II: Leaving sub states
Sub states II: Leaving sub states
Orthogonal Sub states
Orthogonal Sub states
Orthogonal Sub states
Orthogonal Sub states
Orthogonal Sub states
Orthogonal Sub states
History states
History states
Activity diagrams compared with State machines:
Activity diagram
Activity diagrams compared with State Machines:
State machines
Contents
UML State Machines Components (part II)
Problem for the connection of components
pinNotOK pinOk
verifyPIN verifyPIN
withdraw
pinOk pinNotOK withdrawOK withdrawNotOk Company
Clearing− Bank ATM
BC BankATM
AB
CB BA
Interconnecting Components: What can go wrong?
I message sent but not understood
I message sent but component is not ready to receive
I component waits for a message not sent
I . . .
Solution 1: Interfaces
Port AB
Bank
Clearing Company ATM
Port BC Port BA
Provided Interface by port AB Required Interface
by port BA
Provided Interface by port BA
Required Interface by port AB
Bank ATM
< < i n t e r f a c e > >
AtmToBank pinOK pinNotOK withdrawOk withdrawNotOk
< < i n t e r f a c e > >
BankToAtm verifyPIN(iban:IBAN, pin:int)
withdraw(iban, amount:Money)
Protocol state machine transition
Protocol state machine
s1 [pre] m / [post] s2
Behavioural state machine
s1 trigger [guard] / effect s2
Protocol state machines
I Protocol for the interface BankToAtm which is the provided interface of PortBA and the required interface of PortAB
withdrawing w i t h d r a w
verifying idle
sm: BankToAtm {protocol}
/ [ ^ p i n N o t O k ]
/ [ ^ w i t h d r a w O k ] / [ ^ w i t h d r a w N o O k ]
withdraw(i,a) / [ ^ p i n O k ]
verifyPin(p)
I Protocol for interface AtmToBank which is the provided interface of PortAB and the required interface of portBA
waiting AtmToBank {protocol}
Idle
pinNotOk
pinNotOk / [ ^ v e r i f y P i n ]
Protocol state machines
I Protocol for the interface BankToAtm which is the provided interface of PortBA and the required interface of PortAB
withdrawing w i t h d r a w
verifying idle
sm: BankToAtm {protocol}
/ [ ^ p i n N o t O k ]
/ [ ^ w i t h d r a w O k ] / [ ^ w i t h d r a w N o O k ]
withdraw(i,a) / [ ^ p i n O k ]
verifyPin(p)
I Protocol for interface AtmToBank which is the provided interface of PortAB and the required interface of portBA
waiting AtmToBank {protocol}
Idle
pinNotOk
pinNotOk / [ ^ v e r i f y P i n ]
Protocol state machines
I Protocol for the interface BankToAtm which is the provided interface of PortBA and the required interface of PortAB
withdrawing w i t h d r a w
verifying idle
sm: BankToAtm {protocol}
/ [ ^ p i n N o t O k ]
/ [ ^ w i t h d r a w O k ] / [ ^ w i t h d r a w N o O k ]
withdraw(i,a) / [ ^ p i n O k ]
verifyPin(p)
I Protocol for interface AtmToBank which is the provided interface of PortAB and the required interface of portBA
waiting AtmToBank {protocol}
Idle Withdraw
pinNotOk
/ [ ^ v e r i f y P i n ] pinOk/[^withdraw(i,a)]
withdrawNotOk withdrawOk
Exercise: Bank to Clearing Company
Port AB
Bank
Clearing Company ATM
Port BC Port BA
Provided Interface by port AB Required Interface
by port BA
Provided Interface by port BA
Required Interface by port AB
«interface»
CcToBank verifyPin(p)
«interface»
BankToCc pinOk
pinNotOk
What are the two PSM’s for the two interfaces?
PSM’s CcToBank and BankToCc
«interface»
CcToBank verifyPin(p)
«interface»
BankToCc pinOk
pinNotOk
Implementing components by components
UML User Manual, Grady Booch
Bank component showing Implementation by classes
Bank
Bank
Customer Account
ClearingCompanyToBank
BankToAtm
*
«delegate»
«delegate»
* BankToATMPort
«delegate»
BankToClearingCompany
AtmToBank
«delegate»
Detailed Class Diagram for the Bank Component
Bank name: String ...
pinOK pinNotOk
accountFor(a): Account ...
«interface»
AtmToBank pinOK
pinNotOK withdrawOk withdrawNotOk
Customer name
address ...
Account number : IBAN balance : int
withdraw(amount:int): bool ...
BankToATMPort verifyPIN(a,p): bool withdraw(a,m): bool pinOK
pinNotOk
1 cc
1..*
1..*
c *
*
«interface»
BankToAtm verifyPIN(a,p): bool
withdraw(a,m): bool *
1 b
«interface»
ClearingCompanyToBank verifyPIN(a,p)
«interface»
BankToClearingCompany pinOK
pinNotOk
1 a t m
Behaviour implementation
Lifecycle state machine BankToATMPort
sm: BankToATMPort
idle verifyPin(a,p)/b.verifyPin(self,ap,p) verifying pinNotOk/atm.pinNotOk
pinOK/atm.pinOK
waiting for w i t h d r a w
widthdraw(a,m)/b.withdraw(self,a,m) withdrawing
withdrawNotOk/atm.withdrawNotOk withdrawOk/atm.withdrawOK
Lifecycle state machine Bank
LSM conformance with PSM
Protocol for provided interface of the port Bank to ATM
withdrawing w i t h d r a w
verifying idle
sm: BankToAtm {protocol}
/ [ ^ p i n N o t O k ]
/ [ ^ w i t h d r a w O k ] / [ ^ w i t h d r a w N o O k ]
withdraw(i,a) / [ ^ p i n O k ]
verifyPin(p)
BankToAtmPort lifecycle state machines
sm: BankToATMPort
idle verifyPin(a,p)/b.verifyPin(self,ap,p)
verifying pinNotOk/atm.pinNotOk
pinOK/atm.pinOK
waiting for w i t h d r a w
widthdraw(a,m)/b.withdraw(self,a,m)
withdrawing
withdrawNotOk/atm.withdrawNotOk withdrawOk/atm.withdrawOK
Summary
I State machines:
I Behaviour diagram
I Focus on states and how events change the state
I Life Cycle State Machine (LSM) of objects
I methods trigger state changes I Components
I Connecting components: Interfaces + Communication protocol
I Protocol State Machines (PSM)
I Attached to interfaces
I Communication protocol
I Conformance
I PSM’s of connected interfaces need to be able to work together deadlock free
I LSM’s have to ”implement” PSM’s
