2 Why We Need Model-Based Testing

58 Model Programs
system comprising several programs, or a distributed system that includes several
computers connected by a network. A model program can also represent the environment
where the implementation runs, including messages in transit between
networked computers, or events originating in attached hardware.
Actions are the units of behavior. In many kinds of systems, including computer
systems, behaviors are made up of discrete, discontinuous steps. Each step is an
action. An action can be composed of several smaller activities, but an action is
atomic: once it begins, it runs to completion, without being interrupted or preempted
by another action. For each kind of action in the implementation, there is a method
in the model program. When the model program runs, each method call represents
an action in the implementation. 1
State is the information stored in a program or system at one point in time.
The concept of state captures our intuition of a “situation” or “state of affairs”: the
important properties of a system at one moment. The state of the implementation is
represented by variables of the model program. Each particular assignment of values
to variables in the model program represents a particular state (a situation) of the
implementation. The variables in the model program that represent implementation
state are called state variables (to distinguish them from the model program’s
local variables, parameters, etc.). State variables in the model program need not
correspond exactly to program variables in the implementation; they might represent
information that is not stored in implementation variables (messages in transit, for
example).
Every program or system starts up in an initial state. The initial state is usually
an empty or idle state. Behavior continues until the system reaches an accepting
state. An accepting state is usually a state where the program’s goals have been
achieved, where some unit of work has been completed. The system may stop in
an accepting state; alternatively, it may continue, starting new work. A sequence of
actions beginning in the initial state and ending in an accepting state is called a run
or a trace. A run must not end in a state that is not an accepting state (if the model
program does not identify any accepting states, a run may end in any state). The
runs of a model program are sequences of method calls (and returns).
The behavior of a program or system is the complete collection of all the runs
that it can execute. A contract model program is a specification that describes
all of the allowed behavior of its implementation: it describes everything that its
implementation must do, might do, and must not do. Every run that a contract
model program can execute represents a run that its implementation must be able to
execute. A contract model program cannot execute any run that its implementation is
forbidden to execute. A contract model program often has a large collection of runs;
1 This is a simplification; the relation between actions in the implementation and methods in the
model program is not always one-to-one. Chapters to come and Appendix A tell the whole story.
more free ebooks download links at:
http://www.ebook-x.com