The application of XSL for XML transformations in e-business solutions   Table of contents   Indexes   Text analysis tools for XML documents using regular expressions &, XSL
XML, Model engineering, Model transformation, XSLT, XMI.
 

On levels of model transformation

Peltier, Mikaël
 
 Mikaël  Peltier
 Ph.D. Student
  Cesson-Sévigné 
 FTRD/DIH/HDM/DEI 
 France 
FTRD/DIH/HDM/DEI,  4, rue du Clos Courtel, BP 59
Cesson-Sévigné   35512 France
Phone: (03) 02 99 12 38 37 email: mikael.peltier@cnet.francetelecom.fr
 Biography
 Mikaël Peltier - Mikaël Peltier works at France Telecom R&D; Rennes, while doing a Ph.D. at the University of Nantes on the subject of XML-based transformation languages and meta-modeling.
Ziserman, François
 
 François  Ziserman
 Engineer
  Cesson-Sévigné 
 FTRD/DIH/HDM/DEI 
 France 
FTRD/DIH/HDM/DEI,  4, rue du Clos Courtel, BP 59
Cesson-Sévigné   35512 France
Phone: (03) 02 99 12 39 53 email: francois.ziserman@cnet.francetelecom.fr
 Biography
 François Ziserman - François Ziserman is an engineer at France Tecom R&D,Rennes. He is holding a Master in Computer Science from the University of Orléans. He is currently leading the EOPM research team at France-Telecom R&D, Rennes.
Bézivin, Jean
 
 Jean  Bézivin
 Professor
  France 
 Nantes 
Université de Nantes, LRSG
Université de Nantes, LRSG,  2, rue de la Houssinière, B.P. 92208
Nantes   44322 France
Phone: (03) 02 51 12 58 13 email: Jean.Bezivin@sciences.univ-nantes.fr
 Biography
 Jean Bézivin - Jean Bézivin is professor of Computer Science at the University of Nantes, France. He got his Master degree from the University of Grenoble and Ph.D. from the University of Rennes. Since 1980 he has been very active in Europe in the object-oriented community, starting the ECOOP series of conference (with Pierre Cointe), the TOOLS series of conferences (with Bertrand Meyer), the Objet'9X industry meeting (with Sylvie Caussarieu and Yvan Gallison), and more recently the "UML" series of conferences (with Pierre-Alain Muller). He founded in 1979, at the University of Nantes, one of the first Master programs in Software Engineering entirely devoted to Object Technology (Data Bases, Concurrency, Languages and Programming, Analysis and Design, etc.). His present research interests include object-oriented analysis and design, reverse engineering, knowledge-based software engineering, product and process modelling
 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.
 

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 .
 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 .
 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.
 

Model organization

 With the emergence of the MOF specification, we see the arrival of a layered architecture for model engineering . This architecture is sometimes referred as four-levels architecture of OMG. The different layers are:
 
  • M3: The meta-meta-level, i.e. a self-defined language to define others languages at level M2. This level contains only one recommendation, which isMOF .
    • MOF
     
  • M2: The meta-level, i.e. a set of domain specific meta-models. At OMG any meta-model is defined in terms of MOF. A domain specific meta-model defines a language to write models at level M1. One of the most known meta-models is the UML meta-model, but there are much more. For example, we can imagine a Java meta-model.
    •  
  • M1: The model level. Any model is compliant with a specific meta-model. To give an example, a specific UML model for describing organization of the XML-Europe Conference would be one of M1 level models. Another example could be a Java program to handle inscriptions to the same conference.
    •  
  • M0 level: The last level is an instance level, and it is much more controversial. In this paper we will not use this level. Nevertheless, we could see this level as an execution of the Java program mentioned above.
    •  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 .
     
    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.
     

    Architecture of translator between abstract and concrete level

     The MOF translator uses several existing technologies such as XSLT, DOM and automatic compiler generation . 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 represents this architecture:
     
    Architecture of translator between abstract end concrete level
     

    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" . 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:
     
  • Attribute. This is the case when the value of an attribute in the destination meta-model depends on a value of an attribute in the source meta-model. There is no conflict of name even if you affect, for example, the attribute "name" to "name". Indeed, the name that appears on the left side of an assignment is an attribute belonging to the destination entity, while the name that appears on the right side is an attribute belonging to the source meta-model.
    •  
  • Literal value. In this case the value is represented between quotes. This value must correspond to values that are allowed for this entity in the destination meta-model.
    •  
  • Conditional. Our formalism allows a short cut to express a conditional. This mechanism is identical to macros in the C language. The condition can only depend on a specific value of an attribute. Consequently, value and attribute must belong to the source meta-model. The keywords resultIfTrue and resultIfFalse which appear in the code below can contain in turn another conditional, an attribute or a literal value. If they contain an attribute or a literal value, they must satisfy the same properties that both items above. The syntax for a conditional is the following one:
     ( condition ? resultIfTrue : resultIfFalse )
    •  
  • Concatenation. In this case elements of concatenation must be strings. Elements of the concatenation statement may be conditionals, in this case result of conditional must be a string. Concatenation is represented by the symbol "#" as shown below:
     E1 # E2
    •  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:
     
  • Role. This is the case when the value of a role in a destination meta-model depends on the value of a role, which belongs to source meta-model. As for attributes, there is no conflict of name. The name that appears on the left side of assignment is a role, which belongs to destination entity, while the name that appears on the right side is a role, which belongs to source meta-model.
    •  
  • Restricted role. This is the same case as above where we restricted the target entities. It can be interesting to divide a role of the source meta-model into several roles of the destination meta-model. Actually, only compositions can have a restriction. For example, we can divide a role "feature", which belongs to source meta-model, into two roles that belong to destination meta-model. One, which contains entities "Attribute" and another, which contains entities "Operation". This can be done with the following code:
    •  
    fields = feature [ Attribute ]
method = feature [ Operation ]
     
  • Conditional. A conditional based on roles has exactly the same restrictions than a conditional on an attribute. The only difference is that a condition is based on roles and can also contain some restrictions.
    •  Now, that we presented our formalism, we are going to define a mapping between abstract and concrete level.
     

    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:
     
  • An attribute is assigned to a literal value:
     a = "value"
    This code is transformed into a XSLT fragment, which is the following one:
    •  
    <xsl:attribute name="a">
<xsl:value-of select="'value'"/>
</xsl:attribute>
     
  • An attribute is assigned to another attribute:
     a = b
    This code is mapped into a XSLT fragment, which is the following one:
    •  
    <!--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)
     
  • An attribute is assigned to the result of a conditional:
     a = ( b op 'value' ? c : d )
    This code is mapped into a XSLT fragment, which is the following one:
    •  
    <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.
     
  • A role is assigned to another role:
     a = b
    Like for attributes, we must take into account the specificity of XMI. If the role "b" is an association, it can be represented by an XML attribute or an XML element as explained in the attribute mapping section. But if the role "b" is a composition, then it is can only be represented by an XML element. The code above is mapped into a XSLT fragment, which is the following one:
    •  
    <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.
     
  • A role is assigned to another role, which uses a restriction:
     a = b[c]
    In this code, the role "a" is assigned to an entity which can be accessed by the role "b" and only if his type is "c". Consequently the marked instruction (1) in the code above is transformed into the following one:
     <xsl:apply-templates select="./child::c"/>
    Therefore we only transform entities that correspond to the restriction, others are discarded :
    •  
  • A role is assigned to another role, which is an indirect role:
     a = b.c
    The code above is mapped into a XSLT fragment presented below:
    •  
    <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".
     
    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.
     
  • A role is assigned to another role, which is a composition. In this case, it is not necessary to verify if the role is an XML attribute or an element. A composition is treated as all children that belong to an entity; therefore we only create a template, which catch this case. The assignment is mapped into a XSLT fragment presented below:
    •  
    <xsl:template match="owner.b" mode="ownerEntity">
<xsl:element name="a">
<xsl:apply-templates select="./child::node()"/>
</xsl:element>
</xsl:templates>
     
  • A role is assigned to the result of a conditional:
     a = ( b = value ? c : d )
    This code is mapped into a XSLT fragment, which is the following one:
    •  
    <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".
     

    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:
     
    UML meta-model
     
    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:
     
  • The return type of a method. In the UML meta-model, the return type of a method is represented by a similar way that other attributes except that the value of "kind" attribute is "out". In the JAVA meta-model, the return type of a method is directly contained by the method. Consequently, we examine all parameters until we find the value of "kind" attribute equals to "out", and see what is his type. This is done by the following code:
    •  
    ResultType = (parameter.kind == "out" ?
( parameter.type == Integer ? Int :
( parameter.type == String ? String :
( parameter.type == Class ? parameter.type ))))
     
  • The role separation. Indeed, in the UML meta-model, operations and attributes are contained by only one role that is "feature". But in the JAVA meta-model, there is two roles that are "methods" and "fields". This role separation is done by:
    •  
    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>
     

    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.
     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.
     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
    The application of XSL for XML transformations in e-business solutions   Table of contents   Indexes   Text analysis tools for XML documents using regular expressions &, XSL