Personal Software Process for Engineers: Part II Designing and Verifying State Machines

1. Personal Software Process for Engineers: Part II Designing and Verifying State Machines SM

2. Lecture Topics • The design process • Design representation • State machines • The state specification template • Designing state machines • Verifying state machines

3. The Design Process • Software design is the creative process of producing a precise and effective solution to a poorly-defined problem. • The design process cannot be • reduced to a routine procedure • automated • precisely controlled or predicted • The design process can be structured to • separate the routine from the creative activities • ensure that the design work is performed properly • identify effective design tools and methods

4. Design as an Investment • Experienced programmers do not need to produce designs to write most small programs. • Designs are needed when small programs are to be used as parts of larger systems or when quality is critical. • Based on data from 8,100 PSP programs, programmers who produced designs • spent 53% more time than those who did not • wrote programs that were 46% smaller • Most programmers know how to write small programs. The critical skill is for developing large programs.

5. Designed Programs are Smaller 8,100 Programs

6. Design Takes Longer 8,100 Programs

7. Design Representation • It is important to separate two issues. • how to do the design • how to represent the design when it is completed • Since the PSP can be used with any design method, it does not specify a specific design approach. • However, the PSP does address design representation.

8. Design Methods and Notations • There are many design methods. • None have been proven best for every domain. • The best method often depends on individual skills and preferences. • A widely-usable process must work with many different design methods. • There are also many types of design notations. • Graphics assist in visualizing structure. • Formality provides precision. • Text provides intuitive understanding. • Often all three types of design notations are needed.

9. Poor Design Notations Cause Defects • Design visibility • Complex designs are difficult to visualize. • A poor representation compounds visualization problems. • A well-represented design captures all design decisions unambiguously. • Design redundancy • A redundant design is often inconsistent. • Inconsistency breeds errors and causes defects. • A quality design has minimum duplication. • Where possible, use design tools that ensure consistency.

10. Design Notation Requirements • The design notation must • precisely define all significant design aspects • be commonly understood • communicate the designers’ intent • help to identify design problems and omissions • be suitable for representing a broad range of designs • The design should also • be concise and easy to use • provide a complete and accessible reference • have minimum redundancy • Formal notations meet these criteria.

11. Using Formal Notation • Advantages: using a formal notation • produces precise and compact designs • builds familiarity with an important notation • is consistent with the notation used in formal methods for proving program correctness • distinguishes logic from other expressions • Disadvantages: formal designs • generally take more time to create • take practice to build familiarity • may not be understood by users and co-workers

12. Mathematical Notation

13. Program Functional Statements • When describing program functions, actions and conditions are separated. • Condition  Action • Read, “When Condition is true, do Action.” • Several condition/action pairs are written as Condition A  Action A when Condition A, do Action A Ú or Condition B  Action B when Condition B, do Action B Ú or Condition C  Action C when Condition C, do Action C

14. Notation Examples -1 • If x is positive, set y to zero. • x > 0  y := 0 • If x is even, return the sum of x and y, otherwise return the difference between x and y. • even(x)  return( x + y )  odd(x)  return( x – y )

15. Notation Examples -2 • Produce a list of developers, DeveloperName, for the developers for whom you have PSP data. •  dname : DeveloperName | dname  NameList  •  pdata : PSPData  pdata.Name = dname • This expression reads as follows. • For all dname in DeveloperName, where dname is a member of NameList, there exists a pdata in PSPData where the Name field of pdata equals dname.

16. Why Precision is Needed • For many designs, source code and language descriptions provide adequate clarity. • For intricate or complex designs, precision is usually needed. • State machines are among the more complex program structures. They • often have design defects • are hard to test • are relatively easy to verify • The remainder of this lecture describes state machine design and design verification.

17. State Machines • A state machine has memory and its behavior depends on memory content. • All computers and many programs are state machines. • When module-sized programs contain state machines, the state-machine designs can be precisely defined and verified. • Without proper methods, it is rarely possible to understand or verify even modest-sized state machines.

18. An Example State Machine • The user login program is an example of a state machine. • The user is given several chances to provide a correct ID and password. • When a correct ID and password are provided, the user is logged in. • With too many ID or password errors, the login session is terminated.

19. The “LogIn” State Diagram

20. Designing State Machines • The steps in designing state machines are as follows. • Define the problem. • Devise a solution strategy. • Define the decisions that the program must make. • Identify the information needed to make these decisions. • Determine the states required to store this information. • Specify the transitions among the states.

21. Solution Strategy • The solution strategy outlines the approach to solving the problem. It is usually sequential and often graphic. • An example strategy for LogIn is as follows. • Check user ID. • For security purposes, ask for PWs whether the ID is correct or not. • If ID and password correct, LogIn the user. • If password is incorrect, ask for IDs and passwords until they are both correct or the user makes too many errors. • In all cases, if the user does not respond in time, timeout.

22. Decisions to Make • To implement this strategy, the program must make the following decisions. • Do I request an ID and password? • Do I LogIn the user? • Do I timeout the user? • Do I terminate the user session?

23. Information Required -1 • The information required to make these decisions is as follows. • Do I request an ID? • Is this a new user? • Has the user submitted an incorrect password? • Has the user submitted too many incorrect IDs or passwords? • Do I request a password? • Has the user submitted an ID?

24. Information Required -2 • Do I LogIn the user? • Were the most recent ID and password correct? • Do I timeout the user? • Has the user taken too long to answer a request? • Do I terminate the user session? • Has the user been timed out? • Has the user made too many ID or password errors?

25. System versus State Information • Some information results in the same action regardless of the state, and other information causes state-dependent actions. • Examples are • Timeout – regardless of state, session terminated • n > nMax – regardless of state, session terminated • In these cases, the system takes identical action regardless of the state.

26. Action Conditions • To determine the number or required states, consider the following questions and resulting actions. • 1. Is this either a new user or one with an invalid password? • Yes – get ID • No – go to question 2 • 2. Has the user submitted an ID or a password? • ID – get password • Password – go to question 3 • Neither – terminate the session • 3. Are the ID and password correct? • Yes – log in the user and exit • No – go to question 1 • In every case, check if n > nMax or timeout.

27. Required States • For our example state machine, four states are needed. • Start or new-user state • CheckID • CheckPW • End

28. State Specification Template -1 • The next state-machine design steps are to specify the • transitions among the states • actions taken with each transition • PSP uses the state specification template (SST) to define state-machine states, transitions, and actions. • With the SST, you can • define state machine structure • analyze the state machine design • recognize mistakes and omissions

29. Example State Template

30. State Specification Template -2 • The SST specifies • the name of every state • a brief description of each state • the name and description of any functions or parameters used in the SST • the conditions that cause transitions from the state to itself or to any other state • the conditions that cause transitions from any other state to this state • the actions taken during each transition

31. Transition Conditions • Most transition conditions are simple. • The CheckID to CheckPW transition occurs after getting an ID. • It happens whether the ID is correct or incorrect • The n count is advanced when the ID is incorrect. • The CheckID to End transition occurs when there is a timeout, setting Fail := 1.

32. State Machine Exercise -1 • A simple stopwatch has three buttons (start/stop, reset and hold) and a single display. • Initially, the stopwatch shows zero. Pressing the start/stop button starts the timer. The display shows the times. • Pressing the hold (or lap) button while the stopwatch is running causes the display to hold its current value while the timer continues. Pressing the hold button again displays the timer value.

33. State Machine Exercise -2 • Pressing the start/stop button when the stopwatch is running or on hold causes the timer to stop. • Pressing the reset button at any time causes the stopwatch to return to its initial state. • Construct a state diagram and state template for the stopwatch.

34. 20 minutes State Machine Exercise -3 • The first design step is to define the problem. • Is the problem clear? • Once you understand the problem, pair up and take 20 minutes to produce the state template and a state diagram for the stopwatch state machine.

35. Exercise Discussion -1 • Once you have reviewed the requirements, the next design step is to devise a solution strategy. • The solution strategy seems quite simple. • You start, stop, or reset the timer. • You also display, hold, or clear the display. • What decisions must be made?

36. Exercise Discussion -2 • The decisions to be made are as follows. • Start or stop the timer. • Display or hold the time. • Reset the timer and display. • Since these actions are all caused by buttons, why do we need a state machine?

37. Exercise Discussion -3 • A state machine is needed because two buttons cause different actions depending on the watch’s state. • Start/stop - the watch may stop or run. • Hold – the watch may run or hold. • To properly cause these actions, the watch must know if it is running, on hold, or stopped. • It must also know if it has been reset. • This means that we need four states.

38. Exercise: State Diagram Zero reset On-hold hold start/stop reset hold Running reset start/stop start/stop Stopped

39. Exercise: State Template

40. Verifying State Machines • Specify all of the state machines in your programs. • The trivial ones should be trivial to define. • Seemingly simple state machines often are not simple. • Without precise specifications, complex state machines are almost always defective. • Check for completeness and consistency. • The set of transition conditions from any given state must be complete and orthogonal. • The actions on each transition must be defined.

41. A Proper State Machine • In a proper state machine, the state transitions are all complete and orthogonal. • Complete Transitions: a transition is defined for every possible situation. • Orthogonal Transitions: none of the transitions have overlapping conditions. • With a proper state machine • a next state is defined for every possible condition • the designated next state is unique

42. State-machine Verification • The state-machine verification steps are as follows. • Check to ensure that the state machine has no hidden traps or loops. • Check that the set of all transitions from every state is complete and orthogonal. • In addition to verifying state-machine correctness, also ensure that the program performs its intended functions.

43. Hidden Traps or Loops -1 • Check for hidden traps and loops by • constructing the state template • constructing a state machine diagram • determining if any exit states are unreachable from any other states • If any state cannot reach an exit state, this is nota proper state machine. • If the state machine does not have an exit state, ensure that it contains no endless loops.

44. Hidden Traps or Loops -2 • For example, consider the LogIn state machine. • There are four states: Start, CheckID, CheckPW, and End. • There is a direct or indirect path from each state to End. • One possible loop is between CheckID and CheckPW. • Since n is increased by one for every cycle, n will ultimately exceed nMax and cause a transition to end. • Therefore, this state machine has no hidden traps or loops.

45. State Transitions -1 • For LogIn, the transition from Start is always to CheckID. • From CheckID, the transitions are complete and orthogonal with no overlaps. The transition conditions are • Start: impossible • Valid ID: to CheckPW • !Valid ID: to CheckPW • Timeout: to End

46. State Transitions -2 • From CheckPW, the transitions are as follows. • Start: impossible • CheckID: !Valid ID or !Valid PW • End: Valid PW and Valid ID • End: n >= nMax or Timeout • Verifying the completeness and orthogonality of these conditions requires analysis. • A truth table is a useful way to make such an analyses.

47. State Transitions -3 • Transitions from CheckPW are as follows. • The A, B, and C conditions are as follows.

48. State Transitions -4 • The End transition has two indeterminate cases. • n = nMax and valid password and valid ID • n > nMax and valid password and valid ID • These cases are possible, depending on the implementation and should be prevented. • This can be done by changing the C equation.

49. Corrected LogIn State Template

50. 20 minutes Verification Exercise • Using the methods just discussed, verify the stopwatch state-machine design in the state template in the handout. • Pair up again and take 20 minutes to verify the correctness of the state template for the stopwatch state machine.