Comparison Criteria for Ontological Multi-Level Modeling

Transcription

1 Institute für Wirtschaftsinformatik Nr / November 2008 Comparison Criteria for Ontological Multi-Level Modeling Presented at Dagstuhl-Seminar on The Evolution of Conceptual Modeling Bernd Neumayr Michael Schrefl Forschungsbericht Research Report 08.03

2 Vorbemerkung der Herausgeber / Editors preamble Die Forschungsberichte der Institute für Wirtschaftsinformatik dienen der Darstellung vorläufiger Ergebnisse z. B. Projektberichte und Zwischenergebnisse, die i. d. R. für spätere Veröffentlichungen überarbeitet werden. Die Autoren sind für kritische Hinweise dankbar. Alle Rechte vorbehalten. Research reports comprise preliminary results, e.g. project reports and intermediary results which will usually be revised for subsequent publications. Critical comments are appreciated by the authors. All rights reserved. Herausgeber / Editors o. Univ.-Prof. Dipl.-Ing. Dr. Gustav Pomberger, Institut für Wirtschaftsinformatik Software Engineering o. Univ.-Prof. Mag. Dr. Friedrich Roithmayr, Institut für Wirtschaftsinformatik Information Engineering o. Univ.-Prof. Dipl.-Ing. Dr. Michael Schrefl, Institut für Wirtschaftsinformatik Data & Knowledge Engineering o. Univ.-Prof. Dipl.-Ing. Dr. Christian Stary, Institut für Wirtschaftsinformatik Communications Engineering Autoren / Authors Bernd Neumayr bernd.neumayr@jku.at Michael Schrefl michael.schrefl@jku.at Johannes Kepler Universität Linz Institut für Wirtschaftsinformatik - Data & Knowledge Engineering Altenberger Str. 69, A-4040 Linz, Austria

3 Comparison Criteria for Ontological Multi-Level Modeling Bernd Neumayr and Michael Schrefl Department of Business Informatics - Data & Knowledge Engineering, Johannes Kepler University Linz, Austria {neumayr,schrefl}@dke.uni-linz.ac.at Abstract. Ontological multi-level modeling refers to describing domain objects at multiple levels of abstraction. Using traditional semantic data modeling, multi-level modeling can be achieved by representing objects in different abstraction hierarchies, classification, aggregation and generalization. Multiple representation, however, leads to accidental complexity, complicating modeling and extension. Several modeling techniques, like power types, deep instantiation, materialization and m-objects may be employed to reduce unnecessary complexity in modeling objects at multiple levels. This paper compares the use of power types, deep instantiation, materialization and m-objects for multi-level modeling using four comparison criteria: (1) compactness (avoiding accidental complexity), (2) extensibility (ease of introducing new abstraction levels), (3) query flexibility (number and kind of pre-defined entry points for querying), and (4) multiple relationship-abstraction (such as between relationship type and relationship occurrence). 1 Introduction Modeling domain objects at multiple levels of abstraction has received increased attention over the last years. It is nowadays frequently referred to as ontological multi-level modeling to contrast it from linguistic meta-level modeling, which relates to representing modeling language constructs in one or more higher levels, or meta models. Note that multi-level modeling is often associated solely with multiple classification levels, while this paper concerns, more generally, levels in classification, generalization and aggregation hierarchies. Several modeling techniques have been proposed in recent years to reduce accidental complexity in modeling domain objects at multiple levels of abstraction. The prevailing techniques are materialization [1 3], powertypes [4 6], and deep instantiation [7, 8]. While these techniques have the common aim to simplify multi-level modeling, they are not very similar at first appearance. Each one leans more or less to a different semantic abstraction hierarchy: aggregation, generalization, and classification. Materialization has some kinship to aggregation. It provides for modeling concrete objects of category objects differently

4 2 Bernd Neumayr, Michael Schrefl and comes with a very powerful concept for property definitions and propagations along the materialization hierarchy. The powertype approach focuses on generalization. It provides for describing the common properties of subclasses of a class, i.e., one level of the generalization hierarchy, by powertypes. Ontological meta modeling with deep instantiation provides for multiple levels of classification whereby an object at one level can describe the common properties for objects at each instantiation-level beneath that level. In [9] we introduce multi-level objects (m-object) and multi-level relationships (m-relationship). A m-object encapsulates the different levels of abstractions that relate to a single domain concept and a m-relationship links two m-objects at multiple levels. In this paper we present a sample problem (extended from [9]) and comparison criteria for techniques to ontological multi-level modeling. We will model the sample problem using alternative modeling techniques and highlight strengths and weaknesses of each approach. Note, however, that each approach has been developed with a different focus in mind and that therefore the approaches complement one another. A similar comparison of various modeling techniques to reduce accidental complexity in domain models is given by Atkinson and Kühne [10]. An insightful comparison between powertypes and potency-based deep instantiation is given by Gonzalez-Perez and Henderson-Sellers in the related work section of [6]. However, these comparisons do not consider all comparison criteria used in this paper, such as extensibility, query flexibility and multiple relationship-abstraction. The remainder of this paper is organized as follows: Section 2 defines requirements and comparison criteria for multi-level modeling based on a sample problem. Sections 3 shows how to model the sample problem with each approach. Section 4 gives an overview over the different approaches, highlighting strengths and weaknesses using our comparison criteria. Finally, Section 5 concludes the paper with suggestions for future work. 2 Sample Problem and Comparison Criteria In this section, we present our running example (taken from [9]), model it using plain UML, and introduce comparison criteria for techniques supporting ontological multi-level modeling. Example 1 (Sample Problem). The product catalog of an online-store is described at three levels of abstraction: physical entity, model, and category. Each product category has associated a tax rate, each product model has a list price. Book editions, i.e. objects at level model that belong to product category book, additionally have an author. Our company keeps track of physical entities of products (e.g. copies of book HarryPotter4), which are identified by their serial number. In addition to books, our company starts to sell cars, i.e. it introduces car as a new product category. Cars differ from books in that they are described at an additional level, namely brand, and in that they have additional attributes: maxspeed at level product model and mileage at level physical entity. As our

5 Ontological Multi-Level Modeling 3 sample-online-store specializes on selling cars of brand Porsche 911, it wants to be able to register physical entities of this car brand at the Porsche 911 club. Our company further keeps track of companies that produce these products. Companies are likewise described at multiple levels: industrial sector, enterprise, and factory. Producers of cars belong to a specific industrial sector, namely car manufacturer. To track quality problems, our company also associates with each physical entity of product category car the factory at which it was produced. Thereby, this factory must belong to the enterprise, which produces the car model. Using traditional semantic data modeling, e.g. using UML, such multi-level domains can be modeled by representing objects in different abstraction hierarchies, classification, aggregation and generalization. In our reference UML model (cf. Figure 1) the three-level product catalog is modeled by arranging classes (ProductCategory, ProductModel, Product) and their instances ({Car, Book}, {Porsche911CarreraS, Porsche911GT3, HarryPotter4}, {myporsche911carreras, mycopyofhp4}, respectively) in an aggregation hierarchy, where each aggregation level represents one level of abstraction (productcategory,product-model, and physical-entity). Objects at the same level in different subhierarchies may differ from each other. E.g., product models have a listprice, but car models (i.e., objects at level model belonging to car, an object at level category) have an additional attribute maxspeed. Furthermore, physical entities of car additionally have a mileage. In our reference UML model (cf. Figure 1) this non-uniformity between objects on the same level is modeled by specializing classes that are part of the aggregation hierarchy below ProductCatalog, i.e. ProductCategory, ProductModel,, to corresponding classes, CarCategory, CarModel, Car, that describe common properties of objects belonging to product-category Car at the respective level. Note, that singleton classes like CarCategory are necessary to refine aggregation, e.g., to define that each instance of CarModel belongs to product-category Car. Furthermore, we often need to access attributes defined at a higher level of abstraction. For example, to query the taxrate applicable to myporsche911carreras, defined at its product-category, Car. Concerning our reference UML model we could navigate from myporsche911carreras to taxrate at Car by following the aggregation relationships my- Porsche911CarreraS.ProductModel.ProductCategory.taxRate (note, that in order to follow links we use dot-notation and, in the absence of explicit role-names, the names of the classes at the other end of the aggregation relationship). Various modeling techniques, powertypes, potency-based deep instantiation, materialization, and m-objects, can be used to reduce the complexity of such multi-level models. Their suitability to ontological multi-level modeling may be benchmarked against the following comparison criteria. 1. Compactness: A modeling solution is compact if the information about a single domain concept is specified at a single place. To measure the

6 4 Bernd Neumayr, Michael Schrefl Classes Instances Product- Catalog ProductCatalog -desc : String Products: ProductCatalog -desc = 'Our Products' Product- Category ProductCategory -taxrate : Integer Singleton CarCategory Singleton BookCategory Car:CarCategory -taxrate = 20 Book:BookCategory -taxrate = 15 Product- Model ProductModel -listprice : Integer CarModel -maxspeed : Integer BookTitle -author : String Singleton Porsche911CarreraS- Model Singleton Porsche911GT3Model Singleton HarryPotter4BookTitle Porsche911CarreraS: Porsche911CarreraS Model -listprice= maxspeed = 293 km/h Porsche911GT3: Porsche911GT3Model -listprice = maxspeed = 310 km/h HarryPotter4:BookTitle -listprice = author = 'J.K.Rowling' Physical Entity Product -serialnr : String Car -mileage : Integer Book Porsche911CarreraS- Porsche911GT3- HP4- myporsche911carreras : Porsche911CarreraS- -serialnr = 'C333333' -mileage = mycopyofhp4: HP4 -serialnr = 'A121212' Product-Catalog Product-Category Product-Model Fig. 1. Product catalog modeled in plain UML, using generalization, instantiation and aggregation (relationships and level brand are omitted) degree of compactness when representing a domain concept like car, one may count how many separate model elements (objects, classes, relationships, relationship types) are used to capture the information about the domain concept. In our reference UML model (cf. Figure 1), domain concept car is represented by one object, Car:CarCategory, and three classes, (CarCategory,CarModel,Car) and one object,car:carcategory. Furthermore, the hierarchic relation between product and car is represented four times (aggregation between Car:CarCategory and Products:ProductCatalog, generalization between CarCategory and Product- Category, CarModel and ProductModel, and Car and Product- ). 2. Extensibility: A modeling solution is easy to extend if an additional abstraction level can be introduced without the need to change existing model elements. To evaluate this criterion, we will introduce an additional abstraction level car-brand for product-category car between levels product-category and product-model and describe one car-brand, namely Porsche 911. If this extension can be made without affecting the existing model, i.e, definitions

7 Ontological Multi-Level Modeling 5 ProductCategory producedby IndustrialSector 1 context ProductModel inv: self.enterprise.industrialsector->forall( x self.productcategory.industrialsector->exists( y x = y) ) 1 * ProductModel producedby * Enterprise 1 context Product inv: self.factory.enterprise->forall( x self.productmodel.enterprise->exists( y x = y) ) 1 * * producedby Product Factory Car :ProductCategory producedby CarManufacturer :IndustrialSector P911CarreraS :ProductModel producedby PorscheLtd :Enterprise myporsche911carreras :Product producedby PorscheZuffenhausen :Factory Fig. 2. Relationships producedby at different levels of abstraction modeled with UML and OCL of other product-categories, e.g., book, or generally of products, the modeling solution is considered to be easy to extend. Concerning our reference UML model the respective extension could be made by introducing a class CarBrand as component of class CarCategory and as aggregate class of Car- Model. 3. Query flexibility: A modeling solution supports query flexibility if it provides several pre-defined entry points for querying, such as class names or qualified identifiers to refer to various sets of objects. In the context of ontological multi-level modeling we check whether one may easily refer to the set of objects at one abstraction level that belong to a certain domain concept. To test this criterion, we query (1) all objects belonging to product-category car at level product-model, (2) all objects belonging to product-category car at level physical-entity, and (3) all objects belonging to level productphysical-entity. In our reference UML model these entry points for queries are available through the classes (1) CarModel, (2) Car, and (3) Product. 4. Multiple relationship-abstractions: A modeling technique supports multiple relationship-abstractions if it does not only support modeling of domain objects at multiple levels of abstraction, but equally supports ontological multi-level modeling of relationships. Consider, for example, that products

8 6 Bernd Neumayr, Michael Schrefl are produced by factories. Our sample product catalog describes products at three levels of abstraction (physical entity, model and category) and it describes the factories in which products are produced at three levels as well (factory, enterprise, and industrial sector). To test the support for multiple relationship-abstraction, we check how a modeling solution supports the abstraction of relationship produced by between physical entity and factory to relationship produced by between product model and enterprise, and the abstraction of the latter to relationship produced by between product category and industrial sector. In our reference UML modeling solution ( cf. Figure 2), OCL has been used to express extensional constraints that are imposed from a higher to a lower level of abstraction of the producedby relationship. 3 Techniques supporting ontological multi-level modeling In this section, we present several modeling techniques and discuss their suitability for ontological multi-level modeling. We cover Powertypes, Potency-based Deep Instantiation, Materialization, and M-objects. We demonstrate each technique by our example and analyze it according to the criteria introduced in the previous Section. 3.1 Powertypes Powertypes were introduced by Odell [4] and further investigated by Henderson- Sellers and Gonzalez-Perez [5, 6]. Powertypes can be effectively employed to reduce accidental complexity in ontological multi-level modeling. The powertype pattern consists of a partitioned type c (e.g. ProductModel cf. Figure 3) and a powertype p (e.g. ProductCategory). Every subclass s i of partitioned type c is instance of powertype p. Thus, each s i consists of a classand an object-facet (e.g. CarModel and Car:ProductCategory). Such two faceted constructs are often called clabjects (introduced by Atkinson [11]). To model a three-level product catalog, cf. Example 1, one can use the powertype pattern consecutively. E.g., we use the class-facet CarModel of clabject Car:ProductCategory-CarModel as powertype for Car, a class at a lower level. Modeling of non-uniform objects at the same abstraction level in different sub-hierarchies is straightforward. By extending class Car with attribute mileage and extending class-facet CarModel with attribute maxspeed one can describe objects of product-category Car at levels product-model and physical-entity. Evaluation 1. Compactness: Powertypes reduce accidental complexity in that the objectfacet and the class-facet relating to one domain-concept are bound together. But to describe domain-concepts with more than two abstraction levels, several classes are necessary. To represent the domain concept Car with all its abstraction levels, requires to define two separate

9 Ontological Multi-Level Modeling 7 ProductCategory -taxrate : Integer isclassifiedas ProductModel -listprice : Integer Car:ProductCategory -taxrate = 20 CarModel -maxspeed : Integer Book:ProductCategory -taxrate = 15 isclassifiedas BookTitle -author : String Car- -mileage : Integer Porsche911CarreraS: CarModel -listprice= maxspeed = 293 km/h Porsche911CarreraS- Porsche911GT3: CarModel -listprice = maxspeed = 310 km/h myporsche911carreras : Porsche911CarreraS- -serialnr = 'C333333' -mileage = Product- -serialnr : String Porsche911GT3- Book- HarryPotter4:BookTitle -listprice = author = 'J.K.Rowling' HP4- mycopyofhp4: HP4- -serialnr = 'A121212' Fig. 3. Product catalogue modeled with powertypes, notation as proposed by Henderson-Sellers and Gonzalez-Perez [5] model elements, namely class Car and a clabject, consisting of object Car:ProductCategory and class CarModel. Similarly, to represent the hierarchic relationship between domain concepts Car and Product, two separate relationships need to be modeled, namely generalization between Car and Product, and classification between Car:ProductCategory and ProductCategory (with generalization between classes CarModel and ProductModel being implicit). (cf. Figure 3). 2. Extensibility: It is possible to introduce an additional level in one subhierarchy (e.g., for product category car) without affecting other subhierarchies (e.g., product category book). An additional level brand between car category and car model is achieved as follows: One introduces class Car- Brand (cf. Figure 4) as powertype of CarModel, whereby CarModel forms a clabject with object Car:ProductCategory as before (cf. Figure 3). Then, a particular car brand such as Porsche911 is modeled as an instance of Car- Brand, i.e., as a clabject consisting of object Porsche911:CarBrand and class Porsche911Model, which is subclass of CarModel. Furthermore, to describe common properties of objects belonging to car-brand Porsche911 at level

10 8 Bernd Neumayr, Michael Schrefl ProductCategory -taxrate : Integer isclassifiedas isclassifiedas CarBrand -marketlaunch : Date Car:ProductCategory -taxrate = 20 Porsche911: CarBrand -marketlaunch=1964 ProductModel -listprice : Integer CarModel -maxspeed : Integer Porsche911Model Product- -serialnr : String isclassifiedas Book:ProductCategory -taxrate = 15 BookTitle -author : String Car- -mileage : Integer isclassifiedas Porsche911- -porsche911club : Boolean Porsche911CarreraS: Porsche911Model -listprice= maxspeed = 293 km/h Porsche911CarreraS- Porsche911GT3: Porsche911Model -listprice = maxspeed = 310 km/h Porsche911GT3- myporsche911carreras : Porsche911CarreraS- -serialnr = 'C333333' -mileage = porsche911club=true HarryPotter4:BookTitle Book- -listprice = author = 'J.K.Rowling' HP4- mycopyofhp4: HP4- -serialnr = 'A121212' Fig. 4. Powertypes - adding an additional level CarBrand to a sub-hierarchy physical-entity, class Porsche911 is introduced as subclass of Car. E.g., this class has attribute porsche911club to indicate whether some Porsche911 car (i.e., Car) is registered with the Porsche911Club. Note that to reflect the introduction of some car brand in the powertype approach, one needs to add a clabject (in our example Porsche911: CarBrand - Porsche911Model) as well as an additional subclass (in our example Porsche911 of Car). 3. Query flexibility: Querying powertypes is not explicitly treated in the literature we are aware of. But pre-defined entry points can be easily provided for our benchmmark queries. (1) All car-models: members of class CarModel. (2) Physical entities of car: members of Car. (3) All physical entities of products: members of Product. 4. Multiple relationship-abstractions: The literature we are aware of does not introduce special techniques for modeling multiple relationship-abstraction with powertypes. But the modeling approach shown in Figure 2, using plain UML and OCL, can be used together with power types. 3.2 Potency-based Deep Instantiation Deep instantiation refers to meta modeling in which an object at some (meta- )level can describe the common properties for objects at each instantiation-level beneath that level. Metamodeling through meta classes that provide for deep instantiation has been first put forward in the area of databases by the VODAK

11 Ontological Multi-Level Modeling 9 ProductCategory -taxrate 1 : Integer -listprice 2 : Float -serialnr 3 : String O3 Book -taxrate 0 = 15 -author 1 : String Car -taxrate 0 = 20 -maxspeed 1 : Integer -mileage 2 : Integer O2 HarryPotter4 -listprice 0 = author 0 = 'J.K.Rowling' Porsche911GT3 -listprice 0 = maxspeed 0 = 310 Porsche911CarreraS -listprice 0 = maxspeed 0 = 293 O1 mycopyofhp4 -serialnr 0 = 'A121212' myporsche911carreras -serialnr 0 = 'C ' -mileage 0 = O0 Fig. 5. Product catalogue modeled with potency-based deep instantiation system [12]. VODAK associated several types with an object, the own-type describing itself, the instance-type describing objects at one classification level below, and the instance-instance-type describing objects at two classification levels below. In this way, meta classes in VODAK allow to describe not only common properties of instances but also common properties of instances of instances. Ontological metamodeling with potency-based deep instantiation was introduced by Atkinson and Kühne [7]. Rather than using different types for each level as in VODAK, attributes definitions are annotated with a potency, where this potency denotes the instance level. Later, Kühne introduced DeepJava [8] for programming with multi-level models. DeepJava supports unbound classification levels and allows to describe not only common attributes of instances but also common properties of instances of instances, and so forth. Our sample product catalog (cf. Example 1) consisting of abstraction levels physical-entity, product model, and product category, is modeled (cf. Figure 5) by representing objects at level physical entity as objects at classification level O0. Each physical entity (e.g. mycopyofhp4, myporsche911carreras) is modeled as some instance of a product model (e.g. HarryPotter4, Porsche911GT3, Porsche911CarreraS). Each product model is a clabject at classification level O1, i.e., is a class for objects at classification level O0 as well as an instance of some product category (e.g. Book, Car) at level O2. Each product category is again a clabject, i.e., a class for objects at classification level 01 and instance of ProductCategory at classification level O3. To define, that physical entities of product category car additionally have a mileage and car models additionally have a maximum speed, attributes

12 10 Bernd Neumayr, Michael Schrefl maxspeed and mileage are introduced with potency 1 and 2, resp., at clabject Car. To access attributes defined at a higher level (upward navigation) it is possible to follow the instance-of relationships with method type(). The path from myporsche911carreras to taxrate defined at Car is denoted as: my- Porsche911CarreraS.type().type().taxRate. Evaluation 1. Compactness: Potency-based deep instantiation supports very compact modeling. All information concerning all levels of one domain-category can be described local to one clabject. E.g., all information about domain concept car is encapsulated in a single model element Car which is related to ProductCategory only once (cf. Figure 5). ProductCategory -taxrate 1 : Integer -listprice 2 3 : Float -serialnr 3 4 : String O4 Book -taxrate 0 = 15 -author 1 2 : String Car -taxrate 0 = 20 -marketlaunch 1 : Date -maxspeed 1 2 : Integer -mileage 2 3 : Integer O3 BookBrandDummy Porsche911 -p911club 2 : Boolean -marketlaunch 0 = 1964 O2 HarryPotter4 -listprice 0 = author 0 = 'J.K.Rowling' Porsche911GT3 -listprice 0 = maxspeed 0 = 310 Porsche911CarreraS -listprice 0 = maxspeed 0 = 293 O1 mycopyofhp4 -serialnr 0 = 'A121212' myporsche -serialnr 0 = 'C ' -mileage 0 = p911club 0 = true O0 Fig. 6. Deep Instantiation - Adding level brand for category car requires global model changes. 2. Extensibility: Adding an intermediate classification level to a sub-hierarchy (e.g. car-brand under product-category car with instance Porsche911) requires global model changes (cf. Figure 6): When introducing a new classification level O new (e.g., O2 for car-brand with instance Porsche911) below level O n (e.g., O2, cf. Fig.5, becoming O3, cf. Fig.6, with instances

13 Ontological Multi-Level Modeling 11 Car, etc.) and above level O n 1 (e.g., O1, cf. Fig.5 and 6, with instances Porsche911CarreraS, etc.), global model changes are necessary: 1) For each clabject at a classification level above O new (in our case ProductCategory and Book) potencies of attributes that affect objects at classification levels below O new have to be changed (in our case listprice and serialnr in clabject ProductCategory and author in clabject Book). 2) For each clabject at level O n, a (dummy) clabject at level O new has to be introduced, e.g., BookBrandDummy, and each clabject at level O n 1 has to be re-classified to be instance-of the respective clabject at level O new (HarryPotter4 is instance-of BookBrandDummy). Furthermore, (3) upward navigation paths have to be changed: the navigation from myporsche911carreras to its taxrate changes from myporsche911carreras.type().type().taxrate to my- Porsche911CarreraS.type().type().type().taxRate. We conclude that due to these necessary changes in existing model elements, a given design or implementation cannot be easily extended by additional levels. 3. Query flexibility: To our knowledge, extension of classes are not maintained by DeepJava. But to maintain and retrieve the different member sets of our sample queries should be easy in principle, given the set theoretic interpretation of deep instantiation [13]. Every clabject with potency p > 0 can be viewed as having p member sets, one for each level beneath, e.g., Car = {{Porsche911GT3, Porsche911CarreraS},{{},{myPorsche911CarreraS}}}. 4. Multi-level relationships: Modeling of multiple relationship-abstractions is, to the best of our knowledge, not discussed as such in the relevant literature. But the constraints modeled in Figure 2 can be implemented in DeepJava using type parameters [8]. No support, however, for extensional views (sets and subsets of relationships) on relationship-types is given. 3.3 Materialization Materialization [1 3] is a generic relationship type, which can be regarded as a special kind of aggregation. Each materialization relationship connects a more abstract class c a (playing the model role), e.g. ProductModel, with a more concrete class c c (playing the materialization role), e.g. Product. An instance o c of the more concrete class is a materialization of exactly one instance o a of the more abstract class. Object o c both inherits attribute values from object o a (shared values) and instantiates attributes defined at class c c as well as attributes introduced at object o a. Thus, similar to clabjects (cf. Sections 3.2 and 3.1), o a plays both the role of an object and the role of a class. Our sample three-level product catalog, cf. Example 1, can be modeled by applying materialization relationships consecutively. Class Product materializes class ProductModel which materializes class ProductCategory. Each class represents one level of abstraction (or, in this context, one level of materialization). Definition of shared attribute values at the more abstract object o a that are propagated to the more concrete object o c, and definition of attributes at o a,

14 12 Bernd Neumayr, Michael Schrefl ProductCategory -taxrate : Integer (T1) -modelattr (T3) -physentattr (T1-T3) 1 model Car:ProductCategory -taxrate = 20 -modelattr = {maxspeed} -physentattr = {mileage} model Book:ProductCategory -taxrate = 15 -modelattr = {author} -physentattr = {} model materializes * ProductModel -listprice : Integer -physentattr2 (T3) 1 materializes * Product- -serialnr : String materialization model materialization Porsche911CarreraS: ProductModel -listprice= maxspeed = '293 km/h' -physentattr2 = {} -/taxrate = 20 -/physentattr = {mileage} myporsche911carreras: Product -serialnr = 'C333333' -mileage = /listprice = /maxspeed = 293 km/h -/taxrate = 20 materialization materialization materialization model materialization Porsche911GT3: ProductModel -listprice = maxspeed = '310 km/h' -physentattr2 = {} -/taxrate = 20 -/physentattr = {mileage} HarryPotter4: ProductModel -listprice = author = 'J.K.Rowling' -physentattr2 = {} -/taxrate = 15 -/physentattr = {} model materialization mycopyofhp4: Product -serialnr = 'A121212' -/listprice = /author = 'J.K.Rowling' -/taxrate = 15 Fig. 7. Product catalog modeled with materialization (using a respective UMLnotation by Olivé[14]) and applying composite attribute propagation mechanism (T1- T3) to mimic deep instantiation that are instantiated at o c, are facilitated by a set of attribute propagation mechanisms, introduced by Pirotte et al. [2] and further described by Dahchour et al. [3]. Type 1 propagation (T1) simply propagates values of attributes (monoor multivalued) from o a to o c, e.g. taxrate=20 from Car to Porsche911CarreraS. For better readability, we have marked propagated T1-attributes with a / - character, such as /taxrate=20 at object Porsche911CarreraS. Type 2 propagation (T2) allows to define at c a an attribute, instantiated at o a with a set of possible values. This attribute is instantiated at o c with one value (T2mono) or a set of values (T2multi) from the set of possible values defined at o a (not considered in our example). Type 3 propagation (T3) allows to define a multi-valued attribute at c a, instantiated with a set of values at o a. Each of these attribute values defined at o a is transformed to an attribute in o c and instantiated there E.g., class ProductCategory defines an attribute modelattr with T3 that is instantiated at object Car:ProductCategory with {maxspeed}, and maxspeed is instantiated at object Porsche911CarreraS:ProductModel (cf. Fig. 7) Attribute values defined at objects at higher materialization levels, e.g., taxrate = 20 at Car:ProductCategory can be accessed at objects at lower materialization levels, e.g. myporsche911carreras, either by traversal of materialization links (myporsche911carreras.model.model.taxrate) or, if taxrate is prop-

15 Ontological Multi-Level Modeling 13 agated using T1, by directly accessing the propagated attribute value, e.g. my- Porsche911CarreraS.taxRate. Composing attribute propagation types, as described in [3], allows to define attributes that have impact on two materialization levels below and a combination of propagation modes T1 and T3 can be used to mimic potency-based instantiation. The combination of propagation modes T1 and T3 has to the best of our knowledge not be considered in literature, but it can be used as follows to mimic potency-based instantiation. An abstract class c a defines an attribute with T1-T3 propagation. The attribute is instantiated with a set of values at instance o a of class c a and, due to propagation mode T1 (which is first applied), propagated to every materialization o c of abstract object o a. The attribute is propagated further in T3 mode to every materialization o cc of o c, i.e., o cc receives an attribute for every value of that attribute at o c and instantiates it. In this way, attributes with T1-T3 resemble attributes with potency 2 (cf. Section 3.2) and attributes with T1-T1-T3 resemble attributes with potency 3, and so forth. We illustrate this approach by the following example. As described in our sample problem statement, product models and physical entities belonging to product category car differ from other product models and physical entities, in that they have attributes maxspeed and mileage, respectively. To be able to define these peculiarities, attribute modelattr(t3) and physentattr(t1-t3) are introduced at class ProductCategory. As described in the previous paragraph, these attributes serve as placeholders for attributes introduced in instances of ProductCategory: At Car:ProductCategory, modelattr is instantiated with {maxspeed} to define that there is an attribute maxspeed in every materialization of Car, i.e. in Porsche911CarreraS and in Porsche911GT3. Furthermore, attribute physentattr is instantiated with {mileage} to define that there is an attribute mileage in every materialization of a materialization of Car, i.e. in myporsche911carreras. Alternatively, one could explicitly specialize classes ProductModel and Product by subclasses CarModel and Car, respectively. We do not further consider this alternative, because subclassing of classes which are part of materialization hierarchies is not considered in literature on materialization and is somewhat counter-intuitive to the idea of materialization. Another powerful composite attribute propagation type, T3-T2, is discussed in [3], but not needed to model our sample product catalog. Evaluation 1. Compactness: All peculiarities of domain concept car, including those concerning objects at level product model and physical entity, can be described local to one model element, namely Car:ProductCategory. Thus, materialization effectively reduces accidental complexity. 2. Extensibility: Literature on materialization does not discuss introducing additional materialization levels local to a specific object in the materialization hierarchy, like level brand local to Car:ProductCategory. Since the modeling

16 14 Bernd Neumayr, Michael Schrefl solution with materialization presented herein mimics potency-based deep instantiation using T1-T3-attribute propagation, additional levels would lead to similar problems as when using potency-based deep instantiation, i.e., lead to global model changes. Using materialization, propagation modes of attributes need to be adapted analogously as described above for potency values of potency-based deep instantiation. 3. Query flexibility: Materialization hierarchies (as in [3]) provide a pre-defined entry point for all objects at a specific materialization level by the class representing this materialization level, e.g. all objects at level physical entity can be addressed via class Product. Relevant literature does not consider pre-defined query entry points that refer to all objects of one materialization level that directly or indirectly materialize some abstract object. However, one should in principle be able to retrieve such sets of objects rather easily with materialization by queries like (in SQL-Syntax): SELECT * FROM ProductModel p WHERE p.model = Car or to access all physical cars: SELECT * FROM Product p WHERE p.model.model = Car. 4. Multi-level relationships: Pirotte et al. [2] shortly mention materialization of relationships but do not discuss materialization of relationships in detail. They basically consider a relationship as a class that can be materialized like any other class. Pirotte et al. [2] also sketch the idea of materialization of aggregation, e.g. a product model is composed of various parts (bill of materials) and this bill of materials can be materialized to the level of physical entities. This idea could be elaborated and extended for materialization of relationships in order to support multiple relationship-abstractions. 3.4 Multi-Level Objects In [9] we introduce multi-level objects (m-objects) and multi-level relationships (m-relationships) for the concretization of objects and relationships along multiple levels of abstraction. The basic ideas of this approach, which builds on the previous approaches discussed above, are (i) to encapsulate the different levels of abstractions that relate to a single domain concept (e.g., the level descriptions, catalog, category, model, physicalentity that relate to single domain concept, product catalog) into a single m-object (cf. Product), and (ii) to unify the different semantic abstraction hierarchies (aggregation, generalization, and classification) into a single concretization hierarchy. A m-object encapsulates and arranges abstraction levels in a linear order from the most abstract to the most concrete one. Thereby, it describes itself and the common properties of the objects at each level of the concretization hierarchy beneath itself. A m-object that concretizes another m-object, the parent, inherits all levels except for the top-level of the parent. It may also specialize the inherited levels or even introduce new levels. A m-object specifies concrete values for the properties of the top-level. This top-level has a special role in that it describes the m-object itself. All other levels describe common properties of m-objects beneath itself.

17 Ontological Multi-Level Modeling 15 Consider m-object Product of Figure 8, which consists of four levels with one attribute each. Level category is the parent level of level model. Attribute taxrate is associated with level category, has domain Integer and does not define a value. The m-object is at level catalog as this level is its top-level. The top-level defines attribute desc of domain String and specifies value Our Products for this attribute. A m-object can concretize another m-object, which is referred to as its parent. The concretizes-relationship unifies classification, generalization and aggregation: Classification - Instantiation: Each m-object can be regarded as instance of its parent m-object. Thereby, it must adopt all levels from its parent except for the parent s top-level, and it can specify values for its attributes. Generalization - Specialization: The level descriptions of a m-object correspond to subclasses of the corresponding levels of its parent. The m-object can define new levels or add attributes to levels. Aggregation - Decomposition: The hierarchy between m-objects of different levels expresses the aggregation hierarchy. Thereby, a m-object must not change the relative order of levels and attributes which it inherits from its parent. A concretization relationship between two m-objects does not reflect that one m-object is at the same time an instance of, component of, and subclass of another m-object as a whole. Rather, a concretization relationship between two m-objects, such as Car and Product in Fig. 8, is to be interpreted in a multifaceted way. Each m-object plays multiple roles with regard to the classical semantic abstraction hierarchies. M-object Car concretizes m-object Product in Figure 8. The concretization relationship expresses classification: m-object Car is instance of level category of m-object Product because level category, which is the first non-top-level of m-object Product, is its top-level. It also specifies a value for its attribute taxrate. M-object Car specializes m-object Product by introducing a new level brand and adding attribute maxspeed to level model and attribute mileage to level physical entity. The level model of m-object Car can be regarded as a subclass of level model of m-object Product. Cars are further categorized into brands, models and physical entities. These levels define the aggregation hierarchy. M-relationships are analogous to m-objects in that they describe relationships between m-objects at multiple levels of abstraction. M-relationships are bi-directional. To facilitate referencing objects involved in binary relationships, we take, however, a (potentially) arbitrary directional perspective by considering one object in the source role and the other object in the target role of the relationship. Each m-relationship links a source m-object with a target m- object. Additionally, it connects one or more pairs of levels of the source and the target. These connections between source- and target-levels constitute the abstraction levels of a m-relationship. They define that m-objects at source-level are related with m-objects at target-level. We note that the generic roles source

18 16 Bernd Neumayr, Michael Schrefl Product :catalog -desc:string ='Our Products' -taxrate : Integer :category -listprice : Float :model :physical entity -serialnr : String Product Catalog Book :category -taxrate = 15 :model -author : String :physical entity Car -taxrate = 20 :category -marketlaunch : Date :brand -maxspeed : Integer :model :physical entity -mileage : Integer Product Category Porsche911 :brand -marketlaunch = 1964 :model :physical entity -porsche911club : Boolean Car Brand HarryPotter4 :model -listprice = author = 'J.K.Rowling' :physical entity Porsche911CarreraS :model -listprice = maxspeed = 293 km/h :physical entity Porsche911GT3 :model -listprice = maxspeed = 310 km/h :physical entity Product Model mycopyofhp4 :physical entity -serialnr = 'A121212' myporsche911carreras :physical entity -serialnr = 'C ' -mileage = porsche911club = true Product Physical Entity Fig. 8. Product catalogue modeled with m-objects and target, which we introduced here for simplicity, may be easily replaced by relationship-specific role names. To model that car models have a designer, Figure 9 introduces a relationship designedby between source m-object Car and target m-object Person. More precisely, it links source-level model of m-object Car to target-level individual of m-object Person. While relationship designedby only links one source-level with one target-level, relationship producedby between Product and Company specifies multiple source- and target-levels. The relationship expresses that product categories are produced by industrial sectors, product models by enterprises and physical entities by factories. Like m-objects, m-relationships can be concretized. Concretizing a m- relationship means to substitute its source or its target for a direct or indirect concretization. The concretizes-relationship between two m-relationships expresses instantiation and/or specialization.

19 Ontological Multi-Level Modeling 17 Product catalog category model physical entity producedby Company root industrial sector enterprise factory Person root individual designedby Car category brand model physical entity producedby CarManufacturer industrial sector enterprise factory Porsche911 brand model physical entity producedby Porsche Ltd enterprise factory Mr.Black individual designedby Porsche911CarreraS model physical entity myporsche911carreras physical entity producedby Porsche Zuffenhausen factory Fig. 9. Product catalogue modeled with m-objects and their m-relationships [9] Consider m-relationship designedby between m-objects Car and Person in Figure 9. M-relationship designedby between m-objects Porsche911CarreraS and Mr.Black concretizes this m-relationship. In this case, the concretization solely represents an instantiation, i.e. no further concretization is possible. Now look at m-relationship producedby between m-objects Product and Company. M-relationship producedby between Car and CarManufacturer concretizes this m-relationship, expressing that cars can only be produced by car manufacturers. This concretization further defines that each car model must be produced by enterprises that belong to the car manufacturer sector. Similarly, each physical entity of cars must be produced by a factory of the car manufacturer sector. Dependent on the levels which a m-relationship connects, it can play various roles: Relationship class: A relationship that links a non-top-level of the source m-object with a non-top-level of the target m-object can be regarded as a relationship class. It defines that m-objects at the source-level may or must depending on whether the relationship is optional or mandatory, a distinction which we do not discuss in this paper have a relationship with m-objects at the target-level, which are concretizations of the target m- object. A m-relationship that links n pairs of non-top-levels, with n 2, can further be seen as a meta n 1 relationship class because these links constrain how this relationship has to be further concretized. Relationship occurrence: A m-relationship that links the top-level of the source m-object with the top-level of the target m-object can be seen as relationship occurrence. Shared relationship: A m-relationship that links a non-top-level with a toplevel is shared with lower levels. It cannot be further concretized by m-objects

20 18 Bernd Neumayr, Michael Schrefl that still possess that non-top-level, but only by more concrete m-objects beneath. In Figure 9, the relationship designedby between source car model and target person individual can be regarded as a relationship class, defining that each car model may or must (see above) have a relationship with an individual person. In our example, there is such a relationship between the car model Porsche911CarreraS and the individual person Mr.Black. This relationship represents a relationship occurrence. Similarly, relationship producedby between Product and Company connects source-level model of m-object Product with target-level enterprise of m-object Company, which is a relationship class. There is no explicit relationship occurrence between m-object Porsche911CarreraS and m-object Porsche Ltd. But there is a shared relationship between m-objects Porsche911 and Porsche Ltd at the respective levels. This relationship defines that each Porsche911 model, i.e. including Porsche911CarreraS, is produced by Porsche Ltd. It also takes the role of a relationship class, constraining the producers of physical entities of Porsche911 to factories of Porsche Ltd. The relationship cannot be further concretized by m-object Porsche911CarreraS, which still possesses the (former) non-top-level model, but only at m-object myporsche911carreras. Evaluation 1. Compactness: M-objects allow compact modeling by encapsulating all information concerning one domain concept into one m-object. E.g., all information concerning domain concept car is encapsulated into one m-object, Car. 2. Extensibility: Hierarchies of m-objects are easy to extend by an additional level (e.g., brand) in one sub-hierarchy (e.g., the sub-hierarchy rooted by car) without effecting other sub-hierarchies (e.g., the sub-hierarchy rooted by book). Fig. 8 already shows level brand with m-object car. To add this level to cars, but not to books, requires no changes above m-object car or in sibling hierarchies of m-objects (such as book). 3. Query flexibility: Pre-defined qualified identifiers can be used to refer to the set of m-objects at a specific level that belong to a specific m-object. The set of all m-objects that are descendants of a given m-object at some specified level is identified by qualifying the name of the m-object by that level. E.g., (1) to refer to all models of product-category Car one writes Car model, (2) to refer to the physical cars of product category car: Car physicalentity, and (3) to refer to all physical entities of products: Product physicalentity. (See [9] for details). 4. Multiple relationship abstractions: M-relationships between m-objects are like m-objects described at multiple levels, associating one or more pairs of levels of the linked m-objects. M-relationships can be interpreted in a multi-faceted way, once as relationship occurrence (or sometimes also called relationship instance or link) and once as relationship class (or sometimes

21 Ontological Multi-Level Modeling 19 also called relationship type or association), or also as meta-relationship class. They take on these multiple roles depending on what pairs of linked levels one considers and on whether one considers the linked m-objects in an instance or a class-role. As they m-relationships may also be concretized along the concretization hierarchy of linked m-objects, they support multiple relationship abstractions. 4 Summary of comparative evaluation In the previous section we modeled our sample product catalogue using different modeling techniques and evaluated them according to four comparison criteria, which we summarize here again: (1) Compactness refers to whether information about the abstraction levels (e.g., product category, product model, physical entity) of a single domain concept (e.g., car) is represented local to one model element or dispersed across multiple model elements. (2) Extensibility in the context of multi-level modeling refers to the possibility of introducing an additional (intermediate) abstraction level (e.g., level car brand), without the need to change existing model elements. (3) Query Flexibility is measured by the number and kind of pre-defined entry points for querying, e.g. to directly access the set of all physical car entities. (4) a modeling technique supports multiple relationship abstraction if it does not only consider objects and classes at different abstraction levels, but equally supports ontological multi-level modeling of relationships, as exemplified by relationship producedby between physical-entity and factory, product-model and enterprise, and product-category and industrial sector. The results of our evaluations of the various modeling techniques are summarized in Figure 10. We wish to stress that this evaluation only addresses the suitability of modeling techniques for ontological multi-level modeling, especially for domains such as exemplified in Section 2. It does, however, not evaluate the overall quality of these approaches or their suitability for other problem domains. Materializ. Deep Inst. Powertypes M-Objects Compactness Extensibility Query Flexibility + + Relationship-Abstraction )need addressed, but relevant technique not elaborated in detail. 2 )respective constraints involved can be implemented in DeepJava using type parameters. 3 )respective constraints involved can be expressed by OCL Fig. 10. Evaluation of different modeling techniques according to comparison criteria for ontological multi-level modeling

22 20 Bernd Neumayr, Michael Schrefl 5 Conclusion In this paper we presented a sample problem statement and introduced appropriate comparison criteria for ontological multi-level modeling. Following these criteria, we evaluated four modeling techniques concerning their suitability for ontological multi-level modeling. Future work on ontological multi-level modeling should try to combine the strengths of each approach: (i) compactness of potency-based deep instantiation, (ii) applicability, standard-integration (concerning UML), and extensibility of powertypes (iii) from materialization both the general idea and its powerful attribute propagation mechanisms and (iv) finally the extensibility of m-objects and its capabilities for modeling multiple relationship-abstractions. References 1. Goldstein, R.C., Storey, V.C.: Materialization. IEEE Trans. Knowl. Data Eng. 6(5) (1994) Pirotte, A., Zimányi, E., Massart, D., Yakusheva, T.: Materialization: A powerful and ubiquitous abstraction pattern. In Bocca, J.B., Jarke, M., Zaniolo, C., eds.: VLDB, Morgan Kaufmann (1994) Dahchour, M., Pirotte, A., Zimányi, E.: Materialization and its metaclass implementation. IEEE Trans. Knowl. Data Eng. 14(5) (2002) Odell, J.J.: Power Types. In: Advanced Object-Oriented Analysis & Design Using UML (also published as James Odell: Power Types. JOOP 7(2): 8-12 (1994)). Cambridge University Press (1998) Henderson-Sellers, Gonzalez-Perez: Connecting powertypes and stereotypes. Journal of Object Technology 4 (2005) Gonzalez-Perez, C., Henderson-Sellers, B.: A powertype-based metamodelling framework. Software and System Modeling 5(1) (2006) Atkinson, C., Kühne, T.: The essence of multilevel metamodeling. In Gogolla, M., Kobryn, C., eds.: Proceedings of the 4 th International Conference on the UML 2000, Toronto, Canada. LNCS 2185, Springer Verlag (October 2001) Kühne, T., Schreiber, D.: Can programming be liberated from the two-level style: multi-level programming with deepjava. In Gabriel, R.P., Bacon, D.F., Lopes, C.V., Jr., G.L.S., eds.: OOPSLA, ACM (2007) Neumayr, B., Grün, K., Schrefl, M.: Multi-level domain modeling with m-objects and m-relationships. In: Sixth Asia-Pacific Conference on Conceptual Modelling (APCCM 2009), Wellington, New Zealand. (2009) to appear 10. Atkinson, C., Kühne, T.: Reducing accidental complexity in domain models. Software and System Modeling 7(3) (2008) Atkinson, C.: Meta-modeling for distributed object environments. In: EDOC, IEEE Computer Society (1997) Klas, W., Schrefl, M.: Metaclasses and Their Application - Data Model Tailoring and Database Integration. Springer (1995) 13. Kühne, T., Steimann, F.: Tiefe charakterisierung. In Rumpe, B., Hesse, W., eds.: Modellierung. Volume 45 of LNI., GI (2004) Olivé, A.: Conceptual Modeling of Information Systems. Springer (2007)

23 Bisher erschienene Institutsberichte (seit 1996) Nr / Februar 1996 P. Brandl, H. S. Huber: Diagnose der Informationsverarbeitung: Der DASIE- Benchmark Nr / Oktober 1996 M. Schrefl, G. Kappel, P. Lang: Modeling Collaborative Behavior Using Cooperation Contracts Nr / Dezember 1996 I. Wiesinger, B. Hemetsberger: Evaluierung von Managementunterstützungssystemen Nr / Januar 1997 P. Lang, W. Obermair, M. Schrefl: Modeling Business Rules with Situation/Activation Diagrams Nr / Februar 1997 P. Bichler, G. Preuner, M. Schrefl: Workflow Transparency Nr / Jänner 1998 A. Mittelmann: Organisationales Lernen und Geschäftsprozessmanagement Nr / Mai 1999 M. Gappmaier, J. Siller: Partizipative Interaktionsanalyse Videogestützte Methoden für ganzheitliches Geschäftsprozessmanagement Nr / Mai 1999 M. Gappmaier, H. Merl, V. Pilsl: Das Organisationsgesundheitsbild Nr / Mai 1999 M. Gappmaier, M. Ruzicka: Partizives Gestalten von Geschäftsprozessen mit der Bildkartengestaltungsmethode (BKM) Nr / September 1999 I. Häntschel, H. Schmidt: Methoden zur Ermittlung des Informationsbedarfs des Managements Nr / September 1999 I. Häntschel, W. Erhart: Ein Vorgehensmodell zur strategiegeleiteten Einführung von Managementunterstützungssystemen (VEM) Nr / März 2000 G. Preuner, S. Conrad, M. Schrefl: View Integration of Behavior in Object-oriented Databases Nr / März 2000 G. Preuner, S. Conrad: View Integration of Life-cycles in Object-oriented Design Nr / April 2000 M. Schrefl, M. Stumptner: Behavior Consistent Refinement of Object Life Cycles