Extended Statecharts for the Modeling and Specification ... - CiteSeerX

Extended Statecharts for the Modeling and Specification of Manufacturing Control Software Systems* A. Suraj , S. Ramaswamy ** and K. S. Barber

Laboratory for Intelligent Processes and Systems, The Department of Electrical and Computer Engineering, The University of Texas at Austin, Austin, TX 78712-1084.

Abstract Building software systems that are easier to use implies addressing the issue of increasing complexities in managing processes and communication between processes. In order to manage complexity, it is very important to have tools, notations, and methodologies which support the designer's work during design resolution. This paper introduces Extended Statecharts as a comprehensive modeling mechanism for high level systems design. Extended Statecharts allow for the implicit representation of declarable problem-specific system soft failures, thereby allowing for failure related information to be incorporated into the high level system design. Temporal logic is used for verification of important design properties. An example of an assembly process is used to illustrate the capabilities of Extended Statecharts.

I. Introduction The primary objective in using graphical notations for design representation is their ability to capture important design attributes such as encapsulation, information hiding and modular abstractions, independent of implementation, as well as representational details of data objects used in the actual implementation. Most modeling tools and their extensions, by virtue of their flexibility in using graphical notations in different contexts, often provide an inconsistent approach for developing complex hierarchical system models. This provides an inherent inflexibility in building robust abstract high level system design which are independent of the implementational details but reusable across multiple implementation schemes. Moreover, such approaches also implicitly inhibit the intelligent use of these system design models in choosing an implementation strategy for a given design. Some

* This research is supported in part by the Texas Higher Education Coordinating Board and the National Science

Foundation ** Dr. Ramaswamy is with the School of Computer and Applied Sciences, Georgia Southwestern College, Americus, GA 31709. 1

desirable features of any modeling tool used to represent system designs include: (i) Promote simple, easy and general use: The structural and behavioral aspects of system/subsystem must be related and represented within the system design model. Moreover, the description of the system behavior should contain an implicit representation of the temporal knowledge regarding system activities, (ii) Support scalable hierarchy and minimal intrusion: The notations and associated techniques must support hierarchical specifications which allow the model to be incrementally built upon. By scalable hierarchy it is meant that the hierarchical design should expand not only like a conical tree structure in depth to support additional levels in the hierarchy, but must also (and most importantly from the perspective of this research) be able to accommodate the depth of representation within a limited number of levels in the hierarchy [53][23]. A design notation will support minimal intrusion if it allows for the streamlined representation of the system communication structure (between the various sub-systems, or, sub-designs), (iii) Support automation of analysis and simulation: Sufficient formality must be supported to allow formal analysis techniques to verify model properties, and, (iv) Visually explicit syntax and semantics: The notations used to represent activities or abstractions in the design must be visually explicit to understand. The use of object-oriented techniques offers the following advantages in modeling and simulation of realworld systems: (i) software reuse is enhanced when object-oriented techniques are applied efficiently in defining the system objects, (ii) objects in the system can be defined in close correspondence to real-world objects, (iii) rapid development of new software is promoted by reuse, (iv) the use of inheritance features enables the creation of new objects and associated methods with minimal effort, and, (v) the use of encapsulation features provide the appropriate distinction between object boundaries and is effective in identifying and controlling the propagation of errors. From a practical application point of view, object-oriented techniques employed for systems development enables effective software management and revision control in the software evolution process. Several software modeling tools and methodologies, based on object-oriented techniques, have been developed for system specification and analysis [9] [21] [22] [54] [59]. Complete object-oriented methodologies (from analysis through design) are discussed in [9] [21] [54]. In [22], an iterative method for object-oriented analysis and design is presented, which emphasizes proper construction, generalization and abstraction of classes. Sharble, in [59], presents a responsibility-based approach to define objects during systems development. A brief taxonomy of the characteristics to be considered when grouping concepts as objects is also presented. Object charts provide object-

2

oriented aspects of Statecharts and model system behavior as a set of traces of service requests received and generated by objects within the system [14]. DisCo defines a specification language based on Statecharts [33]. StimulusResponse (S-R) Machines focus on events and reactions to events as opposed to states and transitions and specifically identify responses to events [11]. Extended Systems Modeling Language (ESML) is a high-level formal specification technique based on extensions to data flow diagrams [52]. Rumbaugh's State Trees represent state hierarchies similar to Statecharts [55]. It is a static tool useful for object-oriented analysis. Extended Statecharts (ESC), introduced in this paper are dynamic models of system behavior. Modecharts add the notion of time to Statecharts [13]. However, they cannot have data values associated with events in the system. The ESC representation provides a way to have data values associated with events. It also represents an explicit way of integrating failure information in the system design process. Communicating Real-time State Machines (CRSM) represent another extension to state machines with guard commands for transitions [57]. Hierarchical Multi-State Machines [HMS] is a state based executable formalism that uses aspects of Petri Nets, Statecharts, Modecharts and Temporal logic [16]. State Machines for Object-Oriented Concurrent Hierarchical Engineering Specifications (SMOOCHES) has been developed as an environment to develop the derivation of the system information model and the system behavioral model [5][6]. SMOOCHES is the implementation platform for ESC. In this paper, a hierarchical approach to detailed specification of manufacturing control software design using Extended Statecharts (ESC) is presented. As often noticed in real world applications, the development of an abstract, high level, implementation independent design is both iterative and interactive. Therefore the development of an ESC model distinguishes two important design phases: (i) requirements tuning and (ii) behavioral tuning. The initial ESC specification is developed after the requirements tuning phase where the various system requirements have been studied. The behavioral tuning phase is used to refine the initial design into a detailed hierarchical, yet abstract design. For the tasks performed in the behavior tuning phase a more detailed knowledge of all the system requirements, the system operating environment and some knowledge about its final form and usage is necessary. Figure 1 illustrates such a prototyping model for the development of an abstract high level systems design. The paper is organized as follows: Extended Statecharts (ESC), that further the use of Statecharts for preliminary system design representation is presented in Section II. Section III illustrates the use of the ESC based approach in developing an implementation independent design of a simple manufacturing control software system.

3

Section IV provides a temporal logic based approach for the formal verification of ESC designs. The final section, Section V, concludes the paper. Decompositon

Refinement

Defining new system requirements Requirements tuning Constraints Schedules

resources

Responsibility Analysis

Agent Design

requirements

resource behaviors

Behavioral tuning

Refine System Requirements Evaluate Agent Behavior

Refine Agent Behavior

Defining new agent behaviors Final System Design Prototype

Figure 1. A prototyping model for system design

II. Extended Statecharts (ESC) In this section, Extended Statecharts (ESC), a hierarchical extension to Statecharts both with respect to functional and timing extensions are introduced. An ESC is a 4-tuple (S, E, G, T), where, S is a set of states, E is the set of events, G is the set of guards and T is the set of transitions. In the sequel the important ESC features are introduced. It is assumed that the reader is familiar with statechart notations [24-29].

2.1 Basic ESC notations n

The set of states S is defined as, S = U S i where, n is the number of levels in the model hierarchy. Exiti= 1

safe states represent states wherein a substate is in a stable state to process the transition out of a parent state. That is, events causing a transition between higher level (parent) states are handled only if the substate of the parents' state is an exit-safe substate. This extension explicitly allows the developer to specify certain non-interruptable critical operations. Non exit-safe states are states that are not exit-safe and hence do not allow for higher level state transitions. To illustrate, let s be a state where an outgoing transition t occurs on an event e. Let {a, b, c} be the set of substates under s. When specifying the substate life cycle for s, the developer may not desire an outgoing transition on s to occur until substate c is reached. Therefore c will be designated as an exit-safe state. In another implementation, a substate life cycle may be defined by the substates in {a, b, c, d} , and c, d can be designated as

4

"exit-safe". Thus, t can occur in either state c or d of the substate life cycle. Exit-safe states can be used in different ways to define certain desirable system characteristics. Figure 2 illustrates the graphical notations associated with ESC-based designs. The dashed rectangle represents the definition of an Agent. States at the highest levels of a hierarchy are referred to as agents which are used for the definition of higher level classes in an Object-Oriented implementation. The solid rectangle is used to represent a normal state that is decomposed immediately. The arrow pointing to a state denotes a default state that the system reaches first among other states at the same level. The shaded and rounded rectangle is used to represent decomposed states. This means that the state S is decomposed further in another diagram. Intra-level and inter-level transitions are discussed in section 2.2.

S

S

S - Agent

S - State

S

S

S

S - Default state

S - Decomposed state

S

S - Exit safe state

S - Non exit-safe state

Intra-level transitions

Inter-level transitions

Figure 2. ESC graphical notations Y D C

¬e7 ∨ (val(e3) = 35) (val (e2) - val(e3)) > 50

A

L

e8

I e7

¬ e1/ e4

K

J

o in G

¬ e1 / {e5, e6}

B

e1 ∧ e2

in (A:K)

M

N

τm (e8, 2) / e6

Figure 3. ESC example graphical representation Figure 3 shows an example ESC representation. In the figure, Y is an agent that has states C and D in an AND composition. State C has substates A and B that are in a XOR combination, A being the default state. D has substates L, M and N where L is the default state. Notice that J, K and M are exit-safe states. Therefore, a

5

transition from Y to another higher level parent state may occur if and only if the substate of C is either J or K and if substate of D is M.

2.2 Hierarchical Transfer of State Information Two types of transitions are distinguished to manage the hierarchical information transfer between states. These include: (i) Intra-level transitions ( Tint ra ): These are transitions between states in the same hierarchical level and (ii) Inter-level Transitions ( Tint er ): These are transitions between states in different hierarchical levels. The graphical representation of these two transitions between states is shown in Figure 2. defined as

T , the set of all transitions is

T ⊆ SXLXS where L is a set of transition labels1. T is also defined as T = Tint ra ∪ Tint er . The

distinction between these two transition types is essential in failure modeling. There are two important rules that apply for transitions between states at two different hierarchical levels: (i) Transitions from a state at a lower hierarchical level to a state at a higher level are possible only when the lower level state is non exit-safe. (ii) Transitions from a state at a higher hierarchical level to a state at a lower level do not have such a restriction. A transition from a lower level state decomposition to a higher level state can occur on two conditions: (i) the operation is successful and (ii) the operation is unsuccessful and the system in that state requires external intervention (i.e. help in proceeding further). The first phenomenon is implicitly captured by the notion of exit-safe states. The second phenomenon needs to be captured explicitly because it is a failure problem. Thus, we have inter level transitions that occur only if the state at the lower level diagram is non exit-safe. In Figure 3, the transition from state A to state B can happen if the guard oin (G)2 is true when the system is in either state J or K. This is an intra-level transition. The transitions from state I to B and from state B to K are represented using dashed lines since I and K are at the same level of hierarchy and B is at a higher level compared to I and K. These are inter-level transitions.

2.3 Transition Labels L is the set of transition labels defined as L = {(g, a) / g ∈ G, a ∈ A ⊆ 2 E } . Where, G is the set of guards and the A is the set that contains subsets of all the events in the system. Transition labels in ESC representation (see Figure 4) have a guard that acts as the input condition which must be satisfied for the transition to occur. This is followed by the event ξ , that always occurs (this is implicit in 1 Transition labels are discussed in the Section 2.3. 2 The meaning of this guard is explained in Section 2.4 under "Temporal Operators".

6

the transition labels and is not denoted in the examples). The "slash" (i.e. "/") is used to separate the input and the output processes. Output condition(s) or an action(s) can be a simple event or a set of events. These action event(s) is optional. If an action event(s) is specified, it is immediately generated and is regarded as an internal event that may cause transitions in other components. The input conditions and the event causing the transition are incorporated in the guard itself. This removes the need for having separate queues for events and input conditions during implementation. In Figure 3, the transition from I to J is caused by a guard check(e7) 3 (i.e. e7). check(e7) is represented as just e7 for simplicity. This guard does not produce any action. But, the transition from state I to state K is caused by a guard ¬e1 followed by an action e4. This means event e4 is generated immediately. The transition from state B to state K produces two events e5 and e6 which are represented in the set {e5, e6}. Guards and the evaluation of guards to make transitions are discussed in the next section.

(Guard): ξ / [Action(s)]

A

B

Figure 4: Transition labels in ESC

2.4 Guards on Transitions E, the set of all events in the system is defined as E = E BE ∪ ECE where, E BE is the set of basic events and ECE is the set of composite events and E BE ∩ ECE = φ . Guards are formed by the combination of four basic functions and different kinds of operators acting on events/states. These operators and functions may be combined to form complex conditions. These complex conditions will be called as "complex events" from now on. The functions include: (1)

in( x) which denotes that the system is in state x. in( x: y) denotes that the system is in state y

where, y is the immediate substate of x. In Figure 3, the guard in( A: K ) transitions state M to L in D. This guard is true when the system is in state K which is the exit-safe substate of A. (2)

τ m (e, n) which denotes a time-out event that is generated if event e happened n steps earlier

( e ∈ E and n ∈ N − {0 } , where N is the set of Natural numbers). In Figure 3, the transition from N to M

3 The meaning of this guard is explained in Section 2.4.

7

in D is caused by a time-out event. The guard is true if event e8 occurred two time steps ago. This transition causes the action event e6. (3)

check(e) which returns true if event e occurs and false if it does not occur. check(e) is denoted as

just e for simplicity throughout this paper. In Figure 3, the transition from state I to K is caused by

¬check(e1) / e4 which is represented as ¬e1 / e4. Similarly, the guard check(e1) ∧ check(e2) transitions state L to M and is represented as e1 ∧ e2. The meaning of the operators ¬ and ∧ will be covered in this section under "Logical Operators". (4)

val(e) which returns a data value associated with event e. In Figure 3, the transition from state

N to L is D is caused by the guard ¬e7 ∨ (val(e3) = 35) which utilizes the function val(e3) , the logical operators ¬ and ∨ and the arithmetic operator '='. This guard will be explained at the end of this subsection. The operators used in the construction of guards are classified into three categories: (1)

Arithmetic Operators (+, -, , = ): These operators act only on events that have associated data

values. For example, consider two events e1 and e2 that represent temperature values ( e1 , e2 ∈ E ); then, the guard g ∈ G may be g: (val(e1 ) + val(e2 )) > 20 . This means that the guard evaluates to true when the total value of the temperatures (i.e. val(e1 ) + val(e2 ) ) becomes greater than 20. Similarly, conditions such as 'equal' or 'less than' can be checked. In Figure 3, the guard (val(e1) − val(e2)) > 50 has to be true for the transition from state I to state B. (2)

Logical Operators ( ∧ , ∨ , ¬): The logical operators act on both events and states. If g ∈ G and

g = e1 ∨ e2 (or e1 ∧ e2 ) where e1 , e2 ∈ E , g becomes true when either event e1 or e2 (or e1 and e2 ) occur(s). In the same manner, g = ¬e1 implies that the guard is true when e1 does not occur. In Figure 3, the transition from state L to state M occurs if the guard e1 ∧ e2 is true. The transition from state B to state K occurs if ¬e1 is true and in turn produces events e5 and e6. Some of the rules for the logical operators are summarized as follows: (a) g ∈ G ⇒ ¬g ∈ G (b) e ∈ E ⇒ e, ¬e ∈ G (c) τ m (e, n) ∈ G and

¬τ m (e, n) ∈ G (d) if e1 , e2 ∈ G then e1 ∨ e2 , e1 ∧ e2 ∈ G . (3)

Temporal Operators (o,

states. o stands for always ,

◊ , Ο , U ): Within guard functions, the temporal operators act only on

◊ stands for eventually , Ο stands for next and U stands for unless. If

8

s1 ∈S , g:o s1 (or g:oin ( s1 )) is true if and only if in ( s1 ) is true at the present step and continues to be true in all the steps from now on. g: ◊ s1 (or g: ◊ in ( s1 )) is true if and only if in ( s1 ) is true at least once in any step in the future. g: Ο s1 (or g: Ο in ( s1 )) is true if and only if in ( s1 ) is true in the next step (i.e. if the system reaches state s1 in the next step) . Finally, a guard g: s1 U s2 (or g:in ( s1 ) U in ( s2 )) is true if and only if in ( s1 ) is true until in ( s2 ) (i.e. the system continues to be in state s1 till

s2 is reached).

The guard becomes false once s2 is reached. In Figure 3, the guard oin G transitions state A to state B. This transition implies that the system is in state G (not shown in the figure) and would remain so for all the future time steps. In Figure 3, the transition from state N to state L occurs when ¬e7 ∨ (val(e3) = 35) is true (i.e. when event e7 has not occurred or if the value of event e3 is equal to 35).

2.5 Failure Modeling Potential system failures/errors that are identified through sensory inputs are classified into two categories. (1)

Soft failures: System soft failures are those kinds of failures from which the system may recover

and resume normal system operations without any intervention from the external environment. Error classification of previously known errors (and thus incorporated within the ESC design) occurs during the system modeling stage. So when a section of the system fails, it might recover from the error and resume normal operations. (2)

Hard failures: System hard failures correspond to fatal failures from which the system cannot

recover by normal mechanisms and needs external intervention. The system reaches a stop state when one of these errors occur and these errors are not explicitly modeled by ESC. The most important characteristic of ESC is their ability to model failure behavior as part of the system design. Therefore the use of ESC to design manufacturing control processes may lead to improved quality. ESC designs integrate failure operations by exploiting the advantages of using XOR configurations with the transition extensions proposed earlier in this section. For example, in Figure 3, the higher level states A and B are in an XOR configuration where A represents the normal system operation and B represents the state associated with failure operations or an idle state. In the above example, the system can be in either state A or state B which is used to represent a system that is either working or idle.

9

III. Example In this section the modeling extensions discussed in the previous sections are illustrated by means of a small example The example illustrates the modeling concepts for representing an abstract high-level design. The block diagram in Figure 5 illustrates a factory floor consisting of a conveyor, a robot, two cutting machines, and an output buffer for the cutting machines to be employed for a simple assembly process.

Part

In

Out

Cutting Machine

C o n v e y o r

Robot

Buffer

in-path out-path

Cutting Machine

Figure 5. Block diagram of assembly A brief high level description of the system operations is as follows: Parts arriving on a conveyor are picked up by the robot and moved to one of the two cutting machines. As soon as the part arrives on the conveyor and is ready to be picked up (i.e. it enters within the robots’ workspace), a sensor signals the robot. The robot checks for a free cutting machine; picks up the part; and moves it to the appropriate cutting machine. Each part description is assumed to contain information related to the kind of job to be performed on it. The cutting machine uses this job description and performs the specific job and transfers the part on an output buffer. At some appropriate point, the robot moves the finished part from the buffer back to the conveyor. We are assuming that the parts arriving on the conveyor are well spaced in time which removes the need for an input buffer. The process of moving the part from the conveyor to either of the two cutting machines is the “in-path” and the process of moving it from the buffer to the conveyor is the “out-path” (Figure 5). From the given problem description the following system agents are derived as part of the requirements tuning phase (See Figure 1): (i) Part: The part agents carry information related to a particular part and the exact details of the job to be performed on the part. Additionally, the part agent also contains information about the part itself, such as its dimensions, type, etc. (ii) Robot: The robot agent contains information about the robot(s), its

10

operations, availability, etc. (iii) Cutting Machine: The cutting machine agent contains information about the cutting process, the cutter(s) and their availability, (iv) Buffer: The buffer agent maintains the status of the output buffer that is used by the robot and cutting agents. The agents 'PART', 'ROBOT', 'CUTTER1', 'CUTTER2' and 'BUFFER' are in an AND composition as shown in Figure 6. Tables I and II at the end of this section provide a complete description of all the events associated with the state transitions. In the rest of this section, ESC models of the above agents are described. PART

CUTTER 1

ROBOT

CUTTER 2

BUFFER

Figure 6. High-level Agent decomposition

3.1 Part Agent The PART agent has been decomposed in Figure 7(a). The states 'into conveyor', 'robot move' and 'into cutter' of the PART are decomposed further and hence represented as shaded rectangles (See Figure 2 for graphical notation). The part enters the system (shown as the default state 'into conveyor') and defaults to the 'on conveyor' state (Figure 7(b)). If the event e0 occurs (i.e. a signal for the robot to pickup part) it enters the exit-safe state 'ready for pickup'. If the event ¬e0 occurs and the buffer is full at the same time, the system is designed to process only the "out-path" (composite event c6) and goes into the 'suspend' state. Once the buffer is empty, it returns from the 'suspend' state to the default state. At the higher-level, when the part is ready for pickup (the event 'e1') by the robot (Note that the system needs to be in the exit-safe state 'Ready for pickup' of the 'into conveyor' state for it to process event e1 and go to the 'robot move' state), the part enters the 'robot move' state (Figure 7(a)) from the 'into conveyor' state. In the 'robot move' state, the part is picked up, moved and then putdown on one of the cutters (Figure 7(c)). This results in the part moving into the 'into cutter' state after the robot reaches the cutter, placing the part on the cutter and releasing its arm (this transition is caused by the composite event c9) (Figure 7(a)). Once the part is cut, it enters the 'into buffer' state when the system is in the 'put on buffer' state of the 'CUTTER1' or 'CUTTER2'. The event e2 triggers the transition from 'into buffer' to the 'robot move' state. Once the conveyor is reached and the

11

robot arm is released (event (e15 ∧ e11) ), the part is 'back to conveyor' and produces the event e20 which decrements the buffer count. The system goes into the 'Error' state of the PART if both the cutters malfunction (event c11) or when the robot drops a part or malfunctions (event c12) which can occur when the PART is in states 'into cutter' or 'robot move'. The system recovers from the error state if a soft failure occurs in the system i.e. if the part is reachable, the robot is reset or the cutters are reset. PART

c 12 e1

into conveyor

c8 back to conveyor

robot move

c5 e2

c9

into cutter

into buffer

Error

c 10

c 11

7(a) into conveyor

robot move

on conveyor e0

c7

pickup part

e9

into cutter move part on cutter

c6

e 19

e 13 Ready for pickup

Suspend

putdown part

7(b)

7(c)

part cut

7(d)

Figure 7. ESC decomposition of the Part Agent and its substates

3.2 Robot Agent The 'ROBOT' (Figure 8(a)) is in the 'idle' state by default and transitions into the 'pickup' state when the part is ready for pickup from the conveyor or the buffer (event c1= e1 ∨

e2 ). The decomposed 'pickup' state is

represented in Figure 8(b). The robot starts the initialization process and enters the 'init complete' exit-safe state if there is no malfunction (event c14) or it enters the 'pickup aborted' state if there is a malfunction (event c16). It starts the pickup process once the initialization is complete and when either of the two cutters are free (event c2). If the robot does not drop the part, the robot transitions into 'pickup succeeded' state and if it does drop the part while

12

in motion, it enters the 'pickup aborted' state. Notice that the pickup is aborted if either the robot malfunctions, robot drops part or when both the cutters malfunction. This could happen during initialization or during the pickup process itself. Shown in Figure 8(a), the system enters the 'move' state (which is decomposed in Figure 8(c)) once the pickup is complete (event e8).

pickup

ROBOT init start

c 17 idle

c1

c 14

pickup

e 15

init complete

c5 Pickup or Move error

e8 c 27 c 13

pickup aborted

pickup succeeded

c2 c 15

move

putdown

c 16

pickup begin

c 18

e7

8(a)

8(b) move

init start e3

c19

init complete

move failed

e9

c 12

δ move move succeeded

c4

c3

e 14 c 3

dstn reached

dstn not reached

¬ e 13

8(c) Figure 8. ESC decomposition of the Robot Agent and its substates The robot starts the initialization (Figure 8(c)) for the move process and enters the ‘init complete’ exit-safe state. When the initialization is successful, the robot moves to the ' δ move' state. If the initialization is unsuccessful, the robot transitions into the 'move failed' state. From the ' δ move' state the robot transitions to ‘dstn reached’ if the destination is reached (i.e. either of the cutters or the conveyor is reached) or into ‘dstn not reached’ if its not. Note that both the events c3 and c4 produce the action event e14 which causes a transition to ‘move 13

succeeded’ and only c3 produces both e13 and e14. But in ‘move succeeded’ if ¬e13 occurs, it takes the system back to the ‘dstn not reached’ state. Therefore the robot makes certain moves until the destination is reached. The robot malfunction can occur during initialization or during the move process. The move fails when there is a malfunction or if the robot drops a part. Once the exit-safe state ‘move succeeded’ is reached, the system goes from ‘move’ to the ‘putdown’ state (event c13) in ROBOT. In this state, the robot places the part on the conveyor or the cutter depending on whether the robot processing the “in-path” or the “out-path” (see Figure 5). The robot goes back to the ‘idle’ state when the robot arm is released (Figure 8(a)). In the ROBOT agent, errors can occur during ‘pickup’ or ‘move’ (events c17 and c18) and the system goes into ‘Pickup or Move error’. If the error occurred due to the dropping of the part by the robot and if the part is reachable, the system recovers from the error by transitioning into the ‘pickup’ state again. The same occurrence can transpire if both the cutters fail. The robot waits for either of the cutters to recover and then transitions back into ‘pickup’ state (event c5). If the error occurred due to a robot malfunction and if it is not a hard failure, the robot is reset and returns to the default ‘idle’ state (event c27).

3.3 Cutting Agent The 'CUTTER1' (Figure 9(a)) is 'idle' by default and goes into the 'cut' state once cutter1 is reached and the robot's arm is released (event e15 ∧ e10a) then produces event ¬e20 signifying that cutter1 is not free anymore. The ‘cut’ state is decomposed in Figure 9(b). Cutter1 starts the initialization process in the ‘cut’ state and goes into the ‘init complete’ exit-safe state if there is no malfunction. Once the initialization is complete and when it gets the job description from the part (event c24), cutter1 starts the cutting process in the state ‘cut begin’. Cutter1 transitions to the ‘cut failed’ state if there is a cutter1 malfunction (event e17a). Once the cutting process is complete, it transitions to the ‘cut succeeded’ state (event c25). The ‘cut failed’ state is reached during initialization or during the cutting process.

14

cut

CUTTER 1 init start e 17a

c 23

c 20

cut

idle

init complete

c 26

cut succeeded

cut failed

Error c 24

c 21

c 22

c 25

c 28

put on buffer

Cut Begin

9(a)

e 17a

9(b)

Figure 9. ESC decomposition of the Cutting Agent and its substates From Figure 9(a), the system transitions into the ‘put on buffer’ state when the cutting process is complete and if the buffer is not full and signals that the part is on the buffer by producing event e2 (event c22). Cutter1 goes back to the ‘idle’ state and signals it is free and the buffer count is incremented (event c21). The system transitions into the ‘Error’ state of the CUTTER1 from ‘cut’ only when cutter1 malfunctions (event c26). Cutter1 signals the system that it is not free anymore and goes back to the ‘idle’ state if its reset as long as its not a hard failure (event c28). The decomposition of the agent CUTTER2 is identical to the CUTTER1 and hence is not shown separately.

3.4 Buffer Agent The BUFFER agent (Figure 10) is either 'empty' by default or 'full'. The events e22 and e23 signify the transitions between these states. Tables I and II enumerate the basic and composite events in the system. BUFFER empty e 22

e 23 full

Figure 10. ESC decomposition of the Buffer Agent and its substates

15

Table I: Basic Events

e0 - Sensor Signal

e1 - Ready for Pickup from conveyor

e2-Ready for Pickup from buffer

e3 - Robot Malfunction

e4 - Pickup Init Complete

e5 - C1 Free

e6 - c2 Free

e7 - Robot Dropped Part

e8 - Pickup Complete

e9 - Move Init Complete

e10a - Cutter1 Reached

e10b - Cutter2 Reached

e11 - Conveyor Reached

e12 - Cutter Init Complete

e13 - Move Complete

e14 - Moving Done

e15 - Robot Arm Release

e16 - Job Description

e17a - Cutter1 Malfunction

e17b - Cutter2 Malfunction

e18 - Cut Finished

e19 - Cut Process Complete

e20 - Buffer Count Decremented

e21 - Buffer Count Incremented

e22 - Buffer Full

e23 - Buffer Empty

e24 - Part Reachable

e25 - Reset Robot

e26 - Robot Hard failure

e27a - Reset Cutter1

e27b - Reset Cutter2

e28a - Cutter1 Hard Failure

e28b - Cutter2 Hard Failure

Table II: Composite Events

c1 - e1

∨ e2

c3 - ( ¬ e3 c5 - (e24

c2 - e4

∧ ((e10a ∨ e10b) ∨ e11 )) / { e13, e14 }

∨ e25 ∨ e27a ∨ e27b) ∧ ¬ (e26 ∧ e28a ∧ e28b )

c7 - in (Buffer:Empty) c9 - e15

∧ e17b

c14 -

¬ e7 / e8

c27 -

∨ e7 ∨ (e17a ∧ e17b)

c18 - in (Move:Move failed)

¬ e3 / e9 ¬ e17a / e12

c25 - ( ¬ e17a

∧ e11) / e20

¬ e3 / e4

c16 - e3

c21 - e2 / {e5, e21} c23 -

¬ e0 ∧ (in (Buffer:full) U in (Buffer:Empty) ) / ¬ e1

c12 - e3

c17 - in (Pickup:Pickup Aborted) c19 -

c6 -

∧ ¬ ((e10a ∨ e10b) ∨ e11 )) / e14

c10 - in (Cutterx: Put on Buffer) (x = a or b)

c13 - in (move:move succeeded) / e15 c15 -

c4 - ( ¬ e3

c8 - (e15

∧ (e10a ∨ e10b)

c11 - e17a

∧ ((e5 ∨ e6) ∨ e21)

∧ e18 ) / e19

c20 - (e15

∧ e10a ) / ¬ e5

c22 - (e19

∧ ¬ in “Buffer:Full”) / e2

c24 - e12

∧ e16

c26 - in (Cut:Cut Failed) /

¬ e24 ∧ e25 ∧ ¬ e26

c28 - e27a

16

∧ ¬ e28a

¬ e5

IV. ESC Design Verification The most important properties with respect to manufacturing control software are: liveness and safety. The liveness property verifies that the system keeps functioning under certain conditions. The safety property assures that certain error events will not occur and thereby ensures that the system functions normally. Formal analysis of an ESC design includes proofs of both the liveness and safety properties. The proofs presented in the following sections will use the properties of propositional and temporal logic listed below [40]. Sections 4.1 and 4.2 present two distinct liveness and safety properties for the system.4 If

w , w1 and w2 are logical formulas,

P1:

¬◊w ≡ o ¬w

P2:

◊¬w ≡ ¬ o w

P3:

¬(w1 ∧ w2 ) ≡ (¬w1 ∨ ¬w2 )

P4:

¬(w1 ∨ w2 ) ≡ (¬w1 ∧ ¬w2 )

P5:

(w1 ⇒ w2 ) ≡ (¬w1 ∨ w2 )

P6:

◊(w1 ∧ w2 ) ≡ (◊w1 ∧ ◊w2 )

P7:

◊(w1 ∨ w2 ) ≡ (◊w1 ∨ ◊w2 )

P8:

w1 ∧ (w2 ∨ w3 ) ≡ (w1 ∧ w3 ) ∨ (w1 ∧ w3 )

4.1 Liveness Properties The liveness properties specify the events that can occur and the states that can be reached in a system. Liveness Property 1: When the Sensor Signal occurs (i.e. the part is ready for pickup from the conveyor) and the robot is operational, the part is moved to one of the cutters eventually. The proof of this property is given below.

∧ ¬ e3) ⇒ ◊ in (“Part:into cutter”)]

(1)

o[ (e0

(2)

From ESC decomposition and assuming e10 = e10a

∨ e10b, we get o[ (e0 ∧ ¬ e3) ⇒ ◊ (e15

∧ e10)] (3)

Assuming the negation of Liveness Property 1:

¬ o[ (e0 ∧ ¬ e3) ⇒ ◊ (e15 ∧ e10)]

4 Although other liveness and safety properties for the example may be defined, we are interested in capturing the

important characteristics of the high level design representation and the following safety and liveness properties are sufficient to address this concern. Therefore, we describe only two liveness and two safety properties which are most relevant to the desirable characteristics of the high level design specification. 17

(4)

Applying P5:

¬ o[ ¬ (e0 ∧ ¬ e3) ∨ ◊ (e15 ∧ e10)]

(5)

Applying P2:

◊ ¬ [ ¬ (e0 ∧ ¬ e3) ∨ ◊ (e15 ∧ e10)]

(6)

Applying P4 and P6:

(7)

Applying P3 :

◊ [(e0 ∧ ¬ e3) ∧ ( ¬ ◊ e15 ∨ ¬ ◊ e10)]

(8)

Applying P8:

◊ [(e0 ∧ ¬ e3 ∧ ¬ ◊ e15) ∨ (e0 ∧ ¬ e3 ∧ ¬ ◊ e10)]

(9)

Applying P7 and P1:

◊ [(e0 ∧ ¬ e3) ∧ ¬ ( ◊ e15 ∧ ◊ e10)]

◊ (e0 ∧ ¬ e3 ∧ o ¬ e15) ∨ ◊ (e0 ∧ ¬ e3 ∧ o ¬ e10)

From the conclusion of step 9, the first disjunct signifies that eventually, e0 , occur. Consider the composite event c13 = e14 / e15,

¬ e3 and permanently ¬ e15

¬ e15 implies that e14 does not occur which further implies

that 'move succeeded' state is never reached inside the 'move state'. This can happen only when the robot malfunctions which produces event e3. The first disjunct produces a contradiction since The second disjunct can be broken down into above disjunct causes event c4 = ( ¬ e3

¬ e3 occurs.

◊ (e0 ∧ ¬ e3 ∧ o( ¬ e10a ∧ ¬ e10b)) by applying P4. The

∧ ¬ ((e10a ∨ e10b) ∨ e11 )) / e14 (since its guard is true) which takes the

event to the state “dstn not reached” (Assuming that the system is in the “ δ move” state at the present step). The system can never get to the “dstn reached” state since c3 = ( ¬ e3

∧ ((e10a ∨ e10b) ∨ e11 )) / { e13, e14 } can never

occur. This would cause event e3 to occur which is a contradiction. The negation of Liveness Property 1 produces a contradiction which proves the property. Liveness Property 2: If the part is cut successfully and the robot is operational, it eventually ends up back on the conveyor. That is,

∧ ¬ e3) ⇒ ◊ in (“Part:back to conveyor”)]

(1)

o[ (in (“cut:cut succeeded”)

(2)

From ESC decomposition : o[( ¬ e17a

∧ e18 ∧ ¬ e3 ) ⇒ ◊ (e15 ∧ e11)]

Following steps 3 to 9 just as in proof of liveness property 1, we get

◊ ( ¬ e17a ∧ e18 ∧ ¬ e3 ∧ o ¬ e15)

∨ ◊ ( ¬ e17a ∧ e18 ∧ ¬ e3 ∧ o ¬ e11) From the proof of Liveness property 1, we can see that o ¬ e15 implies that e3 occurs which is a contradiction of the first disjunct. Similarly for the second disjunct, we can see that o ¬ e11 implies e3 would occur which is a contradiction. Hence both the disjuncts produce a contradiction of the negation of Liveness Property 2 and this proves the property.

18

4.2 Safety Properties Safety properties specify the events or states that may not occur in a system. Whenever a soft failure occurs, the system eventually gets back to normal operation. For a robot, the soft failure can occur (under the assumptions that a robot hard failure does not occur in the system) if the (1) robot dropped the part or if (2) robot malfunctions. Safety Property 1: If the robot drops a part and the part is reachable and if its not a hard failure, the robot picks up the part eventually. That is,

∧ e24 ∧ ¬ e26) ⇒ ◊ in (“Robot:pickup”)]

(1)

o[ (e7

(2)

From ESC decomposition : o[ (e7

(3)

Rewriting c5 = (a

o[ (e7

∧ e24 ∧ ¬ e26) ⇒ ◊ c5 ]

∧ ¬ b) where a = (e24 ∨ e25 ∨ e27a ∨ e27b) and b = (e26 ∧ e28a ∧ e28b ) :

∧ e24 ∧ ¬ e26) ⇒ ◊ (a ∧ ¬ b)] ¬ o[ (e7 ∧ e24 ∧ ¬ e26) ⇒ ◊ (a ∧ ¬ b)]

(4)

Assuming the negation of Safety Property 1:

(5)

Applying properties P5, P2, P4, P6, P3, P8, P7 and P1:

◊ (e7 ∧ e24 ∧ ¬ e26 ∧ o ¬ a ) ∨

◊ (e7 ∧ e24 ∧ ¬ e26 ∧ o b) (6)

Substituting for a and b:

(7)

◊ (e7 ∧ e24 ∧ ¬ e26 ∧ o ¬ (e24 ∨ e25 ∨ e27a ∨ e27b)) ∨ ◊ (e7 ∧ e24 ∧ ¬ e26 ∧ o (e26

∧ e28a ∧ e28b )) (8)

Applying P4:

(9)

◊ (e7 ∧ e24 ∧ ¬ e26 ∧ o ( ¬ e24 ∧ ¬ e25 ∧ ¬ e7a ∧ ¬ e27b)) ∨ ◊ (e7 ∧ e24 ∧ ¬ e26 ∧

o(e26

∧ e28a ∧ e28b ))

In step 7, we can see the direct contradiction between the events e24 and between the events e26 and

¬ e24 in the first disjunct and

¬ e26 in the second.

Safety Property 2: If the robot malfunctions and its not a hard failure, the robot resets itself eventually. That is,

∧ ¬ e26) ⇒ ◊ e25 ]

(1)

o[ (e3

(2)

Negation of Safety Property 2:

¬ o[ (e3 ∧ ¬ e26) ⇒ ◊ e25 ]

19

(3)

Applying properties P5, P2, P4 and P1:

◊ [e3 ∧ ¬ e26 ∧ o ¬ e25]

The final statement states that eventually, events e3, contradiction comes from the fact that permanently i.e. if event e26 occurs and the occurrence of

¬ e26 and permanently ¬ e25 will occur. The

¬ e25 can occur only when there is a hard failure in the system

¬ e26 contradicts this fact. This proves Safety Property 2.

V. Conclusions In this paper, ESC have been proposed as a modeling mechanism for the specification of high level system designs. An ESC design of an example assembly process has been presented. Temporal logic has been successfully used to verify the liveness and safety properties for the assembly example. The notion of exit-safe states in ESC is shown to be useful for representing reactive systems. The ESC hierarchy and the two transition types were derived to explicitly capture failure information within the high level system design. The different functions and operators defined on the events have been used to provide a complete event structure. The exploratory research described in this paper is shown to provide a simple prototype based approach to the development of detailed hierarchical representation of complex system models. Current research is focused on combining Petri Net extensions with ESC to derive a nested dual approach for representing the complete software design where Petri nets are used for representing lower level system details.

References (1)

Gul A. Agha, "ACTORS: A Model of Concurrent Computation in Distributed Systems," Cambridge,

Massachusetts: The MIT Press, 1986. (2)

M. W. Alford, et al., "Distributed Systems: Methods and Tools for Specification," Lecture Notes in Computer

Science, 190, Springer-Verlag, New York, 1985, pp. 270 - 285. (3)

B. Alpern, F. Schneider, "Defining Liveness," Inf. Process. Lett., vol. 21, no. 4, Oct. 1985, pp. 181 - 185.

(4)

B. Barcio, S. Ramaswamy, K. S. Barber, May 1995,, "OARS: An Object-Oriented Architecture for Reactive

Systems Development", IEEE Intnl. Conf. on Robotics and Automation.

20

(5)

B. Barcio, S. Ramaswamy, R. Macfadzean, K. S. Barber, "Object-Oriented Analysis, Modeling, and Simulation of

a Notional Air Defense System", IEEE International conference on Systems, Man and Cybernetics, Vancouver, Ca. Oct. 1995, Vol. 5, pp. 3983-3988 (6) B. Barcio, "SMOOCHES: State Machines for Object-Oriented Concurrent, Hierarchical Engineering Specifications", M. S. Thesis, Dept. of ECE, Univ. of Texas at Austin, Austin. (7)

Kenneth Basye, et al., "A Decision-Theoretic Approach to Planning, Perception, and Control," IEEE Expert,

1992. (8)

S. Bear, P. Allen, D. Coleman, F. Hayes, "Graphical Specification of Object Oriented Systems," ECOOP/OOPSLA

1990 Proceedings, Ottawa, Canada, Oct. 1990, pp. 28 - 37. (9)

Grady Booch, "Object Oriented Design with Applications," Redwood City, California: The Benjamin/Cummings

Publishing Company, Inc., 1991. (10)

Y. Brave, M. Heymann, "Control of Discrete Event Systems Modeled as Hierarchical State Machines," IEEE

Transactions on Automatic Control, vol. 38, no. 12, Dec. 1993, pp. 1803 - 1819. (11)

G. W. Cherry, "Stimulus-Response Machines: A New Visual Formalism for Describing Classes and Objects," ACM

SIGSOFT Software Engineering Notes, vol. 18, no. 2, Apr. 1993, pp. 86 - 95. (12)

Lawrence A. Ciscon, "A Communications and Interaction Model for Intelligent Cooperating Robots," Ph.D., Rice

University, May 1993. (13)

P. C. Clements, C. L. Heitmeyer, B. G. Labaw, A. K. Mok, "Applying Formal Methods to an Embedded Real-Time

Avionics System", Proceedings of the First IEEE Workshop on Real-Time Applications, New York, 1993, p. 46 - 49. (14)

D. Coleman, F. Hayes, S. Bear "Introducing Objectcharts or How to Use Statecharts in Object-Oriented Design,"

IEEE Transactions on Software Engineering, vol. 18, no. 1, Jan. 1992, pp. 9 - 18. (15)

Alan Davis, "A Comparison of Techniques for the Specification of External System Behavior," Communications

of the ACM, vol. 31, no. 9, Sept. 1988, pp. 1098 - 1115. (16)

Armen Gabrielian, Matthew K. Franklin, "Multilevel Specification of Real Time Systems," Communications of

the ACM, vol. 34, no. 5, May 1991, pp. 51 - 60. (17)

M. Ganti, P. Goyal, S. Podar, "An Object-Oriented Software Application Architecture," Proceedings of the 12th

International Conference on Software Engineering, Long Beach, CA, 1990, pp. 212 - 220.

21

(18)

D. Garlan, C Scott, "Adding Implicit Invocation to Traditional Programming Languages," 15th International

Conference on Software Engineering, Long Beach, 1993, pp. 447 - 455. (19)

R. Gerber and I. Lee, "A Layered Approach to Automating the Verification of Real-Time Systems", IEEE

Transactions on Software Engineering, vol. 18, no. 9, Sept. 1992, pp. 768-784. (20)

C. Ghezzi, D. Mandrioli, A. Morzenti, "TRIO: A Logic Language for Executable Specifications of Real-Time

Systems", Journal of Systems Software, June 1980. (21)

Neal Goldstein, Jeff Alger, "Developing Object-Oriented Software for the Macintosh: Analysis, Design, and

Programming," Reading Massachusetts: Addison-Wesley Publishing Company, Inc., 1992. (22)

S.Gossain, B. Anderson, "An Iterative-Design Model for Reusable Object-Oriented Software," ECOOP/OOPSLA

1990 Proceedings, Ottawa, Canada, Oct. 1990, pp. 13 - 27. (23)

Nahum Greshon, Stephen Eick, "Visualization's New Track: Making sense of Information", IEEE spectrum, Nov

1995, pp. 38-56. (24)

D. Harel, et al., "STATEMATE: A Working Environment for the Development of Complex Reactive Systems," in

Software State-of-the-Art: Selected Papers, Tom DeMarco and Timothy Lister, editors, NewYork: Dorset House, 1990, pp. 322-338. (25)

D. Harel, "On Visual Formalisms," Communications of the ACM, vol. 31, no. 5, May 1988, pp. 514 - 531.

(26)

D. Harel, "Algorithmics: The Spirit of Computing," Addison-Wesley Publishing Company, Inc., 1987.

(27)

.D. Harel, A. Pnueli, J. P. Schmidt, and R. Sherman, "On the Formal Semantics of Statecharts," Proc. 2nd IEEE

Symp. on Logic of Computer Sci., Ithaca, NY, 1987, pp. 54 - 64. (28)

D. Harel, "Statecharts: A Visual Formalism for Complex Systems," Sci. Comput. Program., vol. 8, no. 3, June

1987, pp. 231 - 274. (29)

D. Harel, A. Pnueli, "On the Development of Reactive Systems," Logics and Models of Concurrent Systems,

NATO, ASI Series, vol. 13, K.R. Apt, Ed. Springer-Verlag, New York, 1985, pp. 477 - 498. (30)

C. R. Harrell, K. Tumay, "ProModel Tutorial", Proc. of the Winter Simulation Conference, Arlington VA, Dec.

1992, pp. 405-409. (31)

C.A.R. Hoare, "Communicating Sequential Processes," Englewood Cliffs, NJ: Prentice Hall, 1985.

(32)

Francois Ingrand, et al., "An Architecture for Real-Time Reasoning and System Control," IEEE Expert, 1992.

22

(33)

H.M. Jarvinen, et al., "Object-Oriented Specification of Reactive Systems," Proceedings of the 12th International

Conference on Software Engineering, Long Beach, CA, 1990, pp. 63-71. (34)

Kjell, Nielsen, "Ada in Distributed Real-Time Systems," New York: McGraw-Hill Book Company, 1990.

(35)

F. Kroger, "Temporal Logic of Programs", in EATCS Monographs on Theoretical Computer Science, New York,

Springer-Verlag, 1987. (36)

Christine Lafontaine, et al., "An Experiment in Formal Software Development: Using the B Theorem Prover on a

VDM Case Study," Communications of the ACM, vol. 34, no. 5, May 1991, pp. 63 - 71. (37)

L. Lamport, "A Simple Approach to Specifying Concurrent Systems," Communications of the ACM, vol. 32, no.

1, Jan. 1989, pp. 32 - 45. (38)

J. E. Lenz, "The MAST Simulation Environment", Proc. of the Winter Simulation Conference, Washington D.C.,

Dec. 1989, pp. 243-248. (39)

Marc Linster, "Closing the Gap Between Modeling to Make Sense and Modeling to Implement Systems,"

International Journal of Intelligent Systems, vol. 8, 1993, pp. 209 - 230. (40)

Zohar Manna, Amir Pnueli, "Verification of Concurrent Programs: A Temporal Proof system", Foundations of

Computer Science IV, Amsterdam, 1983, pp. 163-255. (41)

R. Milner, "Calculi for Synchrony and Asynchrony", Theoret. Comput. Sci., vol. 25, 1983.

(42)

C. J. Murgiano, "A Tutorial on WITNESS", Proceedings of the Winter Simulation Conference, New Orleans, LA,

Dec. 1990, pp. 177-179. (43)

Modulus Technologies, "Interagent Toolkit User's Manual," Modulus Technologies, Inc. 1993.

(44)

X. Nicollin, J. Sifakis, S. Yovine, "Compiling Real-Time Specifications into Extended Automata," IEEE

Transactions on Software Engineering, vol. 18, no. 9, Sept. 1992, pp. 794- 804. (45)

O. Nierstrasz, M. Papathomas, "Viewing Objects as Patterns of Communicating Agents," ECOOP/OOPSLA 1990

Proceedings, Ottawa, Canada, Oct. 1990, pp. 38- 43 (46)

H. Oswald, R. Esser, R. Mattmann, "An Environment for Specifying and Executing Hierarchical Petri Nets,"

Proceedings of the 12th International Conference on Software Engineering, 1990, pp. 164-172. (47)

M. Pidd, "Guidelines for the Design of Data Driven Generic Simulators", Simulation, vol. 59, no. 4, 1992, pp.

237-243.

23

(48)

A. Pnueli, "Applications of Temporal Logic to the Specification and Verification of Reactive Systems: A Survey

of Current Trends," in Current Trends in Concurrency, J. W. de Bakker et al., Eds. Lecture Notes in Computer Science, vol. 224, Springer-Verlag, New York, 1986, pp. 510 - 584. (49)

A. Pnueli, "The Temporal Semantics of Concurrent Programs", Theoret. Comput. Sci., vol. 13, 1981.

(50)

Srinivasan Ramaswamy, "Hierarchical Time-Extended Petri Nets (H-EPNs) for Integrated Control and Diagnostics

of Multilevel Systems," Ph.D., The Center for Adv. Comp. Studies, The University of SW Louisiana, May 1994. (51)

Ramaswamy, S., Barber, K. S., "A High Level Specification Language for the Automated Modeling and Analysis

of Complex Systems", Submitted to the Invited Session on Discrete Event and Hybrid Systems, IROS 1995. (52)

G. Richter, B. Maffeo, "Toward a Rigorous Interpretation of ESML-Extended Systems Modeling Language," IEEE

Transactions on Software Engineering, vol. 19, no. 2, pp. 165 - 180. (53)

G. G. Robertson et. al. "Information Visualization Using 3-D Interactive Animation", Communications of the

ACM, Vol. 36, No. 4, April 1993, pp. 57-71. (54)

J. Rumbaugh, M. Blaha, W. Premerlani, F. Eddy, W. Lorensen, "Object-Oriented Modeling and Design,"

Englewood Cliffs, New Jersey: Prentice Hall, 1991. (55)

J. Rumbaugh, "State Trees as Structured Finite State Machines for User Interfaces," Communications of the ACM,

vol. 10, no. 15, Oct. 1988, pp. 15 - 29. (56)

SES, "SES/Objectbench User's Manual," SES, 1993.

(57)

Alan Shaw, "Communicating Real-Time State Machines," IEEE Transactions on Software Engineering, vol. 18,

no. 9, Sept. 1992, pp. 805 - 816. (58)

Sally Shlaer, Stephen Mellor, "Object Lifecycles: Modeling the World in States," Englewood Cliffs, New Jersey:

Yourdon Press, 1992. (59)

Robert C. Sharble, Samuel S. Cohen, "The Object-Oriented Brewery: A Comparison of Two Object-Oriented

Development Methods," ACM SIGSOFT Software Engineering Notes, vol. 18, no. 2, Apr. 1993, pp. 60 - 73. (60)

R. G. Smith, "The Contract Net Protocol: High-Level Communication and Control in a Distributed Problem

Solver," in Readings in Distributed Artificial Intelligence, Bond and Gasser, editors, 1988 (61)

A. Sowmya, S. Ramesh, "Extending Statecharts with Temporal Logic," Technical Report, School of Computer

Science and Engineering, The University of New South Wales, SCS&E Report 9401, 1994.

24

(62)

Jeannette Wing, "A Specifier's Introduction to Formal methods," IEEE Computer, 1990.

(63)

Jeannette Wing, "Using Larch to Specify Avalon/C++ Objects," IEEE Transactions on Software Engineering, vol.

16, no. 9, Sept. 1990. (64)

Thies Wittig (editor), "ARCHON: An Architecture for Multi-agent Systems," New York: Ellis Horwood, 1992.

25