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…

0 error 1 error 2 error 3 error 4 ...

Okay

RULE 1: The program will maintain an error counter,

which will be incremented whenever there is an
error.
State table from the state graph(refer
earlier slide for the graph)…
INPUT

STATE OKAY ERROR

0 0/None 1/
1 2/
2 3/
3 4/
4 5/
5 6/
6 7/
7 8/
Rule 2: If there is an error, rewrite
the block INPUT

STATE OKAY ERROR

0 0/None 1/REWRITE
1 2/REWRITE
2 entries, we include a ‘Rewrite’
For all ‘Error’ 3/REWRITE
3 4/REWRITE
4 5/REWRITE
5 6/REWRITE
6 7/REWRITE
7 8/REWRITE
Rule 3: If there have been 3 successive errors,
erase 10cm of tape and then rewrite the block
INPUT

STATE OKAY ERROR

0 0/None 1/REWRITE
1 The first 3rd successive error occurs 2/REWRITE
2 3/REWRITE,ERASE,REWRITE
3 4/REWRITE,ERASE,REWRITE
4 5/REWRITE,ERASE,REWRITE
5 6/REWRITE,ERASE,REWRITE
6 7/REWRITE,ERASE,REWRITE
7 8/REWRITE,ERASE,REWRITE
Rule 4: If there have been 3 successive erasures, and
another error occurs, put the unit out of service
INPUT

STATE OKAY ERROR

0 0/None 1/REWRITE
1 2/REWRITE
2 3/REWRITE,ERASE,REWRITE
3 4/REWRITE,ERASE,REWRITE
4 5/REWRITE,ERASE,REWRITE
We have 3 successive erasures- so
5 we now put the unit out of service 6/OUT
6
7
 Rule 5: If the erasure was successful, return to the
normal state and clear the error counter
INPUT

STATE OKAY ERROR

0 0/None 1/REWRITE
We reach State 3 after the 1st
1
erasure. If successful, we return to 2/REWRITE
‘None’ & the error counter is made 0
2 3/REWRITE,ERASE,REWRITE
3 0/None 4/REWRITE,ERASE,REWRITE
4 0/None 5/REWRITE,ERASE,REWRITE
5 0/None 6/OUT
6
7
Rule 6: If the rewrite was successful, decrement the
error counter and return to the previous state
INPUT

STATE OKAY ERROR

0 0/None 1/REWRITE
1 0/None 2/REWRITE
2 1/None 3/REWRITE,ERASE,REWRITE
3 0/None 4/REWRITE,ERASE,REWRITE
2/None
4 0/None 5/REWRITE,ERASE,REWRITE
3/None
5 0/None 6/OUT
4/None Example: Say we are at state 1. The error
counter here is 2. If we have a successful(okay)
6 rewrite, the entry for okay at state 2 will have
error counter decremented by 1 which is:
7
(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 