level models and discuss how reflection techniques can be used to create ... with domain-specific knowledge to create domain-specific building blocks, which ...
DOMAIN-SPECIFIC META-MODEL EXTENSIONS AND META-DATA MANAGEMENT IN REPOSITORY SYSTEMS Ilia Petrov, Stefan Jablonski Friedrich-Alexander-University of Erlangen-Nuernberg Martnesstr. 3, 91058 Erlangen, Germany {Petrov, Jablonski}@informatik.uni-erlangen.de
Abstract: Building applications in a flexible and extensible manner is a key requirement in a database environment. We argue that adaptability and extensibility can be guaranteed by the utilizing the concepts meta-modeling, notion building and reflection, which require the use of repositories. We present an approach, in which domain knowledge and meta-framework are combined to produce extended meta-schema. This combination facilitates application design. We show how the extended meta-schemata can be deployed into a repository and thus enforce structural consistency on objectlevel models and discuss how reflection techniques can be used to create meta-aware application programs.
1 Introduction In this paper we investigate database applications concentrating on their development and maintenance phase. Our goal is to provide sophisticated infrastructure to facilitate these issues. We investigate the advantages of meta-modeling and how method oriented meta-models can be enriched with domain-specific knowledge to create domain-specific building blocks, which eases the creation of information models and lead to reduction of complexity. Additionally, we study how reflection techniques can be used to benefit from the rich meta-information at run-time. Reflection assures a degree of decoupling of the application logic form certain specifics of the information model [5]. These observations motivate the transition from database to repository based applications since adaptability and extensibility are typical properties database applications must exhibit on the long run. These properties require a change in the application design style - a shift to open architectures whose key characteristic is the extensive use of meta-layers and reflection [7]. The proposed approach is technically motivated by two observations. Firstly, database applications are often complex and highly integrated. Various application domains must be supported in an application. In a typical application, e.g. e-Commerce applications, various types of data will be stored: product catalogues, manufacturing configuration data, delivery data, user data and user profiles. And secondly, changes to Database schemata are often necessary due to a number of reasons including system improvements, extensions to their functionality range, as well as changes in the legal environment.
133
1.1 Modeling and Formation of Concepts Let us now shift the focus onto modeling methods since they are instrumental for conceptual design of database applications. We will take a closer look on two orthogonal methods within the broad realm of modeling: formation of concepts and meta-modeling. In order to define what advantages meta-modeling can bring, let us first try to answer the central question - what is needed in order to be able to model, i.e. the minimal set of modeling primitives/constructs. We need a clear definition of type. A minimal definition of a type, as the relational model suggests, is: a type consists of attributes of a certain data type. By assuming such an oversimplified type definition we are not in a position to consider the leading programming approach nowadays – OOP. However, the chosen definition is simple and indicative for the purposes we set in this paper. We present the definition of a type T as follows: Def(T) : Tx { A1,Tx~DT1 .. An,Tx~Dk }, where – is type definition operation Tx – is type with a number X of the set of all types. Ap,Tx – is an attribute with number p[1..n] of a the type Tx. DTk – is a data type. Every attribute is of a given data type such that Ak{A1,Tx..An,Tx} DTp{DT1 .. DTk}. DT1 = dom(A1,Tx ). The symbol“~” is used to denote the fact that an attribute is of a data type. Every Type has instances. We define the function inst() to express instantiation. Ii,Tx = inst( Tx ), Ii,Tx {ITx}, where Ii,Tx – is the i-th instance of the type Tx {ITx} – is the set of all instances of the type (the type’s extent), Ii,Tx {ITx} The function inst() is type-instance or schema-instance relationship. This simplified type definition will be used to define notions in concept formation in a formal manner. On conceptual level (or modeling level) types are connected through relationships to express different kinds of dependencies (relations) between them. In our view the most important kinds of relationships are subordination (specialization/generalization), composition (aggregation, containment/decomposition, reduction), and connection. These concepts are present in any modern modeling language (UML, ERM etc.) and there is a native support of almost all of them in the implementation languages (OO languages, object relational database model, etc.) therefore the mapping can be done without significant loss of expressiveness. Abstraction is the process of generating a new (more general) concept (type or relationship), while concealing its internals [9], [11]. In conceptual modeling abstraction has to do with information hiding and in architectures with layering. Historically the simplest way of achieving abstraction in modeling (data-modeling) is through subordination and composition [8], [14]. Relationships are constructs typically existing on conceptual level (modeling level). They are mapped onto type definition constructs throughout the process of mapping the conceptual model on implementation language and are in the general case not separate constructs (types). For example aggregation is expressed as an attribute in the aggregate of type the part-class. For reasons of simplicity we consider the after-mapping types when formalizing composition and subordination.
134
Composition, aggregation and containment are just other names for the Part-Whole (Part-Of) relationship. Composition relationship is used to express the fact that the definition of type Tp is used as part of the definition of type Tw called an aggregate. Through composition we define the substructure of a type. The composition relationship has implication on the life-cycle of the aggregate (Tw) and the part-types (Tp) instances. The existence of instances the Part-Types (e.g. Tp) depends on the existence of the respective instances of Aggregate (the Whole e.g. Tw). By applying aggregation instances of the part types (Tp) can exist without a respective instance of the aggregate (Tw) for example Lawns can exist without a Building. Containment implies that no instance of the part type (Tp) can exist without a respective instance of the aggregate type (Tw) for example no instance of Room can exist without a respective instance of a Building. A unique instance of the Part-Type (Tp) exists for every single instance of the Aggregate (Tw). No two instances of the aggregate can reference the same instance of the Part-Type. The goal of using composition is to define composite (higher-order) types using lower-order types as constituents. An attribute AiTw of the type Tw exists whose data type coincides with the definition of the type Tp. In other words AiTw is of type Tp. Def(Tp):Tp{A1,Tp~DT1,..AqTp~DTx}, Def(Tw):Tw{A1,Tw~DT1,…AiTw~DTx,…An,Tw~DTk} Let us assume that DTx { Def( Tp ). But AiTw ~ DTx, and hence Def(Tp) { DTx { DTTw }. Thus Def(Tp) Def(Tw). Subordination and aggregation relationships are the foundations for formation of concepts. Inheritance and containment hierarchies can be built using subordination and aggregation relationships. Those two kinds of hierarchies are orthogonal to each other [8]. This fact becomes particularly evident on a meta-level. Subordination is a sub-type/super-type relationship, just another name for specialization/generalization. Other terms subordination is associated with are: inheritance, class hierarchies, inclusion polymorphism [16]. Using Subordination we can define common properties (attributes, methods) for a category (super-type) of types (sub-types). Let us assume that two types, Tb and Ts, are connected with a subordination relationship in a way that Ts is the super-type of Tb. The type definitions can be formulated as follows Def (Ts) : Ts { A1,Ts~DT1, … AiTs ~ DTx } and Def(Tb) : Tb { A1,Ts~DT1, … AiTs~ DTx, … An,Tb~DTk }. Here we assume public inheritance only and for reasons of simplicity choose to omit the other kinds of inheritance (e.g. private, protected). Under this assumption it can be stated that the sub-type Tb inherits the definition of the super-type Ts. Hence it can be written Def(Tb) : Tb { Def(Ts), … An,Tb~DTk } and thus Def(Ts) Def(Tb). This fact has the following implications: 1. The extent of Tb is a sub-set of the extent of Ts, thus {ITb} { ITs} 2. The set of attributes of Ts is a sub-set of the attributes of Tb and thus {ATs} {ATb} 3. The identity is preserved in case of relational or object-relational models. Identity(Ts) { Identity(Tb) or in other words PrimaryKey(Ts) { PrimaryKey(Tb) Connection is simply used to relate types, where no specific properties of the “association” exist. Connection is the most general type of relationship therefore we will define it on a conceptual level (before the implementation language mapping). Let Rp,ST be a relationship. Index p uniquely identifies the relationship within a language level. No two relationships are allowed to have the same index. Each relationship connects a set ST= { Tx, … ,T(x+k) }, k t 0 of k types. K=1 for self relationships; k=2 for binary relationships; k=3 for ternary relationships etc. For reasons of simplicity we ignore the fact that relationships may have attributes.
135
The set of all relationships be R = { Rp,ST }. Every Rp,ST can be instantiated. Its extent can be defined as follows: ri,p,SiT=inst(Rp,ST), rp,ST={ri,p,SiT}. The index i identifies instances of a relationship. The index p stands for the number of the relationship. Every instance ri,p,SiT of a relationship Rp,ST is associated with a set of instances SiT of the types belonging to the set of types ST. ri,p,SiT SiT = { Ii,T(x-k) .. Ip,Tx } such that Th = inst-1 (Iq,T(x-k) ), Th ST. By having these three notions at hand we can construct comprehensive new concepts and then are able to define a conceptual schema out of them. One essential characteristic of formation of concepts is the content oriented perspective. It is strongly related to an application domain. Using formation of concepts application designers model the problem domain. Good models contain general (and sometimes abstract) concepts to describe part of the concrete application domain (e.g. Medical services, CRM etc.). The more general and brighter the models the more the expertise in the concrete application domain they express. The application of formation of concepts is exclusively constrained within one language level (cf. Section 1.2). 1.2 Meta Framework Two-level approach comprising an information model level (data-level) and a meta-level (schemadefinition level) is not uncommon today. Typical example is XML, where the data level is represented by the XML document itself, and DTD or XMLSchema documents are the data definition level. The data level contains the concrete data stored in the xml file as instances of the respective schema. The DTD or the XMLSchema documents contain the definition of the schema used in the XML data documents. For instance, on data level we define that buildings B1 with rooms R1, R2, and B2 with rooms R3 and R4 are instances of the element BuildingType1. On the schemadefinition level we define that BuildingType1 is an element in the XML data file and that each building element consists of one or more Room elements. That is, as a first step the designer always defines (on the schema definition level) the elements used to define the data schema (like BuildingType1 and RoomType1 …). As a next step, now on the data level, the already designed schema can be populated with the respective data. From a meta point of view any system is organized as a stack of layers [5] [4]. Each layer is called a meta-level (denoted M0, M1, M2, M3) and is associated with a respective model (schema), e.g. model, meta-model, meta-meta-model (Fig. 1). The model on the layer (or language level) M0 is called an information model [13], which is a synonym for “conceptual model”, UML application model etc. [12]. The XML data document from the example above lays on the M0 level since it contains the data and the schema, whereas the DTD or the XML schema definition lays on M1. M2:meta-meta level
M1: meta-level M0: information models
Basic Modeling Constructs (types, relationships, attributes, data types, constraints)
E/R Modeling
UML
(entity types, relationships, attributes, data types, cont i t )
(classes, associations, attributes, data types, constraints)
ERM Information models
UML information models
Is instance of
Is instance of
Fig. 1. Modeling Constructs and Language Levels
The term “meta” is defined as change of the language level. On every language level there are types and data – instances of the types. A language-level higher in the hierarchy relative to a certain one
136
(and in particular relative to the information model level) is called meta-level (the prefix meta in the context of Fig. 1 expresses the relative stand of language level in hierarchy with respect to the underlying ones). The types on each meta-level are shortly called meta-types and their instances – meta-data or meta-objects. The type-instance relationship inst() is only defined within a single language level. In order to make the transition across the language levels, another kind of relationship is used – the so called referential relationship ref(). It stands for the fact that all model elements (e.g. types, attributes, data types) on a language level are associated with exactly one meta-data entry using the referential relationship. In order to illustrate how the references relationship will be applied let us consider the following. It expresses the fact that a Tt,(m+1) type on a meta level m+1 is reconstructed from types Tx,m on the underlying level m. Tx,m Ii,Tt,(m+1) {ITt,(m+1)} such that Ii,Tt,(m+1) = ref( Tx,m ) hence Tt,(m+1) such that Tt,(m+1) = inst-1[ ref( Tx,m ) ], where Tx,m – is a type on a language level m Ii,Tt,(m+1) – is a meta-data element associated with Tx,m through the referential relationship Ii,Tt,(m+1) = ref( Tx,m ). It is instance of a of the meta-type Tt,(m+1). Tt,(m+1) – is a meta type. Ii,Tt,(m+1) = inst(Tt,(m+1) ) Each data model regardless of which particular modeling approach has been employed is built using types, relationships, attributes, data types, constraints [2], [3], [11]. Relationships connect types; various characteristics of types are described by attributes. Attributes have data types and constraints control the allowable characteristics of an attribute. A meta-model is an explicit representation of a model’s structure, in other words each kind of modeling element is reconstructed as a type on a meta-level. Since there are structural containment dependencies among the model elements the respective meta-model types form a containment hierarchy (bill-of-material structure) [11], [19], [4]. For example, the fact that any entity type (like Building) contains attributes (like Area) is modeled with a containment relationship between the meta-types EntityType and Attribute on a metalevel.
2 Extended Meta-Schemata In this section we introduce the concept of semantically augmented meta-schemata or extendedmeta schemata shortly, which is the major contribution of this paper. We will introduce the concept based on an example coming from an architectural domain. We analyze the advantages of the proposed approach and propose a set of principles for construction of extended meta-schemata. The terms ‘meta’ and ‘formation of concepts’ are orthogonal. The term ‘meta’ has two significant implications: on the one hand it always implies change of meta-levels, on the other hand it is synonymous to explicit description of the structure of the models on the underlying level. The means in formation of concepts (e.g. specialization/generalization, composition etc.) can be applied on any meta-level. Formation of concepts is associated with the creation of domain specific knowledge; however, as stated in section 2.1, the use of formation of concepts is constrained to a single level. Parts of the domain knowledge (on level Mk) are independent on the respective Mk+1 schema. Such parts result from iterative generalization and abstraction and are of general validity for a concrete domain. Consider the following example: company XYZ is an architectural agency, which in general designs “Buildings”, which have only “Rooms” and a “Yard” (Fig. 2, Case1). Using only conventional modeling the schema of all projects XYZ develops have a schema derived form the domain knowledge as shown in Fig. 2, Case 1. As the example shows the domain knowledge shapes
137
the respective model since every building type is to be derived from “Building”. However, it is still a part of the information model, which leads to limited reuse and local scope of such knowledge. Hence the idea of transferring parts of the domain knowledge modeled on level Mk to level Mk+1. The result is a meta-model containing structural information tailored with certain domain-specific concepts (extended meta-model), cf. Fig. 2, Case 2. These domain concepts can then be used as building blocks to underlying Mk models. Although the domain knowledge transfer can be applied between any two adjacent levels, it brings concrete practical benefits when applied between M0 and M1. isa
Room
b_r_1 DetachedHouse b_y_1
LivingRooms
b_r_2
isa isa
BathRooms
b_r
Building b_y
Yard
Garden Case 1
M0: Model for a XYZ-designed Detached House Type
Case 2
isa
Relationship
bhy
bhr Room
EntityType
M1: Meta-Schema
M0: Domain Knowledge XYZ
Aggregation
M1: Domain Extension
Building hasRooms
Yard hasYards
M0: Information Model
LivingRoom
hr1
DetachedHouse
BathRoom
hy2
Garden
hr2
Fig. 2. Information model and Extended Meta-model
Referring to our example with company XYZ, “Buildings” “Rooms” and “Yards” can be modeled as subclasses of the class “EntityType” (or the class “Class” when using UML) on M1 and therefore used as building blocks for different XYZ specific models on M0 (Fig. 2, Case2). The M0 level concepts “LivingRoom”, “Bathroom”, “Garden” and FamilyHouse are instances of the M1 concept “Room”, “Yard” and “Building” respectively (See Fig. 2). The relationships “hr1” and “hr2” connecting the M0 types “LivingRoom”, “BathRoom” and “DetachedHouse” are instances of the M1 relationship type “hasRooms” and therefore carry containment semantics. Attributes are left out for reasons of simplicity, but similar reasoning applies to them as well. The practical result is that any information model using the extended meta-model can utilize both extended M1 concepts (like “Building”) as building blocks and the semantics as modeling rules. Under building blocks we mean the meta-types “Room”, “Building”, “Yard” and the relationship meta-types “hasRooms” and “hasYards”. All of them serve as primitives to the M0 information model. Instantiating these primitives results in creating types with predefined structure (as to what attributes they have, with what relationships they can be connected etc.) on information model level. Semantics is a complementary issue, since we can prescribe what relationship types (e.g. “hasRooms”) can connect instances of the derived meta types (e.g. “Room” and “Building”) based
138
on relationships like “bhr”. Declarative nature of the modeling achieved by this approach is clear. The advantages it provides are discussed in more details in sections 2.1, 2.2, 2.3, 3.1. The process of creating the meta-schema itself is called reconstruction. Reconstruction is a process which is rarely performed, since on the one hand it is very complex and logically exhaustive, and on the other hand the meta-schemata are subject to standardization (cf. [4], and the Open Information Model [20]). We define meta-modeling as the process of extending the meta-schema with domain specific concepts as shown in Fig. 2. In this respect meta-modeling is based on reconstruction. In practice there will be a need to perform meta-modeling much more often; therefore we define certain “meta-modeling” principles that in our view greatly facilitate and simplify the metamodeling process: Principle 1: Derive a new sub-type of the meta-type “Relationship” to create domain specific relationship type. The same applies to all modeling elements such as EntityTypes, Attributes etc. Principle 2: Always use a ternary relationship connecting two derived EntityTypes and a Relationship type to express the fact that types, instances of those types, can be connected with relationships of the respective relationship types. We assume binary relationships. For example we use the ternary relationship “bhr” (Fig. 2, Case2) to express the fact that types of type “Building” can only be connected with types of type “Room” through relationships of type “hasRooms”. Corollary: Never connect two meta-types (having common super-type in the containment hierarchy) with a relationship other than subordination. Principle 3: Always use an aggregation relationship to relate derived Attribute types to a derived EntityType. There are at least three major advantages of the proposed modeling approach: precise modeling; an explicit method for implementing structural control; more open application design. 2.1 Structural Control Structural constraints are constraints applied to an artifact to enforce limits on structure of its derived artifacts in a certain way. Through structural constraints a designer can define a set of types and ensure the conformance of all derived types, i.e. the structure of designer defined types will be automatically propagated to all newly derived ones. For example, the fact that the relationship type “hasRooms” is related to “Room” and “Building” on M1 imposes the constraint that all instances of these classes (LivingRoom, BathRoom and DetachedHouse) can only be connected with relationships instances of “hasRooms” (hr1, hr2). Furthermore relationships instances of “hasRooms” cannot connect type instances of “Yard” such as “Garden”. Conventional RDBMS offer no mechanisms for exercising structural control. In object relational databases (ORDBMS) structural constraints can be implemented partially because of the support for inheritance, overloading and overriding. There is, however, no way to guarantee that a sub-type will follow the constraints specified in a super-type, i.e. no way to guarantee that a sub-type will implement a given method, for example. Furthermore SQL’99 and the ODMG model support only public inheritance which reduces the degree of structural control. In classical OOP “Building”, “Room” and “Yard” can be implemented as abstract types (abstract classes and/or interfaces). We can generalize this by saying that polymorphism (and especially universal polymorphism [16]) is the means to express structural constraints in OOP.
139
2.2 Precise Modeling Precise modeling views the issue of structural control from another standpoint. The domain knowledge types on M1 have the role of modeling building blocks. They have both the semantics of the specific application domain and the structural implication of meta. The degree of consistency between the models, the meta-schema and the domain extension is very high. Therefore we can say that the models are precise from designer’s perspective. No known approach supports the definition of modeling building blocks. First define the building blocks of your model. For example, derive “building” and “room” from EntityType, derive “hasRooms” from “relationship”. Second, design the real model using those building blocks such as “DetachedHouse” “hasRooms” “LivngRoom” and “BathRoom”. Using such approach the application designer can both create a model and ensure that the semantics of the model is correct. 2.3 Open Programming The extensive use of the meta-level as a run-time catalogue translates into a mechanism for more open programming. Two of the relevant aspects are run-time state documentation and decoupling of programming modules. One of the key advantages of metadata catalogues, such as metadata catalogue in RBDMS, is that they provide information to an application about itself. For example, an application program can determine during run time what kinds of constraints are imposed on a database table or how full a specific database table space is and so on. The extensive use of metadata catalogue can lead to a higher degree of decoupling between application modules. This fact leads to increased levels of reusability and allows modules to be implemented in a more generic way. For example, a model exporter and a design module in an architectural system would be in the best position to cooperate sharing the same extended meta-schema as shown in Fig. 2. In theory such decoupling would be possible by using just the meta-schema. In practice, however, it is difficult to achieve since the different modules should share at least some knowledge of each other. An elegant way to achieve this and still preserve high degree of decoupling is to use the meta-catalogue containing extended meta-schema (Fig. 2). In order to handle the extended meta-schemata and let application programmers and designers draw the full benefit out of them we need more powerful reflection mechanisms. The need to handle modifiable (non-read-only) meta-schemata is a leading factor. Similarly important factor is the need to have intuitive constructs and easy-to-use API with giving programmers rich capabilities.
3 Repositories 3.1 Reflective Application Programming Reflection is “the ability to manipulate as data something representing the state of the program during its execution” [6]. Reflection mechanisms allow a regular program to access a meta-data catalogue. There are two kinds of reflection: introspection and intercession. Introspection is ‘the ability of the program to observe its own state [6]. This implies that the program has a ‘read-only’ access to the meta-data catalogue. The program can retrieve (reification) and interpret the meta-data information in order to perform certain action on information model level. Examples of introspection implementations are the Java Reflection API [7] or RTTI [10] mechanism in C++ (partial introspection implementation, [6]). Introspection allows calling a getting class of an object at run-time, invoking a method without knowing its name, setting the value of a field retrieving its name at run time, or traversing the generalization hierarchy in which the class of an object may participate. This
140
allows programmers to write more generic applications disregarding the details of the concrete classes. In the field of relational database systems introspection can only operate on the (read-only) meta-data catalogue. Reification can be shortly defined as “the ability of the program to access the metadata as regular data” [6]. Reification is a method to “bundle” metadata and system state in regular language constructs. In Java Reflection API for example metadata classes can be accessed as regular objects, in RDBMS the (metadata) database catalogue is accessible as regular tables. A tight coupling between the reflection and implementation language (Java, C++, SQL) yields flexible program code and “handy” programming constructs. For example, Java defines the language literals ”Class” and “Object” to handle meta level entities on information model level. Flexible support for introspection and rich reification language constructs are of large practical value to application programmers. These two issues allow programmers to take full advantage of the method proposed in the previous section. 3.2 Repository Systems The idea proposed in Sections 1.1, 1.2, and 3.1 is based on the fact that meta-models are not static (read-only), rather they can be extended with the domain knowledge. To implement it we need a database which would allow support for changes in its meta-catalogue. The authors are not aware of any existing database system with such characteristics. Repositories, however, are a good candidate for a target system. There is a number of definitions of what a repository system is [1], [3]. A repository acts much like a database; however it supports modifiable M1 level models. Therefore the extended meta-models can be deployed in the repository utilized further. A repository system implements the meta-level stack discussed in Section 1.2. The repository system takes the burden of preserving the consistency between extended meta-model and M0 models, i.e. the repository enforces automatically what the extended meta-model defines in terms modeling building blocks and structure onto the M0 models (structural and meta-terminological control). In order to enable applications to make the most out of the advantages the meta-framework provides, they must support rich reflection mechanisms. These mechanisms are more powerful than the ‘conventional’ reflection APIs like RTTI or Java Reflection [7]. Repositories should also offer handy reification mechanisms. This is a challenging task in light of the fact that many application programs written in different languages can use the repository. Both the reflection and the reification mechanisms are part of the repository interface. Its importance is discussed in [13]. In the iRM project we have created a repository prototype implementation as a part of a larger process modeling system; for more details see [24].
4
Related Work
The process of reconstruction and the theoretical properties of meta-data and multiple language levels are described in [3],[2]. The multiple language level framework is defined in [21]. OMG MOF [4] is a standard meta-meta-model defined by the object management group. MDC Open Information Model is a part of OMG MOF. Characteristics of repository systems are defined [1],[12]. An architecture of a repository system is defined in [22]. A similar proposal for domain extensions of the UML meta-model for the Workflow domain based on stereotypes is discussed in [18]. Another similar two-level modeling approach is proposed by [17]. Reflective meta-object architectures are defined in [7],[23]. Aspects of aggregation and specialization hierarchies are defined [8], [14], [15].
141
5
Conclusions
In this paper we proposed a new approach that facilitates the development of applications based on a combination of formation of concepts and meta approaches. The combination of these two techniques leads to meta-schemata enriched with domain knowledge, and results in creating building blocks for modeling domain specific models. This approach contributes to producing semantically correct model, fostering reuse, and reduction of complexity. We motivate the use of repository systems as successor of database systems as target of the extended meta-schemata. Last but not least we point out the role of reflection mechanisms allowing application programs to take full advantage of new capabilities a repository offers.
References [1] BERNSTEIN, P., Umeshwar Dayal: An overview of repository technology. Proceedings of the 20th VLDB Conference Santiago Chile, 1998 [2] ORTNER, E.: Aspekte einer Konstruktionssprache für den Datenbankentwurf (Aspects of a construction language for database design), Darmstadt 1983 [3] ORTNER, E.: Wissensmanagement Teil 1 und 2 Informatik-Spektrum, Volume 23 Issue 2 (2000) pp 100-108 [4] Object Management Group: Meta Object Facility Specification Version 1.4. http://www.omg.org/technology/documents/formal/mof.htm [5] CZARNECKI, K., Eisenecker, U.: Generative Programming., Addison-Weseley, 2000 [6] GREEN, D.: Java Reflection API. http://java.sun.com/docs/books/tutorial/reflect/ [7] BUSCHMANN, F.: Pattern-orientierte Softwarearchtecktur, Adison-Wesley, 1998 [8] SMITH, J.M., Diane C.P. Smith: Database Abstractions: Aggregation and Generalization, ACM Transactions on Dstabsse Systems, Vol. 2, No. 2, June 1977, Page 103-133. [9] KAKKAD,S. V., Mark S. Johnstone, and Paul R. Wilson: Portable Run-Time Type Description for Conventional Compilers, USENIX '97, 1997. [10] MITELSTRAß, J.: Enzyklopädie Philosophie und Wissenschaftstheorie, B.I.-Wissensverlag, 1980 [11] WEDEKIND H., Schlundt M., Neeb J. "Repositories for Workflow Management Systems in a Middleware Environment", 33rd Hawaii International Conference on System Sciences, 2000 [12] BERNSTEIN, P.A.: "Repositories and Object Oriented Databases." SIGMOD Record 27 p.88-96, 1998 [13] SINGH, I., Stearns, B., Johnson, M.: Designing Enterprise Applications with the J2EE Platform, Adison-Wesley, 2002 [14] HENDERSON-SELLERS, B. “Towards the formalization of relationships for object modeling” Technology of ObjectOriented Languages and Systems, 1997. TOOLS 25, Proceedings [15] HENDERSON-SELLERS, B., Barbier, F.: Black and White Diamonds, proceedings of ’99, Beyond the Standard, Fort Collins, USA, Lecture Notes in Computer Science #1723, 1999 [16] CARDELLI, L., Wegner, P.: “On Understanding Types, Data Abstraction and Polymorphism.” In ACM Computing Surveys. Vol. 17, No. 4, 1985 [17] LAUDER, A., Kent, S.: Two-Level Modeling [18] SCHLEICHER, A., Westfechtel, B.: "Beyond Stereotyping: Metamodeling Approaches for the UML" Proceedings of the 34th Hawaii International Conference on System Sciences – 2001 [19] GRAY, J., Reuter, A.: “Transaction Processing: Concepts and Techniques”, Morgan Kaufmann Publishers, 1994 [20] Meta Data Coalition. The Open Information Model, http://www.mdc.org [21] IRDS, ISO Standard, “Information Technology- Information Resource Dictionary Standard”, ISO Ref. Nr 10027:1990, 1990 [22] BERNSTEIN, P. A., Bergstraesser T. et al. 1999. "Microsoft Repository Version 2 and the Open Information Model." Information Systems, 2(24), 1999, pp. 71-98, [23] FOOTE, B., Yorder, J.: “Metadata and Adaptive Object Models“, Proceedings of the Plop98, 1998 [24] iRM Project, 2004. http://www6.informatik.uni-erlangen.de/DE/research/projects/irm/
142
