Modeling Collaborative Behavior Using. Cooperation Contracts. Peter Lang. Abstract

Transcription

1 Modeling Collaborative Behavior Using Cooperation Contracts Michael Schre Institut fur Wirtschaftsinformatik Johannes Kepler Universitat Linz Altenbergerstr. 69, A-4040 Linz, Austria Gerti Kappel Institut fur Angewandte Informatik Johannes Kepler Universitat Linz Altenbergerstr. 69, A-4040 Linz, Austria Peter Lang Institut fur Wirtschaftsinformatik Johannes Kepler Universitat Linz Altenbergerstr. 69, A-4040 Linz, Austria Abstract Several objects exhibit collaborative behavior if they act together in answering a message they have received jointly. Collaborative behavior is dened by cooperation contracts which are established between several object classes and which declare a set of cooperative methods. A cooperative method is invoked by a cooperative message sent to a tuple of instances, one for each object class in the cooperation contract. This extends the traditional message passing paradigm which requires the receiver of a message to be a single object only. Cooperation contracts oer several benets for behavior modeling in objectoriented database design. Behavior provided by several object classes in concert needs not be dispersed and can be dened in a single place. Therefore, behavior designs become symmetric, better maintainable and better extensible. Cooperation contracts can easily be made available as benecial modeling construct in existing object-oriented database management systems by adding a few classes. This paper presents such an extension based on the commercial object-oriented database management system GemStone. Keywords: multiple polymorphism, collaborative behavior modeling, cooperation contracts, object-oriented database design Peter Lang is funded by the Austrian Science Foundation (FWF) under contract P10320-MAT. 1

2 1 Introduction Object-oriented database design [2, 6, 24, 25, 39] brings together data modeling and behavior modeling. An object has a set of instance variables representing its structure and a set of methods representing its behavior. The only way to communicate with an object and manipulate its instance variables is to invoke a method on the object. This communication 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: Classication: Objects of the universe of discourse which share the same structure and behavior are classied into object classes. Encapsulation: There is a clear distinction between the specication of a method, which is visible, and its implementation, which is hidden. Specialization and inheritance: Object classes can be specialized into subclasses which inherit instance variables and methods from their superclasses. Overriding and dynamic binding: The same method may be implemented dierently with dierent object classes. When an object receives a message, a method to handle the message is searched for dynamically. The search starts at the object's class and continues up the class hierarchy until an appropriate method is found. Object-oriented designs oer several benets. It is claimed that object-oriented designs concentrate related behavior around objects, are easy to maintain and easy to extend [33]. Classication 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 [14] that pure objectoriented database models (e.g., [7, 8, 11, 27, 30]) lack a symmetric relationship construct as it is provided by the Entity-Relationship model [10]. If such a construct is missing, a relationship between two object classes Student and Course is either decomposed into two directed relationships \hasenrolled" and \isenrolledby", represented by instance variables of the object classes Student and Course, or it is represented by a third object class Enrollment with two instance variables \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 class representing a relationship. For these and other reasons, several authors (e.g., [12, 32, 36, 37]) have suggested to include the relationship construct as a modeling primitive into object-oriented (database) models. Their discussions, however, focus on data modeling and not on behavior modeling. As behavior modeling is concerned, similar problems exist [43]. The traditional objectoriented approach, which requires the receiver of a message to be a single object only, 2

3 has serious diculties in modeling multi-polymorphic behavior. Behavior which depends on the object classes of several objects is called multi-polymorphic. An example of multipolymorphic behavior is calculating the price of shipping some product p to some customer c, if this calculation depends on the class of product shipped, e.g., hardware or software, and on the class of customer the product is shipped to, e.g., domestic customer or foreign customer. 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. 1 A cooperation contract is established between several object classes. It denes how any tuple of instances of these object classes 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 object-oriented concepts, such as classication, encapsulation, inheritance, overriding, and dynamic binding. The paper is organized as follows: In Section 2, we describe a sample problem of behavior modeling and introduce the object classes of our sample database in the data model of the commercial object-oriented database management system GemStone 2 [7], which we will use as framework for our discussions. In Section 3, we use the sample problem to discuss benets and deciencies 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 shows, using GemStone as reference system, how cooperation contracts can be made available as modeling construct in existing object-oriented database management systems. Finally, Section 6 gives a summary and compares cooperation contracts with related work on collaborative behavior modeling. This paper revises and extends our paper presented at the 10th International Conference on the Entity-Relationship Approach [40], where we have introduced cooperation contracts in a straw-man data model as novice construct for behavior modeling and where we have presented a formal semantics of cooperative message passing by means of Evolving Algebras [18]. This paper follows the same line of thoughts as its predecessor, but instead of using a straw-man data model, we use the data model of GemStone [7], and instead of presenting a formal semantics, we present an implementation of cooperation contracts in GemStone. Further, we present an up-to-date comparison with related work. 1 The word \cooperation" is used with a dierent meaning in AI. There, \cooperative" refers to the feature that a system is willing to cooperate actively, whereas \cooperation contract" refers only to the feature that objects collaborate in giving passive responses. But to indicate the relationship to our previous work [40], we continue using the term \cooperation contract" for the concept to model collaborative behavior. 2 GemStone is a registered trademark of GemStone Systems, Inc. 3

4 2 A sample problem statement In this section, we give a sample problem statement of behavior modeling and introduce the object classes of our sample database in the data model of GemStone [7]. The problem statement will be our running example throughout most of the paper; we omit any details which do not contribute to the essential points of this paper. We use the data model of GemStone as framework for our discussions, but the presented ideas and concepts apply to object-oriented databases in general. 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 company's pricing policy, 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 dier 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 ATS (Austrian Shillings) per kilogram. 2. Hardware sales to European customers outside Austria are charged 300 ATS per kilogram. 3. Hardware sales to US-Customers are charged 700 ATS per kilogram. 4. Software sales to all foreign customers are charged a at rate of 150 ATS. 5. All other sales are subject to a shipping charge of 50 ATS. It is expected that the company will oer additional classes 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 intentionally have kept the example 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 cannot be stored as data values like, for example, the names of products. In the following, we introduce the object classes of our sample database in the data model of GemStone [7]. The programming and query language of the GemStone database management system is GemStone Smalltalk, a variant of the well-known programming language Smalltalk-80 3 [17]. 3 Smalltalk-80 is a registered trademark of ObjectShare, Inc. (formerly ParcPlace Systems, Inc.) 4

5 Product Hardware Software TrainingMaterial MaintenanceAgrmt Customer DomesticCustomer ForeignCustomer EuropeanCustomer USCustomer AsianCustomer subclassof subclassof (later extension) Figure 1: Class hierarchy of the sample database Example: The object classes of our sample database comprise a hierarchy of products, i.e., Product, Hardware, Software, TrainingMaterial, and a hierarchy of customers, i.e., Customer, DomesticCustomer, ForeignCustomer, EuropeanCustomer, and USCustomer (cf. Figure 1). Product and Customer are subclasses of the predened object class Object (this is not shown in Figure 1). Figure 2 shows the denition of object classes Product and Hardware in GemStone Smalltalk. Object class Product denes instance variables name and netprice constrained to instances of class String and Integer, respectively, and instance methods netprice:, netprice, name:, name, and salestax. Method name returns (^) the value of the instance variable name. Method name: has one argument astring of expected class String. Notice that the expected class (domain) of arguments cannot be expressed in the GemStone model. Object class Hardware, dened in Figure 2 as a subclass of Product, inherits all variables and methods of Product. It introduces a new instance variable weight of class Integer and reimplements method salestax. 3 Benets and deciencies 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 5

6 class name Product superclass Object instance variables name netprice instance methods name ^name constrained to String constrained to Integer netprice ^netprice salestax ^0 name: astring name := astring netprice: aninteger netprice := aninteger class name Hardware superclass Product instance variables weight instance methods salestax ^20 constrained to Integer Figure 2: Object classes Product and Hardware shipping charges is polymorphic on the class of product (Hardware, Software, TrainingMaterial) and on the class of customer (DomesticCustomer, EuropeanCustomer, USCustomer). Several solutions to handle such a multi-polymorphic behavior have been proposed in literature for analogous problems [34]. We demonstrate each solution by our example and analyze it according to the following criteria: symmetry, locality of related behavior, extensibility, and ease of maintenance. These criteria can be tested in our example, as follows: Symmetry: A solution is symmetric if it is not biased towards products or towards customers. It is asymmetric, otherwise. Locality of related behavior: A solution localizes related behavior if the information on calculating shipping charges is specied in a single place. The solution disperses related behavior, otherwise. Extensibility: A solution is easy to extend if new classes of products and new classes of customers can be included without the need of modifying existing classes and existing 6

7 method implementations. To evaluate this criterion, we will consider the eects of introducing a maintenance agreement as new class of product, MaintenanceAgrmt, and an Asian customer as new class of customer, AsianCustomer (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 shipping charge of 0 ATS applies to maintenance agreements. 2. A default shipping charge of 100 ATS applies to all foreign customers. 3. Maintenance agreements with foreign customers are charged 30 ATS A conventional solution A conventional solution for determining the price of shipping a given product to a given customer is to test for the class of product and for the class of customer and execute appropriate code to that case. The solution is typical for systems which are not objectoriented. 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 class PriceCalculator. It denes class method shippingcharge- For: aproduct and: acustomer. In a conventional programming language nested casestatements would be used to select the calculation appropriate for the given class of product and the given class of customer. As GemStone Smalltalk does not support case-statements, several nested if -statements are used instead (cf. Figure 3). Message ismemberof: aclass checks whether the receiver of the message is an instance of class aclass or not. 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 object class PriceCalculator, i.e., PriceCalculator shippingchargefor: p and: c. We evaluate the conventional solution: Symmetry: The conventional solution is symmetric. It is not biased towards products or towards customers. Locality of related behavior: The conventional solution localizes related behavior. The information on calculating shipping charges is specied in a single place, method shippingchargefor:and: of object class PriceCalculator. 4 This statement is needed to resolve the conict between the previous two ones. 7

8 class name PriceCalculator superclass Object class variables default constrained to Integer class methods shippingchargefor: aproduct and: acustomer (aproduct ismemberof: Hardware) iftrue: [ (acustomer ismemberof: DomesticCustomer) iftrue: [ ^(aproduct weight * 70) ]. (acustomer ismemberof: EuropeanCustomer) iftrue: [ ^(aproduct weight * 300) ]. (acustomer ismemberof: USCustomer) iftrue: [ ^(aproduct weight * 700) ]]. (aproduct ismemberof: Software) iftrue: [ (acustomer ismemberof: DomesticCustomer) iftrue: [ ^default ]. (acustomer ismemberof: EuropeanCustomer) iftrue: [ ^150 ]. (acustomer ismemberof: USCustomer) iftrue: [ ^150 ]]. (aproduct ismemberof: TrainingMaterial) iftrue: [ (acustomer ismemberof: DomesticCustomer) iftrue: [ ^default ]. (acustomer ismemberof: EuropeanCustomer) iftrue: [ ^default ]. (acustomer ismemberof: USCustomer) iftrue: [ ^default ]]. Figure 3: The conventional solution Extensibility: The solution is hard to extend. Introducing a new class of product, however, is much easier than introducing a new class of customer. To introduce a new class of product, MaintenanceAgrmt, one big nested if -statement has to be added. If a new class of customer, AsianCustomer, is added, the new class of customer must be considered in every outer if -statement of method shippingchargefor:and:. In both situations, existing code has to be modied and recompiled. 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 if -statements of a single outer if -statement (TrainingMaterial) must be considered. To modify the shipping charges for foreign customers, several inner if -statements (EuropeanCustomer, USCustomer, and AsianCustomer) in all outer if - 8

9 class name Hardware superclass Product instance variables weight constrained to Integer instance methods shippingchargefor: acustomer (acustomer ismemberof: DomesticCustomer) iftrue: [ ^(weight*70) ]. (acustomer ismemberof: EuropeanCustomer) iftrue: [ ^(weight*300) ]. (acustomer ismemberof: USCustomer) iftrue: [ ^(weight*700) ]. Figure 4: The simple object-oriented solution (selected part) statements must be considered. Both situations require a detailed analysis of existing code and modications in several places. The performance of the conventional solution could be improved to some extent by using iftrue:iffalse:-statements. The main problems, however, remain. 3.2 A 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 product p a message asking for the price of shipping it to customer c (or vice versa). The method to handle the message will be implemented dierently for every class of product. In a simple solution, such a method will test the class of customer and execute the appropriate code to that case. Example: The simple object-oriented solution is demonstrated in part in Figure 4. Method shippingchargefor: acustomer is dened at object class Product and reimplemented at object class Hardware. 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 product p, i.e., p shippingchargefor: c. We evaluate the simple object-oriented solution: Symmetry: The simple object-oriented solution is asymmetric. It is biased towards products. Alternatively, one could bias the solution towards 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 class hierarchy of products so that the appropriate code is local to each specic class of product. 9

10 However, the simple object-oriented solution is \distributed" compared to the conventional solution, but less distributed than the sophisticated solution (see below). Extensibility: The simple object-oriented solution can be hard to extend. Adding a new class of product, e.g., MaintenanceAgrmt, is easy. Method shippingchargefor: is reimplemented at object class MaintenanceAgrmt and no existing method needs to be modied. But, if a new class of customer, e.g., AsianCustomer, is introduced, every implementation of method shippingchargefor: must be modied accordingly. Additional if-statements checking on AsianCustomer must be introduced. 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. Method shippingchargefor: must be reimplemented at object class MaintenanceAgrmt taking several if -statements into account. But it is much harder to consider a new default shipping charge which applies to all foreign customers. Every implementation of method shippingchargefor: has to be modied. Furthermore, in each implementation several labels in the if -statements, referring to EuropeanCustomer, USCustomer, and AsianCustomer must be considered for possible modications. 3.3 A sophisticated object-oriented solution A sophisticated object-oriented solution eliminates the need for if-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 class of the sender [20]. Using this trick, for every leave node hxi in the class hierarchy of products a method hxishippingchargeof: aproduct is dened at object class Customer 5. The method is reimplemented at direct and indirect subclasses of Customer if needed. Example: Figure 5 demonstrates the approach. Object class Customer denes methods HWshippingChargeOf: ahardware, SWshippingChargeOf: asoftware, and TMshippingChargeOf: atrainingmaterial. Their implementations return the default shipping charge. Each of these methods is overridden at every subclass of Customer for which the shipping charge diers from the default shipping charge. 6 Like in the simple object-oriented solution, method shippingchargefor: acustomer is de- ned at object class Product and reimplemented at its subclasses. At a given subclass hxi of Product calculating shipping charges is delegated to customer c, by a message which encodes the class of product in the method selector. Example: Method shippingchargefor: acustomer is implemented at object class Hardware as ^(acustomer HWshippingChargeOf: self). 5 For simplicity, we assume that only leave nodes of the class hierarchy have direct instances. 6 Only some implementations of the method HWshippingChargeOf: make actually use of the argument p. To design for reusability, all other methods take a product p as argument, although it is not really needed to implement the current pricing policy. 10

11 class name Hardware superclass Product instance variables weight instance methods weight ^weight constrained to Integer shippingchargefor: acustomer ^(acustomer HWshippingChargeOf: self) class name Customer superclass Object instance variables name, address instance methods defaultshippingcharge ^50 constrained to String HWshippingChargeOf: ahardware ^(self defaultshippingcharge) SWshippingChargeOf: asoftware ^(self defaultshippingcharge) TMshippingChargeOf: atrainingmaterial ^(self defaultshippingcharge) class name DomesticCustomer superclass Customer instance methods HWshippingChargeOf: ahardware ^(ahardware weight * 70) class name ForeignCustomer superclass Customer instance methods SWshippingChargeOf: asoftware ^150 class name EuropeanCustomer superclass ForeignCustomer instance methods HWshippingChargeOf: ahardware ^(ahardware weight * 300) class name USCustomer superclass ForeignCustomer instance methods HWshippingChargeOf: ahardware ^(ahardware weight * 700) Figure 5: The sophisticated object-oriented solution 11

12 We evaluate the sophisticated object-oriented solution: Symmetry: Like the simple object-oriented solution, the sophisticated object-oriented solution is asymmetric. It is biased towards products with respect to the external interface, and it is biased towards 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 classes of two class hierarchies. Extensibility: The sophisticated object-oriented solution is relatively easy to extend. If a new class of product or a new class of customer is introduced, no existing implementations of methods need to be changed. Inherited methods need to be reimplemented at subclasses, and sometimes, new methods need to be introduced. If a new class of product, e.g., MaintenanceAgrmt (MA), is added, method MAshippingChargeOf: amaintenanceagrmt has to be introduced at object class Customer, and method shippingchargefor: of object class MaintenanceAgrmt is reimplemented such that it invokes method MAshippingChargeOf:. If a new class of customer, e.g., AsianCustomer, is introduced the methods hxishippingchargeof: (where hxi is a leave node in the class hierarchy of products) must be reimplemented for the case that a dierent shipping charge applies to Asian customers than to foreign customers in general. 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 MAshippingChargeOf: of object class Customer has to be modied. But it is more dicult to take a new default shipping charge for foreign customers into account. Several methods of ForeignCustomer (the methods SWshippingChargeOf:, HWshippingChargeOf:, and TMshippingChargeOf:) need to be reimplemented. 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: symmetry, 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 classes, are easy to extend and easy to maintain [33]. This is true, if the behavior to be modeled depends on only one class of object. We have seen that this is false in our example, in which the calculation of shipping charges depends on the class of product shipped and on the class 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 12

13 is a message which is sent jointly to several objects. Notice that 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. Cooperative messages are dened with cooperation contracts which are established between several object classes. A cooperation contract fullls 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 objectoriented data models require [7, 8, 11, 27, 30]. Similarly, cooperation contracts make a behavioral interaction between instances of several object classes explicit. They avoid that one of several objects has to be singled out arbitrarily as receiver of a message whose answer depends on an interaction of several objects. Notice that the receivers of a cooperative message are associated only during method execution, which is dierent to binary, undirected relationships in data modeling, which \associate" objects persistently. In the remainder of this section, we introduce the concept of cooperation contracts and discuss how cooperation contracts obey key object-oriented concepts such as classication, encapsulation, inheritance, overriding, and dynamic binding. A cooperation contract is established between several object classes, which are referred to as partner classes of the cooperation contract. For sake of simplicity, we will consider only binary cooperation contracts in the following. This helps us concentrate on essential points and simplies our discussions. A binary cooperation contract is established between two partner classes and denes a set of cooperative methods. Extending our previous work [40], several cooperation contracts with dierent names may be dened between the same classes. The interface of a cooperative method is dened the same way as it is for a method of an object class. The implementation of a cooperative method is described below. Example: Cooperation contract Pricing is dened between partner classes Product and Customer in Figure 6. It denes the cooperative methods shippingcharge and totalprice. A cooperative method is invoked by a cooperative message addressed to one instance of each object class in a cooperation contract. As several cooperation contracts may exist between two object classes, the cooperation contract to be used in handling a cooperative message must be specied in the message. A cooperative message mone:mtwo: addressed to two objects v1 and v2, with arguments w1 and w2, using a cooperation contract named X is conceptually represented as (v1,v2) X mone: w1 mtwo: w2. In our extension of GemStone Smalltalk, a cooperative message (v1,v2) X m: w is written as (CoopMsg on: v1 and: v2 using: 'X') m: w (cf. Figure 6). Example: If p denotes a product and c denotes a customer, cooperative message (p,c) Pricing shippingcharge is handled by cooperative method shippingcharge of cooperation contract Pricing and returns the price of shipping product p to customer c. 13

14 The implementation of a cooperative method is dened the same way as it is for a method of an object class, except that several receivers have to be distinguished. To denote a particular receiver, we use the variables self1 and self2, where self1 depicts an instance of the rst partner class and self2 depicts an instance of the second partner class of the cooperation contract at which the cooperative method is dened. Example: The message self1 netprice is used in the implementation of the method totalprice of cooperation contract Pricing to retrieve the net price of that product being the rst receiver 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 denition of classication. The traditional denition requires that every object is direct instance of exactly one object class. Furthermore, every message understood by an object o is dened at an object class O of which o is a direct or indirect instance. We extend this denition as follows for cooperative messages: Any cooperative message understood by a pair of objects o1 and o2 must be dened at a cooperation contract that is established between two object classes 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 if and only if o1 and o2 are direct or indirect instances of the partner classes 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 classes O1 and O2 denes not only the cooperative behavior of pairs of direct instances of O1 and O2 but also the cooperative behavior of pairs of indirect instances of O1 and O2. Example: If p denotes an instance of Software and c denotes an instance of DomesticCustomer, cooperative message (p,c) Pricing shippingcharge is dened for p and c. The message is understood by p and c, because cooperative method shippingcharge is de- ned at cooperation contract Pricing, whose partner classes Product and Customer are superclasses of Software and DomesticCustomer, respectively. Cooperation contracts support specialization, overriding, and dynamic binding. Cooperation contracts with the same name may be dened between dierent classes. Names of cooperation contracts specied in a cooperative message are bound dynamically to a specic cooperation contract similarly as method names of messages are bound dynamically to a specic method implementation. To refer to a specic contract, we add the names of the partner classes as subscripts to the contract name. Example: Cooperation contract Pricing Product,Customer identies the cooperation contract named Pricing between partner classes Product and Customer. We say a cooperation contract C' between two partner classes O1' and O2' specializes a cooperation contract C between two partner classes O1 and O2 if and only if 14

15 contract name Pricing partner classes Product, Customer methods shippingcharge ^50 totalprice ^(self1 netprice + self1 salestax + (CoopMsg on: self1 and: self2 using: 'Pricing') shippingcharge) contract name Pricing partner classes Product, ForeignCustomer methods totalprice ^(self1 netprice + (CoopMsg on: self1 and: self2 using: 'Pricing') shippingcharge) contract name Pricing partner classes Software, ForeignCustomer methods shippingcharge ^150 contract name Pricing partner classes Hardware, DomesticCustomer methods shippingcharge ^(self1 weight * 70) contract name Pricing partner classes Hardware, EuropeanCustomer methods shippingcharge ^(self1 weight * 300) contract name Pricing partner classes Hardware, USCustomer methods shippingcharge ^(self1 weight * 700) Figure 6: Cooperation contracts 15

16 i. C and C' have the same name, and ii. O1' is identical to O1, or O1' is a direct or indirect subclass of O1, and iii. O2' is identical to O2, or O2' is a direct or indirect subclass of O2, and iv. O1' is dierent from O1, or O2' is dierent from O2. Example: Cooperation contract Pricing Product,ForeignCustomer specializes cooperation contract Pricing Product,Customer, as ForeignCustomer is a subclass of Customer (see Figure 6 and 7). A cooperation contract C' which specializes a cooperation contract C may dene new cooperative methods and may reimplement any cooperative method of C. Example: Cooperation contract Pricing Product,ForeignCustomer reimplements the cooperative method totalprice of cooperation contract Pricing Product,Customer. The new implementation takes into account that foreign customers are exempted from paying a sales tax (see Figure 6). Now, we informally describe how cooperative messages are handled. A formal denition is given in [40]. An implementation based on this formal denition is presented in Section 5. A cooperative message m addressed to two objects o1 and o2 is handled as follows: 1. A most specic cooperation contract C to which o1 and o2 are subject and which implements m is determined. There may be several. How such a situation is handled, will be discussed later. A cooperation contract C is a most specic 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' specializing C with this property. 2. The implementation of the method m given at C is selected and executed. Example: Consider cooperative messages (p,c) Pricing shippingcharge and (p,c) Pricing total- Price in which p denotes a direct instance of TrainingMaterial and c a direct instance of EuropeanCustomer. Further, assume that the cooperation contracts shown in Figure 6 are currently dened. The pair of objects p and c are subject to cooperation contract Pricing Product,ForeignCustomer and to cooperation contract Pricing Product,Customer. As the rst cooperative message is concerned, only cooperation contract Pricing Product, Customer implements method shippingcharge. Therefore the implementation of method shippingcharge given at this cooperation contract is executed and will return the default shipping charge of 50 ATS. As the second cooperative message is concerned, both cooperation contracts implement method totalprice. Cooperation contract Pricing Product,ForeignCustomer specializes cooperation contract Pricing Product,Customer. Therefore the implementation of method totalprice given at cooperation contract Pricing Product, is selected and executed. ForeignCustomer 16

17 Pricing Product,Customer Pricing Hardware,DomesticCustomer Pricing MaintenanceAgrmt,Customer Pricing Product,ForeignCustomer Pricing MaintenanceAgrmt,ForeignCustomer Pricing Hardware,USCustomer Pricing Software,ForeignCustomer Pricing Hardware,EuropeanCustomer has-most-specific-supercontract has-most-specific-supercontract (later extension) Figure 7: Specialization hierarchy of cooperation contracts 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 reected by exactly one method implementation. The method is implemented at that cooperation contract whose partner classes are identied in the statement. Example: The statement \Software sales to all foreign customers are charged a at rate of 150 ATS" is reected by the implementation of the method shippingcharge of cooperation contract Pricing Software,ForeignCustomer established between partner classes Software and ForeignCustomer. We evaluate the solution using cooperation contract: Symmetry: The solution using cooperation contract is symmetric. It is not biased towards either products or customers. Locality of related behavior: The cooperation contract solution localizes related behavior. Behavior which depends on several object classes, such as the pricing policy, is not dispersed but dened in a single place, the specialization hierarchy of cooperation contract Pricing. Extensibility: The cooperation contract solution is easy to extend. If a new class of product, e.g., MaintenanceAgrmt, or a new class of customer, e.g., AsianCustomer, is added, no existing implementations of methods need to be modied and no additional classes of methods need to be introduced (such as hclassofproductishippingcharge in the sophisticated object-oriented solution). Default shipping charges apply to the new product and the new class of customer immediately. Because of inheritance, direct instances of MaintenanceAgrmt are subject to all cooperation contracts in which the superclass 17

18 of MaintenanceAgrmt, object class Product, is a partner class. These are the cooperation contracts Pricing Product,Customer and Pricing Product,ForeignCustomer in Figure 6. Similarly, direct instances of AsianCustomer are subject to all cooperation contracts in which a direct or indirect superclass of AsianCustomer is partner class. These are the cooperation contracts Pricing Product,Customer, Pricing Product,ForeignCustomer, and Pricing Software,ForeignCustomer in Figure 6. If for a new class of product or a new class of customer special shipping charges apply, new cooperation contracts reimplementing the cooperative method shippingcharge are dened. 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 MaintenanceAgrmt,Customer between object classes MaintenanceAgrmt and Customer (cf. Figure 8) is dened. To consider the default shipping charge of 100 ATS for all products and foreign customers the method shippingcharge is reimplemented at cooperation contract Pricing Product,ForeignCustomer. To model the calculation of shipping charges for maintenance agreements and foreign customers, a new cooperation contract Pricing MaintenanceAgrmt, ForeignCustomer is introduced (cf. Figure 8). It has been mentioned above that handling a cooperative message (o1,o2) X m can be ambiguous, if more than one most specic cooperation contract named X to which o1 and o2 are subject and which implements m exists. Example: Consider cooperative message (p,c) Pricing shippingcharge in which p denotes a direct instance of MaintenanceAgrmt and in which c denotes a direct instance of ForeignCustomer. Assume that method shippingcharge has not been implemented at cooperation contract Pricing MaintenanceAgrmt,ForeignCustomer or that cooperation contract Pricing MaintenanceAgrmt,ForeignCustomer has not been dened at all. Then, two most specic cooperation contracts to which p and c are subject and which implement method shippingcharge exist, Pricing MaintenanceAgrmt,Customer and Pricing Product, ForeignCustomer (cf. Figures 6, 7, and 8). There are two possible solutions to the problem. The rst one is to forbid such a situation at all. The second one is to dene a conict resolution scheme similar to resolving ambiguities due to multiple inheritance [38, 42]. 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 conict can be resolved by adding a statement concerning this situation. This has been done in the revision of the pricing policy. 18

19 contract name partner classes methods shippingcharge ^0 Pricing MaintenanceAgrmt, Customer contract name Pricing partner classes Product, ForeignCustomer methods totalprice ^(self1 netprice + (CoopMsg on: self1 and: self2 using: 'Pricing') shippingcharge) shippingcharge ^100 contract name partner classes methods shippingcharge ^30 Pricing MaintenanceAgrmt, ForeignCustomer Figure 8: Cooperation contracts (extension and revision) As the second solution is concerned, we need to dene a conict resolution scheme. A possible conict resolution is to give the rst receiver priority over the second receiver. This means 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 conict resolution scheme in our extension of GemStone which describes the implementation of cooperative message handling, presented in Section 5.2. Nevertheless, we believe that ambiguities should be avoided in general. Then, the conict resolution scheme is not needed. 5 Extending object-oriented systems with cooperation contracts In this section, we describe how object-oriented systems can be extended with cooperation contracts. In particular, we show how cooperation contracts can be made available as benecial modeling construct in GemStone. In the rst subsection, we show how to dene and how to use cooperation contracts and cooperative methods in our extension of GemStone. In the second subsection, we present the general idea of the implementation. The entire code is given in the Appendix. 19

20 class methods of ObjectWithContracts subclass: astring instvarnames: anarrayofstrings classvars: anarrayofclassvars classinstvars: anarrayofclassinstvars pooldictionaries: anarrayofpooldicts indictionary: adictionary constraints: aconstraint instancesinvariant: invarboolean ismodiable: modifyboolean purpose Create new subclass with contracts Figure 9: Method for creating a new class with cooperation contracts ObjectWithContracts subclass: 'Product' instvarnames: #( 'name' 'netprice' ) classvars: #() classinstvars: #() pooldictionaries: #[] indictionary: CooperationContract constraints: #[ #[#name, String], #[#netprice, Integer] ] instancesinvariant: false ismodiable: false. Figure 10: Creation of a possible partner class of a cooperation contract 5.1 Dening and using cooperation contracts Cooperation contracts can be provided in GemStone, i.e., in its denition and manipulation language GemStone Smalltalk, by adding three classes: ObjectWithContracts, CoopContract, and CoopMsg. The partner classes of a cooperation contract must be dened as direct or indirect subclasses of class ObjectWithContracts (see Figure 9). Creating a new class with contracts: Sending message subclass:instvarnames:classvars:- classinstvars:pooldictionaries:indictionary:constraints:instancesinvariant:ismodiable: to class ObjectWithContracts or to some subclass of it creates a new subclass which may serve as partner class in a cooperation contract. Figure 10 gives an example. The various arguments of this message are the usual arguments for dening a subclass in Gem- Stone Smalltalk. It is not essential to know their meaning in order to understand the remainder of this paper. The class behavior of CoopContract, which is summarized in Figure 11, provides messages for dening, retrieving, and deleting contracts, as well as for adding and removing cooperative methods. 20

21 class methods of CoopContract denecontract: acontractname between: aclass1 and: aclass2 getcontract: acontractname between: aclass1 and: aclass2 deletecontract addmethod: asourcestring purpose Dene new contract Retrieve existing contract Delete existing contract Add cooperative method Figure 11: Methods for dening, retrieving, and deleting cooperation contracts and adding cooperative methods Dening new cooperation contracts: A cooperation contract can be dened by sending message denecontract:between:and: to class CoopContract with the name of the cooperation contract and the partner classes as arguments. Figure 12 shows the denition of contract Pricing with partner classes Product and Customer. Retrieving contracts: Sending message getcontract:between:and: to class CoopContract with the name of the cooperation contract and the partner classes as arguments returns the identied cooperation contract. Figure 12 shows the retrieval of contract named Pricing between partner classes Product and Customer. Deleting contracts: A cooperation contract can be deleted by sending message deletecontract to a contract class. Figure 12 shows the deletion of the previously dened cooperation contract Pricing with partner classes Product and Customer. Adding cooperative methods: A cooperative method can be added by sending message addmethod: with the source string as argument to a contract class. Figure 12 shows examples of adding cooperative methods to a contract. Removing cooperative methods: A previously dened method can be removed by sending the GemStone Smalltalk message removeselector: to the contract class with the selector as argument. All methods of a contract class can be removed by sending removeallmethods to the contract class. As cooperative messages are not supported as such in GemStone Smalltalk, they are mimicked by a message to a substitute object, which is able to execute a cooperative method on behalf of two objects. The class behavior of CoopMsg provides a message to select that substitute object for two objects addressed by a cooperative message (see Figure 13). As the code should be re-entrant, a dierent substitute object is provided for each method execution. Select an object to take care of a cooperative message: Sending message on:and:using: to class CoopMsg with the two addressees of a cooperative message and the name of 21

22 " Dene cooperation contract and its methods " (CoopContract denecontract: 'Pricing' between: Product and: Customer) addmethod: 'shippingcharge ^50'; addmethod: 'totalprice ^(self1 netprice + self1 salestax + (CoopMsg on: self1 and: self2 using: "Pricing") shippingcharge)'. " Get and delete contract " (CoopContract getcontract: 'Pricing' between: Product and: Customer) deletecontract. Figure 12: Denition and deletion of cooperation contracts in extended GemStone Smalltalk class methods of CoopMsg on: anobject1 and: anobject2 using: acontractname purpose Returns an object which is able to execute a cooperative method on behalf of anobject1 and anobject2 using cooperation contract acontractname Figure 13: Method for writing cooperative messages the cooperation contract as arguments returns an object that is able to execute a cooperative method on behalf of the two addressees. A cooperative message with selector totalprice addressed to an instance p of Hardware and to an instance c of USCustomer under contract named Pricing is written in our extension of GemStone Smalltalk as (CoopMsg on: p and: c using: 'Pricing') totalprice (cf. Figure 14 for an example). 5.2 Implementation In this section, we rst present the overall approach of extending GemStone Smalltalk with cooperation contracts. Then, we describe the individual classes added to GemStone Smalltalk. 22

23 " Dene receivers " p := Hardware new. p name: 'Workstation'. p netprice: p weight: 15. c := USCustomer new. c name: 'Smith'. c address: 'California'. " Cooperative message " (CoopMsg on: p and: c using: 'Pricing') totalprice. Figure 14: Cooperative message in extended GemStone Smalltalk Each cooperation contract is mapped to a class, which we will refer to as contract class. The partner classes of the cooperation contract are represented as values of two class instance variables and the cooperative methods of the cooperation contract are represented by instance methods. A cooperative message to two receiver objects is realized by creating a temporary instance of the contract class which represents the most specic cooperation contract to which the two receiver objects are subject and by delegating the message to that instance. The two receiver objects are remembered by two instance variables of the temporary instance and, thus, can be accessed as self1 and self2 in the implementation of a cooperative method. If the contract class of the temporary instance does not implement a method for the selector of the cooperative message, GemStone Smalltalk raises an exception by sending predened message doesnotunderstand: to that instance. This message is trapped by overriding it for contract classes as follows: First, the contract class that represents the most specic cooperation contract to which the two receivers are subject and which implements a method for the given selector is determined. If there are several most specic cooperation contracts, the cooperation contract with the most specic rst partner class is given priority. Second, a new temporary instance of this contract class is created and a message composed of the selector and the arguments of the cooperative method is sent to this instance. The temporary instance will no longer be referenced after the method is executed and, thus, will be garbage collected. The implementation's performance is discussed in Section 6.1. The behavior described above is provided by three classes, ObjectWithContracts, CoopMsg, and CoopContract (cf. Appendix). Class ObjectWithContracts is an auxiliary class and a (direct or indirect) superclass of all classes which may be partner classes in cooperation contracts. (Actually, only the rst 23