Frequently, the set of modeling concepts for a given domain experiments certain kind of evolution: new elements are added,
previous elements are ruled out while others just remain but suffering from some modifications. This way, the models conforming
to the previous version of the metamodel become obsolete, so they have to be updated in order to conform to the new metamodel
specification. This task can be very tedious and even more in situations like the one tackled in this use case, where the size
of the metamodels considered makes almost impossible to perform this task by hand.
In this Use Case we show how model weaving can be used in order to generate model transformations that support the migration of
models conforming to different version of a same metamodel. This use case applies similar techniques of the
use case, but modified to work with very large metamodels (each one comprises around 25.000 elements).
With such a size, the definition of a model transformation between those metamodels from scratch would be completely
The metamodels considered in this use case are two different versions of a metamodel used to describe the System, Software
and Hardware of an automobile defined by AUTOSAR (AUTomotive Open System ARchitecture), a partnership of automotive manufacturers
and suppliers working together to develop and establish a de-facto industry standard for automotive electrical/electronic (E/E) architectures.
The approach followed in this Use Case is basically the same followed in a previous one:
two different versions of the same metamodel, AUTOSAR2.0 and AUTOSAR2.1, used to define the set of modeling concepts considered in
the automotive domain,
are compared with the aim of defining a model transformation that allows migrating from models conforming to the former version
of the metamodel to the later one.
This model comparison is based on the execution of refined versions of the matching
transformations already used in the mentioned
Metamodel Comparison Use Case that generates as output different versions of the weaving model
between the two versions of the metamodel considered.
The transformations were modified to support matching of large metamodels.
The process is summarized in the figure below.
A preliminary weaving model (Autosar.amw) containing just one root element referencing the woven models
(AUTOSAR2.0 and AUTOSAR2.1) is created by hand using the AMW wizard.
This basic weaving model is refined in a continuous process that consist basically in executing different matching transformations that
take as input the two considered metamodels and the last weaving model generated.
"Metamodel comparison" Use Case's Overview
This way, with each new transformation executed we obtained
a more valuable weaving model, since the different links defined between both metamodel elements are more likely to be real equivalences
between the input metamodels. These equivalences will be translated to be supported by a model transformation.
So, the weaving models generated are:
Finally, the obtained weaving model is used to automatically generate a model transformation that supports
the migration of models conforming to AUTOSAR2.0 metamodel to models conforming to AUTOSAR2.1 metamodel.
This transformation is obtained by executing a higher-order transformation (HOT) included in the AMW plug-in. This transformation
takes as inputs two different metamodels and a weaving model between these metamodels and generates as output an .ecore model conforming
to the ATL metamodel, that is, an ATL model (Autosar_cp_th_equal_lr_noneq_hot.ecore).
- Restricted Cartesian Product (Autosar_cp.amw): this weaving model is merely a Cartesian product of the elements having the same type
found in both metamodels
- Threshold (Autosar_cp_th.amw): the elements from the previous weaving model with the lower similarity values
are rolled out of the resulting weaving model
- Name equality (Autosar_cp_th_equal.amw): a similarity value is assigned to each one of the matched elements obtained in the previous model
(Autosar_cp.amw); the elements with the same name receive a higher value.
- Link rewriting (Autosar_cp_th_equal_lr.amw): the elements from the previous weaving model are reorganized according to their nature, that is,
taking into account if they are Classes or Attributes/References contained in those Classes
- Enum Datatypes processing (Autosar_cp_th_equal_lr_enum.amw):
due to the special characteristics of the metamodels considered, a
new transformation dedicated to map the enum datatypes has been developed and applied in this use case
- Link rewriting - non equivalence (
Autosar_cp__th_equal_lr_enum_noneq.amw): a new set of links is added in the previous model, identifying
the elements from the input metamodels (AUTOSAR2.0 and AUTOSAR2.1) for what no equivalence has been found
This model is directly extracted to an ATL file by using again one of the functionalities provided by the AMW/AM3 plug-ins.
As mentioned before, this use case is similar to the
Metamodel comparison and model migration use case.
The major difference is that the metamodels and models
are much bigger, so new and refined
transformations has been developed to generate the different weaving models.
Another significance difference is the way of defining the metamodels
implied in the model migration process, as well as the models used to
verify the ATL transformation generated as result of the process.
The idea of this process is depicted in the figure below:
In this case, developing the metamodels from scratch would had been a very
tedious task and prone to errors. Nevertheless, we take advantage
of the functionalities provided by EMF to automatically generate the
AUTOSAR 2.0 and AUTOSAR 2.1 ecore metamodels from the original XML Schema where
those metamodels were defined.
Moreover, once these .ecore metamodels are defined, we use EMF to generate the code
capable of reading models
models conforming to those metamodels, as well as a visual editor for those
Metamodels and Models extraction
Finally, by using the plug-ins automatically generated by EMF, any XML
document conforming to the original XML Schema defining
the AUTOSAR 2.0 metamodel (or AUTOSAR 2.1 metamodel) is automatically
recognized as a model conforming to the AUTOSAR 2.0.ecore metamodel (respectively, AUTOSAR 2.1.ecore).
Thus, this model is edited using the generated editor, and can be used as input to test the ATL transformation obtained
directly. This process is an ad-hoc XML injection.
This example contains the transformation that was generated.
Metamodel Comparison and Model Migration
The Use Case in which the one presented here is based.
HowTo that explains how to execute the examples is
recommended here in order to execute this Use Case.
Matching is the generic process that creates weaving models.
This use case gives a general overview of the matching process, and how it is handled by AMW and ATL.
The present work is been supported by the GOLD project financed by the Spanish Ministry of Education and Science (TIN2005-00010)
and the FoMDAs project (URJC-CM-2006-CET-0387)
co-financed by the Rey Juan Carlos university
and the Regional Government of Madrid.