MDE Case Studies

Modelling software is usually about abstraction. UML allows for the introduction of custom abstractions using stereotypes and/or profiles. These abstractions can be refined to a lower-level UML description using refinement model transformations. Several refinement transformations are provided to refine such abstractions as 'Observer', 'Singleton' and 'Applet'. Refinement transformations are also provided to refine standard UML elements into lower-level structures, such as associations to public attributes and public attributes to encapsulated attributes (with getter and setter methods).

Some case studies have been worked out using UML 1.4, UML 2 and Java. All case studies can be found in our Subversion repository under UML1CaseStudies and UML2CaseStudies. As part of these case studies, a number of model transformations have been written using the ATLAS Transformation Language. If you want to try out the case studies for yourself, follow the installation instructions link below:

Installation instructions

The following case studies are available:

• Instant Messenger case study
• Breakout Game case study

You can view the following presentation, including flash demo, of the instant messenger case study:

• Wagelaar, D., MDE Case Study: Using Model Transformations for UML ands DSLs, presentation/demo for JUGS, Zürich, Switzerland, 30 March 2006.
  [ OpenOffice ] [ Adobe PDF ] [ Flash demo (49 min.) ]

• Dennis Wagelaar

Below you'll find an explanation for each of the model transformations based on the UML 2 meta-model. All transformations use an 'IN' and an 'OUT' UML2 model next to any specified models, except where specified differently.

This is a basic transformation that copies all UML2 model elements from the input model to the output model. It includes a condition that makes sure only the elements from the 'IN' model are copied.

This is a transformation that copies particular kinds of stereotype applications from the input model to the output model. It is not a stand-alone transformation, but is meant to be superimposed on top of the UML2Copy transformation. Note that it is possible to superimpose any number of transformations on top of eachother and this transformation is usually the last on the stack.

Note: The UML2Profiles.ecore meta-model is a special “wrapper” meta-model that imports the standard UML meta-model as well as all applicable UML profiles. UML profiles can be treated as Ecore meta-models, since they include EClass (meta-class) representations of each Stereotype.

This transformation applies the Accessors profile, if necessary. It is not a stand-alone transformation, but is meant to be superimposed on top of the UML2Copy transformation and superimposed by the UML2ProfileCopy transformation.

This transformation introduces accessor methods (getters and setters) for all public properties and then converts those properties to private properties. It is not a stand-alone transformation, but is meant to be superimposed on top of the UML2Copy transformation and superimposed by the UML2ProfileCopy transformation.

These transformations implement the Observer profile. They introduce the infrastructure to implement the “Observer”, “Observable” and “subscribe” stereotypes. Any instances of “Observer” classes that have a “subscribe” association to an “Observable” class, will automatically be subscribed to the “Observable” instance that they are linked to. In addition, all setter operations of the “Observable” Class will be updated to do a notify as well. An “update” operation is introduced for each “Observer” class, which is configured to invoke any “onXYZChange” operations, where “XYZ” is the name of the property that is changed. They are not stand-alone transformations, but are meant to be superimposed on top of the UML2Copy transformation and superimposed by the UML2ProfileCopy transformation. There are two variants available:

This transformation implements the AbstractFactory profile. It is not a stand-alone transformation, but is meant to be superimposed on top of the UML2Copy transformation and superimposed by the UML2ProfileCopy transformation.

This transformation implements the Singleton profile. It is not a stand-alone transformation, but is meant to be superimposed on top of the UML2Copy transformation and superimposed by the UML2ProfileCopy transformation.

These transformations implement the Applet profile. They are not stand-alone transformations, but are meant to be superimposed on top of the UML2Copy transformation and superimposed by the UML2ProfileCopy transformation. There are two variants available:

This transformation implements the Async profile. It wraps the execution of all asynchronous operations in a thread. It is not a stand-alone transformation, but is meant to be superimposed on top of the UML2Copy transformation and superimposed by the UML2ProfileCopy transformation.

This transformation translates all UML2-specific data types to programming language types. As such, it must be applied after all transformations that introduce references to UML2-specific data types. It is not a stand-alone transformation, but is meant to be superimposed on top of the UML2Copy transformation and superimposed by the UML2ProfileCopy transformation.

This transformation generates Java code from a UML2 model. As such, it is applied after all UML2-to-UML2 refinement transformations. It requires a 'parameters' model that specifies the 'path' to write the code to. This 'parameters' model is an XML file that needs to be injected using AM3 Ant tasks.

This transformation generates an ATL transformation that copies models using the given Ecore meta-model. It has been used to generate parts of the UML2Copy and UML2ProfileCopy transformations. It requires a 'config.atl' library that specifies 'path', 'inclusionCondition' and 'useQualifiedName' helpers.

This transformation generates an Ant 'build.xml' file from a configuration model. This 'build.xml' file is an Ant template that contains macros and targets for executing the 'UML2…' transformations according to the given configuration. The 'build.xml' file must be extracted using AM3 Ant tasks.

This transformation generates a 'parameters.xml' file from a configuration model. This 'parameters.xml' file is used by the UML2ToJava transformation. The 'parameters.xml' file must be extracted using AM3 Ant tasks.

Below you'll find an explanation for each of the model transformations based on the UML 1.4 meta-model:

These are very simple transformations, meant to copy all elements of one model into another model. There are two variants available:

Note that the ModelCopy.atl transformation has been generated with the ModelCopyGenerator.atl transformation. The “inclusionCondition” helper used in the ModelCopyGenerator.atl transformation is in turn derived from the output of the ModelUsage.atl query transformation, which is generated by the ModelUsageGenerator.atl transformation .

These transformations are meant to merge a model with the main model. The MERGE model is merged with the IN model and written to the OUT model. They are currently limited to copying elements that can occur in UML Class Diagrams (including Action Semantics). There are two variants available:

Note that most other refinement transformations are derivatives (and include the rules) of the MergeModel.atl transformation. This allows the refinement transformations to include static model content into the target model without having to generate it (and use complex queries to make links to this newly generated content).

These transformations introduce Attributes (with Java initial values) for each Association End. There are two variants available:

These transformations introduce accessor Operations/Methods (with Java bodies) for each public Attribute. The public Attributes are then made private. This transformation is also used in refactoring as “Encapsulate Field”. There are two variants available:

These transformations introduce the Java infrastructure to implement the “Observer”, “Observable” and “subscribe” Stereotypes. Any instances of “Observer” Classes that have a “subscribe” Association to an “Observable” Class, will automatically be subscribed to the “Observable” instance that they are linked to. In addition, all setter Methods of the “Observable” Class will be updated to do a notify as well. An “update” Operation/Method will be introduced for each “Observer” Class, which is configured to invoke any “onXYZChange” Operations, where “XYZ” is the name of the Attribute that is changed. There are two variants available:

A simple transformation that adds a static “getInstance” Operation/Method and a static “instance” Attribute to each Class with a “Singleton” Stereotype:

These transformations introduce Java Applet infrastructure for each Class with an “Applet” stereotype. There are two variants available:

These transformations replace the OCL types with Java types. There are two variants available:

A simple transformation that wraps the Method body of each Operation with an “asynchronous” Stereotype inside a Thread:

An ATL query that generates Java code from a low-level (i.e. fully refined) UML model. Note that no code is generated for Associations, since the AssociationAttributes transformation is responsible for translating them to implementation-level attributes.