Vous êtes sur la page 1sur 20

183

Step-Wise Validation of Communication


Protocols and Services
Hasan U R A L and Robert L. P R O B E R T 1. Introduction
Department of Computer Science, University of Ottawa, Ottawa,
Ontario, Canada, KIN 9B4 Step-wise refinement in a typical software de-
velopment process starts from a formulation of
intentions of the desired system functionality and
A highly automated approach is proposed for testing the
converges to an implementation of the system
consistency of distinct representations of identical system func-
tionality. This approach is based on dynamic comparison and providing this functionality. This step-wise refine-
analysis of observable behaviors presented by system function- ment process produces a series of system function-
ality representations given at different levels of abstraction. ality representations (SFRs) such as intentions,
These representations are encoded in a relatively mechanical natural language assertions, formal specifications,
way as procedures in sequential PROLOG and thus provide
designs, and implementations in decreasing levels
the capability of generating and checking the system function-
ality they capture. The approach is extremely flexible, of abstraction. In general, each such representa-
straightforward to use, and particularly appropriate to systems tion describes the system functionality in terms of
whose externally observable behavior can be modeled by finite externally observable behavior of the system (e:g.,
state automata. The use of this approach is illustrated in the possible types and orderings of interactions that
context of OSI communication protocol design and validation.
the system exchanges with its environment) and is
Kevwords: Executable Specifications, Design Tools, Valida- derived by successively refining the more abstract
tion. Testing, Simulation. repreSentation immediately preceding it. It is
widely acknowledged that many errors can be
introduced into the representations during these
derivations (i.e., transformations from one repre-
sentation to another) and that such errors can
propagate throughout subsequent representations
unless they are detected and corrected.
A major concern (and thus the purpose of
validation) in a software development process is to
Robert L. Probert was born in Belle- ensure that these distinct but highly related SFRs
ville, Ont., Canada. He received the are in fact consistent. Here, by consistency we
B.Sc., M.Sc., and Ph.D. degrees in
computer science from the University mean equivalence of externally observable behav-
of Waterloo in 1969, 1970, and 1973, ior. There are basically two approaches to valida-
respectively.
He joined the Department of Com- tion: namely, verification and testing. Verification
putational Science at the University of is based on formal and logical means (e.g., induc-
Saskatchewan in 1973 as an Assistant
Professor, and is now a Professor in tion arguments) and aims to prove desired behav-
the Department of Computer Science ioral equivalence of SFRs. Testing, on the other
at the University of Ottawa. His re-
search interests include software test-
ing tools and techniques, protocol specification and testing,
and rule-based software engineering.
Dr. Probert is the Coordinator of the Protocols Research Hasan Ural was born in Ankara,
Group at the University of Ottawa, involving several faculty Turkey. He received the Ph.D. degree
and graduate students and is currently directing a subgroup in electrical engineering from the Uni-
working on a protocol validation contract for Bell-Northern versity of Ottawa in 1984. He is now
Research. He has served as a consultant in the area of proto- an Assistant Professor in the Depart-
cols and software testing to both industry and government and ment of Computer Science at the Uni-
on the board of directors of a software development corpora- versity of Ottawa. His research inter-
tion. ests include communication software
specification and validation, applica-
tions of logic programming tech-
North-Holland niques, and distributed processing.
Computer Networks and ISDN Systems 11 (1986) 183-202

0376-5075/86/$3.50 © 1986, Elsevier Science Publishers B.V. (North-Holland)


184 H. Ural, R.L. Probert / Communication Protocols and Services

hand, attempts to reveal inconsistencies between refined service specification constructed from two
S F R _ K and its abstraction SFR_K-1 by com- copies of the protocol specification and an un-
paring the system behavior observed during the derlying service specification. Finally, working
execution of SFR K with the expected system groups of both ISO and CCITT are currently
behavior as described by SFR_K-1. However, studying issues related to conformance testing of
testing cannot guarantee that S F R _ K is "con- protocol implementations. These studies should
sistent" With SFR_ K-1 unless all possible system benefit from our research into testing the behav-
behavior patterns described by these SFRs are ioral equivalence of abstract and refined SFRs.
explored and compared against each other. In The paper is organized as follows: In section 2,
general, this corresponds to "exhaustive" testing we detail the consistency checking approach by
which is practically infeasible. Thus, practical test- elaborating the possible ways of comparing actual
ing aims at detecting particular (if not all), highly against expected behaviors of SFRs, and by de-
likely instances of inconsistencies between SFR_ K scribing its requirements and basic components.
and SFR_K-1. In section 3, we present the application of our
In this paper, we present a validation approach approach to the development and validation of
which employs testing as a means of detecting layered communication protocols.
inconsistencies between SFR K and SFR_K-1.
This approach is motivated by consideration of
the need of a practical, easy to use development 2. The Approach
aid which aims to increase our confidence in the
refinement process. Usually, in an incremental 2.1. Overview of the Approach
development process a refinement of S F R K-1 is
attempted only after SFR K-1 has been vali- Assume that SFR_K-1 and S F R _ K are avail-
dated. Thus, we will assume that SFR_K-1 is able in sufficiently precise formalisms that all
acceptable as a reference for consistency checking. actual behaviors of each SFR can be obtained
In our approach, detection of inconsistencies (if (e.g., by direct execution). The following valida-
any) between two SFRs is based on dynamic tion scenarios can be used for detecting incon-
analysis of externally observable behavior of these sistencies between SFR_ K and SFR_ K-l:
SFRs at corresponding observation points. That 1) Obtain a set of actual execution histories of
is, the analysis involves comparing each actual S F R _ K (i.e., sequences of interactions in which
behavior of SFR_ K observed during its execution S F R _ K participates during its execution). Each
with a corresponding expected (or intended) be- execution history is a sequence of input stimuli
havior of S F R _ K described in (or implied by) and responses recorded during the execution of
SFR_ K-1. Two possible ways of comparing actual SFR_K. We call each such sequence a trace of
against expected behavior for the purpose of de- SFR_K. Each trace of S F R _ K corresponds to an
tecting inconsistencies can be identified; namely, instance of actual behavior of S F R _ K which in
checking whether: turn corresponds to an instance of externally ob-
a) a representative set of observed behavior of servable system behavior described by this SFR.
SFR_ K is permitted by SFR_ K-1 Since SFR_K-1 has already been validated, the
b) a representative set of intended (or expected) system behavior described by SFR_K-1 can be
behaviors of SFR_ K (derived from SFR_ K-l) considered to be the expected (desired) behavior of
is realized by (is actually possible in) SFR_K. SFR_K. That is, each trace of S F R _ K can be
Testing the behavioral equivalence of two SFRs checked for consistency with the corresponding
is a useful approach to, for example, in-house expected behavior(s) described by SFR_K-1.
validation of implementation of protocol entities. Therefore, apply each trace of SFR K to
In this case, SFR_K-1 is the accepted protocol SFR_K-1 to check whether it is permitted by
specification and S F R _ K is a protocol imple- SFR_K-1. This validation activity is called 'trace
mentation. In addition, design of the protocol checking '.
specification can be assisted by testing the con- 2) Obtain a set of actual interaction sequences
sistency of two SFRs. In this case, SFR_K-1 is from SFR K-1. This set contains intended (or
the accepted service specification and SFR_ K is a expected) sequences of interactions between
H. Ural, R.L. Probert / Communication Protocols and Services 185

SFR K and its environment. We call each such cases for the discussion on trajectory checking:
interaction sequence a trajectory for S F R _ K, i.e., a) S F R _ K includes all non-deterministic compo-
an instance of expected behavior (i.e., potential nents and options specified in S F R _ K - 1 .
trace) of S F R _ K . In general, a trajectory for b) S F R _ K includes some (possibly one) of the
S F R _ K is a test sequence which is a string of non-deterministic components or options of
stimuli (i.e., input interactions to be applied to SFR_K-1.
SFR_ K) interleaved with expected responses (i.e., Obviously, case b) cannot be handled using
output interactions of S F R _ K). Then apply each single-valued trajectories since inconsistency re-
selected trajectory to S F R _ K to check whether it vealed using such a trajectory does not guarantee
is actually allowed by S F R _ K . We call this vali- inconsistency between S F R _ K and S F R _ K - 1 .
dation activity 'trajectory checking'. On the other hand, case a) can be handled using
In fact, this is a two-way complementary con- single-valued trajectories provided that S F R _ K
sistency checking approach. The aim in trajectory can undo the choices it has taken which do not
checking is to reveal any expected behaviors that lead to a particular expected response. In fact, we
S F R _ K fails to perform or performs incorrectly. build trajectory checkers to direct S F R _ K to
On the other hand, the aim in trace checking is to produce the expected response if it is among
reveal any behavior of S F R _ K that was not in- S F R _ K's possible choices. Thus, an inconsistency
tended. As well, the actual limits and constraints between the two SFRs is detected if and only if
that are realized S F R _ K may be revealed during there is no sequence of actions taken by S F R _ K
trace checking. In each of these cases, discrepan- which generates the specific expected response.
cies between actual and expected behaviors of This is discussed in more detail in section 2.3
SFRs are reported for subsequent analysis and Trajectory checking using multiple-valued
reconciliation. trajectories involves checking whether an actual
It is important to note that in some cases response of S F R _ K is among the responses
S F R _ K - 1 may involve some nondeterminism specified at the corresponding points in the trajec-
which allows certain implementation choices for tory. Thus, an inconsistency is detected if and
S F R _ K. In these cases, there is a need to adapt to only if a response of S F R _ K does not match any
unpredictable choices of S F R _ K in response to a of the allowed expected responses. The mecha-
given stimulus during testing. That is, the response nisms for representing and applying such trajecto-
(if valid) of S F R _ K must be identified as one of ries require further study.
the acceptable expected responses and the subse- In the following subsections, we describe basic
quent stimulus must be determined. components of our approach,~namely, construc-
In our approach, the requirement of adapting tion of executable SFRs and analysis of system
to unpredictable responses of S F R _ K is met as functionality captured by these SFRs.
follows: In trace checking, S F R _ K-1 is employed
as a test oracle which determines whether an
observed trace of S F R _ K is permissible or not. 2.2. Construction of Executable Representations
Thus, an inconsistency is detected if and only if
the actual response of S F R _ K in the trace does A variety of formal description techniques are
not match any of the (expected) responses per- classified as finite state machine (FSM) based
mitted by S F R _ K - 1 . formalisms [2] which have been used to describe a
As far as trajectory checking is concerned, a wide variety of systems such as communication
trajectory which includes a single expected re- protocols and services, airline reservation systems,
sponse for a given stimulus (i.e., a single-valued real-time process control systems, telephone
trajectory) cannot provide the capability of adapt- switching systems, etc. Considering the widespread
ing to unpredictable responses of S F R _ K . In- use of FSM based formalisms, we focus in this
stead, all allowed responses to a stimulus should paper on the application of our approach to those
be included in a trajectory. This corresponds to a systems whose externally observable behavior can
tree structure which we call a multiple-valued be modelled by these formalisms. Without loss of
trajectory. generality, we assume that original system descrip-
At this point, we identify the following two tions are given in the extended finite state ma-
186 H. Ural, R.L. Probert / Communication Protocols and Services

chine (EFSM) formalism of ISO (i.e., Estelle) [6]. possible state transitions. The state space of a
Note that original system descriptions given in module is specified by a set of variables (i.e., the
this formalism may not be directly executable. major state variable(s) and some additional state
Thus, based on these descriptions, we construct variables). A possible state of a module is char-
SFRs in a directly executable form (i.e., in Prolog). acterized by the values of all of these variables.
In the following subsections, we describe EFSM Each state transition is defined by an enabling
and Prolog based formalisms and the procedure condition which is a combination of boolean ex-
employed for constructing SFRs in Prolog. pressions involving some state variables and possi-
bly an input interaction and by an action which
2.2.1. An Extended Finite State Machine For- may update some state variables and may generate
malism some output interactions. Transitions may be clas-
Estelle is based on an interaction model char- sified according to the cause of initiation as fol-
acterizing distributed systems [1,7]. In this model, lows:
each system or subsystem is considered as a col- 1) input-initiated transitions which are initiated
lection of modules (e.g., processes) where each by some input interaction and may produce
module is interacting with its environment (e.g., some output interactions,
other modules) through its interaction points. An 2) internal transitions which are spontaneous and
interaction between two modules takes place at a do not produce output interactions,
pair of corresponding interaction points (one in 3) output generating transitions which are sponta-
each interacting module) which is called a channel. neous and produce some output interactions.
An interaction is characterized by a name and a Note that non-determinism in module descriptions
number of parameters. An occurrence of an inter- is introduced by the existence of spontaneous
action between two modules involves a particular transitions a n d / o r the presence of more than one
assignment of valid values to its parameters and a input-initiated transition for a specific input inter-
transfer of this information from one module to action at some states. Details of this formal de-
the other over the particular channel. That is, an scription technique can be found in [6].
interaction transfers information only in one di-
rection. Interactions that transfer information from 2.2.2. Logic Programming and PROLOG
a module are considered as "output" interactions Logic programming employs a clausal form of
by that module whereas the ones transferring in- logic [8] where a logic program is considered as a
formation to the module are considered as "input" collection of clauses. The general form of a clause
interactions. It is assumed that each interaction is is conclusion:- condition1 . . . . . conditionN where
atomic and parameter values included in an inter- conclusion and conditions are of the form: rela-
action are determined by the module that outputs tion (object1 . . . . . objectM) which denotes a rela-
the interaction. tionship among the objects. Such a clause states
Each channel between a pair of interacting that the conclusion holds if all the conditions are
modules is associated with a pair of interaction met (i.e., a logical implication). A clause with no
queues, one for each direction of information conditions is called an assertion.
transfer. Thus, the output interaction of a module Each clause in a logic program is interpreted
at an interaction point is queued before it is individually and has two interpretations: namely,
considered as an input interaction at the corre- a declarative interpretation where the clause is
sponding interaction point of the other module. considered as a logical implication or an assertion;
Furthermore, modules are allowed to have inter- and a procedural interpretation which takes the
nal buffers (possibly represented by FIFO queues) conclusion of the clause and attempts to satisfy it
to store some data that they receive through an either unconditionally (in the case of an assertion)
input interaction before they send it to another or conditionally (in the case of a logical impli-
module via an output interaction. cation). The procedural interpretation of clauses
In Estelle, the externally.observable behavior of in a logic program corresponds to a non-determin-
a module (i.e., the possible orderings of interac- istic computation model [8]. That is, in order to
tions exchanged at the interaction points of the satisfy a conclusion, the conditions (if any) may
module) is defined by the state space and by the be satisfied in any order and in order to satisfy a
H. Ural, R.L. Probert / Communication Protocols and Services 187

chosen condition, any of the clauses whose conclu-


sions match with this condition may be selected.
C12
Prolog [3] is a practical logic programming
language which provides an approximation to this
conputational model by specifying both the order
in which conditions are selected to be satisfied
(i.e., left-to-right) and the order in which specific IC21
clauses are considered to satisfy the chosen condi-
tion (i.e., top-to-down). Prolog supports invertable I M21
execution (i.e., both forward (from input to out-
put) and backward (from output to input) execu- Fig. 1. Module Descriptions and Channels.
tion) of procedures defining a complete relation
between input and output. We implement SFRs as
Prolog procedures and then use these procedures Executable SFRs are constructed as follows:
as generators and analyzers of the system func- 1) Each system being described consists of a
tionality. That is, a Prolog procedure P imple- number of modules. Each module in the system is
menting an abstract S F R _ K (e.g., the design of a denoted by Mij where j = (1, 2 . . . . . m) stands for
system) can be used the occurrence number of module type i - -
1) as a generator to obtain interaction sequences (1, 2 . . . . . n). For example, Figure 1 depicts a sys-
in which S F R _ K participates. Specifically, P tem which is composed of two occurrences of
can be executed as a generator to produce module type M1 (i.e., M l l and M12) and one
a) all possible interaction sequences, or occurrence of module type M2 (i.e., M21).
b) a set of all possible output a n d / o r input 2) Modules in the system interact through a
interaction sequences observed at the inter- number of channels. Each channel is denoted by
action points of SFR K for a given input Cpq where q = (1, 2 . . . . . y) stands for the occur-
(or output) interaction sequence. rence number of channel type p - - ( 1 , 2 . . . . . z).
2) as a validator in recognizer or acceptor mode Continuing with the above example, C l l and C12
to check whether are two occurrences of channel type C1, and C21
a) observed interaction sequences obtained and C22 are two occurrences of channel type C2.
during the execution of a less abstract 3) Each channel is associated with at least one
S F R _ K + 1 (e.g., an implementation of the module in the system. If a channel is referred to
system) are permissible by only one module, it is called an external chan-
b) intended interaction sequences obtained by nel. For example, channels C l l and C12 in Figure
executing a more abstract S F R _ K - 1 (e.g., 1 are external channels. Each external channel
the specification of the system) are achieva- connects two modules, one of which is not in-
ble. cluded in the system being described. Thus, the
system is thought of interacting with its environ-
2.2.3. The Form of Executable SFRs ment via external channels. On the other hand, if
An executable SFR is intended to specify the a channel is referred to by exactly two modules, it
system behavior in terms of possible orderings of is called an internal channel. That is, it is a chan-
externally observable input and output interac- nel connecting two modules which are included in
tions of the system. A Prolog program correspond- the system. For example, channels C21 and C22 in
ing to an executable SFR defines all possible Figure 1 are internal channels.
orderings of externally observable system interac- 4) Each internal channel is represented by a
tions via possible tours of the state space of the pair of interaction queues; one for each direction
system. It describes system transitions in terms of of information transfer. Thus, modules are inter-
transitions of the modules in the system. This connected by two queues as shown in Figure 2.
requires definitions of all possible state transitions The convention is that the input queue at the
of each module as Prolog clauses. These clauses interaction point of module Muv is the output
are constructed from the original EFSM based queue at the interaction point of module Mst, and
module descriptions. vice versa.
188 H. Ural, R.L. Probert / Communication Protocols and Se/vices

INPUT QUEUEFOR Mst


I result of a change in the state of one of the
QINst 4 4 I QOUTuv modules.
Mst
7) This assumption results in a set of clauses
CHANNELCpq I Muv
(SC) where each clause represents those system
QOUTst ) ) QINuy transitions that are due to a single transition in
INPUT QUEUEFOR Muv one of the modules. Thus, the number of clauses
in the set SC defining all possible system transi-
Fig. 2. Channels Between Modules.
tions is the same as the number of modules in the
system. A clause in the set SC (e.g., the one
defining all system transitions due to a single
transition of the module Mij) is of the form:
5) For each module Mij in the system, a set of t _ system(P_ System_ State, N _ System_ State,
clauses (SCMij) is constructed using the original System Input, System_ Output):-
description of the module given in the EFSM / * Queue operations to remove from the head
formalism. For each state transition defined in the of input interaction queues of the module
original description of the module Mij, the set Mij * /
SCMij contains a clause which is of the form: t _ Mij(P _ SMij,N _ SMij ,Input,Output)
t _ M i j ( P _ S M i j , N _ S M i j , I n p u t , O u t p u t ) :- ena- / * Queue operations to insert to the rear of
bling_condition,action. Here, P _ S M i j and output interaction queues of the module
N SMij stand for the present and the next state Mij * /
of the module Mij, respectively. Since the state of 8) The SFR is then the union of the set SC and
the module Mij (SMij) is determined by the values the sets SCMij (which are the sets of clauses
of all major and additional state variables of the defining transitions of each module in the system).
m o d u l e , P_SMij and N _ S M i j are two lists con- In the following sections, we describe the con-
taining values of state variables before and after struction of invocation routines which can be used
the execution of the transition. Input and Output to automatically invoke executable SFRs for the
are two lists representing interactions of the mod- purposes of generating or checking observable in-
ule Mij taking place during the transition. For teraction sequences.
each interaction point of the module, there exists
an element in both of these lists. Each element is
2.3. Trace and Trajectory Checking and Generation
either an empty list or a list containing interaction
point identifier, interaction identifier, and interac-
tion parameters depending on the absence or pres- An advantage of constructing executable SFRs
ence of an interaction at that interaction point, in Prolog is that they can be executed as either
respectively. The enabling condition is a set of generators or analyzers of the observable behavior
predicates which must hold for the transition to (i.e., i n p u t / o u t p u t interaction sequences) of
take place and actions define some relationships specified systems. The invocation of Prolog based
between mainly the present and the next values of SFRs for either of the above (as well as for
state variables. simulation) purposes is achieved by executing the
6) A SFR is intended to specify all possible following relation (denoted by "repeat_until")
orderings of externally observable system interac- which recursively invokes a given SFR:
tions through all possible system state tours. This
requires the definitions of all possible system tran- repeat until(Present_state, Final_state,
sitions. The system state is defined as the com- [Input,Output Rest of I0 sequence]):-
sfr(Present state, Next state, Input, Output),
position of the states of all the modules and the repeat until(Next state'Final state,
contents of all the interaction queues in the sys- Rest of I0 sequence).
repeat until(Present state,f:inal state,
tem. System transitions can be specified in terms [Input,Output]) :-
of transitions of modules in the system. For the sfr( Present_state, Final_state, Input, Output).
sake of simplicity, we assume that each system
transition corresponds to a transition of one of the Here, ":-" and "," read as "if" and " a n d " respec-
modules. That is, the system state changes as a tively. The first clause states that an input/output
H. Ural, R.L. Probert / Communication Protocols and Services 189

(IO) sequence is obtained on a path from the repeat until(Present state, Final state,
[Input Rest of I sequence.],
present state to the final state if i) the system [Output Rest_of 0 sequence]) :-
changes its state from the present state to a next sfr(Present state,Next state,input,Output),
state while performing some interactions (denoted repeat_until(Next state, Final state,
Rest of I sequence,
Input and Output) with its environment and ii) Rest of 0 sequence).
the rest of the i n p u t / o u t p u t sequence is obtained repeat until(Present s-;cate,Final state,
[Input], [Output]):-
on a subpath between the next state and the final sfr(Present_state,Final state,Input,Output).
state. The second clause applies to the last state
change which leads to the final state.
The relation " r e p e a t _ u n t i l " can be used for: This relation can also be used for simulation pur-
a) determining whether a given input/output in- poses such as determining possible final states that
teraction sequence (i.e., a trace or trajectory) can be reached from a given initial state or de-
actually results on some execution path be- termining possible execution paths between a given
tween a pair of states (e.g., initial and final pair of states, etc. Note that it is also possible to
states) in the SFR and construct a variant of the original relation which
b) generating possible sequences of input/output applies a given input interaction sequence to a
interactions performed by the SFR on its ex- SFR and records the output interactions inter-
ecution paths between a pair of states. leaved with applied input interactions in the order
The first use corresponds to trace and trajec- of occurrence. Such a relation is particularly usefull
tory checking where checking whether a trace of if one is interested in all possible interleavings of
SFR K + 1 is permitted by S F R _ K or whether a input and output interactions. The interested
trajectory of S F R _ K - 1 is achieved by S F R _ K is reader can refer to [12] for applications of variants
performed in the same manner: The given of " r e p e a t u n t i l " to reachability analysis.
i n p u t / o u t p u t interaction sequence is processed There are basically two disadvantages associ-
sequentially from left to right and a match for the ated with the run-time behavior of relation "re-
sequence is sought by recursively invoking peat_until" and its variants. One of the disad-
SFR K. vantages is that " r e p e a t _ u n t i l " may go into an
The second use corresponds to generating the infinite loop when a cycle is encountered. During
set of all possible interaction sequences. Often this the execution of a SFR, a cycle is encountered
set is intractably large due to the existence of large when the next state of the SFR happens to be one
number of combinations of valid values for inter- of the states already visited along the execution
action parameters, or self-loops in certain states, path. Such cycles are usually due to spontaneous
etc. Such a set can be restricted to a small number transitions whose enabling conditions include only
of interesting interaction sequences by guiding the those state variables which are not modified dur-
generation process with some selected input inter- ing the execution of these transitions. This disad-
action sequences. These input interactions se- vantage may be eliminated by embedding a loop
quences may be either specified by a tester a n d / o r detection mechanism into relation " r e p e a t _ until".
constructed automatically by employing some sys- An obvious loop detection mechanism is to carry
tematic test generation methods (e.g., transitions along the sequence of states visited so far to the
tours, distinguishing sequences, etc. [10,13]). Once next level of recursion and to check whether the
input interaction sequences are selected they may most recently reached state has already been
be used to guide the generation of actual or in- visited.
tended behavior (i.e., traces or trajectories) of The other disadvantage of " r e p e a t _ u n t i l " is
SFRs. That is, each sequence of input interactions that when it fails (i.e., terminates unsuccessfully) it
is applied to a SFR and the responses (i.e., output provides no indication about the nature and loca-
interactions) of the SFR are recorded in the order tion of failure. Such failures are usually due to
of occurrence as a separate sequence. This may be occurrences of unspecified receptions or unex-
achieved by a variant of relation " r e p e a t _ u n t i l " pected outputs which may indicate inconsistencies
which is constructed by splitting the IO_sequence between SFRs.
into two sequences, one for the input interactions Moreover, during trace and trajectory genera-
and the other for the output interactions: tion and checking, when " r e p e a t _ u n t i l " fails, it
H. Ural, R.L. Probert / Communication Protocols and Services 191

sal of a possible transition path through the com- dation (to relate protocol specifications to corre-
plete state space of a possibly non-deterministic sponding service specifications), and protocol test-
SFR. The set of possible transition paths is de- ing (to relate protocol implementations to corre-
termined by the applied sequence of input stimuli sponding protocol specifications).
and the set of possible spontaneous transitions at As an illustration of our approach, we consider
the states reached during the application of that the OSI transport protocol (TP) design validation
sequence of input stimuli. which aims to demonstrate that the collaboration
Thus, an algorithm for a generator is a variant of entities executing the TP as described in the TP
of the one for a checker obtained by replacing specification over an already validated network
steps taken for internal transitions with those steps service (NS) provides the transport service (TS) as
for spontaneous transitions and by logging the described in the TS specification. As shown in
states visited during traversal in order to construct Figure 3, this goal is attained via testing the
the corresponding traces or trajectories. behavioral equivalence of a refined TS provider
In Appendix B, we present a Prolog encoding (rts) which is composed of two TP entities (tpl
of an algorithm for trace and trajectory genera- and tp2) interacting over a NS provider (nsp) with
tors. This algorithm detects and reports unspeci- respect to the abstract TS provider (ts).
fied receptions and infinite loops (if any) and
terminates with irredundant traces or trajectories 3.1. Construction of the Abstract TS Provider
of deterministic or non-deterministic SFRs. It is
important to note that once S F R _ K - 1 has been A TS specification given in [4] describes the
validated, certified traces obtained during its externally observable behavior of an abstract TS
validation can be considered as trajectories for (or provider. Based on this specification, a SFR of the
potential traces of) S F R _ K . Also, input interac- abstract TS provider is constructed in Prolog as a
tion sequences extracted from validated traces of single procedure called "ts". Procedure "ts" is a
S F R _ K - 1 can be used to facilitate generation of collection of clauses defining the state transitions
traces of S F R _ K. of the abstract TS provider. The following clauses
In the next section, the use of this approach is define the first two transitions in "ts":
illustrated in the context of communication proto- ts([idle,idle,B12,B21],[idle,idle,B12,B21],
cols design and validation. [[tsapl,tcreq,PARAM1],[]],
[[tsapl,tdind,PARAM2],[]]):-
congestion,input([tsapl,tcreq,PARAM1]),
3. Application of the Approach to Design and output([tsapl,tdind,PARAM2]).
Development of Protocols ts([idle,idle,B12,B21],[wait_accept,idle,[],[]],
[[tsapl ,tcreq,PARAM1],[]],[[I,[]I) :-
Consider the Open Systems Interconnection n o _ congestion,input([tsapl,tcreq, PARAM1]).
(OSI) Reference Model [16]. Protocols and services The first and the second arguments in the conclu-
referred to in this model are developed in various sion of each clause are two lists representing the
phases starting with some natural language de- present and next state for the abstract TS pro-
scriptions which are called informal specifications. vider. The state of the provider is determined by
Formal specifications of protocols and services are the values of major state variables $1 and $2 and
usually based on these informal specifications. the contents of the internal buffers B12 and B21
Service specifications describe the service provided which are two additional state variables. (For the
by the layers whereas protocol specifications de- sake of simplicity, we ignore all other additional
scribe the behavior of protocol entities in those state variables in our examples throughout this
layers. Protocol implementations are developed paper). The third (forth) argument stands for in-
based on formal or informal protocol specifica- put (output) interactions at two transport service
tions. access points, namely, tsapl and tsap2. Here, an
Validation activities in a typical protocol devel- empty list (denoted by []) indicates that no input
opment process include: informal validation activ- or output interaction occurs at the related interac-
ities (to relate formal specifications to correspond- tion point. For example, in the second clause,
ing informal specifications), protocol design vali- [[I,[]], [[],[]]] indicates that only an input interac-
192 H. Ural, R.L. Probert / Communication Protocols and Services

TEST DRIVER

I1

tpl
a I

I
ts

rts

I
,I.:t2 tp2 |

/¢,'/ ~,\
I 1101 0101 nsp 1102 0102

Fig. 3. A configurationfor ProtocolDesignValidation.

tion I occurs at tsapl whereas no input and output of nsp, tpl, and tp2 which are obtained from the
interactions occur at tsap2. original NS and TP specifications, respectively.
Thus, the first clause corresponds to the transi- Based on the TP specification given in [5], a
tion initiated by the input interaction tcreq (carry- SFR of a TP entity is constructed as a collection
ing a list of parameters, denoted by PARAM1) at of clauses called procedure " t p " which defines the
tsapl and takes place when major state variables state transitions of the TP entity. Conclusions of
S1 = idle and $2 = idle and when there is conges- the clauses defining state transitions in procedure
tion in the system. There is no action related to " t p " are of the form:
this transition, only an output interaction (i.e., tp([PT, PBFU,PBTU],[NT,NBFU,NBTU],
tdind) is generated at tsapl. Note that the values [I _ tsap,I _ nsap],[O_ tsap,O_ nsap]).
of major state variables remain unchanged. Here, the state of the TP entity is determined by
The second clause corresponds to a transition the value of the major state variable T, and by the
that is initiated by an input interaction at tsapl contents of internal buffers BFU (buffer to store
changes the value of the major state variable S1 data from user) and BTU (buffer to store data to
and initializes internal buffers but does not gener- user). The third (forth) argument represents the
ate any output. Note that, procedures "input" and list of input (output) interactions at the transport
"output" are used to generate as well as recognize and the network service access points (i.e., tsap
input and output interactions with interaction and nsap). In order to construct two copies of this
parameters, respectively. These two procedures are SFR, each clause in " t p " is replicated while aug-
based on the definitions of interactions and menting each identifier in the clause with an in-
parameters. For more details, see [15]. teger (i.e., 1 or 2). Hence, the conclusion of each
clause defining a transition in " t p l " and "tp2"
3.2. Construction of the Refined TS Prooider (which stand for TP entity-1 and TP entity-2,
respectively) is written in the following form:
As shown in Figure 3, a refined TS provider tpl([PT1,PBFU1,PBTU1],[NT1,NBFU1,NBTU1],
(rts) is composed of a NS provider (nsp) and two [I_tsapl,I_nsapl],[O_tsapl,O_nsapl]).
TP entities (tpl and tp2). A SFR of the refined TS tp2([PT2,PBFU2,PBTU2],[NT2,NBFU2,NBTU2],
provider can be constructed by utilizing the SFRs [ I _ t s a p 2 , I _ n s a p 2 ] , [ O _ tsap2,O_nsap2]).
H. Ural, R.L. Probert / Communication Protocols and Sert,ices 193

Based on a NS specification, a SFR of the NS trajectory generation and checking are presented
provider can be constructed as a collection of in the following section.
clauses called procedure "nsp". This procedure
defines the state transitions of the NS provider. 3.3. Examples of Trace and Trajectory Generation
Assuming that a NS specification similar to the and Checking
TS specification in [4] is given, the state of the NS
provider is determined by the values of the two The Prolog procedure, denoted "totgen", given
major state variables $1 and $2, and by contents in Appendix B receives an input interaction se-
of internal buffers B12 and B21. Moreover, "nsp" quence and by applying this sequence to a SFR
is interconnected to both " t p l " and "tp2" at two (e.g., procedure "ts" or procedure "rts") generates
network service access points (nsapl and nsap2 all corresponding traces or trajectories as se-
respectively) via interaction queues. The outputs quences of input and output interactions. Each
O_nsapl and O_nsap2 (inputs I_nsapl and interaction sequence is represented as a list whose
I_nsap2) of " t p l " and "tp2" at nsapl and nsap2 elements are in the form of:
are the inputs (outputs) of "nsp" at those interac-
tion points. Hence, each state transition of the NS [Interaction-Type,[TSAP-Id,TS-Primitive-Type,
provider is represented in "nsp" by a clause whose TS-Primitive-Parameters]]
conclusion is as follows:
nsp(PS1,PS2,PB12,PB21],[NS1,NS2,NB12,NB21], where Interaction-Type is either "i" (stands for
[O_nsapl,O_nsap2][I_nsapl,I_nsap2]) input), or "o" (stands for output). TSAP-Id is the
Given the procedures "nsp", " t p l " , and "tp2", identifier for the access point at which the interac-
a Prolog procedure, denoted "rts", is constructed tion occurs. Note that if the interaction sequence
to specify the transitions of the refined TS pro- consists of only input interactions then the Inter-
vider in terms of transitions of its modules. Recall action-Type is dropped for simplicity.
that the system state is determined as a composi- Two examples of generating traces and trajec-
tion of the states of all the modules and the tories are given in Appendix C. In these examples,
contents of all the interaction queues in the sys- "totgen" is invoked via procedure "run-totgen"
tem. Thus, the system state of the refined TS which includes a group of sample input interac-
provider is defined as the composition of the tion sequences. Each invocation of procedure
states of " t p l " , "tp2", and "nsp" and the con- "run-totgen" contains the sequence number of the
tents of interaction queues IIQ1, OIQ1, IIQ2, and input interaction sequence to be passed to
OIQ2 (see Figure 3). Conclusion of each clause in "totgen". Accordingly, the first example involves
procedure "rts" is in the following form: generating traces of the refined TS provider. In
rts([PT1,PBFU1,PBTU1,PT2,PBFU2,PBTU2, this case, "totgen" applies the given input interac-
PS1,PS2,PB12,PB21, tion sequence to procedure "rts" and constructs
PIIQI,POIQ1,PIIQ2,POIQ2]/* PRESENT all corresponding traces of the refined TS pro-
SYSTEM STATE * / vider. In the second example, trajectories for the
[NTI,NBFU1,NBTU 1,NT2,NBFU2,NBTU2, refined TS provider are obtained from the abstract
NS1,NS2,NB12,NB21, TS provider. That is, "totgen" applies the given
NIIQ1,NOIQ1,NIIQ2,NOIQ2]/* NEXT input interaction sequence to procedure "ts" and
SYSTEM STATE * / records its responses interleaved with applied in-
[I_tsapl,I_tsap2],[O_ tsapl,O_ tsap2]) put interactions to construct all corresponding
Assuming that each transition of the refined TS trajectories.
provider corresponds to a change in the state of Note that, in these two examples, the same set
only one of its modules, procedure "rts" will of input interaction sequences is used for gener-
contain only three clauses: one for each system ating traces and trajectories. However, only those
transition caused by a transition in one of the traces of "rts" and trajectories of "ts" correspond-
modules. For more details, see [15]. ing to the last input interaction sequence are iden-
Both "ts" and "rts" may be employed by trace tical. The difference between sets of traces and
and trajectory generators and checkers to carry trajectories corresponding to the first two input
out validation activities. Examples of trace and interaction sequences stems from an inconsistency
194 H. Ural, R.L. Probert / Communication Protocols and Services

between "ts" and "rts": That is, "ts" does not designs, or implementations of a given system.
allow the connection initiator to terminate the The approach involves two complementary
connection establishment prior to receiving a con- consistency checking activities: namely, trace and
firmation whereas "rts" allows this particular type trajectory checking which seem to be appropriate
of termination. This inconsistency results in an to validation activities anticipated in a protocol
additional trace (i.e., the fifth trace) of "rts" cor- development process, particularly in the case of
responding to the first input interaction sequence layered protocols such as in the OSI Reference
and three traces of "rts" corresponding to the Model. In this context, trace checking can be used
second input interaction sequence. for relating formal specifications of services to
It is interesting to note that this inconsistency informal specifications expressed in a natural lan-
can be revealed during trace checking. However, guage. As well, both trace and trajectory checking
since no trajectory reflecting this situation could can be employed for protocol design validation
be generated from "ts", this particular incon- (relating protocol specifications to corresponding
sistency would not be revealed during trajectory service specifications) and for testing of protocol
checking. Thus, this is an interesting illustration implementations (relating implementations to pro-
taken from the public domain of the distinction tocol specifications).
between trace and trajectory checking. As an illustration of the feasibility and useful-
The Prolog procedure, denoted "totvar', given ness of the approach, we presented an application
in Appendix A receives an interaction sequence to design validation of a transport protocol. In
(i.e., either a trace or a trajectory) and by invoking this case, the abstraction (SFR_K-1) is the trans-
a SFR (e.g., procedure "ts" or procedure "rts") port service specification and the refinement
checks whether this interaction sequence is per- (SFR_K) is the refined transport service provider
missible or achiavable by this SFR. constructed from the transport protocol specifica-
In the examples included in Appendix D, pro- tion and the underlying network service specifica-
cedure "totval" is invoked via procedure "run- tion according to the OSI Reference Model. A
totval" which contains a group of sample interac- minor inconsistency was found, namely that a
tion sequences. Each invocation of procedure premature disconnection is permitted by the re-
"run-totval" carries an invocation sequence num- finement, yet is not allowed in the abstraction.
ber which identifies the sequence to be passed to We have shown how to construct SFRs in
"totval". In the first example, traces of the refined Prolog from specifications given in a popular
TS provider is checked by the abstract TS pro- EFSM formalism. Our focus was on the structure
vider. That is, "totval" is used to invoke proce- of these Prolog based SFRs rather than on the
dure "ts" to check whether traces of procedure specifics of translating EFSM constructs into
"rts" are permissible interaction sequences. In the equivalent Prolog constructs. The translation
second example, trajectories obtained from the methodology is straightforward, but does depend
abstract TS provider are applied to the refined TS on the particular definitions of EFSM constructs
provider. In this case, "totval" invokes procedure [141.
"rts" to check whether given interaction sequences A major advantage of constructing SFRs in
are achievable by this procedure. Notice that when Prolog is the capability of reversable execution of
the given interaction sequence is not achievable or these SFRs. This capability allows not only check-
permissible an error message is printed. ing and generating externally observable behaviors
of SFRs via their simulated execution, but also
utilization of SFRs as reference specifications for
4. Conclusions trace checking purposes. Another advantage of
Prolog-based SFRs seems to be the ease of con-
We have presented an approach for detecting structing tools (invocation routines) to direct trace
inconsistencies between different representations and trajectory checking and generation.
of the same system functionality. This approach is Finally, as does any other dynamic testing ex-
based on observable behaviors of SFRs at differ- ercise, this approach requires the selection of rep-
ent levels of abstraction. These SFRs may be resentative and discriminating test sequences (i.e.,
requirements, functional specifications, detailed input/output interaction sequences) to facilitate
H. Ural, R.L. Probert / Communication Protocols and Services 195

t r a c e a n d t r a j e c t o r y c h e c k i n g . S e l e c t i o n o f dis- [7] C. Jard, and G.v. Bochmann, An Approach to Testing


c r i m i n a t i n g s e q u e n c e s of i n p u t / o u t p u t interac- Specifications, Journal of Systems and Software, 3, 1983,
pp. 315-323.
t i o n s is a closely r e l a t e d p r o b l e m w h i c h is a d d r e s s -
[8] R. Kowalski, Logic For Problem Solving, New York,
e d in m o r e d e t a i l in e a r l i e r w o r k s [10,11,13], a n d is North-Holland, 1979.
the s u b j e c t of c o n t i n u i n g study. [9] R.L. Probert, D.R. Skuce, and H. Ural, Specification of
Representative Test Cases", Proc. of 16th Hawaii Int.
Conf. on System Sciences, Jan 1983, pp. 190-196.
[10] B. Sarikaya and G.v. Bochmann, Some Experience with
Acknowledgements
Test Sequence Generation for Protocols, Proc. of 2nd Int.
Workshop on Protocol Specification, Verification, and
T h e a u t h o r s g r a t e f u l l y a c k n o w l e d g e the s u p p o r t Testing, Cal, May 1982, pp. 555 567.
f r o m the N a t u r a l S c i e n c e s a n d E n g i n e e r i n g R e - [11] B. Sarikaya and H. Ural, Test Sequence Generation for
search Council of Canada. Protocols Using PROLOG, Tech. Report: TR-84-17, Dept.
of CSI, Univ. of Ottawa, 1984.
[12] D.P. Sidhu, Protocol Verification via Executable Logic
Specifications, Proc. of 3rd Int. Workshop on Protocol
References Specification, Verification, and Testing, Zurich, May 1983,
pp: 237-248.
[1] G.v. Bochmann, A General Transition Model for Proto- [13] H. Ural, and R.L. Probert, User-guided Test Sequence
cols and Communication Services, IEEE Trans. on Com- Generation, Proc. of 3rd lnt. Workshop on Protocol
munications, Vol. 28, No. 4, 1980, pp. 643-650. Specification, Verification, and Testing, Zurich, May 1983,
[2] G.v. Bochmann and C.A. Sunshine, Formal Methods in pp: 421-436.
Communication Protocol Design, IEEE Trans. on Com- [14] H. Ural, The Construction of Logic Specifications for
munications, Vol. 28, No. 4, 1980, pp. 624-631. Communication Protocols and Services, Tech. Report:
[3] W.F. Clocksin and C.S. Mellish, Programming in Prolog, TR-85-17, Dept. of CSI, University of Ottawa, 1985.
Springer-Verlag, 1981. [15] H. Ural, Logic Specifications for Communication Sys-
[4] G.v. Bochmann et al, A FDT Based on an Extended State tems, Proc. of PCCC 86, Phoenix, Arizona, March 1986,
Transition Model, ISO/TC 97/SG16/WG1, Subgroup B pp: 121-128.
on FDT, Mar 1981. [16] H. Zimmermann, OSI Reference Model-The ISO Model
[5] G.v. Bochmann, Example of a Transport Protocol Specifi- of Architecture for Open Systems Interconnection, IEEE
cation, ISO/TC 97/SG16/WG1, Subgroup B on FDT, Trans. on Communications, Vol. 28, No. 4. 1980, pp.
Nov 1982. 425-432.
[6] "Draft proposal of Estelle", ISO/TC 97/SG21/DP 9074,
June 1985.
196 H. Ural, R.L. Probert / Communication Protocols and Services

Appendix A

Trace and Trajectory Checker: Procedure “Totval”

totval(IOS) :- echo(IOS), initial(SPS), invoker(IOS,SPS).

invoker([],SPS) :- checker([],SPS).
invoker([[i,tsapl,I,P]],SPS):- checker([[[tsapl,I,P],[]],[[],[]]],SPS,SNS),
invoker([],SNS).
invoker([[o,tsapl,O,P]],SPS):- checker([[[],[]],[[tsapl,O,P],[]]],SPS,SNS),
invoker([],SNS).
invoker([[i,tsap2,I,P]],SPS):- checker([[[],[tsap2,I,P]],[[],[]]],SPS,SNS),
invoker([],SNS).
invoker([[o,tsap2,0,P]],SPS):- checker([[[],[]],[[],[tsap2,0,P]]],SPS,SNS),
invoker([],SNS).
invoker([[Sl,Cl,Il,Pl]~Rl],SPS):- Rl=[YIRZ], Y=[SZ,C2,12,P2],
((Sl=i, SZ=i, ((Cl=tsapl, R=Rl, ~=~~~~~~~~,~~1~~11~~~1,~111~
;(Cl=tsa@, R=Rl, ~=~~~1,~C~,~~,~111,~~1,~111~~~
;(Sl=i, S2=0, ((Cl=tsapl, CP=tsapl,
(R=Rl,~=~~~~~,~~,~~1,~11,~~1,~111
;R=R2,~=~~~~~,~~,~~1,~11,~~~~,~~,~~1,~111~~
;(Cl=tsapP, C2=tsap2,
(R=RI,~=~~~1,~~~,~~,~~11,~~1,~111
;R=@, ~=~~~1,~~~,~~,~~11,~~1,~~~,~~,~~111~~
;(Cl=tsapl, CZ=tsap2,
(R=Rl,~=~~~~~,~~,~~1,~11,~~1,[111
;R=Q, ~=~~~~~,~~,~~1~~11,~~1,~~~~~~,~~111~~
;(Cl=tsapE, C2=tsapl,
(R=RI,~=~~~1~~~~,~~,~~11~~~1,~111
;R=R2,~=~~~1,~~~,~~,~~11,~~~~,~~,~~1,~111~~~~
;(Sl=o, Cl=tsapl, R=Rl, O=[[[],[]],[[Cl,Il,pl],[]]])
;(Sl=o, Cl=tsapE, R=Rl, O=[[[],[]],[[],[Cl,Il,Pl]]])
) ,checker(O,SPS,SNS), invoker(R,SNS).

checker([],SNS) :- final( member(FS,SNS), nl, write('*,** VALID ***I),!.


checker(IO,SPS,SNS) :- for_each(IO,SPS,[],SSNS), ((SSNS=[],!,errorl(IO))
;(not(SSNS=[]), for_all(SSNS,[],SNS))).

/* Apply each invocation IO to each state CS in set SPS and


obtain set SSNS */

for each(_,[],X,X).
forIeach(IO,[CSIRESTSTATUS],LS,SSNS) :- get(IO,CS,LSTATUS),
append(LS,LSTATUS,LN), for_each(IO,RESTSTATUS,LN,SSNS).
get([I,O],PS,LSTATUS) :- INSERT_l...SEE COMMENTS
,setof(NS, T, LSTATUS), !.
W_9_9[l).
/* Find all states that can be reached by internal transitions
from each state in set SSNS and obtain set SNS */

for_all([],X,X).
for_all([CS/RS],LS,SNS) :- get_all(CS,LSl), union(LS,LSl,LN),
for_all(RS,LN,SNS),!.
get_all(CS,LSl) :- store_p(CS), not(each path(CS)), collect(LS1).
each_path(CS) :- get_each(CS,[CS]), fail.
get_each(PS,PSF) :- INSERT_E...SEE COMMENTS
,store_s(NS) ,check(NS,PSF), get_each(NS,[NSjPSF]).
get_each(_,_).

initial(INSERT_3...SEE COMMENTS).
final (INSERT_I...SEE COMMENTS).
H. Ural, R.L. Probert / Communication Protocols and Ser~,ices 197

/* U t i l i t y Procedures */

append([],X,X).
append([XIR],Y,[XIZ]) :- append(R,Y,Z).

member(X,[Xl_]).
member(X,[ IY]) :- member(X,Y).

union([],X,X).
union([XLR],Y,Z) :- member(X,Y) ,!, union(R,Y,Z).
union([XIR],Y,[XIZ]) :- union(R,Y,Z).
check(S,X) :- not(member(S,X)), store_p(S),!.
check(S,X) :- error2(S,X).
collect([XIR]) :- retract(p(X)), collect(R),
collect([]).
store_s(NS) :- not(s(NS)) , assert(s(NS)) ,!.
store_s(NS) :- fail.
store p(NS) :- not(p(NS)) , asserta(p(NS)) ,!
store_p(NS) :- fail.
echo(IOS) :- nl, w r i t e ( ' I n p u t Output Interaction Sequence'),
nl, outprint(lOS).
outprint([]).
outprint([HIT]) :- write(H) nl, outprint(T).

is_I([[I,[]],[[],[]]]).
is_I([[[],l],[[],[]]]).
is O ( [ [ [ ] , [ ] ] , [ o , [ ] ] ] ) .
is o ( [ [ [ ] , [ ] ] , [ [ ] , o ] ] ) .
get_type([ll,[]],[OZ,[]],1)
get_type([[],12],[[],02],2)
e r r o r l ( l O ) :-
( ( i s l(lO);is_O(lO)) -> nl, write('Execution Aborted')),
( i s _ l ( l O ) -> nl,write('Unspecified Reception Encountered:'),
nl,write(lO);true),
(is 0(I0) -> nl,write('Unexpected Output Encountered:'),
nl,write(lO);true),
( ( i s _ l ( l O ) ; i s 0(I0)) -> nl, w r i t e ( ' * * * NOT VALID * * * ' ) , n l ) , !, f a i l .
error2(Y,PSF) :-
nl, w r i t e ( ' I n f i n i t e idle loop encountered'),
nl, write('The p a t h : ' ) , nl, outprint(PSF),
nl, write('forms a loop w i t h : ' ) , nl, o u t p r i n t ( Y ) , ! , f a i l .

When " t o t v a l " is used to invoke


a) the abstract TS provider b) the refined TS provider
INSERT I T=..[ts,PS,NS,I,O] get type(l,O,X), T=..[rts,X,PS,NS,I,O]
INSERT-2 t s ( P S , N S , [ [ ] , [ ] ] , [ [ ] , [ ] ] ) rts(,PS,NS,[[],[]],[[],[]])
INSERT-3 [ [ i d l e , i d l e , [ ] , I l l ] [[shut,[],[],shut,[],[],
idle,idle,[],[],[],[],[],[]]]
INSERT 4 [idle,idle .... ] [shut . . . . . shut . . . . .
idle,idle ............ ]
*/
198 H. Ural, R. L. Probert / Communicarion Protocols and Services

Appendix B

Trace and Trajectory Generator: Procedure “Totgen ”

totgen(SIS) :- initial(SSi_l), echo(SIS), invoker(SSi_l,SIS), alltrace(SSi_1).

invoker(SSi_l,[]).
invoker(%i_l,[IIRIS]) :- for_each(I,SSi_l,[],SSINi),
((SSINi=[],!,errorl(SSi_l,I,RIS))
;(not(SSINi=[]), for_all(SSINi,[],SSi), invoker(SSi,RIS))).

/* Apply each input stimulus IS to each state CS in set SSi_l and


obtain set SSINi */

for_each(_,Cl,X,X).
for_each(IS,[CSjRESTSTATUS],LS,SSINi) :- get(IS,CS,LSTATUS),
append(LS,LSTATUS,LN), for_each(IS,RESTSTATUS,LN,SSINi).

get(Il,[_,[CNll PSI,_,_],LSTATUS) :- Il=[tsapllR], 12=[], CN is CNl+l,


T=..INSERT_l...SEE COMMENTS,
setof([[CNl~PS],[CN~NS],[I1,12],[01,02]],T,LSTATUS), ! .
get(I2,[_,[CNllPSl ,_,_],LSTATlJS) :- Il=[], 12=[tsapZ(R], CN is CNl+l,
T=..INSERT_E...SEE COMMENTS,
setof([~CNl~PS],~CN~NS],~Il,I2],[01,02]],T,LSTATUS), ! .
get(_,_,Cl).
/* Find all states that can be reached by spontaneous transitions
from each state in set SSINi and obtain set SSi */

for_all( 1,X,X).
for_all( CSIRS],LS,SSi) :- store_s(CS,T), ((T=O, for_all(RS,LS,SSi))
;(T= , get_all(CS,LSl), !, union(LS,LSl,LN), for_all(RS,LN,SSi))), !.

get_all(CS,LSl) :- store_p(CS), not(each_path(CS)), collect(LS1).


each_path([_,[CNlIPS],_,_]) :- get_each([CNljPS],[PS]), fail.
get_each([CNlIPS],PSF) :- INSERT_3...SEE COMMENTS,
Y=~~~~~l~Sl,C~~~lNSl,[[l,[ll,~~~,~~jl,
store-s(Y), check(Y,NS,PSF), get_each([CNljNS],[NSlPSF]).

alltrace([[_,IS,_ ,_]I) :- allpaths( traceout.


allpaths :- final( at(IS,FS,T), not(path(T)), assert(path(T)), fail
allpaths(

at([IlX],[JlX],[]) :- not(I=J).
at(X,Y,Z) :- s([X,Xl,I,O]), at(Xl,Y,Zl), rmv(I,O,V), append(V,Zl,Z).

initial INSERT_4...SEE COMMENTS).


final INSERT_5...SEE COMMENTS).
H. Ural, R.L. Probert / Communication Protocols and Seruices 199

/* U t i l i t y Procedures */

append([],X,X).
append([XIR],Y,[X]Z]) :- append(R,Y,Z).

member(X,[X1 ]).
member(X,[_IY]) :- member(X,Y).
union([],X,X).
union([XIR],Y,Z ) :- member(X,Y) ,!, union(R,Y,Z).
union([XIR],Y,[XIZ]) :- union(R,Y,Z).
check(Y,S,X):- not(member(S,X)), store=p(Y),!.
check(Y,S,X):- error2(S,X).
collect([XIR] :- retract(p(X)), collect(R),
collect([]).
store s(NS,I) - not(s(NS)), assert(s(NS)), !
store_s(NS,O)
store_s(NS) :- not(s(NS)), assert(s(NS)), !.
store_s(NS) :- f a i l .
store_p(NS) :- not(p(NS)), asserta(p(NS)), !.
store p(NS) :- f a i l .
traceout:- retract(path(T)), traceprint(T), nl, traceout.
traceout.
traceprint([]).
t r a c e p r i n t ( [ X I T ] ) :- write(X), nl, w r i t e ( ' ' ) , traceprint(T).
l i s t s :- s(L), w r i t e ( L ) , nl, f a i l .
outprint([]).
o u t p r i n t ( [ X I T ] ) :- write(X), nl, outprint(T).
echo(SIS) :- nl, w r i t e ( ' I n p u t Interaction Sequence i s : ' ) , nl, outprint(SIS),
nl, write('Trace or trajectory i s ( a r e ) : ' ) , nl.
e r r o r l ( I S , l , R l S ) :-
nl, write('Execution Aborted. Unspecified reception encountered.'),nl,
nl, w r i t e ( ' A l l possible Status that the representation can be'),
nl, w r i t e ( ' a f t e r the application of previous Input I n t e r a c t i o n . ' ) ,
nl, o u t p r i n t ( I S ) ,
nl, write('Current Input Interaction Sequence:'), nl, write(1), nl,
nl, write(tRest of Input Interaction Sequence:'), nl, outprint(RIS),
nl, write('Status seen up to this p o i n t : ' ) , nl, n o t ( l i s t s ) , !, f a i l .
error2(Y,PSF) :-
nl, write('Execution Aborted. I n f i n i t e Idle loop encountered'),
nl, write('The p a t h : ' ) , nl, outprint(PSF),
nl, write('forms a loop w i t h : ' ) , nl, outprint(Y), !, f a i l .
When "totgen" is used to invoke
a) the abstract TS provider b) the refined TS provider
INSERT 1 [ t s , P S , N S , [ I I , 1 2 ] , [ 0 1 , 0 2 ] ] [rts,I,PS,NS,[II,12],[01,02]],
INSERT-2 [ t s , P S , N S , [ I I , 1 2 ] , [ 0 1 , 0 2 ] ] [rts,2,PS,NS,[II,12],[OI,02]],
INSERT-3 ts(PS,NS,[[],[]],[01,02]) rts(_,PS,NS,[[],[]],[01,02]),
INSERT~4 [ [ _ , [ O , i d l e , i d l e , [ ] , [ ] ] . . . . ]] [[_,[O,shut,[],[],shut,[],[],
idle,idle,[],[],[],[],[],[]] . . . . ]]
INSERT_5 [O,idle,idle .... ] [O,shut . . . . . shut . . . . .
idle,idle ............ ]
200 14. Ural, R.L. Probert / Communication Protocols and Services

Appendix C
run_totgen(Z) :- clear [i,[tsapl,tcreq,p]]
,input_interaction_sequence(Z,X) [o,[tsap2,tcind,p]]
,totgen(X). [i,[tsap2,tareq,p]]
clear :- retract(s(_)), f a i l . [i,[tsap2,tdatr,1]]
clear. [o,[tsapl,taind,p]]
input_interaction_sequence(l,[ [i,[tsapl,tdreq,user]]
[tsapl,tcreq,p], [o,[tsap2,tdind,user]]
[tsap2,tareq,p],
[tsap2,tdatr,1], [i,[tsapl,tcreq,p]]
[tsapl,tdreq,user] [o,[tsap2,tcind,p]]
]). [i,[tsap2,tareq,p]]
input_interaction_sequence(2,[ [i,[tsap2,tdatr,1]]
[tsapl,tcreq,p], [i,[tsapl,tdreq,user]]
[tsapl,tdreq,user] [o,[tsap2,tdind,user]]
]),
input interaction_sequence(3,[ yes
[tsapl,tcreq,p], I ?- run totgen(2).
[tsap2,tdreq,user] Input InTeraction Sequence is:
]). [tsapl,tcreq,p]
[tsapl,tdreq,user]
Trace or trajectory is(are):
EXAMPLEC-I [i,[tsapl,tcreq,p]]
[o,[tsap2,tcind,p]]
C-Prolog version 1.4a
[i,[tsapl,tdreq,user]]
[ Restoring f i l e /.plstartup ] [o,[tsap2,tdind,user]]
[ ?- [rts,tpl,tp2,nsp,totgen,run_totgen].
rts consulted 2052 bytes 0.85 sec.
tpl consulted 6496 bytes 3.1 sec.
[i,[tsapl,tcreq,p]]
[i,[tsapl,tdreq,user]]
tp2 consulted 6868 bytes 3.36667 sec. [o,[tsap2,tcind,p]]
nsp consulted 9760 bytes 4.45 sec. [o,[tsap2,tdind,user]]
totgen consulted 8068 bytes 2.76667 sec.
run totgen consulted 996 bytes 0.400007 sec. [i,[tsapl,tcreq,p]]
[i,[tsapl,tdreq,user]]
yes
[ ?- run totgen(1).
Input InTeraction Sequenceis:
yes
I ?- run totgen(3).
[tsapl,tcreq,p] Input InTeraction Sequence is:
[tsap2,tareq,p] [tsapl,tcreq,p]
[tsap2,tdatr,1] [tsap2,tdreq,user]
[tsapl,tdreq,user]
Trace or trajectory is(are):
Trace or trajectory is(are): [i,[tsapl,tcreq,p]]
[i,[tsapl,tcreq,p]] [o,[tsap2,tcind,p]]
[o,[tsap2,tcind,p]] [i,[tsap2,tdreq,user]]
[i,[tsap2,tareq,p]] [o,[tsapl,tdind,user]]
[o,[tsapl,taind,p]]
[i,[tsap2,tdatr,1]] yes
[o,[tsapl,tdati,1]] I ?- halt.
[i,[tsapl,tdreq,user]] [ Prolog execution halted ]
[o,[tsap2,tdind,user]]
[i,[tsapl,tcreq,p]] EXAMPLEC-2
[o,[tsap2,tcind,p]]
[i,[tsap2,tareq,p]] C-Prolog version 1.4a
[o,[tsapl,taind,p]] [ Restoring f i l e /.plstartup ]
[i,[tsap2,tdatr,1]] I ?- [ts, totgen, run totgen].
[i,[tsapl,tdreq,user]] setparam tsp consulted 992 bytes 0.683336 sec
[o,[tsap2,tdind,user]] ts consulted 9208 bytes 5.45 sec.
totgen consulted 7904 bytes 4.6 sec.
[i,[tsapl,tcreq,p]] run_totgen consulted 996 bytes 0.616667 sec.
[o,[tsap2,tcind,p]]
[i,[tsap2,tareq,p]] yes
[i,[tsap2,tdatr,1]] [ 7- run totgen(1).
[o,[tsapl,taind,p]] Input InTeraction Sequence is:
[o,[tsapl,tdati,1]] [tsapl,tcreq,p]
[i,[tsapl,tdreq,user]] [tsap2,tareq,p]
[o,[tsap2,tdind,user]] [tsap2,tdatr,l]
[tsapl,tdreq,user]
H. UraL R.L. Probert / Communication Protocols and Services 201

Trace or trajectory is(are): Trace or trajectory is(are):


[i,[tsapl,tcreq,p]] [i,[tsapl,tcreq,p]]
[o,[tsap2,tcind,p]] [o,[tsap2,tcind,p]]
[i,[tsap2,tareq,p]] [i,[tsap2,tdreq,user]]
[o,[tsapl,taind,p]] [o,[tsapl,tdind,user]]
[i,[tsap2,tdatr,1]]
[o,[tsapl,tdati,1]] yes
[i,[tsapl,tdreq,user]] i ?- halt.
[o,[tsap2,tdind,user]] [ Prolog execution halted ]
[i,[tsapl,tcreq,p]]
[o,[tsap2,tcind,p]]
[i,[tsap2,tareq,p]]
[o,[tsapl,taind,p]] Appendix D
[i,[tsap2,tdatr,1]]
[i,[tsapl,tdreq,user]]
[o,[tsap2,tdind,user]] run totval(X) :- clear
,interaction sequence(X,S)
[i,[tsapl,tcreq,p]] ,totval(S).
[o,[tsap2,tcind,p]] clear:- retract(s(_)), f a i l .
[i,[tsap2,tareq,p]] clear.
[i,[tsap2,tdatr,l]] interaction sequence(l,[
[o,[tsapl,taind,p]] [i,tsapl,tcreq,p]
[o,[tsapl,tdati,l]] [o,tsap2,tcind,p]
[i,[tsapl,tdreq,user]] [i,tsap2,tareq,p]
[o,[tsap2,tdind,user]] [i,tsap2,tdatr,l]
[i,tsap2,tdatr,2]
[i,[tsapl,tcreq,p]] [o,tsapl,taind,p]
[o,[tsap2,tcind,p]] [i,tsapl,tdatr,1]
[i,[tsap2,tareq,p]] [i,tsapl,tdatr,2]
[i,[tsap2,tdatr,1]] [o,tsapl,tdati,1]
[o,[tsapl,taind,p]] [i,tsapl,tdatr,3]
[i,[tsapl,tdreq,user]] [o,tsapl,tdati,2]
[o,[tsap2,tdind,user]] [o,tsap2,tdati,1]
[o,tsap2,tdati,3]
]).
yes interaction_sequence(2,[
I ?- run totgen(2). [i,tsapl,tcreq,p],
Input Interaction Sequence is: [o,tsap2,tcind,p],
[tsapl,tcreq,p] [i,tsap2,tareq,p],
[tsapl,tdreq,user] [i,tsap2,tdatr,1],
[i,tsap2,tdatr,2],
Trace or trajectory is(are): [o,tsapl,taind,p],
[i,tsapl,tdatr,1],
Execution Aborted. Unspecified reception encountered. [i,tsapl,tdatr,2],
[o,tsapl,tdati,1],
All possible Status that the representation can be [i,tsapl,tdatr,3],
after the application of previous Input Interaction. [o,tsapl,tdati,2],
[[l,wait accept,idle,[],[]],[1,wait accept,wait_accept,[],[]], [o,tsap2,tdati,1],
[[],[]],[[],[tsap2,tcind,p]]] [i,tsapl,tdreq,user],
[[O,idle,idle,E],[]],El,wait accept,idle,I],[]], [o,tsap2,tdind,user]
[[tsapl,tcreq,p],[]],[[],[]]] ])-
interaction sequence(3,[
Current Input Interaction Sequence: [i,tsapl,tcreq,p],
[tsapl,tdreq,user] [o,tsap2,tcind,p],
[i,tsap2,tareq,p],
Rest of Input Interaction Sequence: [i,tsap2,tdatr,1],
[o,tsapl,taind,p],
Status seen up to this point: [i,tsapl,tdatr,2],
[[O,idle,idle,[],[]],[1,wait_accept,idle,[],[]], [o,tsapl,tdati,l],
[[tsapl,tcreq,p],[]],[[],[]]] [o,tsap2,tdati,1]
[[1,wait accept,idle,[],[]],[1,wait_accept,wait_accept,[],[]], ]).
[[],[]],[[],[tsap2,tcind,p]]] interaction sequence(4,[
[i,tsapl,tcreq,p],
no [o,tsap2,tcind,p],
( 7- run totgen(3). [i,tsap2,tareq,p],
Input Interaction Sequence is: [i,tsap2,tdatr,l],
[tsapl,tcreq,p] [o,tsapl,taind,p],
[tsap2,tdreq,user] [i,tsapl,tdatr,2],
[o,tsapl,tdati,1],
[o,tsap2,tdati,2],
[i,tsapl,tdreq,user],
[o,tsap2,tdind,user]
]).
202 14, Ural, R.L. Probert / Communication Protocols and Services

EXAMPLE D-I EXAMPLE D-2


C-Prolog version 1.4a C-Prolog version 1.4a
[ Restoring f i l e /.plstartup ] [ Restoring f i l e /.plstartup ]
I ?- Its, totval, run totval]. I ?- [rts,tpl,tp2,nsp,totval,run_totval]
setparam tsp consulted 992 bytes 0.416669 sec. rts consulted 2052 bytes 0.783333 sec.
ts consulted 9208 bytes 3.28333 sec. tpl consulted 6496 bytes 2.98333 sec.
totval consulted 8528 bytes 2.78333 sec. tp2 consulted 6868 bytes 3.3 sec.
run totval consulted 1948 bytes 0.550004 sec. nsp consulted 9760 bytes 4.3 sec.
totval consulted 8784 bytes 2.76667 sec.
yes run totval consulted 3072 bytes 0.85 sec
I ?- run totval(1).
Input OuTput Interaction Sequence yes
[i,tsapl,tcreq,p] I ?- run totval(3).
[o,tsap2,tcind,p] Input OuTput Interaction Sequence
[i,tsap2,tareq,p] [i,tsapl,tcreq,p]
[i,tsap2,tdatr,1] [o,tsap2,tcind,p]
[i,tsap2,tdatr,2] [i,tsap2,tareq,p]
[o,tsapl,taind,p] [i,tsap2,tdatr,1]
[i,tsapl,tdatr,l] [o,tsapl,taind,p]
[i,tsapl,tdatr,2] [i,tsapl,tdatr,2]
[o,tsapl,tdati,1] [o,tsapl,tdati,1]
[i,tsapl,tdatr,3] [o,tsap2,tdati,1]
[o,tsapl,tdati,2]
[o,tsap2,tdati,1] Execution Aborted
[o,tsap2,tdati,3] Unexpected Output Encountered:
[[[],[]],[[],[tsap2,tdati,1]]]
Execution Aborted *** NOT VALID ***
Unexpected Output Encountered:
[[[],[]],[[],[tsap2,tdati,3]]] no
*** NOT VALID *** I ?- run totval(4).
Input OuTput Interaction Sequence
no [i,tsapl,tcreq,p]
I ?- run totval(2). [o,tsap2,tcind,p]
Input OuTput Interaction Sequence [i,tsap2,tareq,p]
[i,tsapl,tcreq,p] [i,tsap2,tdatr,1]
[o,tsap2,tcind,p] [o,tsapl,taind,p]
[i,tsap2,tareq,p] [i,tsapl,tdatr,2]
[i,tsap2,tdatr,1] [o,tsapl,tdati,1]
[i,tsap2,tdatr,2] [o,tsap2,tdati,2]
[o,tsapl,taind,p] [i,tsapl,tdreq,user]
[i,tsapl,tdatr,1] [o,tsap2,tdind,user]
[i,t~apl,tdatr,2]
[o,tsapl,tdati,1] *** VALID ***
[i,tsapl,tdatr,3] yes
[o,tsapl,tdati,2] I ?- halt.
[o,tsap2,tdati,l] [ Prolog execution halted ]
[i,tsapl,tdreq,user]
[o,tsap2,tdind,user]

*** VALID ***


yes
[ ?- halt.
[ Prolog execution halted ]