State-based Specification

Miheer Bhachech, Ebru Dincel, Nikunj Mehta

State-based Specification• Describe behavior of a system in terms of possible

states and transitions– Capture the condition of a system in terms of its state

• Hardware and control systems where the behavior of a system is reactive

• State-based specification techniques have:– Explicit description and complete coverage of states

and transitions– Specification language and formal reasoning– Precise mathematics– Analysis tools

Benefits• Objectives

– Clarify requirements

– Locate and correct inconsistency and non-determinism

– Refine requirements consistently into design

– Decomposition of system

– Prove or disprove assertions about system behavior

• End Result– Predictably safe systems, more deterministic behavior

– Links between customer needs and system design

Concepts• State

– A state represents the computational readiness of a system at that instance of time during its lifetime

• Initial state– The state in which a system starts

• Condition– Represents an existing on-going state of the system

• Quantification– The application of a condition over more than one

variable

Concepts (2)• Transition

– A transition is a change in the state of the system

• Event– An event is an instantaneous change in the

environmental or internal condition of a system.

• Action/activity– The function that is carried out or the event that is

emitted upon the transition of the system from one state to another

• Invariant– A global or local property that holds true for the

duration of the system lifetime

Techniques and Methods• Finite state machines• Augmented transition networks• SDL• Petri nets• Sequence diagrams• Statecharts• Computational tree logic• ASLAN specifications• UML state diagrams

Statecharts•Purpose

– Specification and design of discrete-event systems– Provide behavioral description of reactive systems

When event α occurs in state A and condition C is true, transfer state to B•Features

– State-transition diagrams– Hierarchy, concurrency and communication– Uses area and location of graphical objects– Statecharts = state diagrams + depth + orthogonality +

broadcast-communication

Decomposition in Statecharts• Use of higraphs

– Hierarchical graph

• Super-states – Exclusive-OR combination of states– Economize number of arrows

• Abstraction or refinement?– Capture a common property– Bottom up and top-down

• Exclusive disjunction of individual states• Zooming

B

Da

d

bA

C

g(P)

B

Da

d

b

displays

alarms-beepalarm1 beeps

both beep

alarm2 beeps

T hits T1 (P1)

any button pressed

30 sec in alarms-beep

T hits T1 (P)

T hits T2 (P2)

displays

alarms-beep

T hits T1 (P1)

any button pressed

30 sec in alarms-beep

T hits T1 (P)

T hits T2 (P2)

Default and History States• Default states

– Equivalent to start states for FSM

• History– (H) Record of the last

state at the current level

– (H*) Deep history stores last state at all levels current and below

AA

DA

D

alarm1

off

on

d d

HK

G H

H*

A

B

C

D

E

Orthogonality• AND combination of states • Concurrency and synchronization

– Simultaneous transitions in component states

• Independence– Independent transition in one of the component state

• Orthogonality = concurrency + independence• Communication among states by common events• Exits

– Synchronized, independent and -transition exit

A

B

D

C

abin (G)

G

E

g F

d

a

Y

Semantics of statecharts• Challenges

– Depth of states, non-determinism, concurrency– Use of communication mechanism for concurrency– One part generates and all other parts sense it– Atomic event propagation

• State machine– State tree and a set of transitions– Nextstep(X, C, E)– Select relevant transitions by analyzing trigger for E– Check source configuration for ancestral relation of X– Analyze consequences of applying actions of transition– Generate next full basic configuration

Additional features• Condition and selection entrances

– Abbreviated decisions

• Parameterized states– Repeating structure across states,

• Delays and timeouts– Prevent starvation and deadlocks

• Overlapping states– Convert XOR into OR

• Non-determinism– Assign probabilities to transitions

Integration With Other Methods• Pure statecharts represent control part only

– Internal state change

• Actions and activities– Generate events and change value of conditions

• Activity charts for functional description• Module charts for structural description• Specify eventualities, absence of deadlocks,

timing constraints using TL– Synthesis of statecharts from TL specs– Describe scenarios using TL and derive statecharts

from a large set of scenarios

Merits and demerits• No explosive growth of states• Can be refined into designs• Simple but powerful notation and techniques• Tool support for editing and analysis -

STATEMATE• Strong semantic underpinning• Rich graphical notation• Difficult to synthesize complex systems• Mapping between hierarchies of states and

hierarchies of objects

Requirements Modeling• Applicable to verify

– Safety properties of event-driven systems

• Premise– Informal requirements specs

– Implicit assumptions about the system

• Formal Method– Requirement specs

• An informal description of system behavior

– Formalizing requirements• Adding the implicit assumptions in the specs

• Dealing with non-determinism, ambiguity

– Automated Model checking using logical formulas

SCR Concepts• Mode

– Set of system states that share a common property

• Modeclass– Set of modes, describing one aspect of the system’s behavior

• Mode transition– Occurs between modes in the same modeclass due to system

changes– Specified by conditions and events

• Software requirements document– An informal specification of a system’s behavior

• Safety properties– Global assertions, system invariants– System properties that must always hold

SCR Semantics• Events

– @T(Cond1) – specifies the point in time when value of condition Cond1 changes from false to true

– Cond1 is the events’ triggered condition– @T(Cond1) WHEN [Cond2] – event of Cond1 becoming true

while condition Cond2 is also true– Cond2 is the events’ WHEN condition

• Event Occurrence– Event @T(A) WHEN [B]– Three definitions of event occurrence

• B is true throughout [t@T(A) - €, t@T(A) ]• B is true throughout [t@T(A), t@T(A) + € ]• B is true throughout [t@T(A) - €, t@T(A) + € ]

– We shall use the last definition since it distinguishes between WHEN conditions and triggered conditions

SCR Example

TABLE 1: Mode Transitions For Temperature Control System

• Each row specifies the event causing the transition from left mode to right mode

• Some Global Constraints– OFF => ~Running– INACTIVE => (Running & TempOK)– HEAT => (Running & BelowDesiredTemp)– (Running&BelowDesiredTemp=>(HEAT | O(HEAT)))

Current

Mode

Running Below Temp OK Above

Desired Desired

Temp Temp

New

Mode

OFF @T - t -

@T t - -

@T - - t

INACTIVE

HEAT

AC

HEAT @F - - -

- - @T -

OFF

INACTIVE

Formalizing SCR Requirements• Implicit assumptions are added for automatic verification

– Temperature cannot be Above, Below and OK simultaneously

• Sequences of Instantaneous mode transitions – Example: HEAT-INACTIVE-OFF

– Adding a new distinct mode transition (HEAT-OFF)

– Desired level of determinism is achieved

• Detecting instances of nondeterminism– Event (@F(Running)&@T(TempOk)) in HEAT triggers transitions

into both OFF and INACTIVECurrent

Mode

Running Below Temp OK Above

Desired Desired

Temp Temp

New

Mode

OFF @T f t f

@T t f f

@T f f t

INACTIVE

HEAT

AC

HEAT @F - - -

t @F @T f

OFF

INACTIVE

FORMALIZED MODE TRANSITIONS

Model Checking• Verification of safety properties• System is represented as a finite state machine• Transition conditions(input condition values)• Attributes• Safety properties-temporal formulas

– Every atomic proposition is a CTL formula– If f & g are CTL formulas, so are ~f, f&g, f|g, AXf, EXf, A[ fUg ], E[ fUg ], AFf, EFf, AGf, EGF, AGf, EGF

• We are interested in formulas of the form AGf since safety properties are invariant – for model verification– Examples

• AG(OFF -> ~Running)• AG(INACTIVE -> (Running & TempOK))

Requirements to CTL Machines• CTL states

– mode state - represents the system in the mode– exit state - represents the system leaving the mode

• Marks readiness of the system to allow a state change

~Running & AboveDesiredTemp & RUNNING & AboveDesiredTemp & ~TempOk & ~BelowDesiredTemp ~TempOk & ~BelowDesiredTemp

~Running & TempOK & RUNNING & TempOK & ~BelowDesiredTemp & ~BelowDesiredTemp &

~AboveDesiredTemp ~AboveDesiredTemp

RUNNING & BelowDesiredTemp & ~TempOK & ~AboveDesiredTemp

~Running & BelowDesiredTemp & ~TempOK & ~AboveDesiredTemp

Fig. 2. CTL representation of multiple SCR events

Off NoFailure

Off NoFailure Exit

Off NoFailure Exit

Off NoFailure Exit

Invariant Properties• Mode invariants –

– invariant properties of a system mode

– true when system enters the mode, and is in the mode

– Becomes true or false when system leaves the mode

– EG: ~Running is an invariant property of mode OFF

• State invariants - conditions that are always true when the CTL machine is in that state

• Mode and state invariants must be equivalent

• First Scenario:– State invariant is stronger than the mode invariant

INV

C ~C C ~C

Fig. 3. State Invariant stronger than the mode invariant Fig.4. State Invariant equals the mode invariant

Global Global Exit Global Global

Invariant Properties• Second Scenario:

– Solution to the first problem results into a second scenario

– State invariant is weaker than the mode invariant.

E A & B

~A & B

E ~E

Fig. 5. State invariant is weaker than the mode invariant

E A & B

~A & B & E

E ~E

Fig. 6. State invariant equals the mode invariant

ModeX1 ModeY1

ModeX1 ModeY1

ModeX1 ModeY1 Exit

ModeX1 ModeY1 Exit

ModeX2 ModeY1

ModeX1 ModeY2

ModeX1 ModeY1 Exit

ModeX1 ModeY1 Exit

ModeX2 ModeY1

ModeX1 ModeY2

Merits & Demerits The specification language is intuitive and scalable

• Clarifies customer requirements• Reveals any ambiguity or nondeterminism• Provides deterministic requirement specifications

Analysis is automated No Concurrency issues have been addressed

– Single modeclass examples have been discussed– How are multiple modeclasses shown ?– How do they communicate ?– What happens to scalability ?

• Adding more modeclasses increase number of modes, hence number of states resulting in complexity of states

Model checker is restricted to the study of FSM– System need not be an FSM– Requirement specs must be an FSM

A Specification LANguage• Purpose

– Is specification correct with respect to critical requirements?

– Generates lemmas (correctness conjecture)

• Features– Hierarchical– Based on first order Predicate logic– Built on a FSM

• Elements• state variables• Invariants• transitions

Notation• State variables change through transitions

• X’= before X= after

• e.g. A clock model

Transition Tick

Current_Time= Current_Time’ + 1

Mathematical Approach• System should always satisfy critical

requirement

• Basis of induction– Start with state invariant satisfying initial state

• Initial condition– initial_assertion invariant_assertion

• Inductive step– invariant_assertion’ & T invariant_assertion

ASLAN Example• Critical requirement :

– the number of items in warehouse is never less than zero

• Initial_assertion: – INITIAL Inventory >= 0

• Invariant_assertion: – INVARIANT Inventory >= 0

• Correctness conjecture: – Inventory >= 0 Inventory >= 0

Entry & Exit Assertions• Entry Assertion

– Inventory > 0

• Exit Assertion– Inventory = Inventory’ - 1

• Inductive step: – invariant_assertion’ & entry_assertion’ &

exit_assertion invariant_assertion

Inventory’ >= 0 & Inventory’ > 0 & Inventory = Inventory’ – 1 Inventory >= 0

Top level specificationSPECIFICATION Authentication LEVEL Top_LevelTYPE

Log_Entry IS STRUCTURE OF (Who:User, When:Time, Tried: Password, Result:BOOLEAN)CONSTANTPassword_Ok(Password, Password): BOOLEAN VARIABLECurrent_Time: Time,Login_Allowed, Sound_Alarm: BOOLEAN INVARIANTFORALL le: Log_Entry (le ISIN Log-- Password_Ok (User_Password(le[Who]),

le[Tried]) = le[Result]) TRANSITION Login (u:User, p:Password)

EXIT Log=Log’ UNION {le: Log_Entry (le[Who]=u & le [When]=Current_Time & le[Tried]=p & le[Result]=Password_Ok(User_Password(u),p))}& Current_Time>Current_Time’ IF Password_Ok(User_Password(u),p)THEN Login_Allowed & ~Sound_Alarm ELSE ~Login_Allowed & Sound_AlarmFI

END Top_Level END Authentication

No Change States• Certain state variables are not

mentioned in assertions – Assume no change in value– Exit value = Entry value

1) Variables whose new values were not referred in EXIT assertion2) If new value of a state variable is mentioned in THEN(ELSE), but not

in ELSE (THEN), assumed not to change in ELSE(THEN)3) If new value of a state variable is referred in one half of ALT

(procedural disjunction) not in the other, conjoin NOCHANGE to the half where it is not mentioned

Unparametrized ExampleUser_Ok(p) & Login_Allowed ALT ~User_Ok(p) & Sound_Alarm

User_Ok(p) & Login_Allowed & Sound_Alarm= Sound_Alarm’

ALT

~User_Ok(p) & Sound_Alarm & Login_Allowed= Login_Allowed’

Procedural vs. Nonprocedural• Easy vs. harder implementation• Problems with quantification: generated

nochanges are universal, consistency problems• E.g.IF predicate1 THEN x(1)=1 ELSE x(2)=2 FI 

IF predicate1 THEN x(1)=1 & FORALL i: INTEGER (~(i=1| i=3 | i=4) - x(i)=x’(i))

ELSE x(2)=2 & FORALL i: INTEGER (~(i=2| i=3 | i=4) - x(i)=x’(i))

Merits and Demerits Easier to grasp Provides both logical and procedural

constructs Hierarchy supportedNo conditional statement within

quantificationStill need theorem prover for verification

Real-Time Systems and Object Paradigm

• Real-Time System– A software system that maintains an ongoing and

timely interaction with its environment.

• Maintaining an ongoing interaction ?• System is constant, behavior comes and goes• Software – structure of interacting dynamic

components• More importance is given on structure• Models have to be predictive, hence model not

only structure & behavior, but also logical and physical resources and engineering infrastructure

Modeling Real-Time Behavior• Concurrent System

– More than one flow of control– Multiple things take place at a time

• UML Active objects– An object that owns a process or thread and can

initiate control activity

• Behavior modeling– Event-driven(reactive) behavior modeling– Time-driven behavior modeling

Event-driven behavior modeling• Functional behavior

– Processing of services

• Control behavior– Actions performed as a controlled entity within the

overall system

• Transition system formalism– Model of an entity that performs a transition from one

state to another in reaction to the arrival of an event– Activity – event-response pairs– Concurrency and priority

• Example: UML state machines– Resolves problem of conflicting control & functional

behaviors in a RTS

UML State Machines• Example: ackB/ reset/

send/^A reset

data/

data/

stop/ start/

error/

ackA/ send/^B

Fig. 3. Functional Behavior: a communication protocol handler Fig. 4. A typical control behavior

• Two different state machines describing different aspects of the same object

• Have to be combined in some way

ReadyToSendA

SendingA

ReadyToSendB

SendingB

Uninitialized

Operational

Initialized Error

Hierarchical states and transitions• Yields a nice separation of the two behaviors

• Modification can be made independently

• Using inheritance, the same control behavior can be used for modeling similar control behaviors

reset/ reset/

data/

data/

stop/ start/ error/

Operational

Uninitialized

ErrorInitialized

ReadyToSendA

ReadyToSendB

SendingBSemdomgA

Time-driven behavior modeling• Based on periodic activities

• State machines can be used at the highest level of description of an object

• Periodic behavior is activated by a periodic timeout event

• When a timeout occurs, an internal transition associated with the operational state is triggered– The action associated with the transition is a periodic activity

• Same object can perform multiple periodic activities at different rates, each of which handled by a separate transition triggered by it’s own timer.

Modeling Inter-object Behavior • Modeling behavior of a set of collaborating objects

– Collaboration: society of classes, interfaces, and other elements that work together to provide some cooperative behavior

• Different ways of modeling provided by UML– Sequence diagrams: show a set of objects & the messages sent and

received by those objects, emphasizing on timing order of message– Interactions: a behavior comprising of a set of messages

exchanged among a set of objects, to accomplish a purpose.– Activity diagrams: shows the flow from activity to activity within

a system. Illustrates the dynamic view of the system– Protocols: a special type of UML collaboration that specifies the

set of valid message exchange sequences• Defined independently of any specific objects or class• Reusable

Architectural Modeling• Formalizing architectural specifications

models can be analyzed for consistency and completeness models are executable and allow early and precise assessment implementations can be derived directly from architectural

specifications using automatic code generation

• Capsule– An active object that may have an internal structure described by a

collaboration diagram

– recursion allows modeling of complex structures

– One or more ports handle all incoming & outgoing communications within a capsule

– Makes the capsule a self-contained component, fully reusable

Rose RealTime• comprehensive visual development environment

• powerful combination of notation, processes, and tools to meet real-time challenges

• Automatic generation of complete C++ executables directly from system or component models

• The Rose RealTime DOORS Link – Integration to DOORS requirements management tool & Rose

RealTime modeling tool.

– Provides the ability to link and trace requirements to software design elements and vice versa.

– Ability to identify requirements not address in the design

– Associates requirements to specific elements of the design

Merits & Demerits UML is a standard for modeling system

requirements and design Easy to understand Reusable stereotypes e.g Real Time clock Provide a view of the system from an

implementation aspect Models are analyzable and executableUML formalism is an issueAmbiguous interpretations of a modelModel verification is doubtful