02291: System Integration Hubert Baumeister hub@imm.dtu.dk Spring - - PDF document

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

Withdraw Idle verifyPin(p)/[^pinNotOk] verifyPin(p)/[^pinOk] withdraw(i,a)/[^withdrawOk] withdraw(i,a)/[^withdrawNotOk] PortBA {protocol}

Protocol state machine transition Protocol state machine s1 s2 [pre] m / [post] Behavioural state machine

s1 s2 trigger [guard] / effect

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

pinNotOK pinOk verifyPIN verifyPIN withdraw pinOk pinNotOK withdrawOK withdrawNotOk

Company Clearing− Bank ATM BC BankATM AB CB BA

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

pinNotOK pinOk verifyPIN verifyPIN withdraw pinOk pinNotOK withdrawOK withdrawNotOk

Company Clearing− Bank ATM BC BankATM AB CB BA

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 by port BA Provided Interface by port BA Required Interface by port BA Provided Interface by port BA Port BA Port BC ATM Clearing Company Bank

25

«interface» BanktToAtm verifyPIN(iban:IBAN, pin:int) withdraw(iban, amount:Money) «interface» AtmToBank pinOK pinNotOK withdrawOk withdrawNotOk ATM Bank

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) «interface» AtmToBank pinOK pinNotOK withdrawOk withdrawNotOk ATM Bank

Protocols state machine for ports

• Protocol for port BA of the bank

Withdraw Idle verifyPin(p)/[^pinNotOk] verifyPin(p)/[^pinOk] withdraw(i,a)/[^withdrawOk] withdraw(i,a)/[^withdrawNotOk] PortBA {protocol}

26

• Protocol for port AB of the ATM

Withdraw Idle pinNotOK pinOk/[^withdraw(i,a)] withdrawOk withdrawNotOk PortAB {protocol}

Implementing components by components

UML User Manual, Grady Booch

Ports of the super component are realized by ports of the sub component through delegation 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 27

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 atm

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 withdraw widthdraw(a,m)/b.withdraw(self,a,m) withdrawing withdrawNotOk/atm.withdrawNotOk withdrawOk/atm.withdrawOK

Lifecycle state machine Bank Protocol conformance 28

Protocol for the port Bank to ATM

Withdraw Idle verifyPin(p)/[^pinNotOk] verifyPin(p)/[^pinOk] withdraw(i,a)/[^withdrawOk] withdraw(i,a)/[^withdrawNotOk] PortBA {protocol}

Bank lifecycle state machine

sm: BankToATMPort idle verifyPin(a,p)/b.verifyPin(self,ap,p) verifying pinNotOk/atm.pinNotOk pinOK/atm.pinOK waiting for withdraw widthdraw(a,m)/b.withdraw(self,a,m) withdrawing withdrawNotOk/atm.withdrawNotOk withdrawOk/atm.withdrawOK

The bank life cycle state machine must be an refinement of the the protocol machine of the port bankt to ATM. Refinement of state machines

• The implementation refines the port protocol state machine (PSM), if

1) every message the PSM can handle, the implementation can handle 2) every message is produced by the implementation is also produced by the PSM → Substitutability – Whenever a client can work together with the PSM, he can work together with the implementation of the component 29

→ Encapsulation

• Note how the implementation ties together the message of the BA and BC port (it explains that when BA

receives a verifyPin message, that this message is sent through the BC port to the Clearing Company) Synchronous version of the Bank

• Asynchronous: ATM sends to the Bank the message verifyPin and does not wait for the answer

– Instead the Bank sends a message pinOK or pinNotOk back to the ATM

• Synchronous: ATM sends to the Bank the message verifyPin and waits for the answer (true or false)

Closer View

• View on ATM, Bank, ClearingCompany with interfaces

– Port Bank to ATM (BA) ∗ Provided Interface 30

∗ Required Interface: None – Port ATM to Bank (AB) ∗ Provided Interface: None ∗ Required Interface Protocol for port BA of the bank

• Asynchronous version of the protocol state machine

Withdraw Idle verifyPin(p)/[^pinNotOk] verifyPin(p)/[^pinOk] withdraw(i,a)/[^withdrawOk] withdraw(i,a)/[^withdrawNotOk] PortBA {protocol}

• Synchronous version of the protocol state machine

31

Withdraw Idle verifyPin(p)/[result = false] verifyPin(p)/[result = true] withdraw(i,a)/[result = true] withdraw(i,a)/[result = false] PortBA synch. {protocol}

Bank component with Implementation

Bank Bank Customer Account ClearingCompanyToBank BankToATM * «delegate» «delegate» BankToATMPort *

Detailed Class Diagram for the Bank Component

Bank name: String ... accountFor(acct): Account verifyPin(acct,pin) withdraw(acct,amount) «interface» ClearingCompanyToBank verifyPIN(acct,pin): bool Customer name address ... Account number : IBAN balance : int withdraw(amount:int): bool ... BankToATMPort verifyPIN(acct,pin): bool withdraw(acct,amt): bool 1 cc * 1..* 1..* * c * «interface» BankToATMSync verifyPIN(acct,pin): bool withdraw(acct,amt): bool * 1 b

Behaviour Design BankToATMPort

• Behaviour of class BanktToATMPort

32

• Behaviour of class Bank

Protocol conformance Protocol for the port Bank to ATM

Withdraw Idle verifyPin(p)/[result = false] verifyPin(p)/[result = true] withdraw(i,a)/[result = true] withdraw(i,a)/[result = false] PortBA synch. {protocol}

BankToATMPort lifecycle state machine Components

• Ports in components have

– provided and required interfaces – Each interface: Protocol state machine

• Implementing Compenents

1) Subcomponents delegating ports 2) Set of classes ∗ Classes implement provided interface of a port 33

∗ Classes use the required interface of a port ∗ Lifecycle state machine and protocol state machine have to conform to each other 34