On levels of model transformation
Mikaël Peltier
François Ziserman
Jean Bézivin
Find

Abstract
This paper presents a vision of organizing models in two levels called the abstract space and the concrete space. At the concrete level, XML is the unique representation technology, whereas at the abstract level many different representation systems may be found, like UML or MOF. We argue that model transformation is becoming an important paradigm in many areas of information processing. As a consequence model transformation should be dealt with, both at the abstract and concrete level. Considering XSLT as the central transformation tool of the concrete space seems the obvious approach. Nevertheless other more abstract transformation languages should exist at the abstract level. As a consequence, we need to define translation schemes from these languages to XSLT, like one may translate from high-level languages to assembly languages. We show that the problem is more simplified if all the models and meta-models of the abstract space are based on the same meta-meta-model and if there is a canonical XML transformation defined in this meta-meta-model. We use the MOF and XMI standards of OMG to illustrate our approach.

Keywords

Contents
  1. Introduction
  2. Model organization
  3. Architecture of translator between abstract and concrete level
  4. Formalism
  5. Mapping between our formalism and XSLT
    1. Attributes mapping
    2. Roles mapping
  6. UML to Java as example
  7. Conclusion
  8. Acknowledgements
  9. Bibliography
Introduction
XML is becoming the "lingua franca" for data communication between applications. Another way to state this is that XML is also becoming the common and standard projection for models of any kind, at a time when model engineering is becoming to be considered as an emerging technology [XMI].
If we view an information system as populated with a high number of different models, it becomes obvious that model transformation is progressively taking its place as a central paradigm in software engineering, information system engineering and many similar areas [LR-TRBMM98].
This paper takes a practical and conceptual view of the general problem of model transformation. The practical view is routed in the observation that XSLT is at the heart of any XML transformation system. The conceptual view is based on the belief that there should be higher levels of transformation formalisms. Our work consists in finding some way to conciliate the practical and conceptual view. We offer, in this paper, a vision called the two-space framework to handle this situation. Our approach will be illustrated with several practical examples.
Previous Previous Table of Contents
Model organization
With the emergence of the MOF specification, we see the arrival of a layered architecture for model engineering [MOF]. This architecture is sometimes referred as four-levels architecture of OMG. The different layers are:
In this architecture all levels may be considered as having some kind of instance relation with their parent meta-level. The M3 level allows a MOF model to define all meta-models which can appear to M2 level. Also, we see here a new issue, which is the compatibility between meta-models. Indeed, if a MOF model can express all meta-models, then it is possible to transform a model based on a meta-model to another. This paper presents a solution to describe a set of transformations rules based on the M3 level. These transformations may also be used to realize some modifications or extensions on a meta-model and not only simply to transform a meta-model to another meta-model. They may be used to automatically generate rules to transform one model to another model which is compliant with the new meta-model. Our two-space framework is depicted by the Figure 1.
Figure 1 . A two-space framework for models transformation
MOF specification brought compatibility between models and XML brought a good improvement in data interchange. XMI is the outcome of these two standards (XMI=MOF+XML). Indeed, with the XMI specification we have a standard to exchange any models, not only models compliant with a specific meta-model. This is possible because a DTD XMI represents a meta-model and a model of this meta-model is represented by a XMI document that is compliant to this DTD. To allow model transformation, we define a first-space in our framework, which is called abstract level. Within this level is defined a formalism to express transformation rules, which will convert for example meta-model M1 to meta-model M2. Those transformations works on a meta-model definition, which is an instance of MOF meta-model. The second space in our framework is called the concrete level. Transformations which run at this level can be automatically generated. Those transformations can be expressed by XSLT. An XSLT program takes a XML document as entry and generates another XML document as output. XSLT is suitable since models can be represented in XML. Our work consists of two steps: first we define an abstract formalism to express transformation rules, and then we define a mapping between this formalism and an XSLT equivalent program.
Previous Previous Table of Contents
Architecture of translator between abstract and concrete level
The MOF translator uses several existing technologies such as XSLT, DOM and automatic compiler generation [XSLT] [DOM] [SABLECC]. More precisely the SableCC generator of compilers, is used to parse and analyze the formalism used to express transformation rules. The MOF translator takes three inputs, which are the source meta-model, the destination meta-model and the transformation rules to transform the first meta-model towards the second. Our translator checks some properties on transformation rules such as if attributes are really attributes in source meta-model or destination meta-model. To do this verification, we first collect some information on the meta-model, for example the attributes list of a specific entity. Initially, we intended to collect this information by using XSLT specification, but this approach is difficult on practical grounds. XSLT programs are used to transform an XML document to another one, but this collection of information goes further that a simple transformation. Meta-models are described by using the MOF specification under a XMI representation, and thus we can use a DOM parser to collect information on this meta-model. DOM specification is used to represent a Document. XSLT was not the best solution for collecting information on meta-model but is good for outputting format of the MOF translator. The MOF translator must map transformations rules to an XSLT program able to convert a model that is compliant with the source meta-model into a model, which is compliant with the destination model. The Figure 2 represents this architecture:
Figure 2 . Architecture of translator between abstract end concrete level
Previous Previous Table of Contents
Formalism
Transformation rules essentially express how to transform entities of a specific meta-model into entities of another meta-model. In model transformation we must transform only useful things, i.e. only entities that can appear in a flat meta-model. What is a flat meta-model? It is a meta-model that contains only concepts, which can appear in a model that is compliant with this meta-model, or in other words that defines the set of "terminal instances" sometimes called "surface semantics". Indeed, if in a source meta-model you have a inheritance tree, then only leafs are interesting for transformations.For example, in the UML meta-model an entity "Class" inherits from an entity "Classifier" but in a model we do not see the entity "Classifier" [UML]. Entity transformation is divided into two parts: the first part is used to specify source entity and destination entity. This first part is represented by the following syntax:
Entity [Restriction]? to Entity
In the code above, the first item represents an entity that may be found in the source meta-model and the second item corresponds to the resulting entity of the transformation belonging of course to the destination meta-model. For example, the code below transforms an entity "Attribute" toward an entity "Field".
Attribute to Field
We can also apply some restrictions on the entity transformation. Indeed, we may transform only entities that satisfy a condition. The restrictions are based either on attributes or on roles. When a restriction is based on an attribute, we specify what value it must have to be transformed. When it is based on a role, we specify what type of entity it must have to be transformed. A restriction is represented by an assignment where the right part corresponds to an attribute or a role and the left part corresponds to the acceptable value. Since all meta-models are described by using MOF and are saved in XMI, therefore all concepts or entities are represented by the class concept of MOF. As a result, there is no problem in finding a specific entity in a meta-model.
The second part represents transformations, which are applied on attributes and roles of the source entity. The pattern for those transformations is the following:
attributes :
attributes transformation
roles :
roles transformation
In this pattern you can initialize some attributes and define some roles, possibly none attribute or none role. Attribute initialization is realized by a standard assignment. The syntax is the following one:
nameOfAttribut = value
The value of an attribute can be of different types:
In addition to the attribute transformation, we also allow role transformation. As attribute transformation, role transformation is realized by a standard assignment, with the following syntax:
nameOfRole = value
The value of a role can be of different types:
fields = feature [ Attribute ]
method = feature [ Operation ]
Now, that we presented our formalism, we are going to define a mapping between abstract and concrete level.
Previous Previous Table of Contents
Mapping between our formalism and XSLT
The XSLT language is ideal to apply at concrete level, especially since XMI became a standard for exchanging models between tools. Indeed, XSLT allows us to transform a XML document towards another document, which can be a XML document but not necessary. As shown below, entities transformation is done by:
Entity1 [ attOrRole operator value]? to Entity2
The XSLT fragment that corresponds to the mapping of entities transformation is the following one:
<xsl:template match="Entity1" >
<xsl:if test="attOrRole operator value">
<xsl:element name="Entity2">
<!--attributes mapping -->
<!--roles mapping -->
<xsl:apply-templates select="./child::node()" mode="Entity1"/>
</xsl:element>
</xsl:if>
</xsl:template>
We see that all source entities are mapped into templates, which add an element in the XML destination tree when the restriction is correct. This element represents the destination entity that appears in the model resulting from the transformation. In those templates we add the code corresponding to attributes mapping and roles mapping. At the end of those templates, we apply transformation rules on children, which belong to source entities. We use mode attribute of xsl:apply-templates to select only templates, which transform the children of the current template. All entities must have a specific template for their children because, for example, an attribute that is contained into an entity does not map into the same thing for another entity. The restriction mapping is not directly as we see on the XSLT fragment above. Indeed, we must take into account the XMI specificity presented below. Therefore, the exact mapping is similar to the attribute conditional mapping or the role conditional mapping depending on the restriction type.
Attributes mapping
Now that we have seen entity mapping, we are going to see attribute mapping. We must know that XMI 1.1 can use two ways to represent an attribute in a XMI document. Indeed, it can be an XML attribute of the owner entity, or a child of the owner entity. Therefore, if "y" is an attribute of the "x" entity then the two ways to represent this attribute are the following one:
<x y="..."/>
or
<x>
<y>...</y>
</x>
Consequently, we must take into account those two cases, i.e. we must generate the mapping for all possibilities because the translator does not know how attributes are represented. Mapping of attribute transformation depends on the kind of transformation. Below, we present the three cases:
<xsl:attribute name="a">
<xsl:value-of select="'value'"/>
</xsl:attribute>
<!--First part -->
<xsl:variable name="cond">
<xsl:value-of select="@b"/>
</xsl:variable>
<xsl:if test="$cond!=''>
<xsl:attribute name="a">
<xsl:value-of select="$cond"/>
</xsl:attribute>
</xsl:if>
<!--Second part-->
<xsl:if test="$cond=''>
<xsl:element name="a">
<xsl:value-of select="./owner.b"/>
</xsl:element>
</xsl:if>
In this case we must take into account the specificity of XMI. This is why we put the value of the "b" attribute in a variable to test if it is an attribute or an element in the model. We must also take into account the specificity of XSLT, which enforces us to add all attributes in the XML result tree, before adding elements, which will be children. Consequently, the first part is put into the attribute mapping part that belongs to the owner of the attribute transformation rule. But the second part is put at the end of entity mapping just before the xsl:apply-templates instruction. Therefore, if we have "a=b, c=d", then this code is mapped into:
First part of attribute mapping (a)
First part of attribute mapping (c)
Second part of attribute mapping (a)
Second part of attribute mapping (c)
<xsl:attribute name="a">
<xsl:variable name="cond">
<xsl:value-of select="@b"/>
</xsl:variable>
<xsl:if test="$cond=''">
<xsl:variable name="cond">
<xsl:value-of select="./owner.b"/>
</xsl:variable>
</xsl:if>
<xsl:if test="$cond='value'">
<!--mapping based on kind of c -->
</xsl:if>
<xsl:if test="$cond!='value'">
<!--mapping based on kind of d -->
</xsl:if>
</xsl:attribute>
A conditional is mapped by using xsl:if instruction. The mapping for "c" and "d" depend on his kind. Therefore, the mapping refers to one of three mapping for attributes that we presented above.
Roles mapping
Now that we described the mapping for entities and attributes, we still have to explain the mapping of roles. The two cases for roles transformations are presented below.
<xsl:variable name="cond">
<xsl:value-of select="@b"/>
</xsl:variable>
<xsl:if test="$cond!=''">
<xsl:attribute name="a">
<xsl:value-of select="$cond"/>
</xsl:attribute>
</xsl:if>
<xsl:if test="$cond=''">
<xsl:apply-templates select="./owner.b"/ mode="single>
</xsl:if>
<xsl:template match="owner.b" mode="single">
<xsl:element name="a">
<xsl:apply-templates select="./child::node()"/> (1)
</xsl:element>
</xsl:templates>
If the role "b" is an attribute then we report the value of this attribute into the role "a". But if it is an element then we create a template that we select by the "xsl-apply-templates" instruction. The pattern of selection is "owner.b", because XMI use this form when an role is represented by an element. The owner of a role does not appear in transformation rules but this information is automatically collected at the analysis stage of MOF translation on the meta-model definition. This stage is not detailed in this paper but it collects some information and verifies some properties on rules.
<xsl:variable name="cond"> (2)
<xsl:value-of select="@b"/>
</xsl:variable>
<xsl:if test="$cond!=''">
<!-- generate a template which is called strip-value -->
</xsl:if>
<xsl:template match="b.dest">
<!-- the code generated here depend if c is the last role -->
</xsl:template>
In this case, we must cross all paths that can reach "c" and to collect all information. The template "strip-value" allows us to catch all references which are contained by an XML attribute which represents the role "b". For each contained reference, we call the template corresponding to the destination entity of this role. At the time of this call, we precise if we are on the last contained reference by this role. Indeed, if we are not on the last reference then we will have to turn over to the "strip-value" that called this template. If the next role in the list is not the last then we apply the same process. Otherwise, we return the value of this role by a XSLT fragment that is similar to the first case. And so on. When we recall the "strip-value", we also pass the value of last role; indeed the result will be the concatenation of all values which corresponding to "c". The Figure 3 below explains this mechanism by showing the path taken by the data. For this example "c" is an element and "b" is an attribute that contains "d" and "e".
Figure 3 . Mechanism to catch role value
The template "strip-value" which is generated for the first role is not exactly the same as the template "strip-value" which is generated for the intermediary role. Indeed, the first does not recall entity, which you called. On the other hand, intermediary templates have more arguments and return a value to entity, which you called.
<xsl:template match="owner.b" mode="ownerEntity">
<xsl:element name="a">
<xsl:apply-templates select="./child::node()"/>
</xsl:element>
</xsl:templates>
<xsl:attribute name="a">
<!-- variable value is assigned to value of b -->
<xsl:if test="contains($value,'value')">
<!--mapping based on kind of c -->
</xsl:if>
<xsl:if test="not(contains($value,'value'))">
<!--mapping based on kind of d -->
</xsl:if>
</xsl:attribute>
"b" can be a direct role or a composed role. To recover the value of "b", we use a XSLT fragment that is similar to the fragment for the assignment of a role. But instead of creating an attribute with the value of the role, we create a variable, which is called value. Thereafter, we can verify that the value "value" belong or not to the possibilities. Mapping for "c" and "d" is based on their type, if this is a conditional, we apply the same process, and so on. Otherwise, we assign "a" to "c" or "d".
Previous Previous Table of Contents
UML to Java as example
We transform a uml model to a java model, as an example of a toy illustrative transformation system. as transformation rules are expressed on meta-models, we depicted them below:
Figure 4 . UML meta-model
Figure 5 . JAVA meta-model
When we have the meta-models, the first question is "What do I want to transform ?". The general purpose is to convey the concepts from the source meta-model to the destination meta-model. For example, we transform the attribute concept into the field concept by the following transformation rule:
Attribute to Field {
attributes :
name=name,
visibility=visibility,
share = (ownerScope=="classifier" ? "static" : "none"),
state= (changeability=="frozen" ? "final" : "none")
roles:
resultType = (type==Integer ? Int :
(type==String ? String :
(type==Class ? type)))
}
In this example, we see that the first two attributes are automatically initialized with the content of attributes belonging to the source meta-model. On the other hand, we also see that the share attribute and the state attribute are not initialized by another content but are directly assigned to a value belonging to the destination meta-model. This assignment is based on a conditional depending to the value of an attribute that appears in the source meta-model. All transformation rules for transforming UML model to JAVA model are similar to the previous example. There is only two exceptions presented below:
ResultType = (parameter.kind == "out" ?
( parameter.type == Integer ? Int :
( parameter.type == String ? String :
( parameter.type == Class ? parameter.type ))))
Fields = feature [ Attribute ],
Methods = feature [ Operation ]
We do not present all transformation rules, but with the meta-models depicted by the UML diagram class and the examples above, we can easily imagine the remaining rules. We present below a UML model under a XMI representation and the JAVA model corresponding to the result of transformation. For the reasons of size, we only include a significant part of the XML document.
<UML:Class xmi.id="Shape" isAbstract="true" visibility="public"
isRoot="true" isActive="false" name="Shape" isLeaf="false">
<UML:Classifier.feature>
<UML:Attribute xmi.id="name" visibility="public" changeability="
changeable" ownerScope="instance" type="String" name="name"
targetScope="instance"
multiplicity="1,1"/>
</UML:Classifier.feature>
<UML:GeneralizableElement.specialization>
<UML:Generalization child="Circle " xmi.id="GCircleShape"
visibility="public" parent="Shape " name="GCircleShape"/>
</UML:GeneralizableElement.specialization>
</UML:Class>
<UML:Class generalization="GCircleShape " xmi.id="Circle" isAbstract="false"
visibility="public" isRoot="false" isActive="false" name="Circle"
isLeaf="true">
<UML:Classifier.feature>
<UML:Attribute xmi.id="CR" visibility="public"
changeability="changeable" ownerScope="instance" type="Integer"
name="R" targetScope="instance" multiplicity="1,1" owner="Circle"/>
<UML:Attribute xmi.id="CX" visibility="public"
changeability="changeable" ownerScope="instance" type="Integer"
name="X" targetScope="instance" multiplicity="1,1" owner="Circle"/>
<UML:Attribute xmi.id="CY" visibility="public"
changeability="changeable" ownerScope="instance" type="Integer"
name="Y" targetScope="instance" multiplicity="1,1" owner="Circle"/>
<UML:Operation isPolymorphic="true" visibility="public"
ownerScope="instance" isQuery="false" name="pos"
concurrency="guarded"owner="Circle ">
<UML:BehavioralFeature.parameter>
<UML:Parameter xmi.id="px" visibility="public" type="Integer "
name="px" behavioralFeature="pos">
<UML:Parameter.kind xmi.value="in"/>
</UML:Parameter>
<UML:Parameter kind="in" xmi.id="py" visibility="public"
type="Integer " name="py" behavioralFeature="pos"/>
<UML:Parameter kind="out" xmi.id="result" visibility="public"
type="Integer " name="result" behavioralFeature="pos"/>
</UML:BehavioralFeature.parameter>
</UML:Operation>
</UML:Classifier.feature>
</UML:Class>
<UML:DataType xmi.id="String" isAbstract="false" visibility="public"
isRoot="false" name="String" isLeaf="false"/>
<UML:DataType xmi.id="Integer" isAbstract="false" visibility="public"
isRoot="false" name="Integer" isLeaf="false"/>
<UML:Generalization child="Polygon " parent="shape " xmi.id="GPolygonShape"
visibility="public" name="GPolygonShape"/>
The XML fragment below corresponds to the transformation result of the UML model above.
<JAVA:Class name="Shape" visibility="public" state="abstract"
subclass="Circle ">
<JAVA:fields>
<JAVA:Field share="none" name="name" visibility="public" state="none"
typeOf="String"/>
</JAVA:fields>
<JAVA:methods/>
</JAVA:Class>
<JAVA:Class name="Circle" visibility="public" state="none"
superclass="Shape ">
<JAVA:fields>
<JAVA:Field share="none" name="R" visibility="public" state="none"
typeOf="Int"/>
<JAVA:Field share="none" name="X" visibility="public" state="none"
typeOf="Int"/>
<JAVA:Field share="none" name="Y" visibility="public" state="none"
typeOf="Int"/>
</JAVA:fields>
<JAVA:methods>
<JAVA:Method name="pos" visibility="public" state="final synchronized"
share="none" ownerClass="Circle " resultType="Int">
<JAVA:parameters>
<JAVA:Parameter name="px" owner="pos" typeOf="Int"/>
<JAVA:Parameter name="py" owner="pos" typeOf="Int"/>
</JAVA:parameters>
</JAVA:Method>
</JAVA:methods>
</JAVA:Class>
Previous Previous Table of Contents
Conclusion
With our two-space framework, we can easily transform a model to another one with abstract transformation rules, which are expressed on a meta-model. Indeed, since a meta-model contains concepts for models then rules are easy to write and we minimize the rules complexity. From these transformation rules, we can automatically generate a program that applies these rules to models.
This solution can be used to transform a UML model to a JAVA model as shown in this paper, as an example of a toy illustrative transformation system. The two-space framework presented in this paper can also be used in software engineering to realize some modifications on a source meta-model. Consequently, the source models are transformed into target models which are compliant with the destination meta-model. This avoids a model becoming not compliant after some extensions on a meta-model. Our framework allows models to stay compliant with meta-model.
The XSLT language is suitable to transform an XML document into another one. But it is hard and error prone to manually write XSLT programs. Our formalism allows expressing transformation rules in a more compact and readable way. For example, transformation rules to transform UML model to JAVA model takes about 50 lines and the generated XSLT program takes about 1200 lines. This factor should be approximately the same for similar programs. Furthermore, the translator checks some properties on transformations to avoid errors.
Previous Previous Table of Contents
Acknowledgements
We want to thank Mariano Belaunde for many inspiring remarks on this work and for the time that he spent to apply our meta-models in the Universalis Environment.
Previous Previous Table of Contents
Bibliography
[BJ-MMT99] Bézivin J., Meta-model technology: concepts and applications, XML'99, Philadelphia, December 1999
[DOM]DOM, World Wide Web Consortium. Document Object Model Level 1 specification 1.0. W3C Recommendation. See http://www.w3.org/TR/REC-DOM-Level-1/
[HG-IXSLT99]Holman G. Ken, Crane Softwrights Ltd. Introduction to XSLT and Xpath, Graphic Communications Association, MetaStructures'99 Montreal. See http://www.gca.org
[LR-TRBMM98]Lemesle R., Transformation rules bases on meta-modeling EDOC'98, San Diego, 1998
[MA-XMLLA99]Michard A., XML Language et applications, Eyrolles 1999.
[MBWP-COMT96]Blaha Michael and Premerlan William i. A Catalog of Object Model Transformations. 3rd Working Conference on reverse Engineering. Monterey, California, November 1996.
[MOF]OMG/MOF Meta Object Facility (MOF) Specification. AD/97-08-14, Object Management Group, Framingham, Mass., September 1997.
[RH-FLSCT]Reinhold Heckmann, A Functional Language for the Specification of Complex Tree Transformation. 2nd European Symposium on Programming, Nancy, pp. 175-190, Springer-Verlag, 1988
[SABLECC]Gagnon E. SableCC, an object-oriented compiler framework. Thesis submitted to the McGill university, Montreal.
[UML]OMG/UML, Unified Modeling Language UML semantics.AD/97-08-04
[UMLAUT]Wai Ming Ho, Jézéquel Jean-Marc, Le Guennec Alain, Pennaneac'h François. UMLAUT : an extensible UML transformation FrameWork. 14th IEEE International Conference On Automated Software Engineering.1999.
[XMI]OMG/XMI XML MetaData Interchange (XMI) Proposal to the OMG OA&DTF; RFP3 : Stream Based Model Interchange Format (SMIF) Document ad/98-10-05, (October 20, 1998), Adopted at the Washington Meeting, (January 1999).
[XML] XML, World Wide Web Consortium. Extensible Markup Language (XML) 1.0. W3C Recommendation. See http://www.w3.org/TR/1998/REC-xml-19980210
[XSLT]XSLT, World Wide Web Consortium. Extensible Stylesheet Language Tranformations (XSLT) 1.0. W3C Recommendation. See http://www.w3.org/TR/1999/REC-xslt-19991116
Previous Previous Table of Contents