Transforming UML Profiles to EMF Profiles

Introduction

As Domain Specific Modeling Languages (DSMLs) have high design and implementation costs, UML profiles are getting more and more popular as an option to bridge the gap between DSMLs and general purpose modeling languages (GPMLs). UML profiles provide a generic mechanism for customizing UML to support domain specific needs. EMF profiles emulate UML profiles inside the eclipse modeling framework environment. In this blog post, we describe our project which consists of providing a model-to-model transformation from UML profiles to EMF profiles to help users evade having to create a new EMF profile from scratch when a UML profile specifying the same domain already exists.

Background

UML profiles are packages of related and coherent extensibility elements including stereotypes, properties (previously called "tagged values") and constraints. The following figure represents parts of the UML metamodel defining UML profiles. It's kept rather simple by abstraction to hide the true complexity shifting the focus on the meta-class "Stereotypes" and the association "Extension". We can see that a Profile consists of the Profile itself, a ProfileApplication, a Stereotype, an Extension and an ExtensionEnd.

Excerpt of the UML Profile metamodel

EMF Profiles can be integrated into the EMF environment to act as a counterpart to UML Profiles. The figure below is an abstract representation of the EMF Metamodel with a focus on the stereotype and the extension elements. Since Ecore does not natively support Profiles, the EMF Profile extension is needed. As depicted below, a Profile in EMF consists of a Profile, a Stereotype and an Extension. The ProfileApplication, however, is not part of the EMF Profile itself.

Excerpt of the EMF Profile metamodel

 

 Conceptual Mapping and Implementation

When transforming Profiles from UML to EMF we look out for similar concepts and map them accordingly so that no relevant information is lost after the transformation. The core concepts can be mapped as shown in the table beneath.

Table 1. Mapping general Profile concepts

Furthermore, when examining the metamodels of both sides two problems become noticeable. First, in UML an Extension is represented by the Extension itself which furthermore consists of ExtensionEnds. They hold the reference to a Stereotype and to a Class. The main purpose of ExtensionEnds is saving the corresponding references of an Extension. In EMF an Extension is represented only by one class. Thus, the references to a Stereotype and a Class are part of the extension. Second, the ProfileApplication in UML is part of the profile itself. In EMF however it is outside of the profile.

The transformation is carried out in two steps primarily to keep the original design rational of a defined UML Profile and to exploit metamodel-aware profile reuse mechanism as introduced by EMF Profiles. 

1. Step 1: Map all needed UML concepts that a profile requires so it can be applied to a model to a set of generic Ecore classes in order to act as placeholders for future extensions.
2. Step 2:  Map all the specific features and references of stereotypes defined by a UML profile to stereotypes of an EMF profile. Extensions to UML meta-classes are mapped to generic Ecore classes as produced in the first step.

Step 1: Mapping of UML Concepts to Generic Ecore EClasses

Generic classes are used as placeholders for future ecore model classes. The goal is to design them with a minimal set of necessary attributes and references so that the transformed profile can still be applied to them. These classes work as a generalization of future model elements that are extended by the profile. Therefore every attribute and reference they have limits the options of future modelling elements where the profile can be applied to. Consequently we analyzed the attributes and references of the native UML classes and tried to find the minimum set of features necessary, so that it can be used as a reference by the EMF Profile. We focused on the UML concepts that are used in the UML Profile Store. In particular we produced generic EClasses for the following UML concepts: Class, Property, Enumeration, EnumerationLiteral, Operation, DataType, PrimitiveType and ProfileApplication. The table below features an example listing the attributes and references of the generic class (It does not represent a mapping table).

Table 2 Details on the generic Class

Step 2: Mapping of UML Concepts to EMF Profile Concepts:

After producing the generic classes, they can  be used for supporting the mapping of the EMF Profile specific concepts such as the profile, the stereotype and the extension. The table below depicts the example of the mapping of stereotypes. Even though both Stereotype concepts serve the same purpose, some features are di fferent and could not be mapped. In particular there is no visibility in ecore. This information is lost after the transformation. Furthermore Constraints are not de fined in ecore. We solved this problem by transforming constraints into annotations and storing the name and the OCL expression as its value. This expression can then be evaluated and enforced by the OCL line editor in EMF.
 

Table 3 Mapping Stereoptypes

 

Evaluating the Transformation

In order to evaluate the practical application of the transformation, we developed some samples of source models (inputs) and their respective expected target models (outputs). A comparison of the actual result of the transformation with the expected output serve as a benchmark for the degree of the practical application of the transformation. Furthermore, by varying modeling elements, their relationships and their numbers, so does their complexity. We also test the transformation using all existing profiles from the UML Profile Store as transformation inputs which are complete profile examples as used in the industry. Overall, we analysed the practical application of 20 transformed profiles from the UML Profile Strore and perceived  no unexpected behavior.