Formal Specification of Software Uml State Machines

7/28/2019 Formal Specification of Software Uml State Machines

1/99

Formal Specification of Software

UML State Machines

Bernhard Beckert

UNIVERSITT KOBLENZ-LANDAU

B. Beckert: Formal Formal Specification of Software p.1


2/99

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)



3/99

Notions Related to State Machines

State

Transition

Event

Action, Activity

GuardsSending messages

Nesting

Concurrency

History states



4/99

Example: Chess

A chess game consists

of alternate moves of

Black and White. Whitemoves first.



5/99

Example: Chess



Black and White. White

moves first.Behaviour of ChessGame

Whites Move

Blacks Move

State

StateMachine

Initial State

Transition

Event

bm(p:Piece)



6/99

Example: Chess




moves first.

The game can end both

when it is Whites and

when it is Blacks turn.

Behaviour of ChessGame

Whites Move

Blacks Move

State

StateMachine

Initial State

Transition

Event

bm(p:Piece)



7/99

Example: Chess




moves first.





Whites Move

Blacks Move

Final Statebm(p:Piece)



8/99

Example: Chess




moves first.




The moving player can

end the game: winning

(checkmate),


Whites Move

Blacks Move

Final Statebm(p:Piece)



9/99

Example: Chess




moves first.






(checkmate),


Whites Move

Blacks Move

White Win

Black Win

bm(p:Piece)



10/99

Example: Chess




moves first.






(checkmate),

loosing (resign),


Whites Move

Blacks Move

White Win

Black Win

bm(p:Piece)



11/99

Example: Chess




moves first.






(checkmate),

loosing (resign),


Whites Move

Blacks Move

White Win

Black Win

bm(p:Piece)



12/99

Example: Chess




moves first.






(checkmate),

loosing (resign),or with a draw.


Whites Move

Blacks Move

White Win

Black Win

bm(p:Piece)



13/99

Example: Chess




moves first.






(checkmate),

loosing (resign),or with a draw.


Whites Move

Blacks Move

White Win

Black Win

Drawbm(p:Piece)



14/99

State Machines

State Machine

Labelled, finite graph (cycles possible)



15/99

State Machines

State Machine


States

Nodes of the graph

Labelled with: name, do-, entry-, exit-action, . . .

Initial and final states have special shapes



16/99

State Machines

State Machine


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, . . .



17/99

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



18/99

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)



19/99

State

Abstract view

the same response to the same stimuli

the same active behaviour



20/99

State

Abstract view

the same response to the same stimuli

the same active behaviour

Implementation view

certain attributes have certain values



21/99

Event

Properties

observable in the environment of the current object

takes place at certain point in time (has no duration)

has possibly parameters



22/99

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



23/99

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)



24/99

Transition

Properties

decribes change from one state to another state

without duration when executed



25/99

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



26/99

Example: ATM

The customer must pass

authentication before

withdrawing money.


E l ATM


27/99

Example: ATM



withdrawing money.

Customer at ATM

Authentication WithdrawMoney


E l ATM


28/99

Example: ATM



withdrawing money.

Authentication is done by

checking a PIN.

Customer at ATM



E l ATM


29/99

Example: ATM



withdrawing money.


checking a PIN.

Customer at ATM

Authentication WithdrawMoneyCheckPIN


Example ATM


30/99

Example: ATM



withdrawing money.


checking a PIN.

The PIN can be correct or

not.

Customer at ATM

Authentication WithdrawMoneyCheckPIN


Example: ATM


31/99

Example: ATM



withdrawing money.


checking a PIN.


not.

Customer at ATM


Guard

CheckPIN[correct]

CheckPIN

[incorrect]


Example: ATM


32/99

Example: ATM



withdrawing money.


checking a PIN.


not.

Unseccessful attempts are

counted,

Customer at ATM


Guard

CheckPIN[correct]

CheckPIN

[incorrect]


Example: ATM


33/99

Example: ATM



withdrawing money.


checking a PIN.


not.


counted,

Customer at ATM


Action

CheckPIN[correct]

CheckPIN[incorrect]/increaseErrCounter


Example: ATM


34/99

Example: ATM



withdrawing money.


checking a PIN.


not.


counted,

If the counter exceeds a

limit, the customer is

rejected.

Customer at ATM


Action

CheckPIN[correct]

CheckPIN[incorrect]/increaseErrCounter


Example: ATM


35/99

Example: ATM



withdrawing money.


checking a PIN.


not.


counted,

If the counter exceeds a

limit, the customer is

rejected.

Customer at ATM


Rejected

SendEvent

CheckPIN[correct]

CheckPIN[incorrect and ErrCnt=Limit]Authentication Failed


Internal Transitions


36/99

Internal Transitions

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


Entry and Exit Actions


37/99

Entry and Exit Actions

Notation

Written as

entry/Action resp.exit/Action


Semantics

Dispatched on entering resp. exiting the state


Activities


38/99

Activities

Notation

Written as

do/Action


Semantics

have duration

can be finished by event for outgoing transitions


Example: ATM (Alternative Formalisation)


39/99

Example: ATM (Alternative Formalisation)

Customer at ATM

Authentication

do/CheckPINentry/maskScreenexit/unmaskScreen

WithdrawMoney

Rejected

Closed

when(correct)

when(incorrect and ErrCnt=Max)Authorization Failed

deposit(amount)/changeAccount

withdraw(amount)[amount


40/99

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 students registration is cancelled.


Exercise: Student


41/99

A student must complete

the basic level before

entering the advanced level.


Exercise: Student


42/99




Student

Basic Level

Advanced Level


Exercise: Student


43/99




After both levels, the

student has to pass five

examinations.

Student

Basic Level

Advanced Level


Exercise: Student


44/99






examinations.

Student

Basic Level

Advanced Level

when(FExaCnt>=5)

passMExa/inc(MExaCnt)

passFExa/inc(FExaCnt)

when(MExaCnt>=5)


Exercise: Student


45/99






examinations.An examination can be

retaken at most twice. After

the third failed attempt the

students registration is

cancelled.

Student

Basic Level

Advanced Level

when(FExaCnt>=5)



when(MExaCnt>=5)


Exercise: Student


46/99






examinations.An examination can be

retaken at most twice. After

the third failed attempt the

students registration is

cancelled.

Student

Basic Level

Advanced Level

Graduated

Examination

Cancelled

when(FExaCnt>=5)


when(MExaCnt>=5)

when(FailCnt>=3)

failFExa/inc(FailCnt)

enterFExa



Criticism


47/99

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


Advanced Constructs Can Help


48/99

Deferred event

Composite state

Concurrent composite state

Join state, Fork State

Concurrent transition

Junction state

Sync state


Events: The Detailed View


49/99

State1

entry/ActEntry1exit/ActExit1do/ActDo1

State2


Ev(Arg)[Guard]/ActTrans(Arg, Arg1)




50/99

State1


State2



1. Event is generated: Event raised (somewhere) by some action




51/99

State1


State2




2. Event is conveyed: Event transported to current object

(transpotation does not change event)




52/99

State1


State2






3. Event is received: Event placed on event queue of current object




53/99

State1


State2







4. Event is dispatched Event de-queued from event queue

(becomes current event)




54/99

State1


State2







4. Event is dispatched Event de-queued from event queue

(becomes current event)

5. Event is consumed Event is processed


Event Processing: The Detailed View


55/99

State1


State2






56/99

State1


State2



1. check Guard if false abort




57/99

State1


State2




2. abort ActDo1




58/99

State1entry/ActEntry1exit/ActExit1do/ActDo1




2. abort ActDo1

3. execute ActExit1




59/99





2. abort ActDo1

3. execute ActExit1

4. execute ActTrans(Arg,Arg1)

(syncronous processing, i.e. wait until finished)




60/99





2. abort ActDo1

3. execute ActExit1



5. execute ActEntry2




61/99





2. abort ActDo1

3. execute ActExit1




6. execute ActDo2


Event Processing: Completion Event


62/99



[Guard]/ActTrans(Arg1)




63/99




1. wait until ActDo1 finishes (raises completion event)




64/99




1. wait until ActDo1 finishes (raises completion event)


3. execute ActExit1

4. execute ActTrans(Arg1)


6. execute ActDo2


Event Processing: Change Event


65/99



when(Guard)/ActTrans(Arg1)




66/99




1. wait until Guard switches from false to true (raises change event)




67/99




1. wait until Guard switches from false to true (raises change event)

2. abort ActDo1

3. execute ActExit1

4. execute ActTrans(Arg1)


6. execute ActDo2


Completion Event vs. Change Event


68/99

Activity

Completion event: after activity has ActDo1 finished

Change event: activity ActDo1 is aborted


Completion Event vs. Change Event


69/99

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


Event Processing: Deferred Events


70/99

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)




71/99


Ev/defer



Triggering deferred events

A deferred event is activated as soon as a state is entered

where it is not deferred




72/99


Ev/defer



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 Example


73/99

State1Ev1/deferentry/ActEntry1exit/ActExit1do/ActDo1

State2


Ev

Ev1

Scenario

State1 is current state

Ev1 dispatched first, Ev dispatched afterwards




74/99


State2


Ev

Ev1

Scenario



Then . . .

1. event Ev1 is deferred




75/99


State2


Ev

Ev1

Scenario



Then . . .


2. transition from State1 to State2, consuming event Ev




76/99


State2


Ev

Ev1

Scenario



Then . . .



3. event Ev1 is re-activated




77/99


State2


Ev

Ev1

Scenario



Then . . .



3. event Ev1 is re-activated

4. transition from State2 to State1, consuming Ev1B. Beckert: Formal Formal Specification of Software p.26

Composite States


78/99

PurposeAllow to model complex behaviour

Idea

Similar sub-states are grouped into a composite state

(nesting hierarchy is a tree)

Composite states can havetransitions, 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 statesB. Beckert: Formal Formal Specification of Software p.27

Composite States: Example


79/99

Off

On

Initial

Process

switchOn

GoswitchOff

Initial, Process are sub-states of On

Initial, Process inherit transition switchOff


Composite States: Three Equivalent Models


80/99

Off

On

Initial

Process

switchOn

GoswitchOff

NoteThese models are equivalent if

entry/exit actions and

do activities of On

are ignoredB. Beckert: Formal Formal Specification of Software p.29



81/99

Off

On

Initial

Process

switchOn

GoswitchOff Off

On

Initial

Process

switchOn

switchOff

Go



do activities of On




82/99

Off

On

Initial

Process

switchOn

GoswitchOff

Off

Initial

Process

switchOn

switchOff Go

switchOff

Off

On

Initial

Process

switchOn

switchOff

Go



do activities of On


Composite States: Active States


83/99

Off

On

Initial

Process

switchOn

GoswitchOff

Active states

Sub-state and composite state can be active simultaneously

Active state now denotes a pathfrom a top-level state to a leaf node in the state hierarchy


Composite States: Rules for Entering States


84/99

Off

On

Initial

Process

switchOn

GoswitchOff

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-downB. Beckert: Formal Formal Specification of Software p.31

Composite States: Rules for Exiting States


85/99

Off

On

Initial

Process

switchOn

GoswitchOff

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 raisedB. Beckert: Formal Formal Specification of Software p.32

Concurrent Composite States


86/99

Taking Class

Incomplete

Lab1 Lab2

Project

Final Test

Passed

Failed

lab done

project done

pass

lab done

fail

Regions

Concurrent parts of composite state

Are activated synchronously (when composite state is acitivated)

Separated by dashed linesB. Beckert: Formal Formal Specification of Software p.33


T ki Cl


87/99

Taking Class

Incomplete

Lab1 Lab2

Project

Final Test

Passed

Failed

lab done

project done

pass

lab done

fail

Active state

Also called state configuration

Now consists of ???



T ki Cl


88/99

Taking Class

Incomplete

Lab1 Lab2

Project

Final Test

Passed

Failed

lab done

project done

pass

lab done

fail

Active state

Also called state configuration

Now consists of a sub-tree of the state hierarchy


Concurrent Composite States: Rules for Entering

Taking Class


89/99

Taking ClassIncomplete

Lab1 Lab2

Project

Final Test

Passed

Failed

lab done

project done

pass

lab done

fail

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 regionsB. Beckert: Formal Formal Specification of Software p.35

Concurrent Transitions

Taking Class


90/99

Taking Class

Incomplete

Lab1 Lab2

Project

Final Test

Passed

Failed

lab done

project done

pass

lab done

fail

Concurrent transition

Alternative notation for entering concurrent composite state

Uses pseude-states fork and join


History States

Taking Class


91/99


Lab1 Lab2

Project

Final Test

H

Passed

Failed

Army

lab done

project done

pass

lab done

fail

was killed

outbreak of war

resume

When re-entering composite state,

establishes the last active configuration

Outgoing transition indicates default active configurationB. Beckert: Formal Formal Specification of Software p.37

History States: Shallow vs. Deep

Taking Class


92/99


Lab1 Lab2

Project

Final Test

H

Passed

Failed

Army

lab done

project done

pass

lab done

fail

was killed

outbreak of war

resume

Shallow (H): Records history only of composite state is belongs to

Deep (H): Records history of sub-states as well


Synch States

Taking Class


93/99


Lab1 Lab2

*

Project

Final Test

Passed

Failed

lab done

project done

pass

lab done

fail

Allow to synchronise regions

Used in combination with fork and join


Junction Points

State1 State2


94/99

State1 State2

State3 State4 State5

e1[g1]

e2[g2]

[g3]

[g4]

[g5]

Purpose

Simplify notation, allow to factor out transitions

Different from fork/join


Junction Points

Example without junction point


95/99

Example without junction point

State1 State2

State3 State4 State5

e1[g1 and g3]

e1[g1 and g4]

e1[g1 and g5]e2[g2 and g3]

e2[g2 and g4]

e2[g2 and g5]


Metamodel for State Machine

ModelElement

(from core)


96/99

StateMachineGuard

expression:BooleanExpression

StateVertex Transition

PseudoStatekind:PseudostateKind

SynchState

bound:UnlimitedInteger

StubState

referenceState:Name

State

Action

(from CommonBehavior)

Event

CompositeState

isConcurrent:BooleanSimpleState FinalState

+context 0..1

+behavior *

source

1 +outgoing

*

target

1 +incoming

*

0..1

+top 1

0..1

+transitions*1

+guard0..1

*

+trigger 0..1

0..1

+internalTransition*

0..1

+effect0..10..1

+entry

0..1

0..1

+exit

0..1

0..1

+doActivity

0..1

0..* +deferrableEvent

0..*

0..1

container

+submachine

1


PseudoStateKind

initial


97/99

initial

final

deepHistoryshallowHistory

join

fork

junction


A Constraint of the Meta Model

Constraint on context of StateMachine


98/99


A state machine is aggregated within either a classifier or

a behavioural feature (e.g. an operation)


A Constraint of the Meta Model



99/99


A state machine is aggregated within either a classifier or

a behavioural feature (e.g. an operation)

context StateMachine

invself.context.notEmpty implies

self.context.oclIsKindOf(BehavioralFeature) or

self.context.oclIsKindOf(Classifier))

Note

Nothing said about what happens if self.context.isEmpty


Formal Specification of Software Uml State Machines

Documents

Transcript of Formal Specification of Software Uml State Machines