Specification of Application and Interface Objects for Reuse

Speci cation of Application and Interface Objects for Reuse P.S.C. Alencar 

D.D. Cowan y

C.J.P. Lucena z

L.C.M. Nova x

Abstract

In this paper we have shown how the description of application objects and interface objects can be formalized and applied to the speci cation of a highly interactive system. We have presented the Abstract Data View (ADV) model which is a design concept for the speci cation of interfaces. An ADV can be used to represent an interface between a user, a network or a device such as a timer and an Abstract Data Object (ADO), or as an interface between two or more ADOs, where an ADO is a speci cation for an object's public interface. Thus, ADVs can be viewed as media transformers or transformers between ADOs, and can add a \reuse dimension" to design, since they can determine the way in which one object \views" another, and could support syntactic non-interference and semantic context independence among dierent object speci cations. Our experience has shown that the practical use of ADV/ADOs in object-oriented design is related to both the formulation of reusable design patterns and to the reuse of existing ones. We view designs as being composed of ADVs and ADOs, and in order to specify a design we require a speci cation framework that provides adequate descriptions of the properties of ADVs and ADOs, and their components. This paper presents such a framework based on descriptive schemas for both ADVs and ADOs. These schemas describe the structural, static, and dynamic features of each system object, and include the speci cation of the concurrent operation of system components. Additionally, such schemas can be seen as an underlying structure to support the development of a speci cation language that describes the interconnection between interface and application components.

1 Introduction Reuse which applies at all stages of software development is a key concern of software engineering, where reuse of processes, requirements, design speci cations, and object implementations can all assist in reducing the cost of bringing a software product to the marketplace. We are currently  P.S.C. Alencar is a Visiting Professor in the Computer Science Department at the University of Waterloo, Waterloo, Ontario, Canada and is currently on leave from the Departamento de Ci^encia da Computaca~o, Universidade de Braslia, Braslia, Brazil. Email: [email protected] y D.D. Cowan is a Professor in the Computer Science Department at the University of Waterloo. Email: [email protected] z C.J.P. Lucena is a Visiting Professor in the Computer Science Department at the University of Waterloo and is currently on leave from the Departamento de Informatica, Pontifcia Universidade Catolica do Rio de Janeiro, Brazil. Email: [email protected] x L.C.M. Nova is a PhD candidate in the Computer Science Department at University of Waterloo and holds a doctoral fellowship from CNPq. Email: [email protected]

1

investigating the reuse of formal design speci cations of objects and interfaces [17, 19] because they support unambiguous speci cation, allow for tool-supported mathematical reasoning about these speci cations, and could allow rapid prototyping of functionality [8, 7]. Formal methods and reuse are closely related; reusing a component developed using formal methods spreads the higher development costs over more projects while improving both the quality of the development process and the resulting software systems. Combining formal design speci cation of objects into a software system can be viewed as a programming-in-the-large activity [23], where the interface or functionality of objects are speci ed, and then the objects are joined together into a complete software system. If we specify reusable objects or reuse-in-the-large, then we must connect the objects and also implement transformations between the semantic domains speci ed by these reusable objects. These transformations determine the way in which one object \views" another, and must guarantee syntactic non-interference and semantic context independence [22] among dierent speci cations. Of course these views can be between objects or between objects and the external world. In this latter case the view represents a user interface or an interface to a network or other device. Views are also objects, since they provide an interface and maintain state information that alters the way in which objects view each other, or the way in which objects are made accessible to the external world. Since a software system is composed of objects and views, both are candidates for reuse. We call the form of speci cations for objects and views, abstract data objects (ADOs), and abstract data views (ADVs). ADVs were originally conceived to act as general user interfaces and to achieve a separation of concerns by providing a clear separation at the design level between the application as represented by an ADO and the user interface or ADV [17, 18]. The extension of the concept of ADVs from a design model for user interfaces to a model that encompasses the general speci cation of interfaces between application components or ADOs has been informally proposed in [19]. Some methods for interconnecting or combining ADV and ADO speci cations have been achieved by speci cation constructors such as simple composition, sets, sequences of component types, and inheritance of speci cations [1, 2, 3]. The preliminary semantics for these speci cation constructors were given in terms of textual substitution in the same style used by Hoare in [29]. Subsequent work provided a formal semantics for the ADV theory using logic and category theory [5]. The work on formal semantics considerably improved our understanding of the theory but we could not rely on the formalisms to produce practical designs with ADVs. For that purpose we need to introduce the notion of ADV/ADO abstract schemas, that are useful tools for both formal and informal program speci cations [4]. The schemas are not the actual objects of the system, but rather descriptions of their static and dynamic properties and declarations of entities that are used within the scope of the object. Our speci cation framework is based on the descriptive schemas for both ADVs and ADOs, that are the basic building blocks for system speci cation, design, and implementation using the ADV approach. These schemas can include the speci cation of the concurrent operation of system components. Additionally, such schemas can be seen as an underlying structure to support the development of a speci cation language that describes the interconnection between interface and application components. In this paper we present the design speci cation schemas for both ADVs and ADOs, introduce another form of interconnection that we call \acquaintance" and then show how the schemas are used through an example. 2

ADVs have been used during both design and implementation of a number of practical software systems. Speci cally ADVs have been used to support user interfaces for games and a graph editor [16], to interconnect modules in a user interface design system (UIDS) [33], to support concurrency in a cooperative drawing tool, to design and implement a ray-tracer in a distributed environment [37], and a scienti c visualization system for the Riemann problem. The VX-REXX [40] system that was built as a research prototype, was motivated by the idea of composing applications in the ADV/ADO style. We have shown in [18] and [20] how ADVs can be used to compose complex applications from simpler ones in a style which is similar to some approaches to component-oriented software development [36] and megaprogramming [41]. We have created a visual formalism called Jasminum based on ADVs [10, 11, 12] for describing highly interactive systems and their user interfaces. This visual notation is state-machine and eventoriented and is based on earlier research on visual formalisms (Statecharts [28] and Objectcharts [14]). The semantics of ADVcharts, the state transition diagram part of JASMINUM, is de ned in terms of Statecharts [28].

2 Concepts of the ADV Model The ADV model is composed of object-oriented design concepts to support reuse-in-the-large. This approach was created to specify clearly and formally the separation of interfaces from the application components of a software system. The application components in an ADV-based design are speci ed by objects called Abstract Data Objects (ADOs), while the interface objects are de ned by Abstract Data Views (ADVs). The terms view and interface are used interchangeably in reference to the general concept of ADVs. ADVs and ADOs constitute the basic building blocks of the speci cation framework. An ADO is an object that has a state and a public interface that can be used to query or change this state. An ADV may be considered a generalization of an ADO, since an ADV has additional characteristics to support the speci cation of general interfaces. As a consequence, the ADV model will contain the characteristics that are inherent in the theory of objects [35]. Since an ADV is intended to specify a view or interface to an application object or ADO, an ADV should have in its structure a formal association with this corresponding ADO, in order to monitor and represent the ADO's state. This formal association called a mapping is a design mechanism to relate elements of the view to elements of the public interface of the application object that query the ADO's state. This mapping allows changes in the ADO state to be re ected in the ADV. The mapping mechanism is de ned by morphisms between public actions of the ADO that query its state and the corresponding attributes and actions of an associated interface object that is represented by an ADV. The ADV can also change the state of its corresponding ADO by directly invoking the public interface of the ADO. However, ADVs are not always associated with application objects. Exceptions are made when the ADVs have interface functions that are not related to the the application. A button that changes the colors on the screen is a typical example of an interface object disconnected from any application component. Actions are divided into two categories: causal actions and eectual actions. We use the term causal actions to denote the input events acting on an ADV. Causal actions are triggered from 3

outside the system and internal objects are not able to generate this type of action. A key stroke or a mouse click typify input events that are causal actions. Eectual actions are the actions generated directly or indirectly by a causal action. The triggering of an eectual action by another action will be a synchronous process if the morphism associating them does not include any delaying condition. In an ADV/ADO con guration only causal actions can change the state of the system. In other words, a causal action can make an eectual action occur, but an eectual action can not make a causal action occur. Since causal actions come from outside the system, causal actions can not cause other causal actions. If we visualize a tree of actions occurring over time, then a causal action can only appear at the root of a tree of actions and this syntactic rule also characterizes the ADO-ADV interaction. ADO

Public

Effectual Action Mapping Causal Action

Owner Output

Vertical Consistencies

Horizontal Consistency

ADV

Mapping Effectual Action

Causal Action

Owner Output ADV

Figure 1: An ADV/ADO interaction model. Both ADOs and their associated views represented by ADVs must be consistent. For example, both a digital and an analog view of a clock where the views are represented by ADVs and the clock by an ADO, must show the same time. We call consistency among the dierent ADVs horizontal consistency, while consistency between the visual object (ADV) and its associated ADO is called vertical consistency. These consistency properties must be guaranteed by the speci cation of ADVs, ADOs, and by their environment. Figure 1 illustrates these consistency properties, the mapping mechanism, and the occurrence of actions using a model of an ADO containing two distinct interfaces. It is important to note that the mapping linking the ADV with its associated ADO public interface is a design concept, rather than an implementation strategy. This mapping, which is represented in Figure 1 by means of a linking variable owner, is a design structure that assures the vertical consistency among application objects and views. In fact, we could propose many strategies to implement the mapping concept, but, this is not an issue in a design model. 4

3 ADOs and ADVs Both ADOs and ADVs are objects and are composed of data signatures, attributes, and actions. ADVs are modi ed ADOs that support the role of interfaces in a software system. Although we can nd many structural similarities in both concepts, it is important to observe that there is a clear separation between capabilities of ADOs and ADVs. An ADO has no knowledge of its interfaces (ADVs), thus ensuring independence of the application from its interface. On the other hand, an ADV does know about its associated ADO and can query its state by means of actions in the ADO public interface, or by a mapping representing the relationship between the ADV and associated ADO. An ADV is a design structure conceived to act as an interface and to achieve a separation of concerns by providing a clear separation at the design level between the application and its view. As shown in Figure 1, the interaction between an ADV and a user is by means of input events and output messages. The action interface of an ADV is invoked by input events, that is, an ADV action can be triggered by operations such as a mouse click, a keyboard event, or a timer. Thus, the action interface of the ADV extends the ADO interface to include external or causal events. ADVs also send output actions such as display commands, if their appearance is altered through an input message or a change in the state of an associated ADO.

3.1 The speci cation schemas for objects

In this section we introduce some abstract schemas for the speci cation of ADVs and ADOs. These abstract schemas are useful tools for both formal and informal program speci cations [15, 24]. In fact, our schemas are based on the ones described in [15, 27, 26]. A schema for an object in a system describes how that object modi es its state through its associated actions. The de nition of a schema for each ADV and ADO in a software system is an important step in the software development process, since these objects constitute the basic entities of the system. Components of the ADV model are called objects since their schema speci cations describe behavior over the lifetime of the object, and involve both static and dynamic properties. Both interface and application components are composed of dynamic properties that specify changes in the attributes representing the state memory of the objects. ADVs and ADOs have distinct roles in a software system and, as a consequence, they are described by dierent schemas. These schemas are not the actual objects inside a system, but rather provide descriptions of their static and dynamic properties and declarations of entities that are used within the scope of the object. Therefore, every ADV or ADO structure is subdivided into three sections: declarations, static properties, and dynamic properties. A declaration part contains a description of all the elements that compose the object. Additionally, sorts, functions, attributes, and actions might have a public or private status inside the object de nition. The public interface of the object speci cation consists of elements that were not explicitly declared as private. During development of an object speci cation, some trivial declarations may be omitted in the object speci cation for reasons of readability. The static properties part de nes all the properties which do not aect the state of the object. Their de nitions are always based on values stored by primitive attributes. Dynamic properties establish how the states and attribute values of an object are modi ed 5

ADO ADO Name Declarations Data Signatures Attributes Eectual Actions Nested ADOs Static Properties Constraints Derived Attributes Dynamic Properties Initialization Interconnection Valuation Behavior End ADO Name

- sorts and functions - observable properties of objects - list of possible eectual actions - allows composition, inheritance, sets, ... - constraints in the attributes values - non-primitive attribute descriptions - list of initialization actions - description of the communication process among objects - the eect of events on attributes - behavioral properties of the ADO

Figure 2: A descriptive schema for an ADO. during its lifetime. The description of dynamic properties together with a state memory and a public interface characterizes the entities being described as objects, rather than classes or types. Figure 2 shows the structure of the schemas to be used in the speci cation of ADOs. The speci cation syntax of the whole schema is presented essentially through a temporal logic formalism [34], and it may be regarded as an initial step towards the speci cation of a formal semantics for the ADV design approach. The data signature section of an object consists of a set S of sort names, and a set F of functions. A sort declaration represents an association of a set of values to a sort name. A function speci cation associates a speci c operation to a function name and its declaration in the schemas has the form f : s1 ; : : :; sn ?! s0 , with si 2 S for i = 0; : : :; n, where s1 ; : : :; sn is called the domain of f , s0 is called the codomain of f , and n is the arity of f . We use the pair in our object speci cations for establishing the available types and operations on the values that are stored in the attributes. Among sort expressions we may have the basic abstractions such as integer and string, and the application-speci c abstractions including object instances or user-de ned sorts. Sort constructors, such as set and union, can also be applied to compose complex sort expressions, since the semantics involved in a sort signature is an association of a set of values with a sort expression. The functions, denoting operations over given values, are also part of the data signature section. Attributes denote the state or the set of features of an object that can change over time. Attributes can be used by other objects to report on the current state of an object, since Attributes are its observable properties. Attributes are represented as a set of declarations of the form g : s1 ; : : :; sn ?! s0 , with si 2 S for i = 0; : : :; n, where g is an attribute name, s1 ; : : :; sn (n  0) denote optional parameter sorts of the attribute, and s0 is a sort determining the range of the attribute. 6

Actions are represented as a set of declarations of the form a : s1 ; : : :; sn , with si 2 S for

i = 0; : : :; n, where a is an action name, and s1; : : :; sn (n  0) represent the optional parameter sorts of the action. Note that attribute values can only be aected by local actions, which are the actions de ned in the same schema as the attribute to be changed. Additionally, we can subdivide types of actions into two subtypes: observer and change actions. The observer actions query the state of the associated ADO, while the change actions modify the state. In the Nested ADO section we can introduce the list of all the component objects of a composite ADO with the speci cation constructors that support nesting. Therefore, we specify the syntax of this section by the expression [constr]obj , where constr is a speci cation constructor, and obj denotes the nested ADO name. All objects are components of some composite object; objects which do not belong to a composite object are a component of the operating environment or \system". Composite objects are responsible for creating the instance of the components. Since the creation action can happen only once in a life of any object, then a component object can never be nested in two distinct composite objects. The rules used here for ADOs also apply to ADVs. The static properties of an object are represented by closed formulas. Constraint formulas refer to properties that must be true for all time, and derived attribute formulas de ne the derivation rules for the non-primitive attributes from the primitive (base) attributes. A derived attribute is an attribute in that it is a property of the object, but computing the derived attribute does not change the state of the object [39]. Constraints are represented by the temporal logic expression 2, where  is an invariance property, and 2 is the temporal logic operator \always". Derived attributes are also expressed by means of temporal logic formulas. The initialization of an object is de ned by means of eectual actions that, in general, initialize attribute values of this object when the object is created. The initialization process is expressed by the formula BEG ! a1 (s1 ; : : :; si ) ^ : : : ^ aN (s1 ; : : :; sj ), where a1 ; : : :; aN are the initialization actions that are declared as eectual actions. Before the creation of an object, every attribute has the value unde ned. The interconnection section is described by morphisms of actions and attributes. These morphisms or mappings have several uses. They can establish how component objects relate to the composite object, how ADVs are associated with an ADO, or they can be an instrument to de ne synchrony between actions of dierent objects. The intended interpretation of a morphism is that the mapped attributes must always have the same values and the mapped actions must happen simultaneously. The de nitions of morphism are organized by objects and, the morphisms between the current object and each other object are speci ed by expressions of the form element1 7?! element2 where element2 always refers to attributes or actions which are de ned inside the current object. In the interconnection section there is a description of which attributes and actions in one object have a synchronous correspondence with the attributes and actions in any other object. An important consideration is that an ADO schema cannot contain a reference to any ADV element, since the ADO has no knowledge about the existing ADVs. The valuation properties of an object describe the changes occurring in attribute values of this object as an immediate consequence of a triggered action. However, the valuation rules are applied only if all the speci ed pre-conditions for the occurrence of the action are satis ed. The valuation for an action a is described by means of temporal formulas of the forms: a ! att1 = 7

ADV ADV Name [for ADO j on ADO] ADO Name Declarations Data Signatures - sorts and functions Attributes - observable properties of objects Causal Actions - list of possible input actions Eectual Actions - list of possible eectual actions Nested ADVs - allows composition, inheritance, sets, ... Static Properties Constraints - constraints in the attributes values Derived Attributes - non-primitive attribute descriptions Dynamic Properties Initialization - list of initialization actions Interconnection - description of the communication process among objects Valuation - the eect of events on attributes Behavior - behavioral properties of the ADV End ADV Name Figure 3: A descriptive schema for an ADV.

value1 ^ : : : ^ att1 = valuen and a ! att1 = value1 ^ : : : ^ attm = valuem . The rst form of temporal formula de nes n pre-conditions on the occurrence of the action named a. The second form of temporal formula establishes m post-conditions on the occurrence of an action. Such formulas show the eects of an action over the attribute values of the object, since the temporal logic symbol means \at the next moment". The expressions that will determine new attribute values and pre-conditions are to be evaluated before the action occurrence. Behavior description is in general a complex task. Most of the object-oriented models represent system behavior by means of transition networks, which are augmented state-machine diagrams [21]. In this paper, we chose temporal logic formulas to describe the object behavior. However, there are a number of graphical representation languages that we could have chosen instead to describe the behavior of objects [9, 28, 14, 13]. The behavior section de nes the sequencing of the actions and changes in the state of the object. A behavior expression is described by pre state ^ action name ! post state, where pre state and post state are states of the object that are declared in the data signature section as boolean functions, and action name is an action of the object. Figure 3 contains a schema for an ADV, and as we can see by comparing Figures 2 and 3, the ADO and ADV schemas are similar, since they both incorporate object properties. However, there are some structural distinctions that clearly dierentiate the roles of ADOs and ADVs in the ADV design approach. One structural dierence is found in the header of the schemas. Since an ADO has no knowledge about the existence of ADVs, the header of an ADO schema contains only the de nition of the ADO name. On the other hand, the header of the ADV schema might contain a pair ADV Name/ADO Name declaring an association of the ADO with an ADV. The ADV Name/ADO Name 8

pair is separated by either the phrase for ADO or on ADO. These phrases indicate the mode of the association between an ADV and its corresponding ADO. The dierence between the phrases for ADO and on ADO are described in Section 4.2. The whole description of this association is de ned further in the interconnection section, or by a design structure called a Body ADV which we describe later. This structure describes what and how the ADV knows about the ADO state. Another distinction between ADV and ADO schemas is in the sections related to the declaration of actions. An ADO has no de nition of causal actions in its structure, thus every ADO action is eectual. However, ADVs may be aected by causal (external) actions, which should be declared in a particular section of the schema. This distinction clari es that the ADO has no interface properties.

3.2 An example

This section presents an illustrative example of a vending machine which we will use in the rest of this paper. Since a vending machine is a highly interactive system, it can serve to illustrate the main issues underlying a system design speci cation using the ADV approach. To keep the speci cation manageable, we limit the number of features on the vending machine, as shown in Figure 4.

2

D R I N K S

Coffee

Money In

Chocolate

Credit:

Tea

95 Cents Cola Change Lever

Figure 4: The vending machine interface. In the ADV approach, we normally start by analyzing which modules compose the application framework and the interface. In our example, such an analysis step is straightforward. The application objects consist of ADOs that have operations to determine the amount deposited by the user (credit), to allow product selection and release, and to request and release change. Such operations should be present in any vending machine application, and are independent of the interface designed to implement them. The interface objects provide the user with all the useful information about the behavior of the application objects. Figure 4 illustrates the interface designed for our system. All the buttons, and input/output ports (for drinks and money) shown in Figure 4 are supported 9

Request

CreditView

CoinSlot

ChangeRequest

ChangeLever

ProductRequest Facade

ProductButton Credit ChangeOutput

ChangeRelease

ProductRelease

ProductOutput

(a)

(b)

Figure 5: Object Model for the Vending Machine. by interface objects (ADVs) which are also responsible for updating the states and attribute values of the application objects (ADOs). The number of objects for this example is quite small, and so we just listed them. However, for a larger system we might need a notation to illustrate the organization of objects in the system; an example of such a notation is shown in Figure 5. The graphics in this Figure are part of the notation used in a method called the Object Modeling Technique (OMT), which is described in [39]. The diagram follows the object model, and describes the identities of the objects and their relationships to other objects within the system. Although we illustrate relationships among objects in Figure 5, we omitted the representation of every ADV/ADO association in order to simplify the diagram. Furthermore, such associations can be easily inferred. No doubt there are several dierent designs that could be used in our system speci cation. The design presented here was chosen to illustrate most of the important characteristics of the ADV design approach and its speci cation tools. The system design can be de ned by means of speci cation schemas such as the ones illustrated in Figure 6. Such ADO schemas have the responsibility of processing the basic user inputs. The Credit ADO is designed to keep the user balance at any time, and should store consistent values after any possible sequence of operations. The Request ADO is an abstraction of request operations, and will used for both product and change requests, as we will see later. The object speci cations, as described in Figure 6, de ne all the ways in which actions modify the state of the corresponding object. Any possible change in an attribute value should be precisely de ned by pre- and post-condition formulas in the valuation section of the object. Note that these ADO speci cations have no knowledge about their associated interfaces. ADV schemas associated with the Credit ADO are illustrated in Figure 7. Our initial speci cation for the example illustrates many important aspects of the ADV approach. Dierences between ADO and ADV schemas, knowledge about the existence of other objects, and multiple interfaces associated with a single ADO, are some of the important issues we address. 10

ADO Credit Declarations Attributes

Value: nat;

Eectual Actions

IncreaseValue: nat; DecreaseValue: nat; ResetValue; InformValue: nat;

Dynamic Properties Initialization

BEG ! ResetValue;

Valuation

End Credit

IncreaseValue(val) ! Value = Value + val; DecreaseValue(val) ! Value = Value - val; ResetValue ! Value = 0; InformValue(val) ! val = Value;

ADO Request Declarations Attributes

Requested: boolean;

Eectual Actions

SetRequest; ResetRequest;

Dynamic Properties Valuation

End Request

SetRequest ! Requested = false; SetRequest ! Requested = true; ResetRequest ! Requested = true; ResetRequest ! Requested = false;

Figure 6: ADO speci cations.

11

ADV CoinSlot ForADO Credit Declarations Data Signatures Function SizeValue: nat ?! nat; Attributes

Coin: nat;

Causal Actions

InsertCoin: nat;

Eectual Actions

AddCoinValue: nat;

Dynamic Properties Interconnection WithADO Credit

IncreaseValue(V) 7?! AddCoinValue(V);

Valuation

InsertCoin(size) ! Coin = SizeValue(size); AddCoinValue(val) ! val = Coin;

Behavior End CoinSlot

Idle ^ InsertCoin ! CoinDropped; CoinDropped ^ AddCoinValue ! Idle;

ADV CreditView ForADO Credit Declarations Attributes

Display: nat;

Eectual Actions

DrawView: nat;

Dynamic Properties Initialization

BEG ! DrawView(V);

Interconnection WithADO Credit

Value 7?! Display;

Valuation

DrawView(val) ! val = Display;

End CreditView

Figure 7: ADVs for the Credit ADO.

12

4 Structuring Components We introduce in this section the structuring approaches for the organization and interconnection of objects inside a system, as prescribed in the ADV design model. While organization is a description of the static structure of the system, the interconnection properties describe how objects dynamically interact among themselves. The structures used to de ne the organization of the objects will also have major in uence on the interconnections among these objects. The organization is a description of how the objects are related in a system. It should represent associations between ADVs and ADOs, nesting among objects, and any other relationship between objects. The organization of objects within a software development process is described by the static model of an object-oriented methodology, while interconnections are described by a dynamic model. Interconnections have a close relationship to the way objects are organized. For example, the fact that a component object knows about the structure of its composite objects creates a one-way channel of communication that is embedded in the system structure. We describe the issues related to the interconnection processes in the next section.

4.1 Interconnection

The interconnection process de nes how two distinct objects are dynamically coupled in a network of communicating objects. The coupling mechanism is represented in the schemas by a set of morphisms between the interconnected objects. Additionally, a morphism is used in the object speci cations as an identi cation between actions and attributes to imply concurrency of actions or equivalence of attribute values between related objects. We describe the morphisms inside the interconnection section of the schema of the object that is responsible for establishing the interaction. For instance, the interconnection between the ChangeRequest ADO and its associated ChangeLever ADV is represented in the schema of the ADV, as shown in Figure 8. As a consequence, the ADV will take responsibility for triggering actions of the corresponding ADO. Such a characteristic ensures that the ADO design has no knowledge of associated interface object. A similar relationship is illustrated in Figure 9, where ProductButton ADV is the associated view to ProductRequest ADO. An alternative structure to represent the interconnections could use a design module to specify the relationship between two objects (ADVs or ADOs). This structure was used in [6] and is called Body ADV. An example of such a structure connecting Credit ADO and CreditView ADV is shown in Figure 10. Interconnections are established between objects that are related by means of object aggregation or acquaintance. Aggregation of objects involves nesting and implies that one object is part of another object. On the other hand, acquaintance means that one object merely knows of the existence of the other object, and that these two objects have no responsibility for each other. The relationship between objects has a major in uence on a system's dynamic structure. In the OMT diagrams, acquaintance is represented by a plain arrowline, while aggregation is denoted by an arrowline with a diamond at its base. We call tightly-coupled interconnections the interactions between aggregated objects. We use the term tightly-coupled because of the existing structural link between composite and component 13

ADO ChangeRequest Declarations Nested ADOs Inherit Request; Dynamic Properties Initialization

BEG ! ResetRequest;

End ChangeRequest

ADV ChangeLever ForADO ChangeRequest Declarations Attributes

Pressed: boolean;

Causal Actions

PressLever; ReleaseLever;

Eectual Actions

InitializeLever;

Dynamic Properties Initialization

BEG ! InitializeLever;

Interconnection WithADO ChangeRequest

SetRequest 7?! PressLever;

Valuation

InitializeLever ! Pressed = false; PressLever ! Pressed = true; ReleaseLever ! Pressed = false;

Behavior

Idle ^ PressLever ! Pressed; Pressed ^ ReleaseLever ! Idle; End ChangeLever

Figure 8: Objects for requesting change.

14

ADO ProductRequest Declarations Attributes

Product: string;

Eectual Actions

SetProduct: string;

Nested ADOs Inherit Request; Dynamic Properties Initialization

BEG ! ResetRequest;

Valuation

SetProduct(prod) ! Product = prod;

Behavior

Idle ^ SetProduct ! Speci ed; Speci ed ^ SetRequest ! Idle; End ProductRequest ADV ProductButton ForADO ProductRequest Declarations Attributes

Name: string; Pressed: boolean;

Causal Actions

PressButton; ReleaseButton;

Eectual Actions

InitializeButton; MakeRequest: string;

Dynamic Properties Initialization

BEG ! InitializeButton;

Interconnection WithADO ProductRequest

SetProduct(S) 7?! MakeRequest(S);

Valuation

InitializeButton ! Pressed = false ^

Name = PROD NAME; MakeRequest(prod) ! prod = Name; PressButton ! Pressed = true; ReleaseButton ! Pressed = false;

Behavior

Idle ^ PressButton ! Pressed; Pressed ^ MakeRequest ! Requested; Requested ^ ReleaseButton ! Idle; End ProductButton

Figure 9: Objects for requesting product.

15

BodyADV ADO Credit/ADV CreditView Declarations Attributes

LinkValue: nat;

Dynamic Properties Interconnection WithADO Credit

Value 7?! LinkValue;

WithADV CreditView End BodyADV

Display 7?! LinkValue;

Figure 10: A body ADV structure. objects. In contrast, loosely-coupled interconnections are the interactions resulting from acquaintance, where a communication relationship is more volatile, in that it is usually made and remade more frequently than a tightly-coupled interconnection. The interconnection between an ADV and its associated ADO is either tightly-coupled or loosely coupled, and these two cases are discussed later. First, we clearly de ne these two the types of interaction. 4.1.1

Tightly-coupled interconnections

We usually qualify an interconnection by the way the interacting objects are structured in the system. Interconnections are called tightly-coupled when one of the interacting objects owns or is responsible for the other object involved in the interaction. Since an object is created at the same time as its owner, tightly-coupled interconnections are always made between objects with the same lifetime. As mentioned before, tightly-coupled interconnections are de ned by relationships where elements of the composite object are related to elements of the component object by morphisms. Since every public attribute or action of the component object is known by its enclosing object, there should exist a morphism in the composite object to every public element of its components. However, to keep design simple, we explicitly de ne only morphic elements that will be eectively used by the composite object. The implication of using aggregation to interconnect objects, is that the composite object keeps a strong relationship with the component object structure. Such a relationship may often lead to the introduction of unnecessary object dependencies, thus producing a monolithic structure which could make the reuse of objects in isolation quite dicult. In addition, these unnecessary dependencies can cause problems of both comprehension and maintenance of the system design. The expression \tightly-coupled" expresses this potential in exibility. In the ProductRelease ADO de ned in Figure 11, we nd two component objects de ned in the Nested ADOs section. The corresponding morphisms from these objects to the nesting ADO are explicitly stated in the Interconnection section. As we see, the MValue morphic attribute was de ned in the speci cation of the ProductRelease ADO to monitor the value of the Value attribute in the Credit ADO. Similarly the MDecreaseValue action de nition was made to correspond to 16

the DecreaseValue action, so that an occurrence of MDecreaseValue will synchronously trigger a corresponding action in the component ADO. The occurrence of this action will also be subject to the pre-conditions, if any, of its morphic action DecreaseValue. 4.1.2

Loosely-coupled interconnections

Loosely-coupled interconnections are performed between objects that have no structural link to each other, but one of them is acquainted with the other. The \loosely-coupled" terminology re ects the weak relationship between these objects, in contrast with the nesting relationship described in the previous section. Representations of such interconnections are also described in the schemas by morphisms between elements of an object and the public interface of its acquaintance. Although implementation of both kinds of interconnection may not be distinguishable, the design issues are clear and important. Since loosely-coupled interconnections are more dynamic than tightly-coupled ones, the acquainted object might be easily changed, as long as it maintains a consistent interface. For example, if a Window object is speci ed to delegate another Shape object to draw its format, such object speci cation might be altered from rectangle to circle, as long as they maintain the same interface structure. Loosely-coupled interconnections are identi ed in the speci cation schema of an object when the morphisms identifying them are paired with elements of an object that is not declared in the Nested ADO (ADV) section. In Figure 8 we de ne a loosely-coupled interconnection from ChangeRelease ADO to Credit ADO. Since there is no aggregation involved in this process, the de ned morphisms indicate loose-coupling. The weak relationship between objects speci ed in the ADO of Figure 8, was chosen for reasons other than good design. The Credit ADO could not be nested in two distinct objects, as explained in Section 3. However, using aggregation to connect objects does not restrict them to this mode of interconnection.

4.2 ADO/ADV relationships

Unless an ADV has only functions that relate to its appearance, it should be connected to the functional interface of its corresponding application object or ADO. This linking is conceptually represented by a mapping between both objects that allow the interface object to represent its associated object correctly. The concepts of the ADV design approach make the relationship between an ADO and its associated ADV a key factor in understanding a design speci cation. Since ADVs are visual objects their interaction with the corresponding ADO can performed by either tightly-coupled (aggregation) or loosely-coupled (acquaintance) interconnection. We choose to dierentiate these two forms of interconnection by using either the term On ADO (aggregation) or for ADO (acquaintance) in the header of an ADV speci cation. In the speci cation in our example we have been using acquaintance to specify ADO/ADV relationships.

4.3 Nesting speci cation constructors

In the ADV design model, we extend the concept of ADOs and ADVs to allow nesting of objects through speci cation constructors, where nesting implies that objects are aggregated or composed from a number of constituent objects, and that one object encloses its constituents. In using 17

ADO ProductRelease Declarations Data Signatures Function ProductValue: string ?! nat; Attributes

MValue: nat; MProductRequested: string;

Eectual Actions

MDecreaseValue: nat; MResetProductRequest; ReleaseProduct: string;

Nested ADOs Compose ProductRequest; Dynamic Properties Interconnection WithADO Credit

Value 7?! MValue, DecreaseValue(V) 7?! MDecreaseValue(V); WithADO ProductRequest Requested 7?! MProductRequested, ResetRequest 7?! MResetProductRequest;

Valuation

MDecreaseValue(val) ! val = ProductValue(MProductRequested); ReleaseProduct(prod) ! MValue >= ProductValue(MProductRequested) ^ MProductRequested null ^ prod = MProductRequested;

Behavior

Idle ^ ReleaseProduct ! Released; Released ^ MDecreaseValue ! Paid; Paid ^ MResetProductRequest ! Idle; End ProductRelease ADV ProductOutput ForADO ProductRelease Declarations Attributes

Product: string;

Eectual Actions

VerifyRequest: string; MakeAvailable: string;

Dynamic Properties Interconnection WithADO ProductRelease

ReleaseProduct(S) 7?! MakeAvailable(S);

Valuation

VerifyRequest(prod) ! Product = prod; MakeAvailable(prod) ! prod = Product;

Behavior

Idle ^ VerifyRequest ! IsRequested; IsRequested ^ MakeAvailable ! Idle; End ProductOutput

Figure 11: Objects for releasing product. 18

ADO ChangeRelease Declarations Attributes

ValueToRelease: nat; MChangeRequested: boolean;

Eectual Actions

MResetValue; MResetChangeRequest; ReleaseChange;

Nested ADOs Compose Credit, ChangeRequest; Dynamic Properties Interconnection WithADO Credit

Value 7?! ValueToRelease; ResetValue 7?! MResetValue; WithADO ChangeRequest Requested 7?! MChangeRequested, ResetRequest 7?! MResetChangeRequest;

Valuation

ReleaseChange ! MChangeRequested = true;

Behavior

Idle ^ ReleaseChange ! Started; Started ^ MResetValue ! Cleared; Cleared ^ MResetChangeRequest ! Idle; End ChangeRelease ADV ChangeOutput ForADO ChangeRelease Declarations Attributes

Change: nat;

Eectual Actions

ProcessRequest; MakeAvailable: nat;

Dynamic Properties Interconnection WithADO ChangeRelease

ValueToRelease 7?! Change; MResetChangeRequest 7?! ProcessRequest;

Valuation

MakeAvailable(val) ! val = Change;

Behavior

Idle ^ ProcessRequest ! Processed; Processed ^ MakeAvailable ! Idle; End ChangeOutput

Figure 12: Objects for releasing change.

19

ADV Facade Declarations Attributes

Pos: nat;

Eectual Actions

DrawView: position;

Nested ADVs Compose CoinSlot, ChangeLever, CreditView, ProductOutput, ChangeOutput; Set of ProductButton; Dynamic Properties Initialization

BEG ! DrawView(P);

Valuation End Facade

DrawView(pos) ! Pos = POSITION;

Figure 13: The enclosing interface object. aggregation or composition we also assume that the enclosing ADO or ADV knows the identity of its constituents, but each enclosed object does not know the identity of its enclosing object. Composition, inheritance, sets and sequences are the mechanisms in the ADV model for combining and reusing speci cations. They are described in [1, 2, 3] and all of these constructors are composition-based, which means that they can be interpreted through a primitive composition speci cation construct. For example, sequences can be interpreted as multiple ordered compositions. According to [25], the two most common techniques for reusing functionality in object-oriented systems are inheritance and composition. The similarities between these two nesting constructs sometimes leads to confusion of concepts and terminology. However, important distinctions between inheritance and composition could make design signi cantly better with a proper choice of the nesting construct. Examples of the speci cation of inheritance and composition in schemas are illustrated in Figure 8 and Figure 13 respectively. In the enclosing object perspective, inheritance can be viewed as clear-box design where all the contents and structures of the enclosed object are visible. Inheritance is particularly useful for design abstractions, where a nesting object can build its structure based on an existing object design. On the other hand, composition can be viewed as black-box design, since the nesting object knows its nested objects only through the public interface of the nested object. In the OMT methodology [39], each nesting construction supported by the ADV model has a particular graphical representation. In our model, such distinction is made by the use of speci cation constructors in the Nested ADO (ADV) section. Each nesting declaration is identi ed by one of the following speci cation constructors: Compose, Inherit, Set of and Sequence of. Additionally, the details of the nesting are declared through morphisms in the interconnection section. These morphisms will specify the relationship of an enclosing ADO (ADV) to its enclosed objects. Figure 13 illustrates the composite ADV responsible for composing the many interface components into a single interface unit. This composition is displayed on the screen, where the component 20

ADVs are drawn inside the composite ADV region. The Facade ADV is also responsible for initializing each of its constituent ADVs. Once more, morphisms between composite and component objects will be omitted from the speci cation, since they are not used in this simpli ed vending machine example.

5 Communication While the interconnection property describes how two distinct objects are coupled by morphisms, the communication process speci cation is concerned with the meaning of each of these morphisms and how they are used to exchange data between the interconnected objects. In the ADV model, there are two basic forms for exchanging data between objects: mapping of attributes and parameter passing. Mapping of attributes is de ned by attribute morphisms in the interconnection section of a schema. The attribute mapping is always part of the description of an ADO/ADV association or the relationship of nesting and nested objects. In the rst case, the mapping is the design mechanism in which a visual object (ADV) monitors the state of the ADO it is representing. In the other case, the mapping de nes channels of communication in which the enclosing object receives any data from the nested objects. In both cases the mapping is used as a mechanism for querying data in the accessed object. The modi cation of such data would require invoking modifying actions in the public interface of the accessed object. The parameters in the action description may have important roles inside a system speci cation. They might be used to set the eect of an action occurrence on the current attribute values of an object, or they could be used to describe the transmission of data during the communication process. In the rst case, the parameter values are used to update the attribute of the object. This process is always described in the valuation section of the object speci cation. In the second case, the parameters may be considered as a querying mechanism to transmit data from one object to another. The communication mechanisms mentioned are illustrated in the speci cation of the vending machine example. In the ChangeOutput ADV speci cation, shown in Figure 12, the Change value to be released by the machine interface is known because of the mapping to the ChangeRelease ADO. On the other hand, Figure 11 illustrates how the ProductOutput ADV queries the ProductRelease ADO about the name of the product to be released. The query is made using the parameter of the query action VerifyRequest which is connected to another action in the target ADO.

5.1 Synchronous invocations

In the ADV approach, communication between object instances is generally made by synchronous invocation of actions and attribute values that are mapped through morphisms between the object instances, as described in the previous section. The synchronous approach contrasts with other user interface models, where a component must handle both synchronous and asynchronous invocations from other components. Handling asynchronous invocations is considerably more complex than handling synchronous invocations, since it requires error-prone mechanisms such as signals, interrupts, or callbacks. With an explicit mapping we enforce a one-way communication and, as 21

a consequence, have fewer interconnections, thus ensuring that the role and scope of the interface are de ned unambiguously.

5.2 Asynchronous invocations

Although action invocations de ned by morphisms are synchronous, we can still model asynchronous invocation of actions using the ADV approach. We do this by de ning a relationship that introduces a gap in time between the invocation of two related actions. This gap is speci ed in the schema by a boolean function. Consider act1 and act2 as two actions that are asynchronously related in time. Then the speci cation of the invocations would be stated by the terms act1 ! 3 P and act2 ! P . The rst term states that when act1 is triggered then, sometime in the future, the boolean function P will be true. This time relation is established by the temporal logic operator 3, which means \eventually". The second term is a pre-condition to the triggering of P.

6 Conclusion In this paper we have shown how the ADV approach can be formalized and applied to the speci cation of a highly interactive system. We have presented the concepts of the ADV model and described the individual ADVs and ADOs, and their descriptive schemas. The approach has been illustrated by means of an example. We have described both the tightly-coupled and loosely-coupled structuring approaches for the interconnection of views and applications inside a system. We have also discussed the ADV/ADO relationships and presented the nesting speci cation constructors, namely component, inherit, sets and sequences, as well as the concurrent and communicationrelated features of our approach. We intend in a future paper to describe an extension to the approach for representing distributed, component based systems, namely to support component interconnections based on client-server relationships. Our experience has shown that the practical use of ADV/ADOs in object-oriented design is related to both the formulation of reusable design patterns and to the reuse of existing ones. Recently, a collection of design patterns has been identi ed and communicated in the literature [25]. The inspiration for design pattern classi cation in a recent book [25] appears to have been provided by the MVC model [31] which has been used to suggest model-like patterns and view-like patterns. The authors have generalized the MVC model beyond its use for man-machine interfaces, as we did in our general ADV/ADO approach [19]. Both the generalizations in [25] and [19] allowed the formulation of a general collection of design patterns for both programming-in-the-large and programming-in-the-small, but no distinction was made between these two levels of programming. Some patterns using the ADV/ADO approach have been informally speci ed in [4]. Since the MVC model can be directly used to implement ADV/ADO design speci cations we have found that the design patterns similar to the ones proposed in [25] can be abstracted and formalized in terms of the ADV/ADO model for its use in programming-in-the-large. Recent work reported in [30] indicated how design in the context of programming-in-the-large may be inserted into the commonly recognized object oriented analysis and design methods (OOADMs). Thus design patterns created within the ADV/ADO model may be used in several of the OOADMs, providing them with a reuse dimension. For the formalization of design patterns both at the programming-in-the-small 22

and programming-in-the-large levels a meta-pattern speci cation notation is needed. For example, in [38] the term meta-pattern is used to designate a set of design patterns that describe how to construct frameworks which are independent of a speci c domain. We are in the process of proposing a meta-pattern speci cation notation based on ADV/ADOs to express design patterns to be used in the programming-in-the-large design phase. Design patterns are formalized in terms of ADV and ADOs through a meta-pattern composed of two parts. In one part the pattern process is expressed using \development operators" [32]. In the other part the result of applying a design pattern is expressed in terms of the ADV/ADO schemas [4] presented in this paper.

References [1] P.S.C. Alencar, L.M.F. Carneiro-Con, D. D. Cowan, and C.J.P. Lucena. The Semantics of Abstract Data Views: A Design Concept to Support Reuse-in-the-Large. In Proceedings of the Colloquium on Object-Orientation in Databases and Software Engineering (to appear). Kluwer Press, May 1994. [2] P.S.C. Alencar, L.M.F. Carneiro-Con, D. D. Cowan, and C.J.P. Lucena. Towards a Formal Theory of Abstract Data Views. Technical Report 94{18, University of Waterloo, Computer Science Department, Waterloo, Ontario, April 1994. [3] P.S.C. Alencar, L.M.F. Carneiro-Con, D. D. Cowan, and C.J.P. Lucena. Towards a Logical Theory of ADVs. In Proceedings of the Workshop on the Logical Foundations of Object Oriented Programming ECOOP94 (to appear), July 1994. [4] P.S.C. Alencar, D. Cowan, C.J.P. Lucena, and L.C.M. Nova. Formal Speci cation of Reusable Interface Objects. In Proceedings of Symposium on Software Reusability (to appear), Seattle, USA, April 1995. [5] P.S.C. Alencar, D.D. Cowan, and C.J.P. Lucena. A Logical Theory of Interfaces and Objects. ftp://csg.uwaterloo.ca/pub/ADV/theory/interobj.ps.gz, 1995. [6] P.S.C. Alencar, D.D. Cowan, C.J.P. Lucena, and L.C.M. Nova. Formal speci cation of reusable interface objects. Technical Report 94-44, Computer Science Depatment, University of Waterloo, 1994. [7] P.J. Bumbulis, P.S.C. Alencar, D.D. Cowan, and C.J.P. Lucena. A Framework for MachineAssisted User Interface Veri cation. In Proceedings of the Fourth International Conference on Algebraic Methodology and Software Technology (AMAST'95). Springer Verlag Lecture Notes in Computer Science (to appear), 1995.

[8] P.J. Bumbulis, P.S.C. Alencar, D.D. Cowan, and C.J.P. Lucena. A Framework for Prototyping and Mechanically Verifying User Interfaces. In Proceedings of CASE95 (to appear), 1995. [9] L.M.F. Carneiro, D.D. Cowan, and C.J.P. Lucena. ADVcharts: a Visual Formalism for Describing Abstract Data Views. Technical Report 93{20, Computer Science Department and Computer Systems Group, University of Waterloo, Waterloo, Ontario, Canada, 1993. 23

[10] L.M.F. Carneiro, D.D. Cowan, and C.J.P. Lucena. ADVcharts: a Visual Formalism for Interactive Systems - position paper. In SIGCHI Bulletin, pages 74{77, 1993. [11] L.M.F. Carneiro, D.D. Cowan, and C.J.P. Lucena. ADVcharts: a Visual Formalism for Interactive Systems. In Proceedings of the York Workshop on Formal Methods for Interactive Systems (to appear). Springer, 1994. [12] L.M.F. Carneiro-Con, D. D. Cowan, C.J.P. Lucena, and D. Smith. An Experience Using JASMINUM | Formalization Assisting with the Design of User Interfaces. In Proceedings of the Workshop on Research Issues between Software Engineering and Human-Computer Interaction (to appear), Sorrento, May 1994.

[13] George W. Cherry. S-R Machines: a Visual Formalism for Reactive and Interactive Systems. ACM Software Engineering Notes, 16(3):52{55, July 1991. [14] Derek Coleman, Fiona Hayes, and Stephen Bear. Introducing Objectcharts or How to Use Statecharts in Object-Oriented Design. IEEE Transactions on Software Engineering, 18(1):9{ 18, January 1992. [15] Stefan Conrad, Martin Gogolla, and Rudolf Herzig. TROLL light: A core language for specifying objects. Technical Report 92-02, Technische Universitat Braunschweig, December 1992. [16] D.D. Cowan et al. Program Design Using Abstract Data Views{An Illustrative Example. Technical Report 92{54, Computer Science Department, University of Waterloo, Waterloo, Ontario, Canada, December 1992. [17] D.D. Cowan, R. Ierusalimschy, C.J.P. Lucena, and T.M. Stepien. Abstract Data Views. Structured Programming, 14(1):1{13, January 1993. [18] D.D. Cowan, R. Ierusalimschy, C.J.P. Lucena, and T.M. Stepien. Application Integration: Constructing Composite Applications from Interactive Components. Software Practice and Experience, 23(3):255{276, March 1993. [19] D.D. Cowan and C.J.P. Lucena. Abstract Data Views: An Interface Speci cation Concept to Enhance Design. IEEE Transactions on Software Engineering, 21(3):229{243, March 1995. [20] D.D. Cowan, C.J.P. Lucena, and R.G. Veitch. Towards CAAI: Computer Assisted Application Integration. Technical Report 93{17, Computer Science Department and Computer Systems Group, University of Waterloo, Waterloo, Ontario, Canada, January 1993. [21] Dennis de Champeaux, Douglas Lea, and Penelope Faure. Object-Oriented System Development. Addison-Wesley, Reading, Massachusetts, 1993. [22] J. Dennis. Modularity. In Advanced Course on Software Engineering. Springer-Verlag, 1973. [23] F. DeRemer and H. Kron. Programming-in-the-large Versus Programming-in-the-small. IEEE Transactions on Software Engineering, 2(2), 1976. 24

[24] B. Fields, M. Harrison, and P. Wright. From Informal Requirements to Agent-based Speci cation: an Aircraft Warnings Case Study. Technical report, University of York, August 1993. [25] Erich Gamma, Richard Helm, Ralph Johnson, and Jonh Vlissides. Design Patterns. AddisonWesley, Reading, Massachusetts, 1995. [26] M. Gogolla, N. Vlachantonis, R. Herzig, G. Denker, S. Conrad, and H.D. Ehrich. The KORSO approach to the development of reliable information systems. Technical Report 94-06, Technische Universitat Braunschweig, June 1994. [27] Martin Gogolla, Stefan Conrad, and Rudolf Herzig. Sketching Concepts and Computational Model of TROLL Light. In Proceedings of Int. Conf. Design and Implementation of Symbolic Computation Systems (DISCO'93), Berlin, Germany, March 1993. Springer. [28] David Harel. Statecharts: a Visual Formalism for Complex Systems. Science of Computer Programming, 8(3):231{274, June 1987. [29] C.A.R. Hoare. Proof of Correctness of Data Representations. Acta Informatica, 1(4):271{281, 1972. [30] Shuguang Hong, Geert van den Goor, and Sjaak Brinkkemper. A Formal Approach to the Comparison of Object-Oriented Analysis and Design Methodologies. In Proceedings of HICSS26, January 1993. [31] Glenn E. Krasner and Stephen T. Pope. A Cookbook for Using the Model-View-Controller User Interface Paradigm in Smalltalk-80. JOOP, pages 26{49, August 1988. [32] N. Levy and G. Smith. A Language-Independent Approach to Speci cation Construction. ACM SIGSOFT '94, December 1994. [33] C.J.P. Lucena, D.D. Cowan, and A.B. Potengy. A Programming Model for User Interface Compositions. In Anais do V Simposio Brasileiro de Computaca~o Gra ca e Processamento de Imagens, SIBGRAPI'92, Aguas de Lindoia, SP, Brazil, November 1992. [34] Z. Manna and A. Pnueli. The Temporal Logic of Reactive and Concurrent Systems, volume 1. Springer-Verlag, Berlin/New York, 1992. [35] Jose Meseguer. A Logical Theory of Concurrent Objects and Its Realization in the Maude Language. Technical Report SRI-CSL-92-08, SRI International, July 1992. [36] Oscar Nierstrasz, Simon Gibbs, and Dennis Tsichritzis. Component-Oriented Software Development. Communications of the ACM, 35(9):160{165, September 1992. [37] A.B. Potengy, C.J.P. Lucena, and D.D. Cowan. A Programming Approach for Parallel Rendering Applications. Technical Report 93{62, Computer Science Department and Computer Systems Group, University of Waterloo, Waterloo, Ontario, Canada, March 1993. 25

[38] W. Pree. Meta-patterns: A Means for Describing the Essentials of Reusable O-O Design. In Proceedings of ECOOP'94, 1994. to appear. [39] James Rumbaugh et al. Object-Oriented Modeling and Design. Prentice Hall, 1991. [40] Watcom International Corporation, Waterloo, Ontario, Canada. WATCOM VX
REXX for OS/2 Programmer's Guide and Reference, 1993. [41] G. Wiederhold, P. Wegner, and S. Ceri. Towards Megaprogramming. CACM, 35(11), November 1992.

26