Lecture Notes in Computer Science 3472

5 Preorder Relations 145
condition in that a successful state must be reached from every state in the
system.
It is immediate that ⊑should is coarser than ⊑fmust (since the success condition
is stronger). This relationship is even stronger for processes with only finite
visible runs:
Proposition 5.16. Foranytwoprocessespandq,p⊑should qimpliesp⊑fmust
q (but not the other way around); for any two processes p and q for which all
the visible runs are finite p ⊑should qiffp⊑fmust q.
In addition ⊑should is a pre-congruence under hiding—as well as under prefixing
and synchronization [BRV95]; in fact we have:
Proposition 5.17. The relation ⊑should is the largest relation contained in
⊑fmust that is a pre-congruence under synchronization and hiding.
5.9 Conformance Testing, or Preorders at Work
This section is different from the previous ones, because it does not introduce
new testing scenarios and new preorders. Instead, it puts the existing scenarios
in a formalization of the concept of conformance testing [Tre94]. The description
of such an environment in which preorders are put to good use is indeed a nice
wrap up of our presentation.
We mentioned at least two times that preorders can be interpreted as implementation
relations. In this sections we elaborate on this idea. We thus present
here the application of everything we talked about before.
Conformance testing consists in testing the implementation of a system
against that system’s specification. Formally, we are given a formal specification
language LFDT (such as CCS [Mil80] or even labeled transition systems),
and we have to determine for some specification s ∈LFDT what are the implementations
that conform to s (i.e., are a correct implementation of s). Of course,
implementations are physical objects, so we analyze their properties by means
of formal models of such implementations, that are also members of LFDT .We
assume that any concrete implementation can be modeled in LFDT .
There usually are more than one correct implementation of some specification,
so we actually work with a set CONFORMs of implementations conforming
toaspecifications. This set can be defined using either a behavior (or modelbased)
specification, orarequirement (or logical) specification.
In the behavior specification approach the set CONFORMs is defined by
means of an implementation relation imp, such that i imp s iff i conforms
to s:
CONFORMs = {i ∈LFDT | i imp s}.
In the requirement specification approach we define the set CONFORMs by
giving all the properties that should hold for all of its elements. Such properties,