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
map:(a® b)® [a]® [b]
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
filter:(a® boolean)® [a]® [a]
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:(a® a® a)® [a]® a
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
- Apply a filter on the linearized model to select only the metaclass Association.
This yields us a list of Association metaclass instances.
- 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.
- 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
(map map nameElement) · (map
getConnection) · (filter isAssociation ) [element]
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 VisualBasic1
provided in the Rose982
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
- Select the sequence of Classifiers from the UML model
using a filter.
- 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.
- Filter the Feature metaclass instances to select only Attribute
metaclass instances.
- For each Attribute metaclass instance, apply a map to
generate a new Operation metaclass instance.
- 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
innerOperator c= (map newOp) · (filter
isAttrib) · (c#feature)
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
- Addition of new elements to an existing model
- Removal one or more model elements from an existing model
- 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.
Last update: $Date: 1999/05/28 08:58:42 $ $Revision: 1.4 $