DevBooststLogotudLogorewerseLogo modelplexLogo
Bridging the gap between models and source code.

Java Code Generation with Model-2-Model Transformations

Return to Main JaMoPP Applications Page



We use the capability of JaMoPP to print Java models into code to generate code from the UML model using a model-2-model (m2m) transformation. In contrast to model-2-text (m2t) transformations, which generate not necessarily structured text, a m2m transformation transform models (i.e., instances of metamodels) into other models and therefore ensure a correctly structured results. This has benefits in the case of Java of which some are briefly examined in this section.

We used the Atlas Transformation Language (ATL) of the Eclipse M2M Project for a transformation that transforms a UML class diagram into a set of Java classes. The transformation can handle all concepts of UML used in the contact management example. ATL is a declarative rule-based language relying on OCL.

In the following we describe one rule of our ATL transformation that transforms UML Properties into Java Fields shown below.

 rule Property {
   from umlProperty : uml!Property
   to javaField : java!Field (
     name <-,
     type <- typeReference
   typeReference : java!TypeReference (
     target <- if (umlProperty.upper = 1) then
         java!Package.allInstances()->any(p | = 'java.lang').compilationUnits->collect(
         	cu | cu.classifiers)->flatten()->any(c | = 'LinkedList')
     typeArguments <- if (umlProperty.upper = 1) then
         Sequence{} --empty type argument list
   typeArgument : java!QualifiedTypeArgument(
     target <- umlProperty.type

In UML, Attributes as well as AssociationEnds are Properties and are thus matched by the rule shown in Line 2. The corresponding concept in Java is Field of which one is constructed as seen in Line 3. The name of a UML Property is mapped to the name of the constructed Java Field (Line 4). For the Field's type, a TypeReference is created and assigned (Lines 5 and 7).

Determining the concrete target of the TypeReference is a bit more complex: if the UML Property has a multiplicity greater than one, it should be mapped to a list type. Therefore, depending on the UML Property's upper bound, we either map to the Java Type that corresponds to the UML Type of the Property (Line 9 - here ATL automatically determines the rule that translates the UML Type into the Java Type (rule not shown here)), or find the java.lang.LinkedList class by examining the Java standard library packages (Lines 11-12), which are also represented as models and given as input into the transformation. If a list is used, it should be type-argumented with the correct type. Therefore, a TypeArgument is constructed (Line 20), set to the correct type (Line 21) and assigned (Line 17).

The m2m transformation rule presented above, shows how a complex type mapping between UML and Java can be realised without bothering about details of the text syntax. In a m2t transformation one has to keep care of opening and closing angle brackets for type arguments and that all ; are correctly placed.

However, we do not want to imply that code should only be produced by m2m transformations in the future. As one can see, for instance, in Lines 11-12 of the transformation rule above, m2m transformation rules tend to become complex. With a m2t template, this part can be written down more elegantly. With the Java metamodel at hand, we can start to combine the advantages of m2m and m2t transformations. A type-safe template language for Java could be defined by extending the metamodel with template functionality. An example that uses JaMoPP with Reuseware shows that such extensions can now be performed using metamodelling.