Lecture Notes in Computer Science 3472

126 Stefan D. Bruda
obs(Succ, p) ={⊤}
obs(Fail, p) ={⊥}
obs(ao, p) = � {obs(o, p ′ ) | p a ⇒ p ′ }∪{⊥|p ↑} ∪ {⊥ | p ε ⇒ p ′ , p ′ ref a}
obs(�ao, p) = � {obs(o, p ′ ) | p a ⇒ p ′ }∪{⊥|p ↑} ∪ {⊤ | p ε ⇒ p ′ , p ′ ref a}
obs(εo, p) = � {obs(o, p ′ ) | p ε ⇒ p ′ }∪{⊥|p ↑}
obs(o1 ∧ o2, p) =obs(o1, p) ∧ obs(o2, p)
obs(o1 ∨ o2, p) =obs(o1, p) ∨ obs(o2, p)
obs(∀ o, p) =∀ obs(o, p)
obs(∃ o, p) =∃ obs(o, p)
⊓⊔
The function from Definition 5.5 follows the syntax of test expressions faithfully,
so most cases should need no further explanation. We note that tests of
form (5.3) are allowed to continue only if the action a is available to, and is
performed by the process under test; if the respective action is not available, the
test fails. In contrast, when a test of form (5.4) is applied to some process, we
record a success whenever the process refuses the action (the primary purpose of
such a test), but then we go ahead and allow the action to be performed anyway,
to see what happens next (i.e., we remove the block on the action; maybe in addition
to the noted success we get a failure later). As we shall see in Section 5.7
such a behavior of allowing the action to be performed after a refusal is of great
help in identifying crooked coffee machines (and also in differentiating between
processes that would otherwise appear equivalent).
As a final thought, we note again that tests can be in fact expressed in the
same syntax as the one used for processes. A test then moves forward synchronized
with the process under investigation, in the sense that the visible action
performed by the process should always be the same as the action performed
by the test. This synchronized run is typically denoted by the operator |, and
the result is itself a process. We thus obtain an operational formulation of tests,
which is used as well [Abr87, Phi87] and is quite intuitive. Since we find the
previous version more convenient for this presentation, we do not insist on it
and direct instead the reader elsewhere [Abr87] for details.
5.2.3 Equivalence and Preorder Relations
The semantics of tests presented in the previous section associates a set of outcomes
for each pair test–process. By comparing these outcomes (i.e., the set
of possible observations one can make while interacting with two processes, or
the observable behavior of the processes) we can define the observable testing
preorder 3 ⊑. Given the preorder one can easily define the observable testing
equivalence �.
3 Recall that this was originally named testing preorder [Abr87], but we introduce the
new name because of name clashes that developed over time.