Sequence Enumeration – A Method of Rigorous Specification for Software Intensive Systems

Sequence Enumeration – A Method of Rigorous Specification for Software Intensive Systems

Specifying a SystemIf the systems planners and customer do notspecify what is expected in all types of interactionswith the system, i.e. the behavior of the system,someone else will. That someone else is mostlikely the programmer when he or she is codingthe ELSE option of some IF statement. There is avery low probability that the programmer’sguesses as to the expected behavior will be whatThe customer expects.

-- James Kowal, “Behavior Models: SpecifyingUser’s Expectations”

How do we ensure correct operation of software? Testing?

A sampling process As complexity increases, a sufficient sample becomes

more impractical Peer reviews?

Often subjective Labor intensive No objective criteria for sufficiency

A better approach Derive mathematically rigorous specification and

design from requirements Prove critical design properties using basic

mathematics of software

Goal: Complete, consistent, correct

• “Complete” All possible stimulus histories have been mapped to their corresponding responses.

• “Consistent” No history has been mapped to more than one response or one set of responses.

• “Correct” The domain, range, and mapping have been properly specified in the judgement of the domain experts.

A Quick Overview of Function Theory

Two Sets

In Out

ab

c

d x

y ze

w

In X Out = { <a,b> | a X, b Y } = <a,x>, <a,w>, <a,y>, <a,z>, <b,x>, <b,w>, <b,y>, <b,z>, <c,x>, <c,w>, <c,y>, <c,z>,<d,x>, <d,w>, <d,y>, <d,z>, <e,x>, <e,w>, <e,y>, <e,z>}

A relation between two sets

A relation between two sets that qualifies as a function

In

In

Out

Out

A complete function

Software is a rule for a function

A software program is arule for computing a mathematical function thatmaps all possible stimulushistories to all possible responses

OutIn

A rigorous specification process1. Establish the system boundary2. Define the human/software/hardware

interfaces3. Itemize the stimuli and the responses4. Perform the enumeration5. Perform the canonical sequence analysis6. Generate the state machine specification7. Transform the state machine to code or

another formal notation

Example – Specification of a Security Alarm

1. System Boundary Definition Determines which components are

inside and outside the system Entities outside are sources of stimuli and

destination of responses Identification begins at the atomic level Abstractions invented to simplify the

enumeration process Used to hide well-known details Reflect natural partitions in the product Reduce a large set of elements to a smaller

set

1,2. System Boundary and interfaces

Stimulus; an event resulting in information flow from the outside to the inside of the system boundary

Output; externally observable item of information flow from inside to outside the system boundary

Response; occurrence of one or more outputs caused by a stimulus

3. Itemize Security Alarm Stimuli

Trip, Set, Clear are atomic stimuli GoodDigit and BadDigit are abstractions (single

stimulus respresenting multiple events) Represent correct and incorrect behavior of digits in a

three-digit code Abstraction serves the purpose of hiding well

understood atomic level details (whether a digit is good or bad) Must be defined by disjoint predicates representing all

possible stimuli

7

3. Itemize Security Alarm Responses

Two additional responses used in sequence enumeration Null response; occurs when there is no external system

response System ignoring stimuli System accumulating stimuli

Illegal response; sequence is impossible (e.g. stimuli presented before invocation)

4. Sequence-based Enumeration Process Define response to all possible stimulus sequences by considering

them in order of length Continue until all sequences of a given length are either illegal or

equivalent to previous sequences Identify canonical sequences Stimulus sequence is

Illegal by definition if it is impossible for the system to observe it or for the environment to generate it

Illegal by design if the system design is intended to prevent either generation or observation of it

A sequence is Equivalent to another sequence if their responses to the same

future stimuli are identical Reduced if it has been declared equivalent to a previous sequence Canonical if it is legal and unreduced when enumeration is

complete

Enumeration Mechanics For each stimulus sequence of length n;

If illegal, mark it illegal and do not extend further

Document correct response based on requirements

If no requirement found, create derived requirement

Record requirements trace Check for equivalence with previous

sequences Extend only those sequences that are not

illegal or equivalent

Sequence Enumeration – length 1

Carry toCarry tonext levelnext level

Sequence Response Equivalence Requirements trace number

Length 2

SS Null S

ST Alarm on 4

SB Null S D2; Digit entries ignored until alarm on

SC Null S

SG Null S D2; Digit entries ignored until alarm on


The discovery and documentation of derived requirements is a naturaland desirable part of the sequence enumeration process


Length 3

STS Null ST D4; ignore set after first occurrence

STT Null ST D5; ignore Trip after first occurrence

STB Null 7

STC Null ST

STG Null 5



Length 4

STBS Null STB D3; after bad digit entry, wait for clear

STBT Null STB D3; after bad digit entry, wait for clear

STBB Null STB 7

STBC Null ST 7 - Hitting the clear button resets

STBG Null STB 7 - One bad digit means must reset



Length 4

STGS Null STG D4; ignore set after first occurrence

STGT Null STG D5; ignore Trip after first occurrence

STGB Null STB Any B digit means reset

STGC Null ST Hitting the clear button resets - 7

STGG Null Two good digits entered


Sequence Length FiveSequence Response Equivalenc

eRequirements trace

Length 5

STGGS Null STGG D2

STGGT Null STGG D6

STGGB Null STB D3

STGGC Null ST D4

STGGG Alarm off, Light off

Empty 3, 5, 6

Each entry has an equivalence –Therefore we can stop enumerating!!!

Enumeration complete Every scenario has been mapped to a response (complete) Every scenario has been mapped to only one response (set),

(consistent) Requirements can now confirm that assumptions and derived

requirements are correct A sequence represents a scenario of use Sequence enumeration reveals;

Possible scenarios Impossible scenarios Intended uses Erroneous use Reducible sequences Irreducible sequences

Use caseScenario!!

5. Canonical sequence analysis Legal sequences in the enumeration that are not

equivalent to any previous sequence are canonical Represent unique conditions of system usage Analysis reveals the state space for the system (at

current level of abstraction) State data used to encapsulate and retain the

components of stimulus history that must be preserved for the system to produce the correct response

1. Construct a table and list the canonical sequences in the order enumerated

2. Define one of more state variables such that each canonical sequence corresponds to a unique combination of values

Canonical sequence

State variables

Value before current stimulus

Value after current stimulus

Empty N/A

S; the user has pressed the set button to activate the device

DEVICE OFF ON

ST; the device has been set and the trip signal has occurred, setting off the device

DEVICE

ALARM

ON

OFF

ON

ON

State data creation Variables invented to encapsulate conditions in each

sequence of stimuli These represent state data for the system

Canonical sequence

State variables

Value before current stimulus

Value after current stimulus

STB; the device has been set, the trip signal has occurred and one bad digit has been entered (Clear must now be pressed)

DEVICE

ALARM

CODE

ON

ON

NONE

ON

ON

ERROR

STG; the device has been set, the trip signal has occurred and one good digit has been entered

DEVICE

ALARM

CODE

ON

ON

NONE

ON

ON

1_OK

STGG; the device has been set, the trip signal has occurred and two good digits has been entered

DEVICE

ALARM

CODE

ON

ON

1_OK

ON

ON

2_OK

State data creation

State Variables

Recast as a State-based Specification “When the system receives the stimulus

____ and the state data values are ____, the system response is ____ and the state update is ____. This use can be traced to sequence ____.”

State Transition Diagram

S/light onDevice = onAlarm = offCode = none

T/alarm on

Device = onAlarm = onCode = none

Device = onAlarm = offCode = error

S,B,C,G/null

B/null

C/null

S,T,C/null

G/null B/null

Device = onAlarm = onCode = 1_ok

B/null

G/null

G/alarm off Device = onAlarm = onCode = 2_ok

S,C,T/null

S,T,B,G/null

S,C,T/null

Confirmation and analysis - Sequences ending in TSequence Response

T Illegal

ST Alarm on

STT Null

SBT Alarm on

SGT Alarm on

STBT Null

STGT Null

SGGT Alarm on

STGGT Null

Test Case Scenario

S/light onDevice = onAlarm = offCode = none

T/alarm on

Device = onAlarm = onCode = none

Device = onAlarm = offCode = error

S,B,C,G/null

B/null

C/null

S,T,C/null

G/null B/null

Device = onAlarm = onCode = 1_ok

B/null

G/null

G/alarm off Device = onAlarm = onCode = 2_ok

S,C,T/null

S,T,B,G/null

S,C,T/null

Software architecture

Some helpful tips

Does not have to be an “all or nothing” approach (use when needed)

Great for testing Force decisions when stuck Most useful for UI and real-time systems with

lots of stimuli and/or functions that are not well defined

Conclusion Sequence enumeration leads to complete, consistent,

traceable, and verifiably correct specifications State data values, system response, and state update

requirements for every scenario have been defined, so the specification is complete

State data values, system response, and state update requirements for every scenario have been unambiguously defined , so the specification is consistent

Sequence enumeration leads to complete, consistent, traceable, and verifiably correct specifications Each element of the state-based specification can be

compared to the corresponding element of the previously verified sequence-based specification to confirm that correctness has been preserved

“Sequence Enumeration”, Embedded Systems Programming, (embedded.com)

“Cleanroom Software Engineering”, Prowell, Trammell, Linger, Poore, Addison-Wesley, 1998, 0-201-85480-5

Backup (clear box implementation)

Procedural view

Security Alarm;#----------------------------------------------------------------# Declarations#----------------------------------------------------------------# ConstantsCLEAR constant 0; # no error or alarmSTOP constant –1; # stops main loop on

correct codeTRIPSIGNAL constant –99; # hardware trip wire signalSET constant –100; # set button on keypad

pressed# VariablesEvent trigger init (CLEAR); # any keypad entry or

hardware signalSecurityStatus boolean init (CLEAR); # alarm on/off

Procedural view

#----------------------------------------------------------------# Main Program#----------------------------------------------------------------# start the device; SB 9DisplayManager (Start);

While (Event != STOP)Do

# get next user input or hardware signalget (Event);

switch (Event);

# SB 10-17

Procedural view# SB 10-17case (SET);

# do nothing

# SB 1-8case (TRIPSIGNAL)

AlarmManager (Query, SecurityStatus);if (SecurityStatus = CLEAR)then

# SB 1,3,4,7AlarmManager (Start);# SB 4,7CodeManager (Alert, Event);

# else do nothing; SB 2,5,6,8endif

Procedural view# SB 18-37default

CodeManager (Evaluate, Event);# CodeManager will return STOP if code

entry is completeendswitch

enddo

# SB 38,39AlarmManager (Stop);DisplayManager (Stop);

# end of security Alarm main program

Procedural viewDisplayManager (DisplayService);#------------------------------------------------------------------------# Data#------------------------------------------------------------------------# ConstantsON constant 1; # light is onOFF constant 0; # light is off

# State DataLightStatus boolean static init (OFF); # device activation

light#------------------------------------------------------------------------# Services#------------------------------------------------------------------------

Procedural view# SB 9Start;

LightStatus := ON;# SB 38-39Stop;

LightStatus := OFF;

# end DisplayManager

AlarmManager (AlarmService, Status);#------------------------------------------------------------------------# Data#------------------------------------------------------------------------# Constants

Procedural viewON constant 1; # alarm is onOFF constant 0; # alarm is off# State dataAlarmStatus boolean static init (OFF); # alarm activation

status#------------------------------------------------------------------------# Services#------------------------------------------------------------------------# SB 1,3,4,7Start;

AlarmStatus := ON;Query;

Status = AlarmStatus;

Procedural view# SB 39Stop;

AlarmStatus := OFF;

# end AlarmManager

Codemanager (CodeService, Event);#------------------------------------------------------------------------# Data#------------------------------------------------------------------------# ConstantsNONE constant 0; # no keypad entry1_OK constant 1; # first correct digit in code entered2_OK constant 2; # second correct digit in code entered

Procedural viewCLEAR constant 0; # Clear button on keypad

pressedCOMPLETE constant –1; # correct code enteredERROR constant –2; # error in code entry

# state dataCodeCombination array static init ([1]:=7; [2]:=5;[3];=7)

# code is 757EntryStatus integer static init (NONE); # code entry status#------------------------------------------------------------------------# Services#------------------------------------------------------------------------# SB 4,7Alert;

Procedural viewif (EntryStatus = 1_OK) | (EntryStatus = 2_OK))then EntryStatus := ERROR;endif

# SB 18-37Evaluate;

if (Event = CLEAR)then

# clear button has been pressed; SB 26-33EntryStatus := NONE;

else# digit has been pressed

Procedural viewswitch (EntryStatus);

case (NONE)# SB 34, 35if (Event = CodeCombination[1])then EntryStatus := 1_OK;# SB 18, 19else EntryStatus := ERROR;endif

case (1_OK)# SB 36, 37if (Event = CodeCombination[2])then EntryStatus := 2_OK;# SB 21, 23else EntryStatus := ERROR;endif

Procedural viewcase (2_OK)

# SB 38, 39if (Event = CodeCombination[3])then EntryStatus := NONE;Event := COMPLETE;

# SB 24, 25else EntryStatus = ERROR;endif

default# if EntryStatus = ERROR, do nothing;

SB 20, 22endswitch

endif# end CodeManager

Confirmation and analysis - Sequences ending in TSequence Response

T Illegal

ST Alarm on

STT Null

SBT Alarm on

SGT Alarm on

STBT Null

STGT Null

SGGT Alarm on

STGGT Null

Behavior view Defines required external behavior for all possible

circumstances of use Receives stimulus, S, from environment and

produces response, R to environment Response depends on current stimuli and history of

stimuli received so far No knowledge of internal behavior State free and procedure free Mathematically, SH R

What is the effect of pressing 6 ? It depends Stimulus history 1

SH: Clear 7 1 3 S: 6 Response: Display 7136

• What is the effect of pressing 6 ?• It depends• Stimulus history 2

– SH: Clear 7 1 3 *– S: 6– Response: Display 6

State view Defines the state space Encapsulate stimulus history as state data

(procedure free) (old state, stimulus) (new state,

response) Preserves black box specification Several possible state implementations of

the black box

Clear Box view Defines processing required to

implement the defined state behavior

Computer program that accepts stimulus, S, and, using the state data defined, produces response, R

Several possible implementations (old state, stimulus) (new state,

response), by procedure

Documents

Sequence Enumeration – A Method of Rigorous Specification for Software Intensive Systems