A Graphical Tool for Specification of Reactive Systems

Transcription

1 A Graphical Tool for Specification of Reactive Systems Kari Systä Tampere University of Technology P.O.Box 527, SF Tampere, Finland Abstract A prototype of a simulation tool with graphical visualization and animation facilities has been implemented for the Dis- Co specification language. This paper describes the basic ideas behind it, with emphasis on the visualization and animation facilities. The DisCo language is designed so that formal reasoning can be used to ensure critical properties of the specification. Simulation with animation is intended to complement the formal reasoning, not to replace it. Another purpose of graphical animation is to visualize specifications so that their authors and the customers can more easily discuss them. Because the user of the DisCo tool may lack the required knowledge and motivation to write programs for the animations, it must be possible to create the displays as easily and automatically as possible. The DisCo tool provides facilities for that. 1. Introduction Joint actions can be used to specify reactive 1 systems. A description of the joint action approach can be found in [1], [2] and [3]. A joint action specification consists of multiparty actions and objects that participate in them. A difference between joint actions and most other operational specification methods is that the joint action method is not process-oriented. The objects in the joint action method can be implemented either as separate processes, or as passive data structures. An important feature of DisCo is that the effects of actions are not distributed to processes involved, but are collected to special syntactic entities. Pictures help the reader to understand the specifications and to interact more easily with them. The structure of a specification, especially its internal relations, are best described with graphical displays. The advantages of pictures are [4]: Multiple dimensions. Text is one-dimensional sequential data, but pictures provide means to have two or even more 1. Reactive systems are ones that are in continuous interaction with their environment. This distinguishes them from traditional input/output computations. Reactive systems typically contain parallelism and most often they are embedded systems. dimensions. Pictures are also richer, because properties like color, shape, direction and distance can be used. Random access. In pictures it is easy to shift attention from any part of the picture to another. Text is normally sequential. Good partitioning, different fonts and different highlighting techniques can make text access less sequential, but at some level the reader must use sequential scanning. Transfer rate. Information from good pictures can be read much faster than from text. This fact has been utilized for example in advertisements, operating instructions and traffic signs. Natural language independence. Although cultural differences exist, pictures are language independent and they do not need translation from one country to another. Concreteness and abstractness. Pictures are direct translations of existing objects, but text is an abstract way of describing things. In textual representations objects must be named before they can be accessed. In pictures objects may be accessed simply by pointing. The abstractness of text is also its strength, and in formal specification the use of mathematical abstractions requires textual notation. In the DisCo tool the combination of textual language and graphical displays gives the advantages of both representations. The structure of the rest of this paper is the following. Section 2 gives an introduction to the DisCo language. Section 3 describes the design of the DisCo tool. Section 4 gives an example of a specification, whose animation and visualization is also shown. This section complements the information of Sections 2 and 3 with concrete examples. Section 5 briefly describes the implementation tools we have used, discusses the experiences we have got so far. Finally, Section 6 relates the DisCo tool to work done elsewhere. 2. The DisCo-language Before going to details of the tool, a quick overview to the DisCo specification language is given. A more detailed description can be found in [5] and [6]. DisCo supports objectoriented modelling; DisCo language objects always belong to a class that defines the data and state structures of objects within that class. An object can be understood to consist of two interrelated parts: a finite state part that is a state autom-

2 aton, and a data part that contains variables and constants. The finite-state structure of a DisCo object is similar to the hierarchical structure used in statecharts [7]. Figure 1 contains an example of a class definition and the corresponding statechart. In a complete form the statechart would also contain arrows that describe the state-transitions. In DisCo these transitions correspond to actions, and they have been omitted from Figure 1. class Proc (Next:Proc) is -- Next is a parameter, which is a -- reference to another Proc-object state *Prepare, Compute; -- two states, default marked with * state *Important,Unimportant;-- two independent states extend Important by state *Quite_I, Very_I; -- substates of Important end Important; Data : integer; -- a variable end Proc; *Preparing Computing Proc *Important *Quite_I Very_I Unimportant Figure 1. An example class and the corresponding statechart. The state-transitions are not shown in this picture. The other basic components in DisCo are actions, in which the objects may participate. An action definition has a name, zero or more parameters, one or more participants, body, and an enabling guard. Each participant is specified by its class, and it is given a formal name called role. Whenever an action is executed with some objects as participants, the action body may change the participating objects. An action cannot modify objects that are not participants of the action. The guard is a boolean expression which has to be true for the action to be executed. The guard can therefore be used to restrict the possible participant combinations. The following is an example of an action: action Exchange (X: integer) by L,R:Proc is when X > 0 and L.Data > R.Data+X do -- guard R.Data := L.Data L.Data := R.Data; -- body of the action end Exchange; This action has two participants named L and R, which are both instances of class Proc. The identifier X denotes a parameter whose value is determined when the execution of the action begins. The guard of this action restricts the participating objects and the possible values of the parameter X. The action is enabled only for those objects of class Proc whose Data components satisfy the condition given in the guard. If there is freedom in selecting the possible participants or parameter values, they are determined by a nondeterministic choice. An execution of the DisCo specification consists of a sequence of successive actions, and at any moment the next action can be any of the enabled actions. In addition to classes and actions, assertions can be given in specifications. An example of an assertion is assert P:Proc:: Proc.Data > 0; which states that the Data variables of all Proc-objects must be positive. Assertions can be used to specify invariants for the whole execution, and to restrict the initial state of the system. Reasoning about DisCo specifications is based on an execution model in which actions are executed sequentially - not in parallel. However, the next action to be executed is selected by a nondeterministic choice from the enabled actions. This means that an interleaving model of parallelism is used. The relation between nondeterministic serial execution and parallel execution of actions has been addressed in [2] and [3]. The problem of modelling real-time properties in DisCo is currently under research. A collection of classes, actions and assertions is called a system. Instances of classes are not created in a system, and a separate creation section is used for this purpose. System with assertions for the initial state is enough for formal proofs, but a concrete initialization described by the creation is needed for execution. DisCo has two mechanisms for derivation of specifications: inheritance that is similar to the corresponding concept in object-oriented programming languages, and an extension mechanism that is suited for superposition. A comparison of DisCo and the object-oriented paradigm can be found in [5]. More details of the DisCo language will be given in connection with a complete example in Section The DisCo Tool and its User Interface 3.1. Formal Methods, Testing and Animation Executability of DisCo specifications 1 gives us a possibility to validate specifications by testing. It is clear that critical properties cannot be verified by testing, because the execution may never reach all possible states of the system. On the other hand, formal reasoning is a very expensive and time consuming task, and so applicable only to the most critical properties. Another problem with formal reasoning is the recognition of the properties to be proved. Our goal is to use testing in combination with formal reasoning. When a specification is tested, the user gets another view of the specification, which helps in understanding the problem and helps in finding the critical properties that need formal reasoning. The initial assumptions and the conclusions of formal reasoning can also be added to the specification as assertions. 1. This is actually semiexecutability, in the sense that all actions cannot be executed without user assistance. It is possible to write guards with implicit conditions in the guards, so that the tool is not able to determine the possible participants and parameter values. In practice this kind of complicated actions are very rare, and typical actions can be executed automatically.

3 When the specification is executed, these assertions are continually checked. Thus, testing can be used as a tool that aids the formal reasoning. Graphical visualization and animation is useful also when a specification is demonstrated to other people. For example, experts in the application area are not always capable or willing to understand formal proofs, but after seeing graphical animation they can comment on the specification, and their questions may provide valuable input for further formal reasoning by a computer scientist. The DisCo language has some properties that facilitate the use graphical notations. Objects and actions are well encapsulated concepts with simple relations to each other. Also, the state structure of the objects is designed so that an existing graphical notation, statecharts, can be used. The DisCo language has also concepts that are difficult to deal without graphical notations. Objects have no global names, and thus the description and control of the execution is difficult without concrete graphical objects The Architecture of the DisCo Tool The DisCo specification tool consists of three parts: compiler, interpreter and user interface. The compiler [8] takes a specification written in the DisCo language, performs semantic checks, and produces an executable internal representation. The internal representation, which is Lisp-code, can then be executed by the interpreter. The user interface is used to control and visualize the static structure of the specification as well as dynamic changes during execution. The architecture of the DisCo tool is shown in Figure 2. DisCo language Configuration info Compiler 3.3. Graphical Displays Internal representation Interpreter USER INTERFACE Figure 2. Architecture of the DisCo tool. The graphical entities to be displayed correspond to actions, classes, objects and states of the specification. The user can work with a specification by displaying its entities in graphical browsing windows, and browse it by directly pointing to the interesting entities. For example, if there is a window displaying all classes of the current specification, the user can click on one of the icons with the right mouse button. This creates a pop-up menu, from which the user can choose the command display instances. All instances of the classes are then displayed in a separate window. The whole interaction with the browser takes place by directly pointing and operating with the items on the screen. The entities in the displays are simple graphical objects with textual labels. For example, the labels of actions consists of the name of the action and the names and classes of the participating objects. Displays often include relations between objects. These relations are displayed by drawing connecting lines between objects. For example, if an object contains a reference to another object, this reference can be represented by drawing a line from the referring object to the referred one. The browser displays are active windows, not just snapshots of the state of the specification. The user can start commands from all windows. For example, there is a set of commands that can be issued to a DisCo class. In the user interface these commands can be started from any visible depiction of the class of interest. Also, the displays are automatically updated if the contents of the objects change Animation of execution Animation is used to display the effects of the actions to the objects. We assume that there is no need to animate how a single action works. It is more useful to base the display on what the effects of the action are and which action is responsible for the effect. Because all displays are updated automatically, the user can see the effects of the actions in the displays immediately. The user also has a possibility to start a special animation display which contains actions and instances of several classes. The user can add or remove classes and actions from the animation display in order to get a selection of the most interesting entities Execution control by a graphical user interface There are two possible ways to fire actions: automatic and manual. In automatic execution the next action as well as its participants and parameters are automatically chosen. In some complicated cases an automatic execution cannot select the participants and parameters. This is a consequence of unbounded nondeterminism and the generality of guards. In such cases execution must be guided by a manual interface. In manual execution the user must first select the action to be executed, then the participating objects, and finally the parameters. While selecting participants the user selects a role (formal name of the participant) and the object that should take this role. If the action has several participants the user must continue selecting the other participants until the system can uniquely determine the remaining ones. All these selections are done by direct pointing with the mouse cursor. When the participants have been selected, the values of the parameters (if any) are asked from the user. The interface guides the user by showing currently enabled and disabled actions in a different way. This means that in the manual execution the user can immediately see which actions are available. In the same way the allowed partici-

4 pants could be displayed differently from the objects which cannot participate. However, it is impossible to show all possible participant combinations in a clear way. The current version of the tool tries to solve this problem by showing the legal participants for a role after the user has specified an action and the role. In many cases the user may want to repeat a sequence of previously executed actions. This feature is needed in testing, when execution has to be replayed after modifications to the specification. Also when the system is used for demonstration, the interesting execution sequences should be available. To fulfill these requirements the DisCo tool allows the user to save and restore execution histories Configuration The purpose of the animation display is to describe the behavior of the specification so that also a user who is not the author of the specification can understand it. Thus, the animation display should reflect the structure and terms of the application under specification. In distributed sorting, for example, a suitable layout is a horizontal row. In the classical problem of dining philosophers, the objects should be placed on a circular path. Also, it is not straightforward to decide what the textual label of an object should be. It could be the current state of the object, a value of some variable, or a combination of those. It is not possible to have a general algorithm, that can generate a good display by analyzing the textual specification. The problem is hard enough, if the only requirement is to place objects so that the crossings of lines are minimized. There is also another problem with automatically generated display layouts: a minor change in the original specification may cause a total reorganization of the display. After such reorganization the user has to learn the new picture from the beginning. Sophisticated animation displays require user programming, which is not reasonable in our case. Because we want to keep the configuration effort as easy as possible, we have made a compromise by providing a configuration facility, that is based on predefined choices. The tool generates the first display, and the user can change its properties by using the configuration facilities. This does not require programming skills, and it can be done in a few minutes. All choices also have defaults, and so the user gets always a default display without doing any configuration work. Once specified, the configuration can be saved and automatically reused when the same specification is animated again. More details of the configuration facilities are described together with a concrete example in Section An Example Specification and its Animation As an example we give a simple specification of a doctors' office. This example demonstrates also modularity and stepwise refinement, which are important features of the DisCo method and language. After completing the specification, the execution and graphical animation is shown The Specification of Doctors' Office On the most abstract level our specification indicates only that there are patients that may get sick and well: system Patients is class Patient is state *Well, Sick; -- Two states: Well is a default state end Patient; action Get_Sick by P:Patient is when P.Well do -- Action is enabled if some patient is in state Well -> P.Sick; -- '->' denotes a state-transition, where the object end Get_Sick; -- participating in role P changes to state Sick. action Get_Well by P:Patient is when P.Sick do -> P.Well; end Get_Well; end Patients; In the next version we specify that doctors are needed to cure patients. This specification imports the previous specification by using the import-statement. system Doctors import Patients; is -- More details to the Patient by adding substates to Well. The -- keyword hide of state Checking_Out disables old action Get_Sick -- while a patient is in state Well.Checking_Out. extend Patient.Well by state Released, hide *Checking_Out; end Patient.Well; class Doctor is -- A doctor is either free or busy with some patient. state *Free, Busy(P:Patient); end Doctor; -- The old action is refined to have a new participant. refined Get_Well by... D:Doctor is when... D.Free do -- An ellipsis (...) denotes parts of the -> D.Busy(P); -- action taken directly from old system Patients. end Get_Well; -- A new action that completes the healing. action Release by P:Patient; D:Doctor is when D.Busy.P = P and P.Well.Checking_Out do -> D.Free; -> P.Well.Released; end Release; end Doctors; In this example we have used a superposition transformation, which adds new details to the existing Patient class, and adds a new class Doctor. Also a new action Release is introduced, and the old action Get_Well is refined to have a new participant. This new specification does not change the old structure of existing classes, but it adds new components. The new actions and changes to old actions do not affect old class components. In other words, we can always have a Patients view to the system Doctors, and in that view all executions of system Doctors are legal also in system Patients. This means that superposition preserves safety properties: the new system does not do anything that was

5 not allowed in the old specification. The transformation does not necessarily preserve liveness properties, and it is possible to have a legal superposition that inhibits an action. The next step is to add receptionists to maintain queues of waiting patients and doctors. Previous actions are refined to include necessary queue operations. system Office import Doctors; is class Receptionist is PQ: sequence Patient;-- queue of patients waiting to see a doctor DQ: sequence Doctor;-- queue of free doctors end Receptionist; -- Doctor is extended by a new parameter, which binds a doctor to a -- receptionist. extend Doctor(... My_Rep: Receptionist := null) by end Doctor; refined Get_Sick by... R:Receptionist is when... do... R.PQ := R.PQ & <P>; -- add a patient to the end of queue end Get_Sick; refined Get_Well by... R:Receptionist is when... P = head(r.pq) and D = head(r.dq) do R.DQ := tail(r.dq); -- remove the first doctor from queue R.PQ := tail(r.pq);... end Get_Well; refined Release by... R:Receptionist is when... D.My_Rep = R do R.DQ := R.DQ & <D>;... end Release; end Office; The rest of this section refers to the system Office, for which the animation is shown. If we want to execute and animate the system Office we need a creation, which could be the following: creation Run_Office of Office is P : Patient; R : Receptionist; D : Doctor; for I in 1..5 loop -- Create 5 patients P := new Patient; -> P.Well.Released; end loop; for K in 1..2 loop -- Create 2 receptionists R := new Receptionist; for J in 1..2 loop -- 2 doctors for each receptionist D := new Doctor(R); R.DQ := R.DQ & <D>; -- Initialize queue end loop; end loop; end Run_Office; 4.2. Animation Display and its Configuration When the DisCo tool is started, a main window with several push-buttons and a text message area is displayed. When the user pushes the button COMPILE, the system displays a selection of DisCo source files. From these files the user selects the one to be compiled. In our example the user must compile the file(s) containing systems Patients, Doctors and Offices, and he must also compile the file containing the creation Run_Office. Usually all these specification components are placed in a single file, and thus they can be compiled with a single command. RELEASE GET_ GET_SICK R D P R D P R P PATIENT-5 PATIENT-4 PATIENT-3 PATIENT-2 PATIENT-1 DOCTOR-9 DOCTOR-8 DOCTOR-7 DOCTOR-6 RECEPTIONIST-11 RECEPTIONIST-10 nil nil Figure 3. The first animation display of the example specification.

6 After compilation, when the user wants to load a creation, the system displays the selection of compiled creations. When the user has chosen one, the creation and the corresponding system are loaded. When the system and creation have been loaded, the user may start an animation window. An example of that window is shown in Figure 3. In this display the layout and graphical properties of the objects are automatically selected by using the defaults of the system. The following rules are used to create this display: Place the instances of each class to a single horizontal line. Use a fixed value for the width and height of an object. Generate the text label from the finite-state part of the object. Display all relations between objects indicated by the parameters and variables in the objects by connecting lines. Usually this automatically generated display is not satisfactory, and the user has a set of configuration facilities to change it. The first changeable attribute is the layout of class, which can be a horizontal line, a vertical line, a diagonal line, a two dimensional table, a circle, or a stack. The last option, stack, makes the objects overlap. This is useful when the number of objects is high. The layout can also be varied by changing its screen area from the whole window to a user selected subarea. If no predefined layout fits the user's need, he can move each object by direct dragging with the mouse. In addition to the global layout, the user may also change the attributes of single objects. The changeable attributes are: the width, the height, and the displayed text. The displayed text may contain either the current state of the object or the contents of any of its variable. It would be easy to add colors to the list of changeable attributes, but this has not been done because colors are used to indicate execution properties during animation. The set of displayed object references may also be selected by the user. For this purpose the tool displays a list of variables that may contain object references. From this list the user can select the interesting ones. The result of the configuration done for our example is shown in Figure 4. When the user has completed the configuration of the display, he can save it either to a specified file or to a default file. The default configuration file is read automatically, when the same specification is loaded into the tool next time. The whole configuration work is based on predefined choices and direct manipulation interfaces. This means that no traditional programming is needed, and the configuration can be done by an end-user, who usually is a person who works with the specification. In practice, if the user is familiar with the tool, the configuration takes only a few minutes Execution During execution, all displays are automatically updated when the state of the specification changes. In addition, some extra highlighting is added to make execution easier to follow. Actions, which are placed in the upper part of the window, change their color according to their activity. An action that is not enabled is displayed in yellow. An active action, whose guard is true, is carmine. In the middle of execution the color of the executing action is red. Also the participants of an action are highlighted: they are surrounded RELEASE GET_ GET_SICK R D P R D P R P PATIENT-5 PATIENT-4 PATIENT-3 PATIENT-2 PATIENT-1 GET_SICK RECEPTIONIST-11 RECEPTIONIST-10 nil nil DOCTOR-9 DOCTOR-8 DOCTOR-7 DOCTOR-6 Figure 4. Animation display during action execution. The participating objects are highlighted, and the name of the executing action is displayed diamond-shaped icon.

7 by a red frame. To complete the visual outlook, an extra graphical object with connecting lines to all participants is displayed when an action is under execution. Figure 4 shows the animation display during execution. As mentioned in section 3.5, the user has three possible ways to execute a specification: The next action, its participants and its parameters are chosen by the tool. This is called automatic execution. The user selects the next action and its participants. This manual execution is used when the user wants to have full control. The execution repeats a previously executed history, which is recorded and saved for later use. The purpose of the animation display is not just to display the animation, but also to help the user to control the execution. This is especially needed in manual execution. When the previous action has been completed, the user can see what are possible actions, because enabled and disabled actions are shown in different colors. If the user wants to specify the next action manually, he starts by selecting the choice execute from the pop-up menu of the action. Then he specifies the participants one after another. A participant is specified as follows: the user points first the role box in the lower half of the action symbol, and then he points the object. The tool helps the user by highlighting the legal objects after the role has been selected. 5. Implementation and First Experiences The implementation of the tool is still going on. The current version is complete enough for demonstrating and testing the ideas presented in this paper, but does not implement all features of the DisCo language described in [5] and [6]. We are currently working on implementation which is based on this version of the language. The new implementation has also a better algorithm for automatic execution. The tool runs on Sun workstations. NeWS windowing system [9] and Allegro Common Lisp [10] have been used as implementation tools. Syntax analysis of the compiler is done by a C-program generated by YACC [11] and LEX [12]. The postscript based NeWS windowing system is used instead of the more standard X Window System [13] (with toolkits like Xview [14] or Motif [15]), because with NeWS we can separate the user interface from the tool semantics so that new user interface ideas can be tested without touching other parts of the tool. NeWS gives also better facilities to create new user interface elements, than the widget structure of X11-based toolkits. The original idea of the tool was to help the user in validating a specification. This has also worked in practice. When a specification has been extracted from a document and loaded to the tool, we have found errors which would have been difficult to find without the tool. The other goal was to use DisCo as a communication tool, which helps people discussing the specification. The developers of VERDI [16] have also experiences that graphical tools help people in using specification methods. The third important benefit of the DisCo tool has been in introducing the DisCo method and language to new people. The ideas behind the DisCo method are very different from those people are usually used to. This gives some people an impression that the method is difficult. The graphical tool helps this problem by providing a bridge between programmers and computer scientists, as well as between application experts and computer scientists. 6. Related Work The DisCo tool differs from the well-known graphical specification methods like SA/SD and SADT in that DisCo specifications are written in a textual specification language, and the graphical user interface synthesizes visualizations from those specifications. In DisCo the specifications are not composed with drawing tools, but with a standard text editor of the system. The manipulations done by the graphical user interface change only the displays. The VERDI system [16] has similar goals as DisCo. Its graphical language has also the concept of multiparty interactions, but its structuring mechanisms are different. Because the VERDI language is graphical, the specifications are written by using a graphical editor. In DisCo the graphical descriptions are derived from the textual specifications written by the user. The textual language used in DisCo allows the user to use both formal reasoning and animated simulation, although no tools have yet been provided for formal verification. However, the constructs of the language support rigorous use of superposition as a design method by guaranteeing that safety properties of imported systems are preserved. The graphical displays of VERDI are based on the notations of a graphical specification language, and no emphasis is put to facilities to change the display so that it can have a correspondence to the application domain. Execution in VERDI is always automatic, which means that if there are several possible executions, one is selected by the system. It also has a virtual clock, which is used to simulate time. The current version of DisCo does not support modelling of real-time properties, but we are currently working on adding this. The STATEMATE [17] tool is based on graphical views, and the user enters the specification in the form of graphical pictures instead of textual descriptions. Another difference is in the way how the behavior of the environment is described. In DisCo, specifications are closed in the sense that the description of the environment is included in the specification. In STATEMATE a special-purpose simulation control language (SCL) is used to describe the behavior of the environment.

8 GROPE [18] is a tool which provides graphical visualizations and animations of protocols specified in Estelle [19]. The GROPE systems has the same approach to animation configuration as DisCo: the animation is edited interactively using an automatically generated animation as the basis. Acknowledgments The joint action method was initially developed by Ralph- Johan Back and Reino Kurki-Suonio. The DisCo language was designed by Hannu-Matti Järvinen and Reino Kurki- Suonio. The DisCo project team Olavi Eerola, Hannu-Matti Järvinen, Tauno Kankaanpää, Reino Kurki-Suonio and Tatu Männistö have all helped me to clarify my ideas and also have given new ideas. They have also helped my by reading the manuscript of this paper, and by giving valuable comments on contents of the paper. Project DisCo is part of the FINSOFT programme of the Technology Development Centre of Finland (TEKES) and it is supported by the following industrial partners: Kone Oy, Oy Nokia Ab Research Centre, Telenokia Oy, and Valmet Automation Oy. References [1] R. J. R. Back and R. Kurki-Suonio, Decentralization of process nets with a centralized control. Distributed Computing 3, 3, May 1989, An earlier version in Proc. 2nd ACM SIGACT-SIGOPS Symposium on Principles of Distributed Computing, Montreal, Canada, August 1983, [2] R. J. R. Back and R. Kurki-Suonio, Serializability in distributed systems with handshaking. In Proc. ICALP 88, Automata, Languages and Programming (Ed. T. Lepistö and A. Salomaa), LNCS 317, Springer-Verlag 1988, [3] R. J. R. Back and R. Kurki-Suonio, Distributed cooperation with action systems. ACM Transactions on Programming Languages and Systems 10, 4, October 1988, [4] G. Ræder, Programming in pictures. PhD dissertation, University of Southern California, Los Angeles, USA, November 1984; Technical Report TR [5] H-M. Järvinen, R. Kurki-Suonio, M. Sakkinen and K. Systä, Object-Oriented Specification of Reactive Systems. Proceedings of the 12th International Conference on Programming Languages and Systems, Nice, France, March ,IEEE Computer Society Press, [6] H-M. Järvinen and R. Kurki-Suonio, The DisCo Language. Tampere University of Technology, Software Systems Laboratory, Report 8, March 1990, [7] D. Harel, Statecharts: a visual formalism for complex systems. Science of Computer Programming 8, 1987, [8] O. Eerola, A compiler for an executable specification language (in Finnish). Diploma Thesis, Tampere University of Technology, [9] NeWS 2.0 Programmer s Guide, Sun Microsystems, Inc., [10] Allegro Common Lisp User Guide, Release 3.1, Franz Inc., November [11] S. C. Johnson, YACC - Yet Another Compiler Compiler. Comp. Sci. Tech. Rep. No. 32, Bell Laboratories, July [12] M. E. Lesk, Lex - A Lexical Analyzer Generator. Comp. Sci. Tech. Rep. No 39. Bell Laboratories, October [13] R. W. Scheifler and J. Gettys, The X Window System. ACM Transactions On Graphics 5, 2, , April [14] D. Heler, XView Programming Manual. Second Edition, O'Reilly & Associates, Inc [15] OSF/Motif Programmer's Reference Manual. Revision 1.0, Open Software Foundation, August [16] V. Chen, C. Richter, M. Graf and J. Brumfield, VER- DI: A Visual Environment for Designing Distributed Systems. Journal of Parallel and Distributed Computing, 8, 6, June 1990, [17] D. Harel, H. Lachover, A. Naamad, A. Pnueli, M. Politi, R. Sherman and A. Shtul-Trauring, STATEMATE: a working environment for the development of complex reactive systems. IEEE Transactions on Software Engineering 16, 4, April 1990, [18] D. New and P. Amer, Adding Graphics and Animation to Estelle. Information and Software Technology 32, 2, March 1990, [19] Information Processing Systems - Open System Interconnection. ISO International Standard 9074: Estelle - A Formal Description Technique Based on an Extended State Transition Model.