Cooperation Contracts Michael Schre Department of Information Systems Vienna University of Technology Paniglg. 16, A-1040 Vienna, Austria schre @vexpert.dbai.tuwien.ac.at
Gerti Kappel Institute of Statistics and Computer Science University of Vienna Liebigg. 4, A-1010 Vienna, Austria
[email protected]
Abstract
In this paper we introduce the concept of cooperative message handling, in which several objects act together in answering a message they have received jointly. Cooperative message handling extends the traditional message passing paradigm which requires the receiver of a message to be a single object only. Cooperative messages are de ned with cooperation contracts which are established between several object types. A cooperative message is sent to a tuple of instances, one for each object type in the cooperation contract. We show that cooperation contracts o er new bene ts for behavior modeling in object-oriented database design. Behavior which is provided by several object types in concert needs not be dispersed and can be de ned in a single place. Furthermore, behavior designs become symmetric, better maintainable and better extensible.
sign
Keywords: multiple polymorphism, behavior modeling, object-oriented database de-
1 Introduction
Object-oriented database design [1, 6, 19, 22, 30] brings together data modeling and behavior modeling. An object has a set of properties representing its structure and a set of methods representing its behavior. The only way to communicate with an object and manipulate its properties is to invoke a method on the object, which is called message passing. The message passing paradigm is only one of several characteristic features of objectoriented databases [3]. Others, which are of relevance in this paper, are: Classi cation: Objects of the universe of discourse which share the same structure and behavior are classi ed into object types. Encapsulation: There is a clear distinction between the speci cation of a method, which is visible, and its implementation, which is hidden. Specialization and inheritance: Object types can be specialized into subtypes which inherit properties and methods from their supertypes.
The research described in this paper is supported by SIEMENS Austria under grant GR 21/96106/5
Overriding and dynamic binding: The same method may be implemented di erently
with di erent object types. When an object receives a message, a method to handle the message is searched for dynamically. The search starts at the object's type and continues up the type hierarchy until an appropriate method is found. Object-oriented designs o er several bene ts. It is claimed that object-oriented designs concentrate related behavior around objects, are easy to maintain and easy to extend [27]. Classi cation supports concentrating related behavior. Encapsulation, specialization, overriding and dynamic binding assist in maintaining and extending designs. There are, however, also some weak points. It has been recognized [11] that pure object-oriented database models (e.g., [2, 7, 23]) lack a symmetric relationship construct as it is provided by the Entity-Relationship model [9]. If such a construct is missing, a relationship between two object types STUDENT and COURSE is either decomposed into two directed relationships \hasEnrolled" and \isEnrolledBy", represented by properties of the object types STUDENT and COURSE, or it is represented by a third object type ENROLLMENT with two properties \enrolledStudent" and \enrolledCourse", holding references to instances of STUDENT and COURSE. In the rst case, pairs of inverses have to be maintained. In the second case, the instances of COURSE related to a particular instance of STUDENT can not be determined without writing some intrinsic code, which is inherently the same for every object type representing a relationship. For these and other reasons, [10, 25, 29] have suggested to include the relationship construct as a modeling primitive into object-oriented (database) models. Their discussions, however, focus mainly on data modeling and not on behavior modeling. As behavior modeling is concerned, similar problems exist [33]. The traditional objectoriented approach, which requires the receiver of a message to be a single object only, has serious diculties in modeling multi-polymorphic behavior. Behavior which depends on the object types of several objects is called multi-polymorphic. An example of multi-polymorphic behavior is calculating the price of shipping some product p to some customer c, if this calculation depends on the type of product shipped, e.g., hardware or software, and on the type of customer the product is shipped to, e.g., domestic customer or foreign customer. We show that current solutions to model multi-polymorphic behavior in the object-oriented paradigm cause asymmetries and disperse related behavior, or complicate maintenance and later extensions. These diculties can be overcome by providing an equivalent concept for behavior modeling as the relationship construct is in data modeling. We call this concept cooperation contract. A cooperation contract is established between several object types. It de nes how any tuple of instances of these object types handle messages they receive jointly. Thus, cooperation contracts extend the traditional message passing paradigm in that a message may be addressed to several objects in common. At the same time, they utilize key objectoriented concepts, such as classi cation, encapsulation, inheritance, overriding, and dynamic binding. The paper is organized as follows: In section 2, we describe a sample problem of behavior modeling. We recapitulate the essential concepts of object-oriented database models and de ne the notations used within the paper. In section 3, we use the sample problem to discuss bene ts and de ciencies of alternative solutions to handle multi-polymorphic behavior. The purpose of this section is to study the implications of behavior designs which do not make use of a construct equivalent to the relationship construct in data modeling. In section 4, we introduce the concept of cooperation contracts and show how they can be eciently employed in behavior modeling. Section 5 concludes the paper and discusses current and future research topics.
2 A sample problem statement and a simple objectoriented data model
In this section, we give a sample problem statement of behavior modeling and de ne a simple object-oriented data model. The problem statement will be our running example throughout the paper. We omit any details which do not contribute to the essential points of this paper. We could use any of several object-oriented data models [2, 7, 23, 24] for our discussions. As no standard or commonly agreed to object-oriented data model exists [26] and as we do not expect all readers to be familiar with a particular model, we introduce a simple objectoriented data model. It contains the essential features of object-oriented systems, but leaves out concepts and details not needed in this paper. Our purpose is not to introduce a new object-oriented data model, but to have a medium to convey our ideas.
2.1 A sample problem statement
A company located in Austria records names, net prices and sales taxes of its products, which currently include hardware, software and training material. Its customers come from Austria, other countries in Europe, and the US. The problem is to model the pricing policy of the company, which is as follows: The total price a customer has to pay for a product consists of the net price, the sales tax and the shipping charge. Net prices are given with individual products. Sales taxes di er for hardware, software and training material and do not apply to foreign customers. Shipping charges depend on the product and the customer. They are determined as follows: 1. Hardware sales to domestic customers are charged 70 AS (Austrian Shillings) per kilo. 2. Hardware sales to European customers outside Austria are charged 300 AS per kilo. 3. Hardware sales to US-Customers are charged 700 AS per kilo. 4. Software sales to all foreign customers are charged a at rate of 150 AS. 5. All other sales are subject to a handling charge of 50 AS. It is expected that the company will o er additional types of products in the near future. For the moment, the company sells only to European and US customers, but it will soon go into business with customers outside Europe and the US. The pricing policy will be revised then. We have kept the example intentionally very simple. Calculating a shipping charge often means only to return a constant. This will not be the case in a realistic example. For example, the shipping charges of software sales to foreign customers may depend on the number of tapes on which the software is shipped. Therefore, shipping charges can not be stored as data values like, for example, the names of products.
2.2 A simple object-oriented data model
We consider an object-oriented database schema to consist of a set of object types organized in a type hierarchy, which is a forest (set of trees). The object types Integer, String and Boolean are prede ned. Example: The object-oriented database schema of our sample database consists of a type hierarchy of products, i.e., PRODUCT, HARDWARE, SOFTWARE, TRAINING-MATERIAL and a type hierarchy of customers, i.e., CUSTOMER, DOMESTIC-CUSTOMER, FOREIGNCUSTOMER, EUROPEAN-CUSTOMER and US-CUSTOMER (cf. Figure 1).
PRODUCT
HARDWARE
SOFTWARE
TRAINING-MATERIAL
MAINTENANCE-AGRMT
CUSTOMER
DOMESTIC-CUSTOMER
FOREIGN-CUSTOMER
EUROPEAN-CUSTOMER
US-CUSTOMER
ASIAN-CUSTOMER
subtypeOf subtypeOf (later extension)
Figure 1: Object type hierarchy of sample database Every object type de nes a set of properties and a set of methods. The de nition of a property gives its name and the type of its value. The de nition of a method consists of a public interface and a private implementation. The interface of a method consists of a name for the method selector, the names and types of input parameters, and the type of the return value. The implementation of a method is described below. Example: Figure 2 shows the de nition of object type PRODUCT. Object type PRODUCT de nes the properties \name" and \netPrice" of types String and Integer, respectively, and the methods \recordNetPrice", \netPrice", \recordName", \name", and \salesTax". The method \recordName" has one input parameter \n" of type String and returns an instance of PRODUCT. De nitions of properties and methods are inherited from supertypes to subtypes. For simplicity, we require that a subtype may not rede ne an inherited property and may not rede ne the interface of an inherited method. It may, however, give a new implementation. Example: Object type HARDWARE, de ned in Figure 2 as a subtype of PRODUCT, inherits properties and methods of PRODUCT. It introduces a new property \weight" of type Integer and reimplements the method \salesTax". The extension of an object-oriented database schema consists of a set of objects, of which each one is direct instance of exactly one object type. Every object is also an indirect instance of every supertype of its object type. We say an object o is instance of an object type O, if o is direct or indirect instance of O. Every object is described by a value for each property de ned at or inherited to its object type. The value must be an instance of the type of the property. Example: An instance i of object type HARDWARE is described by three values, one for its \name", one for its \netPrice", and one for its \weight".
object type PRODUCT properties name: String; netPrice: Integer; methods recordNetPrice(c: Int) returns PRODUCT f netPrice:= c; return(self) g; netPrice() returns Integer f return(netPrice) g; recordName(n: String) returns PRODUCT f name:= n; return(self) g; name() returns String f return(name) g; salesTax() returns Integer f return(0) g; ... end object type PRODUCT object type HARDWARE subtypeOf PRODUCT properties weight: Integer; methods salesTax() returns Integer f return(20) g; ... end object type HARDWARE
Figure 2: Object types PRODUCT and HARDWARE
The implementation of a method m consists of read and write accesses to properties of the object self (i.e., the object on which the method m is executed), messages, control
ow statements (e.g., case : : :label1 : : : :labelN : : : :endcase), operators of prede ned object types (e.g., + or for Integer), assignment statements of the form variable := : : :, and a return-statement with a single actual parameter. Variables in method implementations are formal input parameters, properties of the object self, the pseudovariable self denoting the object on which a method is executed, and local variables declared as such within the method implementation. A property p of the object self may be read and updated using p as a variable that is read or updated by an assignment statement. Example: The assignment statement \netPrice:= c" in the implementation of the method \recordNetPrice" of object type PRODUCT updates the value of the property \netPrice" of the object self. The return statement \return(netPrice)" in the implementation of the method \netPrice" of object type PRODUCT reads and returns the value of the property \netPrice" of the object self. Sending a message m to an object i, denoted by the variable v, with actual parameters i1; : : :; in, denoted by the variables v1 ; : : :; vn, is written as [v m(v1; : : :; vn)]. Example: Assume the variable p holds an instance of object type HARDWARE. Then the message \[p recordNetPrice(100)]" updates the net price of that instance. The semantics of handling a message m to an object i is as follows: If the object type of which i is direct instance implements a method m, it is executed. Otherwise the method is searched for recursively up the type hierarchy. Example: In the previous example, the method \recordNetPrice" is searched for at object type HARDWARE. No implementation is found. The search is continued at the supertype of HARDWARE, object type PRODUCT, where an implementation is found and executed.
3 Bene ts and de ciences of alternative modeling solutions
In this section we discuss several alternatives to model the pricing policy of our company. Calculating shipping charges is our key interest. Remember, shipping charges depend on the product shipped and on the customer a product is shipped to. Therefore, calculating shipping charges is polymorphic on the type of product (HARDWARE, SOFTWARE, TRAINING-MATERIAL) and on the type of customer (DOMESTIC-CUSTOMER, EUROPEAN-CUSTOMER, US-CUSTOMER). Several solutions to handle such a multi-polymorphic behavior have been proposed in literature for analogous problems [28]. We demonstrate each solution by our example and analyze it according to the following criteria: symmetricity, locality of related behavior, extensibility, and ease of maintenance. These criteria can be tested in our example, as follows: Symmetricity: A solution is symmetric, if it is not biased on products or on customers. It is asymmetric, otherwise.
Locality of related behavior: A solution localizes related behavior, if the information on calculating shipping charges is speci ed in a single place. The solution disperses related behavior, otherwise. Extensibility: A solution is easy to extend, if new types of products and new types of customers can be included without the need of modifying existing types and existing method implementations. To evaluate this criterion, we will consider the e ects of introducing a new type of product, MAINTENANCE-AGRMT, and a new type of customer, ASIAN-CUSTOMER (see: Figure 1) Ease of maintenance: A solution is easy to maintain, if a later revision of the pricing policy causes only minor and simple changes. To evaluate this criterion, we will consider the following revision of the pricing policy: 1. A default handling charge of 0 AS applies to maintenance agreements. 2. A default handling charge of 100 AS applies to all foreign customers. 3. Maintenance agreements with foreign customers are charged 30 AS.1
3.1 The conventional solution
The conventional solution for determining the price of shipping a given product to a given customer is to test for the type of product and for the type of customer and execute appropriate code to that case. The solution is typical for systems, which are not object-oriented. As we will see in our analysis below, the conventional solution has not only drawbacks, but also some merits. Example: Our problem can be solved the conventional way in an object-oriented system by introducing an object `priceCalculator'. That object is the only instance of object type PRICE-CALCULATION de ning the method \shippingCharge(p: PRODUCT, c: CUSTOMER) returns Integer". Its implementation uses nested case-statements to select the calculation appropriate for the given type of product and the given type of customer. (cf. Figure 3). A sales representative using the database can retrieve the price of shipping a given product p to a given customer c by means of a message to the object `priceCalculator', denoted by the variable priceCalculator, i.e., \[priceCalculator shippingCharge(p; c)]". We evaluate the conventional solution: Symmetricity: The conventional solution is symmetric. It is not biased on products or on customers. Locality of related behavior: The conventional solution localizes related behavior. The information on calculating shipping charges is speci ed in a single place, the method \shippingCharge" of object type PRICE-CALCULATION. Extensibility: The solution is hard to extend. Introducing a new type of product, however, is much easier than introducing a new type of customer. To introduce a new type of product, MAINTENANCE-AGRMT, one big nested case-statement has to be added. If a new type of customer, ASIAN-CUSTOMER, is added, the new type of customer must be considered in every outer case-statement of the method \shippingCharge". In both situations, existing code has to be modi ed and recompiled. 1
This statement is needed to resolve the con ict between the previous two ones.
object type PRICE-CALCULATION properties default: Integer; methods shippingCharge(p: PRODUCT, c: CUSTOMER) returns Integer f case p isInstanceOf: HARDWARE: f case c isInstanceOf: DOMESTIC-CUSTOMER: return([p weight()]*70); EUROPEAN-CUSTOMER: return([p weight()]*300); US-CUSTOMER: return([p weight()]*700); end caseg; SOFTWARE: f case c isInstanceOf: DOMESTIC-CUSTOMER: return(default); EUROPEAN-CUSTOMER: return(150); US-CUSTOMER: return(150); end caseg; TRAINING-MATERIAL:f case c isInstanceOf: DOMESTIC-CUSTOMER: return(default); EUROPEAN-CUSTOMER: return(default); US-CUSTOMER: return(default); end caseg; end caseg; ... end object type PRICE-CALCULATION
Figure 3: The conventional solution Ease of maintenance: The conventional solution is hard to maintain. Code in several places has to be changed to take into account a revision of the pricing policy. Updating the default shipping charge for training materials is easier than updating the default shipping charge for foreign customers. To modify shipping charges for training materials, all inner case-statements of a single outer case-statement (TRAINING-MATERIAL) must be considered. To modify the shipping charges for foreign customers, several inner casestatements (EUROPEAN-CUSTOMER, US-CUSTOMER, and ASIAN-CUSTOMER) in all outer case-statements must be considered. Both situations require a detailed analysis of existing code and modi cations in several places. The conventional solution could be simpli ed to some extent by using an otherwiseconstruct in the case-statements. The main problems, however, remain.
3.2 The simple object-oriented solution
An object-oriented solution for determining the price of shipping a given product p to a given customer c is to send the product p a message asking for the price of shipping it to the customer c (or vice versa). The method to handle the message will be implemented di erently for every type of product. In a simple solution, such a method will test the type of customer and execute the appropriate code to that case. Example: The simple object-oriented solution is demonstrated in part in Figure 4. The method \shippingChargeFor(c: CUSTOMER) returns Integer" is de ned at object type PRODUCT and reimplemented at object type HARDWARE.
object type HARDWARE subtypeOf PRODUCT ... methods shippingChargeFor(c: CUSTOMER) returns Integer f case c isInstanceOf: DOMESTIC-CUSTOMER: return(weight*70); EUROPEAN-CUSTOMER: return(weight*300); US-CUSTOMER: return(weight*700); end caseg; ... end object type HARDWARE
Figure 4: The simple object-oriented solution (selected part) A sales representative using the database can retrieve the price of shipping a given product p to a given customer c by means of a message to the product p, i.e., \[p shippingChargeFor(c)]". We evaluate the simple object-oriented solution: Symmetricity: The simple object-oriented solution is asymmetric. It is biased on products. Alternatively, one could bias the solution on customers as well. Locality of related behavior: The simple object-oriented solution localizes related behavior. The calculation of shipping charges is distributed properly in the type hierarchy of products so that the appropriate code is local to each speci c type of product. Extensibility: The simple object-oriented solution can be hard to extend. Adding a new type of product, e.g. MAINTENANCE-AGRMT, is easy. The method \shippingChargeFor" is reimplemented at object type MAINTENANCE-AGRMT and no existing method needs to be modi ed. But, if a new type of customer, e.g., ASIAN-CUSTOMER, is introduced, the implementation of the method \shippingChargeFor" must be modi ed at every leave node of the type hierarchy of product.2 An additional label, ASIAN-CUSTOMER, must be introduced in their case-statements. Ease of maintenance: The simple object-oriented solution can be hard to maintain. It is relatively easy to consider a new default shipping for maintenance agreements. The method \shippingChargeFor" must be reimplemented at object type MAINTENANCEAGRMT taking several labels in the case-statement into account. But it is much harder to consider a new default shipping charge which applies to all foreign customers. The implementation of the method \shippingChargeFor" has to be modi ed at every leave node of the type hierarchy of products. Furthermore, in each implementation several labels in the case-statement, i.e., EUROPEAN-CUSTOMER, US-CUSTOMER, and ASIAN-CUSTOMER, must be considered for possible modi cations. 2
For simplicity, we assume that only leave nodes of the type hierarchy have direct instances.
3.3 The sophisticated object-oriented solution
The sophisticated object-oriented solution eliminates the need of case-statements in the simple object-oriented solution. The trick is to add a second level of messages and to encode in the method selector (message name) the type of the sender [18]. Using this trick, for every leave node X in the type hierarchy of products a method \X -shippingCharge" is de ned at object type CUSTOMER. The method is reimplemented at direct and indirect subtypes of CUSTOMER if needed. Example: Figure 5 demonstrates the approach. Object type CUSTOMER de nes the methods \HW-shippingCharge(p: HARDWARE) returns Integer", \SW-shippingCharge(p: SOFTWARE) returns Integer", and \TM-shippingCharge(p: TRAINING-MATERIAL) returns Integer". Their implementations return the default shipping charge. Each of these methods is overridden at every subtype of CUSTOMER for which the shipping charge di ers from the default shipping charge.3 Like in the simple object-oriented solution, the method \shippingChargeFor(c: CUSTOMER)" is de ned at object type PRODUCT and reimplemented at its subtypes. At a given subtype X of PRODUCT calculating shipping charges is delegated to the customer c, by a message which encodes the type of product in the method selector. Example: The method \shippingChargeFor(c: CUSTOMER)" is implemented at the object type HARDWARE as \f return([c HW-shippingCharge(self)]) g". We evaluate the sophisticated object-oriented solution: Symmetricity: Like the simple object-oriented solution, the sophisticated object-oriented solution is asymmetric. It is biased on products with respect to the external interface, and it is biased on customers with respect to calculating shipping charges. Locality of related behavior: Unlike the simple object-oriented solution, the sophisticated object-oriented solution disperses related behavior. Methods representing the pricing policy are distributed among several object types of two type hierarchies. Extensibility: The sophisticated object-oriented solution is relatively easy to extend. If a new type of product or a new type of customer is introduced, no existing implementations of methods need to be changed. Inherited methods need to be reimplemented at subtypes, and sometimes, new methods need to be introduced. If a new type of product, e.g. MAINTENANCE-AGRMT (MA), is added, a method \MA-shippingCharge(p: MAINTENANCE-AGRMT) returns Integer" has to be introduced at object type CUSTOMER, and the method \shippingChargeFor" of object type MAINTENANCE-AGRMT is reimplemented such that it invokes the method \MA-shippingCharge". If a new type of customer, e.g., ASIAN-CUSTOMER is introduced the methods \X -shippingCharge" (where X is a leave node in the type hierarchy of products) must be reimplemented for the case that a di erent shipping charge applies to asian customers than to foreign customers in general.
Only some implementations of the method \HW-shippingCharge" make actually use of the inputparameter p. To design for reusability, all other methods take a product p as input parameter, although it is not really needed to implement the current pricing policy. 3
object type HARDWARE subtypeOf PRODUCT methods weight(): Integer; shippingChargeFor(c: CUSTOMER) returns Integer freturn([c HW-shippingCharge(self)])g; ... end object type HARDWARE object type CUSTOMER methods defaultShippingCharge() returns Integer f return(50) g; HW-shippingCharge(p: HARDWARE) returns Integer f [self defaultShippingCharge()] g; SW-shippingCharge(p: SOFTWARE) returns Integer f [self defaultShippingCharge()] g; TM-shippingCharge(p: TRAINING-MATERIAL) f [self defaultShippingCharge()] g; ... end object type CUSTOMER object type DOMESTIC-CUSTOMER methods HW-shippingCharge(p: HARDWARE) returns Integer f return([p weight()]*70) g; ... end object type DOMESTIC-CUSTOMER object type FOREIGN-CUSTOMER methods SW-shippingCharge(p: SOFTWARE) returns Integer f return(150) g; ... end object type FOREIGN-CUSTOMER object type EUROPEAN-CUSTOMER methods HW-shippingCharge(p: HARDWARE) returns Integer f return([p weight()]*300) g; ... end object type EUROPEAN-CUSTOMER object type US-CUSTOMER methods HW-shippingCharge(p: HARDWARE) returns Integer f return([p weight()]*700) g; ... end object type US-CUSTOMER
Figure 5: The sophisticated object-oriented solution
Ease of maintenance: The solution is sometimes hard to maintain. It is very easy to consider a new default shipping charge for maintenance agreements. Only the implementation of the method \MA-shippingCharge" of object type CUSTOMER has to be modi ed. But it is more dicult to take a new default shipping charge for foreign customers into account. Several methods of FOREIGN-CUSTOMER (the methods \SW-shippingCharge", \HW-shippingCharge", and \TM-shippingCharge") need to be reimplemented. Some object-oriented languages, e.g., C++ [12], allow to overload method selectors of one object type. Several methods having the same selector are distinguished by the types of their input parameters. This gives rise to another approach to handle multi-polymorphic behavior. In our example, one would de ne for each type of customer Y a method \shippingChargeFor(c: Y )" at object type PRODUCT and reimplement this method at subtypes of PRODUCT. It is left to the reader to evaluate this solution. It is equivalent to the sophisticated object-oriented solution with respect to our comparison criteria, except that it localizes related behavior in the type hierarchy of products.
3.4 Summary
We have analyzed and evaluated three solutions to model multi-polymorphic behavior. The rst three columns of Table I summarize the result. The fourth column concerns cooperation contracts, which are introduced in the next section. conventional simple oo sophisticated oo contracts symmetricity + + + + -(+) + locality extensibility +/+ +/+ maintenance Table 1: Comparison of di erent solutions to model multi-polymorphic behavior The entry in parenthesis refers to overloading method selectors of one object type
4 Cooperation Contracts
In the previous section we have discussed several alternatives to model multi-polymorphic behavior. We have seen that every solution falls short in at least one of four criteria: symmetricity, locality of related behavior, extensibility, and ease of maintenance. All solutions have in common that they employ the traditional message passing paradigm, which require the receiver of a message to be a single object only. It is claimed that object-oriented designs concentrate related behavior around object types, are easy to extend and easy to maintain [27]. This is true, if the behavior to be modeled depends on only one type of object. We have seen that this is false in our example, in which the calculation of shipping charges depends on the type of product shipped and on the type of customer the product is shipped to. In this section, we suggest a solution by extending the traditional message passing paradigm. We introduce the concept of cooperative message handling. A cooperative message is a message which is sent jointly to several objects. Note: Such a message is not received several times by each object alone, but once by all objects together. An example of a cooperative message is the message \shippingCharge" sent jointly to a product p and a customer c. We will denote such a message by \[hp; ci shippingCharge()]".
Cooperative messages are de ned with cooperation contracts which are established between several object types. A cooperation contract ful lls a similar purpose in behavior modeling as the symmetric, undirected relationship does in data modeling. Symmetric, undirected relationships are used in data modeling to express relations between several objects. They make an abstract interaction between several objects explicit in a natural way and avoid to bury such interactions in binary directed relationships (as many object-oriented data models require [2, 7, 23]). Similarly, cooperation contracts make a behavioral interaction between instances of several object types explicit. They avoid that one of several objects has to be singled out arbitrarily as target of a message whose answer depends on an interaction of several objects. Note that the receivers of a cooperative message are not connected by a stored relationship. In our example, one can ask the price of shipping any product p to any customer c. Of course, one will not store all possible pairs of products and customers (i.e., all possible orders). Multi-methods of CommonLoops [4] support multi-polymorphic behavior in a similar way. Multi-methods overload a method selector with several methods which are distinguished by the types of their parameters. Cooperative methods di er from multi-methods as follows: Multi-methods are de ned freely (i.e., independent of object types), and, hence, violate the object-oriented concept of classi cation. Cooperative methods are de ned with cooperation contracts, and thus, comply to an extended notion of classi cation. (This will be explained in the next subsection.) Cooperation contracts group together several related cooperative methods and can be specialized in a similar way as object types. They support inheritance, overriding, and dynamic binding of methods. The remainder of this section is organized as follows. We introduce the concept of cooperation contracts in the rst subsection. We discuss how cooperation contracts obey key object-oriented concepts such as classi cation, encapsulation, inheritance, overriding and dynamic binding, and we describe cooperative message handling informally. In the second subsection, we de ne the semantics of cooperative message handling formally.
4.1 The concept
A cooperation contract is established between several object types, which are referred to as partner types of the cooperation contract. For sake of simplicity, we will consider only binary cooperation contracts in the following and require that at most one cooperation contract exists between any two object types. Furthermore, we will not consider cooperation contracts in which the same object type occurs twice as partner type. This helps us concentrate on essential points and simpli es our discussions. A binary cooperation contract is established between two partner types and de nes a set of cooperative methods.4 The interface of a cooperative method is de ned the same way as it is for a method of an object type. The implementation of a cooperative method is described below. Example: The cooperation contract PRICING is de ned between partner types PRODUCT and CUSTOMER in Figure 6. It de nes the cooperative methods \shippingCharge() returns Integer" and \totalPrice() returns Integer". A cooperative method is invoked by a cooperative message addressed to one instance of each object type in the cooperation contract. A cooperative message m addressed to two
Cooperation contracts are given a unique name, although this name is redundant if at most one cooperation contract exists between the same object types. In this case the partner types already identify the cooperation contract. 4
objects i1 and i2, denoted by variables v1 and v2, with actual parameters j1; : : :; jn, denoted by variables w1; : : :wn, is written as [hv1; v2i m(w1; : : :; wn)]. Example: If p denotes a product and c a customer, the cooperative message \[h p, c i shippingCharge()]" is handled by the cooperative method \shippingCharge" of cooperation contract PRICING and returns the price of shipping product p to customer c. The implementation of a cooperative method is de ned the same way as it is for a method of an object type, except that several receivers have to be distinguished. To denote a particular receiver, we use the expression self(X ), where X is one partner type of the cooperation contract at which the cooperative method is de ned. Example: The message \[ self(PRODUCT) netPrice() ]" is used in the implementation of the method \totalPrice" of cooperation contract PRICING to retrieve the net price of that product being one of the receivers of the cooperative message \totalPrice". We show in the following paragraphs how cooperation contracts support and extend key object-oriented concepts. Cooperation contracts comply to an extended de nition of classi cation. The traditional de nition requires that every object is direct instance of exactly one object type. Furthermore, every message understood by an object o is de ned at an object type O of which o is a direct or indirect instance. We extend this de nition as follows for cooperative messages: Any cooperative message understood by a pair of objects o1 and o2 must be de ned at a cooperation contract that is established between two object types O1 and O2 of which o1 and o2 are direct or indirect instances. We say a pair of objects o1 and o2 are subject to a cooperation contract C , i o1 and o2 are direct or indirect instances of the partner types of C . Cooperation contracts support encapsulation. Only the interfaces of cooperative methods are public, their implementations are private. Cooperation contracts support inheritance. A cooperation contract between two partner types O1 and O2 de nes not only the cooperative behavior of pairs of direct instances of O1 and O2 but also the cooperative behavior of pairs of direct or indirect instances of O1 and O2. Example: If p denotes an instance of SOFTWARE and c denotes an instance of DOMESTICCUSTOMER, the cooperative message \[hp; ci shippingCharge()]" is de ned for p and c. The message is understood by p and c, because the cooperative method \shippingCharge" is de ned at cooperation contract PRICING, whose partner types PRODUCT and CUSTOMER are supertypes of SOFTWARE and DOMESTIC-CUSTOMER, respectively. Cooperation contracts support specialization, overriding and dynamic binding. We say a cooperation contract C 0 between two partner types O10 and O20 specializes a cooperation contract C between two partner types O1 and O2, i (i) O10 is identical to O1, or O10 is a direct or indirect subtype of O1, and (ii) O20 is identical to O2, or O20 is a direct or indirect subtype of O2, and (iii) O10 is di erent from O1, or O20 is di erent from O2.
cooperation contract PRICING between PRODUCT and CUSTOMER methods shippingCharge() returns Integer f return(50) g totalPrice() returns Integer f return([ self(PRODUCT) netPrice()] + [self(PRODUCT) salesTax()] + [h self(PRODUCT),self(CUSTOMER) i shippingCharge()]) g end cooperation contract PRICING cooperation contract PRICING-FOREIGN between PRODUCT and FOREIGN-CUSTOMER methods totalPrice() returns Integer f return([self(PRODUCT) netPrice()]+ [h self(PRODUCT),self(FOREIGN-CUSTOMER) i shippingCharge()]) g end cooperation contract PRICING-FOREIGN cooperation contract PRICING-SW-FOREIGN between SOFTWARE and FOREIGN-CUSTOMER methods shippingCharge() returns Integer f return(150) g end cooperation contract PRICING-SW-FOREIGN cooperation contract PRICING-HW-DOMESTIC between HARDWARE and DOMESTIC-CUSTOMER methods shippingCharge() returns Integer f return([self(HARDWARE) weight()]*70) g end cooperation contract PRICING-HW-DOMESTIC cooperation contract PRICING-HW-EUROPEAN between HARDWARE and EUROPEAN-CUSTOMER methods shippingCharge() returns Integer f return([self(HARDWARE) weight()]*300) g end cooperation contract PRICING-HW-EUROPEAN cooperation contract PRICING-HW-US between HARDWARE and US-CUSTOMER methods shippingCharge() returns Integer f return([self(HARDWARE) weight()]*700) g end cooperation contract PRICING-HW-US
Figure 6: Cooperation contracts
Example: Cooperation contract
PRICING-FOREIGN between partner types PRODUCT and FOREIGN-CUSTOMER specializes cooperation contract PRICING between partner types PRODUCT and CUSTOMER, as FOREIGN-CUSTOMER is a subtype of CUSTOMER (see Figure 6 and 7).
A cooperation contract C 0 which specializes a cooperation contract C may de ne new cooperative methods and may reimplement any cooperative method of C . Example: Cooperation contract PRICING-FOREIGN reimplements the cooperative method \totalPrice" of cooperation contract PRICING. The new implementation takes into account that foreign customers are exempted from paying a sales tax. We describe now informally how cooperative messages are handled. A formal treatment is given in the next subsection. A cooperative message m addressed to two objects o1 and o2 is handled as follows: 1. A most speci c cooperation 5contract C to which o1 and o2 are subject and which implements m is determined. A cooperation contract C is a most speci c cooperation contract to which o1 and o2 are subject and which implements m, if o1 and o2 are subject to C , C implements m, and if there exists no other cooperation contract C 0 specializing C with this property. 2. The implementation of the method m given at C is selected and executed. Example: Consider the cooperative messages \[hp; ci shippingCharge()]" and \[hp; ci totalPrice()]" in which p denotes a direct instance of TRAINING-MATERIAL and c a direct instance of EUROPEAN-CUSTOMER. Assume the cooperation contracts shown in Figure 6 have been de ned. The pair of objects o1 and o2 are subject to the cooperation contract PRICING- FOREIGN, established between partner types PRODUCT and FOREIGNCUSTOMER, and to the cooperation contract PRICING, established between partner types PRODUCT and CUSTOMER. As the rst cooperative message is concerned, only the cooperation contract PRICING implements the method \shippingCharge". Therefore the implementation of the method \shippingCharge" given at cooperation contract PRICING is executed and will return the default shipping charge of 50 AS. As the second cooperative message is concerned, both cooperation contracts implement the method \totalPrice". Cooperation contract PRICING-FOREIGN specializes cooperation contract PRICING. Therefore the implementation of the method \totalPrice" given at cooperation contract PRICING-FOREIGN is selected and executed. The pricing policy of our company is represented by the cooperation contracts in Figure 6. Their specialization hierarchy is represented in Figure 7. Notice that every statement about the pricing policy (see section 2) is re ected by exactly one method implementation. The method is implemented at that cooperation contract whose partner types are identi ed in the statement. Example: The statement \Software sales to all foreign customers are charged a at rate of 150 AS" is re ected by the implementation of the method \shippingCharge" of cooperation contract PRICING-SW-FOREIGN established between partner types SOFTWARE and FOREIGN-CUSTOMER. 5
There may be several. How such a situation is handled, will be discussed later.
PRICING
PRICING-HW-DOMESTIC
PRICING-FOREIGN
PRICING-MA
PRICING-MA-FOREIGN
PRICING-HW-US
PRICING-SW-FOREIGN
PRICING-HW-EUROPEAN has-most-specific-supercontract has-most-specific-supercontract (later extension)
Figure 7: Specialization hierarchy of cooperation contracts We evaluate the cooperation contract solution: Symmetricity: The cooperation contract solution is symmetric. It is not biased on either products or customers. Locality of related behavior: The cooperation contract solution localizes related behavior. Behavior which is contributed to several object types, such as the pricing policy, is not dispersed but de ned in a single place, the specialization hierarchy of cooperation contract PRICING. Extensibility: The cooperation contract solution is easy to extend. If a new type of product, e.g., MAINTENANCE-AGRMT, or a new type of customer, e.g., ASIAN-CUSTOMER, is added, no existing implementations of methods need to be modi ed and no additional types of methods need to be introduced (such as \typeOfProduct-shippingCharge" in the sophisticated object-oriented solution). Default shipping charges apply to the new product and the new type of customer immediately. Because of inheritance, direct instances of MAINTENANCE-AGRMT are subject to all cooperation contracts in which6 the supertype of MAINTENANCE-AGRMT, object type PRODUCT, is a partner type. Similarly, direct instances of ASIAN-CUSTOMER are subject to all cooperation con-7 tracts in which a direct or indirect supertype of ASIAN-CUSTOMER is partner type. If for a new type of product or a new type of customer special shipping charges apply, new cooperation contracts reimplementing the cooperative method \shippingCharge" are de ned. This is a special form of maintenance and can be handled easily as it is shown in the next paragraph. Ease of maintenance: The cooperation contract solution is easy to maintain. The design is properly modular. To revise the pricing policy as required by the three statements in section 3 is very easy. To consider the default shipping charge for maintenance agreements and all customers, a new cooperation contract PRICING-MA between object types MAINTENANCE-AGRMT and CUSTOMER (Figure 8) is de ned. To consider the default shipping charge of 100 AS for all products and foreign customers the method \shippingCharge" is reimplemented at cooperation contract PRICING-FOREIGN, which 6 7
These are the cooperation contracts These are the cooperation contracts
PRICING
,
PRICING
and
in Figure 6. , and
PRICING-FOREIGN
PRICING-FOREIGN
PRICING-SW-FOREIGN
in Figure 6.
cooperation contract PRICING-MA between MAINTENANCE-AGRMT and CUSTOMER methods shippingCharge() returns Integer f return(0) g end cooperation contract PRICING-MA cooperation contract PRICING-FOREIGN between PRODUCT and FOREIGN-CUSTOMER methods totalPrice() returns Integer f return([self(PRODUCT) netPrice()]+ [h self(PRODUCT), self(FOREIGN-CUSTOMER) i shippingCharge()])g shippingCharge() returns Integer f return(100) g end cooperation contract PRICING-FOREIGN cooperation contract PRICING-MA-FOREIGN between MAINTENANCE-AGRMT and FOREIGN-CUSTOMER methods shippingCharge() returns Integer f return(30) g end cooperation contract PRICING-MA-FOREIGN
Figure 8: Cooperation contracts (extension and revision)
has already been established between object types PRODUCT and FOREIGN-CUSTOMER. To model the calculation of shipping charges for maintenance agreements and foreign customers, a new cooperation contract PRICING-MA-FOREIGN is introduced (Figure 8). Table I compares the previous solutions ( rst three columns) to the solution with cooperation contracts (last column). It has been mentioned above that handling a cooperative message [ho1; o2i; m] can be ambiguous, if more than one most speci c cooperation contract C to which o1 and o2 are subject and which implements m exists. Example: Consider the cooperative message \[hp; ci shippingCharge()]" in which p denotes a direct instance of MAINTENANCE-AGRMT and in which c denotes a direct instance of FOREIGN-CUSTOMER. Assume that the method \shippingCharge" has not been implemented at cooperation contract PRICING-MA-FOREIGN or cooperation contract PRICING-MA-FOREIGN has not been de ned at all. Then, two most speci c cooperation contracts to which p and c are subject and which implement the method \shippingCharge" exist, PRICING-MA and PRICING-FOREIGN (cf. Figures 6, 7 and 8). There are two possible solutions to the problem. The rst one is8 to forbid such a situation at all. The second one is to de ne a con ict resolution scheme. We believe that the rst solution is more appropriate as any ambiguity indicates that the problem statement is incomplete. For example, the rst two statements of the revised pricing policy (see section 3) leave open how sales of maintenance agreements to foreign customers are to be charged. One could either decide to use the default shipping charge for maintenance agreements or to use the default shipping charge for foreign customers. The con ict can be resolved by adding a statement concerning this situation. This has been done in the revision of the pricing policy. As the second solution is concerned, we need to de ne a con ict resolution scheme. A possible con ict resolution is to give the rst receiver priority over the second receiver. This would mean in our previous example that the default shipping charge for maintenance agreements applies (supposing that the maintenance agreement is the rst addressee of the cooperative message \shippingCharge"). We have chosen this con ict resolution scheme in the following subsection, which describes the formal semantics of cooperative message handling. Nevertheless, we believe that ambiguities should be avoided in general. Then the con ict resolution scheme is not needed.
4.2 The formal semantics of cooperative message handling
We use the evolving algebra approach [15] to de ne the semantics of cooperative message handling formally. An evolving algebra consists of a pair (A; T ), where A is a many-sorted, partial algebra and T a set of transition rules. Evolving algebras have been successfully employed to de ne the operational semantics of several conventional programming languages [5, 16, 17] and of object-oriented systems [14]. The operational semantics of a program is speci ed by an abstract machine which simulates the execution of the program. Using the evolving algebra approach, the algebra A de nes the initial state of an abstract machine and the transition rules in T de ne the transitions from one state to the next state. The algebra A is said to evolve, as every application of a transition rule results in a new algebra A0. In the following, we give a (simpli ed) de nition of an evolving algebra [15]. 8
The problem is related to resolving ambiguities due to multiple inheritance [32].
De nition: An evolving algebra is a pair (A; T ), where A is a many-sorted, partial algebra
and T is a set of transition rules. The algebra A consists of a set of universes and a set of functions on Cartesian products of these universes.9 The transition rules in T have the form if b then f (e1; :::; ek) := e0, where (1) b is a closed boolean expression over the signature of A (2) f: U1 : : :Uk ! U0 is a function in A, and (3) e0; :::; ek are closed expressions over the universes U0; : : :Uk .10 The result of applying a transition rule if b then f (e1; :::; ek) := e0 on an algebra A0 is an algebra A00 which is identical to0 A0, except that f (a1; :::; ak) = a0, where a0; :::; ak are the evaluations of e0; :::; ek in A . We now de ne an evolving algebra (Ac; Tc) whose universes, functions, and transition rules express the semantics of cooperative message handling. The algebra (Ac; Tc) models a cooperative message handler which given a cooperative message selects the appropriate method implementation. The algebra (Ac; Tc) does not represent the executions of methods. It may be extended in that direction following the approach outlined in [14]. De nition: The algebra Ac consists of the universes O, I , M and F representing object types, instances of object types (objects), message selectors, and method implementations, respectively. In addition, the algebra Ac consists of the following total functions: The function instanceOf : I ! O maps every object to its object type. The function subtypeOf : O ! O maps an object type o to its supertype or, if o has no supertype, to `unde ned'. The function mImpl : M (O O) ! F maps a message selector m 2 M and a pair of object types (o1 ; o2) 2 O O to a method implementation, if a binary cooperation contract between partner types o1 and o2 exists and if this cooperation contract implements m; the function maps to `unde ned', otherwise. The functions instanceOf , subtypeOf , and mImpl are static, i.e., they are not changed by the transition rules in Tc . For simplicity, we de ne the derived relation subtypeOf + O O: For o 2 O, o0 2 O, + (o; o0) 2 subtypeOf , 9o1 2 O; : : : on 2 O (n > 1) such that o = o1, o0 = on and for i = 2::n subtypeOf (oi?1 ) = oi . Furthermore, Ac contains the following 0-ary functions (i.e, variables): i1 2 I and i2 2 I represent the pair of receivers of a cooperative message, m 2 M represents the message selector, j1 2 I; : : :jn 2 I represent the actual parameters, AT1 2 O as well as AT2 2 O hold an object type. i1; i2; m; j1; : : :; jn are initialized according to the cooperative message to be handled. AT1 and AT2 are unde ned originally and are changed by the transition rules in Tc. The changes of AT1 and AT2 re ect the search of a method implementation. The transition rules of Tc are shown in Figure 9.
The algebra A may also contain relations over Cartesian products of its universes for notational convenience. Every relation can be represented by a boolean function, mapping a tuple to true if it is contained in the relation and to false if it is not contained in the relation. 10Transition rules may be nested for notational convenience. For example, the transition rule if b then if b1 then r1 endif, if b2 then r2 endif endif. is a shorthand notation for the two rules (1) if b ^ b1 then r1 endif. and (2) if b ^ b2 then r2 endif. 9
if AT1 = `unde ned' then AT1 := instanceOf (i1); endif. if AT2 = `unde ned' then AT2 := instanceOf (i2); endif. if AT1 6= `unde ned' ^ AT2 6= `unde ned' ^ mImpl(m; (AT1; AT2)) = `unde ned' then if 6 9o 2 O : (mImpl(m; (AT1; o)) 6= `unde ned' ^ (AT2; o) 2 subtypeOf + ) ^subtypeOf (AT1) 6= `unde ned' then AT1 := subtypeOf (AT1) endif, if 9o 2 O : mImpl(m; (AT1; o) 6= `unde ned' ^ (AT2; o) 2 subtypeOf + then AT2 := subtypeOf (AT2) endif, if subtypeOf (AT1) = `unde ned' ^ subtypeOf (AT2) = `unde ned' then f \report error" g endif endif. Figure 9: Transition rules The algebra (Ac; Tc) models the message handler as follows. Given a message [hi1; i2i m(j1; : : :; jn )], the transition rules in Tc are applied repeatedly until no more rule can be applied. The resulting algebra A0c de nes AT1 and AT2, such that mImpl(m; (AT1; AT2)) holds the appropriate method implementation to be executed. We brie y discuss the transition rules. The rst and second transition rule initialize AT1 and AT2 with the object types of the receivers i1 and i2, respectively. The third transition rule searches a most speci c cooperation contract for AT1 and AT2 that implements m. The nested transition rules replace AT1 and AT2 by their supertypes such that nally AT1 and AT2 are partner types of a cooperation contract that implements m. In case of ambiguous cooperation contracts, the object type of the rst receiver (AT1) is given precedence over the object type of the second receiver (AT2). Thus, the supertype hierarchy of AT1 is searched after the supertype hierarchy of AT2. The search fails, if no cooperation contract in which AT1 and AT2 are partner types and which implements m exists and if both, AT1 and AT2, have no supertype. The search succeeds if AT1 and AT2 are partner types of a cooperation contract which implements a method for m. In this case, no more transition rule can be applied. An actual implementation of a message handler for cooperative messages may be realized more eciently. For example, it may use a precomputed hash table, in which a pair of object types and a method selector are mapped to the appropriate method implementation. We have employed the evolving algebra approach to de ne the formal semantics of cooperative message handling independent of a particular implementation. The formal speci cation can be used to verify the correctness of any actual implementation, e.g., that of the hash table.
5 Conclusion
We have presented a novel concept for behavior modeling in object-oriented database design, cooperation contracts. Cooperation contracts are the behavioral equivalent to the symmetric, undirected relationship construct in data modeling. Symmetric, undirected relationships make an abstract interaction between several objects explicit in a natural way. Similarly, cooperation contracts make a behavioral interaction between any instances of several object types explicit. They avoid that one of several objects has to be singled out arbitrarily as target of a message whose answer depends on an interaction of several objects. Cooperation contracts extend traditional object-oriented concepts, such as classi cation, encapsulation, inheritance, overriding, and dynamic binding. They o er new bene ts for behavior design. Whereas the traditional object-oriented approach has serious diculties in modeling multi-polymorphic behavior, cooperation contracts provide a clean solution. They produce symmetric designs, which localize related behavior and which are easy to extend and to maintain. We made some simplifying assumptions in this paper. For example, we considered only binary cooperation contracts. We believe that an extension to n-ary cooperation contracts is rather straightforward. Cooperation contracts can be included as a primary concept for behavior modeling in any object-oriented design technique. We currently extend our graphical design environment of object-oriented databases, Object/Behavior Diagrams [20, 21], in that direction.
Acknowledgement
Thanks are due to J. Eder, M. Stumptner, and the anonymous referees for valuable comments.
References
[1] J. Almarode and T.L. Anderson, \EasyObjects Designer: A Tool for Object-Oriented Database Design," in Proceedings of the IFIP TC2 Working Conference on Object-Oriented Databases (DS-4), ed. R. Meersman and W. Kent, North-Holland, 1990. [2] T. Andrews and C. Harris, \Combining language and database advances in an object-oriented development environment," in Object-Oriented Programming Systems Languages and Applications (OOPSLA), Special Issue of SIGPLAN Notices, ed. N. Meyrowitz , vol. 22, no. 12, pp. 430-440, Dec. 1987. [3] M.B. Atkinson, F. Bancilhon, D. DeWitt, K. Dittrich, D. Maier and S. Zdonik, \The ObjectOriented Database System Manifesto," in Proceedings First Int. Conf. on Deductive and Object-Oriented Databases, pp. 40-57, Kyoto, Japan, Dec. 1989. [4] D.G. Bobrow, et al., \CommonLoops: Merging Lisp and Object-Oriented Programming," in Object-Oriented Programming Systems Languages and Applications (OOPSLA), Special Issue of SIGPLAN Notices, ed. N. Meyrowitz, vol. 21, no. 11, pp. 17-29, Nov. 1986. [5] E. Borger , \A Logical Operational Semantics of Full Prolog, Part I: Selection Core and Control," in CSL'89, 3rd Workshop on Computer Science Logic, ed. E. Borger, H. Kleine Buning, and M. Richter, Springer, LNCS, 1990. [6] M. Bouzeghoub and E. Metais, \A Design Tool For Object Oriented Databases," in CAiSE, Proceedings of the 2nd Nordic Conf. on Advanced Information Systems Engineering, pp. 365392, May 1990.
[7] R. Bretl et al, \The GemStone Data Management System," in Object-Oriented Concepts, Databases, and Applications, ed. W. Kim and F.H. Lochovsky, pp. 283-308, ACM Press & Addison-Wesley, 1989. [8] P. Butterworth, A. Otis and J. Stein, \The GemStone Object Datebase Management System," in Communications of the ACM, vol. 34, no. 10, pp 64{77, October 1991 [9] P.P. Chen, \The Entity-Relationship Model - Toward a uni ed view of data," in ACM Transcations on Database Systems, vol. 1, no. 1, pp. 9-36, 1976. [10] O. Diaz and P. Gray , \Semantic-rich User-de ned Relationships as a Main Constructor in Object-Oriented Databases," in Proceedings of the IFIP TC2 Working Conference on ObjectOriented Databases (DS-4), ed. R. Meersman and W. Kent, North-Holland, 1990. [11] K. Dittrich, \Object-Oriented Database Systems: The Next Miles of the Marathon," in Information Systems, vol. 15, no. 1, pp. 161-167, 1990. [12] M.A. Ellis and B. Stroustrup, in The Annotated C++ Reference Manual, Addison-Wesley, 1990. [13] A. Goldberg and D. Robson, \Smalltalk-80: The Language And Its Implementation," AddisonWesley, May 1983 [14] G. Gottlob, G. Kappel and M. Schre , \Semantics of Object-Oriented Data Models - The Evolving Algebra Approach," in Next Generation Information System Technology, Proceedings of the First International East/West Database Workshop, ed. J.W. Schmidt and A.A. Stogny, pp. 144-160, Springer LNCS 504, 1991. [15] Y. Gurevich, \Logic and the Challenge of Computer Science," in Trends in Theoretical Computer Science, ed. E. Borger, pp. 1-57, Computer Science Press, 1988. [16] Y. Gurevich and J.M. Morris, \Algebraic Operational Semantics and Modula-2," in CSL'87, 1st Workshop on Computer Science Logic, ed. E. Borger, H. Kleine Buning, and M. Richter, Springer, LNCS 329, 1988. [17] Y. Gurevich and L.S. Moss, \Algebraic Operational Semantics and Occam," Tech. Rep. RC 15352, IBM Research Division, 1/9/90, T.J. Watson Research Center, Yorktown Heights, 1990. [18] D. Ingalls, \A simple technique for handling multiple polymorphism," in Object-Oriented Programming Systems Languages and Applications (OOPSLA), Special Issue of SIGPLAN Notices, ed. N. Meyrowitz, vol. 21, no. 11, pp. 347-349, Nov. 1986. [19] G. Kappel and M. Schre , \A Behaviour Integrated Entity Relationship Approach for the Design of Object-Oriented Databases," in A Bridge to the User, Proceedings of the 7th Int. Conf. on ER Approach, ed. C. Batini, pp. 311-328, North-Holland, 1989. [20] G. Kappel and M. Schre , \Using an Object-Oriented Diagram Technique for the Design of Information Systems," in Proceedings of the International Working Conference on Dynamic Modelling of Information Systems , ed. H.G. Sol, North-Holland, 1991. [21] G. Kappel and M. Schre , \Object/Behavior Diagrams," in Proceedings of the 7th International Conference on Data Engineering, pp. 530-539, IEEE Computer Society Press, Kobe, Japan, April 1991. [22] G. Kappel, \Reorganizing Object Behavior by Behavior Composition - Coping with Evolving Requirements in Oce Systems," in Proceedings BTW'91 (Datenbanken f"ur B"uro, Technik und Wissenschaft), ed. H.-J. Appelrath, Springer IFB 270, Kaiserslautern, Germany, March 1991. [23] W. Kim, J.F. Garza, N. Ballou and D. Woelk, \Architecture of the ORION Next-Generation Database System," in IEEE Transactions on Knowledge and Data Engineering, vol. 2, no. 1, pp. 109-124, March 1990. [24] C. Lecluse, P. Richard and F. Velez, \O2, an object-oriented data model," in Proceedings of the ACM-SIGMOD Int.Conference on Management of Data, SIGMOD Record, vol. 17, no. 3, pp. 424-433, Chicago, 1988.
[25] M. Loomis, A. Shah and J. Rumbaugh, \An Object Modelling Technique for Conceptual Design," in Proc. of the European Conference on Object-Oriented Programming, pp. 325-335, 1987. [26] D. Maier, \Why isn't there an object-oriented data model?," in Information Processing 89 IFIP World Computer Congress, ed. G.X. Ritter, pp. 793-798, North-Holland, 1989. [27] B. Meyer, Object-Oriented Software Construction, Prentice-Hall, 1988. [28] J. Micallef, \Encapsulation, Reusability and Extensibility in Object-Oriented Programming Languages," in Journal of Object-Oriented Programming (JOOP), pp. 12-36, April/May 1988. [29] J. Rumbaugh, \Relations as Semantic Constructs in an Object-Oriented Language," in ObjectOriented Programming Systems Languages and Applications (OOPSLA), Special Issue of SIGPLAN Notices, ed. N. Meyrowitz , vol. 22, no. 12, pp. 466-481, Dec. 1987. [30] M. Schre , \Behavior Modeling by Stepwise Re ning Behavior Diagrams," in Proceedings of the 9th Int. Conf. on Entity Relationship Approach, Lausanne, October 1990. [31] M. Schre and G. Kappel, \Cooperation Contracts" in Proceedings of the 10th International Conference on Entity Relationship Approach, San Mateo (CA), October 1991. [32] A. Snyder, \Inheritance and the Development of Encapsulated Software Components," in Research Directions in Object-Oriented Programming, ed. P. Wegner, pp. 165-188, The MIT Press, 1987. [33] S.B. Zdonik and D. Maier, \Fundamentals of Object-Oriented Databases," in Readings in Object-Oriented Database Systems, ed. S.B. Zdonik and D. Maier, pp. 1-36, Morgan Kaufmann Publishers, 1990.
