Proposals for Extending the Modelling Facilities of Object Oriented Languages Peter Grogono Antero Taivalsaari1 Karen Tennenhouse Department of Computer Science, Concordia University 1455 de Maisonneuve Blvd., Montreal, Quebec Canada H3G 1M8 Tel: (514) 848-3000 Fax: (514) 848-2830 e-mail:
[email protected]
[email protected] [email protected]
Abstract The object oriented paradigm provides powerful tools for implementors but has less to o er to designers and modellers. We use examples to illustrate the weaknesses of object oriented facilities for design and modelling, review proposed extensions of the paradigm, and introduce some extensions of our own.
Submitted to ECOOP'92. Last revision: 12 April 1991. 1
Currently visiting Concordia University. Permanent address: University of Jyvaskyla, Finland.
Proposals for Extending the Modelling Facilities of Object Oriented Languages 1 Introduction Advocates of object oriented programming used to base their claims on data modelling capabilities. Stripped to its essentials, the argument is that objects in a program, viewed as autonomous entities encapsulating both data and actions, can accurately simulate their counterparts in the real world [13, page 51], [3, section 3.1]. Object oriented languages also provide inheritance, which caters to the human propensity for abstracting by classifying. The claims about modelling were followed by claims about the advantages of object oriented programming for software development. Advocates pointed to the ease of maintenance (code is added rather than altered) and reuse (inheritance again). Both claims|modelling and development|have strengths and weaknesses. In this paper, we focus on the weaknesses of the object oriented paradigm for conceptual modelling. In Section 2, we use a simple example to illustrate some of the weaknesses of the object oriented design methodology that we have encountered in our own work. We then demonstrate, in Section 3, that there have been numerous proposal for enhancement and extension of the basic object oriented paradigm. In Section 4, we discuss the extensions that we believe to be necessary to make object oriented design useful in practice.
2 An Example of Modelling We consider an application which illustrates the de ciencies that concern us. We have chosen the example with respect to three criteria. 1. It is suciently complex to illustrate our major points. The complexity precludes a complete presentation of the example in this paper. 2. It is not one of the \classical" applications for which object oriented programming is known|or at least believed|to work well, such as a user interface. 3. It appears to be a suitable candidate for object oriented design, in that objects and their attributes are readily identi ed. 1
Our example is a simple reservation system for an airline. Traditionally, such systems are rather large, but with today's technology we can assume that a small airline might manage with a typical desktop workstation. The name of our hypothetical corporation is Penguin Airlines (hereafter \PA"). The central object in the design is a reservation with a unique reservationNumber (Figure 1). Unique keys are not usually required in object oriented programming, because each object has its own identity. In some cases, however, we require a unique identi er which is accessible to users as well as the system itself. In the class Reservation, the variables reservationNumber and seat are intrinsic components of the reservation but the variables passenger and ight are references to other objects, or \associates". The distinction is not always obvious and we clarify it with the following rule of thumb: if an object is destroyed, its components are also destroyed but its associates are not destroyed. For example if a reservation is cancelled, its reservationNumber is deleted but the passenger and actualFlight presumably still exist. DSN is one of the few object oriented languages which provide this kind of facility [15]. Implementation devices such as values and pointers are not appropriate tools for modelling distinctions of this kind. For example, seatingDescriptor, which is a component of class Plane (Figure 5) might be a data structure represented by a pointer. A reservation links a passenger to an actual ight. We show Passenger as a single class (Figure 2) although in practice there might be a hierarchy of passenger classes. A passenger holds a (possibly empty) set of reservations. Mutual interactions of this kind (passengers and reservations must refer to each other) arise frequently in modelling and e ective techniques for dealing with them are essential. An ActualFlight (Figure 3) is an instance of a Flight (Figure 4). For example, ight PA69
ies from McMurdo to Terra del Fuego on Thursdays, and the particular ight \PA69 on 26/12/91" is an instance of the general ight PA69. Although \instance of" suggests that actualFlight is an object and Flight is a class, in practice we must model a Flight as an object, because ights can be added, changed, and deleted. The connection between a ight and an actual ight must therefore be represented by an association link: the eld ight in class ActualFlight. A similar distinction is required between the abstraction Plane (Figure 5) and ActualPlane (Figure 6). An instance of the class Plane for PA is Dakota. Instances of ActualPlane include #17 and \the black and white one with a yellow beak". Generic planes, like generic ights, cannot be sensibly modelled as a class in any language that does not provide attributes at the class level. The application includes a number of collections (Figure 7), all of which we have shown as Set[C] for some class C. In classical object oriented programming, these would be implemented as subclasses of an appropriate collection class. In a typical language with genericity, they would be implemented as parameterized classes, as our notation suggests. Both methods have advantages and disadvantages [12] and genericity introduces the additional complication of higher order classes [14]. 2
Since much has been written about the use of inheritance in design, our remarks about it are brief. Our experience has been that, although there are situations in which inheritance is almost indispensable, they are rare. In our example, there are a few places in which inheritance might be useful, but early introduction of inheritance would confuse rather than clarify the model. There are several places in the example where objects really need several interfaces. Although we do not show the details, each plane should have a schedule of ying times interleaved with maintenance periods. Attributes pertaining to ying and maintenance should be visible to di erent parts of the system. Both design and implementation are simpli ed if objects can have modes [18]. For example, a reservation may be open, con rmed, or cancelled, and a plane may be available, in-use, grounded, or lost. Modes correspond to union types in traditional languages. Modes are not the same as subclasses, because it is normal and expected that an object should change its mode frequently. To conclude the discussion of the example, we note that it is not particularly dicult to come up with a design using traditional data structures such as records, unions, and pointers. The resulting program would be harder to maintain and enhance than the object oriented program. This kind of example crops up frequently in database discussions, not because it is dicult to solve, but because it presents interesting issues.
3 Extending the Basic Paradigm Numerous authors have proposed re nements and extensions to the object oriented paradigm. In fact the sheer number of proposals may be an indication of fundamental weaknesses in the basic paradigm. We brie y review some of these proposals and we show in Section 4 that they can be placed into a small number of categories. The litmus test that we use for modelling with inheritance is the relation is-a. If every X \is a" Y , then the class of X s inherits from the class of Y s. Brachman, however, distinguishes six di erent ways in which the is-a relationship is actually used as a relation between classes and four di erent ways in which it is used as a relation between classes and individuals [6]. Although Brachman was writing about knowledge representation, his reasoning applies to object oriented programming as well. There are three inter-class relations that most authors seem to agree upon: generalization, aggregation, and association. Roughly, generalization corresponds to is-a and aggregation corresponds to has-a. Brodie [7] and Loomis et al. [11] de ne \associations" to be userde ned relations . For example, possible relationships between Person and Car are Owner (Person ! Car) and Asset (Car ! Person). Data models usually provide such associations but object oriented languages do not. In addition to the is-a relation, object oriented languages provide a \has-a" relation, usually in the form of instance variables. This relation, like is-a, has many di erent uses in practice. A person may \have" a name, an age, a bank account, a boss, and a headache, but \have" 3
does not adequately express the di erences between these relations. In particular, Blake and Cook point out that most object oriented languages lack the ability to describe part hierarchies [2]. Suppose, to use their example, a person has a LeftLeg, which has a LowerLeg, which has a Foot, which has a BigToe: most object oriented languages do not provide a convenient way of telling Joe to wiggle his left big toe. People are accustomed to dealing with the contradictions that arise from over-generalization. They accept, for instance, that \all birds y", \penguins are birds", and \penguins do not
y". Programming languages do not easily accdate this kind of fuzzy thinking. Borgida proposes a modeling language which allows such contradictions and even provides rules for safe typing in their presence [4]. The distinction between classes and objects is clear at the design level. Planes and Dakotas are classes, #17 is an object. Implementation issues, however, muddy the demarcation. If we implement Planes and Dakotas as classes, then instances such as #17 will contain a large amount of information, most of which is redundant. Moreover, a class such as Dakota is subject to change. One way out of this impasse is to go back to the source. Smalltalk has the feature we need: classes are objects. The trend, however, has been away from dynamic languages like Smalltalk and towards static languages like C++ and Ei el.2 Software engineering concerns such as eciency, security, type correctness, and maintenance encourage this trend. In most object oriented languages, each object presents one interface to its heirs and another to its clients. We think of real objects as having many di erent aspects. The signi cant attributes of a car, for example, depend on whether we view it as a means of travel, an expensive acquisition, a status symbol, or a source of pollution. A number of researchers have suggested that object oriented languages should provide similar distinctions [1, 8, 16, 20]. The need to specify contracts between objects is a related concept [9]. One of the achievements of object oriented programming is the reduced need for selection statements such as if, case, and switch. Statements which choose an action based on a variant type can often be eliminated by subclasses and dynamic binding. For applications in which subclasses are inappropriate, we may be able to eliminate the selection statements by providing modes , as described in Section 2. Although inheritance is one of the cornerstones of object oriented programming, it is still a controversial topic. Snyder's classic paper shows the tension beetween inheritance and encapsulation [17]. Some feel that even multiple inheritance is not general enough and that mechanisms such as mixins are required for object oriented modelling [5].
4 Towards Better Modelling The example in the previous section highlights some of the diculties we have experienced in object oriented design. The following list summarizes these diculties. SELF [19] is a notable exception, but it does not solve this particular problem: classes (called \maps" in SELF) are hidden by the implementation. 2
4
1. The object oriented paradigm encourages abstract design by providing objects as autonomous entities, but it lacks some of the mechanisms for appropriate implementation of the abstractions. 2. There is confusion between abstraction mechanisms and implementation mechanisms. Lalonde identi ed this as a problem with inheritance [10]. We encountered it in making distinctions between classes and objects (see Section 3). 3. Inheritance is less useful than it is often claimed to be. Introducing inheritance early in the design process may lead to confusion. Introducing inheritance late may help to reduce redundancy in the design, but this implies that inheritance is more an implementation mechanism than a design tool. 4. The idea that an object presents a single interface to its environment is often inadequate. On the positive side, the object oriented paradigm has advantages which have already been widely advertised. Brie y: 1. Object modelling has advantages over other kinds of modelling, including relational modelling. Object identity eliminates much of the need for unique keys and object structure eliminates much of the need for value-based joins. 2. The underlying metaphor|sending messages to active objects|is easier to understand for many people than declarative approaches, although the latter may have simpler semantics than the former. In summary, we believe that object oriented programming is a large step in the right direction, but it is not a universal panacea|at least, not yet. We conclude this section by summarizing the features that we believe are necessary for successful object oriented modelling. 1. It should be possible to distinguish components and associates of objects. 2. It should be possible for an object to reveal di erent interfaces to di erent parts of the system. 3. Objects should have modes. The response of an object to a message depends on both its internal state and its current mode. 4. There should be a clear distinction between classes and objects, but both should be run-time entities.
5
5 Conclusion Our experience indicates that the people who get the most out of object oriented programming are implementors rather than modellers and designers. Object oriented programs have modular structure with good encapsulation and are relatively easy to maintain and extend. The claim that the object oriented paradigm supports modelling and the early phases of design is harder to substantiate. It is true that people are good at using classi cation for abstraction and that they can relate to message-passing as a model of computation. It is not true that these ideas are sucient for serious programming. We have made proposals in this paper, based on our own experience. We intend to pursue these proposals and we hope that others will too. The deeper message of this paper, however, is that, if the object oriented paradigm is to remain an emperor, it needs some clothes|or perhaps wings. Acknowledgements Grogono's research was supported by the Natural Sciences and Engineering Research Council of Canada, the Fund for Research and Development of Concordia University. Taivalsaari's research was supported by the Academy of Finland as part of the project Object-oriented Languages and Techniques (#1061120) and by the Emil Aaltonen Foundation.
References [1] J. Bergin. Iterators, cohort classes, and private classes. In Proc. Symp. on ObjectOriented Programming Emphasizing Practical Applications (SOOPPA), pages 261{268, September 1990. [2] E. Blake and Stephen Cook. On including part hierarchies in object oriented languages, with an implementation in Smalltalk. In Proceedings of the 1987 European Conference on Object Oriented Programming, pages 41{50, 1987. [3] Grady Booch. Object Oriented Design with Applications. Benjamin/Cummings, 1991. [4] A. Borgida. Modelling class hierarchies with contradictions. In ACM International Conference on Management of Data, pages 434{443, 1988. Also published as SIGMOD Record , 17:3, September 1988. [5] G. Bracha and William Cook. Mixin-based inheritance. In N. Meyrowitz, editor, Proc. ACM Conf. on Object-Oriented Programming Systems, Languages and Applications, pages 303{311, October 1990. [6] R. Brachman. What IS-A is and isn't: an analysis of taxonomic links in semantic networks. IEEE Computer, 30{36, October 1983. [7] M. Brodie. Association: a database abstraction for semantic modelling. In P. Chen, editor, Entity-Relationship Approach to Information Modeling and Analysis, pages 577{ 602, Elsevier Science Publishers, 1983. 6
[8] I. Goldstein and D. Bobrow. Extending object oriented programming in Smalltalk. In Conference Record of the 1980 LISP Conference, pages 75{81, 1980. [9] R. Helm, I. Holland, and D. Gangopadhyay. Contracts: specifying behavioral compositions in object oriented systems. In N. Meyrowitz, editor, Proc. ACM Conf. on Object-Oriented Programming Systems, Languages and Applications, pages 169{180, 1990. [10] W. Lalonde, D. Thomas, and J. Pugh. An exemplar based Smalltalk. In N. Meyrowitz, editor, Proc. ACM Conf. on Object-Oriented Programming Systems, Languages and Applications, pages 322{330, 1986. [11] M. Loomis, A. Shah, and J. Rumbaugh. An object modeling technique for conceptual design. In Proceedings of the 1987 European Conference on Object Oriented Programming, pages 192{202, 1987. [12] Bertrand Meyer. Genericity versus inheritance. In N. Meyrowitz, editor, Proc. ACM Conf. on Object-Oriented Programming Systems, Languages and Applications, pages 391{405, 1986. [13] Bertrand Meyer. Object-oriented Software Construction. Prentice Hall International, 1988. [14] Jens Palsberg and M. Schwartzbach. Type substitution for object-oriented programming. In N. Meyrowitz, editor, Proc. ACM Conf. on Object-Oriented Programming Systems, Languages and Applications, pages 151{160, October 1990. [15] J. Rumbaugh. Controlling propagation of operations using attributes on relations. In N. Meyrowitz, editor, Proc. ACM Conf. on Object-Oriented Programming Systems, Languages and Applications, pages 285{296, September 1988. [16] J. Shilling and P. Sweeney. Three steps to views: extending the object-oriented paradigm. In N. Meyrowitz, editor, Proc. ACM Conf. on Object-Oriented Programming Systems, Languages and Applications, pages 353{361, October 1989. [17] Alan Snyder. Encapsulation and inheritance in object-oriented programming languages. In N. Meyrowitz, editor, Proc. ACM Conf. on Object-Oriented Programming Systems, Languages and Applications, pages 38{45, September 1986. [18] A. Taivalsaari. Object-oriented programming with modes. In European Conference on Object-Oriented Programming, 1992. Submitted. [19] David Ungar and R. Smith. SELF: the power of simplicity. In N. Meyrowitz, editor, Proc. ACM Conf. on Object-Oriented Programming Systems, Languages and Applications, pages 49{70, 1987. [20] F. Wolinski and J.-F. Perrot. Representation of complex objects: multiple-facets with part-whole hierarchies. In P. America, editor, Proceedings of the 1991 European Conference on Object Oriented Programming, pages 288{306, Springer, 1991. 7
CLASS Reservation component reservationNumber: ReservationNumber; associate passenger: Passenger; associate ight: ActualFlight; component seat: SeatNumber; ENDCLASS;
Figure 1: A Class for Reservations CLASS Passenger component name: String; component street: String; component city: String; ... component reservations: Set[Reservation]; ENDCLASS;
Figure 2: A Class for Passengers CLASS Flight component ightNumber: FlightNumber; associate carrier: Carrier; associate plane: Plane; component departure: Event; component arrival: Event; component frequency: Frequency; ENDCLASS;
Figure 3: A Class for Flights
8
CLASS ActualFlight component seatingDescription: SeatingDescription; component date: Date; component gate: GateNumber; associate ight: Flight; associate plane: ActualPlane; ENDCLASS;
Figure 4: A Class for Actual Flights CLASS Plane component planeName: PlaneName; component seatingDescription: SeatingDescription; component cruisingSpeed: Speed; ENDCLASS;
Figure 5: A Class for Types of Aircraft CLASS ActualPlane; component planeId: PlaneId; component nickName: String; associate plane: Plane; associate owner: Carrier; ENDCLASS;
Figure 6: A Class for Actual Aircraft Carriers = Set[Carrier]; Passengers = Set[Passenger]; Planes = Set[Plane]; Frequency = Set[Day]; ActualFligths = Queue[ActualFlight]; FlightNumbers = Set[FlightNumber];
Figure 7: Collections 9
