Modeling Cooperative Behavior Using Cooperation Contracts. Peter Lang. Abstract

Size: px
Start display at page:

Download "Modeling Cooperative Behavior Using Cooperation Contracts. Peter Lang. Abstract"

Transcription

1 Modeling Cooperative Behavior Using Cooperation Contracts Michael Schre Department of Data & Knowledge Engineering University of Linz Altenbergerstr. 69, A-4040 Linz, Austria Gerti Kappel Department of Information Systems University of Linz Altenbergerstr. 69, A-4040 Linz, Austria Peter Lang Department of Data & Knowledge Engineering University of Linz Altenbergerstr. 69, A-4040 Linz, Austria Abstract Several objects exhibit cooperative behavior if they act together in answering a message they have received jointly. Cooperative 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 object-oriented 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, cooperative behavior modeling, cooperation contracts, object-oriented database design 1 Introduction Object-oriented database design [2, 6, 24, 26, 41] 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, 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: 1

2 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 [35]. 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, 29, 32]) 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, 34, 38, 39]) 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 [44]. 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 classes 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 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. 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. Further, cooperation contracts are a useful aid to make communication structures between objects explicit. In object-oriented systems, any object can possibly communicate with any 2

3 other object by sending a message to it. Unconstrained communication between objects may lead to code which is hard to analyze, to extend and to debug. Therefore, design rules such as the law of Demeter [33] propose to restrict the set of possible receivers of messages in order to increase coupling and cohesion properties of object-oriented software [15]. Cooperation contracts and semantic relationships between object classes, such as component relationships, can be used to model allowed communication patterns among objects and, thus, to make them explicit. Similar as communication in large organizations usually follows only predened paths communication paths among objects may be restricted to be only along specic semantic relationships or via explicitly declared cooperation contracts. The paper is organized as follows: In section 2, we describe a sample problem of behavior modeling and introduce the basic concepts of the data model of the commercial objectoriented database management system GemStone [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 compares cooperation contracts with related work on cooperative behavior modeling and discusses future research topics. This paper revises and extends our paper presented at the 10-th International Conference on Entity-Relationship Approach [42], 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 [19]. This paper follows the same line of thoughts as its predecessor, but instead of using a strawman data model, we use the data model of the commercial object-oriented database management system GemStone [7], and instead of presenting a formal semantics, we present an implementation of cooperation contracts in GemStone. Further, we discuss the potential use of cooperation contracts in modeling communication patterns and we present an up-to-date comparison with related work. 2 A sample problem statement and the GemStone data model In this section, we give a sample problem statement of behavior modeling and introduce 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. 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 3

4 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 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 kilo. 2. Hardware sales to European customers outside Austria are charged 300 ATS per kilo. 3. Hardware sales to US-Customers are charged 700 ATS per kilo. 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 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 The GemStone data model We introduce the data model of the commercial object-oriented database management system GemStone [7] only as far as needed to present our ideas. The GemStone database schema consists of a set of object classes organized in a class hierarchy, whose root is the predened class Object. GemStone provides many predened classes, among them object classes Integer, String and Boolean. The programming and query language of the GemStone database is called Smalltalk DB, a variant of the well-known programming language Smalltalk-80 [18]. Example: The object-oriented database schema of our sample database consists of 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 prede- ned object class Object (this is not shown in Figure 1). Every object class denes a set of instance variables and a set of instance methods. Gem- Stone supports class variables and class methods, too. But they are not relevant to our sample database and therefore we use \method" and \variable" as synonyms for \instance method" and \instance variable". Instance variables are dened by giving their names, and furthermore, they can be constrained to a specic class of objects. The denition of a method consists of a public interface and a private implementation. The interface of a method (selector) consists of a name for the method selector including the names of arguments. The implementation of a method is described below. 4

5 PRODUCT HARDWARE SOFTWARE TRAINING-MATERIAL MAINTENANCE-AGRMT CUSTOMER DOMESTIC-CUSTOMER FOREIGN-CUSTOMER EUROPEAN-CUSTOMER US-CUSTOMER ASIAN-CUSTOMER subclassof subclassof (later extension) Figure 1: Object class hierarchy of sample database Example: Figure 2 shows the denition of object class Product. Object class Product denes the instance variables name and netprice constrained to instances of class String and Integer, respectively, and the instance methods netprice:, netprice, name:, name, and salestax. The method name returns (^) the value of the instance variable name. The method name: has one argument astring of expected class String. Note that the expected class (domain) of arguments cannot be expressed in the GemStone model. Denitions of variables and methods are inherited from superclasses to subclasses. A subclass may constrain an inherited variable to a subclass of the inherited constraint and may reimplement (override) an inherited method. Example: Object class Hardware, dened in Figure 2 as a subclass of Product, inherits variables and methods of Product. It introduces a new variable weight of class Integer and reimplements the method salestax. The extension of a GemStone database schema consists of a set of objects, of which each one is direct instance of exactly one object class. Every object is also an indirect instance of every superclass of its object class. We say an object o is instance of an object class O, if o is direct or indirect instance of O. In Smalltalk DB classes do not manage their extension and therefore do not know their instances. Since extension management is not essential to the contents of the paper it will not be treated further. Every object is described by a value for each variable dened at or inherited to its object class. The value must be a (direct or indirect) instance of the constraint class of the variable. Example: An instance i of object class Hardware is described by three values, one for its name, one for its netprice, and one for its weight. 5

6 class name Product superclass Object instance variables name constrained to String netprice constrained to Integer instance methods name ^name netprice ^netprice salestax ^0 name: astring name := astring netprice: aninteger netprice := aninteger class name Hardware superclass Product instance variables weight constrained to Integer instance methods salestax ^20 Figure 2: Object classes Product and Hardware The implementation of a method m consists of read and write accesses to instance variables of the object self (i.e., the object on which the method m is executed), messages, control ow statements (e.g., iftrue:iffalse:), operators of predened object classes (e.g., + or * for Integer), assignment statements of the form variable := : : :, and a return-statement with a single argument denoted by ^. Variables in some method implementation are arguments, instance variables of the object self, the pseudovariable self denoting the object on which the method is executed, and local (temporary) variables declared as such within the method implementation. An instance variable p of the object self may be read and updated using p as a variable that is read and updated by an assignment statement. Example: The assignment statement netprice := aninteger in the implementation of the method netprice: of object class Product updates the value of the instance variable netprice of the object self. The return statement ^netprice in the implementation of the method netprice of object class Product reads and returns the value of the instance variable netprice of the object self. Smalltalk DB distinguishes between several types of messages. Keyword messages are the most common one and therefore relevant to us. A keyword message consists of a receiver and 6

7 up to 15 keyword-argument pairs. Each keyword is a simple identier ending in a colon. For example, sending a keyword message with two arguments mone:mtwo: to an object i, denoted by the temporary variable v, with actual arguments j1 and j2, denoted by the temporary variables w1 and w2, is written as v mone: w1 mtwo: w2. Example: Assume the temporary variable p holds an instance of object class Hardware. Then the message p netprice: 100 updates the net price of that instance. The semantics of handling a message m sent to an object i is as follows: If the object class of which i is direct instance implements the method m this implementation gets executed. Otherwise the method is searched for recursively up the class hierarchy. Example: In the previous example, the method netprice: is searched for at object class Hardware. No implementation is found. The search is continued at the superclass of Hardware, object class Product, where an implementation is found and executed. 3 Benets and deciences 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 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 [36]. 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 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 method implementations. To evaluate this criterion, we will consider the eects of introducing a new class of product, MaintenanceAgrmt, and a 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. 1 1 This statement is needed to resolve the conict between the previous two ones. 7

8 class name PriceCalculation superclass Object instance variables default constrained to Integer instance 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 ]]. 3.1 The conventional solution Figure 3: The conventional solution The 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 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 class PriceCalculation dening the method shippingchargefor: aproduct and: acustomer. In a conventional programming language nested case-statements would be used to select the calculation appropriate for the given class of product and the given class of customer. As Smalltalk DB does not support case-statements, several nested ifstatements are used instead (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 shippingchargefor: p and: c. We evaluate the conventional solution: 8

9 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 specied in a single place, the method shippingchargefor:and: of object class PriceCalculation. 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 the 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-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 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 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. The 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 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 class hierarchy of products so that the appropriate code is local to each specic class of product. 9

10 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) Extensibility: The simple object-oriented solution can be hard to extend. Adding a new class of product, e.g., MaintenanceAgrmt, is easy. The 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 the 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. The 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 the 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 The sophisticated object-oriented solution The sophisticated object-oriented solution eliminates the need of 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 [21]. Using this trick, for every leave node <X> in the class hierarchy of products a method <X>shippingChargeOf: aproduct is dened at object class Customer 2. The method is reimplemented at direct and indirect subclasses of Customer if needed. Example: Figure 5 demonstrates the approach. Object class Customer denes the 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. 3 2 For simplicity, we assume that only leave nodes of the class hierarchy have direct instances. 3 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 constrained to Integer instance methods weight ^weight shippingchargefor: acustomer ^(acustomer HWshippingChargeOf: self) class name Customer superclass Object instance variables name constrained to String address constrained to String instance methods defaultshippingcharge ^50 HWshippingChargeOf: ahardware ^(self defaultshippingcharge) SWshippingChargeOf: asoftware ^(self defaultshippingcharge) TMshippingChargeOf: atrainingmaterial ^(self defaultshippingcharge) class name superclass instance methods DomesticCustomer Customer HWshippingChargeOf: ahardware ^(ahardware weight * 70) class name superclass instance methods ForeignCustomer Customer SWshippingChargeOf: asoftware ^150 class name superclass instance methods EuropeanCustomer ForeignCustomer HWshippingChargeOf: ahardware ^(ahardware weight * 300) class name superclass instance methods USCustomer ForeignCustomer 11 HWshippingChargeOf: ahardware ^(ahardware weight * 700)

12 Like in the simple object-oriented solution, the method shippingchargefor: acustomer is dened at object class Product and reimplemented at its subclasses. At a given subclass <X> of Product calculating shipping charges is delegated to the customer c, by a message which encodes the class of product in the method selector. Example: The method shippingchargefor: acustomer is implemented at the object class Hardware as ^(acustomer HWshippingChargeOf: self). 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 objectoriented 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, a method MAshippingChargeOf: amaintenance- Agrmt has to be introduced at object class Customer, and the method shippingcharge- For: of object class MaintenanceAgrmt is reimplemented such that it invokes the method MAshippingChargeOf:. If a new class of customer, e.g., AsianCustomer, is introduced the methods <X>shippingChargeOf: (where <X> 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: 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 classes, are easy to extend and easy to maintain [35]. 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 12

13 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 is a message which is sent jointly to several objects. Note 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. We will conceptually denote such a message by (p,c) shippingcharge. 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 object-oriented data models require [7, 8, 11, 29, 32]). 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 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. The remainder of this section is organized as follows. We introduce the concept of cooperation contracts in the rst subsection, where we also discuss how cooperation contracts obey key object-oriented concepts such as classication, encapsulation, inheritance, overriding and dynamic binding. In the second subsection, we show how cooperation contracts can be employed as benecial aid to make communication structures between objects explicit. 4.1 The concept 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 and require that at most one cooperation contract exists between any two object classes. Furthermore, we will not consider cooperation contracts in which the same object class occurs twice as partner class. 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. Cooperation contracts are given a unique name, although this name is redundant if at most one cooperation contract exists between the same object classes. In this case the partner classes already identify the cooperation contract. 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: The cooperation contract Pricing is dened between partner classes Product and Customer in Figure 6. It denes the cooperative methods shippingcharge and totalprice. 13

14 A cooperative method is invoked by a cooperative message addressed to one instance of each object class in the cooperation contract. A cooperative message mone:mtwo: addressed to two objects i1 and i2, denoted by variables v1 and v2, with arguments j1 and j2, denoted by variables w1 and w2, is conceptually represented as (v1,v2) mone: w1 mtwo: w2. In our extension of Smalltalk DB, a cooperative message (v1,v2) m: w is written as (CoopMsg on: v1 and: v2) m: w (cf. Figure 6). Example: If p denotes a product and c a customer, the cooperative message (p,c) 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 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 is the rst and self2 is 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 total- Price 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 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, i 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, the cooperative message (p,c) shippingcharge is dened for p and c. The message is understood by p and c, because the cooperative method shippingcharge is dened 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. 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, i i. O1' is identical to O1, or O1' is a direct or indirect subclass of O1, and 14

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

16 ii. O2' is identical to O2, or O2' is a direct or indirect subclass of O2, and iii. O1' is dierent from O1, or O2' is dierent from O2. Example: Cooperation contract PricingForeign between partner classes Product and ForeignCustomer specializes cooperation contract Pricing between partner classes Product and 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 PricingForeign 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 denition is given in [42]. 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 the cooperative messages (p,c) shippingcharge and (p,c) total- Price in which p denotes a direct instance of TrainingMaterial and c a direct instance of EuropeanCustomer. Assume the cooperation contracts shown in Figure 6 have been dened. The pair of objects p and c are subject to the cooperation contract PricingForeign, established between partner classes Product and ForeignCustomer, and to the cooperation contract Pricing, established between partner classes 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 ATS. As the second cooperative message is concerned, both cooperation contracts implement the method totalprice. Cooperation contract PricingForeign specializes cooperation contract Pricing. Therefore the implementation of the method totalprice given at cooperation contract PricingForeign 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 reected by exactly one method implementation. The method is implemented at that cooperation contract whose partner classes are identied in the statement. 16

17 PRICING PRICING-HW-DOMESTIC PRICING-MA PRICING-FOREIGN 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 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 PricingSWForeign established between partner classes Software and ForeignCustomer. We evaluate the cooperation contract solution: Symmetricity: The cooperation contract solution is symmetric. products or customers. It is not biased on either Locality of related behavior: The cooperation contract solution localizes related behavior. Behavior which is contributed to 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 <classofproduct>shippingcharge 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 of MaintenanceAgrmt, object class Product, is a partner class. These are the cooperation contracts Pricing and PricingForeign 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, PricingForeign, and PricingSWForeign 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. 17

18 contract name partner classes methods PricingMA MaintenanceAgrmt, Customer shippingcharge ^0 contract name partner classes methods PricingForeign Product, ForeignCustomer totalprice ^(self1 netprice + (CoopMsg on: self1 and: self2) shippingcharge) shippingcharge ^100 contract name partner classes methods PricingMAForeign MaintenanceAgrmt, ForeignCustomer shippingcharge ^30 Figure 8: Cooperation contracts (extension and revision) 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 PricingMA between object classes MaintenanceAgrmt and Customer (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 PricingForeign, which has already been established between object classes Product and ForeignCustomer. To model the calculation of shipping charges for maintenance agreements and foreign customers, a new cooperation contract PricingMAForeign is introduced (Figure 8). It has been mentioned above that handling a cooperative message (o1,o2) m can be ambiguous, if more than one most specic cooperation contract C to which o1 and o2 are subject and which implements m exists. Example: Consider the cooperative message (p,c) shippingcharge in which p denotes a direct instance of MaintenanceAgrmt and in which c denotes a direct instance of ForeignCustomer. Assume that the method shippingcharge has not been implemented at cooperation contract PricingMAForeign or cooperation contract PricingMA- Foreign has not been dened at all. Then, two most specic cooperation contracts to 18

19 which p and c are subject and which implement the method shippingcharge exist, PricingMA and PricingForeign (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 [40, 43]. 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. 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. 4.2 Cooperation contracts as design aid In object-oriented systems, any object can possibly communicate with any other object by sending a message to it. But unconstrained communication between objects may lead to code which is hard to analyze, cumbersome to extend and dicult to debug. Therefore, design rules such as the law of Demeter [33] propose to restrict the set of possible receivers of messages in order to increase coupling and cohesion properties of object-oriented software [15]. The law of Demeter forbids to send, within a method implementation, messages to objects retrieved by another message. Messages may only be sent to (1) the object on which a method is executed, (2) objects provided as input parameter to the method, (3) objects referenced by instance variables of the object on which the method is executed, and (4) objects created by the method. If the law of Demeter is obeyed in a typed language, the communication structure between instances of a set of object classes can be determined a posteriori by analyzing domains of method parameters and domains of instance variables. An instance of object class A possibly sends a message to another instance of object class B 0, if either class A possesses an instance variable with domain B or if class A possesses a method having class B as domain of one of its input parameters, where B 0 = B or where B 0 is a direct or indirect subclass of B. Two remarks should accompany this statement: (i) We say \an object class possesses an instance variable/instance method" if the class denes that variable/method or if it inherits that variable/method from one of its superclasses. (ii) We have assumed here, for simplicity, that a method executed on an object o may create only objects which are instances of a class which is the domain of some instance variable of o. We claim that the communication structure between instances of a set of object classes should not just be derivable a posteriori by analyzing method interfaces and instance variables 19

20 of these classes, but that it should already be xed a priori by the conceptual organization of classes. Various object-oriented design approaches provide a rich set of modeling constructs to express dierent semantic relationships between object classes (e.g., [39, 17, 27]). These semantic relationships provide a conceptual organization of object classes similar as organization charts give an overview of organizational units of an enterprise and their relationships. Communication between dierent organizational units of an enterprise usually goes only along predened paths, which implicitly follow from the organization chart or which are explicitly dened. Similarly, communication between instances of object classes should go only along specic semantic relationships or should be explicitly declared by a cooperation contract. In addition, we suggest to distinguish dierent types of messages when communication between objects is considered, such as messages requesting to read or to update an object. Then, dierent laws on how objects may communicate can be dened for dierent types of messages. Since it is beyond the scope and focus of this paper to fully discuss the interdependences between class organizations and communication structures, we only sketch an approach based on a simple conceptual object-oriented model. Object classes describe the structure of their instances by a set of attributes, whose values are instances of data types such as Integer or Date, and by two types of relationships, general relationships and has-component relationships. A general relationship links two independent objects. A has-component relationship links a superordinate object with a component object that is dependent on and exclusively referenced by the superordinate object. The class of the component object is referred to as component class. Object classes describe the behavior of their instances by a set of methods, classied into (1) read methods and (2) update methods. Read methods read a property (attribute or relationship) of an object without updating any property of the object nor sending an update message to some other object. Update methods modify a property of an object or send an update message to another object. In our simple model, objects are created and deleted by applying a predened operator to the class of which an instance should be created or removed. Messages can be classied the same way as methods, depending on which kind of methods they address. We use the graphical notation of the Object Modelling Technique of Rumbaugh [39] to denote the conceptual schema of an object-oriented database. Example: Figure 9 depicts object classes Account, Customer, Deposit, and Withdrawal. Classes Account and Customer are related by a general relationship which links an account to the customer holding the account. Classes Deposit and Withdrawal are component classes of Account. For each account, all deposits to the account and all withdrawals from the account are maintained. Class Withdrawal has an optional relationship to class Account, which refers { in the case the withdrawal has not been in cash { to the account to which money has been transferred. (Alternatively, one could introduce two subclasses of Withdrawal, CashWithdrawal and TransferWithdrawal, from which we abstained for simplicity.) The reader is asked to ignore the box labeled Transfer for the moment. Now we dene a communication rule for objects organized in component hierarchies in analogy to similar communication rules in large governmental or business organizations. In hierarchical organizations, instructions are generally given by the superordinate to the subordinate. Reports are provided usually on request to any related organizational unit. 20

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

Modeling Collaborative Behavior Using. Cooperation Contracts. Peter Lang. Abstract Modeling Collaborative Behavior Using Cooperation Contracts Michael Schre Institut fur Wirtschaftsinformatik Johannes Kepler Universitat Linz Altenbergerstr. 69, A-4040 Linz, Austria schre@dke.uni-linz.ac.at

More information

Institut fur Informatik, Universitat Klagenfurt. Institut fur Informatik, Universitat Linz. Institut fur Witschaftsinformatik, Universitat Linz

Institut fur Informatik, Universitat Klagenfurt. Institut fur Informatik, Universitat Linz. Institut fur Witschaftsinformatik, Universitat Linz Coupling and Cohesion in Object-Oriented Systems Johann Eder (1) Gerti Kappel (2) Michael Schre (3) (1) Institut fur Informatik, Universitat Klagenfurt Universitatsstr. 65, A-9020 Klagenfurt, Austria,

More information

NOTES ON OBJECT-ORIENTED MODELING AND DESIGN

NOTES ON OBJECT-ORIENTED MODELING AND DESIGN NOTES ON OBJECT-ORIENTED MODELING AND DESIGN Stephen W. Clyde Brigham Young University Provo, UT 86402 Abstract: A review of the Object Modeling Technique (OMT) is presented. OMT is an object-oriented

More information

What are the characteristics of Object Oriented programming language?

What are the characteristics of Object Oriented programming language? What are the various elements of OOP? Following are the various elements of OOP:- Class:- A class is a collection of data and the various operations that can be performed on that data. Object- This is

More information

Acknowledgments 2

Acknowledgments 2 Program Slicing: An Application of Object-oriented Program Dependency Graphs Anand Krishnaswamy Dept. of Computer Science Clemson University Clemson, SC 29634-1906 anandk@cs.clemson.edu Abstract A considerable

More information

Chapter 11. Categories of languages that support OOP: 1. OOP support is added to an existing language

Chapter 11. Categories of languages that support OOP: 1. OOP support is added to an existing language Categories of languages that support OOP: 1. OOP support is added to an existing language - C++ (also supports procedural and dataoriented programming) - Ada 95 (also supports procedural and dataoriented

More information

Systems Analysis and Design in a Changing World, Fourth Edition. Chapter 12: Designing Databases

Systems Analysis and Design in a Changing World, Fourth Edition. Chapter 12: Designing Databases Systems Analysis and Design in a Changing World, Fourth Edition Chapter : Designing Databases Learning Objectives Describe the differences and similarities between relational and object-oriented database

More information

Chapter No. 2 Class modeling CO:-Sketch Class,object models using fundamental relationships Contents 2.1 Object and Class Concepts (12M) Objects,

Chapter No. 2 Class modeling CO:-Sketch Class,object models using fundamental relationships Contents 2.1 Object and Class Concepts (12M) Objects, Chapter No. 2 Class modeling CO:-Sketch Class,object models using fundamental relationships Contents 2.1 Object and Class Concepts (12M) Objects, Classes, Class Diagrams Values and Attributes Operations

More information

Inheritance (Chapter 7)

Inheritance (Chapter 7) Inheritance (Chapter 7) Prof. Dr. Wolfgang Pree Department of Computer Science University of Salzburg cs.uni-salzburg.at Inheritance the soup of the day?! Inheritance combines three aspects: inheritance

More information

SAMOS: an Active Object{Oriented Database System. Stella Gatziu, Klaus R. Dittrich. Database Technology Research Group

SAMOS: an Active Object{Oriented Database System. Stella Gatziu, Klaus R. Dittrich. Database Technology Research Group SAMOS: an Active Object{Oriented Database System Stella Gatziu, Klaus R. Dittrich Database Technology Research Group Institut fur Informatik, Universitat Zurich fgatziu, dittrichg@ifi.unizh.ch to appear

More information

R/3 System Object-Oriented Concepts of ABAP

R/3 System Object-Oriented Concepts of ABAP R/3 System Object-Oriented Concepts of ABAP Copyright 1997 SAP AG. All rights reserved. No part of this brochure may be reproduced or transmitted in any form or for any purpose without the express permission

More information

Classes and Objects. Object Orientated Analysis and Design. Benjamin Kenwright

Classes and Objects. Object Orientated Analysis and Design. Benjamin Kenwright Classes and Objects Object Orientated Analysis and Design Benjamin Kenwright Outline Review Previous Weeks Object Model, Complexity,.. What do we mean by Classes and Objects? Summary/Discussion Review

More information

Lecture 13: Object orientation. Object oriented programming. Introduction. Object oriented programming. OO and ADT:s. Introduction

Lecture 13: Object orientation. Object oriented programming. Introduction. Object oriented programming. OO and ADT:s. Introduction Lecture 13: Object orientation Object oriented programming Introduction, types of OO languages Key concepts: Encapsulation, Inheritance, Dynamic binding & polymorphism Other design issues Smalltalk OO

More information

Symbol Tables Symbol Table: In computer science, a symbol table is a data structure used by a language translator such as a compiler or interpreter, where each identifier in a program's source code is

More information

A taxonomy of race. D. P. Helmbold, C. E. McDowell. September 28, University of California, Santa Cruz. Santa Cruz, CA

A taxonomy of race. D. P. Helmbold, C. E. McDowell. September 28, University of California, Santa Cruz. Santa Cruz, CA A taxonomy of race conditions. D. P. Helmbold, C. E. McDowell UCSC-CRL-94-34 September 28, 1994 Board of Studies in Computer and Information Sciences University of California, Santa Cruz Santa Cruz, CA

More information

Chapter 5 Object-Oriented Programming

Chapter 5 Object-Oriented Programming Chapter 5 Object-Oriented Programming Develop code that implements tight encapsulation, loose coupling, and high cohesion Develop code that demonstrates the use of polymorphism Develop code that declares

More information

Chapter 8: Class and Method Design

Chapter 8: Class and Method Design Chapter 8: Class and Method Design Objectives Become familiar with coupling, cohesion, and connascence. Be able to specify, restructure, and optimize object designs. Be able to identify the reuse of predefined

More information

REVIEW OF THE BASIC CHARACTERISTICS OF OBJECT ORIENTATION

REVIEW OF THE BASIC CHARACTERISTICS OF OBJECT ORIENTATION c08classandmethoddesign.indd Page 282 13/12/14 2:57 PM user 282 Chapter 8 Class and Method Design acceptance of UML as a standard object notation, standardized approaches based on work of many object methodologists

More information

Chapter 11 Object and Object- Relational Databases

Chapter 11 Object and Object- Relational Databases Chapter 11 Object and Object- Relational Databases Copyright 2011 Pearson Education, Inc. Publishing as Pearson Addison-Wesley Chapter 11 Outline Overview of Object Database Concepts Object-Relational

More information

CMPT 354 Database Systems I

CMPT 354 Database Systems I CMPT 354 Database Systems I Chapter 2 Entity Relationship Data Modeling Data models A data model is the specifications for designing data organization in a system. Specify database schema using a data

More information

Copyright 2016 Ramez Elmasri and Shamkant B. Navathe

Copyright 2016 Ramez Elmasri and Shamkant B. Navathe Chapter 12 Outline Overview of Object Database Concepts Object-Relational Features Object Database Extensions to SQL ODMG Object Model and the Object Definition Language ODL Object Database Conceptual

More information

Generating Continuation Passing Style Code for the Co-op Language

Generating Continuation Passing Style Code for the Co-op Language Generating Continuation Passing Style Code for the Co-op Language Mark Laarakkers University of Twente Faculty: Computer Science Chair: Software engineering Graduation committee: dr.ing. C.M. Bockisch

More information

M301: Software Systems & their Development. Unit 4: Inheritance, Composition and Polymorphism

M301: Software Systems & their Development. Unit 4: Inheritance, Composition and Polymorphism Block 1: Introduction to Java Unit 4: Inheritance, Composition and Polymorphism Aims of the unit: Study and use the Java mechanisms that support reuse, in particular, inheritance and composition; Analyze

More information

OBJECT ORIENTED PROGRAMMING USING C++ CSCI Object Oriented Analysis and Design By Manali Torpe

OBJECT ORIENTED PROGRAMMING USING C++ CSCI Object Oriented Analysis and Design By Manali Torpe OBJECT ORIENTED PROGRAMMING USING C++ CSCI 5448- Object Oriented Analysis and Design By Manali Torpe Fundamentals of OOP Class Object Encapsulation Abstraction Inheritance Polymorphism Reusability C++

More information

Graphical Interface and Application (I3305) Semester: 1 Academic Year: 2017/2018 Dr Antoun Yaacoub

Graphical Interface and Application (I3305) Semester: 1 Academic Year: 2017/2018 Dr Antoun Yaacoub Lebanese University Faculty of Science Computer Science BS Degree Graphical Interface and Application (I3305) Semester: 1 Academic Year: 2017/2018 Dr Antoun Yaacoub 2 Crash Course in JAVA Classes A Java

More information

Advanced Database Applications. Object Oriented Database Management Chapter 13 10/29/2016. Object DBMSs

Advanced Database Applications. Object Oriented Database Management Chapter 13 10/29/2016. Object DBMSs Object Oriented Database Chapter 13 1 Object DBMSs Underlying concepts: Freely sharing data across processing routines creates unacceptable data dependencies All software should be constructed out of standard,

More information

CPS 506 Comparative Programming Languages. Programming Language

CPS 506 Comparative Programming Languages. Programming Language CPS 506 Comparative Programming Languages Object-Oriented Oriented Programming Language Paradigm Introduction Topics Object-Oriented Programming Design Issues for Object-Oriented Oriented Languages Support

More information

For 100% Result Oriented IGNOU Coaching and Project Training Call CPD TM : ,

For 100% Result Oriented IGNOU Coaching and Project Training Call CPD TM : , Course Code : MCS-032 Course Title : Object Oriented Analysis and Design Assignment Number : MCA (3)/032/Assign/2014-15 Assignment Marks : 100 Weightage : 25% Last Dates for Submission : 15th October,

More information

CHAPTER 4 HEURISTICS BASED ON OBJECT ORIENTED METRICS

CHAPTER 4 HEURISTICS BASED ON OBJECT ORIENTED METRICS CHAPTER 4 HEURISTICS BASED ON OBJECT ORIENTED METRICS Design evaluation is most critical activity during software development process. Design heuristics are proposed as a more accessible and informal means

More information

and therefore the system throughput in a distributed database system [, 1]. Vertical fragmentation further enhances the performance of database transa

and therefore the system throughput in a distributed database system [, 1]. Vertical fragmentation further enhances the performance of database transa Vertical Fragmentation and Allocation in Distributed Deductive Database Systems Seung-Jin Lim Yiu-Kai Ng Department of Computer Science Brigham Young University Provo, Utah 80, U.S.A. Email: fsjlim,ngg@cs.byu.edu

More information

Lecture Notes on Programming Languages

Lecture Notes on Programming Languages Lecture Notes on Programming Languages 85 Lecture 09: Support for Object-Oriented Programming This lecture discusses how programming languages support object-oriented programming. Topics to be covered

More information

A Short Summary of Javali

A Short Summary of Javali A Short Summary of Javali October 15, 2015 1 Introduction Javali is a simple language based on ideas found in languages like C++ or Java. Its purpose is to serve as the source language for a simple compiler

More information

Ch. 21: Object Oriented Databases

Ch. 21: Object Oriented Databases Ch. 21: Object Oriented Databases Learning Goals: * Learn about object data model * Learn about o.o. query languages, transactions Topics: * 21.1 * 21.2 * 21.3 * 21.4 * 21.5 Source: Ch#21, Bertino93, Kim

More information

Algorithmic "imperative" language

Algorithmic imperative language Algorithmic "imperative" language Undergraduate years Epita November 2014 The aim of this document is to introduce breiy the "imperative algorithmic" language used in the courses and tutorials during the

More information

OBJECT ORİENTATİON ENCAPSULATİON

OBJECT ORİENTATİON ENCAPSULATİON OBJECT ORİENTATİON Software development can be seen as a modeling activity. The first step in the software development is the modeling of the problem we are trying to solve and building the conceptual

More information

UNIT II Requirements Analysis and Specification & Software Design

UNIT II Requirements Analysis and Specification & Software Design UNIT II Requirements Analysis and Specification & Software Design Requirements Analysis and Specification Many projects fail: because they start implementing the system: without determining whether they

More information

Object-Oriented Programming Paradigm

Object-Oriented Programming Paradigm Object-Oriented Programming Paradigm Sample Courseware Object-Oriented Programming Paradigm Object-oriented programming approach allows programmers to write computer programs by representing elements of

More information

Database Systems Concepts *

Database Systems Concepts * OpenStax-CNX module: m28156 1 Database Systems Concepts * Nguyen Kim Anh This work is produced by OpenStax-CNX and licensed under the Creative Commons Attribution License 3.0 Abstract This module introduces

More information

Chapter 6 Introduction to Defining Classes

Chapter 6 Introduction to Defining Classes Introduction to Defining Classes Fundamentals of Java: AP Computer Science Essentials, 4th Edition 1 Objectives Design and implement a simple class from user requirements. Organize a program in terms of

More information

Late-bound Pragmatical Class Methods

Late-bound Pragmatical Class Methods Late-bound Pragmatical Class Methods AXEL SCHMOLITZKY, MARK EVERED, J. LESLIE KEEDY, GISELA MENGER Department of Computer Structures University of Ulm 89069 Ulm, Germany {axel, markev, keedy, gisela@informatik.uni-ulm.de

More information

CS112 Lecture: Defining Classes. 1. To describe the process of defining an instantiable class

CS112 Lecture: Defining Classes. 1. To describe the process of defining an instantiable class CS112 Lecture: Defining Classes Last revised 2/3/06 Objectives: 1. To describe the process of defining an instantiable class Materials: 1. BlueJ SavingsAccount example project 2. Handout of code for SavingsAccount

More information

Chapter 2 Overview of the Design Methodology

Chapter 2 Overview of the Design Methodology Chapter 2 Overview of the Design Methodology This chapter presents an overview of the design methodology which is developed in this thesis, by identifying global abstraction levels at which a distributed

More information

Back to ObjectLand. Contents at: Chapter 5. Questions of Interest. encapsulation. polymorphism. inheritance overriding inheritance super

Back to ObjectLand. Contents at: Chapter 5. Questions of Interest. encapsulation. polymorphism. inheritance overriding inheritance super korienekch05.qxd 11/12/01 4:06 PM Page 105 5 Back to ObjectLand Contents at: Chapter 5 #( encapsulation polymorphism inheritance overriding inheritance super learning the class hierarchy finding classes

More information

Reverse Engineering with a CASE Tool. Bret Johnson. Research advisors: Spencer Rugaber and Rich LeBlanc. October 6, Abstract

Reverse Engineering with a CASE Tool. Bret Johnson. Research advisors: Spencer Rugaber and Rich LeBlanc. October 6, Abstract Reverse Engineering with a CASE Tool Bret Johnson Research advisors: Spencer Rugaber and Rich LeBlanc October 6, 994 Abstract We examine using a CASE tool, Interactive Development Environment's Software

More information

CS112 Lecture: Defining Instantiable Classes

CS112 Lecture: Defining Instantiable Classes CS112 Lecture: Defining Instantiable Classes Last revised 2/3/05 Objectives: 1. To describe the process of defining an instantiable class 2. To discuss public and private visibility modifiers. Materials:

More information

Object-Oriented Design

Object-Oriented Design Object-Oriented Design Lecture 14: Design Workflow Department of Computer Engineering Sharif University of Technology 1 UP iterations and workflow Workflows Requirements Analysis Phases Inception Elaboration

More information

DRAFT for FINAL VERSION. Accepted for CACSD'97, Gent, Belgium, April 1997 IMPLEMENTATION ASPECTS OF THE PLC STANDARD IEC

DRAFT for FINAL VERSION. Accepted for CACSD'97, Gent, Belgium, April 1997 IMPLEMENTATION ASPECTS OF THE PLC STANDARD IEC DRAFT for FINAL VERSION. Accepted for CACSD'97, Gent, Belgium, 28-3 April 1997 IMPLEMENTATION ASPECTS OF THE PLC STANDARD IEC 1131-3 Martin hman Stefan Johansson Karl-Erik rzen Department of Automatic

More information

Data Structures (list, dictionary, tuples, sets, strings)

Data Structures (list, dictionary, tuples, sets, strings) Data Structures (list, dictionary, tuples, sets, strings) Lists are enclosed in brackets: l = [1, 2, "a"] (access by index, is mutable sequence) Tuples are enclosed in parentheses: t = (1, 2, "a") (access

More information

Several major software companies including IBM, Informix, Microsoft, Oracle, and Sybase have all released object-relational versions of their

Several major software companies including IBM, Informix, Microsoft, Oracle, and Sybase have all released object-relational versions of their Several major software companies including IBM, Informix, Microsoft, Oracle, and Sybase have all released object-relational versions of their products. These companies are promoting a new, extended version

More information

The Next Step: Designing DB Schema. Chapter 6: Entity-Relationship Model. The E-R Model. Identifying Entities and their Attributes.

The Next Step: Designing DB Schema. Chapter 6: Entity-Relationship Model. The E-R Model. Identifying Entities and their Attributes. Chapter 6: Entity-Relationship Model Our Story So Far: Relational Tables Databases are structured collections of organized data The Relational model is the most common data organization model The Relational

More information

Weiss Chapter 1 terminology (parenthesized numbers are page numbers)

Weiss Chapter 1 terminology (parenthesized numbers are page numbers) Weiss Chapter 1 terminology (parenthesized numbers are page numbers) assignment operators In Java, used to alter the value of a variable. These operators include =, +=, -=, *=, and /=. (9) autoincrement

More information

Object Oriented Programming is a programming method that combines: Advantage of Object Oriented Programming

Object Oriented Programming is a programming method that combines: Advantage of Object Oriented Programming Overview of OOP Object Oriented Programming is a programming method that combines: a) Data b) Instructions for processing that data into a self-sufficient object that can be used within a program or in

More information

OO Design Principles

OO Design Principles OO Design Principles Software Architecture VO (706.706) Roman Kern Institute for Interactive Systems and Data Science, TU Graz 2018-10-10 Roman Kern (ISDS, TU Graz) OO Design Principles 2018-10-10 1 /

More information

Overview of OOP. Dr. Zhang COSC 1436 Summer, /18/2017

Overview of OOP. Dr. Zhang COSC 1436 Summer, /18/2017 Overview of OOP Dr. Zhang COSC 1436 Summer, 2017 7/18/2017 Review Data Structures (list, dictionary, tuples, sets, strings) Lists are enclosed in square brackets: l = [1, 2, "a"] (access by index, is mutable

More information

Class Inheritance and OLE Integration (Formerly the Common Object Model)

Class Inheritance and OLE Integration (Formerly the Common Object Model) TM Class Inheritance and OLE Integration (Formerly the Common Object Model) Technical Overview Shawn Woods, Mike Vogl, and John Parodi August 1995 Digital Equipment Corporation Introduction This paper

More information

3. Object-Oriented Databases

3. Object-Oriented Databases 3. Object-Oriented Databases Weaknesses of Relational DBMSs Poor representation of 'real world' entities Poor support for integrity and business rules Homogenous data structure Limited operations Difficulty

More information

The Essence of Object Oriented Programming with Java and UML. Chapter 2. The Essence of Objects. What Is an Object-Oriented System?

The Essence of Object Oriented Programming with Java and UML. Chapter 2. The Essence of Objects. What Is an Object-Oriented System? Page 1 of 21 Page 2 of 21 and identity. Objects are members of a class, and the attributes and behavior of an object are defined by the class definition. The Essence of Object Oriented Programming with

More information

Chapter 6: Entity-Relationship Model. The Next Step: Designing DB Schema. Identifying Entities and their Attributes. The E-R Model.

Chapter 6: Entity-Relationship Model. The Next Step: Designing DB Schema. Identifying Entities and their Attributes. The E-R Model. Chapter 6: Entity-Relationship Model The Next Step: Designing DB Schema Our Story So Far: Relational Tables Databases are structured collections of organized data The Relational model is the most common

More information

UNIT II. Syllabus. a. An Overview of the UML: Visualizing, Specifying, Constructing, Documenting

UNIT II. Syllabus. a. An Overview of the UML: Visualizing, Specifying, Constructing, Documenting UNIT II Syllabus Introduction to UML (08 Hrs, 16 Marks) a. An Overview of the UML: Visualizing, Specifying, Constructing, Documenting b. Background, UML Basics c. Introducing UML 2.0 A Conceptual Model

More information

Assoc. Prof. Marenglen Biba. (C) 2010 Pearson Education, Inc. All rights reserved.

Assoc. Prof. Marenglen Biba. (C) 2010 Pearson Education, Inc. All rights reserved. Assoc. Prof. Marenglen Biba (C) 2010 Pearson Education, Inc. All Inheritance A form of software reuse in which a new class is created by absorbing an existing class s members and enriching them with

More information

Concept as a Generalization of Class and Principles of the Concept-Oriented Programming

Concept as a Generalization of Class and Principles of the Concept-Oriented Programming Computer Science Journal of Moldova, vol.13, no.3(39), 2005 Concept as a Generalization of Class and Principles of the Concept-Oriented Programming Alexandr Savinov Abstract In the paper we describe a

More information

Informatics 1: Data & Analysis

Informatics 1: Data & Analysis Informatics 1: Data & Analysis Lecture 3: The Relational Model Ian Stark School of Informatics The University of Edinburgh Tuesday 24 January 2017 Semester 2 Week 2 https://blog.inf.ed.ac.uk/da17 Lecture

More information

Lecture 2 - Graph Theory Fundamentals - Reachability and Exploration 1

Lecture 2 - Graph Theory Fundamentals - Reachability and Exploration 1 CME 305: Discrete Mathematics and Algorithms Instructor: Professor Aaron Sidford (sidford@stanford.edu) January 11, 2018 Lecture 2 - Graph Theory Fundamentals - Reachability and Exploration 1 In this lecture

More information

Introduction to Computers and Programming Languages. CS 180 Sunil Prabhakar Department of Computer Science Purdue University

Introduction to Computers and Programming Languages. CS 180 Sunil Prabhakar Department of Computer Science Purdue University Introduction to Computers and Programming Languages CS 180 Sunil Prabhakar Department of Computer Science Purdue University 1 Objectives This week we will study: The notion of hardware and software Programming

More information

Design issues for objectoriented. languages. Objects-only "pure" language vs mixed. Are subclasses subtypes of the superclass?

Design issues for objectoriented. languages. Objects-only pure language vs mixed. Are subclasses subtypes of the superclass? Encapsulation Encapsulation grouping of subprograms and the data they manipulate Information hiding abstract data types type definition is hidden from the user variables of the type can be declared variables

More information

2 Addressing the Inheritance Anomaly One of the major issues in correctly connecting task communication mechanisms and the object-oriented paradigm is

2 Addressing the Inheritance Anomaly One of the major issues in correctly connecting task communication mechanisms and the object-oriented paradigm is Extendable, Dispatchable Task Communication Mechanisms Stephen Michell Maurya Software 29 Maurya Court Ottawa Ontario, Canada K1G 5S3 steve@maurya.on.ca Kristina Lundqvist Dept. of Computer Systems Uppsala

More information

CHAPTER 5 GENERAL OOP CONCEPTS

CHAPTER 5 GENERAL OOP CONCEPTS CHAPTER 5 GENERAL OOP CONCEPTS EVOLUTION OF SOFTWARE A PROGRAMMING LANGUAGE SHOULD SERVE 2 RELATED PURPOSES : 1. It should provide a vehicle for programmer to specify actions to be executed. 2. It should

More information

The Architecture of a System for the Indexing of Images by. Content

The Architecture of a System for the Indexing of Images by. Content The Architecture of a System for the Indexing of s by Content S. Kostomanolakis, M. Lourakis, C. Chronaki, Y. Kavaklis, and S. C. Orphanoudakis Computer Vision and Robotics Laboratory Institute of Computer

More information

Concepts of Programming Languages

Concepts of Programming Languages Concepts of Programming Languages Lecture 10 - Object-Oriented Programming Patrick Donnelly Montana State University Spring 2014 Patrick Donnelly (Montana State University) Concepts of Programming Languages

More information

The Compositional C++ Language. Denition. Abstract. This document gives a concise denition of the syntax and semantics

The Compositional C++ Language. Denition. Abstract. This document gives a concise denition of the syntax and semantics The Compositional C++ Language Denition Peter Carlin Mani Chandy Carl Kesselman March 12, 1993 Revision 0.95 3/12/93, Comments welcome. Abstract This document gives a concise denition of the syntax and

More information

Abstract. Programs written in languages of the Oberon family usually. contain runtime tests on the dynamic type of variables.

Abstract. Programs written in languages of the Oberon family usually. contain runtime tests on the dynamic type of variables. Type Test Elimination using Typeow Analysis Diane Corney and John Gough Queensland University of Technology, Brisbane, Australia Abstract. Programs written in languages of the Oberon family usually contain

More information

JAVASCRIPT AND JQUERY: AN INTRODUCTION (WEB PROGRAMMING, X452.1)

JAVASCRIPT AND JQUERY: AN INTRODUCTION (WEB PROGRAMMING, X452.1) Technology & Information Management Instructor: Michael Kremer, Ph.D. Class 2 Professional Program: Data Administration and Management JAVASCRIPT AND JQUERY: AN INTRODUCTION (WEB PROGRAMMING, X452.1) AGENDA

More information

UNIVERSITÄT PADERBORN. ComponentTools

UNIVERSITÄT PADERBORN. ComponentTools UNIVERSITÄT PADERBORN ComponentTools Component Library Concept Project Group ComponentTools pg-components@uni-paderborn.de Alexander Gepting, Joel Greenyer, Andreas Maas, Sebastian Munkelt, Csaba Pales,

More information

What is Inheritance?

What is Inheritance? Inheritance 1 Agenda What is and Why Inheritance? How to derive a sub-class? Object class Constructor calling chain super keyword Overriding methods (most important) Hiding methods Hiding fields Type casting

More information

Transparent Access to Legacy Data in Java. Olivier Gruber. IBM Almaden Research Center. San Jose, CA Abstract

Transparent Access to Legacy Data in Java. Olivier Gruber. IBM Almaden Research Center. San Jose, CA Abstract Transparent Access to Legacy Data in Java Olivier Gruber IBM Almaden Research Center San Jose, CA 95120 Abstract We propose in this paper an extension to PJava in order to provide a transparent access

More information

Idioms for Building Software Frameworks in AspectJ

Idioms for Building Software Frameworks in AspectJ Idioms for Building Software Frameworks in AspectJ Stefan Hanenberg 1 and Arno Schmidmeier 2 1 Institute for Computer Science University of Essen, 45117 Essen, Germany shanenbe@cs.uni-essen.de 2 AspectSoft,

More information

proc {Produce State Out} local State2 Out2 in State2 = State + 1 Out = State Out2 {Produce State2 Out2}

proc {Produce State Out} local State2 Out2 in State2 = State + 1 Out = State Out2 {Produce State2 Out2} Laziness and Declarative Concurrency Raphael Collet Universite Catholique de Louvain, B-1348 Louvain-la-Neuve, Belgium raph@info.ucl.ac.be May 7, 2004 Abstract Concurrency and distribution in a programming

More information

0. Database Systems 1.1 Introduction to DBMS Information is one of the most valuable resources in this information age! How do we effectively and efficiently manage this information? - How does Wal-Mart

More information

Semantics via Syntax. f (4) = if define f (x) =2 x + 55.

Semantics via Syntax. f (4) = if define f (x) =2 x + 55. 1 Semantics via Syntax The specification of a programming language starts with its syntax. As every programmer knows, the syntax of a language comes in the shape of a variant of a BNF (Backus-Naur Form)

More information

Index. Index. More information. block statements 66 y 107 Boolean 107 break 55, 68 built-in types 107

Index. Index. More information. block statements 66 y 107 Boolean 107 break 55, 68 built-in types 107 A abbreviations 17 abstract class 105 abstract data types 105 abstract method 105 abstract types 105 abstraction 92, 105 access level 37 package 114 private 115 protected 115 public 115 accessors 24, 105

More information

Forth Meets Smalltalk. A Presentation to SVFIG October 23, 2010 by Douglas B. Hoffman

Forth Meets Smalltalk. A Presentation to SVFIG October 23, 2010 by Douglas B. Hoffman Forth Meets Smalltalk A Presentation to SVFIG October 23, 2010 by Douglas B. Hoffman 1 CONTENTS WHY FMS? NEON HERITAGE SMALLTALK HERITAGE TERMINOLOGY EXAMPLE FMS SYNTAX ACCESSING OVERRIDDEN METHODS THE

More information

In this Lecture you will Learn: Object Design. Information Sources for Object Design. Class Specification: Attributes

In this Lecture you will Learn: Object Design. Information Sources for Object Design. Class Specification: Attributes In this Lecture you will Learn: Object Design Chapter 14 How to apply criteria for good design How to design associations The impact of integrity constraints on design How to design operations The role

More information

Schema Evolution for Real-Time Object-Oriented Databases 1

Schema Evolution for Real-Time Object-Oriented Databases 1 Schema Evolution for Real-Time Object-Oriented Databases 1 Lei Zhou, Elke A. Rundensteiner, and Kang G. Shin Department of Electrical Engineering and Computer Science The University of Michigan Ann Arbor,

More information

Contents. I. Classes, Superclasses, and Subclasses. Topic 04 - Inheritance

Contents. I. Classes, Superclasses, and Subclasses. Topic 04 - Inheritance Contents Topic 04 - Inheritance I. Classes, Superclasses, and Subclasses - Inheritance Hierarchies Controlling Access to Members (public, no modifier, private, protected) Calling constructors of superclass

More information

Object Relationships

Object Relationships Object Relationships Objects can work together in three different types of relationships: Uses: An object can use another to do some work (association). Composition: A complex object may be composed of

More information

HOW AND WHEN TO FLATTEN JAVA CLASSES?

HOW AND WHEN TO FLATTEN JAVA CLASSES? HOW AND WHEN TO FLATTEN JAVA CLASSES? Jehad Al Dallal Department of Information Science, P.O. Box 5969, Safat 13060, Kuwait ABSTRACT Improving modularity and reusability are two key objectives in object-oriented

More information

CS54100: Database Systems

CS54100: Database Systems CS54100: Database Systems Data Modeling 13 January 2012 Prof. Chris Clifton Main categories of data models Logical models: used to describe, organize and access data in DBMS; application programs refers

More information

The major elements of the object-oriented model

The major elements of the object-oriented model The major elements of the object-oriented model Abstraction Encapsulation Inheritance Modularity Suggested Reading: Bruce Eckel, Thinking in Java (Fourth Edition) Reusing Classes Hierarchy 2 An abstraction

More information

Reuse Contracts As Component Interface. Descriptions. Koen De Hondt, Carine Lucas, and Patrick Steyaert. Programming Technology Lab

Reuse Contracts As Component Interface. Descriptions. Koen De Hondt, Carine Lucas, and Patrick Steyaert. Programming Technology Lab Reuse Contracts As Component Interface Descriptions Koen De Hondt, Carine Lucas, and Patrick Steyaert Programming Technology Lab Computer Science Department Vrije Universiteit Brussel Pleinlaan 2, B-1050

More information

CS558 Programming Languages Winter 2013 Lecture 8

CS558 Programming Languages Winter 2013 Lecture 8 OBJECT-ORIENTED PROGRAMMING CS558 Programming Languages Winter 2013 Lecture 8 Object-oriented programs are structured in terms of objects: collections of variables ( fields ) and functions ( methods ).

More information

Chapter 15. Object-Oriented Programming

Chapter 15. Object-Oriented Programming number of operands as their built-in counterparts. user-defined conversion A synonym for class-type conversion. Chapter 15. Object-Oriented Programming Contents Section 15.1 OOP: An Overview Section 15.2

More information

Credit where Credit is Due. Lecture 4: Fundamentals of Object Technology. Goals for this Lecture. Real-World Objects

Credit where Credit is Due. Lecture 4: Fundamentals of Object Technology. Goals for this Lecture. Real-World Objects Lecture 4: Fundamentals of Object Technology Kenneth M. Anderson Object-Oriented Analysis and Design CSCI 6448 - Spring Semester, 2003 Credit where Credit is Due Some material presented in this lecture

More information

Software Development. Modular Design and Algorithm Analysis

Software Development. Modular Design and Algorithm Analysis Software Development Modular Design and Algorithm Analysis Data Encapsulation Encapsulation is the packing of data and functions into a single component. The features of encapsulation are supported using

More information

The Object Recursion Pattern

The Object Recursion Pattern SilverMark, Inc. woolf@acm.org OBJECT RECURSION Object Behavioral Intent Distribute processing of a request over a structure by delegating polymorphically. Object Recursion transparently enables a request

More information

Self-review Questions

Self-review Questions 7Class Relationships 106 Chapter 7: Class Relationships Self-review Questions 7.1 How is association between classes implemented? An association between two classes is realized as a link between instance

More information

CS 4604: Introduction to Database Management Systems. B. Aditya Prakash Lecture #5: Entity/Relational Models---Part 1

CS 4604: Introduction to Database Management Systems. B. Aditya Prakash Lecture #5: Entity/Relational Models---Part 1 CS 4604: Introduction to Database Management Systems B. Aditya Prakash Lecture #5: Entity/Relational Models---Part 1 E/R: NOT IN BOOK! IMPORTANT: Follow only lecture slides for this topic! Differences

More information

Week 3: Functions and Data. Working with objects. Members of an object. = n 1d 2 n 2 d 1. + n 2. = n 1d 2. = n 1n 2 / n 2. = n 2

Week 3: Functions and Data. Working with objects. Members of an object. = n 1d 2 n 2 d 1. + n 2. = n 1d 2. = n 1n 2 / n 2. = n 2 Week 3: Functions and Data In this section, we'll learn how functions create and encapsulate data structures. Exemple : Rational Numbers We want to design a package for doing rational arithmetic. A rational

More information

CIS 1.5 Course Objectives. a. Understand the concept of a program (i.e., a computer following a series of instructions)

CIS 1.5 Course Objectives. a. Understand the concept of a program (i.e., a computer following a series of instructions) By the end of this course, students should CIS 1.5 Course Objectives a. Understand the concept of a program (i.e., a computer following a series of instructions) b. Understand the concept of a variable

More information

Java Object Oriented Design. CSC207 Fall 2014

Java Object Oriented Design. CSC207 Fall 2014 Java Object Oriented Design CSC207 Fall 2014 Design Problem Design an application where the user can draw different shapes Lines Circles Rectangles Just high level design, don t write any detailed code

More information

Java How to Program, 8/e

Java How to Program, 8/e Java How to Program, 8/e Polymorphism Enables you to program in the general rather than program in the specific. Polymorphism enables you to write programs that process objects that share the same superclass

More information