The Design of a Simulator Tool

The LOTOS simulator Hippo was developed in the ESPRIT/SEDOS project. In this chapter we elaborate on its design process. We give an overview of the functional requirements on a LOTOS simulator for the analysis of dynamic behaviour. Following that we describe how the implementation of Hippo is derived by stepwise transformation of the LOTOS inference rules. 1. Functionality of a Simulator Tool It appears that a central tool for LOTOS is a simulator for specifications, since it is the core for analysing the dynamic behaviour. In this chapter we elaborate on the design of a LOTOS simulator. The purpose of a simulator is to analyse a specification with respect to its dynamic behaviour. This can be done by going stepwise through all the interactions and checking whether or not these interactions conform to the expectations of the designer. The basic operation of a simulator is as follows. From the specification a set of acceptable events is computed. Subsequently, usually under user control, one of the events is chosen (accepted) and the resulting behaviour is computed. This step repeats at liberty, under user guidance. Other functions of the simulator serve to enhance the presentation of this basic model to the user. The structure of this chapter is as follows. The functions of a simulator are motivated by the design process in which they are needed. The underlying model and a set of possible functions are explained. Some of these functions are considered more basic than others because, for example, other functions can be expressed in them, they are fundamental to the user, or they can be implemented more directly. Such subsets of functions are discussed and motivated. Based on a formal definition of the basic simulator functions, an implementation of these functions is derived. This is done by systematic transformation of the formal definition. 1.1. Functional Requirements 1.1.1. Relation with the Design Process In this section we elaborate on the relation between the process of designing protocol systems and the simulator. This is because the functions that are provided by a simulator are to be justified by the structure of the design process for protocols. That is, a tool function should be useful in the context of a design process. The simulator models the observational behaviour of the specified entity. This can serve as a way to demonstrate the functionality of the protocol. A simulator thus provides a prototype for the protocol. In the specification phase of protocols there is a need for animation of the protocol design. A designer would like to browse through the possible behaviour of the protocol in terms of the possible stimuli and interactions. This will allow the expectations of the designer to be confirmed or contradicted. In general, this aids in verifying and validating that certain constraints are satisfied, where these constraints can be given in a formal or in an informal way. Examples of such constraints are: deadlock freeness, elegance of design. In general, the implementation phase of a protocol need not be conducted by the designer of the protocol. This is especially true in the case of international protocol standards. One therefore needs a way to communicate the details of the design of a protocol to its implementors. If the standard contains a formal specification, a simulator can act as a teaching aid, so that the implementors intuitive understanding of the protocol can be checked. This is another function realised by behaviour animation. Once an actual implementation of a protocol is at hand, the need rises to validate the correct realisation of the protocol. Apart from properties inherent in the design process, e.g. as in the case where the implementation is produced automatically from the specification, the only way to gain confidence in the protocol implementation is to test it for correct functioning. For this we need on the one hand a way to assist in the generation of tests and on the other hand a mechanism to check actual behaviour of an implementation against prescribed behaviour. These functions are obviously related to the simulator tool. Whether they should be incorporated in a simulator is dependent on other criteria such as user and implementation convenience. 1.1.2. Relation to Other Tools As pointed out in the preceding section a simulator shares much of its functionality with other tools. Examples of these are the tools to support test generation and trace checking. Generating tests consists in principle of enumerating sequences of allowable interactions. Trace checking consists of ascertaining whether a particular sequence of interactions is allowed by the specification. This may involve examining all possible resolutions of nondeterminism. A simulator also forms a basic module for tools that support the verification of protocols by searching in the state space. Such a verification involves making a tour through the communication tree, guided and restricted by certain criteria to make it feasible. 1.2. Elements of Functionality This section contains a functional analysis of a possible simulator for LOTOS. The intention is that all relevant simulator functions are covered in this section, although in varying levels of detail. We distinguish three groups of functions: navigation functions, checking functions, and coverage analysis functions. There are three levels of detail in this functionality overview, although this is not reflected in the division in sections. One group consists of functions that are fundamental to a simulator. A second group consists of functions that are complete in their definition and that can be implemented. They may, however, for implementation resource reasons, not be implemented in a first version. The last group consists of functions of which the definition is not completely finished, and that require further study. These are indicated in the text as such. The Abstract Data Type part of LOTOS is not discussed in detail here. It is orthogonal to the process part of LOTOS, and the only function assumed on it is a function ‘eval’.