The authors would like to thank Patrick ESQUIROL for being the first to use. PNO for ... Thèse d'état Université Joseph Fourier Grenoble FRANCE. 1988. [15].
PETRI NET OBJECTS FOR THE DESIGN, VALIDATION AND PROTOTYPING OF USERDRIVEN INTERFACES. Rémi Bastide * Philippe Palanque **
ABSTRACT Petri Net Objects (P.N.O.) are a high-level, object-structured dialect of Petri nets, primarily devised for the design of parallel systems. We show how this formalism can be used for the specification and design of event-driven interfaces, through the use of a real-life example. We then discuss the potential for dialogue validation, integration in UIMS and prototyping offered by this model. KEYWORDS : User interface design, High level Petri Nets, prototyping, validation, Object oriented software design.
I. INTRODUCTION. Nowadays, the user interface designer undertaking a development in a window-oriented environment finds himself less unprovided than only a few years ago. He has at his disposal a whole array of tools that alleviate to a great extend the non trivial task to build a user-friendly interface out of the rather low level services provided by graphical toolboxes. These tools, variously called Interface Generators or User Interface Management Systems and featuring interactive editing of the interface components generally rely on an "event driven" or "callback" style of programming [1], [2]. Interfaces produced with these systems usually exhibit a distinctive style of user/application dialogue where control flow is most of time event driven (or external) and application driven (internal or m o d a l ) only when some * TECHLOG
Bâtiment Aurélien II 2, Rue Boudeville 31100 Toulouse France Tél. 61.44.46.44
**L.I.S. Université Toulouse I 1 place Anatole France 31042 Toulouse cedex France
Petri Net Objects for the Design, Validation and Prototyping of User-driven Interfaces imperative action or confirmation is needed. It is now generally admitted that external control enables friendlier interfaces [3], where the d e c i s i o n scope of the user is broader [4]. This increased flexibility, however, causes some problems to the application programmer : event driven programming, as opposed to more conventionnal styles, does not exhibit a global and sequential control flow for the application. Even if the application is implemented in a single (sequential) computer process, the user can hold several seemingly parallel dialogues with different parts of the program, where subtle synchronisation and resource sharing problems may take place. The programmer, faced with this unforeseen complexity, generally has few conceptual tools to help him conceive and validate a global design for his application. Formalisms like finite state automata, Augmented Transition Networks or grammar and production systems are not particularly well suited to this kind of design, because they tend to model the user as a parsable sequential file, which does not fit well with the "pseudo-parallel" behavior expected in such systems [5] . Similar problems are encountered in another area of computer science : real-time software designers have been confronted for a long time with the complexity of modelling parallel systems. Indeed, it might seem an interesting idea to undertake an event-driven interface design using concepts usually put forward in real time systems. An interface may well be thought of as a reactive system, as usual interface components such as buttons, gauges and sliders can be viewed as the sensors and actuators found out in real time systems descriptions. Another aspect could incite us to bring closer the two approaches : it is the interest shown on both sides towards the object-oriented approach, which is the cornerstone of many current UIMS and which gives rise a lot or work and research in the real-time community [6], [7]. These are the points that led us to investigate the interest of using Petri Net Objects (PNO), a model whose main purpose is to describe parallel or real-time systems, in the field of user interface design. Petri nets have already been used for the description of computer-aided tasks [8] and for prototyping of interactive application [9], but not yet in the field of event driven interfaces.
II.
PNO MODEL OVERVIEW.
The description of PNO formalism will be rather informal, leaving out of scope several features of the model introduced in order to increase its modelling power in the field of real-time and parallel systems design, where timing and synchronisation constraints are somewhat tougher. A complete description of the formalism may be found in [10]. A system described by means of PNO will be modeled as a set of objects that cooperate to handle the global tasks of the system. An object in this
Petri Net Objects for the Design, Validation and Prototyping of User-driven Interfaces model is not a sequential entity such as an ADA task or a computer process. On the contrary, we consider, like in HOOD [6], that the operations offered by an object are activated by control flows, and that an object may take place in several different control flows at the same time. An object is also not a passive entity, but often will have its own spontaneous activity, not triggered by the call of its operations but processed on its own behalf. Like in conventionnal object-oriented models, an object is described by the data structure it maintains (its attributes) and the operations it offers to its environment (its methods). The model adds another dimension to this description by adding the specification of a b e h a v i o r for the object : this behavior is intended to describe the spontaneous activity of the object, the effect of its internal state on the availability of the operations it offers, and conversely the effect of operations on the internal state of the object. This behavior, called the Object Control Structure (OBCS) is described by a Petri Net (PN). The Petri Net model used to describe the OBCS is of course a high level PN model, where tokens flowing in the net, instead of zerodimensional entities found in conventional PN, will be constant or objects whose class can also feature an OBCS of its own. Arcs in the OBCS will be labeled by typed variables that act as the formal parameters for the transitions. A transition will be made of a precondition (a boolean expression of the input variables of the transition) and an action. If variables are of simple types (integer, strings, boolean ...) their value will be used. If they are of Class type, methods described in this class will be called in the precondition or action (Figure 1). Small window
< w, height, wd >
w Register width_max = 200 screen : Window Variable w : Window height, wd, d : integer
Enlargment
wd < width_max & w.height < height & w.open w.widen (height, wd) ; screen.swap (w, height, wd) ; ENLARGE d := (height**2 + wd**2)**1/2; d
w
A transition featuring a pre-condition. Figure 1
Petri Net Objects for the Design, Validation and Prototyping of User-driven Interfaces The semantics of the cooperation between objects (through operation calls) is also expressed through the use of PN formalism. Synchronous and non synchronous communication is available, but this is beyond the scope of this paper. This formalism is oriented towards an implementation in a compiled object-oriented language such as Eiffel [9], C++ [10] or Objective C [11], in the very same way that HOOD is oriented towards an implementation in ADA. In the rest of this paper, object-oriented descriptions will be given in "quasi Eiffel" syntax. To design an interface using this formalism, we will consider an interface as an object whose methods can be interactively triggered by the user, through interactions with usual dialogue components. The sequencing an synchronisations constraints for these methods will then be expressed in the OBCS.
III. ILLUSTRATIVE EXAMPLE. The example chosen to demonstrate the use of this model is a fairly common one : we wish to design an editor for tuples in a relational database table. This editor will allow adding new tuples, deleting tuples from the database, selecting tuples from those already stored and changing their values. Of course, our goal is to provide a fully user-driven style of dialogue, as opposed to menu-driven interactions usually found in most applications. The overall look of the interface is shown on Figure 2. A scrollable list shows the tuples in the database, presenting them by a distinctive attribute such as their primary key. Items in this list are selectable by clicking on them with the mouse. The attributes of a selected object are editable through the use of standard interface components (radio buttons, check boxes, sliders, ...). Database operations (creation, deletion, ...) are launchable by clicking on command buttons.
Petri Net Objects for the Design, Validation and Prototyping of User-driven Interfaces Machines database
Edit zone : Attributes of the object being edited.
Machine Id mach_36 Scroll list of unselected objects highlighting the selected one.
mach_33 mach_34 mach_35 mach_36 mach_37 mach_38 mach_39
Attribute xx
1
2
3
Command zone showing the availability of commands.
Attribute yy
ADD
REPLACE
RESET
Delete
Overall look of the interface window Figure 2 More often than not, the application programmer will get something like the paragraph just above, along with a sketch of the dialogue window, by way of specifications for the interface he has to build. Clearly, this is not enough : nothing is said about what will make the interface a pleasure or a pain to use, i.e. the structure of the dialogue between the user and the system. What is the meaning of commanddelete, if the object has been edited ? Is the Quit command always available ? Are the dialogue items always active ? Such questions are left open, and finally answered according to the implementor's taste and experience. We will design this dialogue as a PNO class, in order to provide a concise, yet formal and complete specification for the control structure of the application.
Petri Net Objects for the Design, Validation and Prototyping of User-driven Interfaces class Tuple_editor[Editable] export add, delete, replace, select, edit, reset, quit inherit Window feature display(Editable) is ... end; add is ... end; delete is ... end; ... obcs o,x,old : Editable; Declarations for Class Tuple_editor Figure 3 As stated in section II, the interface will be thought of as an object whose methods can be interactively triggered by user actions. The method of class Tuple_editor are easily found out (one might think of proceeding "à la Grady Booch" and underline the verbs found in the informal specifications of the dialogue). Our class will therefore offer operations Add, Delete, Select, Edit (change the attribute values of the object being edited), Replace (to record the changes) and Quit to end the application. It is also a good user-interface practice to add operation R e s e t , which will allow the user to undo his changes. An instance of class T u p l e _ e d i t o r is also a window in its own right, and therefore should be made a descendant of class Window in order to inherit methods such as Move, Resize, ... Tuple_editor will also be made a generic or Parametrized class : we will then be able to derivate a new class for each kind of tuple we wish to edit.
Petri Net Objects for the Design, Validation and Prototyping of User-driven Interfaces quit
edit
being edited
o.is_correct add
o.is_correct replace
reset
old.clone (o)
edit
selected
display(o) select
default
unselected
o.is_correct add
display(o) delete
o.create; display(o);
delete edit
OBCS of Class Tuple_editor Figure 4 The declarations for class Tuple_editor and its OBCS are shown in Figures 3 and 4 respectively. In order for our specification to be complete, we must provide the OBCS with an initial marking, defining which places will be marked at the creation of an instance and the values they will hold. In our example, place default should be marked with an object of class Editable bearing default values (presumably provided by operation create for class E d i t a b l e ). So, at the initialisation of the interface, the u n s e l e c t e d list is empty and only operations add and edit are legal. Finally we must explicit the binding between operations offered by the class an the dialog items that will trigger these operations, which is straightforward : operation c l o s e is triggered by the close box of the window, select is triggered by any of the unselected objects in the scroll list, edit is triggered by any of the dialog items in the edit zone and a d d , reset, replace and delete are triggered by the buttons with the same name. Note how each public operation of class T u p l e _ e d i t o r is associated with transitions in the OBCS : a transition bears the name of the method it is bound to and is pictured with an incoming broken arrow to underline its distinctive role in the OBCS. Most often there is only one transition corresponding to the method (as for add, reset, replace and select). In this case the operation is legal only if the corresponding transition if fireable.
Petri Net Objects for the Design, Validation and Prototyping of User-driven Interfaces Operation delete is bound to two transitions in the OBCS : the meaning of this is that the same user action will give rise to different interpretations depending on the inner state of the dialog : in our example deletion will cause another object in the unselected list to become selected if one is available, and otherwise provide an object with default values. Of course, we would like the behavior of our dialogue to be deterministic : so if the same operation is bound to several transitions in the OBCS, we will have to check that these transitions are in mutual exclusion : that is, any reachable marking of the net will allow at most one of those transitions to be fired. Operation e d i t deserves special attention : first it is bound to several transitions, but it also can be triggered by any of the dialog items in the Edit zone : this highlights the fact that there is neither bijective relation between triggers and methods, nor between methods an transitions in the OBCS. The general relations between those design components are summarized in an entity-relationship fashion on Figure 5. The reader could verify that whichever the state of the dialogue, one and only one e d i t transition is fireable, meaning that the user can always interact with items in the edit zone. Dialog item Item type : ... triggers 0..1 Position ... ...
Method is triggered Name : ... 1..n Parameters ... ... 0..n
is enabled
enables 0..1 Transition Precondition... Action ... ... Relationships between interface components Figure 5 In the OBCS of class Tuple_editor all transitions are bound to an operation of the class. This is not enforced by the model, however : an unbound transition in an OBCS will be able to occur - if it is enabled - without any need for user intervention, thus modelling a systematic operation, carried out by the system as soon as its preconditions are fullfilled. The aim of private operation display is to map individual attributes of the object being edited to dialogue items in the edit zone. This clearly require some knowledge of the object being edited, and that is why we have made Tuple_editor a parametrized class.
Petri Net Objects for the Design, Validation and Prototyping of User-driven Interfaces It should be noted that operations required to virtual class E d i t a b l e are quite different from those offered by class T u p l e _ e d i t o r : an instance of Editable has no method display or edit but is expected to answer calls to i s _ c o r r e c t (that might check integrity constraints in the database), in addition to the usual create and clone methods. An interesting side-effect of this is that our design can be tested before the full functionnality of the application is implemented, by providing a "fake" class with minimal create, clone, and is_correct operations. This design achieves a good separation between interface and application by ensuring that the information exchanged between the application and the UIMS are application concepts [14] : an interface object manipulates application objects only through the operations offered by their class, thus allowing good semantical partitionning. It should also be remenbered that only user-driven interaction has to be stated in the OBCS. When part of the dialog is application-driven and fully sequential, it can be ommited altogether : for example, operation is_correct could pop up a modal dialogue informing the user on why a creation attempt has failed and wait for him to click on a button before continuing processing.
IV. DESIGN VALIDATION . As we have seen above, Petri Nets are a powerful tool for modeling interactions between the various actions that can occur, especially if some amount of concurrency is to be highlighted. Common situations, such as resource sharing, synchronisation and parallel flow of control are expressed in a natural and convenient way, allowing easy communication of the design. Moreover, an important feature brought by the use of PN is the ability to statically check properties of the design through the use of analysis techniques, allowing the designer to prove the correctness of his specifications. A huge amount of literature has been devoted the analysis of PN, and several results are of interest to the interface designer : [15], [16].
IV.1.
Liveness (deadlock freedom).
Deadlocks are easy to avoid in a conventional, application driven style of dialogue. However, in a user-driven dialogue, where the flow of control cannot be predicted because the user carries on concurrent dialogue flows with several parts of the application, the designer should have a way to ensure that is specification is deadlock-free, i.e that wichever the inner state of the application, any application command will have a way to become available again, through a given sequence of commands. In our design, this problem is directly connected to the liveness problem in the PN theory : for a given method to be accessible, at least one of the transistions it relates to should be live in the OBCS, whichever the current marking.
Petri Net Objects for the Design, Validation and Prototyping of User-driven Interfaces
IV.2.
Boundedness.
A place in a Petri Net is k-bounded if there exists an integer k such that the number of tokens in this place cannot exceed k . For example, given the initial marking stated in III, place selected is 1-bounded, thus establishing the desirable property that only one object can be selected at a time. Conversely, place u n s e l e c t e d is not bounded, which is adequate since it models all the tuples in the table. This shows how bounds-checking can help establishing that the elements of design have the right semantical properties. Incidentally, the fact that the net is globally unbounded shows that it cannot be reduced to a finite state automaton.
V.3. Re-initialization. Given an initial marking, a net is reinitializable if there is a finite sequence of transition firings that can bring it back to its initial state. In our design, this means for the user the ability to reproduce it's initial working environment, which might be desirable in most cases. In the example, deletion of the last tuple will reproduce the initial marking, i.e. a token in the default place.
IV.4.
Coverability.
We have stated in section III that if the same operation for a class relates to several transitions in its OBCS, those transitions should be checked for mutual exclusion. This relates to coverability problems in the PN theory. We must check that no reachable marking enables more than one transition relating to the same method. In our example, place being edited and place s e l e c t e d should not be marked at the same time, because two e d i t transitions would then be enabled. Coverability analysis could prove this requirement.
V. PROTOTYPING. The design shown in Figure 4 features several arbitrary decisions that are worth examination : for example, command quit is disabled when a tuple is being edited. Is this the best option to choose ? Would'nt it be better to leave the command allowed and give the user a warning message ? Ultimately, the end-user should be the one to answer such questions. Many current UIMS focus on the easy definition of the external "look and feel" of the interface, and leave out of scope the definition of dialogue structure, because they provide no tool to specify reasonably complex control flow for the application. When using such systems for a prototyping purpose, there is
Petri Net Objects for the Design, Validation and Prototyping of User-driven Interfaces a strong likelihood that the debate between the designer and the user will focus mainly on "cosmetic" matters such as the size or placement of dialogue items, precisely because the UIMS makes it easy to change those parameters "on the fly". Older prototyping systems, using a finite state automaton description for a hierarchy of screens and menus were better off in this case, because the user could have a clear vision of the dynamics of the future application, and answer the "where can I go from here ?" question. PNO formalism could fruitfully be introduced in an UIMS, by allowing the designer to relate his Petri Net design to the user interface components manipulated by an interface editor. This would result in a fully operational prototype for the application, allowing the user to interact and proceed through the various states of the dialogue. What is needed for this is a generic Petri Net Interpretor (sometimes called a token game player) which is not a difficult thing to build, and could act as the "run-time kernel" for the UIM environment. A PNO design can therefore be thought of as "executable specifications" for an interface.
VI. CONCLUSION. The aim of this paper is to promote the use of Petri Nets (and especially of PNO) as a valuable and efficient formalism for user interface specification and design. Several existing tools (some of which are public domain [17]) can already help the designer by providing interactive edition of PN, model analysis and simulation [18]. However, to be an efficient tool for user interface prototyping, support for the PNO formalism should be tightly integrated into an existing UIMS, providing the kind of environment needed to accomodate the frequent changes and experimentations needed in the prototyping process.
VII.
ACKNOWLEDGEMENTS.
The authors would like to thank Patrick ESQUIROL for being the first to use PNO for user interface specifications in real life conditions. The example used in section III is straight from his specification set for project ORIGAN, a job-shop short term scheduler whose interface has been developped on top of the X-Window system using the Open Dialog UIMS [19]
BIBLIOGRAPHY [1]
[2]
KARSENTY S. Graffiti : Un outil graphique pour la construction d'interface homme-machine adaptables. These de 3° cycle Université de Paris-Sud. HULLOT J.M. SOS interfaces : un générateur d'interfaces homme machine. Acte des jounées AFCET-Informatique sur les langages orientés objet.
Petri Net Objects for the Design, Validation and Prototyping of User-driven Interfaces [3]
[4]
[5]
[6]
[7] [8]
[9]
[10]
[11] [12] [13]
[14]
[15]
[16]
[17]
[18]
[19]
BIGRE+GLOBULE N° 48 COUTAZ J. The Construction of User Interfaces and the Object Paradigm ECOOP'87 special issue of BIGRE n° 54 Paris, june 87. M.F. BARTHET. Logiciels interactifs et ergonomie. Dunod informatique 1988. MYERS B.A. Creating user Interfaces by demonstration.. Academic Press, inc. HEITZ M. HOOD, une méthode de conception hiérarchisée orientée objet pour le développement de gros logiciels techniques et temps réel; Bigre+Globule 57, dec. 87 BOOCH G. Software Engineering with Ada, Benjamin/Cummings Publishing, California, 87 BARTHET M.F. SIBERTIN-BLANC C. La modélisation d'applications interactives adaptées aux utilisateurs par des réseaux de Petri à structures de données. Actes du 3° colloque-exposition de génie logiciel, Versailles, Mai 1986. SIBERTIN-BLANC C. Prototyping interactive applications using Petri Nets. Le Genie logiciel et ses applications EC2, TOULOUSE 1988 BASTIDE R. - SIBERTIN-BLANC C. Conception par objets de systèmes parallèles. Le Genie logiciel et ses applications EC2, TOULOUSE 1989 MEYER B. Object-Oriented software construction; Prentice hall, 1988 STROUSTRUP B. The C++ Programming Language ; Addison-Wesley , Mass., 86 COX B. J. Object-Oriented programming : An evolutionary approach; Addison-Wesley , Mass., 1986. Interface Homme-Ordinateur : Conception et Réalisation. J. COUTAZ. Thèse d'état Université Joseph Fourier Grenoble FRANCE. 1988. BRAMS G.W.. Réseaux de Petri : théorie et pratique. Masson 1983 Paris. PETERSON J.L. Petri net theory and the modeling of systems. Prentice Hall. FELDBRUGGE F. JENSEN K. Petri Net Tool Overview 1986 Petri Nets : Applications and relationships to other models of concurrency ; B. Brauer, W. Reisig, G. Rosenberg editor, LNCS 254 &255, Springer. TECHLOG. SEDRIC : presentation générale Techlog 1989 APOLLO 1988 Open dialog reference manual
