An experience in using EDT to process the ISO transaction processing estelle specification

An Experience in Using EDT to Process the IS0 Transaction Processing Estelle Specification R. Lai School of Computer

One

of the

Formal and

hindrances

Description

Transaction dard Estelle with

published

that

has

about

8000

lines

1990

tool that

ment.

This

article

Estelle

generate Estelle some cesses formal ways

of protocol

having

help

specifications.

With

this

industrial fication Science

article

the

uses

lessons

development.

to

TP DIS

developers

with

and

suc-

standardized

tool. One of the of

FDTs

of standardized learned

from

formal

0 1997

is by formal

to encourage

uses of FDTs and standardized for protocol

the

of an IS0

attempts

in using

difficulties

the

develop-

to compile,

to simulate

on uses

also

is a com-

experience

a computer

with

specifica-

there

(EDT)

potential

using

reports

work,

the

and

industrialize

more

even

formal

unless

development

specification to

and

was big in size

It aims to provide

to the

first

However,

Toolset

from,

specification. pointers

the

in LOTOS

its use for protocol

describes

The Stan-

probably

both

specification

is limited

Development C codes

was

standardized

supports

nonavailability

of protocol. International

of codes.

of this

its usefulness

puter

is the

specified

by ISO. The Estelle

availability

tion,

in

been

uses of

in the computer

specification (TP) Draft

Engineering,

of the

(FDTs)

industries

formal

Processing

(DIS)

protocol

the

to the adoption

Techniques

communications

of standardized

the

Science and Computer

by

this wider speci-

Elsevier

Inc.

1. INTRODUCTION Many protocols have been successfully used in the field, but almost all have suffered from unexpected failures, such as deadlocks and livelocks. This is often due to the facts that protocol specifications written in natural languages cannot be verified for correctness and are ambiguous. Any error contained in a standard can be extremely costly when used for industrial purposes. These are some of the reasons that prompted IS0 to develop FDTs in the mid1980’s. The objectives of IS0 in developing FDTs Address correspondence to R. Lai, School of Computer Science and Computer Engineering, La Trobe Uniuersi& Victoria, Australia 3083.

J. SYSTEMS SOFTWARE 1997; 36:137-145 0 1997 by Elsevier Science Inc. 655 Avenue of the Americas. New York, NY 10010

La Trobe Uniuersity, Victoria, Australia

were: to enable specification to be unambiguously written, to enable specification to be analyzed, to act as a guide to the implementer, and to act as a sound basis for conformance testing (ISO, 19861. Estelle (ISO, 1989b; Budkowski and Dembinski, 1987) and LOTOS (ISO, 1989a; Bolognesi and Brinksma, 1987) are the two FDTs standardized by IS0 at tht: end of 1989. Once a protocol has been formally specified in an FDT, the protocol can be verified for correctness and against maloperation and simulated for experimental purposes. Since the introduction of FDTs, work has been conducted on how an informal specification (natural language) of a protocol can be formally specified using an FDT (Bearman et al., 1984; Lai et al., 19891, how a formal specification can be verified (Lai, 1990; West, 1986) and how test cases can be generated from a formal specification (Lee and Lee, 1991; Miller and Paul, 1990). Despite these, the adoption of the uses of formal method in developing communication protocols has not gained wide support from industrial organizations. Some of the hindrances to its adoption are the lack of education in this area, resistance to changes, difficulty to re-invest, and being too academic (Lai and Leung, 1995). In fact, there is another reason for it: standardized formal specification is not readily available. Writing a formal specification for a protocol is very time-consuming and labor intensive. Protocol developers are not very keen to do this type of work. However, a specification written in an FDT is the starting point for a protocol development using formal method. In the past, IS0 protocols were only specified in natural language. To encourage developers to use FDTs, standardized formal specification produced by IS0 begins to appear. The TP DIS published in 1990 was probably the first protocol that has been specified both in LOTOS and Estelle by ISO. This certainly helps developers make better uses of FDTs.

0164.1212/9’7/$17.00 SSDI 0164-1212(9S)oOlY8-0

138

R. Lai

J. SYSTEMS SOFIWARE 1997; 36:137-145

However, even with this availability, its usefulness is limited unless there is a computer tool to support its use for protocol development. To further this type of work, there are other questions that need to be answered. Is there a proven computer tool available for supporting its development? The TP formal specifications are huge; for instance, the Estelle specification contains about 8000 lines of codes. How difficult is it to process the TP Estelle specification? What can you do with it? How easy is it to compile this specification using an Estelle compiler? Is this standardized formal specification correct and complete? How could it facilitate protocol development like implementation and simulation? Traditionally, a protocol is developed using natural language and state-table specifications of a standard (Bochmann and Joochim, 1979). This article describes the experience in using EDT to compile, to generate C codes from, and to simulate the TP Estelle specification so that those questions just raised can be answered. EDT (Budkowski, 1992) checks an Estelle specification for static errors and translates it (if no error is present) into the Intermediate Form (IF) and then into the C language source code. EDT uses the IF for protocol simulation. This article also aims to provide developers with some pointers to the potential difficulties and successes of protocol development of an IS0 standardized formal specification using a computer tool. It was pointed out that one of the ways to help industrialize the uses of FDTs is by having more reports on the uses of FDTs and standardizied formal specifications (Lai and Leung, 1995). With the lessons learned from this work, it attempts to encourage wider industrial uses of standardized formal specification for protocol development.

2. TRANSACTION

PROCESSING

The IS0 TP standard (ISO, 1990) is to provide communication support for transaction type of interactions involving multiple open systems. A number of core terms and definitions are required to fully understand the concept of TP. In the TP standard, a transaction is a unit of work characterized by the ACID properties: Atomic&y-either none is;

all operations are performed

Consistency-all operations are performed rately, correctly and with validity;

or

accu-

Isolation-partial results are not accessible outside a transaction, which prevents other processes

from accessing data that may be changed during the transaction; and . Durability-results

of a completed unit of work are not altered by any sort of failure.

Within each open system, a part of a transaction is performed by an entity called Transaction Processing Service User (TPSU). The remainder of the transaction is performed by a Transaction Processing Service Provider (TPSP), which is an entity that provides the services defined in the standard. A TPSU Invocation (TPSUI) is a particular instance of a TPSU performing function for a specific occasion of information processing. Different TPSUs which cooperate to process a distributed transaction are organized in a hierarchical structure called Distributed Transaction Processing Tree (DTPT). A DTPT originally consists of a single TPSU called the root TPSU. Any TPSU may activate remote TPSUs to execute parts of a respective distributed transaction action. Functional groupings are logical groupings of related elements of procedures defined in the standard. There are six functional units for the TP model: Kernel, Shared control, Polarized control, Handshake, Commit, and Unchained transactions.

3. ESTELLE Estelle (ISO, 1989b; Budkowski and Dembinski, 1987) is a FDT developed by IS0 and based on an extended state transition model. Estelle has benefited from the experience gained from experiments in using its predecessors, and it also reflects collaboration with CCITT, which defined SDL with which Estelle has some notions in common. Estelle models a system using communicating automata which may run in parallel and may communicate by exchanging messages and by sharing some variables in a restricted way. With Estelle, a protocol system is specified as a hierarchically structured system of nondeterministic sequential components (instances of modules) which interchange messages (called interactions) through bidirectional links between their ports (called interaction points). Both the hierarchy of modules and the structure of links may change over time, thereby making the system a dynamic one. Estelle also permits a clear separation of the description of the communication interface between components of a specified system from the description of the internal behavior of such a component. As Estelle is a Pascal-based language, all objects manipulated in Estelle are strongly typed (because

The Estelle Specification

J. SYSTEMS SOFTWARE 1997: 36:137- 145

139

all objects in Pascal are strongly typed), allowing static detection of specification inconsistencies.

4. EDT EDT (Budkowski, 1992) is a set of tools initially developed by Bull S.A. and further extended by Institut National des Telecommunications, France. The tools allow development of reliable implementation of distributed systems specified in Estelle. The EDT set of tools consists of: an Estelle Compiler (EC): It checks an Estelle specification for static errors and translate it (if no error is present) into the Intermediate Form (IF) and then into the C language source code (the Estelle Compiler is in fact composed of two tools: a Translator and a C-code Generator). To compile successfully, a specification needs to be complete, i.e., all occurrences of undefined elements (external functions, procedures or modules) need to be replaced by complete definitions. an Estelle Similator/Debugger (Edb): allows simulation of Estelle specifications with respect to dynamic errors. Edb simulation is based on the IF codes and can only be successful after a clean EC Estelle compilation has been obtained. a Universal Test Drivers Generator (Utdg): permits automatic generation of test suites for Estelle specifications.

J. TP ESTELLE

SPECIFICATION

The specification is divided into several sections. Each of these is put in a file. The “#include” statement is used for putting the specification together. Module headers are put into different files. The specification itself is attributed to systemprocess as it describes the TP communication system. The global declarations are put in a file which includes type, variable, and constant declarations. The main module (i.e., systemprocess) uses “#include” statements to include the files containing descriptions of channels and the files containing module headers and body. All the modules described in the specifications are attributed to process (except the main module). The Estelle codes structure for a TPPM is shown Figure 1. The header for the main module consists of “#include” statements for type declarations, channel declarations, ACSE description, module header, module bodies, and the TP specification. Most of the module body declarations do not contain a transi-

Figure 1.

Structure of the TP Estelle Specification.

tion part; instead, files containing transitions are included using the “#include” directive. If a transition part is not very big, it is included in the module body. Different body definitions are used for describing different combinations of functional units. For example, TPl defines the TP ASE body for the Kernel and Polarized Control functional units; while TP2 describes the TP ASE body for the Kernel and Shared Control functional units. Transitions are put in different sections similar to the module body declarations. For some modules, the transition part is very small; but for others, it is rather big. Some of the module bodies contain external and primitive functions and procedures. There are no primitive or external modules defined in this Estelle specification, and all the modules have attributes. The external functions/procedures are functions/procedures that are incomplete (i.e., to be defined later during refinement of the specification), whereas, primitive functions/procedures are predefined (i.e., defined outside the specification). Not all the variables have been previously declared, but some are to be declared at a later stage. Some of these variables do not play major roles in the specification and can be assigned any dummy values. The overall structure of the specification is very compact and easy to follow. However, when it was required to put the specification together (i.e., not using the “#include” statement) the task became complicated. This complication was due more to the module nesting required by Estelle rather than the structure of the specification itself.

140

6. COMPILATION

USING

EC

To compile the TP specification, it was required to transfer the specification from the IS0 standard 10026-3 to the computer. This was done both by scanning and typing. The specification was then put in different files since “#include” statements were used in the specification. Once these were done, the translator option -I(&) was used to compile the specification. However, due to unknown reasons, this method was not successful. The specification was required to be put together by omitting the “#include” statements. This was an enormous task due to the size of the specification as well as the complexity of the substructures of the modules. Once the specification was put together, the “-t-m” options were used to compile it. Due to the enormous size of the specification (about 8000 lines), the initial number of syntactical errors was huge; and the errors consisted mainly of warnings, undeclared identifiers, unexpected identifiers, and unexpected actual parameter. The “ -m” option provided a listing of the specification with its errors. Most of the undeclared identifiers and warnings were easy to correct by comparing the standardized specification with the one in the computer. The complicated substructuring of the modules were responsible for most of the errors, and due to the size of the specification, it took a fairly long time to correct. Some of the errors were harder to correct than others because it wasn’t always possible to compare with the standardized specification (due to the inability to use the “#include” statement). Other than the errors produced by transferring the specification to the computer, there was only one syntax error in the specification. The error was of type “actual parameter expected” for one of the variables. This was easily corrected because the variable was used correctly on another occasion.

6.1 Restrictions The translator compiles Estelle specification as defined in the IS0 9274 standard. However, due to some technical reasons, minor restrictions are placed on such an Estelle specification. Some of the restrictions are due to machine-dependent limitations, but other were introduced by the C-code generator to ensure a coherent processing of the Intermediate Form. The restrictions are as follows: l

R. Lai

J. SYSTEMS SOFl’WARE 1997; 36:137-145

Primitive functions and procedures are only allowed to be declared at the global level, i.e., within the declaration part of the specification. If this is not followed, the compiler does not recognize the

procedure/function at any level and will provide the error message “undeclared identifier”. The function itself is also not recognized. This is a way of deferring specification or leaving implementation details to implementors. Integer value used in a specification has a limit on its size, mainly due to machine limitations (the limit is from -2147483648 to 2147483647). Integer values used in this specification did not exceed the limit imposed. The length of character items (identifiers, strings, etc.) is limited as well; however, the exact limitation is not known. So far, strings with up to 1024 characters have been tested and are supported by the translator. Similarly, the TP specification did not have any problem with the size of the strings used. All elements of (type) within a “set of (type)” definition must have their ordinal numbers in the closed interval from 0 to 255; for example, if the “set of (a, b, c)” is used, then all three numbers ord(a), ord(b), and ord(c) (where “ord” is a Pascal function) must be in this interval. Each constant C appearing in a set value “[. . C . . I” must have its ordinal number (ord(C)) in the closed interval 0 to 255. The TP specification did not have this problem. Each “stateset” must be defined in such a way that all its state elements belong to the first 255 state identifiers defined for the current body. For instance, if the state-definition is “state sl, . . . , ~255, “, then the stateset-definitions-stateset A lEI87.. ~2051 and stateset B = [sl . . s255]are both admissible, and the state definitionsstateset C = [sl . . ~2561, stateset D = [s250.. sn], and stateset[s255.. s256]-are not acceptable. A “timescale” is required if a “delay” transition is used. An example of this can be seen in the main declaration of the TP specification: SPECIFICATION tpspec SYSTEMPROCESS DEFAULT individual queue; TIMESCALE seconds; STATE idle, creating; A default “queue discipline” is required at the specification level. A declaration of a default queue is shown in the example above. 6.2 Deviations Besides the above restrictions placed on an Estelle specification, the translator also has deviations from the standard Pascal compiler. The purpose of having

The Estelle Specification such deviations is to provide more flexibility during analysis and/or code generation, The deviations are as follows: . Comments

are processed and not, as usual, ignored. These are comments starting with a dollar sign as their first significant character. Such special comments are called qualifying comments. These qualifying comments provide a possibility to insert transparent directives in an Estelle specification for analysis and/or code generation. A qualifying comment list is a sequence of one or more qualifying comments, separated by no other text than regular comments. Occurrence of a qualifying comment list is only allowed in the following three cases: 6) immediately before an identifier, if the occurrence of this identifier is its defining point; (ii) immediately before an imperative statement, even it is an empty statement; and (iii) immediately before an expression.

There is one major difference between the translator and a standard Pascal compiler. It does not recognize as erroneous a declaration of an object that has been previously used in the same scope. For example, the codes below are incorrect according to standard Pascal (Estelle), because the symbol “t0” has been used previously, but this would not be recognized as such by the translator. type t0 = integer; procedure p; type tl = ttl; t0 = char; begin.. . end; l

J. SYSTEMS SOFIWARE 1997; 36:337-145

141

dress of the buffer where the input interaction parameters are stored. There are a few restrictions placed on Estelle by the C-code generator and they are as follows: A transition declaration including a delay-clause, a priority-clause, or an any-clause is not allowed. This restriction only applies to the generator and not to the translator. The TP specification did not use any of these clauses and hence was not affected. Integer cannot be used as an index type. For example, the use of the type “array[integer] of T” is not allowed. Again, the TP specification did not use integer as an index type. External functions and procedures are not allowed. While these external functions and procedures are accepted by the translator, the C-code generator produces the error message “undeclared identifier”.

8. ESTELLE SPECIFICATION

MODIFICATIONS

The TP Estelle specification is divided into six different sections and they all work independently of each other. Some modifications to part of the specification were required, due to the incompleteness of the TP specification. One of the requirements of using Edb successfully for an Estelle specification is that the specification needs to be complete. In the TP specification, there were some incomplete type definitions, as well as 2.5 external functions. It will take up too much space to describe all the modifications (i.e., addition and deletion) made to the type definitions and all the external functions. Instead, only the modifications made to the type definitions and one function are described in this article.

7. C-CODE GENERATION The Estelle-to-C generator is part of the EC compiler. The purpose of the C-Code generator is to preparc the executable form of an Estelle specification which can then be simulated and executed. For each element of an Estelle specification, the C-code generator generates a specific block of codes for it. For instance, each transition block in the specification is converted into a C function with the name _fn_t(i>, where (i) is the number of the transition. The number of parameters required by the predefined function depends on the type of the transition. If the transition is spontaneous, the only parameter is the reference to the module instance context. If, however, the transition has a when-clause, the function requires one more parameter, the ad-

8.1 Variable Declarations There are six incomplete variable declarations in the specification: abort-user-data

= ...;

reject-user-data

= ...;

qos_type

= . . .;

init_type

= .

bit-string

;

= ...;

TBD = . . . ; {To Be Determined) First, it was necessary to determine the roles these type definitions played in the specification, i.e., where and how they were being used. The type definitions

142

R. Lai

J. SYSTEMS SOFTWARE 1997; 36:137-145

for qos_type, hit-type and TBD were used only in record declarations of primitive types. For simulation, only primitive type is important, and the content of a record is not needed to be declared until implementation. The content of the record is not relevant for simulation purposes. Hence, record declarations are commented out as well as the type definitions for TBD, init_type and qos -type. However, the variables bit _ string, abort-user-data, and reject -user-data were used at many different occasions; it was necessary to declare them fully.

begin if (peer_ association -exists) status = idle) then Association-Exists

:= true

else Association-Exists

:= false;

end; In the function, if the value of peer-associationexists is true and the value of association-status is idle, the function returns true; otherwise, it returns false. 9. SIMULATIONS

8.2 External

Functions

There are 25 external functions defined in the TP specification. Nearly all the functions have been given a very brief description, making it rather hard to define them fully. However, by introducing new variables (which was necessary for some functions), the definitions for these functions have been improved. At first, it was decided to define external functions as dummy functions which were given any random values. For instance, the function AssociationJxists is a boolean type; it is assigned the value true at all times. However, all the functions were used as conditions for firing transitions; hence, declaring them as dummy functions would not allow the protocol to be simulated properly. Based on the brief documentation available in the specification, the definitions for the functions were made as complete as possible. The function Association_Exists is used as an example again. Association_Exists returns true if an association with its peer exists and is not currently in use. In defining this function, it was necessary to introduce two new variables: peer _ association _ exists and association-status.

type association-status-type Assoc_ active) {where assoc_idle indicate

= (Assoc_idle,

and Assoc_active

the status of the peer-to-peer

are used to

association}

and (association _

USING

Edb

Edb is not only a simulation tool but also a symbolic debugger for Estelle specification. It allows a user to observe the overall effects of transition execution in terms of communication between system components i.e., module instances. It also allows tracing and undoing of transition, restarting from a previously logged globally environment, and inserting observation points under specified conditions. A simulation session may be conducted in many different ways. The simplest is “step-by-step” i.e., execution of one transition at a time. A transition to be executed can either be chosen automatically by the simulator or by a user who may display all executable (i.e., firable) transitions or select any one of them interactively. Several simple commands are provided by Edb to display objects of the simulation specification or to control the simulation process. Edb allows a user to create simulation script using macro. Simulation script can be though of as simulation scenario which may also include so-called “observers”. These “observers” have the power to describe an overall simulation situation and act according to the situation encountered, e.g., “break” the simulation when a specified situation has been attained. An uninterrupted simulation continues to execute transitions one by one. A user is required to put these conditions and actions within the “observer”. The uninterrupted simulation session continues until a “break” command is executed within the observer or a deadlock situation is encountered or a run-time error in a transition execution is detected.

var peer _ association _ exists: boolean; association-status:

association-status-type;

Complete definitions for the function: Function Association-Exists:

boolean;

9.1 Simulation

Scenario

Simulation scenarios or macros can be created to enable observers to test the protocol in a simulated environment. These macros are designed to perform a particular task which may be very tedious to carry out interactively. The TP specifications were simu-

The Estelle Specification lated using macros. Some commonly used macros are Execute( ), Scenariol( ), and Scenario2( ). The macro Execute( ) provides a scenario which continues for three cycles, given that there are no deadlocks or errors (runtime) encountered. Its purpose is to fire transitions randomly, and if any error is encountered, it determines the cause of the error (i.e., deadlock or runtime error) and outputs details of the last transitions fired before a successful end (i.e., all cycles completed), or an unsuccessful end (i.e., deadlock or run-time error encountered). The Macro Scenariol( ) is to change the working pointer to each individual module and then firing transitions from them. It calls the macro Execute( ) to carry out the firing of transitions and checking of errors. The Macro Scenario2( ) is to fire transitions one step at a time until a deadlock situation is encountered (or break, or error situation). It provides extensive information about the transition that is responsible for the deadlock. It also provides details about the module instance which will contain the last fired transition before a deadlock situation is attained.

9.2 Simulation

Result

A deadlock was found in the AEIMODULE-AEI module. In the specification, the main module (TPSPEC), with the attribute systemprocess fired only one transition. It also initialized the modules (with attribute process): AEIMODULE-AEI (with three different values), and USEMODULE-TPSUI (with 3 different values). The AEIMODULE-AEI in turn initialized the MACMODULE-MACF. The only choice of executing any transition after the initial firing of the transition 0 (i.e., from TPSPEC) was from either USEMODULE-TPSUI or AEIMODULE-AEI. Because there were no transitions present in USEMODULE-TPSUI, only transitions in AEIMODULE-AEI could be fired. No other module transitions could be accessed at this point. In the module instance AEIMODULE-AEI, two more transitions were fired before a deadlock situation was encountered.

10. EVALUATION OF THE TP ESTELLE SPECIFICATION The experience in processing the TP DIS Estelle specification is summarized as follows: l

A deadlock may potentially develop in the TP system specified. The lack of documentation makes it rather hard to investigate this further. It would

J. SYSTEMS SOF’IWARE 1997; 36:137-I45

143

also be inappropriate to make any judgment regarding the protocol itself, as the specification used was of DIS status. The process of transferring the TP DIS Estelle specification onto the computer took up a lot of time. Due to this labor-intensive task, initially, there were a lot of syntactical errors. The inability to successfully use one of the translator options required that the specification needed manipulation before it could be compiled. Due to the large size of the specification, as well as the complicated structuring, this task was very time consuming. The TP specification was incomplete, which meant that to be able to successfully simulate the protocol, the specification had to be fully defined (i.e., completeness of specification is a restriction enforced by Edb). There were about 30 incomplete functions and procedures that needed to be defined completely, and the size of the specification made this task very difficult. The most difficult part was to define the functions and some of the variable declarations. The difficulty arose mainly from the fact that there was no documentation available for the specification; hence, it was required to search through approximately 8000 lines of codes to determine the contents of the functions and the type declarations of the variables. It is difficult to complete codes written by someone else if there is no documentation available for it. 1. EVALAUTION

OF EC

The strengths and weaknesses of EC are as follows: The Estelle translator provides the options such as “-d” and “-w” which make debugging much easier. Error messages are quite explicit and coherent. They are similar to the warnings provided by any Pascal compiler. Anyone familiar with Pascal would find debugging fairly easy. Global warnings should be treated carefully because the translator does not always convert the keywords to its correct form. The warnings do help, however, because most of the time it lets a user know what the error in the specification is. The option “-u” is rather handy when using the C-Code Generator. Without this option. the error message provided means little. The “+I” option allows generation of incomplete C code (i.e., code which may contain errors), with the error message embedded where an error actually occurs.

144

R. Lai

J. SYSTEMS SOFTWARE 1997; 36:137-145

Overall, both the Translator and the C-Code Generator are very easy to use and most of the options provided for each of them are used extensively during the compilation of the TP specification. The extensive usages can only suggest the importance and effectiveness of these options. The C codes generated by the compiler contained documentation. This enabled the codes to be better understood. The C codes generated for each entity of Estelle specification can be readily identified. This makes debugging of program easier. However, there is one problem with one of the Translator options; it led to complications that consumed a lot of time. The “-1” option, which allows the use of “#include” statements in Estelle specifications, did not work. It was then necessary to put all the “include” files together in one file, while the Estelle semantics, such as module nesting, needed to be observed. This task was rather difficult as the TP specification was very large.

12. EVALUATION

OF Edb

The strengths and weaknesses of Edb are as follows: The ability to define simulation macros helps save a lot of time. For instance, if there is a need to execute 200 transitions, without using macros, it would be necessary to issue the command “continue” 200 times (provided there are no errors present). However, with the use of macro, the use of a simple loop (i.e., “do” loop) statement to execute the same number of transitions will be sufficient. The use of observer point allows a user to detect the causes of errors during a simulation session. A user can check any variable at any point in time during a simulation session, making it fairly easy to trace the cause of errors. There is an extensive range of commands available in Edb. They make it very easy to check any variables and to understand the execution of transitions. This is especially good when simulating a large protocol such as TP. Edb is not very user-friendly. Quite often it is very difficult to follow the execution of transitions especially when simulating protocols with many different module instances and transitions. A graphical representation may make the simulator more user-friendly.

When defining a macro at the simulator’s command level, if any typographical error occurs, the macro needs to be defined again from the beginning. This can be quite a nuisance when defining large macros. Another feature that needs improving is file management of macros. Currently, once a simulation session ends, the macro is lost (i.e., not saved); this can be very frustrating if a macro used in one simulation session needs to be used again in another simulation exercise. It may be simpler to create separate files consisting of macros outside a simulation session. Putting macros in files will help their accessibilities during a simulation session, thus eliminating the need to redefine the same macro again when starting a new session.

13. CONCLUSIONS This article has presented the experience in using EDT to compile, to generate C-codes from and to simulate the DIS TP Estelle specification. It has provided developers with some pointers to the potential difficulties and successes when they contemplate using the TP Estelle specification for protocol development. And the lessons learned from this work can also in fact serve as reference points for any one who considers using any IS0 standardized formal specification for protocol development. The lessons learned from this work can be summarized as follows: Compilation of a standardized Estelle specification of the size of a few thousands lines can be a time-consuming job. An IS0 DIS Estelle specification complete.

might not be

An Estelle compiler might impose some restrictions on the specification. Modifications to a standard Estelle specification might be necessary in order to have a clean compilation. Such modifications are very time-consuming, due to lack of documentation available in the standard and the sheer size of the specification. A standardized Estelle specification does enable a protocol to be implemented quickly and analyzed by a computer tool. Tool, like EDT, is very comprehensive and powerful. Without it, the usefulness of any standardized formal specification is limited.

The Estelle

Specification

The IS0 TP specification became an international standard (IS) in 1994 (ISO, 1994). It is not known whether some of the problems mentioned in this article about the Estelle specification have disappeared in the TP IS. Whatever the case, this article has provided a list of things that any TP implementer might need to pay attention to. It was pointed out that one of the ways to help industrialize the uses of FDTs is by having more reports on the uses of FDTs and standardized formal specifications (Lai and Leung, 1995). This article has provided such a report which should help encourage wider uses of FDTs and standardized formal specification in the industries.

ACKNOWLEDGMENT The availability of the EDT software made available by Institut National des Telecommunications, France for this work and the assistance of Tanveer Hossain are hereby acknowledged.

REFERENCES ISO, Information Processing Systems, Open Systems Interconnection. Guidelines for the Application of FDTs to OSI, ISO/TC97/SC21/N1534, Geneva, September 1986. ISO, Information Processing, Open Systems Interconnection. LOTOS: A Formal Description Technique based on a Temporal Ordering of Observational Behaviour, IS0 IS 8807, 1989a. ISO, Information Processing, Open Systems Interconnection. Estclle: A Formal Description Technique based on an Extended State Transition Model, IS0 IS 9074, 1989b. ISO, Information Technology, Open Systems Interconnection. Transaction Processing Model, IS0 DIS 10026, Parts I , 2, and 3, 1990.

J. SYSTEMS 19’)?;36:137

145

SOFTWARE 145

ISO, Information Technology, Open Systems Interconnection. Transaction Processing Model, IS0 IS 10026 Parts 1, 2, and 3, 1994. Bearman, M. Y., Wilbur-Ham, M. C.. and Billington, J.. Specification and Analysis of the OS1 Class 0 Transport Protocol, in Proceedings of the Sec,enth International Conference on Computer Communication, North-Holland, Amsterdam, Holland, 1984. Bochmann, G., and Joachim, T., Development and Structure of an X.25 Implementation, IEEE Transaction on Softiare Engineeting, Vol. SE-S, 429-439, (September 1979). Bolognesi,

T., and Brinksma,

E., Introduction

to the IS0

LOTOS, Computer Networks and ISDN Systems, 14, 25-59 (1987). Budkowski, S., and Dembinski. P., An Introduction to Estelle: A Specification Language for Distributed Systems, Computer Networks and ISDN LYy,stcwu. 14, 3-23 Specification

Language

( 1987). Budkowski,

S., Estelle

Development

Toolset

(EDT), Com-

puter Network and ISDN System.s. 25. 63-82 (1992).

Lai, R., Dillon. T. S., and Parker, K. R.. Application of Numerical Petri Nets to Specify the IS0 ETAM Protocol, in Proceedings of the Singapore International Conference on Networks, Singapore, July, IYXY. Lai, R.. Dillon. T. S., and Parker. K. R., Verification Results for IS0 FTAM Basic Protocol, Prutocol Specification, Te.sting and Verification IX. North-Holland, Amsterdam, Holland, 1090. Lai. R., and Leung, W., Industrial and Academic Protocol Testing: the Gap and the Means of Convcrgencc, Computer Networks and ISDN Systems.

37, 537-547

(1995).

Lee, D. Y.. and Lee, J. Y., A Well-Defined Estellc Specification for the Automatic Test Generation IEEE Transactions on Computers, Vol. 40, No. 4 (April 1YYll. Miller, R. E., and Paul, S., Two Techniques for Gencrating Test Sequences for Communication Protocols, in Proceedings of the 3rd International Workshop on Protocol Test Systems, North-Holland. Amsterdam, Holland, lY90.

West, C. H., A Validation of the OS1 Session Layer Protocol, Computer Networks und I.SDN .5)stew.s. 11, 173- 182 ( 1986).