An Aggregation Model and its C++ Implementation

An Aggregation Model and its C++ Implementation  Manuel Kolp

Alain Pirotte

Universite catholique de Louvain, IAG-QANT 1 Place des Doyens, 1348 Louvain-La-Neuve, Belgium, e-mail: [email protected], [email protected]

Abstract

Object-oriented conceptual models strive to capture more semantics in order to better represent requirements of real-world applications. Aggregation is a powerful construct for semantic modeling. Intuitively, it relates a composite object to its component objects. This paper presents a new version of aggregation, with a generalized version of cardinality constraints and a new subcategorization of part relationships, with an associated transitivity rule. An implementation in C++ is also presented.

Keywords: Object-Oriented Conceptual Modeling, Aggregation, Part-Whole Relationship, C++

1 Introduction There is general agreement on the need for better modeling tools to handle the complexity of realistic applications. In recent years, the object-oriented paradigm has gained popularity in various modeling domains including database systems, World Wide Web and network applications, hypertext, multimedia and CAD/CAM systems, distributed computing, and sophisticated man-machine interfaces. Object-oriented application development methods (e.g., [1, 3, 21]) have led to new ways of thinking about problems with models organized around real-world concepts. The nesting of objects is a powerful construct of object orientation; however, it does not necessarily imply an explicit relationship between aggregated objects. Making aggregation, the semantic notion that an object is a part (component) of another object (composite), explicitly available as a rst-class construct enhances the expressiveness of object models. Surprisingly, only a few object-oriented systems and languages (e.g., SHOOD [6], VODAK [8], ORION [10], TELOS [19]) provide it as rst-class primitive. This paper presents a new simple and powerful version of aggregation and implements it as a hierarchy of C++ classes. The paper is structured as follows. Our aggregation model is described in Section 2. We explain the key aspects of our C++ implementation in Section 3. Finally, conclusions can be found in Section 4.

2 Our Aggregation Model Conceptual object modeling consists in precisely describing application domains for purposes of understanding and communication. Recent research has made possible more adequate conceptual models by precisely de ning classical abstractions, like aggregation, and by identifying new abstractions, like materialization [20].  This work is part of the YEROOS (Yet another project on Evaluation and Research on Object-Oriented Strategies) project, principally based at the University of Louvain. See http://yeroos.qant.ucl.ac.be.

1

Aggregation is generally de ned as an abstraction mechanism by which a relationship between objects is considered a higher-level (aggregate) object [17, 22]. In fact, two versions of abstraction coexist in the literature:  

the general version, through which an entity is analyzed in terms of its constituent parts. For example, a relation schema in the relational model is an aggregate of (attribute-domain) pairs. a relationship with additional speci c semantics to characterize various kinds of dependencies between parts, or component objects, and aggregates, or composite objects [10]. This richer version is sometimes called part-whole [23] or simply part relationship [7].

This paper is concerned with the second version, that we will call Part Relationship. It is de ned as a binary relationship and noted (see Figure 1(a)) as a straight line with a diamond on the side of the composite. For example, Figure 1(b) shows three part relationships, between components Editorial, Article, and Picture, and composite Newspaper. The rest of Section 2 presents the main ideas of our aggregation model. A more thorough discussion can be found in [13]. U M +

Composite Class

Uniclass Derived Attribute

Newspaper

Multiclass Derived Attribute title publisher date

Aggregation operator

nb_of_words + M (cps dependency, cps exclusiveness)

(0,1)

(0,n)

(0,n)

(cpn dependency, cpn exclusiveness)

(1,X1) Editorial

Component Class

nb_of_words

(0,X1)

(0,n)

Article

Picture

nb_of_words

description

date U

(a)

(b)

Figure 1: The Part Relationship

2.1 Exclusiveness/Sharing and Dependence/Independence

Relationships in semantic models are usually annotated with cardinalities (two pairs of numbers) that express minimality and maximality constraints for related objects. We generalize usual cardinalities to model two dimensions of part relationships: exclusiveness/sharing and dependence/independence. Variants of these constraints can bear on several part relationships involving the same composite or component. Thus each part relationship will be annotated with two pairs (cps dependence, cps exclusiveness) and (cpn dependence, cpn exclusiveness), that can be more general than plain numbers (see below), to model the dimensions of dependence and exclusiveness, for the composite class and the component class, respectively (see Figure 1(a)).

2.1.1 Exclusiveness/sharing noted on a single part relationship A rst group of constraints is de ned on the component class of a single part relationship : either they strictly concern and only (in the case of global sharing) or they concern , , and the set of all other part relationships where participates as a component, without referring explicitly to individual part relationships in this set (in the case of global exclusiveness). C pn

C pn

Pr

Pr

C pn

Pr

C pn

2









Component local exclusiveness / global sharing : any component cpn is related through P r to at most one composite cps. The constraint is noted as \cpn exclusiveness = 1" (see Figure 1(a)). For example, in Figure 2(a), each article is part of at most one journal. The constraint does not preclude cpn to be be related to another composite via another part relationship. Thus, the same article, that is part of a journal, could also be part of a compilation, provided of course that all other constraints are satis ed. Component local sharing / global sharing : a component cpn can be related to more than one composite through P r, while allowing, as in the previous constraint, cpn to be related to other composites via other part relationships. Thus, this is the unconstrained case noted as \cpn exclusiveness = n". For example, in Figure 2(b), an article can belong to any number of compilations and this does not constrain the participation of the article as component in other part relationships. Component local exclusiveness / global exclusiveness : every component cpn can be related to at most one composite via P r, and cpn cannot participate as a component in any other part relationship. This is noted as \cpn exclusiveness = X 1". For example, in Figure 2(b), if an article appears in some proceedings, then the article cannot appear in any journal or compilation. Component local sharing / global exclusiveness : a component cpn can be related to several composites via P r, but that relationship excludes participation of cpn as a component in any other part relationship. This is noted as \cpn exclusiveness = X n". For example, in Figure 2(c), a given instance of Binary (i.e., a program) can belong to any number of instances of Dos Software but that excludes its belonging to any instance of Unix Software, and conversely.

Compilation

Journal

Proceedings

Compilation

Journal

Dos Software

Unix Software

(0,1) (0, n)

(0, 1)

(OR1, X1)

(OR1, n)

Article

Article

(a)

(b)

(1, Xn )

(1, Xn )

Binary (c)

Figure 2: Exclusiveness and sharing Similar constraints can be de ned for composite classes. They are not indicated in Figure 2, nor in subsequent examples, to keep them simpler.

2.1.2 Exclusiveness/sharing constraints on several part relationships A second group of constraints bear on two part relationships 1 and 2 with the same component class and with composite classes 1 and 2 , respectively. Pr

C pn



C ps

Pr

C ps

Component XOR local exclusiveness / global sharing : any component cpn of C pn is related to at most one instance of C ps1 or C ps2 via P r1 or P r2 . There is no constraint on other part relationships with C pn as component. This constraint is noted as \cpn exclusiveness = X OR" for both P r1 and P r2 . For example, in Figure 3(a), an article can appear in one newspaper or in one weekly, and in any number of compilations.

3



Component XOR local exclusiveness / global exclusiveness : any component cpn is related to at most one instance of C ps1 or C ps2 via P r1 or P r2 , and cpn does not appear in any other part relationship as a component. This is noted as \cpn exclusiveness = X ORX " for both P r1 and P r2 . For example, in Figure 3(b), an article can appear in one newspaper or in one weekly, and, if it does, it is not linked to any instance of Unpublished. Newspaper

Compilation

Weekly

Newspaper

Unpublished

(0,n) (0, XOR)

Weekly

(0,n) (0, XOR)

(0, XORX)

(0, XORX)

Article

Article

(a)

(b)

Figure 3: XOR and XORX exclusiveness 



Component XOR local sharing / global exclusiveness : cpn instances are not constrained in their participation as components in P r1 or P r2 , but they do not participate as component in any other part relationship. This is noted as \cpn exclusiveness = ORX " for both P r1 and P r2 . For example, in Figure 4, a given instance of Binary (i.e., a program) can belong to any number of instances of Dos Software or of Windows Software, but that excludes its belonging to any instance of Unix Software, and conversely (because cpn exclusiveness = Xn for the part relationship between Binary and Unix Software). Component XOR local sharing / global sharing is the same as component local sharing / global sharing (the unconstrained case) of Section 2.1.1. Dos Software

Unix Software

Windows Software

(0,Xn) (0, ORX)

(0, ORX)

Binary

Figure 4: OR local sharing Similar constraints can be de ned for composite classes.

2.1.3 (In)dependence on a single part relationship  

Component independence : this is equivalent to a null minimal cardinality (optional participation) and is noted \cpn dependence = 0". For example, in Figure 2(a), an article can or cannot be part of a compilation Component dependence : this is equivalent to a minimal cardinality = 1 (mandatory participation) and is noted \cpn dependence = 1". For example, in Figure 2(a), each article belongs to at least one journal.

Composite independence and composite dependence are similarly de ned for composite classes.

4

2.1.4 (In)dependence on two part relationships 

Component OR dependence : for two part relationships P r1 and P r2 , any component cpn participates in at least one instance of P r1 or of P r2 . This is noted as \cpn dependence = OR1" for both P r1 and P r2 . For example, in Figure 2(b), every article belongs to at least one journal and/or at least one instance of Proceedings.

Composite OR dependence is similarly de ned for composite classes.

2.2 Subcategorization of Part Relationships

Winston et al. [23] analyzed part relationships, that they call meronymic relationships, into seven subcategories: 1) component { object; 2) feature { event; 3) member { collection; 4) portion { mass; 5) phase { activity; 6) place { area; 7) stu - object. Although such a subclassi cation appears useful in cognitive sciences or linguistics, it relies on pragmatic and cultural dimensions that are not easily formalizable with current object models. In our model of part relationship, we distinguish three semantic types, called part relationship, part association, and part recursion; they are organized in a specialization hierarchy as shown in Figure 5. In other words, all part recursions are also part associations, which in turn are all part relationships. The right part of Figure 5 shows examples of structures of the semantic types at the left. Part Relationship

Part Association

Part Recursion

Direct Superclass

Figure 5: A simple hierarchy for part relationships Part relationship is the relationship studied in Section 2.1. The same composite can be related to several components. For instance, a newspaper can be composed of editorials, articles, and pictures (see Figure 1(b)). Part association, thus named after [2], specializes part relationship by relating a composite to a collection of components of the same class. In other words, a part association models the case where a class participates as a composite in a single binary part relationship. For example, in Figure 2(a), a compilation is composed of articles. Part recursion specializes part association: not only component objects but also composite objects belong to the same class. For example, a program could be described as composed of (sub)programs.

5

2.3 Re exivity, Symmetry, Transitivity of Part Relationships

The part relationship can also be characterized as to whether it possesses the classical properties of re exivity, symmetry, and transitivity. The part relationship is instance-irre exive, as an object cannot be composed of itself nor belong to itself. Part recursion is class-re exive, as an object 1 of a class can be composed of { or be part of { objects 2 , ..., i also belonging to . Part relationship is antisymmetric for instances and classes. Transitivity of the part relationship is de ned in the obvious manner: if (A is part of B) and (B is part of C), then (A is part of C). Few systems support any kind of transitivity. In Winston's subclassi cation (Section 2.2), a meronymic relationship is transitive when \A is part of B" and \B is part of C" belong to the same subcategory of meronymic relationship. This idea has inspired two object-oriented systems: SHOOD [6] and TELOS [16]. obj

obj

obj

C

C

Our version of part relationship (Figure 5) enjoys a stronger support of transitivity: 



\upwards" transitivity is valid: if (a is part of b) 2 P C at1 and (b is part of c) 2 P C at2 and P C at1 < P C at2 , then (a is part of c) 2 P C at2 where P C at1 < P C at2 means that P C at1 is a subclass of P C at2 in the specialization hierarchy of Figure 5; transitivity within part relationship is also valid.

Thus, for example:   

if a ray is part of a wheel (part relationship) and the wheel is part of a bicycle (part relationship), then the ray is part of the bicycle (part relationship); if a (sub)program is part of a program (part recursion) and the program is part of a package (part association), then the (sub)program is part of the package (part association); if a sentence is part of an article (part association) and the article is part of a newspaper (part relationship), then the sentence is part of the newspaper (part relationship).

However:  

if a hand is part of a musician (part relationship) and the musician is part of an orchestra (part association), it does not hold that the hand is part of the orchestra [16]; if a person is part of a sport club (part association) and the sport club is part of a recreational institution (part association), it does not hold that the person is part of the recreational institution [15].

2.4 Attribute Derivation

We de ne a mechanism for the derivation of attribute values in part relationships that is bidirectional, speci c, transitive dependent, and computable, as follows:  

bidirectional: attributes and their values can be derived and computed both upwards (from components to composites) and downwards (from composites to components); speci c (or optional): whether or not an attribute must be propagated is application speci c, and a generic mandatory mechanism is therefore inappropriate;

6

transitive dependent: the validity of attribute derivation is bound by the transitivity rules of the part relationship (see Section 2.3);  computable: an attribute value of a composite (or a component) can be modeled in terms an attribute value of several of its components (composites). Aggregate operators (e.g., +,-, *, min, max, avg, list) can be applied for computing the derived value from source values. Derived attributes can thus be characterized as uniclass or multiclass:  an attribute of a class C is said to be uniclass derived (UD) if its values are computed from attribute values of objects belonging to a single class C1 related to C by a part relationship;  an attribute of a class C is said to be multiclass derived (MD) if its values are computed from attribute values of objects belonging to classes C1 ; :::; Cn , and C and C1 ; :::; Cn are related by n part relationships with C as composite (resp., component) and C1 ; :::; Cn as components (resp., composites). Graphical notations for attribute derivation are illustrated in Figure 1(b). Derived attributes are quali ed as U (uniclass derived) or M (multiclass derived). Aggregate operators can qualify a derived attribute to indicate how values are computed from source attribute values. Thus, nb of words is an upwards multiclass-derived attribute of Newspaper. The value of nb of words for a Newspaper instance is computed as the sum of values of nb of words for related instances of Editorial and Article. Attribute date is a downwards uniclass-derived attribute in Editorial: its values are propagated downwards from Newspaper. 

3 A C++ Implementation of Part Relationships This section describes the general structure of our C++ implementation. A more complete description can be found in [4]. The implementation provides the following functions:  instantiation of part links between instances of related classes;  exclusiveness and dependence checking when instantiating a part link;  attribute and value derivation compatible with transitivity rules;  destruction of part links;  destruction of objects and related part links, with dependence checking. An application class participates in a part relationship by being declared as subclass of a special class that channels the necessary functionality to it. Thus, the following classes are de ned for the example of Figure 1(b): class Newspaper: public Cpn Set Newspaper f char * title; char * date; char * publisher; public: char * publ date() freturn date;g;g; class Editorial: public Cps Set Editorial f int nb of words; public: Editorial(int i)fnb of words=i;g; int Nbr words() freturn nb of words;g;g;

class Picture: public Cps Set Picture f char * description;g; class Article: public Cps Set Article f int nb of words; public: Article(int i)fnb of words=i;g; int Nbr words() freturn nb of words;g;g;

For example, class Newspaper, which is a composite in three part relationships, is declared as a subclass of a class Cpn Set Newspaper. The latter is a subclass of three classes (Cpn e n, Cpn a n, and Cpn p n), each corresponding to one of the part relationships. Each of these three classes is an instantiation of the Cps Cpn template class, which is the central class of our implementation. 7

The Cps Cpn template - Template class Cps Cpn provides instantiation, deletion, and con-

straint checking services to components and composites. Cps Cpn is instantiated for each application class that participates in a part relationship, by instantiating its three class parameters:   

c 1, the application (resp., composite or component) class; c 2, another application class (resp., component or composite) related to c 1 by a part relationship Pr; part rel, a class describing the speci c characteristics of Pr.

Instances of the Cps Cpn template are called Cps Pr (resp., Cpn Pr) when c 1 is instantiated as a composite (resp., a component) of part relationship Pr (see below). Class part rel serves to de ne an object Rel as data member of Cps Cpn. Member functions of Cps Cpn access the characteristics of part relationship Pr through Rel. Through CreateLink and DeleteLink, Cps Cpn calls functions Local Const() for checking the constraints of local exclusiveness and dependence, and Global Const() for global constraint checking. These functions set Boolean ags allowing or preventing CreateLink and DeleteLink to instantiate or delete a part link, depending on the current set of part links. Consider two application classes A and B (subclasses, respectively, of class Cps Set A and class Cpn Set B) related by a part relationship P A B. Two objects a 2 A and b 2 B dialog via their functions CreateLink to instanciate P A B. Constraints are checked, a and b exchange their adresses if there is no constraint violation; otherwise the instantiation process is aborted. Both objects dialog via their functions DeleteLink when destruction of the part link is requested. As for creation, constraints are checked and the deletion process is aborted if necessary to avoid constraint violation. Destructor ~Cps Cpn() applies deletion services for part links when objects are destroyed. template class Cps Cpn: public setf int NbrCpsOrCpn; boolean XORConst; boolean XConst; boolean ORConst; boolean Sharing; boolean Dep; void NbrCpsOrCpn+1(); void NbrCpsOrCpn-1(); boolean Glob Const(); boolean Local Const(); protected: ~Cps Cpn(); public: part rel Rel; boolean CreateLink(c 1 * ptr); boolean DeleteLink(c 1 * ptr);g;

// Set is a template providing set and list manipulation utilities // Number of composites (components) of an objet // // // Boolean ags for constraints // // // Keeps track of the number of composites or // components of a c 1 object // Global constraint checking // Local constraint checking // Characteristics of the (c 1{c 2) part relationship // Create a part link // Delete a part link

Classes Cps and Cpn - Template Cps Cpn provides its template instances Cps Pr and Cpn Pr

with generic functions for part relationships. Each Cps Pr (resp., Cpn Pr) class manages one part relationship Pr from the standpoint of a composite (resp., component). Uniclass-derived attributes are handled in Cps Pr and Cpn Pr. Computing values for a multiclass-derived attribute on all relevant part links requires accessing objects of several application classes, while each Cps Pr (resp., Cpn Pr) can only deal with a single composite (resp., component) class. Values of multiclass-derived attributes are computed by derived classes Cps Set A or Cpn Set A that can access all composites (resp., components) objects related to a component (resp., composite) object of an application class A. 8

class Cpn e n: public Cps Cpn f public: int Nbr words() // derive an MDA ~Cpn e n() fg;g; // on part relationship class Cpn a n: public Cps Cpn f public: int Nbr words() // derive an MDA on // one a part relationship ~Cpn a n() fg;g; class Cpn p n: public Cps Cpn f public: ~Cpn p n() fg;g;

class Cps n e: public Cps Cpn f public: char * date(); // derive an UDA ~Cps n e() fg; g; class Cps n a: public Cps Cpn f public: ~Cps n a() fg; g; class Cps n p: public Cps Cpn f public: ~Cps n p() fg; g;

The Cps Set and Cpn Set classes - Class Cps Set A (resp., Cpn Set A) of an object belonging

to an application class A is derived by multiple inheritance from all Cps (resp., Cpn) classes implementing binary part relationships in which A participates as composite (resp., component) class. They can thus manage all part relationships in which A participates as composite (resp., component) class, e.g., for MD attribute derivation or for global constraint checking. Thus class Cpn Set Newspaper is de ned for the example of Figure 1(b): class Cpn Set Newspaper: public Cpn e n, public Cpn a n, public Cpn p n f public: int Nbr words() // Derives a multiclass attribute freturn Cpn e n::Nbr words() + // from relevant part relationships Cpn a n::Nbr words();g; ~Cpn Set Newspaper() fg;g;

Classes Cps Set Editorial, Cps Set Article, and Cps Set Picture are de ned in a similar fashion.

The part relationship template - Each part rel class is derived from the part relationship tem-

plate; part rel de nes a speci c part relationship and supplies template Cps Cpn with the characteristics of that relationship through object Rel. template class part relationship f public: char * Cps Depend() freturn cps depend;g char * Cps Exclus() freturn cps exclus;g char * Cpn Depend() freturn cpn depend;g char * Cpn Exclus() freturn cpn exclus;g char * Transitiv Type() freturn transitiv type;gg;

// (In)dependence for composites // Exclusiveness/Sharing for composites // (In)dependence for components // Exclusiveness/Sharing for components // Transitivity type

For the example of Figure 1(b), classes part rel are as follows: class part newsp edit: public part relationship f short dummy;g; class part newsp art: public part relationship f short dummy;g; class part newsp pic: public part relationship f short dummy;g;

4 Conclusion This paper rst presented an original model for part relationships with the following features:   

bidirectionality with exclusiveness/sharing and dependence/independence constraints; generalization of these constraints taking several part relationships into account; re exivity, symmetry, and transitivity; 9



uni- and multiclass attribute and value derivation consistent with transitivity rules.

The paper then presented class interfaces for a complete support of part relationships in C++. The present work suggests many continuations. First, we are studying the formalization of other semantic links for object models. They include binary and n-ary relationships, aggregated relationships and conceptual cycles [14], generalization, and materialization [5, 20]. Second, we are studying metaclass and metaobject mechanisms in dierent systems such as CLOS [9], VML [11] or Logtalk [18]. This will help us de ne common metalevel speci cations for semantic link support and enhancements to object-oriented models. This will nally lead us to construct an integrated metamodel in order to propose a complete metalevel approach and implementation to enhance object models and systems with semantic relationships [12].

References [1] G. Booch. Object-Oriented Analysis and Design with Applications. Benjamin/Cummings, second edition, 1994. [2] M. Brodie and E. Silva. Active and passive component modeling: ACM/PCM. In T. Olle, H. Sol, and A. Verrijn-Stuart, editors, Information systems design methodologies: a comparative review, pages 41{91. North-Holland, 1982. [3] D. Coleman, P. Arnold, S. Bodo, C. Dollin, H. Gilchrist, F. Hayes, and P. Jeremaes. Object-Oriented Development: The Fusion Method. Prentice Hall, 1994. [4] F. Cornet and M. Kolp. Etude et implementation de l'agregation en C++. Technical Report YEROOS TR-96/10, IAG-QANT, Universite catholique de Louvain, Belgium, Dec. 1996. [5] M. Dahchour, A. Pirotte, and E. Zimanyi. Metaclass implementation of materialization. Technical Report YEROOS TR-96/06, Jan. 1996. Submitted for publication. [6] C. Djeraba and H. Briand. A design object concept. In Proc. Int. Symp. on Advanced Database Technologies and their Integration, Nara, Japan, October 1994, pages 97{104, 1994. [7] M. Halper, J. Geller, and Y. Perl. An OODB part relationship model. In Y. Yesha, editor, Proc. of the 1st Int. Conf. on Information and Knowledge Management, CIKM'92, Baltimore, USA, Nov. 1992. [8] M. Halper, J. Geller, Y. Perl, and W. Klas. Integrating a part relationship into an open OODB system using metaclasses. In Proc. CIKM'94, Gaithersburg, Maryland, 1994. [9] G. Kiczales, J. des Rivieres, and D. Bobrow. The Art of the Metaobject Protocol. MIT Press, 1991. [10] W. Kim and F. H. Lochovsky, editors. Object-Oriented Concepts, Databases and Applications. ACM Press, 1989. [11] W. Klas. VODAK V4.0 User Manual. Technical Report TR 910, Arbeitspapiere der GMD, Apr. 1995. [12] M. Kolp. A metaobject protocol for reifying semantic relationship into open systems. Technical Report YEROOS TR-97/08, IAG-QANT, Universite catholique de Louvain, Belgium, Mar. 1997. To appear in Proc. of the 4th Doctoral Consortium of the 9th Int. Conf. on Advanced Information Systems Engineering, CAiSE'97, Barcelona, June 1997 [13] M. Kolp and A. Pirotte. An aggregation object model. Technical Report YEROOS TR-96/09, IAG-QANT, Universite catholique de Louvain, Belgium, Mar. 1997. Submitted for publication. [14] M. Kolp and E. Zimanyi. Relational database design using an ER approach and Prolog. In S. Bhalla, editor, Proc. of the 6th Int. Conf. on Information Systems and Management of Data, CISMOD'95, LNCS 1006, pages 214{231, Bombay, India, Nov. 1995. Springer-Verlag.

10

[15] R. Motschnig and J. Kaasboll. Part-whole relationship categories and their application in objectoriented analysis. In Proc. of the 5th International Conference on Information System Development, ISD'96, Sept. 1996. [16] R. Motschnig-Pitrik. The semantics of parts versus aggregates in data/knowledge modelling. In C. Rolland, F. Bodart, and C. Cauvet, editors, Proc. of the 5th Int. Conf. on Advanced Information Systems Engineering, CAiSE'93, LNCS 685, pages 352{373, Paris, France, June 1993. SpringerVerlag. [17] R. Motschnig-Pitrik and J. Mylopoulos. Classes and instances. International Journal of Intelligent and Cooperative Information Systems, 1(1):61{92, 1992. [18] P. Moura and E. Costa. Logtalk: Object-oriented programming in Prolog. University of Coimbra, Portugal, Sept. 1994. [19] J. Mylopoulos. Conceptual modeling and Telos. In P. Loucopoulos and R. Zicari, editors, Conceptual modeling, databases, and CASE, chapter 2, pages 49{68. Wiley, 1992. [20] A. Pirotte, E. Zimanyi, D. Massart, and T. Yakusheva. Materialization: a powerful and ubiquitous abstraction pattern. In J. Bocca, M. Jarke, and C. Zaniolo, editors, Proc. of the 20th Int. Conf. on Very Large Databases, VLDB'94, pages 630{641, Santiago, Chile, 1994. Morgan Kaufmann. [21] J. Rumbaugh, M. Blaha, W. Premerlani, F. Eddy, and W. Lorensen. Object-Oriented Modeling and Design. Prentice Hall, 1991. [22] J. Smith and D. Smith. Database abstractions: aggregation and generalization. ACM Trans. on Database Systems, 2(2):105{133, June 1977. [23] M. Winston, R. Chan, and D. Herrmann. A taxonomy of part-whole relations. Cognitive Science, 11:417{444, 1987. All appropriate organizational approvals for the publication of this paper have been obtained. If accepted, the author(s) will prepare the nal manuscript in time for inclusion in the conference proceedings and will present the paper at the conference.

11