Design transformation and abstract design prototyping

Design transformationand abstract design pr0t0typing G Friel and D Budgen

In the process ~?/s¢~[?ware design, both 'structured" diagrams as well as mathematical jormalisms can provide use/ul ways +~1 expressing a designer's ideas about a solution to a problem. The paper describes a tran,y[ormation tool that generates executable .specO~eations in the C S P / m e too notation, taking as its input a high-level M A S C O T design. The resulting spee(fieations ean then he used to 'execute' the design, so that the designer ean explore the dynamic behaviour o f the intended~s3'stem. The design modelling strategies ~?["the two .[orms are diseussed and the ways in which their use ean be eombined to support the development of a ,svstem design e.vamined. ~h'sign model, s+4l?ware tools, proto typing, M A S C O T, executable .~pee(fieations

Static and dynamic design models The process of software design can be described as consisting of a series of transformations between a sequence of 'models' of the intended system. These models are created by the designer to be able to reason about their ideas for a solution in a suitably abstract manner. The initial, architectural model is usually formed by considering the structures and the functions of the problem. This can then be systematically developed into a detailed design model, which can provide the basis for an implementation +blueprint' by means of a series of transformalions, in which the designer extends the model by making decisions about such issues as structural forms, and by adding information. One benefit of using abstractions is that it is much easier to understand how the designer intends the system to work, in part at least because a form is being handled that is primarily concerned with problem-oriented struclures and interactions, rather than machine-oriented forms. The architectural model that the designer creates is concerned with the problem, rather than with the details of its solution. Existing work has shown the importance of forming complete initial abstract design models ~, which can be modelled using abstract diagrammatical forms such as dataflow diagrams (DFDs) 2.3 or the S A D T actigrams

and datagrams 4. These static forms of representation are used to describe the properties of an essentially dynamic system, and it is a particular problem of software design that a software-based system will possess both: • static properties, such as module structure, reflecting relationships such as the uses hierarchy between compilation units 5, and the run-time invocation hierarchy between procedures • dynamic properties that concern the behaviour and function of the resulting system when it is eventually executed Essentially, the diagrammatical representation forms that are most widely used for software design are more suited to modelling static properties, and the dynamic properties of a system can only be modelled in an indirect way through such forms as the state-transition diagram (STD) 6 and the statechart 7. These forms provide an aid to the designer's need for mentally 'executing' their models at an abstract level while developing their plans and ideas ~, but, in general, this form of dynamic modelling cannot easily be undertaken in any systematic manner, although a tool does exist that will "execute' statecharts ~.

Design transformations The transformations that are involved in the software design process will vary considerably with design strategy (method) and with the form of the actual problem itself. In general though, each transformation step involves interactions between at least the following components: • an input model of the system that may be described using a 'representation' form (which may be graphical, textual, or mathematical) • an output model that again can have any of the above forms • design inputs through which the designer adds information to the model Within this rather broad framework, the following two principal forms of design step can be recognised:

Department of Computing Science, Universityof Stirling, Stirling FK9 4LA, UK

vol 33 no 9 november 1991

0950-5849/91/090707

• The refinement of structures, in which the input and

13 © 1991 Butterworth Heinemann Ltd

707

output model forms are the same, but extra detail is added through the design inputs, such as the expansion of a 'bubble' in a D F D to produce a 'child' DFD. • The transformation of viewpoint, such as the transform analysis step of the classical Structured Systems Analysis and Structured Design strategy 3, in which the design representation forms that are used for the input and the output models are different and the designer adds information about a new relationship (the invocation hierarchy) to the model. Another example is the Jackson Systems Programming (JSP) design step, which involves composing the input and output data structures to form the program structure diagram - in this case the form remains unchanged but the interpretation has been revised 9,~°. In general, the 'refinement steps' will preserve the representation forms, but add more detail, while the 'transformation of viewpoint' steps provide a means of making an extension to the structure of the designer's model. Within the 'navigation through a solution space' model of the software design process ~, the refinement steps in particular effectively constrain and reduce the eventual 'solution space'. Most design methods use only one principal form of description, be it text, diagrams, or mathematics. It would appear, though, that 'refinement' steps that change the representation form (but not necessarily the viewpoint) can also be helpful in developing the designer's models. The next section discusses an example of such a transformation and the ways in which it can be used.

Transforming from graphical to 'formal' notation The work described in this paper provides a means by which a designer can transform a graphical MASCOTbased design t2,~3 into a descriptive form that is based on the more 'formal' notation of CSP/me too i4. While a number of experiments has attempted to generate code directly from a design representation such as MASCOT j5,16, these are apt to involve large design steps that cannot be constrained adequately. The work described here has aimed instead at performing a smaller design transformation step that is essentially of the 'refinement' type, although providing a change of description form too. This approach provides the following benefits: • The transformation can be performed automatically using a rule-based software tool. • Further design refinement steps can then take place using a form of representation that is more strongly solution oriented, and hence which is better suited to such steps. • There is scope for 'execution' of the transformed design. • Further automatic transformation to actual executable code can then be used on the CSP/me too description t4.

708

It may be useful to elaborate briefly on the third of these points. The CSP/me too model is state based, and so it has been possible to develop tools that will 'execute' a CSP/me too design model as a high-level prototype ~7, by applying 'events' to the model, and stepping through the resulting states of the system. In this way, therefore, the designer can study the dynamic behaviour of a system while still working with an abstract design model. Indeed, as a MASCOT design should be immediately executable when transformed into CSP/me too, the designer can still have the benefit of an executable model even while working entirely with graphical design forms. In practice, however, it has proved more useful to supplement the basic MASCOT model to be able to generate more complete CSP/me too structures. In the generation of the initial executable model it is necessary to make certain assumptions relating to the probable behaviour of the intended system as described using MASCOT. This is due to the limitations of the single viewpoint presented by the MASCOT forms, which needs to be augmented to provide the information needed to create an executable model. During the refinement and elaboration of the design, this additional information can be provided directly by the designer. The following sections of this paper examine the descriptive forms involved; the design transformation steps and assumptions made (as mentioned above); and the ways that the generated CSP/me too form can be used by the designer. In the conclusions those aspects are identified where future work could bring significant benefits and extend the usefulness of this technique for software design.

DESCRIPTIVE FORMS Role of representation forms Software designers use diagrammatical forms of representation in much the same way as designers in other spheres, to describe the structure and properties of a system from a particular viewpoint. Viewpoints are not necessarily physical. For example, in the case of a building, it might be possible to describe it in terms of plan, end-view, and elevation, which would be a viewpoint concerned with external physical dimensions. Equally though, a wiring diagram for the building would provide yet another (more abstract) viewpoint of its structure - and, of course, the two representations would need to be consistent where they described the same object. The design of software is made more complex because the end-product itself is abstract and also possesses a dynamic aspect. So while it is possible to find a number of useful viewpoints, and corresponding representations, ensuring consistency between them is much more difficult. The viewpoints used to describe software are commonly classified in the following way. • Structural viewpoints, which are relatively easily described through the use of diagrams.

information and software technology

• Behavioural viewpoints, which attempt to consider more dynamic aspects of a design and are more difficult to model using diagrams. • Functional viewpoints, which describe what a system does, generally in terms of transformations on data (and hence are difficult to model with any general form). • Data modelling viewpoints, which consider the data objects of the system together with their structure. This paper is mainly concerned with using the first two types of viewpoint, and hence will examine these a little more closely at this point.

Structural viewpoints These are used quite widely for the detailed design modelling process, largely because the task of detailed design is mainly concerned with deriving actual program structures. Examples include: • The structure chart 3,~, which is used to describe the invocation hierarchy of subprogram units. • The structure graph ~'), which was originally developed to describe the detailed form of an Ada program, although it is capable of rather wider use 2°. It describes the uses hierarchy that exists between compilation units, together with details of the interfaces. • The M A S C O T ACP diagram (see next section), which gives a network description of a set of cooperating parallel processes. Essentially though, these forms all identify static relationships or static aspects of relationships that occur between system elements.

Behavioural viewpoints These are event-driven viewpoints and generally assume some form of state-oriented model. Some particular examples are: • The STD 6, which can be used to model large-scale and small-scale systems. This is very much an event-action viewpoint. • The statechart 7, which is essentially concerned with more abstract elements of a system. This is more of an event-state viewpoint than is provided by the STD. • The Petri net 2~, which provides a detailed form of event-state modelling. Again, all of these forms are attempting to capture the essentially dynamic aspects of system structure. To some degree they can also be used for cross-checking with the structural forms. The next section considers one graphical form of description in more depth, namely, the M A S C O T representation.

M A S C O T machine M A S C O T (an acronym standing for Modular Approach to Software Construction, Operation and Test) origi-

vol 33 no 9 november 1991

nated at Royal Signals and R a d a r Establishment, Malvern, U K in the early 1970s ~3-22.It was devised to provide a solution to the problem of designing and constructing large real-time systems containing distributed components and (potentially) many complex devices. The M A S C O T model is based on a network of cooperating parallel processes, using well defined interfaces. The current form is known as M A S C O T 3. The principal components of the ' M A S C O T machine' are: • a set of abstract concepts, represented by the system elements • a diagrammatical representation of a network of system elements • a run-time executive that supports realisations of the system elements and that provides support for their interactions M A S C O T therefore provides a set of abstractions that can be used to construct a model or design for a system without the need to consider the detailed form of the underlying hardware, at least in the initial stages.

System elements and ACP diagram The M A S C O T machine supports three basic system elements. These are: • The Activity. This is a schedulable process, which performs the algorithmic functions of the system and is constructed as a single sequential task. There is no internal concurrent programming, and one Activity cannot directly access data objects in any other Activity. • The Channel. This is a 'pipeline' mechanism for the transmission of data (messages) between Activities. Data in the buffers of a Channel are normally regarded as being transient - - once they are read by the consumer Activity, the corresponding buffer space becomes reusable. • The Pool. This provides a mechanism for giving Activities access to shared 'static' information. Information in a Pool is normally available to readers until it is specifically overwritten. A further, less fundamental, system element is the 'device server', which has been allocated a symbol that is a hybrid between that for an Activity and that for a Pool. A M A S C O T design is represented graphically by an ACP diagram (Activity, Channel, Pool), which is a network diagram used to show the interconnections between the system elements. An example of such a diagram is shown in Figure 1. Arcs between system elements indicate the flow of information. A particularly important rule is the one which requires that Activities may not communicate directly with other Activities, they must always communicate via a Channel or a Pool. Channels and Pools usually contain one or more data buffers, together with a set of access procedures, which are used to provide the necessary interface for any calling

709

Generate local display

r •

Track table

~'

Primary radar

--D

(~e ~ Display update P°siti°nal~ . , ~ ~' L -~-I1~ | transform ~ ~Sectord ~ N'~ I_~_ I ~-" ~ J Displaychannel J Figure 1. Simple A CP diagram Activities. These can provide the desired informationhiding mechanism, so that the calling Activity need not know anything about the detailed structures of the Channel or Pool. Channels and Pools are collectively known as intercommunication data areas (IDAs). The subsystem is used as a composite design object, to allow for a hierarchical structure of design representation, as needed for the description of larger systems. (In Figure 1, the subsystem Track table is contained within the subsystem Generate local display.) A corollary of its use is that the activation of data transfers needs to be made specific, as for a data flow between subsystems, it will not be evident as to whether this is a 'put' or a 'get' operation. This is achieved by adding symbols to the ends of the dataflow arc, with a solid circle indicating the activating end (the port) and a solid rectangle indicating the passive end (the window). Activities then contain ports, while IDAs contain windows. To understand fully the behaviour of any system as represented by an ACP diagram, it is also necessary to consider the form of the underlying executive. This is because the executive creates some 'implicit' rules which will determine and constrain the interactions that occur between the system elements.

Real-time executive The executive provides certain classes of support for the system at run-time. The detailed form will be system dependent (for example, the number of priority levels that can be used for scheduling, structures for procedural interfaces, etc.), but the behaviour of the executive should conform to the model of the M A S C O T machine. The principal support is for: • • • •

Activity execution control timing information synchronization and mutual exclusion interrupt handling

A significant point about the M A S C O T philosophy is that a system is composed of cooperating parallel processes (or 'Activities' in M A S C O T terminology). So an Activity may only control its own actions and may not directly control the execution of any other Activities. It is normally assumed that all system elements are m e m o r y resident. A consequence of this structure is that all of the cou-

710

pling that exists between the system elements is shown in the ACP diagram. There is no hidden control coupling; interprocess control is by message passing only, and this is shown explicitly on the diagram by the use of dataflow arcs.

C S P / m e too approach to software design CSP/me too is an extension of the me too method of software design 23 and was developed by the DESC A R T E S Esprit Project primarily for the design and development of embedded Ada systems '4. The me too method is concerned with the specification and development of sequential software systems and has now been extended by incorporating a subset of CSP 24 to enable it to deal with concurrent systems. The CSP/me too method models a concurrent system as a set of objects that can communicate with one another by message passing. The me too part is used to describe the objects and the CSP process definitions constrain the order of execution of the me too operations. As a syntactically complete CSP/me too specification is executable, it allows the designer to develop and execute a prototype of their design fairly early in the design process. The CSP/me too method has three main steps '4, namely: • The model step. This involves building a model of the problem by identifying a set of objects that can communicate with one another by message passing. The subset of CSP is used to describe the interaction between these objects, and the functionality of the associated operations is expressed in me too. . The specify step. Each object identified in the model is described in the formal representation of me too, in terms of sets, sequences, relations, maps, records, and tuples. The operations on each object are defined in the me too language in terms of the mathematical operations available on the objecrs formal representation. • The validate step. The CSP/me too specification is executed as a prototype. Feedback from this can be used to improve the original model by highlighting design errors, omissions, and inconsistencies. It also enables the possibility of experimenting with alternative designs that can be developed relatively quickly.

Using me too with CSP Each object identified in the model step is represented by a me too module, which has its own local state defined in terms of sets, sequences, maps, relations, etc., and which exports operations on that state. These operations are formally specified by the natural mathematical operations allowed on the aforementioned structures. Each me too module encapsulates a single instance of an object whose type is the local state, and this state can only be changed via the defined operations. Other objects can only make changes to the state by calling those operations that are explicitly exported. In effect, each me too module is an instance of an abstract data type.

information and software technology

By putting all the local states together and adding a clock state (to represent time), a 'super' state is obtained, which is effectively the state of the whole system. This 'super' state and the operations defined on each local state are used by the prototyping tool to model the state machine of the specified design. As concurrent systems are being dealt with, the interactions between objects need to be specified, and this is achieved using CSP. Each object (or concurrent me too module) has an associated CSP process definition and within this is specified the events in which that object can participate. An event occurring in only one process is called a local event, while an event shared by two processes is known as a synchronization event. The latter denotes process interaction. The effect of the occurrence of a local event is defined by a me too operation and a synchronization event by a pair of operations (i.e., an operation within one object calling the associated operation exported from another object). The use of me too allows a mathematical definition of the operations that can be performed on the local state of an object. As me too is a mathematical and purely functional language it provides a simple and clearly defined semantics for the objects and their operations.

Using CSP Synchronization between processes occurs at those points in a CSP/me too specification where two processes have the same event in their CSP definitions. For synchronization to take place, both processes must be ready to execute the event on which they are to synchronize. If one of the processes is not ready then the other must continue execution with an alternative event, if one is available, or wait. The event that corresponds to the me too exported operation is known as the 'responding' event and the calling operation is termed the ~initiating' event. When two me too objects (processes) synchronize with each other there are two possibilities: • The object initiating the synchronization event (known as the initiator) sends a message to the responding object (the respondeD, resulting in the responder updating its local state, i.e., a 'put' operation. • The initiator sending a message to the responder to interrogate the responder's local state. The returned value is used to update the initiator's local state, i.e., a 'geC operation. Normally, the first statement in the CSP part of a complete specification is what might be called the 'system' definition, which contains a list of the processes executing in parallel. For example, a simple system consisting of the processes A, B, and C could have the following initial statement in its CSP definition part: SYSTEM = ((All B)!IC) The ordering and bracketing of processes in the CSP

vol 33 no 9 november 1991

definition is important as 'll' is a binary operator. If it was 'AlIBlIC' then A and B could synchronize and so could B and C, but not A and C. The significance of this point will become more apparent later.

Executing prototype A major benefit of using the CSP/me too method is that tools have been developed which enable a CSP/me too specification to be executed. In effect this allows a design to be animated to provide an abstract prototype of the system. So in the early stages of software development a problem-oriented prototype can be produced relatively quickly and cheaply through this mechanism. This prototype can then be tested and experimented on, to see how well it conforms to the specification. Multiprocessor target environments can also be modelled as the system allows the allocation of CSP processes to processors. By allocating estimates of execution times to events, the behaviour of the model can also be examined when running both under normal conditions and using worstcase scenarios. (A more comprehensive description and examples of using the prototype tool is available~7.)

DESIGN TRANSFORMATION A CSP/me too specification that is sufficiently complete to be executable can be generated automatically from the M A S C O T design representation alone, using rule-based transformation techniques. However, as the time- and event-ordered behaviour of an Activity is not described through the M A S C O T ACP diagram, in the absence of other design information some assumptions about its form have to be made to allow CSP descriptions of the Activity processes to be generated. These assumptions cover such issues as the causality of events (how an Activity interacts with its associated data flows) and the way in which data are managed within Pools and Channels (data buffering within Channels and mutually exclusive access to Pools). This section describes the process used for generating CSP/me too specifications from M A S C O T and informally describes the transformation rules that have been developed. The input to this process is the textual form used to represent a M A S C O T design 13, which is transformed into the CSP/me too representation. An example M A S C O T ACP diagram is shown in Figure 2. The textual form of this diagram and the CSP/ me too specification generated by the transformation are shown in the Appendix.

Generating CSP process definitions Each M A S C O T system element (Activity, Channel, Pool, or Server) is translated into a CSP process, which participates in the events represented by its associated data flows. The IDAs are passive processes, in that they only respond to events and all events are initiated by Activities that are active processes. In this context an event is the passing of data between two processes, which in M A S C O T terms is represented by a dataflow line, and

711

Serv_l

/

signal 3

m,~

-

Serv 3

Act_l

Act_3 m-s' I-.I

s2 I I -

Serv_2

]sngnal 2

b,~l~et-s2 Y

. ~

res~

new_s

Chan 1

~

re

pdate

ou!,

Act_2

Pool_l Figure 2. Simple MA SCO T design example in CSP/me too by the operation through which two processes synchronize. The initial CSP statement which shows the concurrent behaviour of the CSP processes is bracketed so that communication between each and every process is enabled, i.e., the network topology is not taken into account. Therefore, if there was the system S, comprising the CSP processes P~, P2 . . . , P7 executing concurrently, the generated CSP code would look like: S=(((P,IIP2) II (P3IIP4)) II ((PsIIP6) II PT) ) which is of the general form ((AIIB) II (CIID)). This simple approach has been considered adequate for the present purpose, as devising an algorithm to give bracketing that would take into account network topology would result in no significant benefits or improvements. It is a requirement of CSP that each event and each pair of synchronization event names is unique, and using the M A S C O T dataflow name alone is not sufficient to ensure this, as M A S C O T does not require that each data flow is uniquely identified. To deal with this the translator generates an expanded event name by making use of the name of the port that initiates the event (data flow) and the unique reference number associated with the initiating activity. As the M A S C O T examples used in this paper all have uniquely named data flows, to preserve clarity, the extended event names (as generated by the translator) have not been used. For I D A s

The CSP definitions of Pools and Channels have a similar form, the main difference being that the events associated with a Channel perform 'get' and 'put' operations, whereas Pool events are 'read' and 'write' operations. (A Pool is intended to retain data, whereas within a Channel the reading of data will cause them to be consumed.) It is important at this point to make the distinction between

712

the 'get'/'put' and 'read'/'write' events. When data are read from a Pool it is effectively only a copy that is taken, whereas the data can be considered to be physically removed from a Channel in a 'get' event. If there was a Channel 'Chan' that was involved in 'put' events Ep~ . . . Ep, and 'get' event Egl, the corresponding CSP code generated would look like: Chan = (

[]... []...

(Epl ~ Chan)

[] (Ep, --, Chan) [] (Egt ~ (Chan_reset --* Chan)) For example, the definition of Chan 1, as shown in Figure 2, would take the form (using simplified event names): Chan_l = (

(sig 1 out ~ Chan_l) [] (sig 2 out --, Chan_l) [] (new s ~ (Chan 1 reset --* Chan 1))

At the CSP level the only difference between the Channel and the Pool is the presence of the 'reset' event. This represents the me too operation that removes the data stored within the Channel. A 'reset' event, of this type, assumes a simple form of Channel where a 'put' event will overwrite any previous data and a 'get' event removes any data from the Channel, leaving it empty. An alternative approach would be for a 'put' event to add the data to a queue and a 'get' event to remove the first element from the queue. If this was the case then the 'reset' event would be replaced by a 'dec queue' event. The queue could be implemented quite simply within me too as a sequence of data items. To prevent any attempt to take data from an empty queue, the 'get' event would be guarded. Similarly, an upper limit on the queue size could be implemented by adding a guard to the 'put' event.

information and software technology

The queueing method used could be quite complex, especially if there are multiple 'put' events to the same Channel. For example, a single F I F O (first in first out) queue would be less complex than using several queues each with a different priority. The actual structure used will very much depend on the application problem and so cannot be determined directly from the information provided in a M A S C O T diagram. However, it would normally be addressed when expanding the M A S C O T design. As a Pool has been represented by a CSP process, only one event can occur within a Pool at any one time, which is not necessarily the case for a M A S C O T system. Therefore, two events cannot take place simultaneously, not even two 'read's (i.e., mutual exclusion is always maintained). The same principle also applies to Channels. This overhead may or may not be acceptable, again depending on the application. In terms of executing a CSP/me too specification, this means that simultaneous access to a Pool or Channel cannot be modelled. However, this problem only becomes significant if a truly concurrent system is being modelled, where each CSP process is mapped to a physical processor in a multiprocessor environment. If the final implementation is to be run on a sequential machine, all concurrent operations will be implemented sequentially in any case.

For Activities An Activity is represented by a CSP process, and its CSP definition is composed of the details of incoming and outgoing data flows associated with that Activity. These data flows are in turn represented by CSP events. Also each Activity has an additional simple event (i.e., one that represents a local, or nonsynchronizing, operation) assigned to represent the operation of the Activity. This event name is of the form: < process-name > _op As stated previously, the ordering of events for an Activity process cannot be determined from the M A S C O T representation alone. Therefore, if no further description is available, the following assumptions are made: • Input events are scheduled before output events. • Channel 'get' events are scheduled before Pool 'read' events. • Pool 'write' events are scheduled before Channel 'put' events. • Inputs from more than one Channel are considered to indicate a choice. • Outputs to more than one Channel or Pool are done arbitrarily. • The Activity operation is carried out following the completion of the input events and before the initiation of the output events. For example, Act_3, as shown in Figure 2, would be defined as:

vol 33 no 9 november 1991

Act 3 = (new_s ~ (read_d ~ (Act 3 op --~ (result ~ Act_3)))) These assumptions represent a simplistic interpretation of an ACP diagram, but ensure that an executable model can always be generated. As mentioned earlier, this detailed information about behaviour is not provided from the ACP diagram. For example, inputs from multiple Channels to one Activity may or may not represent that a choice is to be made. It could be that data are read from all Channels in sequence each time, or that they are read from only one Channel, with the choice depending on some other factor. As the behaviour of the same Activity can be interpreted in different ways, trying to generalize it is impossible. Although this type of information cannot be represented within the M A S C O T ACP diagram, it can be given in other forms. The F o r m tool, developed within the M D S E (Mascot Design Support Environment) Project 25, provides a limited means of describing the behavioural aspects of an A C P diagram by using formfilling techniques. Another approach would be to use the notation of STDs 6. This is discussed further later.

For Servers The Server is unlike other M A S C O T element types as it can behave either like an I D A or in a similar way to an Activity. The most c o m m o n form it takes is that of an IDA, where the Server represents a buffer between a physical device and the software environment. The CSP definition of a Server looks similar to that of a Channel or Pool, as defined earlier. For example, Serv 1, as shown in Figure 2, could be defined as: Serv 1 = (signal_l ~ Serv 1) When testing the prototype, this form of Server definition proved to be unsatisfactory. The reasons for this are discussed and an improved Server definition described later.

Generating me too module specifications The system generates a me too module specification for each CSP process, which effectively means a specification for each M A S C O T system element. The general structure of a specification is shown in Figure 3. The me too module is split into a number of distinct sections, and these are explained below.

Imports list N o entries are made in this from the automatic generation process at present. Instead, it is used for automating the execution of the prototype when the model is modified by hand (see later). It provides a list of the identifiers of those module identifiers that provide the definitions of abstract data types used by the current module. Contacts list This entry provides a list of the me too modules that synchronize on the events initiated by the current

713

specification of MASCOT..SE_name imports from . . . c o n t a c t s

. .

exported operations

object representations constants

...

state csp o p e r a t i o n s .

.

.

the state of a module is used to model each transition in the execution cycle of a M A S C O T system element. The purpose and exact definition of a state will depend on the type of the corresponding M A S C O T system element. IDA states The state definition is identical for both Channels and Pools. It consists of a Boolean variable that is used to flag the presence of data within the IDA, with the data themselves being represented by the value T R U E . (At this stage the concern is not with what the actual data are, only with the fact that they are present.) For example, the state of Chan_l would be defined as:

op erat ions definitions

end

MASCOT..SE_name

Figure 3. Structure o f me too module

module. That is, the me too modules whose exported operations are called from within this module. Therefore, it should only appear within the specification modules for Activities, and for those Servers that initiate events. In M A S C O T terms, this is the list of those system elements that are connected to an Activity or to the ports of a Server• For example, the contacts list of Act_3, as shown in Figure 2, would be:

state = record(data_pres : boolean) initially mk_chan I(FALSE); This assumes the use of the simple form of data handling within Channels, as described earlier. Alternatively, using a simple queueing mechanism (see earlier), the state could consist of an integer variable that is used to keep a count of the number of data items in the queue. Activity states The state of an Activity is described by a set of Boolean variables, with one being used for each incoming data flow and one being used to represent the operation of the Activity (where the value T R U E indicates that the Activity has carried out its operation/function). For example, the state of Act 3 as shown in Figure 2 would be defined as:

contacts Chan_l, Pool_l, Serv3

Exported operations definitions A list of exported operations is provided within the specification for those system elements that respond to events, namely, IDAs and some Servers (i.e., those that behave like IDAs). They are defined by the name of the appropriate event prefixed by the name of the module exporting the operation. The full definition of an exported operation is as follows: • updating local state: < module-name >_ < event-name > : boolean. < module-name > ~ < module-name > • interrogating local state: < module-name >_ < event-name > : < module-name > --, boolean The module name on the right-hand side of the definition represents the local state•

Module state definition All me too modules have their own local state, and an object can only modify the state of another object by calling one or more of the exported operations from that object. Therefore, each module encapsulates a single instance of an object whose type is the local state. me too is state machine oriented, and in general terms

714

state = record(new s ok:boolean,read d ok:boolean,opnresult:boolean) initially mk_act_I(FALSE,FALSE,FALSE); Server states The state definition generated for a Server is identical to that of an IDA, except when it has been modified to incorporate a test harness (see the next main section). Within those Servers that provide inputs, unlike the IDA, the Boolean flags indicating the presence of data are initially set to T R U E . This means that all Server events providing input to the system will always be available for scheduling by the user.

C S P operations definitions The CSP operations definition section will appear within those me too modules that correspond to the system elements which initiate events and/or contain local (i.e., nonsynchronizing) events. Their functional definition is expressed as follows: • nonsynchronizing events (update local state only): event-name: this-module --* this-module . initiating a 'get' event (interrogate local state of responding process): event-name: resp-module, init-module --* init-module

information and software technology

• initiating a 'put' event (update local state of responding process): event-name : init-module, resp-module --, resp-module

Operation body definitions All me too modules contain a definitions section to provide information about their exported and/or CSP operations. The form of each operation definition will depend on the type of operation. A complete description of the rules used to generate the different types of operations is outwith the scope of this paper. Instead, they are best illustrated by examples. The following are the me too operations generated for the Activity Act l and the IDA Chan 1 from Figure 2. definitions for Act 1

signal_ I (resp,init) - upd signal_ l_OK(init,serv_l_signal I(resp)); sig_l o u t ( i n i t , r e s p ) - chan _I sig__ I_out(opn_result(init),resp); act_l_op(this) - let new = mk actl(false,false) in upd opn result(new,true); definitions for Chan 1

c h a n I _sig_ I out(bool,resp) - upd data pres(resp,bool); chan 1 sig~2 o u t ( b o o l , r e s p ) - upd data_pres(resp,bool); chan 1 new s(resp) guard data pres(resp); - data pres(resp); chan I r e s e t ( t h i s ) - upd data pres(this,false); In general, MASCOT 3 data flows that point from a window to a port are 'get' events and those that flow in the opposite direction are 'put' events. In both cases the port indicates the initiating process and the window the responding process. Also, as stated previously, each synchronization event is represented by a pair of me too operations. The initiating operation is simply the event name and the responding operation is the event name prefixed with the name of the responding process. For example, with event sig_l_out, the operation sig_l_out in Act_l (initiating process) calls the operation chan_ 1 sig 1 out in Chan_l (responding process).

Allocation of processes to processors and times to events The CSP/me too specification language has a facility that allows the user to assign a set of mappings for CSP processes to processors. The inclusion of the processor allocation section (see the Appendix) allows the system

vol 33 no 9 november 1991

specification, or prototype, to be modelled in a multiprocessor environment. If this section is omitted from the specification then a single-processor machine is assumed. Each Server is allocated to its own processor. This is because each Server is regarded by the MASCOT application as a separate entity within its environment. A single processor is used to accommodate the remainder of the application, this being the simplest approach. To automate the execution of a prototype as much as possible, expected execution duration times are allocated to events. This is incorporated within the specification by means of the process times section (see the Appendix). From the MASCOT design alone it is not possible to give expected execution times for events. Therefore, the translator again adopts the simplest approach and allocates a default value for an execution time of one time unit to each event. The user can easily change the default settings for both processor and time allocations by editing the generated specification. In fact, it is expected that it would be normal to do so during the process of testing and developing a CSP/me too specification.

Further design information Various shortcomings of the design transformation process have been highlighted, which are a result of the 'structure only' viewpoint of MASCOT. These shortcomings are resolved by making general case assumptions, which are sufficient for obtaining a reasonable 'first try' executable prototype. Further design information can be incorporated by manually editing the CSP/me too specification. An alternative, and preferable, approach would be to derive the information using some systematic means. The MDSE Form tool 25 can be used for this purpose, but the interface and format are not entirely satisfactory. Making use of STDs is being investigated and is discussed further later.

EXECUTION OF SPECIFICATION Output generated by prototype The output generated by the prototyping tool, when used during the 'validate' step of CSP/me too (i.e., the stage of testing the specification by executing the prototype), consists of the following information: Current time - - this is the current time of the model, using some arbitrary unit of time given in decimal notation, with zero being the start time. Possible events - - this is the list of those events that are possible at the current moment in time. If only one event is possible and it is neither a synchronization event nor requires parameters, it will be scheduled automatically. This is continued until the next point in time when user intervention is required to schedule a synchronization event, provide parameters, or make a choice.

715

• Current state - - this is the current state of the system, which is effectively the current state values of each me too module (each representing a M A S C O T system element). • Process finish times - - the times at which each process becomes idle. This output is generated continuously until user intervention is required, when the model stops execution and the system then waits for the user to input the event to be scheduled along with any required parameter values. Execution then continues in the same manner. This describes execution with the 'verbose' option enabled, i.e., where each successive state change is shown. Alternatively, by switching the 'verbose' option off, the state is only shown prior to when user intervention is required.

amount of displayed data and user interaction can be kept to a minimum. To use time guards, the CSP definition for a Server, as given earlier, has to be modified slightly. This can be done by introducing a Server 'ready' event. For example, Serv 1 would be redefined as: S e r v l = (serv 1 ready ~ (signal_l --* Serv_l)) The me too module definition for Serv_l is shown below, with the modifications required to make use of a constant/regular time interval highlighted: specification of Serv_ 1 imports from calendar exported operations serv_l_signal_l : s e r v l ~ boolean I

Execution control The CSP/me too prototyping tool allows specifications to be executed in automatic mode, but the benefit of this can be lost when there is a choice of events to be executed. When there is a continuous choice of events to be scheduled, this leads to the problem o f the prototype constantly requesting user intervention. This problem mainly arises when there is a number of external events that have to be explicitly initiated by the user. In terms of M A S C O T , this means events that involve a Server process. In the CSP/me too prototype these events are continually available, because once data have been read from or written to a Server, the Server is immediately available again to read from or write to. When there are more than a handful of these events available, there is the further problem of the data presentation becoming cluttered and difficult to comprehend. Some form of control mechanism for execution is therefore required. Two possible solutions have been investigated. The first of these is to make each Server event into a guarded operation by using a simple Boolean flag. The value of this flag can be changed by suspending execution of the prototype and returning to the me too (command) level of the prototyping system. The new value is then assigned to the appropriate flag(s). For example, the operation corresponding to the 'signal_l' even in Figure 2 can be guarded in this way: Serv 1 signal_l_l(param) guard serv 1 ready; - - ...; By switching the Boolean variable 'serv 1 ready' to T R U E or FALSE, the Serv_l Server can be switched on or off, respectively. Alternatively, time guards can be used. Making use of time guards allows an event to be scheduled only after a set time interval has elapsed. This can be done by using either a constant/regular time interval for the event or by assigning different times through a sequence o f values, each used in succession. When using this method, a scenario can then be created under which the model is to be executed. By careful choice of time intervals the

716

state = record(data_pres:boolean I ,signal_l_due:time

)

initially m k _ s e r v _ l ( T R U E ,0 ); csp operations serv_l_ready : serv_l --. serv_l definitions serv_l_ready(local) times guard signall_due(local); = = mk_serv_l (data_pres(local), signal_l_due(local) + < time-interval > ); serv_ l_signal_ 1(resp) - data_pres(resp); end Serv_l To use the alternative approach of assigning a sequence of time intervals, the state would be modified also to contain the required sequence of time values, and the Server ' r e a d y ' operation would use successive values from this sequence. The modifications to the specification that have been illustrated and discussed within this section are for the purpose of providing a test harness within which the CSP/me too prototype is executed. As such, they are not part of the actual specification itself.

Relating prototype run-time output to original MASCOT design The output generated while executing the CSP/me too prototype is very much state machine oriented and its relation to the M A S C O T design may not be immediately apparent. For the output to be of any real benefit, the designer needs to be able to relate the data back to the original M A S C O T design, and the main problem here is making the association between available event names and their corresponding M A S C O T data flows. This is because the translator generates unique event identifiers by expanding the dataflow names (prefixing them with the name of

information and software technology

the initiating port and using the initiating process's refe~'ence number as a suffix). It is not always immediately apparent which data flow an event name corresponds to. Relating the state description back to the MASCOT design is reasonably straightforward, but for larger MASCOT designs the volume of state information can become unwieldy, especially as this is carried out manually. Another problem with the state description is that it is based on assumptions made about the behavioural aspects of the MASCOT design, which may or may not be what the designer intended. This problem is addressed more fully in the next section. CONCLUSIONS The main benefit from the work described in this paper is that it enables designers to generate an executable model of their abstract design without having to be concerned with implementation details. Previous work done in developing systems directly from MASCOT designs has tended to concentrate on generating implementation code directly, the use of Ada ~5 and Occam 216 being two examples. By generating an executable design representation (abstract prototype) instead, it is possible to test the design model and to highlight possible design errors or inconsistencies. Doing this at the design level is likely to be much quicker, simpler, and cheaper than finding and correcting design errors in an implementation. Once the required design is achieved, the CSP/me too specification can be used to generate outline 'implementation' code, which is a relatively straightforward process. Tools are already available for generating outline Ada code from a CSP/me too specification ~4. The initial design model is limited in what it can show about the design, as it is based on the assumptions made during the transformation process from a MASCOT ACP diagram to CSP/me too. These assumptions will, in many cases, represent a simplistic interpretation of the behaviour of different system elements, their functionality, and causality of events. To reduce this problem, a means of supplementing a MASCOT ACP diagram with the additional design information is required for elaboration of the design. A proposed solution and one currently being investigated are now outlined.

Extending M A S C O T design representation MASCOT is a 'single viewpoint' design representation in that it only describes the structural aspects of a design and does not provide the means to give a behavioural description. One solution to this problem would be to supplement the MASCOT design with some form of behavioural description, preferably keeping with a diagrammatic representation for consistency of use. An existing behavioural descriptive form that appears to be suited to this purpose is that of STDs 6. It has a graphical form, is relatively simple to use, and the statemachine-oriented approach is not dissimilar to that of CSP/me too. This effective enhancement to the MASCOT design taxonomy needs to be integrated at the Activity level, i.e., each Activity within an ACP diagram

vol 33 no 9 november 1991

should have an STD associated with it. The STD form can also describe behaviour at the subsystem level of an ACP diagram and queueing, or buffering, mechanism(s) used within Channels. As well as this behavioural description, the STD form also makes it possible to generate better state descriptions for the design objects.

Using prototype output to animate M A S C O T design As outlined earlier, the problem of relating the output from the CSP/me too prototype back to the original MASCOT design form is one that needs support from tools. Ideally, it should be possible to use this output to animate the original MASCOT design in some way on a graphical VDU. This would allow the CSP/me too model to be hidden from the user and provide an animated model based on the original form. The authors are investigating the most effective ways of doing this.

Continuing the design process From the viewpoint of the design process itself, there are two possible paths that can then be taken from here to develop a design further. One would be, as outlined above, for the designer to take the MASCOT design representation (which can now be animated using CSP/ me too as the underlying machine) and further develop and test the design using the MASCOT form throughout. Alternatively, it is possible to take the generated CSP/me too specification and expand on this. The most pragmatic approach would currently appear to be to progress down the former path as far as is practical and then to take the resulting CSP/me too and refine this directly. Whichever process is followed, it will eventually lead to outline implementation code being generated directly from the final CSP/me too specification. Again ways of supporting each of these development paths are being investigated.

ACKNOWLEDGEMENTS The authors thank Dr R.G. Clark for his helpful comments, and for the advice provided on the use of CSP/me too. The support of SERC through the provision of a research studentship is also acknowledged.

REFERENCES 1 Adeison, B and Soloway, E 'The role of domain experience in software design' IEEE Trans. Soft. Eng. Vol 11 No 11 (November 1985) pp 1351 1360 2 DeMarco, T Structured analysis and system specification Yourdon Press (1978) 3 Page-Jones, M The practical guide to structured systems design (2nd ed) Prentice Hall (1988)

4 Marca,D A and McGowan,C L SADT: structured analysis and design technique McGraw-Hill (1988) 5 Parnas, D L 'Designing software for ease of extension and contraction' IEEE Trans. Soft. Eng. Vol 5 No 2 (March 1979) pp 128-137 6 Ward, P T and Mellor,S J Structured development for realtime systems (Vol 1: introduction and tools) Yourdon Press (1985)

717

7 Harel, D 'On visual formalisms' Commun. ACM Vol 31 N o 5 (May 1988) pp 514-530 8 H a r d , D et ai. ' S T A T E M A T E : a working environment for the development of complex reactive systems' IEEE Trans. Soft. Eng. Vol 16 N o 4 (April 1990) pp 4 0 3 4 1 3 9 Jackson, M A Principles of program design Academic Press (1975) 10 Cameron, J R JSP & JSD: the Jackson approach to software development I E E E Computer Society Press (1983) 11 Sheppard, M and Inee, D 'Metrics, outlier analysis and the software design process' Inf. Soft. Technol. Vol 31 No 3 (March 1989) pp 91-98 12 'Special Issue on M A S C O T ' Soft. Eng. J. Vol 1 N o 3 (May 1986) 13 R S R E The official MASCOT3 handbook, edition 3.1 R S R E , Malvern, U K (June 1987) 14 Clark, R G 'The design and development of embedded Ada systems' Soft. Eng. J. Vol 5 N o 3 (1990) pp 175-184 15 Jackson, K ' M A S C O T 3 and A d a ' Soft. Eng. J. Vol 1 N o 3 (May 1986)pp 121-135 16 Knowles, R ' M a p p i n g a Mascot 3 design into Occam' Soft. Eng. J. Vol 5 (July 1990) pp 207-213 17 Clark, R G 'The CSP/me too method' Technical report TR.61 Department of Computing Science, University of Stirling, U K (May 1990) 18 Yourdon, E and Constantine, L Structured design. fundamen-

tals of a discipline of computer program and system design 19 20 21 22 23 24 25

Prentice Hall (1979) Buhr, R J A System design with Ada Prentice Hall (1984) Budgen, D Software development with Modula-2 AddisonWesley (1989) Peterson, J L 'Petrinets' Comput. Surv. Vol 9 (1977) pp 223252 Simpson, H R and Jackson, K 'Process synchronisation in M A S C O T ' Computer J. Vol 22 (1979) pp 332-345 Alexander, H and Jones, V Software design andprototyping using me too Prentice Hall (1990) Hoare, C A R Communicating sequentialprocesses (International Series in Computing Science) Prentice Hall (1985) Chattam, J A, James, R K, Patel, H et al. ' M A S C O T design support environment - - final report' Technical report MDSE/GEN/FR/1.1 Alvey Project SE/044 (March 1989)

APPENDIX: EXAMPLE MASCOT TO CSP]ME TOO TRANSLATION This is the textual representation of the M A S C O T A C P diagram shown in Figure 2. •k ~ , k ~ MDSE Mascot Text Tool: Release 3.02: August 1988MODE/ NORMAL. ACCESS INTERFACE SIG_I_OUT; END; ACCESS INTERFACE SIG_2_OUT; END; ACCESS INTERFACE READ_D; END; ACCESS INTERFACE RESULT; END; ACCESS INTERFACE NEW_S; END; ACCESS INTERFACE SIGNAL_2; END; ACCESS INTERFACE SIGNAL 1; END;

718

SYSTEM EXAMPLE USES un000000001, un000000002, un000000003, un000000004, un000000005, un000000006 un000000007, un000000008; SERVER SERV_I: un000000001 SERVER SERV 2:un000000002 SERVER SERV 3: un000000003: POOL POOL_I: un000000004; CHANNEL CHAN_I: un000000005; ACTIVITY ACT 3: un000000006 ( G E T D = P O O L I.IND, PUT_X=SERV 3.INX,GET S = C H A N I.OUT S); ACTIVITY ACT 2: un000000007 (PUT S2=CHAN 1.IN $2, GET_S2 = SERV 2.OUT $2); ACTIVITY ACT 1: un000000008 (PUT S I = C H A N I.IN S1, GET SI=SERV I.OUT SI); END. SERVER un000000001 PROVIDES OUT SI/OUT : SIGNAL 1; END. SERVER un000000002 PROVIDES OUT S2/OUT : SIGNAL 2; END. SERVER un000000003 PROVIDES IN X/IN : RESULT; END. POOL un000000004 PROVIDES IN_ D / O U T : R E A D D ; END. CHANNEL un000000005 PROVIDES O U T S / O U T : N E W S ; IN_S2/IN : SIG 2OUT; IN_S1/IN : SIG_I_OUT; END. ACTIVITY un000000006 REQUIRES GET D/IN : READ D; PUT_X/OUT : RESULT; G E T S / I N : NEW S; END. ACTIVITY un000000007 REQUIRES PUT_S2/OUT : SIG_2_OUT; GET_S2/IN : SIGNAL 2; END. ACTIVITY un000000008 REQUIRES PUT_SI/OUT : SIG_I_OUT; GET_SI/IN : SIGNAL1; END. %MDSENTT-I-NO_ERRORS, END. The following is the CSP/me too specification generated from the above M A S C O T description. Note that it uses the expanded event names, which are of the form: < initiating_port_name > _ < data_flow_name > _ < initiating_process ref n u m > EXAMPLE = ( ((ACT_I II ACT_2 ) dl (ACT_3 II CHAN_I )) II ((POOL 1 II SERV 3) II (SERV 2 II SERV 1 ))) ACT 1 = (GET SI SIGNAL 1 8 - > (ACT 1 o p - > (PUT SI SIG I_OUT 8 - > ACT 1))) ACT_2 = (GET $2 SIGNAL_2 7- > (ACT 2 o p - > (PUT $2 SIG_2_OUT_7-> ACT_2))) ACT 3 = (GET_S_NEW S 6 -> (GET D READ D 6 -> (Af'l~3_op-> (PUT X RESULT_6-> ACT_3)))) CHAN 1 = (

(PUT_SI SIG 1OUT_8-> CHAN_I)

information and software technology

POOL SERV SERV SERV

1 = ( 3 = ( 2 = (

I = (

[] ( P U T $2 SIG 2 O U T 7 - > C H A N l) [] ( G E T S N E W S 6 - > ( C H A N 1 reset-> C H A N 1)) ) (GET DREAD D 6-> POOL I)) (PUT X RESULT 6-> SERV 3)) ( G E T $2 S I G N A L 2 7 - > S E R V 2 ) ) ( G E T SI S I G N A L 1 8 - > S E R V 1))

concurrent specification of E X A M P L E specification of A C T 1 contactsSERV I.CHAN I state = r e c o r d ( G E T SI S I G N A L 1 8 ok:boolean, opn result:boolean) initially mk ACT I ( F A L S E . F A L S E ) : csp operations G E T SI S I G N A L I 8 : S E R V I ' A C T 1 - > A C T 1 P U T SI SIG l O U T 8 : A C T I * C H A N I - > C H A N 1 ACT 1 op:ACT 1-> ACT 1 definitions G E T SI S I G N A L I 8 ( r e s p . i n i t ) - upd G E T SI S I G N A L I 8 ok(init.SERV 1 G E T SI SIGN A L I 8(resp)): P U T S1 SIG I O U T 8(init.resp) = = C H A N 1 P U T SI S1G I O U T 8(opn result(init).resp): ACT 1 op(local)= = let new = m k A C T I ( F A L S E . F A L S E ) in upd opn result(new.TRUE); end A C T I specification of A C T 2 contacts S E R V 2. C H A N I state = r e c o r d ( G E T $2 S I G N A L 2 7 ok:boolean, opn result:boolean) initially mk A C T 2 ( F A L S E . F A L S E ) : csp operations G E T $2 S I G N A L 2 7 : S E R V 2* A C T 2 - > A C T 2 P U T $2 SIG 2 O U T 7 : A C T 2 * C H A N 1 - > C H A N 1 ACT 2 op:ACT 2-> ACT 2 definitions G E T $2 S I G N A L 2 7(resp.init) = = upd G E T $2 S I G N A L 2 7 ok(init.SERV 2 G E T $2 SIGN A L 2 7(resp)): P U T $2 SIG 2 O U T 7(init.resp) - C H A N I P U T $2 SIG 2 O U T 7(opn result(init).resp): A C T 2 op(local] - let new = mk A C T 2 ( F A L S E . F A L S E ) in upd opn result(new.TRUE): end A C T 2 specification of A C T 3 contacts C H A N 1, SERV 3. P O O L 1 state = r e c o r d ( G E T S N E W S 6 ok:boolean, G E T D R E A D D 6 ok: boolean, opn result:boolean) initially mk A C T 3 ( F A L S E , F A L S E . F A L S E ) ; cap operations GET S NEW S 6:CHAN I'ACT 3-> ACT 3 PUT X RESULT 6:ACT 3*SERV 3-> SERV 3 GET D READ D 6:POOL I'ACT 3-> ACT 3 ACT 3 op:ACT 3-> ACT 3 definitions G E T S N E W S 6(resp,init) - upd G E T S N E W S 6 o k ( i n i t , C H A N 1 G E T S N E W S6(resp)); P U T X R E S U L T 6(init,resp) - S E R V 3 P U T X R E S U L T 6(opn result(init),resp); G E T D R E A D D 6(resp,init) = = upd G E T D R E A D D 6 ok(init,POOL 1 G E T D R E A D D 6(resp)): ACT 3 op(Iocal) - let new = mk A C T 3 ( F A L S E , F A L S E ) in upd opn result(new,TRUE): end A C T 3 specification o f C H A N 1 exported operations C H A N l P U T SI SIG l O U T 8 : B O O L E A N * CHAN 1 C H A N I P U T $2 SIG 2 O U T 7 : BOOLEAN* CHAN 1

vol 33 n o 9 n o v e m b e r

1991

CHAN

1 ->

CHAN

I ->

CHAN 1 GET S NEWS 6:CHAN 1-> BOOLEAN state = record(dataAgres:boolean) initially mk C H A N I(FALSE): csp operations CHAN 1 reset:CHAN 1-> CHAN l definitions C H A N I P U T SI SIG l O U T 8(bool.resp) = = upd dataA~res(resp.bool); C H A N _ I P U T $2 SIG 2 O U T 7(bool.resp) = = upd data y~res(resp.bool); C H A N _ I G E T S N E W S 6(resp) guard data y~res(resp): - data pres(resp); CHAN 1 reset(local)-upd data pres(local.FALSE): end C H A N 1 specification of P O O L 1 exported operations P O O L I G E T D R E A D D 6: P O O L 1 - > B O O L E A N state = record(data pres:boolean) initially mk P O O L I(FALSE); definitions POOL I GET D READ D 6(resp)guard dataA~res(resp);-data pres(resp): end P O O L 1 specification of SERV 3 exported operations SERV 3 PUT X RESULT 6:BOOLEAN* SERV 3-> state = record(data pres:boolean) initially mk S E R V 3(FALSE): definitions SERV 3 P U T X R E S U L T 6(bool.resp) = = upd data pres(resp.TRUE); end S E R V 3 specification of SERV 2 exported operations S E R V 2 G E T $2 S I G N A L 2 7 : S E R V 2 - > state = rccord(dataAgres:boolean) initially mk S E R V 2(TRUE): definitions S E R V 2 G E T $2 S I G N A L 2 7(resp) - data pres(resp); end S E R V 2

SERV 3

BOOLEAN

specification of S E R V 1 exported operations S E R V 1 G E T SI S I G N A L I 8 : S E R V 1 - > B O O L E A N state = r e c o r d ( d a t a p r e s : b o o l e a n ) initially mk S E R V I ( T R U E ) : definitions S E R V 1 G E T SI S I G N A L 1 8 ( r e s p ) = = data~res(resp); end S E R V I end E X A M P L E processor allocation = 1 A C T 1 - > central. A C T 2 - > central. A C T 3 - > central. C H A N 1 - > central. P O O L 1 - > central. S E R V 3 - > cpu a. S E R V 2 - > cpu b. SERV 1 - > cpu c ',: process times = 1 G E T St S I G N A L 1 8 - > 1. P U T SI S1G I O U T 8 - > 1. A C T I o p - > 1. G E T $2 S I G N A L 2 7 - > 1. P U T $2 S I G 2 O U T 7 - > 1. ACT 2~p-> 1. G E T S N E W S 6 - > 1. P U T X R E S U L T 6 - > 1. G E T D R E A D D 6 - > 1. A C T 3 o p - > 1. C H A N 1 r e s e t - > I. I:

719