2 Why We Need Model-Based Testing

34 Why We Need Model-Based Analysis
by more than a particular tolerance, then the sensor is considered to be faulty and
no more samples are requested. Instead, the control program commands the sensor
to reset. If the sensor responds by sending back an acceptable temperature that is
close to the last good sample, the sensor is considered to be working correctly again
and the control program resumes polling.
The control program must not compute a calibration factor with a temperature
sample that is considered erroneous, because that would result in controlling the
process with an incorrect calibration factor, which could have serious consequences.
We have a safety requirement which stipulates that the controller must not do
anything bad: the program must not compute a calibration factor with an erroneous
temperature sample. We also have a liveness requirement which stipulates that the
controller must do something good: the controller must respond to a command
by calculating the calibration factor (except where this would violate the safety
requirement).
3.2 Implementation
Our control program uses a typical strategy for implementing reactive programs
(Figures 3.2–3.6). The observable actions are implemented by events, and the controllable
actions are implemented by methods called handlers. The program waits
for an observable action. When one occurs, the program executes a dispatcher, code
that selects a handler, and then executes the handler selected by the dispatcher. When
the handler returns, the program waits again for the next observable action.
We divide our control program into two classes. The Controller class is a library
that contains the dispatcher and the handlers (Figures 3.2–3.4). It is largely
independent of any operating system or framework. 1 We also provide a simulator
application, so we can experiment with the control program design on any computer
that provides the .NET framework. The simulator substitutes for the much more
elaborate support (including device drivers, etc.) needed by the actual control program.
The Simulator class is an application that generates the events that implement
our observable actions (Figures 3.5 and 3.6). It also provides a rudimentary user
interface so we can raise events by clicking buttons on a form.
Our simulator uses C# events and the .NET framework, in particular the event
machinery provided by the System.Windows.Forms namespace. For example, in our
Simulator class, c.timer is the .NET timer and c.timer.Tick is its Tick event
(Figure 3.5). The statement
c.timer.Tick += new EventHandler(timer_Tick);
1 The Controller class does use the .NET Timer class from System.Windows.Forms.
more free ebooks download links at:
http://www.ebook-x.com