245
A Software Design Method and Its
Application to Protocol and Communication
Software Development
Norio SHIRATORI, Kaoru TAKAHASHI
and Shoichi NOGUCHI
Research Institute of Electrical Communication, Tohoku Univer-
sity, 2-1-1, Katahira, Sendai, Japan 980
This paper proposes an approach, called "the Harmonic
Design Method", to achieve an approximately ideal language
that simultaneously serves the purposes or requirements of
software specification, verification, implementation and so on.
This approach is based on two important concepts--partition-
ing and unification. In the Harmonic Design Method, the
collection of the problem-oriented languages and the transfor-
mation algorithms between the languages, provided through
the process of the partitioning and unification, is regarded as
the approximation to the target ideal language. As an applica-
tion of the Harmonic Design Method, the design of a software
support system for making the development of protocols and
communication software easy is given. In this design, we
provide three problem-oriented languages, viz., the protocol
Norio Shiratorl was born in Miyagi
Prefecture, Japan, on May 11, 1946.
He received the B.E. degree in Electri-
cal Engineering from Tokai Univer-
sity, Tokyo, in 1972, and the M.E. and
Ph.D. degrees in Electrical and Com-
munication Engineering from Tohoku
University, Sendai, in 1974, and 1977,
respectively. He has joined RIEC (Re-
search Institute of Electrical Com-
munication), Tohoku University,
Sendai, since 1977, and he is now an
Associate Professor in the Faculty of
Engineering of Tohoku University. He has engaged in research
in an intelligent distributed processing system based on a
computer communication network including software design.
He is, currently, heading the groups that are designing software
of a communication protocol, network OS, protocol specifica-
tion languages, validation methods, protocol synthesizing
methods and conformance testing. He, also, works on parallel
processing and computer architecture. He is, presently, the
Chairman of the conformance testing committee of Japan.
Prof. N. Shiratori received the 25th anniversary of IPSJ(In-
formation Processing Society of Japan)'s memorial prize-win-
ning paper award on November 1985. He is a member of
IEEE, IPSJ and IEICE (The Institute of Electronics Informa-
tion, and Communication Engineers of Japan).
North-Holland
Computer Networks and ISDN Systems 15 (1988) 245-267
0169-7552/88/$3.50 © 1988, Elsevier Science Publishers B.V. (North-Holland)
specification language NESDEL, the communication software
oriented programming language IDL and the language EXPA
which has both a framework for expressing protocols and an
algorithm for verifying protocols, and three transformation
algorithms between them, i.e., NESDEL-to-EXPA, EXPA-to-
NESDEL and NESDEL-to-IDL. The details of these lan-
guages and transformation algorithms are also given. Finally,
we introduce some software tools used for supporting these
languages and transformation algorithms.
Keywords: Software Design Method, Protocols, Communi-
cation Software, Protocol Verification, Protocol Implementa-
tion, Specification Language, Programming Language, Com-
puter Networks, Support System for Protocol Development.
Kaoru Taluda~hi was born in Miyagi
Prefecture, Japan, On January 9, 1954.
He has joined the Research Institute
of Electrical Communicationi Tohoku
University, in 1974. Currently a re-
search assistant, he is doing research
of protocol specification, verification,
synthesis and implementation in dis-
tributed processing systems based on
computer networks. Mr. K. Takahashi
received the 25th anniversary of IPSJ's
memorial prize-winning paper award
on November 1985. He is a member
of the IEICE (The Institute of Electronics, Information and
Communication Engineers of Japan), the IPSJ (Information
Processing Society of Japan) and the computer society of
IEEE.
Simiehi Naguehi was born in Tokyo,
Japan, on March 5, 1930. He received
the B.E., M.E. and Ph.D. degrees in
electrical and communication en-
gineering from Tohoku University,
Sendai, in 1954, 1956 and 1960, re-
spectively. He has joined RIEC (Re-
search Institute of Electrical Com-
munication), Tohoku University,
Sendai, and has been a professor in
the Faculty of Engineering of Tohoku
University since 1971. He has engaged
in research of theoretical field of in-
formation science and computer network fundamentals. He is,
presently, the director of the computer center of Tohoku
University.
Prof. S. Noguchi received the 25th anniversary of IPSJ's
memorial prize-winning paper award on November 1985. He is
a member of the IEICE (The Institute of Electronics, Informa-
tion and Communication Engineers of Japan) and the IPSJ
(Information Processing Society of Japan).
246 N. Shiratori et al. / A Software Design Method
1. Introduction
The tendency towards distributed computing
and computer communication networks is increas-
ing the development cost as well as the complexity
of protocols and communication software. There-
fore, much work has been done in finding method-
ologies and tools for efficiently developing proto-
cols and communication software. These method-
ologies and tools help protocol designers and pro-
tocol implementors in the formal specification and
verification of protocols, the development of com-
munication software for implementing protocols,
the testing of protocol implementations, and so
on.
Different techniques or languages have been
proposed for specifying and/or verifying proto-
cols. These may be classified into four categories:
(1) techniques based on state transition models
[1-4,6-10,12-19,26-28,38,39],
(2) techniques based on logic [5,22,29],
(3) techniques based on events and event rela-
tionships [23,30], and
(4) axiomatic techniques based on algebraic
axioms [20,25].
Among others, the techniques belonging to the
category (1) have been extensively used for speci-
fying and/or verifying several real-world proto-
cols. The state transition models are also useful
for protocol synthesis [43-45]. There are some
programming languages used for protocol imple-
mentations. For example, FAPL [12-14] and IDL
[40] are languages suitable for this purpose. The
protocol specification language ESTELLE [28]
proposed by ISO may be regarded as one of such
programming languages provided that its compiler
is provided and the compiler can produce ap-
propriate code modules which implement the im-
plementation-dependent portions of a specifica-
tion. It is important to test protocol implementa-
tions. If a protocol implementation is not pro-
duced in conformance with its corresponding pro-
tocol specification, then that implementation is
useless. For that reason, several conformance test-
ing methods (or, tools) have been proposed [34,35].
It is also useful to develop a support system which
provides an integrated set of tools for developing
protocols and the communication software corre-
sponding to those protocols. The systems devel-
oped by Blumer et al. [1,2] and Bochmann et al.
[3] are examples of such systems. Shiratori et al.
proposed a systematic design method of com-
munication systems including protocol and com-
munication software development [36,37]. The
above-mentioned system and design method help
in the specification, verification and implementa-
tion of protocols.
Ideally, it is desirable to design a single lan-
guage or formalism that can help users and com-
puters not only in the formal specification of
protocols but also in the verification and imple-
mentation of protocols and the conformance test-
ing of protocol implementations. However, it is a
crucial problem to design such an "ideal
language", because it should simultaneously satisfy
all the requirements for specification, verification,
implementation and testing.
In this paper, we propose a new approach,
called Harmonic Design Method, to achieve ap-
proximately an ideal language that simultaneously
satisfies several purposes. And, we describe its
application to protocol and communication soft-
ware development. The Harmonic Design Method
is based on two concepts: partitioning and uni-
fication. By partitioning, we mean a process by
which several types of problem-oriented languages
(e.g., specification language, programming lan-
guage) are provided, in order to accomplish differ-
ent requirements desired in the target ideal lan-
guage. By unification, we mean a process by which
the problem-oriented languages obtained by parti-
tioning are associated with each other. This uni-
fication is accomplished by providing transforma-
tion algorithms between the problem-oriented lan-
guages. As a result of the partitioning and unifica-
tion, we think of the collection of the problem-ori-
ented languages and the transformation al-
gorithms as an approximation to the target ideal
language. The details of the Harmonic Design
Method are described in the next section. As an
application of the Harmonic Design Method, we
have been developing a support system for proto-
cols and communication software development. In
this support system, three problem-oriented lan-
guages are provided, i.e., NESDEL [39], EXPA
[38] and IDL [40]. The transformation algorithms
between these languages are also provided.
NESDEL is a protocol specification language. It is
conceptually similar to SDL [15] and ESTELLE
[28J--they are all based on a state transition
model. However, a NESDEL specification is com-
posed of two parts: a directed graph part and a
 N. Shiratori et al. / A Software Design Method
primitive part. The directed graph part expresses
the control flow of the protocol, and the primitive
part defines symbols such as variables used in the
directed graph part. The aim of NESDEL is to
enhance the understandability and to avoid the
ambiguity of a protocol specification, by using
"graphs" and "primitives" at the same time. IDL
is a high-level programming language, based on
the concept of a finite-state machine with varia-
bles and program segments, for describing com-
munication software. It has concise language con-
structs needed to describe communication-ori-
ented software. And, it closely resembles
NESDEL, in its underlying concept. EXPA is a
method for validating certain properties of proto-
cols. It has an appropriate representation for sup-
porting validation. EXPA is a generalization of
the validation method, based on perturbation
analysis, proposed by West [8]. Its validation abil-
ity is superior to that by West. EXPA also resem-
bles NESDEL, in its underlying concept.
This paper is organized as follows. Section 2
gives, in detail, the Harmonic Design Method
described above. As an application of the
Harmonic Design Method, the design of a support
system for protocols and communication software
development is outlined in Section 3. The protocol
specification language NESDEL, the communica-
tion software oriented programming language IDL
and the protocol validation method EXPA, which
are components of the support system given in
Section 3, are described in Sections 4, 5 and 6,
respectively. Section 7 outlines the algorithms used
for the transformation between these languages.
Some of tools used for supporting these languages
and transformation between these languages are
introduced in Section 8.
2. Harmonic Design Method
In general, when a designer is going to design a
language for software development, he has to pay
attention to various requirements. For example,
the language should be easy to read, write and
learn, and it should have a high expressibility.
Furthermore, it may be required that the language
should provide the capability of verifying certain
properties. These conditions become more and
more important as the software system grows
larger in size and complexity. It is a crucial prob-
247
lem to design an ideal language that simulta-
neously satisfies all these required conditions.
The Harmonic Design Method is a new ap-
proach that we propose to achieve approximately
the above-mentioned ideal language. The ap-
proximation is carried out by the process of parti-
tioning and unification. By partitioning, we mean a
process by which several types of problem-ori-
ented languages are provided, in order to satisfy
the different requirements or purposes desired in
the target ideal language. By unification, we mean
a process by which the problem-oriented lan-
guages produced by partitioning are associated
with each other, in order to achieve approximately
the target ideal language. This unification is
accomplished by providing transformation
algorithms between the problem-oriented lan-
guages. Providing "bidirectional" transformation
algorithms between two languages is very useful.
For example, assume that a specification language
and a programming language are given as prob-
lem-oriented languages, and that both a forward
transformation algorithm, i.e., an algorithm for
transforming the specification language into the
programming language, and a backward transfor-
marion algorithm, i.e., an algorithm for transfor-
ming the programming language into the specifi-
cation language, are provided (note that the back-
ward transformation can be accomplished by using
the information derived from the forward trans-
formation). If a user detects "bugs" while debug-
ging an expression written in the programming
language, then he has to, possibly, not only debug
the expression but also revise the corresponding
specification written in the specification language.
Given the provision of backward transformation,
it is relatively easy to do such task, since the user
can easily detect the portion in the specification
corresponding to the "bugs" by using this provi-
sion. On the other hand, without such a provision,
it is generally difficult to do such a task, and
consequently a heavier maintenance cost is
incurred.
We regard the collection of the problem-ori-
ented languages and the transformation algorithms
produced through the process of partitioning and
unification as an approximation to the target ideal
language.
The design procedure of the Harmonic Design
Method is outlined in Fig. 1. The details are as
follows.
248 N. Shiratori et al. / A Software Design Method
n types of problem
oriented languages
@ partitioning
approximation
Fig. 1. The approach of the Harmonic Design Method.
Harmonic Design Method
Harmonic Step 1
(1) Partitioning
Provide n types of problem-oriented lan-
guages to serve the specific purposes.
(2) Unification
Provide m types of transformation algor-
ithms among the n types of problem-ori-
ented languages produced in (1), in order to
achieve approximately the target ideal lan-
guage.
Remark: The n types of problem-oriented
languages should be designed based on the
same fundamental concept so that the
transformation between these languages can
be performed easily.
Harmonic Step 2
Use weak verification methods positively and
repeatedly, to verify specification, software
description, etc. written in the languages pro-
duced in Harmonic Step-1.
These days, some verification methods try to
prove the complete correctness of specification
and program, but it m a y be impossible to apply
them in practical software programs because of
various limitations. Here, a weak verification
method means a method that has low verification
capability, but can be extensively applied in prac-
tical software. For example, the perturbation anal-
ysis [8] used in protocol verification is one such
weak verification method since it helps in only
detecting some fixed logical errors specified in
advance such as deadlock, but it can be exten-
sively applied in real-world protocols. In Harmonic
transformation algorithms
between the languages
unification
Step 2, we use such weak verification methods
repeatedly, in order to enhance the productivity of
software development.
In the sequel, the Harmonic Design Method
gives a methodology to efficiently develop desira-
ble software or programs.
3. Application of the Harmonic Design Method to
Protocol and Communication Software Develop-
ment
In this section, we discuss an application of the
Harmonic Design Method described in the pre-
ceding section to the design of a support system
for protocol and communication software devel-
opment. The objective of this software support
system is to provide its users with a desirable
environment in which the users may develop pro-
tocols and software easily.
In this application of the Harmonic Design
Method, we conceive this support system as an
approximation to the target ideal language which
is useful for protocol specification, verification
and implementation. In other words, we would
like to construct a system in which users can
accomplish such tasks as protocol specification,
verification and implementation, using only a
single language. We provide three types of prob-
lem-oriented languages each pertaining to a
specific task. NESDEL (NEtwork protocol Speci-
fication and DEscription Language) [39] is a pro-
tocol-oriented specification language. It is based
on a finite-state machine, and specifies a protocol
in terms of the protocol machine (i.e., a finite-state
 N. Shiratori et al. / A Software Design Method
machine) expressing the behavior of the protocol.
IDL (Implementation and Design Language) [40]
is a high-level programming language for describ-
ing communication software. EXPA (EXtended
Perturbation Analysis) [38] is a protocol verifica-
tion method. It has a suitable representation form
for protocol verification. NESDEL, IDL and
EXPA are designed based on the same
concept--that of a finite-state machine. The de-
tails of these languages are described in Sections
4, 5 and 6, respectively. We provide three transfor-
mation algorithms in this support system for
transforming
(a) NESDEL expressions into EXPA expres-
sions,
(b) EXPA expressions into NESDEL expres-
sions, and
(c) NESDEL expressions into IDL expressions.
Transformation algorithm (b) is used for making
results of the protocol verification performed in
the EXPA expressions, given as the result of the
execution of transformation algorithm (a), reflect
on the original NESDEL expressions. That is,
users do not need to know the expressions used in
verification. The details of these transformation
algorithms are described in Section 7. EXPA is an
example of the weak verification method we have
used in an application of Harmonic Step 2. By
using EXPA, NESDEL expressions are checked
for deadlock occurrences, completeness, etc. In
practice, this verification is performed after the
NESDEL expressions are transformed into their
corresponding EXPA expressions by transforma-
tion algorithm (a).
To sum up, the Harmonic Design Method is
applied as follows (see also Fig. 2).
n=3
partitioning
and
unification
approximation
Fig. 2. Application of the Harmonic Design Method to proto-
cols and communication software development.
249
(Harmonic Step 1 )
(1) Partitioning
Three types of problem-oriented languages
are provided:
(a) NESDEL: protocol-oriented specifica-
tion language,
(b) EXPA: protocol verification method
and its representation form,
(c) IDL: communication software ori-
ented programming lan-
guage.
NESDEL, EXPA and IDL are designed
based on the same concept, i.e., FSM (Finite
State Machine).
(2) Unification
Three types of transformation algorithms
are provided:
(a) NESDEL --, EXPA,
(b) EXPA --, NESDEL,
(c) NESDEL --, IDL.
(Harmonic Step 2)
NESDEL expressions free of such logical
errors as deadlock and unspecified recep-
tion are obtained by using the weak verifi-
cation method EXPA repeatedly.
In order to support the languages and al-
gorithms described above, some tools are needed.
Such tools are introduced in Section 8.
4. NESDEL
The protocol specification language NESDEL
[39] has been designed so that it possesses the
following desirable characteristics:
(a) easy to use and understand, and
(b) no ambiguity (strictness of description).
For the purpose of (a), NESDEL uses a graphical
representation. Such graphical representation is
good for human understanding, especially in the
case of large and complex specifications. For the
purpose of (b), N E S D E L has introduced
program-like representation. A NESDEL specifi-
cation is written using both representation forms.
NESDEL describes a protocol specification in
terms of the protocol machine expressing the be-
havior of the protocol. Here, a protocol machine is
modeled by using a finite-state machine, aug-
mented by the addition of variables and proce-
250 N. Shiratori et aL / A SoftwareDesign Method

Protocol Machine
above

I. start I m
put
I 1 I

I
I'~ stop [ 4- . . . . . . . . . -~
Timer Protocol Machine
~_] Protocol
I timeout I
input ! ~transmit

I Protocol Machine
below

Fig. 3. Environment of protocol machine.

dures. Figure 3 shows the model of the environ-
ment of a protocol machine.
As described above, a NESDEL specification
consists of two parts: a directed graph part and a
primitive part. The directed graph part expresses
the control flow of the protocol. It corresponds to
an ordinary state transition diagram. The primi-
tive part defines symbols such as variables, mes-
sages and operations used in the graph part. A
basic SDL specification [15] contains ambiguous
descriptions as it permits the use of a natural
language expression. (In order to augment basic
SDL vis-a-vis strictness of description and intro-
duction of structuring concept and procedures,
etc., some recommendations have been made [16].)
To avoid ambiguity, primitive expressions are in-
troduced in the NESDEL specification. A primi-
tive expression is a kind of high-level program-
ming language expression. The notable features of
NESDEL are better understandability and avoi-
dance of ambiguity in protocol specifications, by
using directed graph expressions and primitive
expressions at the same time.
In NESDEL, a directed graph part is described
by using four kinds of nodes, arcs and arc labels.
A node may be expressed hierarchically, that is, it
may be expressed by using another NESDEL ex-
pression. An arc, which indicates a transition be-
tween two nodes, is represented using a parent arc
(thick arc) and a child arc (thin arc) connected to
the parent arc. An operation, which indicates the
transmission or reception of an event, is associ-
ated with a parent arc, and the name of the
corresponding event is associated with the child
arc. A predicate may be associated with a parent
arc or a child arc. If a node has two or more arcs,
an arc whose predicate is interpreted as "true" is
chosen for execution. On the other hand, the
primitive part gives the details of a specification
by supplementing its corresponding directed graph
part. The name of a protocol machine, the list of
interface events exchanged between the protocol
machine and its environment, the names and time-
out limits of timers, the declaration of variables,
the meaning of variables, events, etc., operations
used for processing and so on are described in the
primitive part.
Now, we outline NESDEL by showing an ex-
ample. Figure 4 shows an example of a NESDEL
specification. It represents the behavior of a pro-
tocol machine (which works with the environment
shown in Fig. 3) implementing the following sim-
ple protocol:
(protocol)
1. The user (i.e., the layer above) requests the
protocol machine to transmit a message.
2. The protocol machine transmits this message
to the peer protocol machine, through the
 N. Shiratori et al. / A Software Design Method 251

protocol-machine (PM)
local messages (USER):
INPUT = {message}
OUTPUT = {success,
failure}
global messages (CHANNEL):
accept INPUT = {aek,nak}

pl• age

transmit
OUTPUT= {message}
timers (timer = 3000)
vat ( r : INTEGER)
meaning
timer : for timeout detection
message start r : retransmission counter
local messages :
message = data message
success = successful
timeout transmission
failure =unsuccessful
/ I input transmission
global messages :
timer ~ _ . ~ n a k ack message = data message
aek = acknowledgement
nak = negative ack.
prim ASSIGN : assignment

transmit put 1 put

proc I
statement
STOP : stop a timer
: initialization
P1 : ASSIGN(r,0)
P2 : STOP(timer)
message / failure success P3 : STOP(timer);
ASSIGN(r,r + 1)

<Directed Graph Part> <Primitive Part>

Fig. 4. An example specificationby NESDEL.

layer below. At this time, a timer is activated
for retransmission.
3. If the protocol machine receives an acknowl-
edgement from the peer protocol machine,
through the layer below, then message
"success" is returned to the user. If a nega-
tive acknowledgement is received or the
retransmission timer goes off, then the mes-
sage is retransmitted. This retransmission is
permitted up to three times. In the case of
the four consecutive occurrences of timeout
or reception of negative acknowledgement,
the protocol machine returns message
"failure" to the user, without retransmitting
the message.
4. Repeats 1-3.
In Fig. 4, the transition arc from node Wt to
node/'1 and its arc labels "accept" and "message"
in the upper part of the directed graph, for
instance, mean that when the protocol machine is
in node Wt, called W-node, the protocol machine
receives message "message" from " t h e protocol
machine above" and then moves on to node P1,
called P-node, for processing. (In NESDEL, a
W-node is used to indicate that the protocol ma-
chine waits for the occurrence of an interface
event). The processing of node "P1" is described
in the procedure definition section, identified with
key word " p r o c " , in the primitive part. In this
example, node "P1" performs " A S S I G N ( r , 0)",
i.e., assignment of the value zero to the integer
variable " r " . In node "W2", the arc labeled with
252 N. Shiratori et al. / A Software Design Method
"start" and "timer" indicates that when entering
this node, timer "timer" is activated once. In this
node, when a timeout happens, the transition to
node "P3" occurs. On the other hand, when an
acknowledgement or negative acknowledgement is
received, the transition to node "P2" or transition
to node "/3 occurs, respectively. The transition
arc from node "P3" to node "WE" and its arc
labels indicate that, after the processing of node
"P3", if the value of the variable " r " is less than
or equal to three, then this transition can take
place and message "message" is transmitted to
" t h e protocol machine below" during this transi-
tion. The interface events exchanged between the
protocol machine and " t h e protocol machine
above" are listed in the local message definition
section, labeled with keyword "local messages", in
the primitive part. Similarly, the interface events
exchanged between the protocol machine and " t h e
protocol machine below" are listed in the global
message definition section, labeled with keyword
"global messages". The meaning of the interface
events, variables, etc. is described as comments in
the meaning description section, labded with
keyword "meaning".
As seen in this example, the specifier can freely
define and use operations to be used in the
description of P-nodes. In NESDEL, such an
operation is called a protocol dependent primitive
and is defined in the protocol dependent primitive
definition section, labeled with keyword "prim",
in the primitive part. On the other hand, oper-
ations (see Fig. 3) such as "accept", " p u t " , "in-
put", "transmit", "start", "stop" and "timeout"
are called common primitives, in the sense that
they can be commonly used for any protocol, and
can be used as labels of arcs in the directed graph
part. The common primitives "accept" and "in-
put" are used to indicate the reception of an
interface event from " t h e protocol machine above"
and " t h e protocol machine below", respectively.
" p u t " and "transmit" are used indicate the trans-
mission of an interface event to " t h e protocol
machine above" and " t h e protocol machine be-
low", respectively. The activation and suspension
of a timer, and the occurrence of a timeout are
indicated by using the common primitives "start",
" s t o p " and "timeout", respectively.
N E S D E L has proved very useful in specifying
existing protocols, e.g., X.25 protocol and H D L C
[39].
5. IDL
IDL [40] is a high-level programming language
for describing communication software. The lan-
guage is based on the concept of a finite-state
machine (FSM for short) with variables and pro-
gram segments. IDL has a concept and syntactic
structure similar to that of ESTELLE [28]. For
example, the language syntax of both languages
are closely related with the finite-state machine.
The main differences between IDL and E S T E L L E
are as follows:
(1) IDL is compact in size, on the other hand,
ESTELLE is large.
(2) IDL supports hierarchical descriptions of
state transitions of a FSM. That is, a transition of
a FSM may be represented by using transitions of
its subordinate FSM (called sub-FSM). This can
be thought of as a kind of subroutine call, and
provides a way of structuring a FSM.
The main features of IDL may be summarized
as follows:
(a) a close relation of the language syntax with
the finite-state model,
(b) high understandability as a consequence of
(a),
(c) possibility of handling a wide variety of
event inputs,
(d) availability of a compiler, and so on.
An IDL description consists of a " F S M -
D A T A - D E C L A R A T I O N " section and a " F S M -
BODY" section (if needed, sub-FSM described
above, procedures and macros are also included.).
The former section declares the various variables
needed for representing message buffers, interface
events, message sequence numbers, and so on. The
latter section describes the behavior or action of
the FSM. This comprises a number of F S M action
units. Here, a FSM action unit represents a state
and the possible transitions originated from the
state. It is described as follows:
STATE state_ name
EVENT event_ expression
ACTION action_ sequence
EVENT event_ expression
ACTION action_ sequence
Here, an event expression represents a condition
which must be satisfied before the action sequence
corresponding to it is executed. Some event
 N. Shiratori et al. / A Software Design Method 253

expressions are illustrated later in this paper. An Figure 5 shows an example of a description. In
action sequence is associated with each transition, Fig. 5, the left-hand side represents a software
in order to describe the processing involved in the specification by a state transition diagram and the
transition. As described above, such an action right-hand side represents the corresponding de-
sequence is enabled when the condition specified scription of the software in IDL. This example
by its corresponding event expression is satisfied demonstrates that given a software specification in
while the FSM is in its corresponding state. In an terms of a state transition diagram, the user can
action sequence, the statement "NEXT-STATE" easily describe a program corresponding to the
is used for indicating the next state of the FSM. In specification, by virtue of the feature (a) men-
order to describe an action sequence, the following tioned above. For example, the transition from
statements can be used: state "INITIAL" to state "WAIT" corresponds to
- "TRANSMIT": outputs an interface the first FSM action unit description part (i.e., six
event, lines from statement "STATE INITIAL" to state-
- "NEXT-STATE": indicates next state or calls a ment "NEXT-STATE WAIT"). Keyword "INI-
sub-FSM, TIAL" represents the initial state of the FSM. As
- " A N Y O and "END": indicates that
R D E R ' ' seen in this example, event expressions have several
the statements enclosed by these keywords kinds of representation forms. For example, event
may be executed in arbitrary order, expression "Q1 * MESSAGE" in the first FSM
- "TIMER": activates a timer, action unit description part indicates that if there
- "CANCEL": suspends a timer activated previ- is at least one event in queue " Q I " while the FSM
ously, is in state "INITIAL", then an event is removed
- others: statements, used in ordinary program- from the head of the queue, the event is assigned
ming languages, such as "IF", "DO", to variable "MESSAGE", and then its corre-
"CALL", assignment, etc. sponding action sequence is executed. In IDL,

FSM TRANSMITTER
FSM-DATA-DECLARATION
EVENT MESSAGE
02 TEXT C(128)
EVENT RESPONSE
02 FILLER BIT(6)
02 ACK BIT(2)
EVENT REPLY
02 FILLER BIT(6)
02 SF BIT(2)
R INT VALUE 0
END-OF-DECLARATION
/ ~tivate ; timer ; FSM-BODY
timer ; Success.
STATE INITIAL
clear R. EVENT QI*MESSAGE

r>y
/
/

failure. ~ ,
/ ACTION

STATE
EVENT
TRANSMIT(Q3*MESSAGE)
TIMER(TIMER,3000)
R:=0
NEXT-STATE WAIT
WAIT
Q4*RESPONSE.ACK = WOO'
ACTION CANCEL(TIMER)
REPLY.SF: = B'00'
Simeon:/ TRANSMIT(Q2*REPLY)
NEXT-STATE INITIAL
increment ~ EVENT TIMEOUT(TIMER)
ACTION R:=R+I
. R. r<3~ IF R>3: REPLY.SF:=B'10'
TRANSMIT(Q2*REPLY)
,~ message ; NEXT-STATE INITIAL i
R~3 : TRANSMIT(Q3*MESSAGE)
aetiZt; TIMER(TIMER,3000)
NEXT-STATE WAIT !
END
END-OF-BODY
Fig. 5. A n example of a description in IDL.
254 N. Shiratori et al. / A Software Design Method
queues are used in order to store interface events
exchanged between a FSM and its environment.
All queues have a first-in-first-out discipline. To
output an event to a queue, the statement
" T R A N S M I T " is used. For example, " T R A N S -
MIT(Q3 * MESSAGE)" in the first FSM action
unit description in Fig. 5 represents that the con-
tents of variable " M E S S A G E " is placed at the tail
of queue " Q 3 " b y its execution. As other exam-
ples of event expressions, " Q 4 * RESPONSE.
ACK=B'00'" in the second FSM action unit
description indicates that if there is at least one
event in queue " Q 4 " while the FSM is in state
" W A I T " and two bits from the seventh bit of an
event at the head of the queue are both zeros, then
the event is removed from the queue, the event is
assigned to variable " R E S P O N S E " , and then its
corresponding action sequence is executed. Simi-
larly, event expression " T I M E O U T ( T I M E R ) " in
the second FSM action unit description indicates
that when timer " T I M E R " causes a timeout, its
corresponding action sequence is executed. A
timeout event is handled as a special event which
does not depend on any queue. We assume that
events pertaining to time are controlled by the
particular mechanism of the system under which
I D L programs are executed. In addition to the
forms of the event expressions mentioned above
through this example description, we have one
more representation form for event expressions.
Event expression " N U L L " is used for describing
an action sequence that does not depend on any
incoming event. It is useful in describing a proce-
dure unconditionally executed.
6. EXPA
EXPA [38] is a protocol validation algorithm
which can be applied to systems composed of two
or more processes communicating with each other.
In EXPA, each process is modeled as a finite-state
machine, and is represented by a set of states, a
set of actions, a state transition function, an initial
state and a set of final states. Here, an action
means the exchange of an event accompanying the
execution of a transition between states. The basic
philosophy of EXPA is to examine all possible
states of a system by defining an initial system
state and a set of final system states. A system
state consists of the states of the processes and the
states of the communication channels between the
processes. West [8] gave an algorithm, based on
the perturbation analysis, which could make a
reachability graph R G of system states. By using
this RG, a designer starts from an initial system
state and traces the whole R G so that he will be
able to detect design errors. EXPA is a generaliza-
tion of the perturbation analysis theory of proto-
col validation which overcomes a number of limi-
tations of the original theory. Validation ability of
EXPA is superior to that of the validation al-
gorithm, based on perturbation analysis, made by
West [8]. For example, E X P A can detect the loca-
tions of critical system states (defined below) which
cause logical errors, as well as occurrences (system
states) of logical errors such as deadlock. The
main idea in the EXPA algorithm is to give a
backward perturbation as well as a forward per-
turbation so that EXPA can overcome the limita-
tions of the original theory. A backward perturba-
tion is a perturbation analysis which starts from a
final system state. By the backward perturbation,
all the systems states can be classified into two
groups, a set of normal system states and a set of
abnormal system states (see Fig. 6). A normal
system state is a system state which is reachable
from an initial system state and has access to a
final system state. An abnormal system state is a
system state which is reachable from an initial
system state and does not have access to a final
system state. A normal system state which has
immediate access to an abnormal system state is
called a critical system state. As a result of the
backward perturbation, EXPA can detect the fol-
lowing logical errors automatically and inform
them to the designer:
(a) state deadlocks,
(b) unspecified receptions,
(c) loops,
(d) buffer overflow (channel overflow),
(e) critical system states,
(f) error transition sequences.
A critical system state indicates a system state
which leads to logical errors in the protocol, for
example, a transition from the critical system state
to an abnormal system state is a protocol error. If
this transition occurs, the system state cannot
reach the set of final system states. By performing
backward perturbation, EXPA can detect the criti-
cal system states which lead to such logical errors
as deadlocks and unspecified receptions. An error
 N. Shiratori et al. / A Software Design Method 255

l ~ initialsystem
state

forward • " I, ) :normal system state

perturbation ." •
." . .* ". : abnormal system
.- ". ~ state
.. -. ( ~ ) : critical system state
.*
**
• --." ";. - -
| Si ) I Sk ]
~_~ normal system states ~_ ¢11."

.. Isjl tsll
- "
backward .. " ".
perturbation .- abnormal "'. " abnormal "..
•* -• ."

•,".::i."
" " system states
....................... G---(D ..... .... ..;-:....
final system states
Fig. 6. Classificationof system states.

transition sequence is a sequence of system states
from a critical system state to a system state
representing a logical error. Incidentally, the num-
ber of system states generated by EXPA is the
same as that generated by the algorithm [8].
The algorithm of EXPA is as follows:
(Step 1)
Find all system states, which are reachable
from the initial system state, by applying the
forward perturbations, and make the reachabil-
ity graph RG. This is the perturbation analysis
given by West [8]. Record the complete infor-
marion of the above perturbations. That is,
build the transition function, say 8, of system
states. For example, system state "$2" in Fig. 8
can reach system states "$3" and "$4" by ac-
tions " + 3" (representing the reception of event
" 3 " ) and " - 1 " (representing the transmission
of event ' T ' ) , respectively. So, we get 8 ( S 2, + 3)
= S 3 and 8 ( S 2 , - 1) = S4. These informations
are used to give the backward perturbation in
Step 2 and Step 3.
(Step 2)
For all system states found in Step 1, obtain the
inverse function, say 8-1, of state transition, by
using the informations of the forward perturba-
tions recorded in Step 1. Given a system state
and an action, the function 8-1 gives the set of
system states which have access to the system
state by the action. For example, system state
" S 7'' in Fig. 8 can be reached from system state
"$6" by action " + 1 " . So, we get 8 - 1 ( $ 7 , + 1)
= (s,).
(Step 3)
Perform the backward perturbation, which is a
perturbation starting from the final system
states by using 8-1 given in Step 2, and classify
the system states into normal system states and
abnormal system states.
(Step 4)
Find the critical system states and then make
the error transition sequences, and report them.
Detect loops in the sets of the normal system
states and the abnormal system states, and
report them. For example, in Fig. 8, system
state "$2" is a critical system state since it is a
normal system state which has immediate access
to abnormal system state "$3".
Next, we give a simple execution example of
EXPA. In this example, we consider a system
consisting of two processes represented in Fig. 7.
In Fig. 7, a circle indicates the state of a process.
A directed arc and its label represent the transi-
tion between two process states and the action
256 N. Shiratori et aL / A S o f t w a r e Design M e t h o d

C
+3 -1 -3

+3 (
+1

< process1 > < process2 >

Fig. 7. Finite state graph representationof processes.

s~, s~o ¢ ~ s~
]~o ~ ' 2 ~ +1 ~ " ~ S l t'--'%
/ ~ 4 ~ E ~,q..~ 1 1 } |" 0 E "1 +3 .....S3
~E 2jg ~%E 2 1 / ~E 0 / N. 3 1 '"""~*'1 ~ ""
" ~ / " v "I ) - - - " - "' : .... . ~5
. j +2 -i J.-3 $4-- • - 1 ".E 1 ""~'&"'2 " ""
s19 g • .,-" "x ..... -2 : " i
]f .~ ($4) | 1 1 "1 ".E 1 ."
! ~ x,~ I ~,%3 1 .," , "'"
" ' . . ~" - 2 " u n s p e c i f i e d ,,
-3 %~ 0 ] 86 ~+3 ~+1~: S reception
#" -V+I .'~ "'. .-" "s~ ~--.~9
(S9) * : E 1 : | 1 E I ( 2 1,2)
~o ~ *" 1 *" "~3 2 ~.," ~_3 1 .
t'°211 "'" " "'" f -- n ~-"~ +1
l + 1 -~. +3 . . _]-+3
~-3 "</)t
$7 "'1" ~ ~.. I~$14
. 2 E °' (814) (87) f o 1,2 ) ~ 2 2 )22
"'~.L-'" \ ~, 1 +2
S15
"deadlock" + 1 ~ ' 1 ~ ~ 3 ~ $ !1 E7
C)
:normal. system state S12 0 22"$1i ~- (-S 1 I)
~.E , -3 816

~ :abnormalsystemstate813_ E 2 " ~+2 ( 1 1,2,1~ (S0) 1 2 E )

:criticalsystemstate 2f2 2.:" (So) ~/~ -2 +3
t, ~+1 ~"Sls
"~'~?'J" (Sl) (812) ( 2 1,2,1,2) (S2)

(819) 1
($13)
Fig. 8. Reachabilitygraph correspondingto Fig. 7.
 N. Shiratori et aL / A Software Design Method
which causes the transition, respectively. The pro-
tocol illustrated in Fig. 7 is given to EXPA as an
input. The information concerning the logical er-
rors is obtained from EXPA as output. For exam-
ple, the reachability graph generated by the execu-
tion of EXPA is shown in Fig. 8. We represent a
system state in the form of matrix, as shown in
Fig. 8. In the matrix form, the top-left element
represents the state of process 1, and the bottom-
right element represents the state of process 2. The
top-right element represents the state of the half-
duplex FIFO (First-In-First-Out) channel from
process 1 to process 2. Similarly, the bottom-left
element represents the state of the half-duplex
FIFO channel from process 2 to process 1. The
special symbol " E " is used for denoting the state
of the empty channel. In this example, we assume
that the initial system state and the final system
state are both "'So", that the capacities of the two
channels are both 5, and that all events are
exchanged perfectly. Then, we obtain the follow-
ing results:
(1) normal system states:
So, sl, s2, s,, &, sg, sl0, s11, s12, &3,
$14, $15, $16, $17, $18, S19, $20, S21;
(2) abnormal system states:
s3, ss, st, s7;
(3) critical system states:
s2, s,, &;
(4) error transition sequences:
(a) s2-" s3-" &,
(b) S, ~ S6-~ ST,
(c) Ss-~ ST;
(5) unspecified reception:
&;
(6) deadlock:
S 7•
7. Transformations Between the Languages
In this section, we describe the algorithms for
performing the transformations between the lan-
guages mentioned in Sections 4, 5 and 6. We
provide three transformation algorithms for trans-
forming
(1) NESDEL expressions into EXPA expres-
sions
(2) EXPA expressions into NESDEL expres-
sions, and
(3) NESDEL expressions into IDL expres-
sions.
257
Transformation algorithm (1) is used for verifying
protocols specified in NESDEL. Transformation
algorithm (2) is used for making the results of the
protocol verification performed in EXPA expres-
sions, which are the output of transformation
algorithm (1), reflect on the original NESDEL
expressions corresponding to the EXPA expres-
sions. Transformation algorithm (3) generates a
IDL program for implementing a protocol speci-
fied in NESDEL.
7.1. Transformation from NESDEL into EXPA
There exist some differences between NESDEL
expressions and EXPA expressions. Thus, a
NESDEL expression has to be transformed into
the corresponding EXPA expression to validate a
protocol specified in NESDEL. Traditional vali-
dation methods based on the perturbation analysis
including EXPA require finite-state transition
graphs without predicates and variables, in order
to represent protocol specifications to be vali-
dated, as inputs to these methods. However, as
described in Section 4, NESDEL expression is
based on a finite-state transition graph with predi-
cates and variables. Therefore, transformations of
NESDEL expressions into EXPA expressions be-
come difficult, so that, until now, the user has
done this transformation using heuristics by him-
self. To overcome this difficulty, we have intro-
duced predicates and variables into EXPA expres-
sions, and have augmented the original EXPA
described in Section 6. Thus, the current version
of EXPA can accept expressions with predicates
and variables as its inputs, and the choice of a
possible transition is determined depending on
not only the transmission or reception of an event
but also the evaluation of a predicate accompany-
ing the transition. By this augmentation, we have
succeeded in building an algorithm for the above-
mentioned transformation.
Now, let G be the NESDEL expression input
to this transformation. Then, the NESDEL-to-
EXPA transformation algorithm is characterized
by the following transformation rules:
Algorithm
(Rute/)
Remove the label on each directed arc in G
concerned with the transmission or reception of
258 N. Shiratoriet al. / A SoftwareDesignMethod
an event relating to the layer above. But, retain
these directed arcs.
(Rule 2)
Remove each directed arc concerned with the
activation of a timer or the occurrence of a
timeout.
(Rule 3)
Change each arc label representing the trans-
mission of an event to the layer below into the
form of " - i " where " i " is a non-negative
integer corresponding to the event to be trans-
mitted.
(Rule 4)
Change each arc label representing the recep-
tion of an event from the layer below into the
form of " + i " where " i " is a non-negative
integer corresponding to the event to be
received.
(Rule 5 5
Retain each predicate. Keep informations such
as variables and operations effecting the
evaluation of the predicates.
(Rule 6)
Regard each node in G as a process state in the
corresponding EXPA expression.
? are transformed into the corresponding N E S D E L
Fig. 9. An example of NESDEL-to-EXPAtransformations.
We actually use a depth-first search technique,
that is, we start from the root of G and then apply
the above-mentioned rules to each of directed arcs
and nodes.
For example, the graph representation in Fig. 9
is obtained by applying the NESDEL-to-EXPA
transformation algorithm to the N E S D E L expres-
sion given in Fig. 4.
7.2. Transformation from EXPA into NESDEL
EXPA generates a reachability graph of system
states, and informs the user of logical errors such
as deadlocks, unspecified receptions and buffer
overflows, if any. But, it is not easy for users to
understand them. This is why EXPA expressions
are inferior to N E S D E L expressions in under-
standability. Therefore, in order to improve user
understandability, we would like to obtain the
information about logical errors in a protocol
specification language, e.g., NESDEL.
In the following, we give the EXPA-to-
N E S D E L transformation algorithm. This algo-
rithm consists of two stages: decomposition stage
and transformation stage. In the decomposition
stage, system states and sequences of system states
are decomposed into states of each process which
are components of a system state. In the transfor-
mation stage, outputs of the decomposition stage
expression. Since a N E S D E L expression has been
given as an input to the NESDEL-to-EXPA trans-
formation mentioned above, it is easy to perform
this transformation stage by using the information
related to the transformation from N E S D E L into
EXPA.
An outline of the EXPA-to-NESDEL transfor-
mation algorithm is given as follows:
Algorithm
(I) Decomposition stage
This stage consists of two decomposition
processes.
1. Decomposition of system states
Given a system state S as an input,
(1) find states of each process on the
EXPA expression from S;
(2) find the corresponding states (nodes)
in the N E S D E L expression by using
the transformation informations from
the N E S D E L expression into the
EXPA expression.
 N. Shiratoriet al. / A SoftwareDesign Method 259

2. Decomposition of sequences of system states (II) Transformation stage

Given a sequence S of system states as
an input, let S be $1 ~ "'" ~ Sk where
each Sj (1 ~ j ~ k) is a system state and
S 1 ~ . . . ~ S k represents a sequence of
system states starting from S~ through Sk.
Let A i be a variable taking a sequence of
states concerned with process i as its value.
(1) for all i (1 ~<i ~<k), A i .'= qi where qi
is a state of process i in $1;
(2) repeat the following until j = k - 1,
starting from j = 1:
if Sj ~ Sj+I is caused by a transition of
process i, then A~-'=A i • (q', j ) where
q' is a state of process i in Sj÷ 1 and
" . " means a concatenation of string.
By using the information related to the trans-
formation of NESDEL expressions into
EXPA expressions, this stage is carried out
straightforwardly. For example, given a tran-
sition in the EXPA expression, we can auto-
matically know which transition in the
NESDEL expression corresponds to it.
Figure 10 shows an example of this transforma-
tion. In this figure, i.e. NESDEL expression, state
N4 of process 1 and state N3 of process 2 are
corresponding to "deadlock" state in Fig. 8. Also,
paths leading to a deadlock state are indicated in
each NESDEL expression.

< Process1> < Process 2 >

I
input ~ transmit transmit ~ I input ~
I mess3 ~ mess1
j \
~Pathleadingto~~ m]essl )
[ a deadlock state J I
transmitI ~ut input d, /
~,,, ~ mess2
]/-~.~mess4
messl~ /
mess2me i ~ 3 ~ .
~ input [
//Zut b/ ~ messl
~ mess3

input
mess3 mess4 ~ . ~

(~): EXPA-to-NESDEL
transformation
( ) (~): NESDEL-to-EXPA
transformation
~): verification using
EXPA

Reachability graph (Fig.8)

Fig. 10. An exampleof EXPA-to-NESDELtransformations.
260 N. Shiratoriet al. / A SoftwareDesignMethod
7.3. Transformation from NESDEL into IDL
A NESDEL expression describes a protocol in
terms of, mainly, the logical behavior of the proto-
col. On the other hand, a IDL expression must
contain not only its logical behavior but also the
structure of the data handled by it, queues needed
to input/output events, and so on. Therefore, the
information available from a NESDEL expression
is insufficient to transform it into a IDL expres-
sion, we need auxiliary information, i.e., informa-
tion which cannot be derived from a NESDEL
expression. Such information is mainly concerned
with the primitive part of a NESDEL expression.
The NESDEL-to-IDL transformation algorithm
acquires, keeps and utilizes it as auxiliary informa-
tion for the transformation (hereafter, called
transformation-information). The transformation-
information is sorted into
(a) common-transformation-information and
(b) individual-transformation-information.
Here, (a) contains the transformation-information
which is considered to be useful for the transfor-
mation of any protocol specification and can be
commonly used for the executions of all transfor-
mations; (b) covers the transformation-informa-
tion peculiar to the execution of individual trans-
formation, and is acquired during the execution of
the transformation. In practice, both (a) and (b)
are unified and then utilized for the execution of
the transformation.
Given a NESDEL expression, the following is
the transformation-information necessary for the
transformation:
(1) finite-state machine name,
(2) structure of each message,
(3) name and timeout limit of each timer,
(4) name and type of each variable,
(5) name and expansion form (IDL expression)
of each protocol dependent primitive,
(6) details of each P-node in the NESDEL graph
expression, and
(7) name of each queue.
The first six are concerned with the transforma-
tion of NESDEL's primitive part while the sev-
enth is concerned with the use of queues. We can
regard the above transformation-information as a
kind of knowledge about the transformation. Once
all of the transformation-information (knowledge)
is fixed, the transformation algorithm can trans-
form the given NESDEL expression into a IDL
expression automatically. The acquisition and the
storage of the above knowledge is performed dur-
ing the preprocessing stage of the transformation
algorithm.
In order to acquire, keep and retrieve the trans-
formation-information (knowledge), we use the
concept of a frame [46,47] in AI. The reason
behind the choice of the frame concept is that it
has a suitable structure for representing a stereo-
typed knowledge that just fits our requirement.
However, some features of frames are redundant
in our application, e.g., property-inheritance
among frames, slot filling criteria, etc.
Thus the transformation-information (knowl-
edge) we handle are structured in the following
form;
(frame (slot (facet (vahie)(value)...)
(facet (value)(value)...)
. o .
(slot (facet (vahie)(vahie)...)
. ° .
° . .
We have two frames: "'primitive" and "queue ",
concerned with the transformation of NESDEL's
primitive part and the queues to be used in the
target IDL program, respectively. In the primitive
frame, we have six slots corresponding to the
knowledge-"bit"s (1)-(6), i.e., "'protocol-name';
"'messages" "'timers", "'variables" "'prim" and
"proc". In the queue frame, we have one slot
corresponding to the knowledge-bit (7), i.e.,
"queue" slot. There are three types of facets:
"'rule" "'default" and "'if-needed". The value se-
quence in a rule facet represents "fixed" transfor-
mation-knowledge. In the case of a default facet,
its value sequence represents default (or built-in)
transformation-knowledge. In either case, a value
sequence takes the form (P1 C1)(/}2 C2) ' ' " (Pn Cn)
where (Pi Ci), roughly speaking, represents a rule
indicating that Pi corresponds to Ci (strictly
speaking, it is interpreted depending on the slot it
is contained in). For example, the rule (timer 3000)
in the timer slot represents that the timer named
"timer" has 3000 milliseconds as its timeout limit.
In if-needed facets, the value represents the name
of a procedure. A procedure is activated automati-
cally when a new value (new rule) in the rule facet
is needed.
Figure 11 gives an outline of the NESDEL-to-
IDL transformation algorithm. As shown in this
figure, the transformation algorithm consists of
 N. Shiratori et al. / A Software Design Method 261

Common (1) I
transformation * • • Initialization I~
information

call

Frame
representation
primitive , .. • Primitive Frame manager ,11.• of
I call I transformation
information

NEs.E,
graph "'" ~" I Ii'iTranslation [/call/'

IDL J"
expression
(5)
Finalization

Fig. 11. A n o u t l i n e o f N E S D E L - t o - I D L transformations.

five stages: "Initialization", "Queue", "Primitive",
"Translation" and "Finalization". The functions
of these stages are as follows.
(1) Initialization. This stage generates the frame
representation of the common-transformation-in-
formation, through the frame manager. This infor-
mation becomes the "default" knowledge of the
frames for the transformation.
(2) Queue. This stage finds out the names of
the queues used by the target IDL program,
through the frame manager, and stores them as
"fixed" knowledge in the queue frame.
(3) Primitive. This stage fetches the transfor-
mation-information pertaining to the NESDEL
primitive expression, through the frame manager,
and stores them as "fixed" knowledge in the
primitive frame.
(4) Translation. This stage generates the target
IDL program by using the NESDEL directed
graph expression and the transformation-informa-
tion about primitives and queues. The task of this
stage is relatively easy since NESDEL and IDL
are both based on the same concept, i.e., FSM.
(5) Finalization. This stage prints the derived
IDL expression, if needed.
A real example, using this algorithm, is shown
in Fig. 12. This example (i.e., a IDL program) was
obtained by applying the NESDEL-to-IDL trans-
lator described in the next section to the NESDEL
expression corresponding to Fig. 4 which has been
produced by using the intelligent NESDEL editor
described in the next section.
8. Supporting Tools
We have been developed a number of software
tools used for supporting the above-mentioned
languages and the transformation between those
languages. In this section, these tools are intro-
duced. The relationship between these tools is
illustrated in Fig. 13.
8.1. The Intelligent NESDEL Editor
As stated in Section 4, a NESDEL specification
comprises a primitive part and a directed graph
262 N. Shiratori et al. / A Software Design Method

FSM-PH (1) Edit. In order to create and modify a

FSM~DATA-DECLARATION
EVENT MESSAGE NESDEL expression, this editor offers the user
02 TEXT E(128) various commands, e.g., "make", "erase", "re-
EVENT REPLY
02 FILLER BIT(6) place", "move", "copy", "scroll", etc. However,
02 SF BIT(2) these commands are divided into three groups,
EVENT RESPONSE
02 FILLER BIT(6) viz., group 1 for beginners, group 2 for mid-
02 ACKNAK BIT(2)
R INT
dlebrows and group 3 for experts, according to the
END-OF-DECLARATION user's level. A command which is easy and simple
FSN-BODY
STATE I N I T I A L
to use belongs to group 1 while a command which
EVENT NULL is difficult and complex to use belongs to group 3.
ACTION N E X T - S T A T E AUX01
STATE AUX01 Note that group i contains all commands belong-
EVENT NULL ing to group j where i > j. The editor initially asks
ACTION N E X T - S T A T E W1200
STATE W1200 the user to input his level. Thereafter that level
EVENT QI*MESSAGE may be changed automatically depending on the
ACTION R:=O
TRANSMIT(@3tMESSAGE) following factors: (a) the number of times "help"
TIMER(TIMER,3000) is activated, (b) the mean execution time, the user
N E X T - S T A T E W1201
STATE u 1 2 0 1 spent, per command, and (c) the number of oper-
EVENT Q4*RESPONSE.ACKNAK=B'IO' ational error occurrences. The editor manages the
ACTION CANCEL(TIMER)
R:ffiR+I user's level by using a "class variable" which
IF R > 3 : REPLY.SF:=B'IO ' takes, as its value, "beginner", "middle" or "ex-
TRANSMIT(Q2*REPLY)
NEXT-STATE W1200 ! pert".
R <- 3 : TRANSMIT(Q3*MESSAGE) (2) Verification. The verification function con-
TIMER(TIMER,3000)
NEXt-STATE W1201 ! sists of (a) checks for consistency between the
END directed graph expression and the primitive ex-
EVENT QA*RESPONSE.ACKNAK=B'O0'
ACTION CANCEL(TIMER) pression, (b) search for loops (directed cycles) in
REPLY.SF:-B~OO '
TRANSMIT(Q2aREPLY)
the directed graph expression, (c) tracing the di-
N E X T - S T A T E W1200 rected graph expression, and (d) reachability anal-
EVENT TIMEOUT(TINER)
ACTION CANCEL(TIMER)
R:=R+I
IF R > 3 REPLYtSF:=B'IO '
:
TRANSMIT('Q2*REPLY) I Intelligent
NEXT-STATE W1200
R <- 3 : TRANSMIT(Q3*MESSAGE) NESDEL Editor
TIMER(TIMER,3000) NESDEL-to-EXPA
NEXT-STATE U 1 2 0 1 ! translator
/
END
END-OF-BODY protocol specifications EXPA
Fig. 12. An example of NESDEL-to-IDL transformations. Executor
in NESDEL
EXPA-to-NESDEL
translator
NESDEL-to-IDL
( protocol verification )
part. Therefore, its editor should provide not Translator
merely the capability of editing text but also the
capability of editing, graphs. Moreover, it is im- ,L
IDL
portant to present the users with an appropriate
working-environment to edit protocol specifica- programs
tions. Also, the provision of a verification function
plays an important role in checking specifications. IDL
The NESDEL expressions, created by this edi-
tor, are translated into a suitable form and stored Compiler
in files specified by the user.
The editor has three functions: edit, verification
I
existing
and intelligent help. These functions are described programming languages
below. Fig. 13. Supporting tools.
 N. Shiratoriet al. / A SoftwareDesign Method 263

ysis of a graph node.
(3) Intelligent help. In order to make the use of
the editor easy, it provides two kinds of help:
user-request-help (i.e., ordinary help) and system-
spontaneous-help. A user-request-help is activated
by the user while a system-spontaneous-help oc-
curs automatically depending on the following
factors: (a) the user's thinking time, (b) error
occurrence, (c) the value of the class variable and
(d) the complexity of the command. The content
of the help information is decided using the fol-
lowing factors: (a) the current value of the class
variable and (b) the present state of the editor.
A real example, produced by this editor, is
illustrated in Fig. 14. It is a hardcopy of the
display on the TOSHIBA AS3000 color bitmap
display. We have completed the implementation
of the major portions (i.e., the editing function) of
the editor.
8.2. The N E S D E L - t o - E X P A Translator, the E X P A
Executor, and the E X P A - t o - N E S D E L translator
We have been developing three tools, which are
closely related to each other, for verifying proto-
cols written in NESDEL. They are
(1) the NESDEL-to-EXPA translator, which is
used for the transformation of NESDEL expres-
sions into EXPA expressions,
(2) the EXPA executor, by which the EXPA
expressions given as the results of the NESDEL-
to-EXPA translator are verified using the EXPA
verification algorithm described in Section 6, and
(3) the EXPA-to-NESDEL translator, which is

transmit

Mssl 1

tr•it
input

input

~ss2

mssl

(
r

ttlmea~t t

$s4

R0SZ%screenoump ] Ipr -v
Ipr: standard input: copy file is too large
~os1% screendump I / u s r / ] i b / c t o m I lpr -v
I

Fig. 14. A real exampleof NESDELspecificationby the editor.

264 N. Shiratori et aL / A Software Design Method

Sum of e r r o r sequences: 3
Error sequence number to deadlock: 1 - 2
ransmit
Error sequence number to u n s p e c i f i e d reception: 3

m SLssl J ~ ~ s s l
Input sequence number: 1 ~
Input size: 1.5 [ size ) [unexecutable t . . . . . .. . ~ # ~,

~ v2 t
./
41 i.!
:,i:;l
4'
Input

I~ss2 I~Ss4 4 | Nss2

16 i ~ ~ dead]ock 5 j ~ , ~" ] messl

I
/
/
u2 E
\
\

I
1-2
/pi ...i\
I
I
(:
\
E u2
//
\ .... 3 . I / input
tranzmi t

41
~) IImSS4
12 / ~ ~ unspec recep'Lior mess3
/
\ \
/ w2 mess2 \ / v2 messl \
I 3

E ul / \ E ,al /
\ \

\
/ u2 E \
....
I
\ E u2 /
\ /

v2 ,~mess ~ / pl mess1 \ / pl E ~ pl E \

• / \~,ess3 vl / \ E u2 / ~ E ul /

Fig. 15. A real example of the NESDEL-to-EXPA translator,the EXPA executor, and the EXPA-to-NESDEL translator.

used for making the results of the verification and the path from a critical state to a deadlock
performed by the EXPA executor reflect on the state.
original N E S D E L expressions corresponding to
the EXPA expressions. 8.3. The N E S D E L - t o - I D L Translator
The algorithms used for the implementation of
these tools are those described in Sections 6 and 7. In order to generate a IDL program corre-
We have completed the implementation of the sponding to a protocol specification given in
NESDEL-to-EXPA translator, the EXPA execu- N E S D E L semi-automatically, we have developed
tor, and the EXPA-to-NESDEL translator. A real the NESDEL-to-IDL translator. This translator
example, produced by these three tools, is demon- consists of six software modules each of which
strated in Fig. 15. It is a hard-copy of the display corresponds to a rectangle shown in Fig. 11. The
on the TOSHIBA AS3000 color bitmap display. functions of all the software modules except the
In the Fig. 15, the right upper part represents frame manager have been described in Section 7.3.
validation results of N E S D E L expression and the The frame manager manages the frames, and car-
right lower part shows validation results of EXPA ries out such functions as the acquisition, storage
expression. Also, the left lower part shows proto- and retrieval of the transformation knowledge de-
col errors, i.e., deadlock and unspecified reception, scribed in Section 7.3. Among other things, if
 N. Shiratori et al. / A Software Design Method
"default" transformation knowledge is useless, the
process of the knowledge acquisition is performed
interactively between the user and the translator.
For example, the procedure attached to a slot has
been designed so that, in its execution, "fixed"
transformation knowledge is acquired interac-
tively.
A real example, produced by this translator, is
illustrated in Fig. 12. IDL expression in Fig. 12 is
corresponding to NESDEL expression in Fig. 4.
8.4. The I D L Compiler
We have designed two compilers for translating
IDL programs:
(1) IDL programs ~ assembly language pro-
grams, and
(2) IDL programs ~ C language programs.
The development of the former compiler has been
completed while the latter complier is scheduled
for development. In the following, we summarize
main features of the former compiler. The IDL
compiler needs to incorporate the structure of
state transitions and the decision of the incoming
events happening at each state described in the
IDL program into the control structure of the
object code. With respect to the control of the
state transitions, the IDL compiler first sets the
entry point of the object code at the initial state of
the IDL program, and then generates "goto"
statements at the "NEXT-STATE" statements of
the IDL program. For incoming events, the IDL
compiler generates the decision sequence to check
whether the described event expressions are satis-
fied, along with the corresponding action se-
quences which will be executed when the event
expression is satisfied. In order to make access to
queues and timers possible, the IDL compiler
generates "call" statements, in the object code,
which call the library programs prepared in ad-
vance for access to them.
9. Conclusion
In this paper, we have proposed an approach,
called Harmonic Design Method, to achieve ap-
proximately an ideal language that simultaneously
satisfies different purposes or requirements such
as software specification, verification and imple-
mentation. The Harmonic Design Method is based
265
on two important concepts - partitioning and
unification, and the collection of the problem-ori-
ented languages and the transformation al-
gorithms provided as a result of the partitioning
and unification is regarded as an approximation
to the target ideal language.
As an application of the Harmonic Design
Method, we have described the design of a sup-
port system for computer communication proto-
cols and communication software development. In
the design of this support system, we have pro-
vided three problem-oriented languages, i.e.,
NESDEL, IDL and EXPA, and three transforma-
tion algorithms between them, i.e., NESDEL-to-
IDL, NESDEL-to-EXPA and EXPA-to-NESDEL.
The protocol specification language NESDEL has
proved very useful in specifying real-world proto-
cols, e.g., X.25 and HDLC. The communication
software oriented programming language IDL has
been used successfully in the description and im-
plementation of HDLC. We are now studying the
incorporation of abstract data types [48,50] into
NESDEL and IDL. EXPA gives an expression
form for representing a protocol and a technique
for analyzing the protocol. The three transforma-
tion algorithms are used for uniting these lan-
guages.
Given a protocol specification in NESDEL, its
verification and implementation can be semi-
mechanically performed with the assistance of the
supporting tools described in Section 8. Conse-
quently, it is expected that the development cost
of protocol and communication software is re-
duced.
References
[1] T.P. Blumer and D.P. Sidhu, Mechanical Verification and
Automatic Implementation of Communication Protocols,
IEEE Transactions on Software Engineering 12 (8) (1986)
827-843.
[2] T.P. Blumer and R.L. Tenney, A Formal Specification
Technique and Implementation Method for Protocols,
Computer Networks 6 (1982) 201-217.
[3] G. v. Bochmann, G.W. Gerber and J.M. Serre, Semiauto-
matic Implementation of Communication Protocols, IEEE
Transactions on Software Engineering 13 (8) (1987).
989-1000.
[4] S. Aggarwal, D. Barbara and K.Z. Meth, SPANNER: A
Tool for the Specification, Analysis, and Evaluation of
Protocols, IEEE Transactions on Software Engineering 13
(12) (1987) 1218-1237.
266 N. Shiratori et al. / A Software Design Method
[51 D.P. Sidhu and C.S. Crall, Executable Logic Specifica-
tions for Protocol Service Interfaces, I E E E Transactions
on Software Engineering I 4 (1) (1988) 98-121.
[6] D.P. Sidhu and T.P. Blumer, Verification of NBS Class 4
Transport Protocol, I E E E Transactions on Communica-
tions 34 (8) (1986) 781-789.
[7] J. Rubin and C.H. West, An Improved Protocol Valida-
tion Technique, Computer Networks 6 (1982) 65-73.
[8] C.H. West, General Technique for Communications Pro-
tocol Validation, I B M Journal on Research Development
22 (4) (1978) 393-404.
[9] M.G. Gouda and Y.T. Yu, Protocol Validation by Maxi-
mal Progress state Exploration, I E E E Transactions on
Communications 32 (1) (1984) 94-97.
[10] C.H. West, A Validation of the OSI Session Layer Pro-
toeol, Computer Networks and I S D N Systems 11 (1986)
173-182.
[11] F.D. Smith and C.H. West, Technologies for Network
Architecture and Implementation, I B M Journal on Re-
search and Development 27 (1) (1983) 68-78.
[12] D.P. Pozefsky and F.D. Smith, A Meta-Implementation
for Systems Network Architecture, I E E E Transactions on
Communications 30 (6) (1982) 1348-1355.
[13] G.D. Schultz, D.B. Rose, C.H. West and J.P. Gray, Ex-
ecutable Description and Validation of SNA, I E E E
Transactions on Communications 28 (4) (1980) 661-667.
[14] IBM, Systems Network Architecture Format and Protocol
Reference Manual: Architecture Logic, IBM Form No.
SC30-3112-2, 1980.
[15] A. Rockstrom and R. Saracco, SDL--CCIT Specification
and Description Language, I E E E Transactions on Com-
munications 30 (6) (1982) 1310-1317.
[16] CCITT, Functional Specification and Description Lan-
guage (SDL), CCITT Recommendations Z.100-Z.104,
1984.
[17] G.J. Dickson and P.E. Chazal, Status of CCITT Descrip-
tion Techniques and Application to Protocol Specifica-
tion, Proceedings of the I E E E 71 (12) (1983) 1346-1355.
[18] S.A. Dart, P.A. Kirton and N.Q. Duc, Use of CCITT
Specification and Description Language (SDL) as a For-
real Description Technique for Open Systems Intercon-
nection Specifications, ISO/TC97/SC16, Technical Note,
OSI-81-9, 1981.
[19] G.J. Dickson, Formal Description of Data Communica-
dons Protocols Using the Specification and Description
Language, Research Laboratories Report 7390, Telecom
Australia, 1980.
[20] T. Higashino et al., An Algebraic Specification of HDLC
Procedures and Its Verification, I E E E Transactions on
Software Engineering 10 (6) (1984) 825-836.
[21] B. Hailpern, A Simple Protocol Whose Proof Isn't, I E E E
Transactions on Communications 33 (4) (1985) 330-337.
[22] B.T. Hailpern and S.S. Owicki, Modular Verification of
Computer Communication Protocols, 1EEE Transactions
on Communications 31 (1) (1983) 56-68.
[23] B. Chen and R.T. Yeh, Formal Specification and Verifica-
tion of Distributed Systems, I E E E Transactions on Soft-
ware Engineering 9 (6) (1983) 710-722.
[24] S.S. Lain and A.U. Shankar, Protocol Verification via
Projections, I E E E Transactions on Software Engineering
10 (4) (1984) 325-342.
[25] C.A. Sunshine et al., Specification and Verification of
Communication Protocols in AFFIRM Using State
Transition Models, I E E E Transactions on Software En-
gineering 8 (5) (1982) 460-489.
[26] G.V. Bochmann et al., Experience with Formal Specifica-
tions Using an Extended State Transition Model, I E E E
Transactions on Communications 30 (12) (1982) 2506-2513.
[27] A. Danthine, Protocol Representation with Finite-State
Models, I E E E Transactions on Communications 28 (4)
(1980) 632-642.
[28] ISO, ESTELLE--A Formal DesCription Technique Based
on an Extended State Transition Model, ISO/DIS 9074,
1987.
[29] R.L. Schwartz and P.M. Melliar-Smith, From State Mac-
hines to Temporal Logic: Specification Methods for Pro-
tocol Standards, I E E E Transactions on Communications
30 (12) (1982) 2486-2496.
[30] ISO, LOTOS--A Formal Description Technique Based
on the Temporal Ordering of Observational Behavior,
ISO/DIS 8807, 1987.
[31] H. Zimmermann, OSI Reference Model--The ISO Model
of Architecture for Open Systems Interconnection, I E E E
Transactions on Communications 28 (4) (1980) 425-432.
[32] C.A. Vissers, R.L. Tenney and G.V. Bochmann, Formal
Description Techniques, Proceedings of the I E E E 71 (12)
(1983) 1356-1364.
[33] A.S. Tanenbaum, Network Protocols, A C M Computing
Surveys 13 (4) (1981) 453-489.
[34] Proc. 7th I F I P International Workshop on Protocol Specifi-
cation, Testing and Verification (1987).
[35] Proc. 6th I F I P International Workshop on Protocol Specifi-
cation, Testing and Verification (1986).
[36] N. Shiratori, J. Gohara and S. Noguchi, A New Design
Language for Communication Protocols and a Systematic
Design Method of Communication Systems, Proc. 6th
International Conference on Software Engineering (1982)
403-412.
[37] N. Shiratori, K. Takahashi and S. Noguchi, IDESS/85:
Intelligent Support System for Protocols and Communica-
tion Software Development, Proc. 8th International Con-
ference on Computer Communication (1986) 543-548.
[38] N. Shiratori, J. Gohara and S. Noguchi, EXPA: Valida-
tion Method of a Communication Protocol Based on the
Perturbation Analysis (in Japanese), Transactions of I P S
of Japan 26 (3) (1985) 446-453.
[39] N. Shiratori, K. Takahashi and S. Nognchi, NESDEL:
Protocol Oriented Specification and Description Lan-
guage and Its Apphcation (in Japanese), Transactions of
I P S of Japan 26 (6) (1985) 1136-1144.
[40] K. Takahashi, N. Shiratori and S. Nognchi, Communica-
tion Software Oriented Very High-Level Programming
Language IDL and Its Application (in Japanese), Journal
d r i P S of Japan 26 (11) (1985) 1378-1387.
[41] K. Takahashi, K. Kurosawa, N. Shiratori and S. Noguchi,
IDESS/85: Intelligent Support System for Protocols and
Communication Software Development (1)--Intelligent
Editor of Protocol Specification Language, Papers of
Technical Group, SE85-94, IECE Japan, 1985.
[42] K. Takahashi, N. Shiratori and S. Noguchi, IDESS/85:
Intelligent Support System for Protocols and Communica-
tion Software Development (2)ITranslation from Proto-
 N. Shiratori et al. / A Software Design Method
col Specificationinto Software, Papers of Technical Group,
SE85-95, IECE Japan, 1985.
[43] D. Brand and P. Zafiropuro, On Communicating Finite-
State Machines, Journal of the A C M 30 (2) (1983)
323-342.
[44] P. Zafiropuro et al., Towards Analyzing and Synthesizing
Protocols, IEEE Transactions on Communications 28 (4)
(1980) 651-660.
[45] M.G. Gouda and Y. Yu, Synthesis of Communicating
Finite-State Machines with Guaranteed Progress, IEEE
Transactions on Communications 32 (7) (1984) 779-788.
[46] P.H. Winston, Artificial Intelligence (Addison-Wesley,
Reading, MA, 1977).
[47] P.H. Winston and B.K.P. Horn, LISP (Addison-Wesley,
Reading, MA, 1981).
267
[48] B. Liskov et al., Abstraction Mechanisms in CLU, Com-
munications of the A C M 20 (8) (1977) 564-576.
[49] N. Wirth, Program Development by Stepwise Refinement,
Communications of the A C M 14 (4) (1971) 221-227.
[50] J.V. Guttag, E. Horowitz and D.R. Musser, Abstract Data
Types and Software Validation, Communications of the
A C M 21 (12) (1978) 1048-1064.
[51] P.B. Hansen, Distributed Processes: A Concurrent Pro-
gramming Concept, Communications of the ACM 21 (11)
(1978) 934-941.
[52] C.A.R. Hoare, Communicating Sequential Processes,
Communications of the A C M 21 (8) (1978) 666-677.
[53] S. Rotenstreich and W.E. Howden, Two-Dimensional Pro-
gram Design, IEEE Transactions on Software Engineering
12 (3) (1986) 377-384.