We designed the controller by considering some typical runs and coding tests
and assignments to make them work. But many more runs are possible than the
ones we considered and tested, so our design is defective. We are getting tired of
experimenting with the simulator. Discovering defects by trial and error provides
Overview 47
no confidence that we are converging on a correct design. There might be even
more ways that the controller can fail. How can we be sure that we have considered
enough runs? We need some systematic way to check the design thoroughly.
3.6 Reviews and inspections, static analysis
The traditional way to detect design defects is to conduct reviews or inspections
where people examine design documents and code, often while consulting a checklist
of likely errors. These assurance techniques are a good match to programs like ours,
which have a simple, regular structure. The control program is largely built from
only two kinds of methods, guards and handlers, and has a simple control structure
expressed here by the DispatchHandler method. This makes it easy to express and
check design rules that the code should observe. The design should be complete:
there should be a handler enabled for every event in every state. The design should
be deterministic: there should be only one handler enabled for each event in every
state. The design should make progress: each handler should execute statements
that bring the controller closer to a goal, usually by enabling a different handler.
Pages:
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86