Transformation framework

UMLAUT Transformation Framework

  A Framework for Automatic Transformation of UML models

A UML model consists of a large collection of modeling entities. In order to facilitate the transformation of such a model, we propose an object oriented framework that automates the tedious tasks involved with such a transformation.

We propose the use of a mix of object oriented and functional paradigm to develop a reusable toolbox of transformation operators. The general approach consists of two major steps. The first phase uses an iterator to traverse the UML metamodel instance into a linear sequence of model elements. The second phase consists of mapping a set of computational or functional operators onto each element in the linear sequence. The following subsections will describe in greater detail the structure of the framework. We conclude this section by demonstrating its application on two examples.

  Iterating Model Elements

Each UML model is made up of an instance of a collection metaclasses from the metamodel [uml-online]. This metaclass collection forms a complex network of associations among one another. Among all these associations, we are particularly interested in the composition relation of these metamodel elements. If we consider only the composition relation among model elements, we arrive at a spanning tree of all UML metamodel elements that describe the model. This spannig structure allows us to iterate through all the model elements in a given model. Thus, we apply a strategy of traversing this structure to derive a linear sequence, permitting us to apply standard list processing techniques.

In our transformation framework, we take a minimalist approach by traversing only a subset of the full composition structure. In particular, we will recursively traverse the ElementOwnership composition relationship between Namespace and ModelElement. The traversal is implemented using the Visitor design pattern [Gamma94]. ElementOwnership is a core composition relation that involves all top level modeling concepts like classes, associations, generalizations and packages, etc. This strategy separates the top level model elements from the lower metalevel model elements. Accessibility to these lower constructs is still possible via the appropriate selectors applied in the form of a map or filter on the top level model element. This classification of elements into different abstraction levels also helps to simplify the transformation semantics since we can defer the fine details until we really need to do a particular transformation.

Once we have ``virtually'' linearized our metamodel instance, we can proceed with the description of the transformation operation itself.

  Transformation Using An Applicative Approach

In the context of the theory of lists, it has been shown that any operation can be expressed as the algebraic composition of a small number of polymorphic operations like map, filter and reduce [Bird87]. This idea has been exploited in the object oriented context by Pacherie in his thesis [Pacherie97b]. He proposed to reify each of map, filter and reduce in the construction of a toolbox of algebraic operators for an object oriented framework for parallel computation [Jezequel98f]. We propose to extend these ideas to handle the polytypic structures described by the UML metamodel. We have chosen to follow an applicative style to develop our transformation framework because applicative programs are modular, making it easy to maintain and reusable.

Conceptually, given a linear list of elements, we can apply the classical operations map, filter and reduce over the list. Each of map, filter and reduce takes an algebraic operator and applies it over every individual element in the list. This algebraic operator can be any function. For instance, map is defined as



which takes a function, f:(a® b) , that acts on an object of type a and returns an object of type b and applies this function to a list of objects to type a to yield a list of objects of type b . f can be any unary function and our aim is to provide an object oriented toolbox of f 's from which we can use directly or customize by functional composition, aggregation of object inheritance. The role of f is to allow us to create, modify or extract information from the model elements of a UML model. This is also the abstraction used to effect the actual transformation.

Similarly, to perform selection of specific elements from a UML model, we apply a filter operation defined by



A filter takes a predicate, p:(a® boolean) , that is a function that takes an element of type a and returns a boolean value based on the predicate test. If the p returns true for a given element, the filter will return the element itself. Otherwise, it discards it. Thus, a filter takes a list of a given type, and returns a possibly shorter list of the same type. Filter plays the role of selecting elements for a given transformation. The predicate p can itself be an OCL expression to provide the selection criteria. Looking at the definitions of map and filter, we notice that both operations return a list of objects as their result. This means that we can re-apply another map or filter over the result. We can compose these polymorphic operations generically, as long as their input and output parameter type signatures match one another.

Finally, the reduce operation can be used to validate the integrity of a UML model.


Reduce takes a binary operator, r:(a® a® a) , and operates on successive elements of a list to yield a single valued result. r 'reduces' it's two operands and returns a single value of the same type. The effect is an 'accumulation' of results from individual tests to yield a summary of the operation.

Therefore, we propose an approach to construct an object oriented abstraction for the three polymorphic operations map, filter and reduce that allow us to apply any of the f , p and r functions. The transformation process can be generalized into three stages - element selection, element processing and reductive validation. We can re-apply the first two stages repeatedly using composition of map and filter to achieve the desired results. To illustrate the applicability of our proposal, we first present a simple example of its application. This will be followed by a more involved example to show the versatility of the approach.

  How It Works - A Simple Example

In a given UML model, it is common for association ends to remain unnamed. By default, the UML semantics defines an unnamed role to the classifier name to which it associates with. In some CASE tools, the name is not displayed, nor stored for reasons of reducing clutter. An example is the UML 1.1 metamodel provided by OMG in MDL format. In order to facilitate code generation from the UML model, we want to add a name for these unnamed association ends. This example shall describe a transformation step that names all unnamed association ends using the default UML definition describe earlier. The steps required are

1. Apply a filter on the linearized model to select only the metaclass Association. This yields us a list of Association metaclass instances.
2. Using the list of Association metaclass instances obtained above, we apply a map that extracts the AssociationEnd metaclass instances found in every Association. The result of this is a list of lists of AssociationEnd metaclass instances.
3. Again, using the previous result, we apply a double map over the list of lists that will name the association if it is not already named. The map return void in this case because the aim is a side effect of renaming an AssociationEnd.

It would be highly inefficient if the UML model was iterated for each step given above. Indeed, using the composition nature of map and filter, only a single iteration over the model is necessary. The composition can be visualized as


From the point of view of the composed map/filter operator, the control flow can be visualized in imperative pseudo-code as:

foreach element in uml_model
 if typeof(element) = Association then
   assoc_end_list = assoc.connection
   foreach assoc_end in assoc_end_list
    if assoc_end.name = void then
      assoc_end.set_name(assoc_end.type.name)
    endif
   endfor
 endif
endfor

We can see from the imperative code segment that such a task can easily be realized by a script-like manipulation language, such as VisualBasic¹ provided in the Rose98² modeling tool. With respect to this argument, we show, in our next example, the added versatility of our approach with respect to a general imperative script language.

  A More Complicated Example

In this second example, we want to illustrate the automatic generation of 'setter' Operations for public Attributes of a Classifier. For instance, we have an attribute name in a class, we would like to add the operation set_name, complete with the appropriate parameter bindings. As before, we first outline the transformation steps

1. Select the sequence of Classifiers from the UML model using a filter.
2. For each of the Classifiers in the list, we map a function to extract the Feature metaclass list of the Classifier. The result is a list of lists of Feature metaclass instances.
3. Filter the Feature metaclass instances to select only Attribute metaclass instances.
4. For each Attribute metaclass instance, apply a map to generate a new Operation metaclass instance.
5. For each generated Operation metaclass instance, we attach it back to the Classifier from which we obtained the Attribute.

We see that from step 1 to 4, the operations are pretty much the same. Step 5 introduces a new problem. Instead of requiring only one operand like the other functional operators, this step requires two. To solve this problem, we use object aggregation to wrap the Operation generation operator inside the last operator. To see how this works, first consider that we have a composition of


that takes a Classifier instance, c , and produces a list of Operation metaclass instances. We shall encapsulate this operator inside our aggregate operator, which operates itself over a list Classifier instances. For each Classifier that it operates on, it passes the same classifier to the inner component operator to obtain the list of Operation metaclass instances that it will attach to the Classifier. The imperative pseudo-code below illustrates the operation of our aggregate operator:

foreach element in uml_model
 if typeof(element) = Classifier then
   # scope of aggregate operator
   op_list = innerOperator.apply(element)
   element.feature.append(op_list)
 endif
endfor

In this example, we have illustrated a combination of operator aggregation and operator composition that allows us to flexibly define transformation operations on UML model elements. In the remaining subsections, we will define some of the semantic issues and problems related to the transformation of UML models.

  Transformation Semantics

In [Lano:ETAPS99], transformations on UML models were classified into three major classes. They are

• Enhancement transformation that 'enhances' the existing model by adding new entities or modifying existing properties.
• Reductive transformation that expresses a full UML model using a subset of the full notation.
• Refinement transformation that converts a model from one conceptual view towards another.

In practice, we believe that a transformation involves a combination of some or all of the above steps. From another point of view, we can address transformation as consisting of

1. Addition of new elements to an existing model
2. Removal one or more model elements from an existing model
3. Modification of one or more properties on an existing model element.

3 is an operation we call a computation that yields no new elements. Therefore, in the transformation process, any operation that is classified as a modification returns the same source element, except that some attributes of the source element have been modified by the computation. Both 1 and 2 pose a problem for the iteration process. This is a classical ``Robust Iterator Problem''.

We have just described the semantics of transformation at a very high level of abstraction. Further precision is required for each transformation operation. This will depend on what the exact transformation is.

A problem that we discovered in the course of constructing this framework is the inevitability of side effects in the transformation. This tends to give rise to impure applicative programs and we believe that it is an important area of research to refine the deeper semantics implicated by these side effects.

References

[1]

UML version 1.1, July 1997.

[2]

R. S. Bird. An introduction to the theory of lists. In M. Broy, editor, Logic of Programming and Calculi of Discrete Design, pages 3--42. Springler-Verlag, 1987.

[3]

Philippe Desfray. Automation of design pattern: Concepts, tools and practices. In Pierre-Alain Muller and Jean Bézivin, editors, Proceedings of UML'98 International Workshop, Mulhouse, France, June 3 - 4, 1998, pages 107--114. ESSAIM, Mulhouse, France, 1998.

[4]

Andy Evans. Reasoning with the Unified Modeling Language. In Proc. Workshop on Industrial-Strength Formal Specification Techniques (WIFT'98), 1998.

[5]

Garavel H. Kerbrat A. Mounier L. Mateescu R. Fernandez, J-C. and Sighineanu M. Cadp: a protocol validation and verification toolbox. In Computer Aided Verification, 1996.

[6]

Erich Gamma, Richard Helm, Ralph Johnson, and John Vlissides. Design Patterns: Elements of Reusable Object-Oriented Software. Addison Wesley, 1995.

[7]

Martin Gogolla and Mark Richters. Equivalence rules for UML class diagrams. In Pierre-Alain Muller and Jean Bézivin, editors, Proceedings of UML'98 International Workshop, Mulhouse, France, June 3 - 4, 1998, pages 87--96. ESSAIM, Mulhouse, France, 1998.

[8]

Jean-Marc Jézéquel, Alain Le Guennec, and François Pennaneac'h. Validating distributed software modeled with UML. In Pierre-Alain Muller and Jean Bézivin, editors, Proceedings of UML'98 International Workshop, Mulhouse, France, June 3 - 4, 1998, pages 331--340. ESSAIM, Mulhouse, France, 1998.

[9]

Jean-Marc Jézéquel and Jean-Lin Pacherie. Object-Oriented Application Frameworks, chapter EPEE: A Framework for Supercomputing. John Wiley & Sons, New York, 1998.

[10]

K. Lano and A. Evans. Rigorous development in uml. In Joint European Conference on Theory and Practice of Software -- ETAPS '99, volume 1577 of LNCS. Springer, mar 1999.

[11]

Kevin Lano and Juan Bicarregui. Formalising the UML in structured temporal theories. In Haim Kilov and Bernhard Rumpe, editors, Proceedings Second ECOOP Workshop on Precise Behavioral Semantics (with an Emphasis on OO Business Specifications), pages 105--121. Technische Universität München, TUM-I9813, 1998.

[12]

OMG. ad/99-03-10, uml profile for enterprise distributed object computing (edoc) rfp. 1999.

[13]

OMG. ad/99-03-13, uml profile for scheduling, performance, and time rfp. 1999.

[14]

J.-L. Pacherie. Système de motifs pour l'expression et la parallélisation des traitements d'énumérations dans un contexte de génie logiciel. PhD thesis, IFSIC / Université de Rennes I, Décembre 1997.

---

1

VisualBasic is a trademark of Microsoft Corporation.

2

Rose98 is a trademark of Rational Software Corporation.

3

H is a language defined for manipulating a metamodel in the commercial CASE tool ``Objecteering'' by Softeam.