State, State Graphs and Transition Testing

TRANSITION BUGS Page 380 of the Boris Beizer text

Note: Please use a slide show since transitions have been animated. Tip: dark red text corresponds to dark red entries in the table for that slide and so on . . .

Introduction to transition bugs…

• Exactly one transition must be specified for every combination of input & state

• A program should not have contradictions or ambiguities

• One of the most common source of contradictions/ambiguities are specifications

Example to convert specification into a state graph…

----------------------------------------------------------------• With an example, we will now follow a set of

rules, i.e. specifications to deduce the state graph and state tables

RULE 1:The program will maintain an error counter which will be incremented whenever there is an error.

Initial state graph deduced from Rule1…

error error error error . . .

Okay

RULE 1: The program will maintain an error counter, which will be incremented whenever there is an error.

0 1 2 3 4

State table from the state graph(refer

earlier slide for the graph)…

STATE OKAY ERROR0 0/None 1/1 2/2 3/3 4/4 5/5 6/6 7/7 8/

INPUT

Rule 2: If there is an error, rewrite the block

STATE OKAY ERROR0 0/None 1/REWRITE1 2/REWRITE2 3/REWRITE3 4/REWRITE4 5/REWRITE5 6/REWRITE6 7/REWRITE7 8/REWRITE

INPUT

For all ‘Error’ entries, we include a ‘Rewrite’

Rule 3: If there have been 3 successive errors, erase 10cm of tape and then rewrite the block

STATE OKAY ERROR0 0/None 1/REWRITE

1 2/REWRITE2 3/REWRITE,ERASE,REWRITE3 4/REWRITE,ERASE,REWRITE4 5/REWRITE,ERASE,REWRITE5 6/REWRITE,ERASE,REWRITE6 7/REWRITE,ERASE,REWRITE7 8/REWRITE,ERASE,REWRITE

INPUT

The first 3rd successive error occurs

STATE OKAY ERROR0 0/None 1/REWRITE1 2/REWRITE2 3/REWRITE,ERASE,REWRITE3 4/REWRITE,ERASE,REWRITE4 5/REWRITE,ERASE,REWRITE

5 6/OUT67

INPUT

Rule 4: If there have been 3 successive erasures, and another error occurs, put the unit out of service

We have 3 successive erasures- so we now put the unit out of service

Rule 5: If the erasure was successful, return to the normal state and clear the error counter

STATE OKAY ERROR0 0/None 1/REWRITE1 2/REWRITE2 3/REWRITE,ERASE,REWRITE3 0/None 4/REWRITE,ERASE,REWRITE4 0/None 5/REWRITE,ERASE,REWRITE5 0/None 6/OUT67

INPUT

We reach State 3 after the 1st erasure. If successful, we return to ‘None’ & the error counter is made 0

Rule 6: If the rewrite was successful, decrement the error counter and return to the previous state

STATE OKAY ERROR0 0/None 1/REWRITE1 0/None 2/REWRITE2 1/None 3/REWRITE,ERASE,REWRITE3 0/None

2/None4/REWRITE,ERASE,REWRITE

4 0/None3/None

5/REWRITE,ERASE,REWRITE

5 0/None4/None

6/OUT

67

INPUT

Example: Say we are at state 1. The error counter here is 2. If we have a successful(okay) rewrite, the entry for okay at state 2 will have error counter decremented by 1 which is: (2-1)/None where, None output for success.

Conclusion…

• Observe the previous slide-RULE6 states “If the rewrite was successful, then decrement the error counter and return to the previous state”. The requirement probably was – “If there have been no erasures and rewrite was successful, then …”

• This has now resulted in contradictions – which is a concern as it might lead to bugs.

• It is always unlikely that a contradictory specification can result in a satisfactory implementation.

Done!!! Please feel free to get back incase you have any questions