Metamodeling

This is the concept of metamodeling in computer science and related disciplines. For the language patterns known as the Meta-model in Neuro-linguistic programming see Meta model (NLP).

Most general, metamodeling or meta-modeling is the analysis, construction and development of the frames, rules, constraints, models and theories applicable and useful for the modeling in a predefined class of problems. This concept definition is composed with the notions of the terms meta- and modeling.

Overview

For the reason of the meta character of metamodeling, this activity and metamodels are the domain of interest of metascience, metaphilosophy, metatheories and systemics, as well as, are related to meta-consciousness.

From the computational perspective, this concept is used in mathematics, and is practically applied in computer science and computer engineering/software engineering, what mainly is illustrated in this article.

In computer science and related disciplines, metamodeling is the construction of a collection of "concepts" (things, terms, etc.) within a certain domain. A model is an abstraction of phenomena in the real world, and a metamodel is yet another abstraction, highlighting properties of the model itself. This model is said to conform to its metamodel like a program conforms to the grammar of the programming language in which it is written. Common uses for metamodels are:

• As a schema for semantic data that needs to be exchanged or stored
• As a language that supports a particular method or process
• As a language to express additional semantics of existing information

Topics in metamodeling

Definition

The following discussion can be viewed as a detailed application of metamodeling techniques, related to Model Driven Engineering. In data engineering and software engineering, the use of models is more and more recommended. This should be contrasted with the classical code-based development techniques. A model always conforms to a unique metamodel. One of the currently most active branch of Model Driven Engineering is the approach named model-driven architecture proposed by OMG[1]. This approach is based on the utilization of a language to write metamodels called the Meta Object Facility or MOF. Typical metamodels proposed by OMG are UML, SysML, SPEM or CWM. ISO has also published the standard metamodel ISO/IEC 24744. All the languages presented below could be defined as MOF metamodels.

Metadata modeling

Metadata modeling is a type of metamodeling used in software engineering and systems engineering for the analysis and construction of models applicable and useful some predefined class of problems.

Model transformations

One important move in Model Driven Engineering is the systematic use of Model Transformation Languages. The OMG has proposed a standard for this called QVT for Queries/Views/Transformations. QVT is based on the Meta-Object Facility or MOF. Among many other Model Transformation Languages (MTLs), some examples of implementations of this standard are AndroMDA, VIATRA, Tefkat or MT.

Relationship to ontologies

Meta-models are closely related to ontologies. Both are often used to describe and analyze the relations between concepts [Söderström2002].

Ontologies express something meaningful within a specified universe or domain of discourse by utilizing a grammar for using vocabulary. The grammar specifies what it means to be a well-formed statement, assertion, query, etc. (formal constraints) on how terms in the ontology’s controlled vocabulary can be used together. [Metamodel-b]

Meta-modeling can be considered as an explicit description (constructs and rules) of how a domain-specific model is built. In particular, this comprises a formalized specification of the domain-specific notations. Typically, metamodels are – and always should follow - a strict rule set. [Metamodel-a]. “A valid metamodel is an ontology, but not all ontology are modeled explicitly as metamodels” [Metamodel-b].

Types of meta-models

For software engineering, several types of models (and their corresponding modeling activities) can be distinguished:

• Metadata modeling (MetaData Model)
• Meta-Process Modeling (MetaProcess Model)
• Executable Meta-Modeling (combining both of the above and much more, as in the general purpose tool Kermeta)
• Model Transformation Language (see below)

Zoos of metamodels

A library of similar meta-models has been called a Zoo of meta-models. There are several types of meta-model zoos. Some are expressed in ECore. Others are written in MOF 1.4 - XMI 1.2. The metamodels expressed in UML-XMI may be uploaded in UML CASE tools.

Concepts in metamodeling

Sequential activities

Sequential activities are activities that need to be carried out in a pre-defined order. The activities are connected with an arrow, implying that they have to be followed in that sequence. Both activities and sub-activities can be modeled in a sequential way. In Figure 1 an activity diagram is illustrated with one activity and two sequential sub-activities. A special kind of sequential activities are the start and stop states, which are also illustrated in Figure 1.

File:Mm21.gif

Figure 1: Sequential activities

File:Mm22.gif

Figure 2: Example sequential activities

In Figure 2 an example from practice is illustrated. The example is taken from the requirements capturing workflow in UML-based Web Engineering. The main activity, user & domain modeling, consists of three activities that need to be carried out in a predefined order.

Unordered activities

Unordered activities are used when sub-activities of an activity do not have a pre-defined sequence in which they need to be carried out. Only sub-activities can be unordered. Unordered activities are represented as sub-activities without transitions within an activity, as is represented in Figure 3.

File:Mm23.gif

Figure 3: Unordered activities

File:Mm24.gif

Figure 4: Example of unordered activities

In some specific cases an activity exists of sequential and unordered activities. The solution to this modeling issue is to divide the main activity in different parts. In Figure 4 an example is illustrated, which clarifies the necessity to be able to model unordered activities. The example is taken from the requirements analysis workflow of the Unified Process. The main activity, “describe candidate requirements”, is divided into two parts. The first part is a sequential activity. The second part consists of four activities that do not need any sequence in order to be carried out correctly.

Concurrent activities

Activities can occur concurrently. This is handled with forking and joining. By drawing the activities parallel in the diagram, connected with a synchronization bar, one can fork several activities. Later on these concurrent activities can join again by using the same synchronization bar. Both activities and sub-activities can occur concurrently. In the example of Figure 5, Activity 2 and Activity 3 are concurrent activities.

File:Mm25.gif

Figure 5: Concurrent activities

File:Mm26.gif

Figure 6: Example concurrent activities

In Figure 6, a fragment of a requirements capturing process is depicted. Two activities, defining the actors and defining the use cases, are carried out concurrently. The reason for carrying out these activities concurrently is that defining the actors and the use cases influences each other to a high extend.

Conditional activities

Conditional activities are activities that are only carried out if a pre-defined condition is met. This is graphically represented by using a branch. Branches are illustrated with a diamond and can have incoming and outgoing transitions. Every outgoing transition has a guard expression, the condition. This guard expression is actually a Boolean expression, used to make a choice which direction to go. Both activities and sub-activities can be modeled as conditional activities. In Figure 7 two conditional activities are illustrated.

File:Mm27.gif

Figure 7: Conditional activities

File:Mm28.gif

Figure 8: Example conditional activities

In Figure 8 an example from practice is illustrated. A requirements analysis starts with studying the material. Based on this study, the decision is taken whether to do an extensive requirements elicitation session or not. The condition for not carrying out this requirements session is represented at the left of the branch, namely [requirements clear]. If this condition is not met, [else], the other arrow is followed.

Process-data diagram

The integration of both types of diagrams is quite straightforward. Each action or activity results in a concept. They are connected with a dotted arrow to the produced artifacts, as is demonstrated in Figure 9. The concepts and activities are abstract in this picture.

Figure 9: Process-Data Diagram

In Table 1 a generic table is presented with the description of activities, sub-activities and their relations to the concepts. In section 5 examples are given of both process-data diagram and activity table.

Table 1: Activity table

Activity	Sub-Activity	Description
Activity 2	Sub-activity 4	Sub-activity 4 results in a STANDARD CONCEPT

Example of a process-data diagram

In Figure 10 an example of a process-data diagram is illustrated. It concerns an example from a the orientation phase of complex project in a WebEngineering method (Van de Weerd, Souer, Versendaal & Brinkkemper).

Notable is the use of open and closed concepts. Since project management is actually not within the scope of this research, the concept CONTROL MANAGEMENT has not been expanded. However, in a complex project is RISK MANAGEMENT of great importance. Therefore, the choice is made to expand the RISK MANAGEMENT concept.

File:Mm42.gif

Figure 10: Example Process-Data Diagram - Orientation phase in a complex project

In Table 2 the activities and sub-activities, and relation to the concepts are described.

Table 2: Activities and sub-activities in a complex orientation phase

Activity	Sub-Activity	Description
Describe Project		Describing the project is done in terms of participants, targets, products, scope and assumptions. This information is derived from the proposal, but with more emphasis on the project management issues. The activity end in a project DESCRIPTION.
Construct planning	Describe project phases	The PLANNING is divided into five PROJECT PHASES, which should be shortly described.
Construct planning	Describe activities	The project ACTIVITIES are described and grouped into PROJECT PHASES.
Construct planning	Describe deliverables	The DELIVERABLES that result from the project ACTIVITIES are described.
Construct planning	Set up schedule	For every DELIVERABLE a DATE is set and for each ACTIVITY a TIME SLOT is estimated.
Control project		Controlling the project results in a CONTROL MANAGEMENT artifact. This artifact is not further explained here, since it concerns regular project management issues, like communication management, progress management, change management and problem management that lie outside the scope of this research.
Control risk	Identify risks	Identifying risks can be done by using standard checklists or organizing risk workshops. The RISKS are included in the PROJECT PLAN.
Control risk	Evaluate risks	Every RISK is provided with an EVALUATION; a description and estimation about the complexity or uncertainty of a project is given.
Control risk	Analyze impact	Analyzing the impact of a risk handles about the IMPACT, a risk has on the success of a project. The evaluation and risk values are indicated by selecting a value: low, moderate or high.
Control risk	Prioritize risks	Prioritizing the risks is done by combining IMPACT and EVALUATION in a table. High priority is then given to RISKS with the highest scores.
Define actions for risk strategy		Risk strategy actions can be obtained from experience or from relevant literature. The project manager adapts the actions to the project in the ACTION LIST FOR RISK STRATEGY. RISKS with the highest priority are on top of the list and need to be handled first.

See also

• Data governance
• Model Driven Engineering (MDE)
• Model-driven architecture (MDA)
• Domain Specific Language (DSL)
• Domain-Specific Modeling (DSM)
• Generic Eclipse Modeling System (GEMS)
• Kermeta (Kernel Meta-modeling)
• VIATRA (Viatra)
• XML transformation language (XML TL)
• Requirements analysis
• MOF Queries/Views/Transformations (MOF QVT)
• Transformation language
• MODAF Meta-Model

Further reading

• Booch, G., Rumbaugh, J., Jacobson, I. (1999), The Unified Modeling Language User Guide, Redwood City, CA: Addison Wesley Longman Publishing Co., Inc.
• J. P. van Gigch, System Design Modeling and Metamodeling, Plenum Press, New York, 1991
• J. Bezivin, On the Unification Power of Models, in: Software and System Modeling (SoSym) 4(2):171--188.
• Ernst, What is meta-modeling? 11.10.2002.
• Woody Pidcock, What are the differences between a vocabulary, a taxonomy, a thesaurus, an ontology, and a meta-model?, 10.10.2002.
• E. Söderström, B. Andersson, P. Johannesson, E. Perjons, and B. Wangler. Towards a Framework for Comparing Process Modelling Languages, in: Lecture Notes In Computer Science; Vol. 2348. Proceedings of the 14th International Conference on Advanced Information Systems Engineering. Pages: 600 – 611, 2001