- Email: [email protected]
Visualizing graphical and textual formalisms
Information Systems 28 (2003) 753–768
Visualizing graphical and textual formalisms$ R. Castelloa, R. Milib,* a b
Department of Computer Science, ITESM Campus Chihuahua, H. Colegio Militar 4700, Chihuahua 31300, Mexico Department of Computer Science, The University of Texas at Dallas, Box 830688, Richardson, TX 75083-0688, USA Received 11 May 2002; received in revised form 1 October 2002; accepted 15 October 2002
Abstract ViSta is a tool suite designed to support the requirements specification of reactive systems. It guides the user through the steps necessary for the visualization of statechart diagrams from an informal document. The user first extracts information from a textual document and stores into a set of interactive templates. The information is used by the tool to automatically generate statechart layouts. In this paper we describe how ViSta is augmented with a tool that automatically translates statecharts into Z specifications. The template, statechart and Z representations are interrelated. This ensures consistency between the different representations, and therefore facilitates the verification and validation effort. r 2002 Elsevier Science Ltd. All rights reserved.
1. Introduction Several requirements specification styles for the specification of reactive systems have been proposed in the literature. Informal specifications are the most widely used in the software industry nowadays, mainly because they are ‘‘understandable’’ by domain experts and software engineers, and therefore can be included as part of a software contract. Unfortunately, because of the inherent ambiguity of natural language, these documents are difficult to interpret and maintain. Formal specifications [1–7] on the other hand, make use of mathematical notations that offer precise syntax and semantics. Unfortunately, because of the complexity of the formal description these documents may not be acceptable to many stakeholders. Visual formalisms [8,9] bridge the gap between informal and formal specifications by offering graphical notations with semantics. Unfortunately, hand made diagrams become easily unreadable when the requirements complexity increases. In addition, visual formalisms do not enjoy the powerful verification, code optimization, or model-checking techniques that are common to formal notations. The purpose of this work is to combine the advantages of using visual formalisms for the specification of reactive systems with that of using formal verification and program transformation tools developed for textual formalisms. We have developed a tool suite called ViSta [10,11] that automatically produces statechart layouts based on information extracted from an informal specification. In this paper, we discuss how ViSta is $
Recommended by Prof. Loucopoulos. *Correspondence author. Tel.: +1-972-883-2091; fax: +1-972-883-2349. E-mail addresses: [email protected] (R. Castello), [email protected] (R. Mili).
0306-4379/03/$ - see front matter r 2002 Elsevier Science Ltd. All rights reserved. doi:10.1016/S0306-4379(02)00081-9
R. Castello, R. Mili / Information Systems 28 (2003) 753–768
754
augmented with a tool that automatically translates statecharts to Z specifications. The resulting system allows the specifier to shift focus from organizing the mental or physical structure of requirements to its analysis. In addition, the interdependence between the template, statechart and Z specifications ensures consistency between the different representations, and therefore facilitates the verification and validation effort. Statecharts [8] are extended finite state machines used to describe control aspects of reactive systems. They provide mechanisms to describe synchronization and concurrency, and manage exponential explosion of states by using state decomposition. The statechart notation is supported by numerous tools [12–15]. Z is a formal notation based on set theory and predicate logic. Z has been successfully used for the specification of complex systems. Industrial applications of this notation include the specification of the B27 traffic control system [16]; the specification of the BMW Rolls-Royce Aero Engine system [17]; and the specification of safety-critical medical applications such as the Clinical Neutron Therapy system [18], and the system to train the reaction abilities of patients with severe brain damage [19]. Eventhough it has been claimed that Z is inadequate for the specification of reactive systems [20], recent studies show that this notation can in fact be used to describe the ‘‘dynamic behavior’’ of an application [21,22]. Z is supported by numerous powerful tools such as provers [23,24], animators [25,26], type checkers [27], model-checkers [28], and open environments that provide editing, browsing and analysis capabilities [29]. The work presented in this paper uses the STATEMATE semantics as described in [12]. It is based on the standard Z notation [6]; hence, it can be used with existing Z tools unchanged. This paper is organized as follows: In Section 2 we give an overview of the ViSta tool suite. In Section 3 we describe in detail the Z visualization tool. Finally, in Section 4, we assess our results and discuss related work. 2. System overview ViSta (version 2.3) [10,11] consists of six components: the template wizard, the statechart visualization tool, the statechart graphical editor, the Z visualization tool, the Z editor and the database (see Fig. 1). The tool’s graphical user interface is shown in Fig. 2. It offers five frames. The text frame (shown in the top-left part of Fig. 2) is used to input a textual description of requirements. The template wizard frame (shown in the top-center part of Fig. 2) is used to extract and store information into a set of templates. The
Statechart Graphical Editor
Statechart Visualization Tool Informal Description
AND
Template Wizard OR
OR
Z Visualization Tool
Z Editor Structured Textual Description
schema1
Fig. 1. System overview.
schema 2
Signature 1
Signature 2
Predicate 1
Predicate 2
R. Castello, R. Mili / Information Systems 28 (2003) 753–768
Fig. 2. Tool’s GUI.
755
756
R. Castello, R. Mili / Information Systems 28 (2003) 753–768
structured text frame (shown in the top-right part of Fig. 2) displays the structured textual description that is derived from the information stored in the database. The statechart graphical editor (shown in the bottom-left part of Fig. 2) displays the statechart drawings. Finally, the Z editor (shown in the bottom-right part of Fig. 2) displays the Z specification either in the Latex format or in a box-like structure. The data stored in the database is summarized in a structure that we call decomposition tree. This tree reflects the underlying structure of statecharts (i.e., AND/OR tree). The root of a decomposition tree corresponds to the system superstate; leaves correspond to atomic states. Each node in the tree can be decomposed through the AND or OR decomposition. A node in the decomposition tree includes the following information: its name; its width and height; the coordinates of its origin point; a pointer to its parent; the list of its children; its decomposition type (e.g., AND, OR or LEAF); the list of incoming arcs; the list of outgoing arcs; a list of attributes; and finally its aliases. The information is entered in the database either through the template wizard, the statechart graphical editor or the Z editor. Vista uses this information to automatically update the graphical, formal, textual and template representations. 2.1. The template wizard The template wizard guides the user through the steps necessary for the construction of statechart drawings. It is used when an informal textual description exists, and the user wants ViSta to generate the drawings. The template wizard forces the user to provide specific behavioral information. The user selects information from the informal description and dynamically introduces it into a set of templates. Selected parts turn into a distinct color to inform the user that they were successfully accepted by the templates. A template is a form-based component that has a predefined structure. It consists of structured propositions with text fields to be filled in with information specific to the requirements. The template wizard stores the information in the database and generates a fixed-format structured document (See top-right part of Fig. 2). 2.2. The statechart graphical editor The user may decide to directly draw statecharts using the graphical editor. In the graphical editor, statechart elements are described using item-forms (e.g., state-form, transition-form). When the user selects a graphical icon (e.g., state, transition, or default state) and clicks in the drawing area, an item-form pops up. Fig. 3 shows a state-form. The information captured in the item-forms is immediately stored in the database, and is used by ViSta to generate (or update) the graphical, formal, template and structured descriptions.
Fig. 3. A sample state-form.
R. Castello, R. Mili / Information Systems 28 (2003) 753–768
757
2.3. The statechart visualization tool This tool automatically produces statechart drawings. It offers a framework that improves the readability of the drawings by focusing on some of the most important aesthetic criteria for graph drawing [30], namely, edge-crossing reduction, edge-bend reduction, labeling, and minimization of the drawing area. It is based on several techniques that include hierarchical drawing, labeling, and floorplanning [31]. Hence, the resulting drawings enjoy several properties: they have a low number of edge crossings; they emphasize the natural hierarchical decomposition of states into substates; and they cover an optimal drawing area.
3. Translating statecharts to Z specifications The Z visualization tool translates statecharts to Z specifications. This is achieved by reading the information stored in the database and applying a set of translation rules. The output is either a Latex file that can be passed on to Z/Eves [32] for type checking and theorem proving (see Fig. 4), or a box-like structured specification that is displayed on the Z editor. The editor is used to modify the specification or to enter a new specification from scratch, if a statechart drawing does not exist. The information is
Fig. 4. Latex format.
758
R. Castello, R. Mili / Information Systems 28 (2003) 753–768
automatically stored in the central database, and is used by ViSta to generate/update the statechart and template representations. 3.1. Basic elements of the translation In this section we describe how the concepts of states, decomposition tree and transitions are translated to Z specifications. In our approach, the set of statechart states are represented by the Z set: STATES ::¼ state name1 jstate name2 j? jstate namen State types are defined as STATE TYPE ::¼ ANDjORjLEAF The decomposition tree is represented by the following schema:
In the signature part of the schema three functions are declared. The first function determines the decomposition type of a given state. The second function determines the set of substates of a particular state. The last function is used to define the set of initial states. In the predicate section, we first describe the decomposition type of each state, then we list the set of substates for each state. We proceed by specifying that LEAF nodes do not have substates. Then we list the default substates of all OR states. Finally, we specify that LEAF and AND states do not have initial states. The active states of a system are described by the following specification: ACTIVE STATES TYPE ¼¼ P STATES
R. Castello, R. Mili / Information Systems 28 (2003) 753–768
759
The semantics of AND/OR state decompositions is the following: when the system is in an AND state, this means that the system is in each of its children’s states; whereas when the system is in an OR state this means that the system is in exactly one of its children’s states. Transitions are represented by operation schemas in Z: A transition has an initial state, a final state and a label, which may include an event, a condition, and an action. Hence the following Z specification: EVENTS ACTIONS ::¼ event description1 j?jevent descriptionn j action description1 j?j action descriptionm
The general format for transition schemas reads as follows:
The predicate section specifies that in order for the transition to take place, the source state has to be active, the event has to occur, and the conditions have to be met. Once the transition takes place, an action is executed, and the sets of active states and events are updated. The system’s initial state is specified by mean of an operation schema that lists the system’s initial active states, and sets the sets of active events and actions executed to empty.
760
R. Castello, R. Mili / Information Systems 28 (2003) 753–768
3.2. Algorithm for generating static Z specifications In this section we describe how statecharts are translated to conventional Z specifications. Traditionally, Z specifications describe systems as abstract data types. Hence operations are specified using state before and state after. Our algorithm takes a decomposition tree as an input, and generates a Z specification. It uses the elements described in the previous section, and includes the following steps: 1. 2. 3. 4. 5. 6. 7. 8. 9. 10.
Declare the set type STATES. Declare STATE TYPES. Declare ACTIVE STATES TYPE. Generate the DecompositionTree schema. Generate the System Active States schema. Declare the set type EVENTS ACTIONS. Generate the System Events schema. Generate the System Actions schema. For each transition t; generate the operation schema originState to destinationState: Generate the Initial System Status schema.
In order to illustrate our approach, we use the statechart depicted in Fig. 5, and more precisely its decomposition tree (see Fig. 6). First, we apply steps 1–3 of the algorithm to define the set type STATES; the data definition types STATE TYPES; and ACTIVE STATES TYPE: STATES ::¼ systemjmonitoringjprocessingjidlejexecutingjsetting upj comparingjenable alarmjsensor not connectedj sensor connectedjwaitingjget signal STATE TYPES ::¼ ANDjORjLEAF ACTIVE STATES TYPE ¼¼ P STATES System Monitoring Execute [in(Sensor Connected) ^ store = ok] / start
Executing
Comparing idle Reset / stop
Enable signal out of Alarm limits / Display Message
Setup stop_setup / store = ok setting_up
Processing Sensor Connected connected start
Sensor Not Connected
Get Signal
Waiting not connected
stop
Fig. 5. Statechart example.
R. Castello, R. Mili / Information Systems 28 (2003) 753–768
761
Level 1 (root)
System
AND Monitoring
OR Idle
Executing
Processing
OR setting_up
Sensor_not Sensor Connected Connected
OR comparing
Level 2
enable alarm
OR waiting
Level 3
Level 4
get_signal
Fig. 6. Decomposition tree.
Next, we apply steps 4 and 5 to generate the DecompositionTree schema and the System Active States schema. We obtain the following:
762
R. Castello, R. Mili / Information Systems 28 (2003) 753–768
We proceed with steps 6–9 to generate Z schemas for transitions. We start by declaring the events and actions part. This is achieved by applying steps 6–8. We obtain
Step 9 of the algorithm generates transition schemas. We use the transition from idle to executing to illustrate this step. We get the following:
The first predicate asserts that the initial state idle is an active state. The second predicate asserts that execute is an active event. The condition part of the transition is described in the third predicate; it asserts that the transition can take place if state sensor connected is active, and event store = ok is active. The following predicate describes the result of performing the transition: the action start is executed, and since start is also an event, then it is included in the set of active events. The fifth predicate updates the set of ActiveStates by removing the initial state idle, and adding the final state executing. We notice that state comparing is added to the set of active states. This is due to the fact that, since executing is an active OR state, its initial substate must also be active. Finally, the last predicate updates the set of ActiveEvents by removing the event execute and adding the action start.
R. Castello, R. Mili / Information Systems 28 (2003) 753–768
763
The last step produces the Initial System Status schema.
Because the root of the decomposition tree (i.e., system) is an AND state, its substates monitoring and processing must be included in the set ActiveStates. Furthermore, monitoring and processing are OR-nodes, hence their initial substates (resp. idle and sensor not connected) must also be included in the set ActiveStates. 3.3. Algorithm for generating dynamic Z specifications The static Z specification has to be augmented with a specification that describes the system’s allowable dynamic behavior. We start by declaring schema Transitions as: Transitions¼Transition Schema 1, # Transition Schema 2,? ?,Transition Schemann , Initial System Status The dynamic behaviour of a system is represented by a sequence of valid sets of ActiveStates. We define the sequence type as follows: HISTORY TYPE ¼¼ N1 -ACTIVE STATES TYPE Following Duke and Smith [33], we define a relation between state ‘‘before’’ and state ‘‘after’’ that we call NextState. NextState : ACTIVE STATE TYPE2 ACTIVE STATE TYPE Finally, we specify the system’s valid behavior in terms of its history and relation NextState. We obtain:
764
R. Castello, R. Mili / Information Systems 28 (2003) 753–768
The first predicate defines relation NextState in terms of all possible pairs of state before and state after that result from taking the system’s transitions. Given a possible behavior history of the system (i.e., a sequence of state changes) h; h is valid if it starts with valid initial states, and proceeds with states that can be reached through valid transitions (any two consecutive elements of h belong to NextState). For example, let us partially define relation NextState for the example given in the previous section. We obtain: NextState ¼ fðfsystem; monitoring; processing; idle; sensor not connectedg; fsystem; monitoring; processing; executing; comparing; sensor not connectedgÞ; ðfsystem; monitoring; processing; executing; comparing; sensor not connectedg; fsystem; monitoring; processing; executing; enable alarm; sensor not connectedgÞ; ðfsystem; monitoring; processing; executing; enable alarm sensor not connectedg; fsystem; monitoring; processing; idle; sensor not connectedgÞ; yyg It is easy to notice that h ¼ fð1; fsystem; monitoring; processing; idle; sensor not connectedgÞ; ð2; fsystem; monitoring; processing; executing; comparing; sensor not connectedgÞ; ð3; fsystem; monitoring; processing; executing; enable alarm; sensor not connectedgÞ; yyg is a valid behavior of System: 3.4. The Z editor The Z editor allows the user to edit an existing specification or to enter a new specification from scratch, if a statechart drawing does not exist. This editor offers 13 schema panels. Some of the schemas (e.g., systemActiveStatesSchemaPanel, systemEventsSchemaPanel) are static. Others can be modified. We illustrate some of the features offered by the Z editor through the statesSchemaPanel (See Fig. 7). This panel displays the set of states STATES :¼ state name1 jstate name2 j state name3 j?jstate namen When the STATES label is selected, the user is given the opportunity to add elements to the list, with a pop up add panel. When the user selects an item on the list, the user is given the opportunity to either delete or change the selected item in the statesSchemaPanel list with the help of a pop up edit panel (see Fig. 7). When an element is deleted/changed from the statesSchemaPanel list, the editor, to ensure that the specification is consistent, automatically updates some of the schema panels: the decompositionTreeSchemaPanel is one of them. If an element is deleted from the statesSchemaPanel list, then the corresponding stateType predicate in the decompositionTreeSchemaPanel is deleted. However, if an element is changed in
R. Castello, R. Mili / Information Systems 28 (2003) 753–768
765
Fig. 7. StateSchemaEdit Panel.
the statesSchemaPanel list then the editor changes the corresponding stateType predicate. In the substates predicate list and the defaultState predicate list, if any of the parent’s correspond to the deleted element in the statesSchemaPanel then the entire substates/defaultState predicate will be automatically deleted by the editor. For example, if substates predicate is ‘‘monitoring ¼ idle; :::’’, this entire line will be deleted. However, if one of the children corresponds to the deleted element then only the string ‘‘monitoring’’ is removed from the substates/defaultState predicate. For example, if the substates predicate is ‘‘system ¼ monitoring; processing’’, then only the string ‘‘monitoring’’ is removed from substates predicate by the editor. In case the statesSchemaPanel element ‘‘system’’ is changed to ‘‘system123’’ then any parent or child string in the substates predicate and the defaultState predicate, which is a ‘‘system’’ will be changed to ‘‘system123’’. The TransitionSchemaPanel’s are also updated automatically whenever an element is deleted/changed in the statesSchemaPanel list. If the schemaName of a transitionSchemaPanel starts with or ends with the deleted element the entire TransitionSchemaPanel is deleted. However if an element ‘‘system’’ is changed to ‘‘sytem123’’ in the statesSchemaPanel list then: any schemaName starting with or ending with ‘‘system’’ will be change to ‘‘system123’’; and any occurrence of the string ‘‘system’’ in the initialStatePredicate and the finalStatePredicate will be changed to ‘‘system123’’. The transitionsPanel will also be updated accordingly.
4. Conclusion 4.1. Summary We have developed a tool suite called ViSta that automatically generates statechart drawings based on information extracted from an informal specification. In this paper we presented a plug-in to ViSta, namely the Z visualization tool. This tool translates statecharts to Z specifications. It consists of two modules: the Z translation module and the Z editor. The translation module reads the information stored in the database and generates a static and a dynamic specification. The editor allows the user to display, modify, or input Z specifications in two different formats. The Latex format can be passed on to numerous tools for theorem
766
R. Castello, R. Mili / Information Systems 28 (2003) 753–768
proving, type checking, model checking or animation. The graphical format allows the user to visualize and edit the specification using the traditional box-structured format. The template, statechart, and Z representations are inter-related. This ensures consistency between the different documents, and therefore facilitates the verification and validation effort.
4.2. Related work Several papers have been published on the translation of statechart diagrams to formal specification languages. In [34], Beauvais et al. propose a method to translate statecharts to the equational Signal language; Mikk et al. [35] translate statecharts to PROMELA, the input language of the SPIN verification system; and, Seshia et al. [36] describe a translation from statecharts to ESTEREL. SIGNAL is a synchronous real-time, declarative, and data flow oriented language. It manipulates signals, which are unbounded series of typed values (e.g., integer, logical). The constructs of the language can be used to specify, in an equational style, relations or constraints on clocks, or clock equality between signals. Systems of equations on signals are built using composition. Each part of the translation is represented by a process in SIGNAL. Each process recognize a tick from a global clock, a local clock, a control signal, or a synchronization signal. The translation from Statecharts to Signal is achieved by encoding Statecharts into Signal processes. For each transition, a specific Signal process is instantiated to check if it is triggered. The process receives the initial and target state of the transition as input parameters. It outputs a new state whenever the transition is enabled. This output signal is used to compute the new list of active states. The set of active states in a statechart is handled by a signal ranging on an enumerated type (state) of n different values. Because a state could be refined into substates, a new configuration signal is associated to each non-basic substate. Because the states of Statecharts form a tree, there is a signal tree. The clock calculus of the Signal compiler uses this information to produce Signal code. The clock hierarchy represents state encapsulation. The set of active states is updated by executing a process. States are translated using a set of equations that are composed to produce the complete translation. The basic object in ESTEREL is the signal. Signals are used for communication with the environment as well as for internal communication. The programming unit is the module. A module has an interface that defines its input and output signals and a body that is an executable statement. Input relations can be used to restrict events. At execution time, a module is activated when an event is detected. The module reacts by executing its body and producing its output signals. There is one predefined signal, the tick; which represents the activation clock of the reactive program. Seshia et al. [36] use an annotated AND-OR tree to represent statecharts, and to keep track of information pertinent for the translation, such as: the states an their types; the hierarchy of states; and the transition between states. The translation is done by traversing the AND-OR tree in a top-down manner. The process is as follows: (1) declare all necessary signals, (2) generate a module for each state, and for each transition, (3) generate code for the communication between the statechart, and (4) generate code for history substates. The translation of Statecharts to PROMELA [35] uses temporal logic formulae. Properties can be expressed as linear temporal logic formulae. PROMELA offers a wide range of abstract constructs that are used for the description of reactive systems: parallel processes; global and local data variables; statements to express assignment and conditions; synchronization of parallel processes. The translation process starts by converting statecharts to extended hierarchical automata ðEHAÞ: The semantics of EHA is a Kripke structure K ¼ ðS; s0 ; -STEP Þ; where S is the set of states, s0 is the initial state of K; and -STEP is the transition relation of K: The maximal non conflicting set of enabled transitions constitutes the step of EHA. Mikk et al. provides rules to define -STEP inductively. The next step consists of mapping EHA to PROMELA. The rules are used to generate code for transitions, sequential automata, and the decomposition of states.
R. Castello, R. Mili / Information Systems 28 (2003) 753–768
767
Acknowledgements We would like to thank Haripriya Madabushi from the University of Texas at Dallas for her contribution to this work. Haripriya implemented the Z editor. References [1] [2] [3] [4] [5] [6] [7] [8] [9] [10] [11] [12] [13] [14] [15] [16] [17] [18] [19]
[20] [21] [22] [23] [24] [25] [26] [27] [28] [29] [30] [31] [32] [33]
G. Berry, A quick guide to ESTEREL version 5.10, release 1.0, Technical report, Ecole des Mines and INRIA, February 1997. G.J. Holzmann, Design and Validation of Computer Protocols, Prentice-Hall, Englewood Cliffs, NJ, 1991. G.J. Holzmann, The model checker spin, IEEE Trans. Software Eng. 23 (5) (1997) 279–295. F. Maraninchi, N. Halbwachs, Compiling ARGOS into Boolean equations, in: Lecture Notes in Computer Science, Vol. 1135, Springer, Berlin, 1996, pp. 72–90. A. Benveniste, P.L. Guernic, C. Jacquemot, Synchronous programming with events and relations: the SIGNAL language an its semantics, Sci. Comput. Programming (16) (1991) 103–149. J.M. Spivey, The Z Notation, A reference Manual, Prentice-Hall, Englewood Cliffs, NJ, 1989. Z. Manna, A. Pnueli, The Temporal Logic of Reactive and Concurrent Systems, Springer, Berlin, 1991. D. Hare, Statecharts: A visual formalism for complex systems, Sci. Comput. Programming 8 (3) (1987) 231–274. J. Peterson, Petri nets, ACM Comput. Surv. 9 (3) (1977) 223–252. ! R. Mili, I.G. Tollis, Vista: a tool suite for the visualization of behavioral requirements, Journal of Systems and R. Castello, Software, 62 (2002), 141–159. ! From informal specification to formalization: an automated visualization approach, Ph.D. Thesis, The University of R. Castello, Texas at Dallas, 2000. D. Harel, A. Naamad, The STATEMATE semantics of statecharts, ACM Trans. Software Eng. Meth. 5 (4) (1996) 293–333. A.S. Tools, Real-time studio: the rational alternative, Available from Artisan Software Tools over the Internet, http:// www.artisansw.com/rtdialogue/pdfs/rational.pdf. Accessed on April 1999. Rational Rose java, Downloaded from Rational over the Internet, http://www.rational.com. Accessed on November 1999. R. O’Donnel, B. Waldt, J. Bergstrand, Automatic code for embedded systems based on formal methods, Available from Telelogic over the Internet, http://www.Telelogic.se/solution/techpap.asp. Accessed on April 1999. B27 traffic control system, Available over the Internet, http://www.csr.ncl.ac.uk/projects/FME/InfRes/applications/ fmadb015.html. Accessed on June 2000. Bmw rolls-royce system test facility (stf), Available over the Internet, http://www.csr.ncl.ac.uk/projects/FME/InfRes/ applications/fmadb018.html. Accessed on June 2000. J. Jacky, Specifying a safety-critical control system in Z; IEEE Trans. Software Eng. 21 (2) (1995) 99–106. V. Kasurinen, K. Sere, Integrating action systems and Z in a medical system specification, in: M.-C. Gaudel, J. Woodcock (Eds.), FME’96: Industrial Benefit and Advances in Formal Methods, Lecture Notes in Computer Science, Vol. 1051, Springer, Berlin, 1996, pp. 105–119. L. Lamport, TLZ, in: J.P. Bowen, J.A. Hall (Eds.), Z User Workshop, Cambridge, UK, June 1994, in: Proceedings, Workshops in Computing, Springer, Berlin, 1994, pp. 267–268. A.S. Evans, An improved recipe for specifying reactive systems in Z; in: J.P. Bowen, M.G. Hinchey, D. Till (Eds.), ZUM’97: The Z Formal Specification Notation, Lecture Notes in Computer Science, Vol. 1212, Springer, Berlin, 1997, pp. 275–294. J. Jacky, Analyzing a real-time program with Z; in: J.P. Bowen, M.G. Hinchey, A. Fett (Eds.), ZUM’98: The Z Formal Specification Notation, Lecture Notes in Computer Science, Vol. 1493, Springer, Berlin, 1998, pp. 136–153. Hol-Z, Available over the Internet, http://www.first.gmd.de/santen/HOL-Z/, Accessed on June 2000. Proofpower, Available over the Internet, http://www.lemma-one.demon.co.uk/ProofPower/, Accessed on June 2000. Mathias, Mathematics in Animation Suite, Available from Dr Ron Knott’s Web site over the Internet. http:// web.comlab.ox.ac.uk/oucl/software/fuzz.html, Accessed on June 2000. Possum, Available over the Internet, http://svrc.it.uq.edu.au/Possum/, Accessed on June 2000. J.M. Spivey, FuZZ type checker, Available from The Spivey Partnership over the Internet, http://web.comlab.ox.ac.uk/oucl/ software/fuzz.html, Accessed on June 2000. The SMV Model Checker, Available over the Internet, http://www.cs.cmu.edu/modelcheck/smv.html, Accessed on July 2000. Zeta, Available over the Internet, http://uebb.cs.tu-berlin.de/zeta/, Accessed on June 2000. H. Purchase, Which aesthetic has the greatest effect on human understanding, in: G.D. Battista (Ed.), Graph Drawing (Proceedings GD’97), Lecture Notes in Computer Science, Vol. 1353, Springer, Berlin, 1997, pp. 248–261. ! R. Mili, I.G. Tollis, Automatic layout of statecharts, Software Practice and Experience, Wiley, 32, 2002, pp. 25–55. R. Castello, Z/eves, Available over the Internet, http://www.ora.on.ca/z-eves/, Accessed on August 2000. R. Duke, G. Smith, Temporal logic and Z specifications, Australian Computer Journal 21 (2) (1989) 62–69.
768
R. Castello, R. Mili / Information Systems 28 (2003) 753–768
[34] J. Beauvais, T. Gautier, P.L. Guernic, R. Houdebine, E. Rutten, A translation of statecharts into signal, in: Proceedings of the International Conference on Application of Concurrency to System Design, Aizu-Wakamatsu, Japan, 1998, pp. 52–62. [35] E. Mikk, Y. Lakhnech, M. Siegel, Implementing statecharts in PROMELA/SPIN, in: Proceedings of the Second IEEE Workshop on Industrial Strength Formal Specification Techniques, Boca Raton, FL, 1998, pp. 90–101. [36] S. Seshia, R. Shyamasundar, A. Bhattacharjee, S. Dhodapkar, A translation of statecharts to esterel, in: J.M. Wing, J. Woodcock, J. Davies (Eds.), FM’99—Formal Methods, Lecture Notes in Computer Science, Vol. 1709, Springer, Berlin, 1999, pp. 987–1007.
Visualizing graphical and textual formalisms$ R. Castelloa, R. Milib,* a b
Department of Computer Science, ITESM Campus Chihuahua, H. Colegio Militar 4700, Chihuahua 31300, Mexico Department of Computer Science, The University of Texas at Dallas, Box 830688, Richardson, TX 75083-0688, USA Received 11 May 2002; received in revised form 1 October 2002; accepted 15 October 2002
Abstract ViSta is a tool suite designed to support the requirements specification of reactive systems. It guides the user through the steps necessary for the visualization of statechart diagrams from an informal document. The user first extracts information from a textual document and stores into a set of interactive templates. The information is used by the tool to automatically generate statechart layouts. In this paper we describe how ViSta is augmented with a tool that automatically translates statecharts into Z specifications. The template, statechart and Z representations are interrelated. This ensures consistency between the different representations, and therefore facilitates the verification and validation effort. r 2002 Elsevier Science Ltd. All rights reserved.
1. Introduction Several requirements specification styles for the specification of reactive systems have been proposed in the literature. Informal specifications are the most widely used in the software industry nowadays, mainly because they are ‘‘understandable’’ by domain experts and software engineers, and therefore can be included as part of a software contract. Unfortunately, because of the inherent ambiguity of natural language, these documents are difficult to interpret and maintain. Formal specifications [1–7] on the other hand, make use of mathematical notations that offer precise syntax and semantics. Unfortunately, because of the complexity of the formal description these documents may not be acceptable to many stakeholders. Visual formalisms [8,9] bridge the gap between informal and formal specifications by offering graphical notations with semantics. Unfortunately, hand made diagrams become easily unreadable when the requirements complexity increases. In addition, visual formalisms do not enjoy the powerful verification, code optimization, or model-checking techniques that are common to formal notations. The purpose of this work is to combine the advantages of using visual formalisms for the specification of reactive systems with that of using formal verification and program transformation tools developed for textual formalisms. We have developed a tool suite called ViSta [10,11] that automatically produces statechart layouts based on information extracted from an informal specification. In this paper, we discuss how ViSta is $
Recommended by Prof. Loucopoulos. *Correspondence author. Tel.: +1-972-883-2091; fax: +1-972-883-2349. E-mail addresses: [email protected] (R. Castello), [email protected] (R. Mili).
0306-4379/03/$ - see front matter r 2002 Elsevier Science Ltd. All rights reserved. doi:10.1016/S0306-4379(02)00081-9
R. Castello, R. Mili / Information Systems 28 (2003) 753–768
754
augmented with a tool that automatically translates statecharts to Z specifications. The resulting system allows the specifier to shift focus from organizing the mental or physical structure of requirements to its analysis. In addition, the interdependence between the template, statechart and Z specifications ensures consistency between the different representations, and therefore facilitates the verification and validation effort. Statecharts [8] are extended finite state machines used to describe control aspects of reactive systems. They provide mechanisms to describe synchronization and concurrency, and manage exponential explosion of states by using state decomposition. The statechart notation is supported by numerous tools [12–15]. Z is a formal notation based on set theory and predicate logic. Z has been successfully used for the specification of complex systems. Industrial applications of this notation include the specification of the B27 traffic control system [16]; the specification of the BMW Rolls-Royce Aero Engine system [17]; and the specification of safety-critical medical applications such as the Clinical Neutron Therapy system [18], and the system to train the reaction abilities of patients with severe brain damage [19]. Eventhough it has been claimed that Z is inadequate for the specification of reactive systems [20], recent studies show that this notation can in fact be used to describe the ‘‘dynamic behavior’’ of an application [21,22]. Z is supported by numerous powerful tools such as provers [23,24], animators [25,26], type checkers [27], model-checkers [28], and open environments that provide editing, browsing and analysis capabilities [29]. The work presented in this paper uses the STATEMATE semantics as described in [12]. It is based on the standard Z notation [6]; hence, it can be used with existing Z tools unchanged. This paper is organized as follows: In Section 2 we give an overview of the ViSta tool suite. In Section 3 we describe in detail the Z visualization tool. Finally, in Section 4, we assess our results and discuss related work. 2. System overview ViSta (version 2.3) [10,11] consists of six components: the template wizard, the statechart visualization tool, the statechart graphical editor, the Z visualization tool, the Z editor and the database (see Fig. 1). The tool’s graphical user interface is shown in Fig. 2. It offers five frames. The text frame (shown in the top-left part of Fig. 2) is used to input a textual description of requirements. The template wizard frame (shown in the top-center part of Fig. 2) is used to extract and store information into a set of templates. The
Statechart Graphical Editor
Statechart Visualization Tool Informal Description
AND
Template Wizard OR
OR
Z Visualization Tool
Z Editor Structured Textual Description
schema1
Fig. 1. System overview.
schema 2
Signature 1
Signature 2
Predicate 1
Predicate 2
R. Castello, R. Mili / Information Systems 28 (2003) 753–768
Fig. 2. Tool’s GUI.
755
756
R. Castello, R. Mili / Information Systems 28 (2003) 753–768
structured text frame (shown in the top-right part of Fig. 2) displays the structured textual description that is derived from the information stored in the database. The statechart graphical editor (shown in the bottom-left part of Fig. 2) displays the statechart drawings. Finally, the Z editor (shown in the bottom-right part of Fig. 2) displays the Z specification either in the Latex format or in a box-like structure. The data stored in the database is summarized in a structure that we call decomposition tree. This tree reflects the underlying structure of statecharts (i.e., AND/OR tree). The root of a decomposition tree corresponds to the system superstate; leaves correspond to atomic states. Each node in the tree can be decomposed through the AND or OR decomposition. A node in the decomposition tree includes the following information: its name; its width and height; the coordinates of its origin point; a pointer to its parent; the list of its children; its decomposition type (e.g., AND, OR or LEAF); the list of incoming arcs; the list of outgoing arcs; a list of attributes; and finally its aliases. The information is entered in the database either through the template wizard, the statechart graphical editor or the Z editor. Vista uses this information to automatically update the graphical, formal, textual and template representations. 2.1. The template wizard The template wizard guides the user through the steps necessary for the construction of statechart drawings. It is used when an informal textual description exists, and the user wants ViSta to generate the drawings. The template wizard forces the user to provide specific behavioral information. The user selects information from the informal description and dynamically introduces it into a set of templates. Selected parts turn into a distinct color to inform the user that they were successfully accepted by the templates. A template is a form-based component that has a predefined structure. It consists of structured propositions with text fields to be filled in with information specific to the requirements. The template wizard stores the information in the database and generates a fixed-format structured document (See top-right part of Fig. 2). 2.2. The statechart graphical editor The user may decide to directly draw statecharts using the graphical editor. In the graphical editor, statechart elements are described using item-forms (e.g., state-form, transition-form). When the user selects a graphical icon (e.g., state, transition, or default state) and clicks in the drawing area, an item-form pops up. Fig. 3 shows a state-form. The information captured in the item-forms is immediately stored in the database, and is used by ViSta to generate (or update) the graphical, formal, template and structured descriptions.
Fig. 3. A sample state-form.
R. Castello, R. Mili / Information Systems 28 (2003) 753–768
757
2.3. The statechart visualization tool This tool automatically produces statechart drawings. It offers a framework that improves the readability of the drawings by focusing on some of the most important aesthetic criteria for graph drawing [30], namely, edge-crossing reduction, edge-bend reduction, labeling, and minimization of the drawing area. It is based on several techniques that include hierarchical drawing, labeling, and floorplanning [31]. Hence, the resulting drawings enjoy several properties: they have a low number of edge crossings; they emphasize the natural hierarchical decomposition of states into substates; and they cover an optimal drawing area.
3. Translating statecharts to Z specifications The Z visualization tool translates statecharts to Z specifications. This is achieved by reading the information stored in the database and applying a set of translation rules. The output is either a Latex file that can be passed on to Z/Eves [32] for type checking and theorem proving (see Fig. 4), or a box-like structured specification that is displayed on the Z editor. The editor is used to modify the specification or to enter a new specification from scratch, if a statechart drawing does not exist. The information is
Fig. 4. Latex format.
758
R. Castello, R. Mili / Information Systems 28 (2003) 753–768
automatically stored in the central database, and is used by ViSta to generate/update the statechart and template representations. 3.1. Basic elements of the translation In this section we describe how the concepts of states, decomposition tree and transitions are translated to Z specifications. In our approach, the set of statechart states are represented by the Z set: STATES ::¼ state name1 jstate name2 j? jstate namen State types are defined as STATE TYPE ::¼ ANDjORjLEAF The decomposition tree is represented by the following schema:
In the signature part of the schema three functions are declared. The first function determines the decomposition type of a given state. The second function determines the set of substates of a particular state. The last function is used to define the set of initial states. In the predicate section, we first describe the decomposition type of each state, then we list the set of substates for each state. We proceed by specifying that LEAF nodes do not have substates. Then we list the default substates of all OR states. Finally, we specify that LEAF and AND states do not have initial states. The active states of a system are described by the following specification: ACTIVE STATES TYPE ¼¼ P STATES
R. Castello, R. Mili / Information Systems 28 (2003) 753–768
759
The semantics of AND/OR state decompositions is the following: when the system is in an AND state, this means that the system is in each of its children’s states; whereas when the system is in an OR state this means that the system is in exactly one of its children’s states. Transitions are represented by operation schemas in Z: A transition has an initial state, a final state and a label, which may include an event, a condition, and an action. Hence the following Z specification: EVENTS ACTIONS ::¼ event description1 j?jevent descriptionn j action description1 j?j action descriptionm
The general format for transition schemas reads as follows:
The predicate section specifies that in order for the transition to take place, the source state has to be active, the event has to occur, and the conditions have to be met. Once the transition takes place, an action is executed, and the sets of active states and events are updated. The system’s initial state is specified by mean of an operation schema that lists the system’s initial active states, and sets the sets of active events and actions executed to empty.
760
R. Castello, R. Mili / Information Systems 28 (2003) 753–768
3.2. Algorithm for generating static Z specifications In this section we describe how statecharts are translated to conventional Z specifications. Traditionally, Z specifications describe systems as abstract data types. Hence operations are specified using state before and state after. Our algorithm takes a decomposition tree as an input, and generates a Z specification. It uses the elements described in the previous section, and includes the following steps: 1. 2. 3. 4. 5. 6. 7. 8. 9. 10.
Declare the set type STATES. Declare STATE TYPES. Declare ACTIVE STATES TYPE. Generate the DecompositionTree schema. Generate the System Active States schema. Declare the set type EVENTS ACTIONS. Generate the System Events schema. Generate the System Actions schema. For each transition t; generate the operation schema originState to destinationState: Generate the Initial System Status schema.
In order to illustrate our approach, we use the statechart depicted in Fig. 5, and more precisely its decomposition tree (see Fig. 6). First, we apply steps 1–3 of the algorithm to define the set type STATES; the data definition types STATE TYPES; and ACTIVE STATES TYPE: STATES ::¼ systemjmonitoringjprocessingjidlejexecutingjsetting upj comparingjenable alarmjsensor not connectedj sensor connectedjwaitingjget signal STATE TYPES ::¼ ANDjORjLEAF ACTIVE STATES TYPE ¼¼ P STATES System Monitoring Execute [in(Sensor Connected) ^ store = ok] / start
Executing
Comparing idle Reset / stop
Enable signal out of Alarm limits / Display Message
Setup stop_setup / store = ok setting_up
Processing Sensor Connected connected start
Sensor Not Connected
Get Signal
Waiting not connected
stop
Fig. 5. Statechart example.
R. Castello, R. Mili / Information Systems 28 (2003) 753–768
761
Level 1 (root)
System
AND Monitoring
OR Idle
Executing
Processing
OR setting_up
Sensor_not Sensor Connected Connected
OR comparing
Level 2
enable alarm
OR waiting
Level 3
Level 4
get_signal
Fig. 6. Decomposition tree.
Next, we apply steps 4 and 5 to generate the DecompositionTree schema and the System Active States schema. We obtain the following:
762
R. Castello, R. Mili / Information Systems 28 (2003) 753–768
We proceed with steps 6–9 to generate Z schemas for transitions. We start by declaring the events and actions part. This is achieved by applying steps 6–8. We obtain
Step 9 of the algorithm generates transition schemas. We use the transition from idle to executing to illustrate this step. We get the following:
The first predicate asserts that the initial state idle is an active state. The second predicate asserts that execute is an active event. The condition part of the transition is described in the third predicate; it asserts that the transition can take place if state sensor connected is active, and event store = ok is active. The following predicate describes the result of performing the transition: the action start is executed, and since start is also an event, then it is included in the set of active events. The fifth predicate updates the set of ActiveStates by removing the initial state idle, and adding the final state executing. We notice that state comparing is added to the set of active states. This is due to the fact that, since executing is an active OR state, its initial substate must also be active. Finally, the last predicate updates the set of ActiveEvents by removing the event execute and adding the action start.
R. Castello, R. Mili / Information Systems 28 (2003) 753–768
763
The last step produces the Initial System Status schema.
Because the root of the decomposition tree (i.e., system) is an AND state, its substates monitoring and processing must be included in the set ActiveStates. Furthermore, monitoring and processing are OR-nodes, hence their initial substates (resp. idle and sensor not connected) must also be included in the set ActiveStates. 3.3. Algorithm for generating dynamic Z specifications The static Z specification has to be augmented with a specification that describes the system’s allowable dynamic behavior. We start by declaring schema Transitions as: Transitions¼Transition Schema 1, # Transition Schema 2,? ?,Transition Schemann , Initial System Status The dynamic behaviour of a system is represented by a sequence of valid sets of ActiveStates. We define the sequence type as follows: HISTORY TYPE ¼¼ N1 -ACTIVE STATES TYPE Following Duke and Smith [33], we define a relation between state ‘‘before’’ and state ‘‘after’’ that we call NextState. NextState : ACTIVE STATE TYPE2 ACTIVE STATE TYPE Finally, we specify the system’s valid behavior in terms of its history and relation NextState. We obtain:
764
R. Castello, R. Mili / Information Systems 28 (2003) 753–768
The first predicate defines relation NextState in terms of all possible pairs of state before and state after that result from taking the system’s transitions. Given a possible behavior history of the system (i.e., a sequence of state changes) h; h is valid if it starts with valid initial states, and proceeds with states that can be reached through valid transitions (any two consecutive elements of h belong to NextState). For example, let us partially define relation NextState for the example given in the previous section. We obtain: NextState ¼ fðfsystem; monitoring; processing; idle; sensor not connectedg; fsystem; monitoring; processing; executing; comparing; sensor not connectedgÞ; ðfsystem; monitoring; processing; executing; comparing; sensor not connectedg; fsystem; monitoring; processing; executing; enable alarm; sensor not connectedgÞ; ðfsystem; monitoring; processing; executing; enable alarm sensor not connectedg; fsystem; monitoring; processing; idle; sensor not connectedgÞ; yyg It is easy to notice that h ¼ fð1; fsystem; monitoring; processing; idle; sensor not connectedgÞ; ð2; fsystem; monitoring; processing; executing; comparing; sensor not connectedgÞ; ð3; fsystem; monitoring; processing; executing; enable alarm; sensor not connectedgÞ; yyg is a valid behavior of System: 3.4. The Z editor The Z editor allows the user to edit an existing specification or to enter a new specification from scratch, if a statechart drawing does not exist. This editor offers 13 schema panels. Some of the schemas (e.g., systemActiveStatesSchemaPanel, systemEventsSchemaPanel) are static. Others can be modified. We illustrate some of the features offered by the Z editor through the statesSchemaPanel (See Fig. 7). This panel displays the set of states STATES :¼ state name1 jstate name2 j state name3 j?jstate namen When the STATES label is selected, the user is given the opportunity to add elements to the list, with a pop up add panel. When the user selects an item on the list, the user is given the opportunity to either delete or change the selected item in the statesSchemaPanel list with the help of a pop up edit panel (see Fig. 7). When an element is deleted/changed from the statesSchemaPanel list, the editor, to ensure that the specification is consistent, automatically updates some of the schema panels: the decompositionTreeSchemaPanel is one of them. If an element is deleted from the statesSchemaPanel list, then the corresponding stateType predicate in the decompositionTreeSchemaPanel is deleted. However, if an element is changed in
R. Castello, R. Mili / Information Systems 28 (2003) 753–768
765
Fig. 7. StateSchemaEdit Panel.
the statesSchemaPanel list then the editor changes the corresponding stateType predicate. In the substates predicate list and the defaultState predicate list, if any of the parent’s correspond to the deleted element in the statesSchemaPanel then the entire substates/defaultState predicate will be automatically deleted by the editor. For example, if substates predicate is ‘‘monitoring ¼ idle; :::’’, this entire line will be deleted. However, if one of the children corresponds to the deleted element then only the string ‘‘monitoring’’ is removed from the substates/defaultState predicate. For example, if the substates predicate is ‘‘system ¼ monitoring; processing’’, then only the string ‘‘monitoring’’ is removed from substates predicate by the editor. In case the statesSchemaPanel element ‘‘system’’ is changed to ‘‘system123’’ then any parent or child string in the substates predicate and the defaultState predicate, which is a ‘‘system’’ will be changed to ‘‘system123’’. The TransitionSchemaPanel’s are also updated automatically whenever an element is deleted/changed in the statesSchemaPanel list. If the schemaName of a transitionSchemaPanel starts with or ends with the deleted element the entire TransitionSchemaPanel is deleted. However if an element ‘‘system’’ is changed to ‘‘sytem123’’ in the statesSchemaPanel list then: any schemaName starting with or ending with ‘‘system’’ will be change to ‘‘system123’’; and any occurrence of the string ‘‘system’’ in the initialStatePredicate and the finalStatePredicate will be changed to ‘‘system123’’. The transitionsPanel will also be updated accordingly.
4. Conclusion 4.1. Summary We have developed a tool suite called ViSta that automatically generates statechart drawings based on information extracted from an informal specification. In this paper we presented a plug-in to ViSta, namely the Z visualization tool. This tool translates statecharts to Z specifications. It consists of two modules: the Z translation module and the Z editor. The translation module reads the information stored in the database and generates a static and a dynamic specification. The editor allows the user to display, modify, or input Z specifications in two different formats. The Latex format can be passed on to numerous tools for theorem
766
R. Castello, R. Mili / Information Systems 28 (2003) 753–768
proving, type checking, model checking or animation. The graphical format allows the user to visualize and edit the specification using the traditional box-structured format. The template, statechart, and Z representations are inter-related. This ensures consistency between the different documents, and therefore facilitates the verification and validation effort.
4.2. Related work Several papers have been published on the translation of statechart diagrams to formal specification languages. In [34], Beauvais et al. propose a method to translate statecharts to the equational Signal language; Mikk et al. [35] translate statecharts to PROMELA, the input language of the SPIN verification system; and, Seshia et al. [36] describe a translation from statecharts to ESTEREL. SIGNAL is a synchronous real-time, declarative, and data flow oriented language. It manipulates signals, which are unbounded series of typed values (e.g., integer, logical). The constructs of the language can be used to specify, in an equational style, relations or constraints on clocks, or clock equality between signals. Systems of equations on signals are built using composition. Each part of the translation is represented by a process in SIGNAL. Each process recognize a tick from a global clock, a local clock, a control signal, or a synchronization signal. The translation from Statecharts to Signal is achieved by encoding Statecharts into Signal processes. For each transition, a specific Signal process is instantiated to check if it is triggered. The process receives the initial and target state of the transition as input parameters. It outputs a new state whenever the transition is enabled. This output signal is used to compute the new list of active states. The set of active states in a statechart is handled by a signal ranging on an enumerated type (state) of n different values. Because a state could be refined into substates, a new configuration signal is associated to each non-basic substate. Because the states of Statecharts form a tree, there is a signal tree. The clock calculus of the Signal compiler uses this information to produce Signal code. The clock hierarchy represents state encapsulation. The set of active states is updated by executing a process. States are translated using a set of equations that are composed to produce the complete translation. The basic object in ESTEREL is the signal. Signals are used for communication with the environment as well as for internal communication. The programming unit is the module. A module has an interface that defines its input and output signals and a body that is an executable statement. Input relations can be used to restrict events. At execution time, a module is activated when an event is detected. The module reacts by executing its body and producing its output signals. There is one predefined signal, the tick; which represents the activation clock of the reactive program. Seshia et al. [36] use an annotated AND-OR tree to represent statecharts, and to keep track of information pertinent for the translation, such as: the states an their types; the hierarchy of states; and the transition between states. The translation is done by traversing the AND-OR tree in a top-down manner. The process is as follows: (1) declare all necessary signals, (2) generate a module for each state, and for each transition, (3) generate code for the communication between the statechart, and (4) generate code for history substates. The translation of Statecharts to PROMELA [35] uses temporal logic formulae. Properties can be expressed as linear temporal logic formulae. PROMELA offers a wide range of abstract constructs that are used for the description of reactive systems: parallel processes; global and local data variables; statements to express assignment and conditions; synchronization of parallel processes. The translation process starts by converting statecharts to extended hierarchical automata ðEHAÞ: The semantics of EHA is a Kripke structure K ¼ ðS; s0 ; -STEP Þ; where S is the set of states, s0 is the initial state of K; and -STEP is the transition relation of K: The maximal non conflicting set of enabled transitions constitutes the step of EHA. Mikk et al. provides rules to define -STEP inductively. The next step consists of mapping EHA to PROMELA. The rules are used to generate code for transitions, sequential automata, and the decomposition of states.
R. Castello, R. Mili / Information Systems 28 (2003) 753–768
767
Acknowledgements We would like to thank Haripriya Madabushi from the University of Texas at Dallas for her contribution to this work. Haripriya implemented the Z editor. References [1] [2] [3] [4] [5] [6] [7] [8] [9] [10] [11] [12] [13] [14] [15] [16] [17] [18] [19]
[20] [21] [22] [23] [24] [25] [26] [27] [28] [29] [30] [31] [32] [33]
G. Berry, A quick guide to ESTEREL version 5.10, release 1.0, Technical report, Ecole des Mines and INRIA, February 1997. G.J. Holzmann, Design and Validation of Computer Protocols, Prentice-Hall, Englewood Cliffs, NJ, 1991. G.J. Holzmann, The model checker spin, IEEE Trans. Software Eng. 23 (5) (1997) 279–295. F. Maraninchi, N. Halbwachs, Compiling ARGOS into Boolean equations, in: Lecture Notes in Computer Science, Vol. 1135, Springer, Berlin, 1996, pp. 72–90. A. Benveniste, P.L. Guernic, C. Jacquemot, Synchronous programming with events and relations: the SIGNAL language an its semantics, Sci. Comput. Programming (16) (1991) 103–149. J.M. Spivey, The Z Notation, A reference Manual, Prentice-Hall, Englewood Cliffs, NJ, 1989. Z. Manna, A. Pnueli, The Temporal Logic of Reactive and Concurrent Systems, Springer, Berlin, 1991. D. Hare, Statecharts: A visual formalism for complex systems, Sci. Comput. Programming 8 (3) (1987) 231–274. J. Peterson, Petri nets, ACM Comput. Surv. 9 (3) (1977) 223–252. ! R. Mili, I.G. Tollis, Vista: a tool suite for the visualization of behavioral requirements, Journal of Systems and R. Castello, Software, 62 (2002), 141–159. ! From informal specification to formalization: an automated visualization approach, Ph.D. Thesis, The University of R. Castello, Texas at Dallas, 2000. D. Harel, A. Naamad, The STATEMATE semantics of statecharts, ACM Trans. Software Eng. Meth. 5 (4) (1996) 293–333. A.S. Tools, Real-time studio: the rational alternative, Available from Artisan Software Tools over the Internet, http:// www.artisansw.com/rtdialogue/pdfs/rational.pdf. Accessed on April 1999. Rational Rose java, Downloaded from Rational over the Internet, http://www.rational.com. Accessed on November 1999. R. O’Donnel, B. Waldt, J. Bergstrand, Automatic code for embedded systems based on formal methods, Available from Telelogic over the Internet, http://www.Telelogic.se/solution/techpap.asp. Accessed on April 1999. B27 traffic control system, Available over the Internet, http://www.csr.ncl.ac.uk/projects/FME/InfRes/applications/ fmadb015.html. Accessed on June 2000. Bmw rolls-royce system test facility (stf), Available over the Internet, http://www.csr.ncl.ac.uk/projects/FME/InfRes/ applications/fmadb018.html. Accessed on June 2000. J. Jacky, Specifying a safety-critical control system in Z; IEEE Trans. Software Eng. 21 (2) (1995) 99–106. V. Kasurinen, K. Sere, Integrating action systems and Z in a medical system specification, in: M.-C. Gaudel, J. Woodcock (Eds.), FME’96: Industrial Benefit and Advances in Formal Methods, Lecture Notes in Computer Science, Vol. 1051, Springer, Berlin, 1996, pp. 105–119. L. Lamport, TLZ, in: J.P. Bowen, J.A. Hall (Eds.), Z User Workshop, Cambridge, UK, June 1994, in: Proceedings, Workshops in Computing, Springer, Berlin, 1994, pp. 267–268. A.S. Evans, An improved recipe for specifying reactive systems in Z; in: J.P. Bowen, M.G. Hinchey, D. Till (Eds.), ZUM’97: The Z Formal Specification Notation, Lecture Notes in Computer Science, Vol. 1212, Springer, Berlin, 1997, pp. 275–294. J. Jacky, Analyzing a real-time program with Z; in: J.P. Bowen, M.G. Hinchey, A. Fett (Eds.), ZUM’98: The Z Formal Specification Notation, Lecture Notes in Computer Science, Vol. 1493, Springer, Berlin, 1998, pp. 136–153. Hol-Z, Available over the Internet, http://www.first.gmd.de/santen/HOL-Z/, Accessed on June 2000. Proofpower, Available over the Internet, http://www.lemma-one.demon.co.uk/ProofPower/, Accessed on June 2000. Mathias, Mathematics in Animation Suite, Available from Dr Ron Knott’s Web site over the Internet. http:// web.comlab.ox.ac.uk/oucl/software/fuzz.html, Accessed on June 2000. Possum, Available over the Internet, http://svrc.it.uq.edu.au/Possum/, Accessed on June 2000. J.M. Spivey, FuZZ type checker, Available from The Spivey Partnership over the Internet, http://web.comlab.ox.ac.uk/oucl/ software/fuzz.html, Accessed on June 2000. The SMV Model Checker, Available over the Internet, http://www.cs.cmu.edu/modelcheck/smv.html, Accessed on July 2000. Zeta, Available over the Internet, http://uebb.cs.tu-berlin.de/zeta/, Accessed on June 2000. H. Purchase, Which aesthetic has the greatest effect on human understanding, in: G.D. Battista (Ed.), Graph Drawing (Proceedings GD’97), Lecture Notes in Computer Science, Vol. 1353, Springer, Berlin, 1997, pp. 248–261. ! R. Mili, I.G. Tollis, Automatic layout of statecharts, Software Practice and Experience, Wiley, 32, 2002, pp. 25–55. R. Castello, Z/eves, Available over the Internet, http://www.ora.on.ca/z-eves/, Accessed on August 2000. R. Duke, G. Smith, Temporal logic and Z specifications, Australian Computer Journal 21 (2) (1989) 62–69.
768
R. Castello, R. Mili / Information Systems 28 (2003) 753–768
[34] J. Beauvais, T. Gautier, P.L. Guernic, R. Houdebine, E. Rutten, A translation of statecharts into signal, in: Proceedings of the International Conference on Application of Concurrency to System Design, Aizu-Wakamatsu, Japan, 1998, pp. 52–62. [35] E. Mikk, Y. Lakhnech, M. Siegel, Implementing statecharts in PROMELA/SPIN, in: Proceedings of the Second IEEE Workshop on Industrial Strength Formal Specification Techniques, Boca Raton, FL, 1998, pp. 90–101. [36] S. Seshia, R. Shyamasundar, A. Bhattacharjee, S. Dhodapkar, A translation of statecharts to esterel, in: J.M. Wing, J. Woodcock, J. Davies (Eds.), FM’99—Formal Methods, Lecture Notes in Computer Science, Vol. 1709, Springer, Berlin, 1999, pp. 987–1007.