multiple object representations - Semantic Scholar

Download PDF
5 downloads 0 Views 65KB Size Report
Comment
round-cornered boxes and instances by rectangles. Class names are in boldface. AIRCRAFT. ENGINE. FLIGHT. ELECTRIC. HYDRAULIC. PRESSURIZATION.
MULTIPLE OBJECT REPRESENTATIONS

Nguyen G.T, D. Rieu IRIMAG° Laboratoire de Génie Informatique IMAG-Campus BP 53 X 38041 GRENOBLE Cedex France Tel : (33) 76.51.45.75 e-mail : [email protected] fax : (33) 76.44.66.75

Abstract In the object-oriented paradigm, objects are instances of the conceptual entities that describe their structure and behavior i.e, the classes. Recent applications of object-oriented programming languages and databases in areas like engineering design and genetics have demonstrated the limits of this assumption. Object instances cannot always conform to their class definitions. They may evolve during the application lifetime. Further, a class may be only one specific object representation among several others required by the users. This paper relaxes some constraints usually associated with instantiation mechanisms. An object instance is no longer considered as a perfect representative of a specific class. It can bear distorsions with its class definition. This is called here flexible instantiation. An instance can also belong simultaneously to different classes. These classes need not be related by any direct or indirect specialization relationship. This is called here multiple instantiation. It is shown how classification mechanisms complement adequatly multiple instantiation. The characteristics of such a classification mechanism are described. It is implemented for an object-based knowledge representation model called SHOOD. °IRIMAG is a research consortium involving INRIA, CNRS, INPG, UJF and ENSL.

1. INTRODUCTION Current research and implementations of objectoriented database systems result from the effective combination of object-oriented programming and database techniques [KIM90, UNL90]. While the mutual enhancement of each technology using the features of one another is a promising approach, few innovative and outstanding concepts have yet emerged from their encounter. Existing applications like engineering design still raise challenging issues [GIA90]. They are sometimes qualified "new" or "next-generation" applications because they emerged only recently in particular domains like databases. Examples problems concern type-checking, incompleteness, inconsistency, object evolution and multiple representations [SIL90, IMI91, BAN87, ABI91]. Engineering design applications for example require that the design objects evolve during the application lifetime [RIE86]. The evolution is twofold. First, the object values evolve over time because refinements in the object definitions increase the accuracy of their attribute values. Second, the object structure may also evolve because designing an object often implies the

redesign or reuse of existing artifacts [NGU91b]. Furthermore, design objects require various technical representations e.g, pressurization, hydraulic and electric power generation, flight management systems, and engine monitoring systems for aircraft (Figure 1). These object representations are complementary. They may be added, refined or deleted depending on the particular design development phase and the current needs of the designers. In all the figures included in this paper, classes are depicted by round-cornered boxes and instances by rectangles. Class names are in boldface. AIRCRAFT AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAAAAAAAAAA AAAAAAAA AAAA AAAAAAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAAAAAAAAAA AAAA

ENGINE FLIGHT ELECTRIC MONITORINGMANAGEMT POWER

HYDRAULIC POWER

AAAAAAAA AAAAAAAA REPRESENTATION

PRESSURIZATION

Figure 1. Multiple representations for aircraft. Recent advances in engineering applications stress the need for powerful and flexible integration mechanisms. Among the issues emphasized by theoreticians and practitioners is the requirement for a data and knowledge base management system able to support the huge information systems encountered : "databases serve as the backbone of computer-aided design systems"[SIL90]. Techniques developed primarily for software engineering and databases are now becoming widely accepted. Their ability to support also engineering design applications has raised the interest of designers in specific areas e.g, mechanical CAD/CAM. This paper proposes an approach based on objectoriented concepts and knowledge representation techniques found in AI to model design objects. It relaxes some constraints found in current modeling paradigms to adapt them to the specifics of engineering design. This study is based on experience gained in mechanical CAD/CAM for the design and implementation of an object-based

knowledge representation model called SHOOD [NGU91b]. It elaborates on object-oriented programming languages as found in software engineering and knowledge representation languages as found in AI. It is an attempt to overcome current limitations in the former and merge them with specific advantages of the latter to support adequatly engineering design applications. We therefore do not necessarily conform to some stringent requirements of software engineering applications e.g, type-checking, object stability, completeness and consistency. Our approach contrasts dramatically with the latter. For example, objects may evolve over time. They may bear distortions with respect to the class definitions e.g, they may be incomplete and inconsistent [IMI91]. Further, the evolution of the objects may concern their structure as well as their values. Hence there is a need for classification mechanisms to monitor the modifications. There must be a way for the programmer to construct the types appropriate for his application. The need for more flexible type systems has been one of the major forces in the development of object-oriented databases [SIL90]. To some extent, recent work on schema evolution [BAN87, CAS90, NGU91b], version management [AHM91] and views [ABI91] in object-oriented database systems address this issue. In existing object-oriented paradigms, an instance is the exact representative of only one class [GOL83, KEE89]. The instantiation graph is a tree. The object-oriented paradigm implements this fundamental assumption together with other concepts like inheritance, encapsulation and message passing. Recent work has shown however that instances cannot always be exact representatives of their classes [NGU91a, KOT88]. They may bear distorsions with respect to the templates defined by the classes. They may also evolve and need to migrate from one class to another, because of changing values or structure [CAS90, KIM90, NGU89a].

Taking into account these observations, this paper relaxes some of the usual assumptions associated with existing instantiation mechanisms. It is assumed in the following that : - an instance may be a representative of several classes simultaneously, - an instance is not necessarily an exact representative of the classes of which it is an instance. The first point is called hereafter multiple instantiation. The second point is called flexible instantiation. We use an explicit instantiation mechanism, which departs from the instantiation incurred by the specialization relationship e.g, if the class Amphibian is a subclass of Aircraft, then an instance of the class Amphibian is also an instance of the class Aircraft. This last form is called here implicit instantiation. To implement explicit instantiation, it is required that the users request instances to be "attached" to the individual classes by specific statements. The model SHOOD defined in the sequel implements set inclusion inheritance. It also implements multiple inheritance and multiple instantiation, as defined above. Multiple instantiation allows here instances to be representatives of classes which are not necessarily related by a specialization relationship. Different semantics may therefore be attached to the instances, depending on the class considered. For example, my old DC-3 is an aircraft. But, it is also a collection item (Figure 2). The classes may therefore define different representations for the objects. They are sometimes called "perspectives", "aspects" or "views" in the literature [ABI91, CAR90, MAR90, RIC91, STE86]. My DC-3 may or may not be in flying condition. This is relevant to the aircraft representation only, and not to the collection representation. For example, this last one may bear historical data only. MUSEUM COLLECTION

AIRCRAFT

instance-of

DC-3

Figure 2. Multiple instantiation.

Using multiple instantiation, an instance may be a representative of several classes simultaneously. In contrast with related work [PER90, SCH88, SCI89, VAN89], our approach emphasizes on classification mechanisms required for the management of evolving, incomplete and inconsistent objects. It therefore combines objectoriented and knowledge representation technologies. Further, there is no need to introduce new concepts and operations in the model, such as "roles" and "rules" [PER90]. These are required only when the instances are specifically attached to one particular class where they may bear different semantics carried by the roles. This is not our definition of multiple instantiation. In SHOOD, representations are modeled by classes : they are first-class objects. Our notion of multiple instantiation is therefore different : an instance can be simultaneously attached to several representation classes by "instance_of" relationships. Each representation corresponds to a specific class definition. This conforms to the fundamental concepts in the object-oriented paradigm which is actually extended by relaxing the single instantiation assumption. Using abstract data types and type conformity, a similar result is achieved by "aspects" in [RIC91], without however making use of object-oriented concepts. The emphasis is here on a unified approach which is used to combine : - classification mechanisms and - multiple instantiation to support multiple representations for evolving objects. In particular, it is shown that multiple object representations are straightforwardly implemented by multiple instantiation (Section 2). This approach has the fundamental property of preserving object identity throughout representations. A classification mechanism implemented for the model SHOOD is described in Section 3. Section 4 is a conclusion.

2. OBJECT REPRESENTATIONS

The characteristics of the objects of interest to a community of designers may vary for various individuals and depend also on time for a particular user. My DC-3 aircraft is a collection item and a flying machine. This implies that servicing has to be done by certified mechanics on various parts of the engines depending on their total flying hours, hence on time. In contrast, the historical data stored in the collection representation is stable and is not likely to change over time. The co-existence of multiple representations of the objects raises new problems : - preserving object identity between representations, - management of object evolution among represen-tations, - maintenance of semantic relationships between representations. Depending on the authors, several approaches have been explored to implement multiple object representations. They may call for explicit concepts e.g, adding specific notions to a data model. For example, "representation relationships" have been proposed in the literature [CAR90], as well as "roles" [PER90] and specific algorithms to maintain parallel class hierarchies [MAR90]. Another approach is to use only concepts that already exist in the data model considered. This implies an implicit definition of object representations. It elaborates on existing notions e.g specialization, aggregates and multiple instantiation. There is no need for specific operators to define and manipulate representations. This greatly simplifies the concepts and mechanisms involved in the implementation of the data model. This approach is used for SHOOD. The use of multiple instantiation for multiple object representations is addressed in the next section (section 2.1). The following section discusses the use of existing concepts. It focuses

on specialization and aggregates (section 2.2). The respective merits of aggregates, specialization and multiple instantiation are then discussed (sections 2.3 and 2.4). 2.1 Multiple instantiation Most object-oriented programming languages do not actually implement implicit instantiation [GOL83]. This is usually dependent on the semantics of the inheritance relationship implemented : the most common form is the structural and behavioral inheritance, by which sub-classes inherit the structure and behavior of their super-class(es). Other form of inheritance exist, among which is set inclusion and specialization. Using specialization, sub-classes may also refine the constraints imposed on attributes. With set inclusion, the sub-classes represent sets of instances which are sub-sets of their super-class(es). This last form prohibits exceptions. It also prohibits attribute redefinition, except by constraint refinements. We assume that implicit instantiation is given for free using the set inclusion semantics of inheritance. We are interested here in the explicit form of instantiation i.e, instances can be simultaneously attached to classes which are not related by a specialization relationship. Multiple instantiation supports in our approach different semantics attached to the same objects. It therefore enhances the semantic representation available to the classes because the various representations of a particular object may bear informations which have - at least at first sight - little in common. For example the aircraft structural design includes the descriptions of the various fuselage sections and the wings. This defines a particular aircraft representation. The computerized flight management system for the aircraft includes in turn a set of redundant computers which have nothing in common with the previous representation, except that, when flying, the computers output signals that will drive the aircraft controls through actuators. Note that these actuators are usually hydraulic or electric systems which are not described in either of the

above representations. There is therefore no explicit requirement that both representations be related, so far. They are parts however of the same aircraft being designed. Relating an aircraft instance "a1" to both representations by the usual "instance_of" relationship clearly preserves the object identity (Figure 3). Further, it allows the various semantics corresponding to the structural design and to the computerized flight management system of "a1" to be attached to the relevant object. In this particular example, no explicit relationships need to be maintained between the two representa-tions. Should there be such relationships, one might however require that the semantics of the relationships be explicitly defined in both representations. This requires that a new class be instance_of FLIGHT STRUCTURE

MANAGEMT

instance

a1

class

Figure 3. Preserving object identity by multiple instantiation. created to keep both the representations and their relationships. The latter may be design and constraints verification programs for example. Such a class is called hereafter an interrepresentation class. These are easily implemented by specific aggregates and specialized sub-classes. This is discussed in the next section (section 2.2). 2.2 Specialization and aggregates An crude approach to implement multiple object representations is to define a common sub-class that will hold the corresponding instances. The super-classes of this inter-representation class are the classes that define the various representations. If implicit instantiation is available, this also preserves object identity. Another advantage here is that this approach allows to locate easily - in the common inter-representation class - the semantic relationships existing between the different

representations.This simplifies somewhat the class graph. In the example, an inter-representation class called Inter_Rep_ Aircraft is defined as a common sub-class for the classes Structure and Flight_Management. It holds the constraints and relationships connecting both representations. It is our opinion however that this is a misuse of the specialization relationship. Indeed, an aircraft is not a sub-class of its structural or electronic representations. These should be better defined as components of the aircraft. The latter is a large composite object which includes, among others, a structural part and lots of avionics sub-parts. If available, this can be implemented by a composition relationship [NGU91a]. Specialization preserves object identity. Aggregates however do not preserve object identity. The aggregate classes define interrepresentation classes. Each of their attributes models a specific representation e.g the attributes f and s. The domain of these attributes are the classes that define each representation e.g Flight_management and Structure. An object instance X that belongs to an aggregate class is therefore an aggregate of references to the particular instances Y, Z, ... defining the object representations. These references are object identifiers. Aggregates cannot therefore implement object identity. 2.3 Discussion Nonetheless, aggregates bear specific advantages. First, the various representations may be defined independently of each other. This advantage is also patent with multiple instantiation. The class graph can therefore be made simpler and easier to maintain. This departs from the specialization approach, where sub-classes can be defined to refine the super-classes (the standard usage of specialization) but also to group representations. In this case, the sub-class is an interrepresentation class. This is quite confusing. It is our opinion that this approach should be avoided. In contrast, aggregates can be used while keeping the original semantics of specialization i.e refining

super-classes. This has an interesting impact on the effectivness of classification mechanisms. The simpler the specialization graph, the better the classification efficiency, because it is not disturbed by the inter-representation classes. Another advantage of aggregates is the following. If a design choice is made to model the various representations by specific classes, aggregates will preserve this choice. This is not the case for specialization because all the attributes are then flattened in a single inter-representation class. One shortcoming of aggregates is the opportunity for unknown and inapplicable values to exist. Unknown values are not per se a critical issue in knowledge representation languages [STE86]. Neither is it in SHOOD. This model supports incomplete objects. It also keeps track of the current completeness of each individual instance for classification purposes.

3. CLASSIFICATION

A classification mechanism supports evolving instances and evolving classes in SHOOD. It can be shown that it is also a powerful means to help implementing reflexive object-oriented models [MCL88]. For example, methods in SHOOD are modeled by classes. They are instances of a particular meta-class called META_METHOD. The methods are organized in a graph and their position depends on the types of their parameters as well as pre and post conditions. For example, the method "integer_difference" is a sub-class of "number_difference" which is in turn a sub-class of "difference". Invoking the method "difference(3,2)" first creates an instance representing the invocation and then triggers its classification in the most appropriate sub-class, i.e "integer_difference" (Figure 4). META_METHOD

2.4 Aggregates plus multiple instantiation As mentioned above, multiple instantiation is effective when the representations have no semantic relationships. This is counter intuitive but the aircraft example in Section 2.1 gives such an example. It is also interesting if the users focus on individual instances and not on whole classes. This is usually the case in engineering design environments. If either of these requirements is not met, aggregates can be combined with multiple instantiation. The existence of inapplicable values is then modeled in SHOOD by the type constructors "AND", "OR". If type A and type B are defined, the type "A OR B" denotes the union of the sets of instances of type A and of type B. An aircraft is the union of its structural and electronic representations : "electronic OR structural".

class

DIFFERENCE

instance MATRIX_DIFFERENCE

NUMBER_DIFFERENCE

sub-class INTEGER_DIFFERENCE

instance_of DIFFERENCE(3,2)

Figure 4. Classification of method invocations. 3.1 Potential and prohibited classes Existing classification mechanisms usually characterize classes in three categories : - admissible classes for which a given instance verifies all the constraints, - potential classes for which no decidable constraint is violated, but where a given instance may bear unknown values, - prohibited classes for which instances bear constraint violations. This characterization assumes that no decidable constraint - i.e one for which all arguments are known - may be violated. This assumption is

however too stringent for engineering design applications. The design objects evolve over time. They may be inconsistent and incomplete for variable periods of time [RIE86, NGU89]. Further, when facing incompleteness and inconsistencies, the system reactions cannot be standardized [KOT88]. With the model SHOOD, constraints on objects may be defined as "strong" and "weak". A strong constraint may not be violated. For example, type constraints for attributes are strong. Weak constraints may be violated. Decidable constraints have all their arguments valued. In contrast, undecidable constraints have one or more unknown arguments. When these arguments are attributes, undecidable constraints simply characterize incomplete objects. This leads to the notion of "optional" attributes. Attributes may be mandatory or optional in SHOOD. When incomplete objects are manipulated, the designers may want to track their exact status with respect to completeness and consistency. We therefore provide only two characterization for the classes : - potential classes where no strong constraint is violated, - prohibited classes where one or more strong constraint is violated. Intances may be attached to potential classes only. Tracking the instances uses the notion of relevant structures. This is described in Section 3.2. 3.2 Classification criteria Classification mechanisms are designed to answer such questions as : - is it possible to attach instance X to class C ? - which are the most specific sub-classes of C to which instance X can be attached ? The "best" classes must therefore be selected among all potential classes. For a given class C, each instance X has three corresponding informations attached : - a relevant structure, - an inconsistency degree, - an incompleteness degree.

Informally, relevant structure are meaningful although partial definitions corresponding to incomplete objects that are allowed to belong to potential classes [NGU89a]. Each class C possesses a set of relevant structures which are generated automatically when the class is defined and modified. Each relevant structure represents a partial object definition. This is used to track object evolution. All instances are attached to exactly one relevant structure at all times. It is the relevant structure for which all attributes are valued and all strong constraints hold. Each instance is also attached incompleteness and inconsistency degrees. They reflect the percentage of unknown optional attributes and weak constraints that are violated by the instances, respectively. If O is the number of optional attributes in the definition of class C and Ox the number of optional attributes in C valued by instance X, the incompleteness degree of X with respect to C is : ICOMP (C, X) = (O - Ox ) / O. If W is the number of weak constraints in the definition of class C and Wx the number of such constraints that hold for instance X, the inconsistency degree of X with respect to C is : ICONS (C, X) = ( W - Wx ) / W. The smaller ICOMP(C, X), the more complete is instance X. The smaller ICONS(C, X), the more consistent is X. The triplets characterizing all instances are called classification criteria. They give to the designers indications on the opportunity to attach the instances to specific classes. Basically they represent the distorsions of the instances with respect to these classes. This is complemented by classification conditions that may help in automating the classification process.

4. CONCLUSION

The object-oriented paradigms implemented by current programming languages, database systems and software development environments rely on

fundamental concepts like classes, meta-classes, inheritance, specialization, methods and message passing. The instantiation mechanism has not yet been emphasized. It is often simple and straightforward : an instance belongs to exactly one class that defines its structure and behavior. This definition is very stringent and instances must conform to their class definition. Recent developments of the object-oriented approach in applications like engineering design and genetics stress the need for new functionalities. Among them is the requirement for evolving objects that do not always conform strictly to the class definitions. Further, another important issue raised by these applications is the notion of multiple representations. This paper relaxes the usual one-to-one mapping between instances and classes. Instances are allowed to belong simultaneously to several classes. These classes are not required to be related by any direct or indirect specialization relationship. The outstanding benefit of this approach is a very simple and consistent implementation of multiple object representations. An important side-effect is also that object identity is always preserved. This supports therefore a very clean and unifying implementation which is consistent with the fundamental concepts in usual object-oriented approaches. It provides a powerful and flexible mechanism required by many realistic applications, without incurring the cost of new specific concepts added to the object-oriented frameworks. It is shown how multiple instantiation combined with classification mechanisms support the evolution of the objects throughout representations. This is another important requirement for engineering design applications where object definitions and values are subject to change. Another result of this proposal is that object representations may be taken into account dynamically. Object evolution encompasses therefore not only the evolution of the object values and structures, but also the management of multiple representations. To the best knowledge

of the authors, this issue has not been addressed this way in the literature before. The implementation of this approach for an object-based knowledge representation model called SHOOD is described. It relies on the set inclusion semantics of inheritance between classes. It also takes into account the notion of constraints which may be strong or weak, i.e which may or may not be violated by the instances. Further, the attributes in the class definitions are mandatory or optional, leaving the opportunity for objects to be incomplete and/or inconsistent. A classification mechanism called MIC allows the objects to evolve and to be dynamically classified according to their attribute values. Classes are characterized as potential and prohibited. Because representations are objects on their own, instances are related to their multiple representations by the standard "instance_of" relationship. The introduction of a new representation therefore requires only the creation of the corresponding "instance_of" relationships between the representation and the instances. The management of multiple representations for evolving objects uses an implicit approach by which only standard features and mechanisms are used. This calls for an explicit, flexible and multiple instantiation mechanism. It allows incomplete and inconsistent objects to evolve throughout representations. This simple approach proves to be very powerful and unifying. The model SHOOD is implemented in Le_Lisp and Aida on Sun 4 workstations. It is part of a joint project from INRIA and IMAG, called SHERPA.

Acknowledgements The authors wish to thank J.M BONNEFOND, F. BOUNAAS, A. CULET, C. DJERABA and J. ESCAMILLA from IMAG for their contributions to the design and implementation of SHOOD. This proposal is based on experience gained in mechanical CAD/CAM for GSIP. It is a joint research effort of the Universities of Grenoble involving also M. TOLLENAERE from Institut de Mécanique de Grenoble.

REFERENCES [ABI91] ABITEBOUL S. BONNER A. Object and views. Proc. ACM SIGMOD 91 Conf. Denver (Co). May 1991. [AHM91] AHMED R., NAVATHE S. Version management of composite objects in CAD databases. Proc. ACM SIGMOD 91 Conf. Denver (Co). May 1991. [BAN87] BANERJEE J., KIM W., KIM K.J., KORTH H. Semantics and implementations of schema evolution in object-oriented databases. Proc. ACM SIGMOD Conf. San Fransisco (Ca). May 87. [CAR90] CARRE B., GEIB J.M. The point of view notion for multiple inheritance. Proc. ECOOP/OOPSLA '90. Ottawa (C). September 1990. [CAS90] CASAIS E. Managing class evolution in object-oriented systems. Centre Universitaire Informatique. Université de Genève (CH). 1990. [ESC90] ESCAMILLA J., JEAN P. Relationships in an Object Knowledge Representation Model. Proc. 2nd Intl. Conf. Tools for Artificial Intelligence. Herdon (Va). November 1990. [GIA90] GIACOMETTI F., CHANG T.C. Object-oriented design for modelling parts, assemblies and tolerances. Proc. 2nd Intl. Conf. TOOLS '90. Paris (F). June 1990. [GOL83] GOLDBERG A. ROBSON D. Smalltalk 80 : the language and its implementation. Addison-Wesley Publ. Co. 1983. [IMI91] IMIELINSKI T. & al. Incomplete objects : a data model for design and planning applications. Proc. ACM SIGMOD 91 Conf. Denver (Co). May 1991. [KEE89] KEENS S.E Object-oriented programming in Common Lisp. A programmer's guide to CLOS. Addison-Wesley. 1989. [KIM90] KIM W. Object-oriented databases : definition and research directions. IEEE Trans. on Knowledge and Data Engineering. Vol. 2, n° 3. September 1990. [KOT88] KOTZ, DITTRICH, MULLE Supporting Semantic Rules by a Generalized

Event/Trigger Mechanism. Advances in DB technology. EDBT '88. Venice (I). March1988. [MAR90] MARINO O. & al. Multiple perspectives and classification mechanism in object oriented representation. Proc. ECAI Conf. Stockholm (S). July 1990. [MCL88] McLEOD D. A learning-Based Approach to Meta-Data Evolution in an ObjectOriented Database. Advances in Object-Oriented Databases Systems. Bad-Munster (G). September 1988. [NGU89a] NGUYEN G.T., RIEU D. Schema evolution in object-oriented database systems. Data & Knowledge Engineering. North-Holland. Vol. 4. N°1. July 1989. [NGU89b] NGUYEN G.T., RIEU D. Schema change propagation in object-oriented databases. Proc XIth World Computer Congress, IFIP Congress '89. San Francisco (Ca). August 1989.

[NGU90] NGUYEN G.T, RIEU D. Heuristic control on dynamic database objects. Information Processing '90. Meersman Ed. North-Holland. 1990. [NGU91a] NGUYEN G.T, RIEU D. Database issues in Object Oriented Design. Proc. 4th Intl. Conf. TOOLS '91. Paris (F). March 1991. [NGU91b] NGUYEN G.T, RIEU D. Representing design objects. Proc.1st Intl. Conf. Artificial Intelligence in Design. Edinburgh (U.K). June 1991. [PER90] PERNICI B. Objects with roles. Proc. Intl. Conf. on Office Information Systems. Boston (Ma). April 1990. [RIC91] RICHARDSON J., SCHWARZ P. Aspects : extending objects to support multiple, independent roles. Proc ACM SIGMOD Conf. Denver (Co.). May 1991. [RIE86] RIEU D., NGUYEN G.T. Semantics of CAD Objects for Generalized Databases. Proc. 23rd Design Atomation Conference. Las Vegas (Nevada). June 1986. [SCH88] SCHREFL D. et al. Object colouring. Proc. Intl. Conf. on Data Engineering. Los Angeles (Ca). February 1988. [SCI89] SCIORE E. Object specialization. ACM Trans. on Office Information Systems. Vol. 7. N° 2. 1989. [SIL90]SILBERSCHATZ A., STONEBRAKER M., ULLMAN J.D. Database systems : achievements and opportunities. Laguna Beach Report. TR 90-22. Dept. of Comp. Sc. The Uni-versity of Texas at Austin. February 1990. [STE86] STEFIK M., BOBROW D.G. Objectoriented programming: themes and variations The AI magazine. January 1986. [UNL90] UNLAND R., SCHLAGETER G. Object-oriented database systems : concepts and perspectives.. Proc. Intl. Symposium "Database Systems of the '90s". Berlin (G). November 1990. [VAN89] VAN DE RIET R.P. Mokum: An Object-oriented active Knowledge base system. Data & Knowledge Engineering. North-Holland. Vol. 4. N°1. July 1989.