Skip to main content

Notice: this Wiki will be going read only early in 2024 and edits will no longer be possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.

Jump to: navigation, search

Difference between revisions of "ATL/Concepts"

< ATL
 
(9 intermediate revisions by 3 users not shown)
Line 5: Line 5:
 
As opposed to this passive approach, the field of Model-Driven Engineering (MDE) aims to consider models as first class entities. It also considers that the different kinds of handled items (such as the tools, the repositories, etc.) can be viewed and represented as models. The model-driven approach supposes to provide model designers and developers with a set of operations dedicated to the manipulation of models.  
 
As opposed to this passive approach, the field of Model-Driven Engineering (MDE) aims to consider models as first class entities. It also considers that the different kinds of handled items (such as the tools, the repositories, etc.) can be viewed and represented as models. The model-driven approach supposes to provide model designers and developers with a set of operations dedicated to the manipulation of models.  
  
In this context, [[#Model Transformation|model transformation]] appears to be a central operation for model handling: it aims to make it possible to specify the way to produce a number of target models based on a set of source models. In the scope of the model-driven engineering, it is assumed that model transformations, as any other model-based tool, can be modelled, which means that they have to be considered themselves as models.
+
In this context, [[#Model Transformation|model transformation]] appears to be a central operation for model handling: it aims to make it possible to specify the way to produce a number of target models based on a set of source models. In the scope of the model-driven engineering, it is assumed that model transformations, as any other model-based tool, can be modeled, which means that they have to be considered themselves as models.
  
This section aims to provide an overview of the main MDE concepts, with a particular focus on model transformation. To this end, it first presents [[#The Model-Driven Architecture|the organisation]] of the model-driven architecture. This first section addresses the model definition mechanisms that constitute the core of the MDE area: it introduces the notions of '''models''', '''metamodels''' and '''metametamodels''', as well as the conformance relation that relates these different artefacts. The second part of the section more particularly deals with model transformation. It provides an overview of the conceptual model transformation architecture and detailed the way this conceptual architecture is matched to the ATL language.
+
This section aims to provide an overview of the main MDE concepts, with a particular focus on model transformation. To this end, it first presents [[#The Model-Driven Architecture|the organization]] of the model-driven architecture. This first section addresses the model definition mechanisms that constitute the core of the MDE area: it introduces the notions of '''models''', '''metamodels''' and '''metametamodels''', as well as the conformance relation that relates these different artifacts. The second part of the section more particularly deals with model transformation. It provides an overview of the conceptual model transformation architecture and details the way this conceptual architecture is matched to the ATL language.
  
= The Model-Driven Architecture =
+
= Model Driven Engineering =
Models constitute the basic pieces of the model-driven architecture. Indeed, in the field of model-driven engineering, a model is defined according to the semantics of a model of models, also called a ''metamodel''. A model that respects the semantics defined by a metamodel is said to ''conform'' to this metamodel. As an example, [[#Figure 1|Figure 1]] illustrates the conformance relation between a Petri net model and the Petri Nets metamodel.
+
Models constitute the basic pieces of the Model Driven Engineering (MDE). Indeed, in this field, a model is defined according to the semantics of a model of models, also called a ''metamodel''. A model that respects the semantics defined by a metamodel is said to ''conform'' to this metamodel. As an example, [[#Figure 1. Conformance relation|Figure 1]] illustrates the conformance relation between a Petri net model and the Petri Nets metamodel.
  
<span id="Figure 1"></span>
+
==== Figure 1. Conformance relation ====
 
[[Image:Petri_Net_Conformance.png]]
 
[[Image:Petri_Net_Conformance.png]]
  
'''Figure 1. Conformance relation'''
+
==== Figure 2. Meta relations ====
 
+
 
+
 
[[Image:Petri_Net_Meta.png]]
 
[[Image:Petri_Net_Meta.png]]
  
'''Figure 2. Meta relations'''
+
==== Figure 3. Model Driven Engineering ====
 
+
 
+
 
[[Image:MD_Architecture.png]]
 
[[Image:MD_Architecture.png]]
  
'''Figure 3. The model-driven architecture'''
 
  
 +
As every model, the described Petri net model is composed of a number of distinct model elements. In the context of a Petri net, these model elements correspond to the places, the transitions and the arcs that compose the model. These different elements, as well as the way they are related, are defined in the scope of the Petri net metamodel. In the same way a model conforms to its metamodel, there exists a relation between the elements of a model and those of its metamodel. This relation, called ''meta'', associates each element of a model with the metamodel element it instantiates. [[#Figure 2. Meta relations|Figure 2]] illustrates some of the existing meta relations between elements of the Petri net model and those of the Petri net metamodel.
 +
 +
At this stage, it must be recalled that, before being a metamodel, a metamodel is a model. This implies for it to conform to its own metamodel. To this end, the model-driven architecture defines a third modelling level which corresponds to the ''metametamodel'', as illustrated in [[#Figure 3. Model Driven Engineering|Figure 3]].
  
As every model, the described Petri net model is composed of a number of distinct model elements. In the context of a Petri net, these model elements correspond to the places, the transitions and the arcs that compose the model. These different elements, as well as the way they are related, are defined in the scope of the Petri net metamodel. In the same way a model conforms to its metamodel, there exists a relation between the elements of a model and those of its metamodel. This relation, called ''meta'', associates each element of a model with the metamodel element it instantiates. [[Media:Petri_Net_Meta.png|Figure 2]] illustrates some of the existing meta relations between elements of the Petri net model and those of the Petri net metamodel.
 
At this stage, it must be recalled that, before being a metamodel, a metamodel is a model. This implies for it to conform to its own metamodel. To this end, the model-driven architecture defines a third modelling level which corresponds to the ''metametamodel'', as illustrated in [[Media:MD_Architecture.png|Figure 3]].
 
 
A metametamodel aims to introduce the semantics that are required to specify metamodels. As a model with its metamodel, a metamodel conforms to the metametamodel. Note that a metametamodel is usually self-defined, which means that it can be specified by means of its own semantics. In such a case, a metametamodel conforms to itself.
 
A metametamodel aims to introduce the semantics that are required to specify metamodels. As a model with its metamodel, a metamodel conforms to the metametamodel. Note that a metametamodel is usually self-defined, which means that it can be specified by means of its own semantics. In such a case, a metametamodel conforms to itself.
Several metametamodel technologies are available. The ATL transformation engine currently provides support for two of these existing technologies: the Meta Object Facilities ([http://www.omg.org/docs/formal/02-04-03.pdf MOF 1.4]) defined by the OMG and the Ecore metametamodel (Budinsky, F., Steinberg, D., Ellersick, R., Grose, T. Eclipse Modeling Framework, Chapter 5 ”Ecore Modeling Concepts”. Addison Wesley Professional. ISBN: 0131425420, 2004) defined by the [[EMF|Eclipse Modeling Framework (EMF)]]. This means that ATL is able to handle metamodels that have been specified according to either the MOF or the Ecore semantics.
+
 
 +
Several metametamodel technologies are available. The ATL transformation engine currently provides support for two of these existing technologies: the Meta Object Facilities ([http://www.omg.org/docs/formal/02-04-03.pdf MOF 1.4]) defined by the OMG and the Ecore metametamodel (Budinsky, F., Steinberg, D., Ellersick, R., Grose, T. Eclipse Modeling Framework, Chapter 5 "Ecore Modeling Concepts". Addison Wesley Professional. ISBN: 0131425420, 2004) defined by the [http://wiki.eclipse.org/EMF Eclipse Modeling Framework (EMF)]. This means that ATL is able to handle metamodels that have been specified according to either the MOF or the Ecore semantics.
  
 
= Model Transformation =
 
= Model Transformation =
Line 37: Line 34:
 
Formally, a simple model transformation has to define the way for generating a model Mb, conforming to a metamodel MMb, from a model Ma conforming to a metamodel MMa. As previously highlighted, a major feature in model engineering is to consider, as far as possible, all handled items as models. The model transformation itself therefore has to be defined as a model. This transformation model has to conform to a transformation metamodel that defines the model transformation semantics. As other metamodels, the transformation metamodel has, in turn, to conform to the considered metametamodel.
 
Formally, a simple model transformation has to define the way for generating a model Mb, conforming to a metamodel MMb, from a model Ma conforming to a metamodel MMa. As previously highlighted, a major feature in model engineering is to consider, as far as possible, all handled items as models. The model transformation itself therefore has to be defined as a model. This transformation model has to conform to a transformation metamodel that defines the model transformation semantics. As other metamodels, the transformation metamodel has, in turn, to conform to the considered metametamodel.
  
[[Image:Model_Transformation.png|An overview of model transformation]]
+
[[Image:Model_Transformation.png]]
  
 
This schema summarizes the full model transformation process. A model Ma, conforming to a metamodel MMa, is here transformed into a model Mb that conforms to a metamodel MMb. The transformation is defined by the model transformation model Mt which itself conforms to a model transformation metamodel MMt. This last metamodel, along with the MMa and MMb metamodels, has to conform to a metametamodel MMM (such as MOF or Ecore).
 
This schema summarizes the full model transformation process. A model Ma, conforming to a metamodel MMa, is here transformed into a model Mb that conforms to a metamodel MMb. The transformation is defined by the model transformation model Mt which itself conforms to a model transformation metamodel MMt. This last metamodel, along with the MMa and MMb metamodels, has to conform to a metametamodel MMM (such as MOF or Ecore).
 
ATL is a model transformation language that enables to specify how one (or more) target model can be produced from a set of source models. In other word, ATL introduces a set of concepts that make it possible to describe model transformations.
 
ATL is a model transformation language that enables to specify how one (or more) target model can be produced from a set of source models. In other word, ATL introduces a set of concepts that make it possible to describe model transformations.
  
[[Image:ATL_Transformation_sample.png|Overview of the Author to Person ATL transformation]]
+
[[Image:ATL_Transformation_sample.png]]
  
 
This schema provides an overview of the ATL transformation (Author2Person) that enables to generate a Person model, conforming to the metamodel MMPerson, from an Author model that conforms to the metamodel MMAuthor. The designed transformation, which is expressed by means of the ATL language, conforms to the ATL metamodel. In this example, the three metamodels (MMAuthor, MMPerson and ATL) are expressed using the semantics of the Ecore metametamodel.
 
This schema provides an overview of the ATL transformation (Author2Person) that enables to generate a Person model, conforming to the metamodel MMPerson, from an Author model that conforms to the metamodel MMAuthor. The designed transformation, which is expressed by means of the ATL language, conforms to the ATL metamodel. In this example, the three metamodels (MMAuthor, MMPerson and ATL) are expressed using the semantics of the Ecore metametamodel.
 +
 +
= See also =
 +
 +
* [[Open_Model_CourseWare_(OMCW)/resources|Open Model CourseWare (OMCW) Available Resources: Teaching Material]]

Latest revision as of 05:03, 22 October 2018

Introduction

Models are now part of an increasing number of engineering processes (such as software engineering). However, in most cases, they are still confined to a simple documentation role instead of being actively integrated into the engineering process.

As opposed to this passive approach, the field of Model-Driven Engineering (MDE) aims to consider models as first class entities. It also considers that the different kinds of handled items (such as the tools, the repositories, etc.) can be viewed and represented as models. The model-driven approach supposes to provide model designers and developers with a set of operations dedicated to the manipulation of models.

In this context, model transformation appears to be a central operation for model handling: it aims to make it possible to specify the way to produce a number of target models based on a set of source models. In the scope of the model-driven engineering, it is assumed that model transformations, as any other model-based tool, can be modeled, which means that they have to be considered themselves as models.

This section aims to provide an overview of the main MDE concepts, with a particular focus on model transformation. To this end, it first presents the organization of the model-driven architecture. This first section addresses the model definition mechanisms that constitute the core of the MDE area: it introduces the notions of models, metamodels and metametamodels, as well as the conformance relation that relates these different artifacts. The second part of the section more particularly deals with model transformation. It provides an overview of the conceptual model transformation architecture and details the way this conceptual architecture is matched to the ATL language.

Model Driven Engineering

Models constitute the basic pieces of the Model Driven Engineering (MDE). Indeed, in this field, a model is defined according to the semantics of a model of models, also called a metamodel. A model that respects the semantics defined by a metamodel is said to conform to this metamodel. As an example, Figure 1 illustrates the conformance relation between a Petri net model and the Petri Nets metamodel.

Figure 1. Conformance relation

Petri Net Conformance.png

Figure 2. Meta relations

Petri Net Meta.png

Figure 3. Model Driven Engineering

MD Architecture.png


As every model, the described Petri net model is composed of a number of distinct model elements. In the context of a Petri net, these model elements correspond to the places, the transitions and the arcs that compose the model. These different elements, as well as the way they are related, are defined in the scope of the Petri net metamodel. In the same way a model conforms to its metamodel, there exists a relation between the elements of a model and those of its metamodel. This relation, called meta, associates each element of a model with the metamodel element it instantiates. Figure 2 illustrates some of the existing meta relations between elements of the Petri net model and those of the Petri net metamodel.

At this stage, it must be recalled that, before being a metamodel, a metamodel is a model. This implies for it to conform to its own metamodel. To this end, the model-driven architecture defines a third modelling level which corresponds to the metametamodel, as illustrated in Figure 3.

A metametamodel aims to introduce the semantics that are required to specify metamodels. As a model with its metamodel, a metamodel conforms to the metametamodel. Note that a metametamodel is usually self-defined, which means that it can be specified by means of its own semantics. In such a case, a metametamodel conforms to itself.

Several metametamodel technologies are available. The ATL transformation engine currently provides support for two of these existing technologies: the Meta Object Facilities (MOF 1.4) defined by the OMG and the Ecore metametamodel (Budinsky, F., Steinberg, D., Ellersick, R., Grose, T. Eclipse Modeling Framework, Chapter 5 "Ecore Modeling Concepts". Addison Wesley Professional. ISBN: 0131425420, 2004) defined by the Eclipse Modeling Framework (EMF). This means that ATL is able to handle metamodels that have been specified according to either the MOF or the Ecore semantics.

Model Transformation

In the scope of model-driven engineering, model transformation aims to provide a mean to specify the way to produce target models from a number of source models. For this purpose, it should enable developers to define the way source model elements must be matched and navigated in order to initialize the target model elements. Formally, a simple model transformation has to define the way for generating a model Mb, conforming to a metamodel MMb, from a model Ma conforming to a metamodel MMa. As previously highlighted, a major feature in model engineering is to consider, as far as possible, all handled items as models. The model transformation itself therefore has to be defined as a model. This transformation model has to conform to a transformation metamodel that defines the model transformation semantics. As other metamodels, the transformation metamodel has, in turn, to conform to the considered metametamodel.

Model Transformation.png

This schema summarizes the full model transformation process. A model Ma, conforming to a metamodel MMa, is here transformed into a model Mb that conforms to a metamodel MMb. The transformation is defined by the model transformation model Mt which itself conforms to a model transformation metamodel MMt. This last metamodel, along with the MMa and MMb metamodels, has to conform to a metametamodel MMM (such as MOF or Ecore). ATL is a model transformation language that enables to specify how one (or more) target model can be produced from a set of source models. In other word, ATL introduces a set of concepts that make it possible to describe model transformations.

ATL Transformation sample.png

This schema provides an overview of the ATL transformation (Author2Person) that enables to generate a Person model, conforming to the metamodel MMPerson, from an Author model that conforms to the metamodel MMAuthor. The designed transformation, which is expressed by means of the ATL language, conforms to the ATL metamodel. In this example, the three metamodels (MMAuthor, MMPerson and ATL) are expressed using the semantics of the Ecore metametamodel.

See also

Back to the top