2 Why We Need Model-Based Testing

Systems with Finite Models 99
Model programs need not have a small number of states and actions. State variables
can be numbers, strings, objects, or other data types that can have a great many
values. The actions can be method calls with arguments, which can also have a great
many values. In that case, the number of states and transitions defined by the model
program is effectively “infinite”: much too large to write down, or even to store in a
computer. Then it is not possible to completely explore the true FSM. We will write
and analyze such infinite model programs in Part III. In Chapter 11, we will show how
to configure nonexhaustive exploration of infinite model programs, in order to perform
analyses that are incomplete, but still useful (we will finitize the analysis instead
of the model). But here in Part II, we only consider model programs where we can
completely explore the true FSM. That is why we emphasized finitizing the model
programs in Chapter 5.
6.2 Exploration
Recall that exploration automatically generates an FSM from a model program. The
FSM can then be used for visualization, analysis, and offline test generation. In the
following subsections we explain how to explore a model program with the library
and tools.
6.2.1 Accessing the model program
To work with the library or any tool created from it (including mpv, otg, orct), a
model program must provide a factory method that creates a LibraryModelProgram
object from the compiled model program assembly. All tools access the model
program indirectly, by invoking the methods of this object.
We recommend putting the factory method in its own factory class. The factory
class always has the same form; only a few identifiers must be changed for each
particular model program. Figure 6.3 shows the factory class from our newsreader
model program.
The factory class appears in the same namespace as the model program and must
be compiled in the same assembly. For example, the code in Figure 6.3 appears in
the same NewsReader namespace as the code in Chapter 5, Figures 5.4 and 5.5. The
factory class must be declared public static. (The class or classes that contain
the state variables and action methods of the model program need not be public;
we recommend they have the default private access.) We usually name the factory
class Factory and the factory method Create, but this is not required. In the body
of the factory method, in the LibraryModelProgram constructor, the argument of
the typeof operator must be the same class, Factory here. The second argument
more free ebooks download links at:
http://www.ebook-x.com