Automatic Code Generation From a High-Level Petri Net ... - CiteSeerX

Automatic Code Generation From a High-Level Petri Net Based Specification of Dialogue Philippe A. Palanque, Rémi Bastide, Valérie Sengès L.I.S., Université Toulouse I Place Anatole France, 31042 Toulouse Cedex, France {palanque, bastide, senges}@cix.cict.fr

Abstract. This paper shows how the code for the user interface part of an interactive application can be automatically generated from an object-oriented specification formalism based on high-level Petri nets. The technique described here is very general and may be applied with any event-driven UIMS. The paper first describes the formalism called Interactive Cooperative Objects (ICO). It then presents a simple case study and details the techniques involved in the code generation process by applying them to this case study. Keywords. Formal methods, mathematical analysis, code generation

1.

Introduction

Nowadays, the vast majority of new software applications feature a WIMP (Windows Icons, Menu, Pointing) style interface. The underlying programming model of this kind of interface is event-driven in the meaning that the evolution of the application is triggered by user actions. In spite of the widespread use of such interfaces, the handling of their most important aspect (the structure of the man-machine dialogue) is still a research topic and has not yet found a proper answer, at least in the commercial products. In those tools, the focus is most often put on the definition of the external look of the interface, with the help of several very good interface presentation editors, and the definition of the internal behavior is generally left to the programmer. Several formal notations (such as grammars or finite state automata) translate easily into the event model [Green 86] needed for implementing the application using usual UIMSes. Unfortunately these notations have shown their limitations in the field of the specification of this kind of interfaces. The reactive nature of event-driven interfaces often leads to huge models hard to build, to manage and to verify mathematically. The reason is that such notations model the user as a parsable sequential file whereas the user is essentially unpredictable [Coutaz 87] and may be involved in several concurrent tasks at a time. In order to tackle those problems, some new formalisms have appeared. However, those formalisms either have a more general purpose and are not meant to be implemented [Fields 93, Abowd 91] or can only be implemented in a special language directly supporting the notation [Paterno 93], thus hampering their use for conventional software development. We have already proposed a formalism based on Petri nets and objects, allowing to describe the dialogue structure of event-driven interfaces. The first presentation [Bastide 90] mainly focused on the use of this formalism for specification, another paper [Palanque 93a] being devoted to the design methodology. This formalism, called Interactive

Cooperative Objects (ICO) is mathematically founded, and allows for a formal verification of the models [Palanque 93b]. The present paper aims at describing the techniques involved in the automatic generation of code for the event-handlers from the formal specification in our formalism. The generation of code is achieved by using the techniques provided by the Petri nets theory. Section II presents the ICO formalism, in which a high-level Petri net model is used for modeling the object's behavior. Section III uses a case study to demonstrate the use of the formalism. Section IV details the techniques involved in the automatic code generation and applies these techniques to the case study.

2.

Interactive Cooperative Objects

The ICO formalism is an object-oriented language specially designed for the modeling and implementation of event-driven interfaces [Palanque 93a, Bastide 90]. In this language, an object is an entity featuring four components: data structure, operations, presentation and behavior. The data structure of an object is a set of attributes, each of them having a name and a type. This type is either a simple type or an object class. Objects communicate according to a client-server relationship, and an object offers to its environment a set of operations called services. The ObCS (Object Control Structure) of an object fully defines its behavior: the availability of its services, but also how it processes service requests, the operations it performs on its own behalf, and the services it requires from other objects as a client. The ObCS of an ICO is defined by a high-level Petri net. Each service of an object is associated with one or several transitions in the ObCS. A service request may be accepted only when one of its associated transitions is enabled, and it is performed by the occurrence of such a transition. Graphically, the name of the service associated with a transition is written inside it in bold-faced type, while the input (resp. output) parameters of a service label a broken arrow incoming to (resp. outgoing from) the transition. The services of an ICO which are at the user’s disposal, called user services, are pointed out by a small ellipse at the beginning of the incoming broken arrow. An ObCS may include transitions which are not associated with any service: they correspond to the object's spontaneous activity. The presentation of an object states its external look. This presentation is a structured set of widgets. The user-system interaction will only take place through those components. Each user action on a widget may trigger one of the ICO's user service, and the user services of an ICO are precisely the ones which may be activated by the user through a widget. The relation between user services and widgets is fully stated by the activation function which associates with each couple (widget, user action) the service to be triggered. When modeling a window by an ICO, the sequencing and synchronization constraints for the availability of the services offered to the user are expressed in the ObCS. Transitions relate to the object's services, stating their availability, and user services relate to widgets through the activation function. Thus the active or inactive state of the widgets may be known by looking at the ObCS' marking: the fact that no transition associated with a service is enabled by the current marking means that this service is not currently available to the user. This must be shown by graying out or otherwise inactivating the related widgets.

3. Modeling an Application In this section we will show how to model a database browsing application by following a stepwise design process. A window is modeled by an ICO, as for example the window shown in Figure 1; its presentation defines the window’s layout, and its ObCS the window’s dialogue. First, we present the informal user interface specification of the application. Next, we detail the non-interactive objects that are interface independent. Then, we define the ICO of the window displayed to the users. 3.1. Informal Specification The example chosen to illustrate the use of the formalism is a fairly common one: an editor for tuples in a relational database table whose attributes are (Identifier, X, Y). This editor allows adding new tuples into the database, deleting tuples, selecting tuples from those already stored and changing their values. Of course, our goal is to provide a fully user-driven dialogue, as opposed to a menu-driven one.

Identifier :

Fig. 1. Overall look of the window

The overall look of the interface is shown in Figure 1. Three different areas can be distinguished in that window: • The editing area, in which the attributes of a selected tuple may be edited through the use of standard interface components (radio buttons, check box, simple-line entry field). • A scrollable list (list box) shows the tuples of the table, presenting them by their distinctive attribute (a primary key). Items in this list may be selected by clicking on them with the mouse. • A command zone in which database operations (creation, deletion, ...) may be launched by clicking on command pushbuttons. The actions available to the user change through time and depend on the state of the dialogue. Those dialogue rules are expressed here informally. One of the goals of the ICO

modeling is to make formal and non-ambiguous such natural language informal requirements: • It is forbidden to Select a tuple from the table when another one is being edited. • It is forbidden to Quit the application while the user is editing a tuple. In any other case it must be possible to quit. • It is forbidden to Delete a tuple whose value has been modified by the user. • After a modification of the current tuple, only the actions Add, Replace and Reset are available. • The user must be able to act on the items of the editing area at any time. • Only tuples that satisfy the integrity constraints may be added to the database. 3.2. Non Interactive Objects: Tuples Class Tuple Attributes ident : Identifier; -- The tuple's key X : 1..3; -- The other attributes Y : Boolean; Services Display; -- Display the attributes in the editing area Add; -- Add the tuple to the database table. Copy :; -- Creates a new object identical to the current one Correct:;-- Does the tuple satisfy the integrity constraints? Delete; -- Delete the tuple Fig. 2. The class Tuple

Our case study yields two object classes: class Tuple, which corresponds to the noninteractive application kernel, and class Editor, which is modeled by an ICO. The class Tuple is detailed in Figure 2. The instances of this class are passive entities, used only as a data structure, they thus do not feature an ObCS (to be more precise, the ObCS is trivial: each service is available at all moments). 3.3. Modeling the Tuple Editor The class Editor is a full fledged ICO, featuring attributes, services, an ObCS and a presentation part. The description of the class, specifying the first two components, may be seen in Figure 3. The ObCS is shown in Figure 4, while the presentation, which consists of the widget list and the activation function, is detailed in Figure 5. Class Editor Attributes -- none Services Reset; Replace; Edit; Delete; Quit; Add; ObCS (see Figure 4) Presentation (see Figure 1 and Figure 5) end Fig. 3. The class Editor

The dialogue is modeled by a Petri net with objects (PNO). This provides a concise, yet formal and complete specification for the control structure of the application. The modeling power of the formalism allows to describe a lot of constraints, otherwise hard to describe in natural language. A transition of a PNO may occur if each of its input places holds at least one token, so that each variable labeling an input arc may be bound to an object. When a transition occurs, the objects bound to input variables are removed from the input places and their values are processed by the transition's action, which may also generate or delete objects. The new or modified objects are finally put into the output places. The PNO of the Editor's ObCS (Figure 4) is read in the following way: • Initialization: The initial marking of the ObCS' net depends on the actual contents of the database at the time the window is opened (when the ICO is created). Figure 4 shows an initial marking: the places list, selected and edited are empty, and the place default contains the template for the first item to be edited. If the table was not empty, one tuple would be automatically selected while all the others would be in the place list.

Edited

quit T9







d.correct add d.add

T8

edit



d.correct T6

T7

reset o.display







key = o.ident



select

T10

o.display

T5

replace o.delete; d.add;

edit d := o.copy

T4



Selected

T2



o.correct add o.add

Default

List

o.correct Default

T11

delete x.delete o.display

delete x.delete o.create o.display



Precondition Place with an initial marking

T1

edit

Edited : ; Type of places Selected, List, Default: ;

Fig. 4. The ObCS of the class Editor

T3



T1 edit

arc with variable Transition T1 related to the Edit service Inhibitor arc

• Processing From this initial state, only the two services edit and add (or transitions T1 and T2) may occur. The occurrence of the edit service removes the template token from the place default, modifies its value and puts it back into the same place. The occurrence of the add service depends on the precondition o.correct, which checks the integrity constraints on the object, eventually producing a modal error dialogue. If the precondition holds, the token is moved from the place default to the place selected. From now on, the table has one tuple. As the place selected is the only one holding a token, only the edit and delete services may occur. The occurrence of the delete service puts the PNO back in its initial state. The inhibitor arc between the place List and the delete service of the transition T3 means that this transition may only occur if the place is empty. The occurrence of the edit service results in creating a local copy of the tuple and depositing the original (o) and the copy (dup) in the place edited. While the place edited holds a token, several services may occur: • Modify the value of the copy by the occurrence of the service edit. • Replace the original by the copy through the service replace. • Cancel all changes by the occurrence of the service reset (the copy is then deleted). • Add the edited tuple to the table; the added tuple becomes selected, while the original one becomes unselected. If this edit / add cycle is performed a number of times, we will reach the state corresponding to Figure 1 where the place selected is empty, the place edited holds one token - a tuple whose identifier value is “Item 04” -, and the place list contains at least tokens corresponding to tuples items 02, 03, 05 and 06. This picture shows three activated pushbuttons, which correspond to the currently allowed user operations on the database. The active or inactive state of the pushbuttons is fully determined by the possible occurrence of the transitions they relate to in the ObCS. For example, the delete button is not activated, since place selected holds no token. Figure 5 shows both the list of widgets associated with an Editor and how the user can request a user service. All the widgets of the editing area trigger the Edit service since their purpose is only to inform the dialogue that an editing action has been performed. Widget PushButtonAdd PushButtonDelete PushButtonReplace PushButtonReset PushButtonClose_Box RadioButton1 RadioButton2 RadioButton3 EntryText CheckBox ListBox

User's action Click Click Click Click Click Click Click Click Keyboard Click Click

Activated service Add Delete Replace Reset Quit Edit Edit Edit Edit Edit Select

Fig. 5. The activation function

4. Automatic code generation The process for generating the application code from its formal ICO specification is pictured on Figure 6. ObCS of the ICOS

Marking tree

Marking graph

Transformation of the OBCS

ATN

State / Transition matrix

State / Service matrix

Application code

Code Generation

Fig. 6. Steps of the automatic code generation process

The process is divided into two main stages: The first one aims at transforming the ObCS into several intermediate representations, while the second aims at producing the code of the application. The first stage of the automatic code generation process is the transformation of the ObCS into an augmented transition network. The second stage processes the state / transition matrix, which is an equivalent description of the ATN. This matrix is correlated with the activation function, which relates the widgets to the actions to be performed. From these two components, the generation of the event-handlers for the widgets is quite simple, and essentially follows the process described in [Green 86]. 4.1. Transformation of the ObCS into an ATN The techniques to calculate an ATN from a Petri net based description have been extensively studied [Wood 70, Peterson 81]. 4.1.1. Calculation of the marking tree The marking tree of a Petri net provided with an initial marking explicitly details the set of reachable states from this initial marking, as well as the sequences of transitions needed to reach those states. Each node in this tree represents a reachable marking of the net, and each arc is labeled with the name of the transition which causes the corresponding change to the marking. In many cases, the set of reachable markings is infinite, and the

marking tree is thus also infinite. This infinite tree may be reduced to a finite structure called the covering tree of the net. 4.1.2. Calculation of the marking graph The marking graph of a Petri net is a state transition diagram whose behavior is strictly equivalent to that of the marked Petri net. The marking graph is easily deduced from the marking tree. The nodes of the marking tree which are associated with an identical marking are collapsed into a single node. Each node of the marking graph corresponds to a state of the dialogue. The marking graph is usually used to prove properties of the net that are dependent on its initial marking. 4.1.3. Calculation of the ATN Edit

state 1

Quit

state 4

Delete //n=0 Add

Delete/n--/ n>0

Quit

state 2

Select // n>0

Edit Add / n++

Reset

States correspond to the following markings of places (default, selected, edited, list): state 1 : (1, 0, 0, 0) state 2 : (0, 1, 0, ω ) state 3 : (0, 0, 1, ω ) state 4 : (0, 0, 0, ω ) Registers n : number of tokens in the list place

Replace

Edit

state 3

Fig. 7. The ATN of the Editor

The marking graph automatically produced from the ObCS of an ICO cannot be represented by a finite state automaton, but it can be by an augmented transition network (ATN) [Woods 70]. In the graphic representation of an ATN, states are depicted by ellipses (the initial state being thick lined) and transitions by arcs. The arc of a transition is labeled by: the service / the assignments, if any/ the preconditions, if any, as shown in Figure 7. An ATN is essentially a finite state automaton provided with a set of registers which may be checked and modified when a changing of state occurs. Thus, an ATN whose set of register is empty is a Finite State Automaton. This ATN is built from the covering graph of the ObCS. Only the states from which a transition associated with a service may occur are kept, and there is one register for each unbounded place of the ObCS (a place for which the number of tokens has no upper limit) being an input place of such a transition (the algorithm is given in [Palanque 92]). Figure 7 shows the ATN of the Editor, and thus the command language at the user’s disposal.

State_1

State_2

State_3

T1

T2

state_1 o.correct o.add state_2 n=0 x.delete ; o.create ; o.display state_1

T3

T4

dup.clone(o) ; state_3 dup.correct o.delete;dup.add; state_2 dup.correct n ++ ; dup.add ; state_2

T5

T6

T7

o.display ; state_2

T8 state_3 T9 state_fin T10

T11

state_fin key = o.ident ∧ n>0 o.display state_2 n>0 n -- ; x.delete ; o.display ; state_2

Fig. 8. The state-transition matrix generated from the ObCS of the Editor

Although the ATN in Figure 7 may appear simpler than the original ObCS, we are convinced that the ObCS is actually simpler to design than the ATN. Indeed, for a complex dialogue, the most intricate parts to manage in the ATN construction are the

definition and the handling of the registers. These complex tasks may be avoided by the building of the ObCS. Moreover, the Petri net description allows for an easy description of the parallel dialogue and synchronization that are needed in multi-threaded applications and are especially difficult to model in a sequential formalism such as ATN. 4.1.4. Construction of the state-transition matrix An ATN may be described by a matrix, a representation which makes it easier to process by computer programs. This matrix is constructed in the following way: • Each transition in the ATN is associated with a line in the matrix. • Each state in the ATN is associated with a column in the matrix. • Each cell in the matrix is divided into three components: The first one represents the conditions imposed on the triggering of the transition. These conditions may come from preconditions in the original ObCS transition, or may concern the value of one of the ATN registers. The second component of a cell represents the action to be performed when the transition occurs. This action is deduced both from the action in the original ObCS transition and from the modifications to be applied to the value of the ATN registers. The third component describes the state reached after the occurrence of the transition. The state-transition matrix generated from the ObCS of the example is shown on Figure 8. 4.1.5. Construction of a state-service matrix: In the state-transition matrix each line concerns one transition. As it is possible for a service to be related to several transitions it is possible for the matrix to contain several lines related to the same service. For example, the service Add is associated with transitions T2 and T4 (see Figure 4). The state-service matrix is constructed by merging all the lines related to a same service into one single line. 4.2. Code Generation The steps we have described so far are independent of any given UIMS. Of course the details of the final step, which is the actual code generation, depend heavily on the UIMS at hand and on the Application Programming Interface (API) it supports. The activation function is used to generate the part of the application code that aims at dispatching the incoming events to the right event handlers. In some UIMSs (such as the C language interface to the MS-Windows toolkit), this is done by explicitly generating a complex switch statement, where the first dispatching is done according to the identifier of the widget which has received the event, and the second dispatching is done according to the type of event received. With higher level APIs, this dispatching is often hidden to the programmer, and implemented with more powerful language constructs. This may be done for example by associating a widget identifier to a virtual member function in a class representing the window (such as in the Borland C++ ObjectWindows API), or the dispatching process may be at the very basis of the programming environment (such as in Microsoft Visual Basic), and thus totally transparent to the programmer. In any case, the activation function holds sufficient information to automatically generate the dispatching code. From the components that have been produced so far, it is possible to generate the code of the application.

4.2.1. Production of the procedures associated with the services: A callback procedure is automatically generated for each service. All the procedures to be generated have the same framework : a procedure is basically a switch structure according to the set of possible values for the state variable (corresponding to the columns of the state-service matrix). Each switch is filled in with the contents of a corresponding cell of the state-service matrix. Each branch of the switch will consist in four parts, the first three of which are directly extracted from the subcells of the corresponding cell in the matrix. The first part is a pre-condition test, the second one holds the semantic action, and the third one sets the state reached after the occurrence of the service. The fourth part of the branch corresponds to the visual feedback of the newly reached state. This part results in visually showing which user actions are enabled in the newly reached state. The necessary enabling and disabling actions are calculated from the state-service matrix and the activation function. The services for which the cell corresponding to the new state is empty have all their associated widget disabled. As an example, the callback procedure associated wih the add service is described in Figure 9 and clearly shows the four parts. 4.2.2. Setup of the event handlers: Callback procedure ADD; Switch (CurrentState) { // test of the state variable case state1 : // no pre-condition to test // semantic action o.add // add the tuple o to the table // state changing CurrentSate = State2 // change the current state // feedback of the commands available in the new state disable(PushButtonAdd) disable(PushButtonReset) disable(PushButtonReplace) enable(PushButtonClose_Box) enable(PushButtonDelete) enable(ListBox) case state2 : // no action, PushButtonAdd is always disabled when the system is in State2 case state3 : o.add // add the tuple o to the table CurrentSate = State2 // change the current state n++ // increment the register representing the number of tuples in the table // show the commands available in new state disable(PushButtonAdd) disable(PushButtonReset) disable(PushButtonReplace) enable(PushButtonClose_Box) enable(PushButtonDelete) enable(ListBox) } Fig. 9. Callback procedure automatically generated for the service Add

The final step to produce a runnable application is to associate an automatically generated procedure with a couple (widget, user-action). The details of this process depend completely on the API of development environment, and thus are not detailed here, but the process is usually straightforward. When the dispatching is done by the system (such as in Visual Basic), an empty procedure has only to be filled in with a call to the corresponding callback procedure.

5. Conclusion This article is devoted to the generation of code from an interface specification based on the ICO formalism. This step appears very late in the life cycle of an interactive application but the ICO formalism may be usefully applied at earlier stages as it allows for a complete, concise and non-ambiguous specification of the user-software dialogue and lends to mathematical analysis and proof of the interface behavior before its implementation. To take advantage of all those features, we are in the process of building a complete UIMS based on the ICO formalism, including analysis modules, run-time interpretation and graphical edition of both the presentation and the ObCS parts.

6. REFERENCES [Abowd 90] Abowd G.D. Agents: Communicating interactive processes, in proceedings of Interact'90 Elsevier p. 143-148 Cambridge August 1990. [Bastide 90] Bastide R., Palanque P. Petri nets with objects for the design, validation and prototyping of user-driven interfaces. in proceedings of Interact'90 Elsevier p. 625631. Cambridge August 1990. [Coutaz 87] Coutaz J. The construction of user interfaces and the object paradigm. ECOOP'87, European Conference on Object Oriented Programming. Paris, June 1987. p. 135-144. [Fields 93] Fields, B., Harrison M., Wright P. From informal requirements to agent-based specification: an aricraft warning case study. Workshop on formal mlethods for the design of interactive systems. York, July 23rd 1993. [Green 86] GREEN M. A survey of three dialogue models. ACM Transaction on Graphics, vol 5, n°3, July 1986, p. 244-275. [Palanque 92] PALANQUE P. Modeling user-driven interfaces by means of Interactive Cooperative Objects. Ph.D. Dissertation of University Toulouse (France). 1992. [Palanque 93a] Palanque Ph., Bastide R., Sibertin-Blanc C., Dourte L. Design of UserDriven Interfaces using Petri Nets and Objects. In proceedings of Conference on Advanced Information Systems Engineering : CAISE 93” Lecture Notes in Computer Science n° 685, Paris, France, 8-11 June 1993, p. 569-585. [Palanque 93b] Palanque, Ph., Sibertin-Blanc C., Bastide, R. Formal specification, design and validation of user-driven interfaces using a Petri net and object based model. Poster session to the conference on Human-Computer Interaction, (HCI'93), Loughborough, U.K. 1993. [Paterno 93] Paterno F. Definition of properties of User Interfaces using Action-Based Temporal Logic. In proceedings of the 5th International Conference on Software Engineering and Knowledge Engineering (SEKE'93) June 18-16, 1993.

[Peterson 81] Peterson, J.L. Petri net theory and modeling of systems. Prentice-hall. 1981. [Wasserman 85] Wasserman A. Extending State-Transition Diagrams for the Specification of Human-Computer Interaction. IEEE Transactions on Software Engineering, vol. 11, n°8, August 1985; p. 699-713. [Wood 70] WOOD W.A. Transition network grammars for natural language analysis. Communications of the ACM, vol. 13 n°10,October 1970, pp. 591-606.