2 Why We Need Model-Based Testing

Advanced Topics 253
15.3 Object IDs and composition
Whether a model program is written in an object-oriented style is not visible during
composition. All kinds of model programs can be composed. In this section we
explain how this works.
When a class T inherits the LabeledInstance base class, it gets a built-in
term label for instances of T. By default, the term label uses the name of class T
as the function symbol of the term and an integer value as the term’s argument.
For example, in the model program Payroll2, instances of the Employee class have
labels like Employee(1), Employee(2), etc. 1
When objects of type T appear as arguments to actions, the term label of the object
is used. Using terms in action arguments provides an insulating layer of syntax. This
allows us to compose arbitrary model programs, regardless of whether they are
written in an object-oriented style, or with compound value types or as finite state
machines. 2
For example, suppose we have the following scenario described as a finite state
machine:
FSM(0, AcceptingStates(2), Transitions(
t(0, CreateEmployee(Employee(1)), 1),
t(1, CreateEmployee(Employee(2)), 2),
t(2, SetSalary(_, 0), 2),
t(2, SetSalary(_, 200), 2)),
Vocabulary("CreateEmployee", "SetSalary", "DeleteEmployee"))
This scenario FSM allows two employees to be created. It then permits any number
of SetSalary actions, using either 0 or 200 as the salary argument. It explicitly
disallows any DeleteEmployee actions. Figure 15.1 shows this graphically.
This FSM may be composed with model program Payroll2. Figure 15.2 shows
the result of the composition.
Notice that the FSM did not define objects or .NET types. It was only necesary
that the FSM and the Payroll2 model program agree on the term vocabulary
(Employee(1), Employee(2), etc.). When the model program Payroll2 sees a term
like Employee(1) it knows to interpret this term as an instance of the Employee class
within its context.
1 The NModel framework allows you to choose a symbol other than the type name by means of the
[Sort] attribute. For example, we could have annotated class Employee with [Sort("Emp")]
if we wanted labels in the form Emp(1), Emp(2), etc.
2 It is even possible to program your own type of ModelProgram using a derived class. As long
as you choose the same vocabulary for the actions and data elements, composition with any of
the other ModelProgram types is possible.
more free ebooks download links at:
http://www.ebook-x.com