Rigorous Specification for Software Systems

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

2. Specifying a System If the systems planners and customer do not specify what is expected in all types of interactions with the system, i.e. the behavior of the system, someone else will. That someone else is most likely the programmer when he or she is coding the ELSE option of some IF statement. There is a very low probability that the programmer’s guesses as to the expected behavior will be what The customer expects. -- James Kowal, “Behavior Models: Specifying User’s Expectations”

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

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

5. A Quick Overview of Function Theory

6. Two Sets In Out b x w d a c z y e 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>}

7. A relation between two sets Out In A relation between two sets that qualifies as a function Out In

8. A complete function Out In Software is a rule for a function A software program is a rule for computing a mathematical function that maps all possible stimulus histories to all possible responses

9. A rigorous specification process • Establish the system boundary • Define the human/software/hardware interfaces • Itemize the stimuli and the responses • Perform the enumeration • Perform the canonical sequence analysis • Generate the state machine specification • Transform the state machine to code or another formal notation

10. Example – Specification of a Security Alarm

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

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

13. 3. Itemize Security Alarm Stimuli 7 • 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

14. 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)

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

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

17. Sequence Enumeration – length 1 Carry to next level

18. Sequence Enumeration – length 2 The discovery and documentation of derived requirements is a natural and desirable part of the sequence enumeration process

19. Sequence Enumeration – length 3

20. Sequence Enumeration – length 4

21. Sequence Enumeration – length 4

22. Sequence Length Five Each entry has an equivalence – Therefore we can stop enumerating!!!

23. 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 case Scenario!!

24. 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 • Construct a table and list the canonical sequences in the order enumerated • Define one of more state variables such that each canonical sequence corresponds to a unique combination of values

25. State data creation • Variables invented to encapsulate conditions in each sequence of stimuli • These represent state data for the system

26. State data creation

27. 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 ____.”

28. State Transition Diagram S,T,B,G/null C/null Device = on Alarm = on Code = none Device = on Alarm = off Code = error T/alarm on B/null B/null S/light on B/null G/null Device = on Alarm = off Code = none S,T,C/null Device = on Alarm = on Code = 1_ok S,C,T/null S,B,C,G/null G/null Device = on Alarm = on Code = 2_ok G/alarm off S,C,T/null

29. Confirmation and analysis - Sequences ending in T

30. Test Case Scenario S,T,B,G/null C/null Device = on Alarm = on Code = none Device = on Alarm = off Code = error T/alarm on B/null B/null S/light on B/null G/null Device = on Alarm = off Code = none S,T,C/null Device = on Alarm = on Code = 1_ok S,C,T/null S,B,C,G/null G/null Device = on Alarm = on Code = 2_ok G/alarm off S,C,T/null

31. Software architecture

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

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

34. “Sequence Enumeration”, Embedded Systems Programming, (embedded.com) • “Cleanroom Software Engineering”, Prowell, Trammell, Linger, Poore, Addison-Wesley, 1998, 0-201-85480-5

35. Backup (clear box implementation)

36. Procedural view Security Alarm; #---------------------------------------------------------------- # Declarations #---------------------------------------------------------------- # Constants CLEAR constant 0; # no error or alarm STOP constant –1; # stops main loop on correct code TRIPSIGNAL constant –99; # hardware trip wire signal SET constant –100; # set button on keypad pressed # Variables Event trigger init (CLEAR); # any keypad entry or hardware signal SecurityStatus boolean init (CLEAR); # alarm on/off

37. Procedural view #---------------------------------------------------------------- # Main Program #---------------------------------------------------------------- # start the device; SB 9 DisplayManager (Start); While (Event != STOP) Do # get next user input or hardware signal get (Event); switch (Event); # SB 10-17

38. Procedural view • # SB 10-17 • case (SET); • # do nothing • # SB 1-8 • case (TRIPSIGNAL) • AlarmManager (Query, SecurityStatus); • if (SecurityStatus = CLEAR) • then • # SB 1,3,4,7 • AlarmManager (Start); • # SB 4,7 • CodeManager (Alert, Event); • # else do nothing; SB 2,5,6,8 • endif

39. Procedural view • # SB 18-37 • default • CodeManager (Evaluate, Event); • # CodeManager will return STOP if code • entry is complete • endswitch • enddo • # SB 38,39 • AlarmManager (Stop); • DisplayManager (Stop); • # end of security Alarm main program

40. Procedural view • DisplayManager (DisplayService); • #------------------------------------------------------------------------ • # Data • #------------------------------------------------------------------------ • # Constants • ON constant 1; # light is on • OFF constant 0; # light is off • # State Data • LightStatus boolean static init (OFF); # device activation • light • #------------------------------------------------------------------------ • # Services • #------------------------------------------------------------------------

41. Procedural view • # SB 9 • Start; • LightStatus := ON; • # SB 38-39 • Stop; • LightStatus := OFF; • # end DisplayManager • AlarmManager (AlarmService, Status); • #------------------------------------------------------------------------ • # Data • #------------------------------------------------------------------------ • # Constants

42. Procedural view • ON constant 1; # alarm is on • OFF constant 0; # alarm is off • # State data • AlarmStatus boolean static init (OFF); # alarm activation • status • #------------------------------------------------------------------------ • # Services • #------------------------------------------------------------------------ • # SB 1,3,4,7 • Start; • AlarmStatus := ON; • Query; • Status = AlarmStatus;

43. Procedural view • # SB 39 • Stop; • AlarmStatus := OFF; • # end AlarmManager • Codemanager (CodeService, Event); • #------------------------------------------------------------------------ • # Data • #------------------------------------------------------------------------ • # Constants • NONE constant 0; # no keypad entry • 1_OK constant 1; # first correct digit in code entered • 2_OK constant 2; # second correct digit in code entered

44. Procedural view • CLEAR constant 0; # Clear button on keypad pressed • COMPLETE constant –1; # correct code entered • ERROR constant –2; # error in code entry • # state data • CodeCombination array static init ([1]:=7; [2]:=5;[3];=7) • # code is 757 • EntryStatus integer static init (NONE); # code entry status • #------------------------------------------------------------------------ • # Services • #------------------------------------------------------------------------ • # SB 4,7 • Alert;

45. Procedural view • if (EntryStatus = 1_OK) | (EntryStatus = 2_OK)) • then EntryStatus := ERROR; • endif • # SB 18-37 • Evaluate; • if (Event = CLEAR) • then • # clear button has been pressed; SB 26-33 • EntryStatus := NONE; • else • # digit has been pressed

46. Procedural view • switch (EntryStatus); • case (NONE) • # SB 34, 35 • if (Event = CodeCombination[1]) • then EntryStatus := 1_OK; • # SB 18, 19 • else EntryStatus := ERROR; • endif • case (1_OK) • # SB 36, 37 • if (Event = CodeCombination[2]) • then EntryStatus := 2_OK; • # SB 21, 23 • else EntryStatus := ERROR; • endif

47. Procedural view • case (2_OK) • # SB 38, 39 • if (Event = CodeCombination[3]) • then EntryStatus := NONE; • Event := COMPLETE; • # SB 24, 25 • else EntryStatus = ERROR; • endif • default • # if EntryStatus = ERROR, do nothing; • SB 20, 22 • endswitch • endif • # end CodeManager

48. Confirmation and analysis - Sequences ending in T

49. 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 2 • SH: Clear 7 1 3 * • S: 6 • Response: Display 6 • What is the effect of pressing 6 ? • It depends • Stimulus history 1 • SH: Clear 7 1 3 • S: 6 • Response: Display 7136

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