2 Why We Need Model-Based Testing

256 Modeling Objects
The most important part of the harnessing is the dictionary maintained by the
harness. This dictionary keeps track of the correspondence between implementation
objects and term labels of the model program.
15.5 Abstract values and isomorphic states
It is sometimes useful to think of certain values as being abstract. An abstract value
in this sense is a value whose only operation is equality. For example, in the Payroll1
model program of this chapter we might consider values of the Employee type to be
abstract.
When enumerating the possible states of a model program, it is often useful to
exclude states that are structurally identical to a previously seen state except for
their choice of term labels for abstract values. We call any two such states isomorphic
states. The concept of isomorphism comes from mathematics and refers to a
structure-preserving transformation.
Let’s look at an example. If you were to examine the states of Figure 15.2, you
would see that state 3 is the following:
nextId = 3
allEmployees = Set(Employee(1), Employee(2))
salary = Map(Employee(1), 200, Employee(2), 0)
State 4 is:
nextId = 3
allEmployees = Set(Employee(1), Employee(2))
salary = Map(Employee(1), 0, Employee(2), 200)
You probably noticed that states 3 and 4 are similar. Both contain one employee
with salary 0 and another employee with salary 200. If you were to transform state
4 by renaming Employee(1) to Employee(2) and vice versa, then you would end
up with state 3. If Employee values are abstract, then states 3 and 4 are isomorphic
states. In other words, two states are isomorphic if there exists a substitution of
abstract values that makes them equal.
In NModel we can mark the values of a data type as abstract by annotating the
type declaration with an attribute:
namespace Payroll1
{
[Abstract]
class Employee : CompoundValue
{
more free ebooks download links at:
http://www.ebook-x.com