Using LOTOS for the Evaluation of Design Options in the PREMO Standard

PREMO, Presentation Environment for Multimedia Objects, is a major new standard under development within ISO/IEC. Itaddresses the creation of, presentation of, and interaction with all forms of information using single or multiple media. The standard is written using an Object Oriented approach. In this paper we specify the behavioural aspects of one of the central objects of the standard, the PREMO synchronizable object, in a constraint oriented style. We show that by adding further constraints in a modular way various design options can be investigated by means of model checking. This provides designers with more reliable information concerning the behavioural aspects of di(cid:11)erent designs which obviously is helpful in the evaluation of design decisions. In this way formal methods do not only play a role in the (cid:12)nal evaluation of the correctness of a design, but can be used in a design methodology in which a more dynamical process of design and evaluation is required. A requirement for this way of working is modularity which is well supported by both the Object Oriented and the Constraint Oriented approaches.


Introduction
Technology has evolved to the point that many i n teractive applications are enriched by the simultaneous use of multiple presentation media. While on the input side, the widespread use of sophisticated techniques, such as those employed within virtual reality systems, is limited to research laboratory prototypes, multimedia technology o ers the capability o f d e v eloping commercial products where the presentation becomes extremely complex in terms of the system architecture. We can think of systems as diverse as medical systems, realtime command control systems and geographical information systems. In each of these systems di erent presentation techniques may be used, such as the simultaneous use of 3D graphics, video animation, and sound. The presentation of data has become a complex task in which a large numb e r o f d i v erse requirements have to be taken into account.
In order to deal with this complexity i n a w a y that allows for extension and adaptability to speci c needs in a uniform way a standardization project is developing a standard, called PREMO ISO96 , that addresses the creation of, presentation of, and interaction with all forms of information using single or multiple media. In particular PREMO addresses the issues of con guration, extension, and interoperation of and between PREMO implementations. The approach taken within PREMO is an object oriented one. It de nes complex object-oriented systems that are to be used in a distributed environment. Objects de ned in PREMO are supposed to function largely independent and to cooperate and synchronize with other objects by means of communication. This aspect of PREMO requires a thorough investigation of the behavioural aspects of the combination of those objects.
Our goal is to get a deeper understanding of multimedia synchronization by specifying the behavioural aspects of one of the central objects in the standard: the synchronizable object. We based our speci cation on the english version of the standard, on a preliminary but quite detailed state-based speci cation DDHF97 , and on a previous process-algebraic speci cation FM97 . Since we w ant to analyse the behavioural aspects of independently operating objects that cooperate by means of communication, we use speci cation and abstraction techniques that have been developed within concurrency theory.
To this purpose, we w ant t o i n v estigate the use of Lotos Language Of Temporal Ordering Speci cation ISO89 , for the speci cation of the behavioural aspects of PREMO objects. We h a v e already experimented with a new way to obtain a constraint oriented, modular Basic Lotos speci cation that can be directly used for computer assisted veri cation such a s s i m ulation and model checking. Our experience with this approach and some of the results obtained are recalled in sections 4 and 5 where we make use of the veri cation environments Lite Lotos Integrated Tools Environment vEi91 and JACK DFGR95, B F e96, BGL94 . The rst provides tools for checking the syntax and some semantic properties of Lotos speci cations and allows for simulation of the speci cation and its translation into a common format for automata. The latter can be used on this common format and gives an integrated set of tools which comprises MAUTO and Autograph RDS90, MaV90 and the XAMC DFGR91 model checker for action based branching-time temporal logic formulas.
The longterm aim of this research is to gain insights in the particular requirements for formalisms and tools for the analysis of speci cations in the area of multimedia. The speci cation of PREMO Objects serves as a representative case study.
The paper is organized to give a short introduction to the PREMO standard with particular emphasis to the synchronization support mechanism in Section 2. This is followed by a short description of the tools making up our development e n vironment in Section 3. Section 4 describes the basic speci cation of PREMO synchronizable objects and gives an analysis of its component processes. In Section 5 we re ne the speci cation by describing the internal progression of synchronizable objects. In Section 6 we i n v estigate di erent design options to de ne the jump operation that is used as an example to introduce a general methodology based on the constraint s t yle of speci cation. In Section 7 we describe our main conclusions of this investigation and we give an outline of future research.
2 Short overview of the PREMO standard PREMO, Presentation Environment for Multimedia Objects, is a major new standard under development in Joint T echnical Committee 1 JTC 1 of the International Organization for Standardization and the International Electrotechnical Committee ISO IEC that addresses the creation of, presentation of, and interaction with all forms of information using single or multiple media. In particular, it addresses the issues of con guration, extension, and interoperation of and between PREMO implementations.
The aim of PREMO is the standardization of programming environments for the presentation of multimedia data. Construction of, and interaction with such m ultimedia information are also important aspects of PREMO; they are supported by application oriented modelling and interaction at several levels of abstraction. Multimedia is considered in a very general sense; high level virtual reality e n vironments, which mix real time 3D rendering techniques with sound, video, or even tactile feedback, and their e ects are, for example, within the scope of PREMO.
PREMO puts great emphasis on open environments which enable easy con gurability, adaptability, and extendibility of standardized components. This way PREMO can react in a direct and timely manner to future developments and stay up to date over a longer period of time. The PREMO standard is organized as a set of largely separable components. Each component provides a set of functionality that is useful for a target application area.
An important aspect of PREMO is the use of object oriented techniques. The object model is a traditional one, and it is based on the concept of subtyping and inheritance. However, de ning complex object-oriented systems to be used in a distributed environment leads to software engineering issues, whose complete solution would go far beyond the charter and the expertise of the PREMO working group. To this purpose, a Special Rapporteur has been appointed to provide a report on the applicability of formal description techniques to multi-media standards, with particular regard to formally specifying object behaviour and interfaces.
Following the recommendations of the Special Rapporteur's Report RDD94 , the Object-Z formal nota-tion DRS94 , an object oriented extension of the Z notation Spi89 , has been used to specify the behaviour of PREMO objects themselves. The choice was largely determined by the available expertize in the PREMO Rapporteur Group and a certain a nity b e t w een the state-based nature of PREMO itself and the state-based description techniques. One of the more challenging aspects that have been faced, is the speci cation of the PREMO synchronization model. Objects can communicate with one another through messages, i.e. through the operations de ned on the object types. Objects can become suspended either by w aiting for an operation invocation to return, or by w aiting on the arrival of an operation request. Consequently, operations on objects serve as a vehicle to synchronize various activities. Whether the concurrent activity of active objects is realized through separate hardware processors, through distribution over a network, or through some multithreaded operating system, is not relevant to PREMO and it is considered to be an implementation dependency. The emphasis on the activity of objects stems from the need for synchronization in multimedia environments and forms the basis of the synchronization model described in this paper. Using concurrency to achieve synchronization in multimedia systems is not speci c to PREMO. Other models and systems have taken a similar approach see for example DNNRA93 and PREMO, whose task is to provide a synthesis for current standardization, has been obviously in uenced by these models.

Supporting Synchronization in PREMO
The PREMO synchronization model is based on the fact that objects can be active elements. Di erent continuous media e.g. a video sequence and corresponding sound track are modelled as concurrent activities that may h a v e to reach speci c milestones at distinct and possibly user de nable synchronization points. This is the event based synchronization approach, which forms the basic layer of synchronization in PREMO. Although a large number of synchronization tasks are, in practice, related to synchronization in time, the choice of an essentially timeless synchronization scheme o ers greater exibility. While time-related synchronization schemes can be built on top of an event-based synchronization model, it is sometimes necessary to support purely event-based synchronization to achieve special e ects required by some application. Examples of how the various synchronization objects may be used can be found in ISO96 .
In line with the object-oriented approach of PREMO, the synchronization model de nes abstract object types that capture the essential features of synchronization. For the event-based synchronization scheme two major object types are de ned: synchronizable objects, which form the super types of, e.g., various media objects types; synchronization points, which m a y be used to manage complex synchronization patterns amongst synchronizable objects.

The PREMO Synchronizable Objects
A synchronizable object is a nite state machine modelling various operations that control the presentation of a medium within a possibly complex multi-media presentation environment. A synchronizable object can be in one of four states or modes namely STOPPED, PLAYING, PAUSING and WAITING. A number of operations are de ned that result in state transitions, and that modify or inquire several parameters controlling the progression along an internal one dimensional co-ordinate space. No particular interpretation is placed on these states, except that certain operations can only be performed in certain states. Similarly, the internal co-ordinate space is introduced as an abstract concept to which di erent synchronizable objects can add a di erent semantic meaning. The intention is that object types representing di erent kinds of media will inherit from this class and specialise the co-ordinate space and state machine in an appropriate way. i.e. media objects, such as audio, may represent time while others, such as video, may address frame numbers along this space.
Reference points can be de ned on the internal co-ordinate space where synchronization elements can be attached. Synchronization elements contain information on an event instance, a reference to a PREMO object, a reference to one of the operations of this object, and, nally, a W ait ag. When a reference point is reached during the progression, the synchronizable object uses the stored information to call, by means of messaging, the indicated operation on the referenced object using the event instance as an argument t o t h e call. Finally it may suspend itself if the Wait ag is set to true. This mechanism allows for the de nition of complex synchronization patterns amongst objects so that one synchronizable object can stop other objects, restart them, suspend them, etc.
Synchronizable objects can progress through the coordinate space in a certain direction by performing a sequence of progression stages. Each stage consists of the computation of a new required position and the stepwise traversal of the space between the current position and the new position by means of a separate pointer. In every step the information found at the coordinate is presented. If a reference point is encountered the call-back mechanism descibed above is activated. At the end of each stage the current position is updated. A stage is essentially atomic which means that external actions such as the mode transitions are delayed until an appropriate moment. Further details on progression are given in Section 5. A graphical presentation of the coordinate space and its relevant attributes and reference points are given in Figure 1.  Finally synchronizable objects contain also operations to change the value of position pointers, to add and delete reference points, and to add and delete synchronization elements associated with reference points.

Development e n vironment
We are interested in investigating the behaviour of synchronizable objects in greater detail than it is possible with a state based speci cation. The Object-Z speci cation of PREMO objects, accompanying the standard, explains and explores the state space of objects by de ning the variables that make up this state, and the operations that result in changing the value of one or more of such v ariables. However, Object-Z, as any other state based speci cation such as for example Z and VDM Bic94 , doesn't fully exploit the temporal order relations between operations. In order to do this, a process algebraic approach is better suited and gives a complementary view on the system under speci cation. Here, Basic Lotos has been chosen out of other available notations, such as CSP Hoa78 and CCS Mil89 , mainly because it is the only formal speci cation language that has been standardised so far, and we w ant to explore its applicability in the eld of multimedia standards.
Our strategy of investigation is based on developing a textual Basic Lotos speci cation of the basic transitions of modes of PREMO synchronizable objects. This speci cation is directly derived from the original Object-Z one following an approach outlined in the next section. The initial speci cation is subsequently re ned by adding further details in this case, the progression along the internal co-ordinate space described by means of separate processes that are composed in parallel with synchronization following a constraint oriented style of speci cation VSv91 . Finally, w e describe additional operations on synchronizable objects by using the same speci cation style. We specify each operation as a separate set of processes that is subsequently composed with, and consequently constrained by the already de ned ones. This enables The textual basic Lotos speci cation can be presented in di erent w a ys. The full Lite environment provides both tools for graphical representation and tools for simulation and for the generation of Extended Finite State Machines. The simulator can be used to derive an action tree where each path in the tree represents one of the traces that can possibly be generated and to produce an Extended Finite State Machine EFSM which is strong bisimulation equivalent to the original behaviour expression. Extended Finite State Machines can be translated automatically into an automaton in a format FC2 suitable for input to the JACK toolset. This set comprises MAUTO, Autograph and the XAMC model checker. In particular, we can generate graphical representations of the automata with the Autograph tool such as those presented in gures 3 and 4. More important, we can use the XAMC model checker to automatically verify properties of a speci cation that are written as ACTL formulas. ACTL is an action based temporal logic. Its syntax and informal semantics are summarized in the annex. Whenever a formula does not hold, the model checker can produce traces of actions that show the violation of the formula. This provides useful information on how to improve the speci cation. Figure 2 outlines the various transformations of the Lotos speci cation and the veri cation tools we used to analyse and develop the speci cation discussed in this paper.

Basic Transitions of Modes
The synchronizable object type de nes operations for making transitions between four di erent synchronization modes: STOPPED, PLAYING, PAUSING and WAITING. The initial mode is STOPPED. For each mode, operations are de ned that result in a transition to a di erent mode of the synchronizable object.
We describe the behaviour with respect to mode transitions by means of one Lotos process for each of the values de ning the mode space. The behaviour of each process is de ned as a non-deterministic choice between behaviour expressions, each one implementing one of the operations that can be invoked on the object in the mode represented by this process. This approach allows for the development of the speci cation per value of each control variable. The di erent parts of the speci cation can be combined by using a constraint oriented style of speci cation in the sense that the parts are combined by means of a synchronization operator. We show this in more detail while developing the speci cation step by step.
Following the informal speci cation of the standard and the formal de nition of the variables making up the state space given in Object-Z, we de ne the following Lotos actions that direct the mode transition of synchronizable objects, distinguished as observable external actions and non-observable internally performed ones: external actions: doSTOP directs a transition to STOPPED mode from any mode, doPLAY directs a transition to PLAYING mode when in STOPPED mode, doPAUSE directs a transition to PAUSING mode from PLAYING or WAITING mode, doRESUME directs a transition to PLAYING mode from PAUSING mode or from WAITING mode, exc preserves the current state and represents the raise of an exception caused by the invocation of an operation not allowed in this mode internal actions doWAIT enters the WAITING mode from PLAYING mode it is an abstraction for the Wait ag set at a reference point during progression donePlay e n ters the STOPPED mode from PLAYING mode on completion of a playing cycle.
With the above de nitions, a process describing the behaviour of the synchronizable object is one specifying its basic mode transition mechanism: process SynchronizableObject doSTOP,doPLAY,doPAUSE,doRESUME,exc : noexit := hide doWAIT,donePlay in modeTransitions doSTOP,doPLAY,doPAUSE,doRESUME,doWAIT,donePlay,exc endproc The basic mode transition mechanism itself is speci ed by a process that behaves as in STOPPED mode, which is the initial mode of each synchronizable object: process modeTransitions doSTOP,doPLAY,doPAUSE,doRESUME,doWAIT,donePlay,exc : noexit := STOPPED doSTOP,doPLAY,doPAUSE,doRESUME,doWAIT,donePlay,exc endproc When in STOPPED mode, only a play or a stop operation can be invoked, while any other request results in an exception. Consequently, the corresponding process o ers the choice of performing a doPLAY or a doSTOP action, or to raise an exception. The creation of a PLAYING process models the fact that the process goes into PLAYING mode. If an exception is raised or a doSTOP is performed, the mode does not change, so the process remains in STOPPED mode. When playing, synchronizable objects may respond to external as well as to internal operation invocations. The current play process can be explicitly stopped and enter STOPPED mode or it can be paused and enter PAUSING mode. Any other invocation of externally observable actions results in an exception. However, a synchronizable object can perform mode transitions as a consequence of internal actions. When the playing cycle is completed, it enters the STOPPED mode and we model this by the donePlay action. Furthermore, it enters the WAITING mode when a reference point is encountered during progression with the Wait ag set. This behaviour is captured by the following process: Similar reasoning applies to the speci cation of the processes de ning the behaviour of synchronizable objects when in PAUSING and WAITING mode. In the former, it is possible either to resume playing by invoking the doRESUME action, or to stop. In the latter, it is possible to choose between resuming the play process, stopping, or pausing. In both modes an exception is raised in the case an operation is invoked other than those speci ed. The corresponding Lotos processes are de ned as in the following: The modeTransitions process is a model of the basic transition mechanism of synchronizable objects. The corresponding automaton consists of four states, each one representing a mode, and fteen transitions as shown in Figure 3. doRESUME doRESUME doRESUME doRESUME doRESUME doRESUME doRESUME doRESUME doRESUME doRESUME doRESUME doRESUME doRESUME doRESUME doRESUME doRESUME doRESUME exc exc exc exc exc exc exc exc exc exc exc exc exc exc exc exc exc doSTOP doSTOP doSTOP doSTOP doSTOP doSTOP doSTOP doSTOP doSTOP doSTOP doSTOP doSTOP doSTOP doSTOP doSTOP doSTOP doSTOP doRESUME doRESUME doRESUME doRESUME doRESUME doRESUME doRESUME doRESUME doRESUME doRESUME doRESUME doRESUME doRESUME doRESUME doRESUME doRESUME doRESUME The automata, generated as a result of simulating the modeTransistions process with the veri cation toolset of Lite, can be shown automatically to satisfy safety properties expressed as ACTL formulas. We list a n umb e r o f i n teresting ones as an example. For reasons of lack of space we refer to DFGR91 for an explanation of the details of the ACTL formulas and give in Appendix A an overview of its syntax and informal semantics. Here, we give an informal description of each property that has been veri ed. We are aware of the fact that the informal descriptions may not capture the property precisely enough but this shows at the same time why a formal description is helpful in avoiding ambiguities and misunderstandings.
In order to address internal actions in the temporal logic formulas we made these actions observable in the speci cation before model checking.
1. In all states it is always possible to raise an exception AG exc true; 2. Whenever a doRESUME is observed in a trace this must have been preceded by at least one doPAUSE or doWAIT since the last doRESUME or, if lacking, the beginning of the trace.
E true f doPAUSE j doWAITg U fdoRESU MEg true & AG doRESUME E true f doPAUSE j doWAITg U fdoRESU MEg true 3. Whenever a doPLAY occurs, then whenever a doPAUSE or doWAIT occurs, eventually a doRESUME is enabled. AG doPLAY AG doPAUSE j doWAIT AF doRESUME true The following property i s not satis ed: 2nd BCS-FACS Northern Formal Methods Workshop 4. Whenever a doPAUSE or doWAIT occurs in a trace this must have been preceded by a doPLAY since the last doPAUSE or doWAIT or, if lacking, the beginning of the trace.
E true f doPLAY g U fdoP AUSE j doWAIT g true & AG doPAUSE j doWAIT E true f doPLAY g U fdoP AUSE j doWAITg true But this is also good because indeed a doPAUSE can be done directly after a doWAIT without doPLAY in between! The model checker is able to give feedback on the results by presenting traces of actions that show the violation of a property; in this case: ! doPLAY ! doWAIT ! doPAUSE 5 Speci cation Re nement Having described the basic transitions of modes, the next step is to get more insights into the system behaviour by i n troducing more details to re ne the previous speci cation. An interesting re nement is the speci cation of the meaning of progression through the co-ordinate space when the object is playing. To extend the speci cation two approaches are possible. Since the re nement is addressing operations that occur in PLAYING mode, a natural choice would be to rede ne the behaviour of the PLAYING process by adding further expressions that take i n to account the progression. Alternatively, a new process can be speci ed describing only the behaviour of progressing the position. This process is subsequently composed with the modeTransitions process following a constraint oriented style of speci cation. This second alternative presents a numb e r o f a d v antages including modularity and incremental re nement of the speci cation by cumulating locally de ned constraints. Consequently, w e adopt a constraint oriented style of speci cation and de ne a new process to model progression.
When directed to start a playing cycle, synchronizable objects enter a loop in which the next required position is computed progress towards that position by performing a sequence of steps. Such a sequence is called a stage. While stepping, the signaling of an event occurs in case a reference point is encountered.
Stepping is terminated when the object reaches the required position or because it completes playing. New actions are de ned to model the above behaviour: external actions: doSignal models the signaling of a reference point; internal actions: target models the computation of the next required position; doStep models the progression of the position; doneStage models the termination of progression because the target has been reached. Because each stage is to be considered atomic, the progression process has to delay external operations until an appropriate moment, which is at the end of a stage or, for a limited number of external operations, when in WAITING state. Consequently the external operations appear as gates in the process de nition.
The process describing the progression of the position initially creates an instance of a process o ering the choice of possible behaviour when the object is not stepping. The stepping stage is performed only when the synchronizable object is in PLAYING mode. Entering PLAYING mode is characterized by the occurrence of either a doPLAY or a doRESUME. Consequently the NOTSTEPPING process reacts to a doPLAY or a doRESUME by computing a new required position with the NEWTARGET process which leads to the stepping stage, or performs a simple recursion in the case of doSTOP or doPAUSE. Eventually, the re nement of the doStep and doneStage actions will require the reworking of this process de nition to take i n to account the special needs of di erent media types. The computation of a new required position is modelled by the target action in the NEWTARGET process. A more concrete speci cation will require the reworking of this process to match the characteristics of speci c media types. After the target has been computed the STEPPING stage is entered. The STEPPING process de nes at a high level of abstraction the possible actions that may take place during one stage progression. The behaviour initially o ered in a choice is either to perform a progression step, or to notify the completion of a stage or of a play cycle. When a stage is completed a new one can be entered by computing a new target, or the progression can be terminated. The completion of a play cycle may always occur and modelled by the donePlay action.
In the speci cation of the STEPPING and NOTSTEPPING processes we h a v e been using non-determinism to abstract from the Object-Z speci cation. Instead of modelling all the variables that describe the precise movement of a pointer in the coordinate space, we modelled only the events that trigger a change in the behaviour, such as the fact that the pointer reaches the end position of a playing cycle that generates a donePlay. In the speci cation we abstract from when exactly such e v ents occur and model only that such an event can occur by means of a non-deterministic choice of the possible events. This way w e capture everything that may happen and we can investigate all possibilities.
When the object is progressing its position by stepping, it can encounter a reference point. In this case it signals the event and may e n ter the WAITING mode if the Wait ag is set. According to the speci cation of mode transition, after the WAITING mode is entered the object can be either stopped or paused or resumed. It should be noted however that this is not equivalent to re-instantiate the NOTSTEPPING process. In fact, the doRESUME action continues the playing cycle with exactly the same stage that was active before waiting, when performed in the WAITING mode. Conversely, the same action initializes a new stage by computing a new target when performed in the PAUSING mode. The two processes are composed in parallel with synchronization on the gates doSTOP, doPLAY, doPAUSE, doRESUME, doWAIT and donePlay. Consequently, the processes constrain each other so that progressPosition cannot force a mode transition that would violate the transition mechanism speci ed by modeTransitions and, conversely, modeTransitions let the object make a mode transition only at those points where also progressPosition is enabled to perform the same action.
The simulation of the speci cation shows, as expected, a more complicated transition system shown in Figure 4 where the states in the middle that are surrounded by t w o b o xes indicate the re nement of the PLAY mode with respect to Figure 3. The small box contains the states representing NOTSTEPPING, the large box those representing STEPPING. doRESUME doRESUME doRESUME doRESUME doRESUME doRESUME doRESUME doRESUME doRESUME doRESUME doRESUME doRESUME doRESUME doRESUME doRESUME doRESUME doRESUME doRESUME doRESUME doRESUME doRESUME doRESUME doRESUME doRESUME doRESUME doRESUME doRESUME doRESUME doRESUME doRESUME doRESUME doRESUME doRESUME doRESUME

Analysis of mode transition and progression
A new set of properties hold in the re ned version of the automata. In particular, the properties expressed for the mode transition part in Section 4.2 hold also for the re ned speci cation. In addition the following properties hold that are speci c for the extended speci cation and that have also been formulated in the Foundation Component document of the PREMO standard ISO96 on section 7.9 Synchronization". 1. After a doRESUME from the PAUSING state always a new target is computed before stepping is continued.
AG doPAUSE doRESUME E true f targetg U fdoStep j donePlay j doneStageg true Note that continuation of stepping is indicated by the occurrence of doStep, donePlay or doneStage. 2. After a doRESUME from the WAITING state it is not the case that rst a new target is computed before stepping is continued.
AG doWAIT doRESUME E truef donePlay j doStep j doneStagegUftargetgtrue 6 Adding a Setting Operation: Jump So far we h a v e been modelling the basic operations of the Synchronizable Object. There are two more kinds of operations to be added to this object; information retrieve actions and value setting actions. Retrieve actions are those that can be invoked to get information on for example the current mode of the object. These actions do not change the state of the object and we don't expect interesting behavioural problems. The setting actions, on the other hand, may c hange the state of the object and since the behaviour is depending on these values it is worth to perform a careful analysis. In this paper we i n v estigate the consequences of adding a jump-operator that can change the value of the currentPosition" pointer to illustrate the kind of analysis that can be performed based on the speci cation given earlier.
The essential design question we are interested in here is under which conditions it is safe to allow a jump-action to be invoked on the synchronizable object. To be able to formulate a proper safety condition for this situation we h a v e to take a closer look at the progress position algorithm.
When a synchronizable object enters the playing mode, it starts a sequence of one or more playing stages. A stage consists of several small steps through the coordinate space where the position is recorded in a separate temporary pointer called pointer" in Figure 1. The end of each stage is marked by the requiredPosition" modelled by the target action which is computed at the beginning of each stage. The currentPosition" pointer is only updated after a target has been reached. A stage can be interrupted if a reference point" is encountered in which the synchronizable object is required to wait and go into WAITING mode. A possibly dangerous situation can occur when the currentPosition" pointer is changed after a new required position has been computed and before the currentPosition pointer has been updated to a stable value, either by reaching the target, or by encountering the end of the coordinate space modelled by donePlay" or by a doSTOP or a doPAUSE action which both may occur when the synchronizable object enters WAITING mode.
In terms of the model checker we should verify in every design alternative that it never happens that a jump occurs between the calculation of a new target and the occurrence of one of the actions doneStage, donePlay, doSTOP and doPAUSE. In ACTL we h a v e to formulate this as follows. In every path at every node that can be reached by performing target" there does not exist a path in which w e cannot observe one of the actions doneStage, donePlay, doSTOP or doPAUSE, which c haracterize the end of a stepping stage, before we can observe a jump. Formally:

AG target E truef doneStagejdonePlayjdoSTOPjdoPAUSEgUfjumpgtrue
In the following four sections we i n v estigate di erent design variants. In each v ariant the jump operation is allowed under di erent conditions. These conditions are speci ed by adding a further constraint t o t h e behaviour of the synchronizable object. We i n v estigate the following four options: Jump always enabled Jump disabled only when in PLAYING mode Jump disabled when in PLAYING or WAITING mode Jump disabled only when STEPPING during a stage For all the variants we use the same structure for restricting the situations in which the jump operation is enabled. We add a process called setOp" setting operations to the main behaviour of the synchronizable object in a constraint oriented way. The behaviour is speci ed as follows: The process de nitions of modeTransitions and progressPosition are unchanged. The jump operation is introduced only by means of the setOp process. The set of gates on which setOp synchronizes with progressPosition and modeTransitions vary depending on the de nition of setOp.

Jump always enabled
In this section we i n v estigate the possibility to enable jump in all situations. In this case the process setOp is very simple and is put in interleaving with the processes modeTransitions and progressPosition. process setOp jump : noexit := JUMPING jump where process JUMPING jump : noexit := jump; JUMPING jump endproc endproc As we could expect, the model checker gives as a result that the formula under investigation, formally expressed in the previous section, is FALSE for this speci cation. But, moreover, the model checker can be asked to give an example of a trace that violates the formula. In this case it shows that the trace ! doPLAY ! target ! jump is an example of a trace that violates the property w e h a v e formulated.

Jump disabled only during PLAYING mode
Due to the result shown in the previous section, we i n v estigate if it is enough to disable jump during PLAYING mode. The process setOp can observe if the synchronizable object enters and leaves PLAYING. The entering of PLAYING mode is triggered by an occurrence of doPLAY or doRESUME. This is modelled in the process setOp that enables jumping unless a doPLAY or a doRESUME action is observed. In that case jump is disabled which is modelled by the JmpDisable process.
Also in this case the model checker shows that the formula does not hold. So disabling jump only during playing is clearly not enough. The trace given by the model checker that violates the requirement i s ! doPLAY ! target ! doStep ! doSignal ! doWAIT ! jump 6.3 Jump disabled during PLAYING and WAITING In order to disable jump when the synchronizable object is in PLAYING or WAITING mode the enabling of jump has to be restricted. The structure of the process setOp is similar to the one of the previous case except that we don't need to take the doWAIT action explicitly into consideration. In fact, the only way t o enter WAITING mode is from PLAYING and the same set of actions identi es the leaving from both modes. The process JmpDisable makes sure that jump is indeed not available and enables it again only after the occurrence of doPAUSE, doSTOP or donePlay. As in the previous case, it also enables the doRESUME action so that it can take place. The process setOp is synchronizing on the actions doPLAY, doPAUSE, doSTOP, donePlay and doRE-SUME with the processes modeTransitions and progressPosition.
After this we can check that the formula under investigation is TRUE for this speci cation. So with this result we can conclude that disabling jump when the synchronizable object is in PLAYING or WAITING is a safe solution with respect to the property w e are investigating.

Jump disabled only during STEPPING
There exists however a less restrictive alternative than the previous one that still satis es the required property. This is the option to disable jump only during the situation in which the synchronizable object is in stepping mode. This means that there may b e a n umber of moments during that situation in which a jump action can safely be allowed.
To show this we follow again a similar structure as in the previous examples. Entering stepping mode in this case is triggered by the action target" that models the calculation of a new required position to be reached in the current stage.
The stepping mode is left when one of the actions doPAUSE, doSTOP, doneStage or donePlay are encountered. The process setOp synchronizes with the modeTransitions and progressPosition processes on the actions doPAUSE, doSTOP, donePlay, target and doneStage. The model checker shows that indeed for this design variant the safety property holds. It should be noted that this speci cation requires a small reworking of progressPosition. Since setOp relies on a synchronization occurring at gates target and doneStage, they must be explicitly shown in the list of gates of progressPosition and be hidden within SynchronizableObject.

Evaluation of the four variants
There are a numb e r o f i n teresting observations that can be made based on the four variants we analysed in the previous sections.
First of all it is shown that with a constraint oriented approach there is the possibility to extend the speci cation with other operations in a modular way, i.e. without changing the processes that had already been de ned. This has been made possible due to a number of methodological decisions. The most important is the choice for a constraint oriented approach and further the particular way this has been worked out in the speci cation. The essential control variables in the Object-Z speci cation have been de ned as processes that re ect the di erent v alues these control variables can take and the process de nitions clearly indicate which operations cause a change in their value.
The constraint oriented approach made it possible to formulate setOp as a separate constraint without changing the other processes. The clear structure in the e ect of actions on the value of the control variables made it possible to formulate the di erent constraints in an explicit way.
Of course it is not guaranteed that all possible design variants can be investigated with a minimal e ort in this way. But at least many options can be evaluated as long as no essential changes of the structure of the main speci cation are required. For example this may be the case if a jump operation must be possible during stepping at any time without delay. This would make jump an operation that has in uence on the value of the control variables that keep track of the stepping cycle of the synchronizable object, and thus requires a change in the process progressPosition.
The speci cation of the setOp processes indicates clearly which actions are considered to trigger the entering in or leaving from particular situations. These may b e v ery helpful in checking the Object-Z speci cation because these actions essentially indicate at which points certain variables have to be updated. In these variants this has been made explicit for the pointer that indicates the current position in the coordinate space of the synchronizable object.

Conclusion
In this article we illustrated a way to obtain a Basic Lotos speci cation from the Object-Z speci cation of the PREMO synchronizable object. We h a v e shown how such a speci cation can be obtained by motivating rigorously, although not fully formal, the relation between the two speci cations. The essential idea is to identify the control variables in the Object-Z speci cation and to model each v alue of each control variable as a separate process. The processes belonging to one control variable have been grouped in one process that consequently has been composed in parallel with other processes modelling other control variables. In fact this way w e obtained a speci cation in a constraint oriented style. This way w e also circumvented the problem of obtaining a full Lotos speci cation that is not directly suitable for model checking and whose automatic transformation into Basic Lotos may lead to a speci cation that is not equivalent to the full Lotos one.
The Basic Lotos speci cation serves as a formal model of the behaviour of the synhronizable object that can be analysed in detail by means of the tools that have been developed for Basic Lotos and for automata such as an action model checker. This way properties of the behaviour, formalized in the action temporal logic ACTL, could be automatically checked on the behavioural speci cation and the results directly confronted with the Object-Z speci cation. In this paper we illustrated that with relatively little e ort di erent design options can be formally evaluated and important properties be checked using tools for formal methods. This provides a better founded evaluation of design options because of the availability of formally validated correctness results that can be taken into consideration in a more complete evaluation. This illustrates well that formal methods do not only play a role in the veri cation of properties after the speci cation is completed, but allow for a speci cation approach in which speci cation and veri cation are much more interleaved.
The integration of di erent tools are in this respect certainly a step forward because it allows one to work basically with one speci cation of which di erent aspects can be investigated. The di erent w a ys to present a speci cation may also play an important role in discussions on the design in which people with di erent expertise take part.
We also want t o p o i n t out the interesting interplay b e t w een the two formal speci cation approaches. The Object-Z speci cation leads to a clear de nition of relatively small objects whose behaviour can subsequently be modelled and investigated in an independent w a y b y using other speci cation techniques and tools.
Of course, the more speci c the questions are that one wants to investigate, the more detailed the model has to be, and this may lead to a trade-o between e ort put into modelling and other ways to investigate the speci cation. Also in our method the level of abstraction was not directly derived from the Object-Z speci cation or the English standard. This part of modelling remains a matter of ingenuity of the designers which is probably inherent to the task of modelling.

A Syntax and Informal Semantics of ACTL
In the following table the syntax and informal semantics are listed of the ACTL operators we used in this paper to formulate the temporal logic properties that have been checked by means of the XAMC model checker. For further explanation and a formal semantics we refer to DFGR91 . Action formulas ::= true any observable action" false no observable action" a the observable action a" any observable action di erent from " j 0 either or 0 " & 0 both and 0 " 0 ::= State formulas ::= true any behaviour is possible" false no behaviour is possible" is impossible" & 0 and 0 " E there exists a possible execution in which " A for each of the the possible executions " there exists a next state reachable by an action that satis es , in which holds " for all next states reachable with actions that satisfy , holds" 0 ::= Path formulas ::= f gU f 0 g 0 actions that satisfy are performed and holds until an action that satis es 0 has been performed and then 0 holds" f gU 0 actions that satisfy are performed and holds until 0 holds" G in every future state holds" F there exists a future state in which holds" Satisfaction relation for action formulas a j= b i a = b a and b actions a j= i a 6 j= action formula a j= j 0 i a j= or a j= 0 a j= & 0 i a j= and a j= 0