27.07.2013 Views

2 Why We Need Model-Based Testing

2 Why We Need Model-Based Testing

2 Why We Need Model-Based Testing

SHOW MORE
SHOW LESS

You also want an ePaper? Increase the reach of your titles

YUMPU automatically turns print PDFs into web optimized ePapers that Google loves.

Advanced Topics 241<br />

14.3 Properties of model program composition<br />

Recall from Section 7.3 that, under composition, model programs synchronize steps<br />

for shared actions and interleave actions not found in their common action vocabulary.<br />

<strong>We</strong> now describe in greater detail how actions are combined, taking into<br />

account both action symbols and arguments, including the placeholder (underscore).<br />

Recall that it is the actions (the terms) that are considered when combining<br />

actions, not the action methods (the C# code).<br />

It is sometimes easier to reason about properties of composition when the action<br />

vocabularies of the composed model programs are the same. In order to do so we<br />

use a simple transformation. The effect of interleaving for nonshared actions is<br />

achieved by treating actions not in the vocabulary as self-loops. <strong>We</strong> transform a<br />

model program M with respect to a set of action symbols a1,...,ak into a new<br />

model program called a loop extension of M for a1,...,ak, as follows. For each<br />

action symbol ai not in the action vocabulary of M, add a trivial guarded update rule<br />

for ai whose enabling condition is true, and whose update rule produces no state<br />

updates, that is, every action whose symbol is ai produces a self-loop in all states of<br />

M. In reality, this transformation is not done explicitly but is built into the product<br />

operation of model programs.<br />

For example, consider the setup model program in Figure 14.15. The loop extension<br />

of the setup model program for Cancel, say SetupC, has the additional<br />

transitions<br />

t("Inactive", Cancel(), "Inactive")<br />

t("Activating", Cancel(), "Activating")<br />

t("Active", Cancel(), "Active")<br />

The arity of an action (symbol) is the number of arguments or parameters that<br />

it takes. When describing a model program it is often convenient to omit trailing<br />

parameters of an action that are not referenced by its guarded update rule. For<br />

example, in the sample protocol model, the arity of a cancel action is one, the arity<br />

of a request action is two, and the arity of a response action is three. Given an<br />

action symbol f with arity k we often use the abbreviated form f (t1,...,ti) for<br />

some i, 0≤ i ≤ k, to stand for the term f (t1,...,ti, _,...,_) with k − i trailing<br />

underscores called placeholders. 1 For example, Cancel() stands for Cancel( ). An<br />

instance of an action with placeholders is a replacement of some (or none) of the<br />

placeholders with concrete values. A trace with placeholders is a sequence of actions<br />

with placeholders and an instance of a trace with placeholders is an instantiation of<br />

some of the placeholders in it. <strong>We</strong> often say trace to mean a trace that may contain<br />

1 Formally, each occurrence of a placeholder represents a fresh logic variable. A term without<br />

logic variables is called ground.<br />

more free ebooks download links at:<br />

http://www.ebook-x.com

Hooray! Your file is uploaded and ready to be published.

Saved successfully!

Ooh no, something went wrong!