02291: System Integration Hubert Baumeister hub@imm.dtu.dk Spring 2013 Contents 1 UML State Machines 1 2 Components (part II) 24 1 UML State Machines UML Behaviour Diagrams • Activity Diagrams • State Machines • Interaction Diagrams (Sequence and Collaboration) UML Behaviour Diagrams • UML Structural Diagrams – Class Diagrams – Object Diagrams – Package Diagrams – . . . • UML Behaviour Diagrams – Use-Case Diagram – State Machine – Sequence Diagram – Communication Diagram – Activity Diagram Introduction State Machines • Basic idea – Show the effect of events to an object/system. – Being in a state , the occurrence of an event moves the object/system represented by the state machine into a new state . • History – Harel’s statecharts – But also used for graphic representation of (finite state) automata 1
Example • Task: Implement a control panel for a safe in a dungeon • The safe should be visible only when a candle has been removed • The safe door opens only when the key is turned after the candle has been replaced again • If the key is turned without replacing the candle, a killer rabbit is released Example Example Execution (Secret Panel Controller) 2
3
Example Execution (Safe) 4
Example Execution (Secret Panel Controler) Example Execution (Safe) 5
Example Execution (Secret Panel Controler) 6
7
8
States 1 9
State A state of an object is a period of time during which it satisfies some condition, performs some activity, or waits for some event. • Usually states have abstract names – But states can also be characterised by its attributes (and most likely in their implementation they will) • States can have invariants States 2 • Entry/Exit effects are executed when the state is being entered/left • Do activities are executed while the state is active • Internal transitions are performed when the state is active, the event happens and the guard is true (if the internal transition has a guard). Internal transitions are different from transitons from a state to itself, because in this case, the state is first left, the transition effect executed and then the entry effect executed. With an internal transition, the entry and exit effects are not executed • One can mark events as deferred to avoid that they be thrown away when they occur, but cannot be handled. This means that a deferred event is queued until the there is a transition having that event as a trigger. States II • Initial state: – is not a ”real” state, i.e. it is called ”pseudostate” • final state: 10
Transitions UML User Manual 2nd edition Transitions • General form trigger [ guard ] /effect • Triggers (includes events) – Call Event ∗ messages being sent (e.g. class / interface operation) ∗ Can have parameters that can be used in the guard or in the effect – Timing events ∗ after (2 seconds) ∗ at (22:30 3.4.2007) – Change events: ∗ when (cond) • Guard – boolean expression • Effect – Is a UML behaviour : UML action language , . . . – The UML defines no precise semantics/notation for effects ∗ Calling a method / return from a (synchronous) call ∗ Changing the state of an object (e.g. variable assignment) ∗ . . . 11
Execution • Event Pool – Contains all the events which the object has received – Each object has its own event pool • Execution Steps 1 Select an event from the event pool ∗ The UML standard does not define the selection criteria 2 Find the matching (firing) transitions ∗ The event must match and the guard must evaluate to true !! If no matching transition is found, the event is discarded! !! deferred events will be put back into the event pool !! If more than one firing transition is found, one is chosen non-deterministically 3 Execute the effects of the firing transitions • Run to completion – all effects of one transition are completed entirely before continuing with the next step How to use State Machines • In general: – Focus on states of a system and how a system reacts to events – e.g. modal user interfaces • Model the life of an object → Life cycle state machine → From the creation of the object to its destruction → Methods are events • Model a method of an object → Description of an algorithm • Model the allowed interaction between components – Communication protocols → Protocol state machines Life cycle state machine 12
Example (cont.) 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()) { 13
state = states.open; safe.open(); } else { state = states.finalState; releaseRabbit(); } break; } } ... } Implementation • The current state is stored in a variable • Events are method calls 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 (candleOut()) { state = states.open; } else { state = states.finalState; releaseRabbit(); } break; } } ... } Describing one operation Communication protocols: Protocol state machines 14
PortBA {protocol} withdraw(i,a)/[^withdrawOk] withdraw(i,a)/[^withdrawNotOk] verifyPin(p)/[^pinOk] Idle Withdraw verifyPin(p)/[^pinNotOk] Protocol state machine transition Protocol state machine [pre] m / [post] s1 s2 Behavioural state machine trigger [guard] / effect s1 s2 Use of state machines State machines can be used to describe • The life of one object or part of one object (e.g. SecretPanelController) – from its creation to its death – which message it accepts and its reaction to messages • The behaviour of one operation 15
• Communication protocols – e.g. of interfaces of components – possibly using UML 2.0: Protocol State Machines Nonorthogonal sub states 16
17
Substates help structure complex state machine diagrams (similar to subroutines). The nonorthogonal sub states of one sub state cannot be active at the same time. Sub states II: Leaving sub states 18
Substates can be left at any time when an outgoing super state transition fires (e.g. cancel below) Orthogonal Sub states 19
20
21
• Model concurrency • Substates are orthogonal if they are in orthogonal regions • Several orthogonal sub states can be active at the same time History states 22
• History states remembers which sub state was active when the super state became inactive, so that this sub state is activated again, when the super state becomes active again. Activity diagrams 23
State machines 2 Components (part II) Problem for the connection of components 24
BankATM verifyPIN verifyPIN withdraw Bank ATM Clearing− Company CB BC AB BA pinOk pinOk pinNotOK pinNotOK withdrawOK withdrawNotOk Interconnecting Components: What can go wrong? • message sent but not understood • message sent but component is not ready to receive • component waits for a message not sent • . . . Problem for the connection of components BankATM verifyPIN verifyPIN withdraw Clearing− Bank ATM Company CB BC AB BA pinOk pinOk pinNotOK pinNotOK withdrawOK withdrawNotOk Interconnecting Components How can we assure that the components work together ? What can go wrong • One component sends a message that the other does not understand • One component sends a message that the other does not expect at this time • One component waits for a message that is not sent by the other component • One component does not do what one expects from it • . . . Solution 1: Interfaces Required Interface Provided Interface by port BA by port BA Clearing Company Bank ATM Provided Interface Required Interface Port BC Port BA by port BA by port BA 25
«interface» BanktToAtm verifyPIN(iban:IBAN, pin:int) withdraw(iban, amount:Money) Bank ATM «interface» AtmToBank pinOK pinNotOK withdrawOk withdrawNotOk Solution Ports contain information about • Which operations are provided by a port • Which operations are required by a port • How do two components talk to each other → (protocol) state machines the expected message exchange between two components • What can another component expect from an operation provided by a component? → Design by contract Port BA • PortBA provides BankToAtm and requires AtmToBank • PortAB provides AtmToBank and requires BankToAtm «interface» BanktToAtm verifyPIN(iban:IBAN, pin:int) withdraw(iban, amount:Money) Bank ATM «interface» AtmToBank pinOK pinNotOK withdrawOk withdrawNotOk Protocols state machine for ports • Protocol for port BA of the bank PortBA {protocol} withdraw(i,a)/[^withdrawOk] withdraw(i,a)/[^withdrawNotOk] verifyPin(p)/[^pinOk] Idle Withdraw verifyPin(p)/[^pinNotOk] 26
Recommend
More recommend
