2 Why We Need Model-Based Testing

126 Structuring Model Programs with Features and Composition
0, 0
1, 0
2, 1
2, 0
Table 7.1. Pair states, enabled actions, and matched actions in M1 × M2
Pair state M1 enabled actions M2 enabled actions
(0, 0) A(), C() A(), B()
(1, 0) B(2), C() A(), B( )
(2, 1) C() A(), C()
(2, 0) C() A(), B( )
M1 A(), M2 A()
M1 B(2), M2 B(_)
M1 C(), M2 C()
Figure 7.11. Model program M1 × M2, showing pair states and matched actions.
the product is complete. The pair state (2, 0) is an accepting state in the product
because both states in the pair are accepting states in their own programs.
Table 7.1 summarizes this procedure. For each pair state, it shows the actions that
are enabled in each loop extension, with the matching actions printed in bold type.
Accepting states are also printed in bold type.
There are a few additional complications that did not arise in this simple example,
concerning the arguments of actions. When actions have the same name but different
arguments (other than the placeholder), they do not match. For example, if M2 in
this example had action B(3) instead of B( ), it would not match B(2) in M1 and no
B action would appear in the product. Moreover, it is possible to define actions that
have placeholders in any position, so the action D( ,4) in one program would match
D(3, ) in another, resulting in D(3,4) in the product. More complex examples and
explanations of composition appear in Chapter 14, especially Section 14.3.
Sometimes it is useful to view the projection of a product onto one of the
composed programs. Figure 7.12 shows the projection of the product M1 × M2 onto
M2. The projection is generated by exploring the product. Each time the product
more free ebooks download links at:
http://www.ebook-x.com