Home
DRAFT


Meta-modeling and meta-model extensions in the construction of software

Alar Raabe


Department of Computer Engineering, Tallinn Technical University, Ehitajate tee 5, 19086 Tallinn, Estonia; alar@aetec.ee

Received 3 June 2001

Abstract. For an effective analysis and design process, an analyst and a designer should be provided a more specific framework than generic analysis and design meta-models (e.g. a UML meta-model) can offer. Extensions of latter can be used in software engineering as a guiding framework. An extended analysis meta-model that embodies domain specific knowledge provides guidance to analyst during the analysis process, and similarly an extended design meta-model that embodies architecture specific knowledge provides guidance a designer during the design process. This article studies the problems of combining several meta-model extensions and offers a solution to the interoperability of meta-model extensions. Additionally, we discuss how model transformations use meta-model extensions.

Key words: meta-modeling, meta-models, meta-model extensions, UML.


1. Introduction

Generic analysis and design meta-models, like the meta-model of the widely used UML, are not of use to analysts and designers during the analysis and design process of a system, except for providing a very generic conceptual framework. To achieve higher effectiveness of the analysis process, a more specific conceptual framework that embodies domain specific knowledge is needed. The need for such extensions to generic meta-models has resulted in a number of efforts to develop domain specific meta-models for business modeling (e.g., Object Management Group (OMG) UML profile for Business Modeling [1] and Eriksson-Penker Business Extensions for the UML [2]), for analysis and description of enterprise-wide data structures and conversions between them (e.g., OMG Common Data Warehouse Meta-Model – OMG CWM [3]), for modeling business workflows (e.g., Workflow Management Coalition Meta-Model [4]).

Analysis and design processes will produce artifacts that are easily mapped to the implementation constructs. If such mapping is automatic, it will help to apply convergent engineering principles to software design [5] and to develop model-based systems. This is possible only if the analysis and design meta-models are rich enough to capture technical details needed for such mappings.

When meta-model extensions are used, they must be combined because a suitable meta-model extension is unlikely to exist for every situation. Different parties usually create these meta-model extensions and therefore mechanisms used to combine meta-model extensions must ensure interoperability.

2. Background

The following four areas cover the background of this work:

    1. Insurance applications as an example of the problem domain, which is sufficiently complex.
    2. The convergent engineering or model driven approach to software construction [5].
    3. Product-line architectures and the construction of product-line members.
    4. The product-line architecture for insurance applications, developed under the guidance of the author, as an example of an application of meta-model use and combining in software construction.
2.1. Insurance applications

Due to deregulation, globalization and competition in the insurance market, shorter development cycles for supporting software should be achieved, and moreover, a tendency exists to develop more complex products that cannot be managed without supporting software. Insurance products must be configurable and customizable in response to concrete customer needs. Because of acceleration in the development of information technology, a constant need exists to build new systems on, and to port existing systems to new base technologies. The requirement of the portability of supporting software to new base technologies leads to the requirement of models reusability, for combining them with different implementation architectures.

The insurance business domain has to deal with a variety of realities that surround us, involving risks that can be connected to anything and business processes and the corresponding business rules that govern these business processes. This leads to potentially very large and complex domain models. Insurance products that can be composed of elementary parts to cover certain risks involve complex business rules and compose a large domain, which must be separately modeled before the systems to support these products can be built.

Therefore the modeling activities performed during the development of insurance software would benefit from the analysis and design meta-models extensions specialized towards representing business processes, business rules and insurance products.

The required short development cycles of insurance software benefit from implementation generators, which use the additional information contained in the extended models to generate large parts of systems.

2.2. Convergent engineering

Today changes in business have become a norm. Business processes and therefore business systems must be adaptive to the changes. Divergent systems, where business and the supporting software are designed separately, show resistance to changes. A solution to this problem is to build convergent systems, where business design (i.e. business structures and business processes) is implemented directly in the software.

Convergent systems are model-based, where the goal is to construct software models that represent the structure and operations of a business as simply and directly as possible.

Model-based systems have the following advantages:

      • They simplify the software engineering process and reduce the total amount of work because only a single system based on a business model will be designed and implemented.
      • They eliminate gaps between business processes and their supporting software, because the same system can be used to execute everyday business processes in real time, to forecast a business outcome and simulate the proposed changes to the structure and business processes, and to represent the structure of a company and the business processes.
      • They facilitate a change by minimizing the problem of coordinating modifications to the business processes and the supporting software.
Generic meta-models of object-oriented analysis and design do not provide direct concepts for modeling business structures and business processes.

Therefore meta-model extensions are needed to support convergent engineering and to automate software construction. These meta-model extensions should provide enough information for mapping a business model to the base technology and supporting model-based approach in software development.

2.3. Product-line architecture

To be able to reduce the duration of a development cycle and software construction costs, software must be produced in batches of similar software systems – product-lines, which are based on the so-called product-line architecture. This organization facilitates reuse of the artifacts produced, that of knowledge and techniques acquired, and that of efforts made during software construction.

Shaw and Garlan define the software architecture as the definition of a software system in terms of computational components and interactions between those components [6].

Bass, Clements, and Kazman define the software product-line architecture as a software architecture that is shared across more than one system, product, or family of products [7].

Alternatively, the software architecture may be defined as a sum of design decisions made during the software design [8]. Accordingly, the software product line architecture is the sum of early (pre-made) design decisions.

As shown in [7], sharing a common architecture between several products enables us to reuse several artifacts (software components, project documents, prototypes and demos), skills, tools, processes and results (like performance improvements and eliminated defects) produced during software construction.

Members of the product line may reuse the product-line architecture to a different extent.

2.4. Application – Once&Done®

Next we will examine briefly a concrete application developed under the guidance of the author at the Progressive Financial Technologies Ltd., sold under the registered trademark Once&Done®. Once&Done® is a product-line architecture to support the creation of insurance applications based on the convergent engineering principles and a special business model, which all belong to the same product-line and are based on the common object-oriented architecture.

Once&Done® product-line architecture consists of following:

      • Models, which are: meta-models that support object-oriented analysis of the insurance domain – the insurance specific extension of the meta-model of the traditional object-oriented analysis, and analysis models of the insurance domain – used as a basis of analysis during a concrete insurance system creation organized according to the main elements of the insurance domain (like party, policy, insurable, coverage) and according to the business lines of the insurance business (like property and casualty insurance, life insurance).
      • Framework, consisting of elements which implement technical (base) services for building object-oriented business software – an environment for business objects. This framework defines interfaces for implementing concrete business objects identified in the business domain and the concrete business functionality. Additionally, this framework contains a generic implementation of insurance domain models and the related insurance functionality.
      • Process, containing the description of steps and tasks required to create a member of the product-line, and based on the object-oriented paradigm. The goal is to support the creation of the insurance software based on the Once&Done® product-line architecture, maintaining the quality and predictability, identification of reusable elements and the accountability (visibility) of the process.
      • Tools, containing facilities for using the framework and models according to the process to produce members of the product-line. A central tool is the Once&Done® Specification Environment (OD-SE), which implements the extended analysis and design meta-model and is an electronic environment supporting the process of building members of the product-line. The basic components of OD-SE are: the repository based on the extended meta-model, document management, discussion, and project management applications. Additionally, tools contain various generators, which permit to generate concrete implementations of business objects based on the information in the OD-SE repository. OD-SE permits to connect several OD-SE repositories, enabling one to create members of the product-line by combining multiple existing models.
3. Meta-model extensions

In terms of the UML a meta-model has been defined differently, however our our study is based on the following statements:

      • a meta-model is a model that defines the language for expressing a model.
      • a meta-model defines the structure and semantics of the meta-data (data that describe the information).
The OMG Meta Object Facility (MOF) and the UML together form a four-layer meta-modeling architecture described in [10], where meta-models are in the second layer, above the model and actual data.

Because the UML [1] is the most widely used modeling language today, established as a single standardized modeling language, in this article we will discuss only the meta-model extension mechanisms available in the UML.

4. Meta-model extension mechanisms in the UML

The meta-model of the UML can be extended either implicitly, using the extension mechanisms built inside the UML, or explicitly, using the MOF [10].

Implicit extension mechanism profiles impose restrictions on the modification of the UML meta-model. When extending the UML meta-model explicitly using the MOF, such restrictions do not apply. In principle any meta-model can be defined and registered in the MOF.

Therefore every profile definition can be expressed as a MOF meta-model, but not all MOF meta-models that extend the UML meta-model, can be expressed as a proper UML profile.

4.1. Implicit meta-model extensions – UML Profiles

The meta-model of the UML can be implicitly extended via stereotypes, tagged values, and constraints.

Stereotypes, the main mechanism of the implicit UML meta-model extension, are new meta-model elements, which are subtypes of existing meta-model elements. To store additional properties not supported by the base meta-model element, stereotypes might use tagged values. Stereotypes may also have a set of constraints to be added to the set of constraints of the meta-model element which is extended by a stereotype.

In the proposal for the UML v1.4 [11], the definition of the stereotype will be changed. Instead of using a tagged value for representing the relationship between a meta-model element and the stereotype, an association with the stereotype “stereotype” is used. Still, it is not clear whether it is possible to use the specialization relationship between the stereotypes themselves.

Tagged values are properties which can be attached to any model element. They form a restricted extension to the meta-attributes of the meta-classes of the UML meta-model. If tagged values are attached to a stereotype, all the model elements conforming to this stereotype should have tagged values with these tags.

Constraints are restrictions imposed upon a set of model elements which cannot be expressed via the UML notation and are therefore represented as text expressions. If constraints are attached to a stereotype, all the model elements conforming to this stereotype must conform to all the connected constraints.

The consistent set represented as a package of implicit UML meta-model extensions (stereotypes, tagged values and constraints) and standard model elements (e.g. comments) is called a UML profile. A UML profile can also have a set of prerequisite profiles required to define the given profile.

The main advantage of UML profiles is the support by all compliant (“off-the-shelf”) UML tools.

The main constraint when using UML profiles is that they can only extend the UML meta-model strictly additively, therefore profiles cannot change the existing semantics of the UML, they can only extend it.

4.2. Explicit meta-model extensions – using MOF

The meta-model of the UML can be extended via the MOF, by explicitly adding new meta-elements to the meta-model.

In principle, any meta-model can be defined and registered in the MOF, therefore every profile definition can be expressed as a MOF meta-model, but not all MOF meta-models that extend the UML meta-model can be expressed as a proper UML profile.

Graphically, it is possible to use the UML for representing the MOF models (UML meta-models).

The advantages of defining a MOF meta-model instead of a UML profile are as follows:

      • it is possible to introduce completely new meta-model elements, which cannot be sub-typed from the existing UML meta-model elements
      • it is possible to introduce classification hierarchies of new meta-model elements
      • the structure of a meta-model extension is better represented
      • description of a model is easier, because a familiar UML notation can be used instead of some different notation for meta-elements as in the case of implicit meta-model extensions
      • it is possible to use the meta-models other than modeling tools and exchange the meta-models between different tools.
If for the classifiers which represent more primitive things in the model, like classes, associations, it is useful to impose the constraint of additivity of changes, which ensures the substitutability of child classifier instances with the parent classifier instances. That is the case when the classifier is extended through the specialization, all the changes done via inheritance in the child classifier must preserve the semantics of the parent classifier.

For models, as packages, there are also generalizable elements, but not classifiers, substitutability is not required and therefore it is possible to implement generalization not only by adding features, but also by changing and removing them.

5. Use of meta-model extensions

There are several phases of software development, where meta-model extensions are useful. Three main phases are: analysis, design and implementation. Additionally, meta-model extensions can support other activities during the software construction process. Meta-model extensions can also represent the structure of additional information about the software models that are used to support the expert systems for software engineering and knowledge bases about the software components [14].

5.1. Example of a meta-model extension

As described previously, possible insurance products that can be composed of elementary parts to cover certain risks involve complex business rules and compose a large domain, which must be separately modeled before the systems to support these products can be built. As an example, let us describe following objects in this domain:

      • insurables – represent insurable interests of a customer
      • coverages – represent complete insurance products and parts of insurance products, covering insurable interests
      • risks – represent risks against which the insurable interests can be insured.
In real cases, many more elements are identified in this domain and used to describe the insurance products, but we will restrict our model with these three elements.

To give a business specialist a suitable language for representing insurance products, which would be understandable also to a software specialist, we could represent the given example domain as an extension of analysis meta-model.

As was described previously in the case of the UML, two ways exist to extend the meta-model: the implicit and explicit way.

In the case of implicit meta-model extension we can define a profile for the insurance products to be defined using the UML, as shown in Fig. 1.


Fig. 1. Stereotypes for representing insurance products.


In the case of an explicit meta-model extension we have to use a MOF model that represents the extension and can be represented using the UML as shown in Fig. 2.

Fig. 2. Meta-model extensions for representing insurance products using the MOF.


As can be seen, in the second case the structure of the meta-model extension is clearer represented.

5.2. Meta-model extensions for analysis

Meta-model extensions for analysis embody the domain knowledge. In the case of the UML sample meta-model extensions are described in the UML standard for analyzing the software development process – “UML profile for Software Development Processes”, and for analyzing business processes – “UML profile for Business Modelling”. As such, they guide the analysis process and provide a system of related concepts or paradigms specialized for the concrete problem domain.

Meta-model extensions for analysis are a result of domain analysis and represent concepts identified as characteristic concepts of the given problem domain.

Analysis meta-model extensions are especially suitable for well-defined and analyzed problem domains, where a bulk of background knowledge exists and where a general purpose modeling language which lacks this background knowledge would make models too complex.

As described earlier, product modeling is a substantial part of the modeling needed for insurance systems development (as well as for business engineering in insurance businesses).

As an example of an extended analysis meta-model use in the insurance domain we present an analysis meta-model extension (implemented as an UML profile) for modeling insurance products, which contains stereotypes of classes «Insurable», «Coverage», and «Risk», representing corresponding domain objects.

A model of a simple insurance product, containing two alternative coverages, the “Regular” which covers risks of fire and flood and the “Premium” which covers additionally risk of liability, modeled by help of this meta-model extension is shown in Fig. 3.


Fig. 3. Model of a simple insurance product.


Such meta-model extensions can be implemented either as UML profiles or as explicit extensions to some suitable generic meta-model (e.g., UML meta-model), using the corresponding meta-meta-model, which in the case of the UML is a MOF meta-model.

5.3. Meta-model extensions for design

Meta-model extensions for design, as a rule embody knowledge related to the design decisions. For example, in the case of the UML, several meta-model elements exist that represent concepts from the object-oriented programming (OOP) (stereotypes like «interface», «implementation», «utility» and meta-model elements like Component, Method). Additional meta-model extensions that are specific to a certain architectural style, implementation technology (e.g., middleware technology, like OMG’s Common Object Request Broker Architecture (CORBA) [15] or Sun’s Enterprise Java Beans (EJB)) or chosen programming environment can help the transition from the analysis model to the design model.

Meta-model extensions for design are a result of architectural, design and implementation decisions that are made beforehand.

These extensions are particularly suitable for supporting reuse through the product line [7] or product family [16], based on the same architecture and implementation technology. In this case, the design meta-model extensions provide transparency to the reuse of the artifacts of product family architecture to the designer.

Insurance companies need to manage data in the following two orthogonal time dimensions:

    1. The validity time of data – each piece of information stored into the information system should have the validity time attached. All information must be retrievable based on some target date which defines the point in time when this information is valid. Similarly, all operations upon information should be done at some target time, which defines the point in time when the changes resulting from the operation are valid. This is needed, for example, to deduce which agreement data were valid when the event stated in the claim occurred.
    2. The transaction time of data – every piece of information should be stored immutable and have the transaction date attached to enable the full auditability of all the changes made in the system. This is needed for accountability reasons.
Additionally, a need can exist to introduce the time dependent functionality – for example, business rules could also have validity periods. In the case of object-oriented (OO) analysis and design it corresponds to different business types (behavior) of different versions of data.

If the design model for an insurance system should include all the constructs needed to represent the time related, the model would be overloaded with the details that obscure the constructs representing the domain concepts and would make the understanding of the model very difficult.

As an example of a design meta-model extension in the insurance domain, we can present a design meta-model extension (implemented as a UML profile) for modeling temporal entities needed in the insurance systems, which contains the class stereotype «Temporal», the association stereotype «Temporal», and the operation stereotype «Temporal».

A model of simple insurance policy, consisting of coverages that are association classes describing a relationship between an insurable and a risk, modeled by help of this meta-model extension is shown in Fig. 4.


Fig. 4. Model of an insurance policy using the meta-model extension with temporal elements.


As in the previous example, such meta-model extensions can be implemented either as UML profiles or as explicit extensions to some other meta-model.

5.4. Meta-model extensions for implementation

Meta-model extensions for implementation generally embody the knowledge related to the implementation facilities. For example, in the case of the UML several meta-model elements exist that represent concepts from the general information technology (IT) systems domain (stereotypes like «file», «executable», and meta-model elements like Component, Subsystem).

Meta-model extensions for representing the detailed information needed to generate an implementation of a software system permits to develop application generators which can generate either a fully functional software system or a framework of a system, based on the extended model (a model that is an instance of an extended meta-model).

As an example of meta-model extension implementation, we can present a design meta-model extension (implemented as a UML profile) for attaching the information needed for the implementation generator to the model elements, which is geared towards generating a code for EJB servers [17] and contains the class stereotypes «EntityBean», «SessionBean», and «Dependent».

A model of simple insurance policy, used in the previous example for design extensions, modeled using this meta-model extension is shown in Fig. 5.


Fig. 5. Model of an insurance policy using a meta-model extension for the EJB implementation.


Again, such meta-model extensions can be implemented either as UML profiles or as explicit extensions to some other meta-model.

5.5. Meta-model extensions for other areas of software engineering

There are several other areas where the meta-model extensions prove useful:

      • software process organization and software process modeling (e.g., UML Profile for Software Development Process [1])
      • enterprise level distributed systems modeling [18]
      • modeling the quality of service issues (e.g., a request for a proposal for the UML Profile for Modeling Quality of Service [13])
      • test planning and organization of testing (e.g., a proposal for the UML Profile for Testing [12])
      • data warehousing (e.g., OMG Common Warehouse Metamodel [3]).
6. Combining of meta-model extensions

As described above, several areas exist in the software construction process where the meta-model extensions are useful. In principle, it is possible to construct an analysis and design meta-model which contains all the required extensions as a whole. In practice, this would be extremely difficult, because

      • different meta-model extensions needed and applicable during different activities in software construction are usually defined by different parties at different times, and it is often impossible to synchronize these efforts
      • different meta-model extensions used by different tools are determined by these tools and cannot be easily changed, furthermore other considerations exist besides the supported meta-model extensions of tools that affect the choice of concrete tools
      • to support the porting of software to a different base technology, a need might exist to change the meta-model extensions specific to the given base technology, so there is a need to be able to re-combine the meta-model extensions.
As shown in the Fig. 6, transformations between different models which possibly use different meta-model extensions are another application, where we need to combine source and target meta-models and their extensions to be able to represent the transformation rules which need to access concepts from both meta-models.

Fig. 6. Need for combined meta-models for model transformations.


Several ways exist to combine meta-model extensions in the UML.
    1. In the case of implicit meta-model extensions or profiles, it is possible to apply several profiles to the same model.
    2. In the case of explicit meta-model extensions, it is possible to apply several mechanisms that are applicable to combine MOF models [10] because in the OMG four layer meta-modeling architecture MOF is used to represent the UML meta-model. Because the UML meta-model is also defined in the UML itself, it would be possible alternatively, to apply mechanisms that are applicable to combine models in the UML.
6.1. Example of combining meta-model extensions

Figure 8 shows an example model that uses a combination of two different meta-model extensions, represented by UML stereotypes, needed if we want to express the implementation of temporal elements with the EJB technology, based on the previously described meta-model extensions for design (see Fig. 4) and implementation (see Fig. 5).

6.2. Combining of meta-model extensions in the UML

Next we will examine the techniques that can be used when combining meta-model extensions in the UML. These techniques are based on the assumption, that the UML meta-model is defined in the UML itself and, as such, meta-model extensions can be combined using the model combination mechanisms of the UML.

First, we will describe the combination of implicit meta-model extensions or a multiple UML profile and then several mechanisms of the combination of explicit meta-model extensions or meta-models.

6.3. Combining of multiple profiles

The UML allows using several profiles for the same model. The relationship of using the profile can be represented by the dependency between the models stereotyped as «appliedProfile» as proposed in the UML v1.4 [11]. Graphical representation of the combination of multiple profiles used in the example is shown in Fig. 7.


Fig. 7. Combination of multiple UML profiles.


An example combination of meta-model extensions, represented as a combination of two profiles, is shown in Fig. 8. To avoid the creation of dummy stereotypes that combine stereotypes from the combined profiles, it has been assumed that model elements can have multiple stereotypes.

Fig. 8. Example of combining meta-model extensions.


The current version UML [1] does not allow multiple stereotypes for model elements, but in the proposed new version of the UML [11], the model can contain elements which are stereotyped with multiple stereotypes. This makes the creation of artificial stereotypes which allow combinations of stereotypes unnecessary.

6.4. Combining of meta-models

If the meta-model extensions that are used in the example are defined explicitly and represented as UML models, we can use containment, importing or multiple inheritance of models. Because a model can be an instance of only one meta-model, we have to create an intermediate meta-model that combines the extensions represented by the meta-models we want to use.

The use of model containment to combine different extended meta-models is shown on Fig. 9.


Fig. 9. Combination of multiple meta-models by containment.


Contained model and combined model elements are encapsulated and are not visible to the combining model or each other. To be able to “see” those elements in the combining model, they have to be either imported or the combining model should be a specialization of all the combined models.

The use of model importing for combining different extended meta-models is represented in Fig. 10. The dependency with the stereotype «imports» in the UML describes an access permission, i.e., that an importing model imports all the elements with sufficient visibility from the supplier models, including elements of models imported by the supplier models that are given public visibility in the supplier.


Fig. 10. Combination of multiple meta-models by importing.


Elements imported from other models extend the namespace of the combining model. To avoid name conflicts, it is possible to rename the imported elements one-by-one. By default, the imported elements are given private visibility in the importing model, which can be changed during renaming.

The use of multiple inheritance of models to combine different extended meta-models is shown in Fig. 11. Because a model can have generalizations to other models, it is possible to construct taxonomic hierarchies of models. The mechanism of constructing the description of a specific model out of more general models is inheritance, i.e., the public and protected elements owned or imported by more general models are also available to its children – more specific models, and they can be used similarly to any element owned or imported by the child models themselves.


Fig. 11. Combination of multiple meta-models by multiple inheritance.


Elements inherited from other models due to generalization retain their name and extend the namespace of the inheriting model. By default, inherited elements have the same visibility both in the child model and in the parent models. It is not possible to change the name or visibility of inherited elements in the inheriting model.

There are several problems related to the meta-model extension mechanisms presented and to the meta-model combination mechanisms presented. We will analyze these next.

The main problem inherent to both of the methods of meta-model extension – implicit and explicit, is the requirement of extensions additivity.

6.5. Problems of implicit meta-model extensions

According to the UML standard, UML profiles can extend the UML meta-model only strictly additively, therefore profiles cannot change the existing semantics of the UML, they can only extend it.

Since meta-model extensions are described in the same framework as models (classification hierarchy of stereotypes is represented on a class diagram, which may contain ordinary model elements), modeling and meta-modeling activities can be easily mixed up and can lead to misuse of stereotypes. This is one of the main problems with the implicit meta-model extension mechanism, as described by Henderson-Sellers [19].

The current version of the UML [1] has a restriction that any model element could have only one stereotype. This forces the modeler to create an extra dummy stereotype to combine other stereotypes. In the proposed next version of the UML [11], this restriction is removed and any model element can have several stereotypes simultaneously.

Tags of tagged values form a flat namespace that must be managed by adopting conventions to avoid naming conflicts. The UML does not include any mechanisms for avoiding name conflicts of tags (e.g. like a registry of tags). Another problem with tags is that it is impossible to specify the type of the value of a given tag. This does not allow any type checking to take place in the modeling tool.

6.6. Problems of explicit meta-model extensions

When explicit meta-model extensions or MOF models are used, the following problems arise:

      • Explicit meta-model extensions are not supported by the majority of “off-the-shelf” tools.
      • Model interchange between tools requires that extended meta-model be available for both tools.
      • It is more difficult to combine and apply the same model:
        • several options for combining meta-models – containment, importing and multiple inheritance
        • meta-models can be constructed without any restrictions – more possibilities to create inconsistent meta-model extensions or such meta-model extensions that are difficult to combine with other extensions
        • need for an artificial combined meta-model if the multiple classification of models is not permitted.
6.7. Problems of combining meta-model extensions

Generic problems of combining meta-model extensions are as follows:

      • name conflicts;
      • conflicting meta-model elements (conflicting features, relationships and constraints);
      • cluttered resultant meta-model (because all of the combination methods are only additive);
      • it is difficult to change the used meta-model extensions of the model.
Unclear semantics of some stereotype being not the stereotype of a meta-model element, but a stereotype of some other stereotype is a specific problem with the implicit meta-model extensions – profiles in the UML.

A need for an intermediate meta-model which would combine several meta-models is a specific problem with the explicit meta-model extensions. This stems from the semantics of generalization relationship between the models and a meta-model, where the model cannot be an instance of several meta-models.

7. Solutions

In the next section we will examine which solutions could be used to avoid the problems previously described.

7.1. Solutions for extending meta-models

For implicit meta-model extensions, stereotypes should not be mixed with model elements, they should always be contained only in a special package stereotyped as «profile».

To make an unnecessary artificial stereotype whose only role is to combine several other stereotypes, multiple stereotypes should be allowed for one model element.

Tagged values should have the types given in the stereotype definition.

These solutions should be included into the next version of the UML [11].

Additionally, to avoid name conflicts when combining several profiles, a profile should act as a namespace for stereotypes and tags.

To avoid naming conflicts in the case of explicit meta-model extensions and facilitate interoperability between different tools, packages should be used as namespaces, making the names of meta-model elements locally unique. To avoid name conflicts, meta-model package structures could be formed similarly to the package names in the Java language or the Internet domain names.

7.2. Solutions for combining meta-model extensions

To avoid name conflicts, when combining meta-model extensions explicitly, meta-model combination techniques, like containment, importing and inheritance, should allow massive renaming of elements. The present UML mechanism for importing elements from another model allows only renaming element-by-element.

A possible solution to name conflicts is also a global name registry similar to the Internet domain name registries.

To resolve conflicts between meta-model elements, we propose to extend the semantics of meta-model combination via inheritance with override, substitution and deferring of meta-model elements during the combination.

To resolve the meta-model clutter, we propose to extend the semantics of meta-model importing with filtering.

Graphical representation of filtering and massive renaming is shown in Fig. 12.


Fig. 12. Extended semantics of meta-model combination via import.


Figure 13 presents an example of using the mechanisms described to combine two previously described meta-model extensions: design meta-model extension representing temporal concepts shown in Fig. 4 and implementation meta-model extension representing EJB specific concepts shown in Fig. 5, so that from first meta-model extension only extended classes and all base elements are imported (filter “ExtendedClassesAndBase”), and from second meta-model extension only extended elements are imported (filter “OnlyExtended”) and their names are prefixed with “EJB”.

Fig. 13. Example of meta-model combination via import.


The filters “ExtendedClassesAndBase” and “OnlyExtended” contain the constraint given in the OCL.

7.3. Resolving conflicts between meta-model elements

By the definition in the UML, model inheritance semantics is such that all public or protected elements which are owned or imported by the ancestor are also available in the specialized model under the same name and interrelated as in the ancestor.

As pointed out above, to solve the problem of possible conflicts between meta-model elements, we propose to extend the semantics of inheritance for the meta-model combination with override, substitution, and deferring.

When a meta-model element is overriden, the meta-model element in the ancestor is masked by the meta-model element in the child. This mechanism is analogous to the concept of overriding class features in the OOPL.

When a meta-model element is replaced, then the meta-model element in the ancestor is replaced by the meta-model element in the child (for instantiations of the child).

When a meta-model element is deferred, then the meta-model element in the ancestor is removed from the child or suppressed in the child.

Graphical representations of the described extensions of the meta-model inheritance are shown in Fig. 14.


Fig. 14. Extended semantics of meta-model combination via inheritance.


7.4. Using profiles as interfaces to meta-model extensions

To change the meta-model extensions used in the model afterward, we propose to use implicit meta-model extensions or profiles as interfaces to the different, implicit or explicit meta-model extensions. Later, they would play the role of implementation for the former.


Fig. 15. Using profiles as interfaces to meta-model extensions.


Figure 15 describes a situation, where we have two different meta-model extensions which we want to make changeable without affecting the model M1. In this case, both profiles P1 and P2 will contain exactly the same set of stereotypes, which contain the same tags, defined on different meta-models.

Here the dependency with the stereotype «extends» describes the relationship between the implicit meta-model extension and the meta-model.

The same technique can be used to prepare the model to be used by the future meta-model extension as shown in Fig. 16.


Fig. 16. Using profiles as interfaces to allow future use of a meta-model extension.



8. Conclusions

Meta-modeling and meta-model extensions to the existing industry standard meta-models (e.g., the UML meta-model) provide a guiding framework for analysis and design. The extended analysis meta-model that embodies domain specific knowledge, guides an analyst during the analysis process and an extended design meta-model that embodies architecture specific knowledge, guides a designer during the design process.

Due to this, a need exists to combine different meta-model extensions.

To avoid name conflicts in meta-model extensions, we proposed that the UML profile description be the name space for the stereotypes and the tags be defined in the given profile.

To allow easier combination of meta-models and meta-model extensions, a method of extending model import semantics in the UML with selective import and massive renaming is proposed. Additionally, to reduce the complexity of a resulting meta-model, an extension of the model inheritance semantics with the concepts of overriding, replacing and deferring meta-model elements is proposed.

Implementation generators can use additional information contained in the meta-model extensions to take design decisions automatically during the generation process.


Acknowledgments

Author wishes to acknowledge gratefully Progressive Financial Technologies Profit Oy (Finland) and the Estonian Science Foundation for their support.

Author wishes to thank Riina Putting, Boris Tamm and Kuldar Taveter for discussions on the subject and many useful suggestions for improving this paper.


References
    1. OMG, Unified Modeling Language Specification, Version 1.3, OMG Document 00-03-01.
    2. Eriksson, H.-E. and Penker, M. Business Modeling with UML, Business Patterns at Work, John Wiley & Sons, Inc., 2000, ISBN 0-471-29551-5.
    3. OMG, Common Warehouse Metamodel (CWM) Specification, Version 1.0, OMG Document ad/01-02-01.
    4. WfMC, The Workflow Reference Model, WfMC Document TC00-1003, 1995
      OMG, Workflow Management Facility Specification, OMG Document bom/97-11-18.
    5. Taylor, D. A. Business Engineering with Object Technology, John Wiley & Sons, Inc., 1995, ISBN 0-471-04521-7.
    6. Shaw, M. and Garlan, D. Software Architecture. Perspectives on an Emerging Discipline, Prentice-Hall, 1996, ISBN 0-13-182957-2.
    7. Bass, L., Clements, P. and Kazman, R. Software Architecture in Practice, Addison-Wesley, 1998, ISBN 0-201-19930-0.
    8. Parnas, D. On the Design and Development of Program Families, IEEE TSE, 1976, 2, 1, 1-9.
    9. Rumbaugh, J., Jacobson, I. and Booch, G. The Unified Modeling Language Reference Manual, Addison-Wesley, 1999, ISBN 0-201-30998-X.
    10. OMG, Meta Object Facility (MOF) Specification, Version 1.3, OMG Document 00-04-03.
    11. OMG, Unified Modeling Language Specification, Version 1.4, Beta R1, OMG Document ad/00-11-01.
    12. OMG, A Testing Profile for UML, OMG Document ad/00-12-05.
    13. OMG, UML Profile for Modeling Quality of Service and Fault Tolerance Characteristics and Mechanisms, RFP, OMG Document ad/00-12-07.
    14. Melnikov, I. and Raabe, A. Expert System Based Computer Aided Software Engineering (CASE) Environment, In Proc. 5. Symposium “Grundlagen und Anwendungen der Informatik” 6.-8. Februar 1990, Wissenschftliche Tagungen der Technischen Universität Karl-Marx-Stadt, 6/1990, 180-188.
    15. OMG, UML Profile for CORBA, OA&DTF RFP-7, (a.k.a. Business Object Initiative RFP-2), OMG Document ad/99-03-11.
    16. Linden, F. (Ed.), Development and Evolution of Software Architectures for Product Families, In Proc. of Second International ESPRIT ARES Workshop, February 26-27, 1998, Lecture Notes in Computer Science Vol. 1429, Springer-Verlag, 1998, ISBN 3-540-64916-6.
    17. Sun, Enterprise JavaBeans Specification, v1.1, Sun Microsystems Inc. 1999.
    18. OMG, UML Profile for Enterprise Distributed Object Computing (EDOC), OA&DTF RFP-6, (a.k.a. Business Object Initiative RFP-1), OMG Document ad/99-03-10.
    19. Atkinson, C., Kühne, T. and Henderson-Sellers, B. To Meta or Not to Meta – That Is the Question, JOOP, 2000, 13, 8, 32 – 35.

Copyright © 1997-20.. by Alar Raabe
Copyright © by A.Raabe