Formal Specification of Software
UML State Machines
Bernhard Beckert
UNIVERSITÄT KOBLENZ-LANDAU
B. Beckert: Formal Formal Specification of Software – p.1 UML State Machines
Important type of UML diagrams
For modelling behaviour
Lifecycle of objects Behaviour of operations
History
Invented by D. Harel (State Charts) Made popular by J. Rumbaugh (OMT)
B. Beckert: Formal Formal Specification of Software – p.2 Notions Related to State Machines
State Transition Event Action, Activity Guards Sending messages Nesting Concurrency History states
B. Beckert: Formal Formal Specification of Software – p.3 The game can end both when it is White’s and when it is Black’s turn. The moving player can end the game: winning (checkmate), loosing (resign), or with a draw.
Example: Chess
A chess game consists of alternate moves of Black and White. White moves first.
B. Beckert: Formal Formal Specification of Software – p.4 The game can end both when it is White’s and when it is Black’s turn. The moving player can end the game: winning (checkmate), loosing (resign), or with a draw.
Example: Chess
A chess game consists of alternate moves of
Black and White. White StateMachine Behaviour of ChessGame moves first.
Event
White’s Move
Initial State bm(p:Piece) Transition Black’s Move
State
B. Beckert: Formal Formal Specification of Software – p.4 The moving player can end the game: winning (checkmate), loosing (resign), or with a draw.
Example: Chess
A chess game consists of alternate moves of
Black and White. White StateMachine Behaviour of ChessGame moves first.
The game can end both Event when it is White’s and White’s Move when it is Black’s turn. Initial State bm(p:Piece) Transition Black’s Move
State
B. Beckert: Formal Formal Specification of Software – p.4 The moving player can end the game: winning (checkmate), loosing (resign), or with a draw.
Example: Chess
A chess game consists of alternate moves of
Black and White. White Behaviour of ChessGame moves first. The game can end both
when it is White’s and White’s Move when it is Black’s turn. bm(p:Piece) Final State
Black’s Move
B. Beckert: Formal Formal Specification of Software – p.4 loosing (resign), or with a draw.
Example: Chess
A chess game consists of alternate moves of
Black and White. White Behaviour of ChessGame moves first. The game can end both
when it is White’s and White’s Move when it is Black’s turn. bm(p:Piece) Final State The moving player can Black’s Move end the game: winning (checkmate),
B. Beckert: Formal Formal Specification of Software – p.4 loosing (resign), or with a draw.
Example: Chess
A chess game consists of alternate moves of
Black and White. White Behaviour of ChessGame moves first. The game can end both
when it is White’s and White’s Move White Win when it is Black’s turn. bm(p:Piece) The moving player can Black’s Move Black Win end the game: winning (checkmate),
B. Beckert: Formal Formal Specification of Software – p.4 or with a draw.
Example: Chess
A chess game consists of alternate moves of
Black and White. White Behaviour of ChessGame moves first. The game can end both
when it is White’s and White’s Move White Win when it is Black’s turn. bm(p:Piece) The moving player can Black’s Move Black Win end the game: winning (checkmate), loosing (resign),
B. Beckert: Formal Formal Specification of Software – p.4 or with a draw.
Example: Chess
A chess game consists of alternate moves of
Black and White. White Behaviour of ChessGame moves first. The game can end both
when it is White’s and White’s Move White Win when it is Black’s turn. bm(p:Piece) The moving player can Black’s Move Black Win end the game: winning (checkmate), loosing (resign),
B. Beckert: Formal Formal Specification of Software – p.4 Example: Chess
A chess game consists of alternate moves of
Black and White. White Behaviour of ChessGame moves first. The game can end both
when it is White’s and White’s Move White Win when it is Black’s turn. bm(p:Piece) The moving player can Black’s Move Black Win end the game: winning (checkmate), loosing (resign), or with a draw. B. Beckert: Formal Formal Specification of Software – p.4 Example: Chess
A chess game consists of alternate moves of
Black and White. White Behaviour of ChessGame moves first. The game can end both
when it is White’s and White’s Move White Win when it is Black’s turn. Draw bm(p:Piece) The moving player can Black’s Move Black Win end the game: winning (checkmate), loosing (resign), or with a draw. B. Beckert: Formal Formal Specification of Software – p.4 States Nodes of the graph Labelled with: name, do-, entry-, exit-action, . . . Initial and final states have special shapes
Transitions Edges of the graph Labelled with: event, guard, action, . . .
State Machines
State Machine Labelled, finite graph (cycles possible)
B. Beckert: Formal Formal Specification of Software – p.5 Transitions Edges of the graph Labelled with: event, guard, action, . . .
State Machines
State Machine Labelled, finite graph (cycles possible)
States Nodes of the graph Labelled with: name, do-, entry-, exit-action, . . . Initial and final states have special shapes
B. Beckert: Formal Formal Specification of Software – p.5 State Machines
State Machine Labelled, finite graph (cycles possible)
States Nodes of the graph Labelled with: name, do-, entry-, exit-action, . . . Initial and final states have special shapes
Transitions Edges of the graph Labelled with: event, guard, action, . . .
B. Beckert: Formal Formal Specification of Software – p.5 Do NOT use State Machines . . . when several objects are involved (interaction diagrams are better)
When to Use State Machines
Use State Machines . . .
at an early stage of software development when behaviour of an object (lifecycle) or operation is not well understood yet
B. Beckert: Formal Formal Specification of Software – p.6 When to Use State Machines
Use State Machines . . .
at an early stage of software development when behaviour of an object (lifecycle) or operation is not well understood yet
Do NOT use State Machines . . .
when several objects are involved (interaction diagrams are better)
B. Beckert: Formal Formal Specification of Software – p.6 Implementation view certain attributes have certain values
State
Abstract view
the same response to the same stimuli the same active behaviour
B. Beckert: Formal Formal Specification of Software – p.7 State
Abstract view
the same response to the same stimuli the same active behaviour
Implementation view
certain attributes have certain values
B. Beckert: Formal Formal Specification of Software – p.7 Role in diagram triggers a transition is “consumed” when transition is executed can be saved under certain circumstances
Event
Properties
observable in the environment of the current object takes place at certain point in time (has no duration) has possibly parameters
B. Beckert: Formal Formal Specification of Software – p.8 Event
Properties
observable in the environment of the current object takes place at certain point in time (has no duration) has possibly parameters
Role in diagram
triggers a transition is “consumed” when transition is executed can be saved under certain circumstances
B. Beckert: Formal Formal Specification of Software – p.8 Types of Events
Signal event An object that is dispatched (thrown) and received (caught)
Call event Represents the dispatch of an operation
Time event Represents the passage of a certain amount of time
Change event Represents the fact that a Boolean expression is changed to true The expression is checked continuously (polling)
B. Beckert: Formal Formal Specification of Software – p.9 Role in diagram triggering controlled by events, guards, state exit conditions execution can cause actions
Transition
Properties
decribes change from one state to another state without duration when executed
B. Beckert: Formal Formal Specification of Software – p.10 Transition
Properties
decribes change from one state to another state without duration when executed
Role in diagram
triggering controlled by events, guards, state exit conditions execution can cause actions
B. Beckert: Formal Formal Specification of Software – p.10 Authentication is done by checking a PIN. The PIN can be correct or not. Unseccessful attempts are counted, If the counter exceeds a limit, the customer is rejected.
Example: ATM
The customer must pass authentication before withdrawing money.
B. Beckert: Formal Formal Specification of Software – p.11 Authentication is done by checking a PIN. The PIN can be correct or not. Unseccessful attempts are counted, If the counter exceeds a limit, the customer is rejected.
Example: ATM
The customer must pass authentication before Customer at ATM withdrawing money.
Authentication WithdrawMoney
B. Beckert: Formal Formal Specification of Software – p.11 The PIN can be correct or not. Unseccessful attempts are counted, If the counter exceeds a limit, the customer is rejected.
Example: ATM
The customer must pass authentication before Customer at ATM withdrawing money. Authentication is done by Authentication WithdrawMoney checking a PIN.
B. Beckert: Formal Formal Specification of Software – p.11 The PIN can be correct or not. Unseccessful attempts are counted, If the counter exceeds a limit, the customer is rejected.
Example: ATM
The customer must pass authentication before Customer at ATM withdrawing money. Authentication is done by Authentication CheckPIN WithdrawMoney checking a PIN.
B. Beckert: Formal Formal Specification of Software – p.11 Unseccessful attempts are counted, If the counter exceeds a limit, the customer is rejected.
Example: ATM
The customer must pass authentication before Customer at ATM withdrawing money. Authentication is done by Authentication CheckPIN WithdrawMoney checking a PIN. The PIN can be correct or not.
B. Beckert: Formal Formal Specification of Software – p.11 Unseccessful attempts are counted, If the counter exceeds a limit, the customer is rejected.
Example: ATM
The customer must pass authentication before Customer at ATM withdrawing money. Guard Authentication is done by CheckPIN Authentication [correct] WithdrawMoney checking a PIN. CheckPIN The PIN can be correct or [incorrect] not.
B. Beckert: Formal Formal Specification of Software – p.11 If the counter exceeds a limit, the customer is rejected.
Example: ATM
The customer must pass authentication before Customer at ATM withdrawing money. Guard Authentication is done by CheckPIN Authentication [correct] WithdrawMoney checking a PIN. CheckPIN The PIN can be correct or [incorrect] not. Unseccessful attempts are counted,
B. Beckert: Formal Formal Specification of Software – p.11 If the counter exceeds a limit, the customer is rejected.
Example: ATM
The customer must pass authentication before Customer at ATM withdrawing money.
Authentication is done by CheckPIN Authentication [correct] WithdrawMoney checking a PIN. CheckPIN [incorrect] The PIN can be correct or /increaseErrCounter Action not. Unseccessful attempts are counted,
B. Beckert: Formal Formal Specification of Software – p.11 Example: ATM
The customer must pass authentication before Customer at ATM withdrawing money.
Authentication is done by CheckPIN Authentication [correct] WithdrawMoney checking a PIN. CheckPIN [incorrect] The PIN can be correct or /increaseErrCounter Action not. Unseccessful attempts are counted, If the counter exceeds a limit, the customer is rejected. B. Beckert: Formal Formal Specification of Software – p.11 Example: ATM
The customer must pass authentication before Customer at ATM withdrawing money.
Authentication is done by CheckPIN Authentication [correct] WithdrawMoney checking a PIN. CheckPIN [incorrect and ErrCnt
Notation Written as
Event[Guard]/Action
within the state box
Example Authentication reset/clearScreen
Difference to self transition Entry and exit actions are not dispatched
B. Beckert: Formal Formal Specification of Software – p.12 Entry and Exit Actions
Notation Written as
entry/Action resp. exit/Action
within the state box
Semantics Dispatched on entering resp. exiting the state
B. Beckert: Formal Formal Specification of Software – p.13 Activities
Notation Written as
do/Action
within the state box
Semantics
have duration can be finished by event for outgoing transitions
B. Beckert: Formal Formal Specification of Software – p.14 Example: ATM (Alternative Formalisation)
Customer at ATM
withdraw(amount) [amount<=balance] /changeAccount
Authentication do/CheckPIN when(correct) WithdrawMoney entry/maskScreen exit/unmaskScreen
deposit(amount) when(incorrect and ErrCnt Closed when(incorrect and ErrCnt>=Max) ˆAuthorization Failed Rejected B. Beckert: Formal Formal Specification of Software – p.15 Exercise A student must complete the basic level before entering the advanced level. After both levels, the student has to pass five examinations. An examination can be retaken at most twice. After the third failed attempt the student’s registration is cancelled. B. Beckert: Formal Formal Specification of Software – p.16 After both levels, the student has to pass five examinations. An examination can be retaken at most twice. After the third failed attempt the student’s registration is cancelled. Exercise: Student A student must complete the basic level before entering the advanced level. B. Beckert: Formal Formal Specification of Software – p.17 After both levels, the student has to pass five examinations. An examination can be retaken at most twice. After the third failed attempt the student’s registration is cancelled. Exercise: Student A student must complete Student the basic level before entering the advanced level. Basic Level Advanced Level B. Beckert: Formal Formal Specification of Software – p.17 An examination can be retaken at most twice. After the third failed attempt the student’s registration is cancelled. Exercise: Student A student must complete Student the basic level before entering the advanced level. After both levels, the Basic Level student has to pass five examinations. Advanced Level B. Beckert: Formal Formal Specification of Software – p.17 An examination can be retaken at most twice. After the third failed attempt the student’s registration is cancelled. Exercise: Student A student must complete Student the basic level before entering the advanced level. passFExa After both levels, the Basic Level /inc(FExaCnt) student has to pass five when(FExaCnt>=5) examinations. passMExa /inc(MExaCnt) Advanced Level when(MExaCnt>=5) B. Beckert: Formal Formal Specification of Software – p.17 Exercise: Student A student must complete Student the basic level before entering the advanced level. passFExa After both levels, the Basic Level /inc(FExaCnt) student has to pass five when(FExaCnt>=5) examinations. passMExa An examination can be /inc(MExaCnt) Advanced Level retaken at most twice. After the third failed attempt the when(MExaCnt>=5) student’s registration is cancelled. B. Beckert: Formal Formal Specification of Software – p.17 Exercise: Student A student must complete Student the basic level before failFExa entering the advanced level. /inc(FailCnt) After both levels, the Basic Level enterFExa Examination passFExa/inc(FExaCnt) student has to pass five when(FExaCnt>=5) examinations. when(FailCnt>=3) passMExa An examination can be /inc(MExaCnt) Advanced Level retaken at most twice. After when(MExaCnt>=5) the third failed attempt the Graduated Cancelled student’s registration is cancelled. B. Beckert: Formal Formal Specification of Software – p.17 Criticism Not really a good model, because . . . the student leaves the basic level to take an exam the student can cheat by repeating a passed exam the student cannot enter parallel exams the student has to complete each exam once tried the student cannot pass exams of the advanced level while in the basic level B. Beckert: Formal Formal Specification of Software – p.18 Advanced Constructs Can Help Deferred event Composite state Concurrent composite state Join state, Fork State Concurrent transition Junction state Sync state B. Beckert: Formal Formal Specification of Software – p.19 1. Event is generated: Event raised (somewhere) by some action 2. Event is conveyed: Event transported to current object (transpotation does not change event) 3. Event is received: Event placed on event queue of current object 4. Event is dispatched Event de-queued from event queue (becomes current event) 5. Event is consumed Event is processed Events: The Detailed View State1 State2 entry/ActEntry1 Ev(Arg)[Guard]/ActTrans(Arg, Arg1) entry/ActEntry2 exit/ActExit1 exit/ActExit2 do/ActDo1 do/ActDo2 B. Beckert: Formal Formal Specification of Software – p.20 2. Event is conveyed: Event transported to current object (transpotation does not change event) 3. Event is received: Event placed on event queue of current object 4. Event is dispatched Event de-queued from event queue (becomes current event) 5. Event is consumed Event is processed Events: The Detailed View State1 State2 entry/ActEntry1 Ev(Arg)[Guard]/ActTrans(Arg, Arg1) entry/ActEntry2 exit/ActExit1 exit/ActExit2 do/ActDo1 do/ActDo2 1. Event is generated: Event raised (somewhere) by some action B. Beckert: Formal Formal Specification of Software – p.20 3. Event is received: Event placed on event queue of current object 4. Event is dispatched Event de-queued from event queue (becomes current event) 5. Event is consumed Event is processed Events: The Detailed View State1 State2 entry/ActEntry1 Ev(Arg)[Guard]/ActTrans(Arg, Arg1) entry/ActEntry2 exit/ActExit1 exit/ActExit2 do/ActDo1 do/ActDo2 1. Event is generated: Event raised (somewhere) by some action 2. Event is conveyed: Event transported to current object (transpotation does not change event) B. Beckert: Formal Formal Specification of Software – p.20 4. Event is dispatched Event de-queued from event queue (becomes current event) 5. Event is consumed Event is processed Events: The Detailed View State1 State2 entry/ActEntry1 Ev(Arg)[Guard]/ActTrans(Arg, Arg1) entry/ActEntry2 exit/ActExit1 exit/ActExit2 do/ActDo1 do/ActDo2 1. Event is generated: Event raised (somewhere) by some action 2. Event is conveyed: Event transported to current object (transpotation does not change event) 3. Event is received: Event placed on event queue of current object B. Beckert: Formal Formal Specification of Software – p.20 5. Event is consumed Event is processed Events: The Detailed View State1 State2 entry/ActEntry1 Ev(Arg)[Guard]/ActTrans(Arg, Arg1) entry/ActEntry2 exit/ActExit1 exit/ActExit2 do/ActDo1 do/ActDo2 1. Event is generated: Event raised (somewhere) by some action 2. Event is conveyed: Event transported to current object (transpotation does not change event) 3. Event is received: Event placed on event queue of current object 4. Event is dispatched Event de-queued from event queue (becomes current event) B. Beckert: Formal Formal Specification of Software – p.20 Events: The Detailed View State1 State2 entry/ActEntry1 Ev(Arg)[Guard]/ActTrans(Arg, Arg1) entry/ActEntry2 exit/ActExit1 exit/ActExit2 do/ActDo1 do/ActDo2 1. Event is generated: Event raised (somewhere) by some action 2. Event is conveyed: Event transported to current object (transpotation does not change event) 3. Event is received: Event placed on event queue of current object 4. Event is dispatched Event de-queued from event queue (becomes current event) 5. Event is consumed Event is processed B. Beckert: Formal Formal Specification of Software – p.20 1. check Guard – if false abort 2. abort ActDo1 3. execute ActExit1 4. execute ActTrans(Arg,Arg1) (syncronous processing, i.e. wait until finished) 5. execute ActEntry2 6. execute ActDo2 Event Processing: The Detailed View State1 State2 entry/ActEntry1 Ev(Arg)[Guard]/ActTrans(Arg, Arg1) entry/ActEntry2 exit/ActExit1 exit/ActExit2 do/ActDo1 do/ActDo2 B. Beckert: Formal Formal Specification of Software – p.21 2. abort ActDo1 3. execute ActExit1 4. execute ActTrans(Arg,Arg1) (syncronous processing, i.e. wait until finished) 5. execute ActEntry2 6. execute ActDo2 Event Processing: The Detailed View State1 State2 entry/ActEntry1 Ev(Arg)[Guard]/ActTrans(Arg, Arg1) entry/ActEntry2 exit/ActExit1 exit/ActExit2 do/ActDo1 do/ActDo2 1. check Guard – if false abort B. Beckert: Formal Formal Specification of Software – p.21 3. execute ActExit1 4. execute ActTrans(Arg,Arg1) (syncronous processing, i.e. wait until finished) 5. execute ActEntry2 6. execute ActDo2 Event Processing: The Detailed View State1 State2 entry/ActEntry1 Ev(Arg)[Guard]/ActTrans(Arg, Arg1) entry/ActEntry2 exit/ActExit1 exit/ActExit2 do/ActDo1 do/ActDo2 1. check Guard – if false abort 2. abort ActDo1 B. Beckert: Formal Formal Specification of Software – p.21 4. execute ActTrans(Arg,Arg1) (syncronous processing, i.e. wait until finished) 5. execute ActEntry2 6. execute ActDo2 Event Processing: The Detailed View State1 State2 entry/ActEntry1 Ev(Arg)[Guard]/ActTrans(Arg, Arg1) entry/ActEntry2 exit/ActExit1 exit/ActExit2 do/ActDo1 do/ActDo2 1. check Guard – if false abort 2. abort ActDo1 3. execute ActExit1 B. Beckert: Formal Formal Specification of Software – p.21 5. execute ActEntry2 6. execute ActDo2 Event Processing: The Detailed View State1 State2 entry/ActEntry1 Ev(Arg)[Guard]/ActTrans(Arg, Arg1) entry/ActEntry2 exit/ActExit1 exit/ActExit2 do/ActDo1 do/ActDo2 1. check Guard – if false abort 2. abort ActDo1 3. execute ActExit1 4. execute ActTrans(Arg,Arg1) (syncronous processing, i.e. wait until finished) B. Beckert: Formal Formal Specification of Software – p.21 6. execute ActDo2 Event Processing: The Detailed View State1 State2 entry/ActEntry1 Ev(Arg)[Guard]/ActTrans(Arg, Arg1) entry/ActEntry2 exit/ActExit1 exit/ActExit2 do/ActDo1 do/ActDo2 1. check Guard – if false abort 2. abort ActDo1 3. execute ActExit1 4. execute ActTrans(Arg,Arg1) (syncronous processing, i.e. wait until finished) 5. execute ActEntry2 B. Beckert: Formal Formal Specification of Software – p.21 Event Processing: The Detailed View State1 State2 entry/ActEntry1 Ev(Arg)[Guard]/ActTrans(Arg, Arg1) entry/ActEntry2 exit/ActExit1 exit/ActExit2 do/ActDo1 do/ActDo2 1. check Guard – if false abort 2. abort ActDo1 3. execute ActExit1 4. execute ActTrans(Arg,Arg1) (syncronous processing, i.e. wait until finished) 5. execute ActEntry2 6. execute ActDo2 B. Beckert: Formal Formal Specification of Software – p.21 1. wait until ActDo1 finishes (raises completion event) 2. check Guard – if false abort 3. execute ActExit1 4. execute ActTrans(Arg1) 5. execute ActEntry2 6. execute ActDo2 Event Processing: Completion Event State1 State2 entry/ActEntry1 [Guard]/ActTrans(Arg1) entry/ActEntry2 exit/ActExit1 exit/ActExit2 do/ActDo1 do/ActDo2 B. Beckert: Formal Formal Specification of Software – p.22 2. check Guard – if false abort 3. execute ActExit1 4. execute ActTrans(Arg1) 5. execute ActEntry2 6. execute ActDo2 Event Processing: Completion Event State1 State2 entry/ActEntry1 [Guard]/ActTrans(Arg1) entry/ActEntry2 exit/ActExit1 exit/ActExit2 do/ActDo1 do/ActDo2 1. wait until ActDo1 finishes (raises completion event) B. Beckert: Formal Formal Specification of Software – p.22 Event Processing: Completion Event State1 State2 entry/ActEntry1 [Guard]/ActTrans(Arg1) entry/ActEntry2 exit/ActExit1 exit/ActExit2 do/ActDo1 do/ActDo2 1. wait until ActDo1 finishes (raises completion event) 2. check Guard – if false abort 3. execute ActExit1 4. execute ActTrans(Arg1) 5. execute ActEntry2 6. execute ActDo2 B. Beckert: Formal Formal Specification of Software – p.22 1. wait until Guard switches from false to true (raises change event) 2. abort ActDo1 3. execute ActExit1 4. execute ActTrans(Arg1) 5. execute ActEntry2 6. execute ActDo2 Event Processing: Change Event State1 State2 entry/ActEntry1 when(Guard)/ActTrans(Arg1) entry/ActEntry2 exit/ActExit1 exit/ActExit2 do/ActDo1 do/ActDo2 B. Beckert: Formal Formal Specification of Software – p.23 2. abort ActDo1 3. execute ActExit1 4. execute ActTrans(Arg1) 5. execute ActEntry2 6. execute ActDo2 Event Processing: Change Event State1 State2 entry/ActEntry1 when(Guard)/ActTrans(Arg1) entry/ActEntry2 exit/ActExit1 exit/ActExit2 do/ActDo1 do/ActDo2 1. wait until Guard switches from false to true (raises change event) B. Beckert: Formal Formal Specification of Software – p.23 Event Processing: Change Event State1 State2 entry/ActEntry1 when(Guard)/ActTrans(Arg1) entry/ActEntry2 exit/ActExit1 exit/ActExit2 do/ActDo1 do/ActDo2 1. wait until Guard switches from false to true (raises change event) 2. abort ActDo1 3. execute ActExit1 4. execute ActTrans(Arg1) 5. execute ActEntry2 6. execute ActDo2 B. Beckert: Formal Formal Specification of Software – p.23 Guard Completion event: guard checked only once (on completion of activity) Change event: guard checked continuously Completion Event vs. Change Event Activity Completion event: after activity has ActDo1 finished Change event: activity ActDo1 is aborted B. Beckert: Formal Formal Specification of Software – p.24 Completion Event vs. Change Event Activity Completion event: after activity has ActDo1 finished Change event: activity ActDo1 is aborted Guard Completion event: guard checked only once (on completion of activity) Change event: guard checked continuously B. Beckert: Formal Formal Specification of Software – p.24 Triggering deferred events A deferred event is activated as soon as a state is entered where it is not deferred Lost events Events that are neither handled nor deferred in the current state are lost Event Processing: Deferred Events Special action defer Ev/defer Puts event Ev in list of deferred events Can only be used in a state (not to label a transition) B. Beckert: Formal Formal Specification of Software – p.25 Lost events Events that are neither handled nor deferred in the current state are lost Event Processing: Deferred Events Special action defer Ev/defer Puts event Ev in list of deferred events Can only be used in a state (not to label a transition) Triggering deferred events A deferred event is activated as soon as a state is entered where it is not deferred B. Beckert: Formal Formal Specification of Software – p.25 Event Processing: Deferred Events Special action defer Ev/defer Puts event Ev in list of deferred events Can only be used in a state (not to label a transition) Triggering deferred events A deferred event is activated as soon as a state is entered where it is not deferred Lost events Events that are neither handled nor deferred in the current state are lost B. Beckert: Formal Formal Specification of Software – p.25 Then . . . 1. event Ev1 is deferred 2. transition from State1 to State2, consuming event Ev 3. event Ev1 is re-activated 4. transition from State2 to State1, consuming Ev1 Event Processing: Deferred Events – Example State1 State2 Ev1/defer Ev entry/ActEntry2 entry/ActEntry1 exit/ActExit2 exit/ActExit1 Ev1 do/ActDo2 do/ActDo1 Scenario State1 is current state Ev1 dispatched first, Ev dispatched afterwards B. Beckert: Formal Formal Specification of Software – p.26 2. transition from State1 to State2, consuming event Ev 3. event Ev1 is re-activated 4. transition from State2 to State1, consuming Ev1 Event Processing: Deferred Events – Example State1 State2 Ev1/defer Ev entry/ActEntry2 entry/ActEntry1 exit/ActExit2 exit/ActExit1 Ev1 do/ActDo2 do/ActDo1 Scenario State1 is current state Ev1 dispatched first, Ev dispatched afterwards Then . . . 1. event Ev1 is deferred B. Beckert: Formal Formal Specification of Software – p.26 3. event Ev1 is re-activated 4. transition from State2 to State1, consuming Ev1 Event Processing: Deferred Events – Example State1 State2 Ev1/defer Ev entry/ActEntry2 entry/ActEntry1 exit/ActExit2 exit/ActExit1 Ev1 do/ActDo2 do/ActDo1 Scenario State1 is current state Ev1 dispatched first, Ev dispatched afterwards Then . . . 1. event Ev1 is deferred 2. transition from State1 to State2, consuming event Ev B. Beckert: Formal Formal Specification of Software – p.26 4. transition from State2 to State1, consuming Ev1 Event Processing: Deferred Events – Example State1 State2 Ev1/defer Ev entry/ActEntry2 entry/ActEntry1 exit/ActExit2 exit/ActExit1 Ev1 do/ActDo2 do/ActDo1 Scenario State1 is current state Ev1 dispatched first, Ev dispatched afterwards Then . . . 1. event Ev1 is deferred 2. transition from State1 to State2, consuming event Ev 3. event Ev1 is re-activated B. Beckert: Formal Formal Specification of Software – p.26 Event Processing: Deferred Events – Example State1 State2 Ev1/defer Ev entry/ActEntry2 entry/ActEntry1 exit/ActExit2 exit/ActExit1 Ev1 do/ActDo2 do/ActDo1 Scenario State1 is current state Ev1 dispatched first, Ev dispatched afterwards Then . . . 1. event Ev1 is deferred 2. transition from State1 to State2, consuming event Ev 3. event Ev1 is re-activated 4. transition from State2 to State1, consuming Ev1 B. Beckert: Formal Formal Specification of Software – p.26 Composite States Purpose Allow to model complex behaviour Idea Similar sub-states are grouped into a composite state (nesting hierarchy is a tree) Composite states can have transitions, entry/exit actions, do activities, . . . (transitions can connect states from different nesting levels) Sub-states “inherit” from the composite state Note State Machines are in fact composite states B. Beckert: Formal Formal Specification of Software – p.27 Composite States: Example On Initial switchOn Off switchOff Go Process Initial, Process are sub-states of On Initial, Process “inherit” transition switchOff B. Beckert: Formal Formal Specification of Software – p.28 On Off switchOn Initial switchOff Go Process Initial switchOn Off switchOff Go switchOff Process Composite States: Three Equivalent Models On Initial switchOn Off switchOff Go Process Note These models are equivalent if entry/exit actions and do activities of On are ignored B. Beckert: Formal Formal Specification of Software – p.29 Initial switchOn Off switchOff Go switchOff Process Composite States: Three Equivalent Models On On Initial switchOn Off switchOn switchOff Go Off Initial switchOff Process Go Process Note These models are equivalent if entry/exit actions and do activities of On are ignored B. Beckert: Formal Formal Specification of Software – p.29 Composite States: Three Equivalent Models On On Initial switchOn Off switchOn switchOff Go Off Initial switchOff Process Go Process Initial switchOn Off switchOff Go Note switchOff Process These models are equivalent if entry/exit actions and do activities of On are ignored B. Beckert: Formal Formal Specification of Software – p.29 Composite States: Active States On Initial switchOn Off switchOff Go Process Active states Sub-state and composite state can be active simultaneously “Active state” now denotes a path from a top-level state to a leaf node in the state hierarchy B. Beckert: Formal Formal Specification of Software – p.30 Composite States: Rules for Entering States On Initial switchOn Off switchOff Go Process Entering a composite state There must be an initial sub-state Entering a sub-state Both the composite state and sub-state are activated Order of entry actions: top-down B. Beckert: Formal Formal Specification of Software – p.31 Composite States: Rules for Exiting States On Initial switchOn Off switchOff Go Process Exiting a composite state Exit active sub-state as well. Exiting a sub-state Order of exit actions: bottom-up When final state becomes active sub-state, completion event is raised B. Beckert: Formal Formal Specification of Software – p.32 Concurrent Composite States Taking Class Incomplete Lab1 lab done Lab2 lab done Project project done Passed Final Test pass fail Failed Regions Concurrent parts of composite state Are activated synchronously (when composite state is acitivated) Separated by dashed lines B. Beckert: Formal Formal Specification of Software – p.33 a sub-tree of the state hierarchy Concurrent Composite States Taking Class Incomplete Lab1 lab done Lab2 lab done Project project done Passed Final Test pass fail Failed Active state Also called state configuration Now consists of ??? B. Beckert: Formal Formal Specification of Software – p.34 Concurrent Composite States Taking Class Incomplete Lab1 lab done Lab2 lab done Project project done Passed Final Test pass fail Failed Active state Also called state configuration Now consists of a sub-tree of the state hierarchy B. Beckert: Formal Formal Specification of Software – p.34 Concurrent Composite States: Rules for Entering Taking Class Incomplete Lab1 lab done Lab2 lab done Project project done Passed Final Test pass fail Failed Entering a composite state There must be an initial sub-state in each region Entering a sub-state There must be an initial sub-state in all other regions B. Beckert: Formal Formal Specification of Software – p.35 Concurrent Transitions Taking Class Incomplete Lab1 lab done Lab2 lab done project done Project Passed pass Final Test fail Failed Concurrent transition Alternative notation for entering concurrent composite state Uses pseude-states “fork” and “join” B. Beckert: Formal Formal Specification of Software – p.36 History States Taking Class Incomplete Lab1 lab done Lab2 lab done Project project done Passed Final Test pass H resume fail Failed outbreak of war Army was killed When re-entering composite state, establishes the last active configuration Outgoing transition indicates default active configuration B. Beckert: Formal Formal Specification of Software – p.37 History States: Shallow vs. Deep Taking Class Incomplete Lab1 lab done Lab2 lab done Project project done Passed Final Test pass H resume fail Failed outbreak of war Army was killed Shallow (H): Records history only of composite state is belongs to Deep (H∗): Records history of sub-states as well B. Beckert: Formal Formal Specification of Software – p.38 Synch States Taking Class Incomplete Lab1 lab done Lab2 lab done * Passed Project project done Final Test pass fail Failed Allow to synchronise regions Used in combination with fork and join B. Beckert: Formal Formal Specification of Software – p.39 Junction Points State1 State2 e1[g1] e2[g2] [g3] [g5] [g4] State3 State4 State5 Purpose Simplify notation, allow to “factor out” transitions Different from fork/join B. Beckert: Formal Formal Specification of Software – p.40 Junction Points Example without junction point State1e2[g2 ande1[g1g3] and g5]State2 e2[g2 and g5] e1[g1 and g3] e2[g2 and g4] e1[g1 and g4] State3 State4 State5 B. Beckert: Formal Formal Specification of Software – p.41 Metamodel for State Machine ModelElement (from core) +context 0..1 +behavior * 1 Guard StateMachine +submachine expression:BooleanExpression 0..1 0..1 +guard 0..1 1 source * * +transitions StateVertex 1 +outgoing Transition target * * 1 +incoming * +internalTransition 0..1 0..1 +top 1 State 0..1 +effect 0..1 0..1 +entry Action SynchState 0..1 0..1 (from CommonBehavior) bound:UnlimitedInteger +exit 0..1 0..1 +trigger 0..1 +doActivity 0..* Event PseudoState 0..* +deferrableEvent kind:PseudostateKind StubState referenceState:Name container CompositeState SimpleState FinalState 0..1 isConcurrent:Boolean B. Beckert: Formal Formal Specification of Software – p.42 PseudoStateKind initial final deepHistory shallowHistory join fork junction B. Beckert: Formal Formal Specification of Software – p.43 context StateMachine inv self.context.notEmpty implies self.context.oclIsKindOf(BehavioralFeature) or self.context.oclIsKindOf(Classifier)) Note Nothing said about what happens if self.context.isEmpty A Constraint of the Meta Model Constraint on context of StateMachine A state machine is aggregated within either a classifier or a behavioural feature (e.g. an operation) B. Beckert: Formal Formal Specification of Software – p.44 A Constraint of the Meta Model Constraint on context of StateMachine A state machine is aggregated within either a classifier or a behavioural feature (e.g. an operation) context StateMachine inv self.context.notEmpty implies self.context.oclIsKindOf(BehavioralFeature) or self.context.oclIsKindOf(Classifier)) Note Nothing said about what happens if self.context.isEmpty B. Beckert: Formal Formal Specification of Software – p.44