Software

Requirements Engineering
Lecture 22
STRUCTURAL & BEHAVIOURAL MODELLING

SESD-2213
FALL 2020

Dr. Anam Mustaqeem

[email protected]
Office: Cabin #2, F303 Building A
OFFICE HOURS: Monday : 10:00 AM- 02:00 PM
Thursday: 10:00 AM- 02:00 PM
State Machine Diagram
4 UML 2.x State Machine Diagrams
 Model discrete behavior (finite state-transition systems)
 System
 Component
 Class
 Protocol

 Several formal definitions as well as textual and graphical syntax of state machines exist
 We focus on the state machines of UML 2.x
 Several techniques and tools exist for defining, analyzing, combining, and transforming (e.g., to code) state
machines
5 Automaton
 A machine whose output depends not only on the input but also on the history of past events
 Its internal state characterizes on
this history

Lamp On
on
ON ON
ON ON

off
OFFOFF
OFF OFF off
Lamp Off
6 Basic Notational Elements of State Machine Diagrams

 Describe the dynamic behavior of an individual object (with states and transitions)
7 Types of State Machines
on on
Lamp On
Lamp On print(”on”)

on/print(”on”) on

off off
off off
Lamp Lamp
Off Off

Mealy Automaton Moore Automaton

 UML allows both types to be mixed
8 Variables (“Extended” States)
on
ctr
ctr :: Integer
Integer
Lamp On

on/ctr := ctr + 1

off
off
Lamp Off
9 Modeling Behavior
 In general, state machines are suitable for describing reactive systems based or events
 Not appropriate to describe continuous systems (e.g., spacecraft trajectory control, stock market predictions)

threshold

time
10
UML State Machine Diagrams – Summary
Composite State
State
Initial
Initial
Pseudostate
Pseudostate top
Trigger
Trigger
Ready
Transition
Transition

stop /ctr := 0

Done
Final State Action
Action
stop
11 Entry and Exit Actions

LampOn
e2
entry/lamp.on();
exit/lamp.off();

e1
12 Action Ordering
LampOn LampOff
off/printf(“to off”);
entry/lamp.on(); entry/lamp.off();
exit/printf(“exiting”); exit/printf(“exiting”);

Resulting action sequence:

off/printf(“needless”);
printf(“exiting”);
printf(“to off”); printf(“exiting”);
lamp.off(); printf(“needless”);
lamp.off();
 Output actions: transition prefix
 Input actions: transition postfix
13 State Activity (Do)
 Creates a concurrent process that will execute until
 The action terminates, or
 We leave the state via an exit transition

“do” activity
Error
entry/printf(“error!”)
do/alarm.ring()
14 Guards (Conditions)
 Conditional execution of transitions
bid [value < 100] /reject

bid [value >= 200] /sell

Selling Happy

bid [(value >= 100) & (value < 200)] /sell

Unhappy

 Guards must not have side effects

15 Hierarchical State Diagrams
 Composed states, to manage complexity

LampOff
flash/ LampFlashing
entry/lamp.off()
FlashOn
FlashOn
off/ entry/lamp.on()

1sec/
on/ 1sec/
on/
FlashOff
LampOn
on/
entry/lamp.off()
entry/lamp.on()
16
Group Transitions
Default
Default transition to
Initial
Initial pseudostate
pseudostate

LampOff
flash/ LampFlashing
entry/lamp.off()
FlashOn
off/ entry/lamp.on()

1sec/
on/ 1sec/
FlashOff
LampOn
on/
entry/lamp.off()
entry/lamp.on()

Group transition
17 Completion Transition
 Triggered by a completion event
 Automatically generated when an embedded state machine terminates

Completion transition
Committing (without trigger)
Phase1
Phase1

CommitDone
Phase2
Phase2
18 Triggering Rules
 Many transitions can share the same triggering event
 When leaving, the most deeply embedded one takes precedence
 The event disappears whether it triggers a transition or not

LampFlashing
FlashOn

on/
off/
on/
FlashOff
19 Action Ordering – Composite States

S1 S2
exit/exS1 entry/enS2

/initS2
S11 E/actE S21
exit/exS11 entry/enS21

Action sequence on transition E:

exS11  exS1  actE  enS2  initS2  enS21
20 Exercise I – Describe this Behavior

 What should be added to this state machine to more fully describe the dialing behavior?
21 “Reusable” State Machines (1)
ReadAmountSM

abort

otherAmount definition
selectAmount
of
exit point
amount
abort
EnterAmount
aborted
definition
of
ok
entry point

again
 22 “Reusable” State Machines (2)

ATM

VerifyCard
use of
acceptCard exit
point
outOfService ReadAmount : aborted
OutOfService ReadAmountSM

again
use of rejectTransaction
entry point releaseCard
VerifyTransaction ReleaseCard

 Encapsulation of a sub-state machines

 Deferred Events (this is called SAVE in SDL)
23  Explicitly select event for later
treatment
 An event may be deferred if it
does not trigger a transition in the
state which defers the event
 Saved until the system is in a
state that does not defer the event Deferred
Deferred Event
 Possible to model a required
event that may occur before or
after another required event

Source: UML Reference Manual

24
History State
 Remember the last active sub-
state before the most recent exit
from the composite state
History State

 Shallow history (H)

 Remember state at the same
nesting depth as history state

 Deep history (H*)

 Remember state at any nesting
depth

Source: UML Reference Manual

25 Orthogonal Regions
 Combine many concurrent perspectives – interactions across regions typically done via shared variables

age
financialStatus

Child

Poor
Adult
age financialStatus

Child Rich
Retiree

Poor
Adult

Retiree Rich
26 Semantics of Orthogonal Regions
 All mutually orthogonal regions detect the same events and respond simultaneously (possibly interleaved)

legalStatus financialStatus

LawAbiding
LawAbiding Poor

robBank/ robBank/

Outlaw Rich
27 Interactions Between Regions
 Typically through shared variables
sane
sane :: Boolean
Boolean
flying
flying :: Boolean
Boolean
Catch22
Catch22
sanityStatus flightStatus

Crazy Flying
Flying
entry/sane
entry/sane :=
:= false;
false; entry/flying
entry/flying :=
:= true;
true;
(flying)/ (sane)/

request
Grounding/ (~sane)/
Sane Grounded
Grounded
entry/sane
entry/sane :=
:= true;
true; entry/flying
entry/flying :=
:= false;
false;
28 Exercise II – Describe this Behaviour

CourseAttempt

Studying

Lab1 lab done Lab2 lab done

project done
Term Project

Final Test pass

fail Failed Passed

29
Advanced Notation: State Machine Inheritance

ATM Behaviour
Statemachine
acceptCard()
outOfService()
amount()

FlexibleATM Behaviour
Statemachine
otherAmount()
rejectTransaction()
30 State Machine Inheritance – ATM
ATM
VerifyCard
{final}
acceptCard

OutOfService outOfService
ReadAmount
{final}

releaseCard
VerifyTransaction ReleaseCard
{final} {final}
31 State Machine Inheritance – Flexible ATM
 States can be added and extended
FlexibleATM {extended}
 Regions can be added and extended
 Transitions can be added or extended ReadAmount {extended}

 Actions may be replaced otherAmount

SelectAmount
 Guards may be replaced
 Targets may be replaced
EnterAmount
 Be very careful. One would like that all
ok
properties that can be proved for the
abstract model, also hold for the detailed
model (and possibly more properties). But rejectTransaction
this is not true in general – it depends on
what extensions have been made. VerifyTransaction
32 Protocol State Machine
 Specifies which operations can be called in which state and under which condition
 Allowed call sequences – legal transitions, order of invocation of operations
 Transitions do not include actions
 May be associated with ports

Door {protocol}

[doorWay.isEmpty()] close/

opened closed
create/

open/ lock/
unlock/

locked
33 Protocol State Machine -Pre/Postconditions

 Transitions specification may include pre- and postconditions

34 Alternative Notation (à la SDL)
Input Idle

Choice
Req(Id)

Action [ID<=10]
[ID>10]

Sequence
MinorReq=Id; MajorReq=Id; Output

Minor(Id) Major(Id)

Busy
State Machine-Based Analysis
36 State Machine-Based Analysis (1)
 Several possible alternatives which depend on the formalisms and tools
 Simulation
 Let the behavior evolve more or less randomly
 Can be interactive

 Test
 Verify that certain traces are supported (or rejected) by the machine

 Reachability analysis
 All states can be reached and all transitions can be traversed
 No unhandled event in each state
 Absence of deadlocks (in communicating state machines)
37 State Machine-Based Analysis (2)
 Conformance checking
 Between two machines (for example, one abstract and the other one more concrete)
 Reduce non-determinism
 Reduce optional behavior (compliant, but some behaviors are not supported)
 Extension (consistent, but some new events are treated and lead to new behaviors)

 Equivalence checking
 Between two machines (for example, one abstract and the other one more concrete)
 Several levels of equivalence: traces, refusals, tests, observational equivalence...
38 State Machine-Based Analysis (3)
 Model checking
 Verifies that the model satisfies temporal logic
properties, for example:
 If A occurs, B could possibly occur
If C occurs, D always occurs

 Traverse systematically all possible behaviors

(execution paths) of the machine
 Generated in advance or on the fly

 Model checker verifies M  P (if not a trace of states and transitions leading to the violation of P is produced)
 Major obstacle is state explosion

 Theorem proving
 Prove by deduction or other formal approaches some properties of the state machine - tools often allow interactive
proving