Model transformations are key artifacts of Model-Driven Engineering (MDE). They are used for various MDE-activities including translation, optimization, and synchro- nization of models [130]. Resulting models should belong to the transformation’s tar-
get language, which means that they have to satisfy all the corresponding language constraints. This means that the developer has the task to design transformation rules such that they behave well w.r.t. language constraints. This task can easily become time-consuming and error-prone. Moreover, it requires high skills related to the theoretical foundation and the environment. Furthermore, a straight forward way to test the well-behavedness of a model transformation is to systematically apply it to selected test models and to analyze the transformation results. Since testing can become tedious, we are interested in a static and automatic way to guarantee constraints.
Based on existing theory [55, 114], we present a static, automated technique which is able to automatically adapt a given rule-based model transformation such that resulting models satisfy a given set of constraints. Use-cases for this technique are abundant, including instance generation [114], ensuring that refactored models do not show certain model smells (anymore), and generating model editing rules from meta-models to enable high-level model version management [66]. More examples of how advancing constraints into application conditions of transformation rules may be used can be found in [28].
Our technique builds upon the following basis (see Chapter 2 for more details): The de facto standard for defining modeling languages in practice are the Eclipse Mod- eling Framework (EMF) [34] for specifying meta-models and the Object Constraint Language (OCL) [99] for expressing additional constraints. Recent empirical find- ings suggest that OCL is especially fit to express complex constraints (compared to Java) [149]. Graph transformation [39] has been shown to be a versatile foundation for rule-based model transformation [40] focusing on the models’ underlying graph structure. To reason about graph properties, Habel and Pennemann [55] have devel- oped (nested) graph constraints being equivalent to first-order formulas on graphs. A construction of application conditions for transformation rules out of constraints was first developed for graphs by Heckel and Wagner [58] and then generalized in [55]. The first component of our technique is able to translate a reasonable subset of OCL constraints to nested graph constraints using the formally defined OCL translation in [114] as a conceptual basis. The second component of our technique integrates a graph constraint as an application condition into a transformation rule. The re- sulting application condition guarantees that the EMF model resulting from the suc- cessful application of the enhanced rule satisfies the original constraint. We call it a constraint-guaranteeing application condition. This integration does not change the rule’ actions. Note, our technique does not yet check in advance whether the given transformation rule with its application condition does already guarantee the constraint or not.
Our technique is implemented as Eclipse plug-in, called OCL2AC, being based on EMF and the model transformation language Henshin.
Note that our OCL translator is novel: Instead of checking satisfiability, it enhances transformation rules such that their applications can result in valid models only. To that extent, our technique is static; moreover, it not just checks constraint satisfaction but also aims the user to improve transformation rules. Specifically, we make the
following contributions:
• Solution design for automatically translating OCL constraints to graph con- straints and application conditions of transformation rules (in Sections 5.3.1 and 5.3.2). The theoretical background for our technique is fully elaborated and proven to be correct. The most comprehensive references are [55] for the calculation of preconditions and [114] for the translation of OCL into graph constraints.
• Implementation: Providing a ready-to-use tool, called OCL2AC, based on EMF and Henshin (in Section 5.3.4). The domain developer can use this tool to automate the whole process.
• Evaluation of this implementation in which we study the complexity and the performance of constraint translation and integration (in Section 5.4).
The rest of this chapter is structured as follows: Section 5.2 contains our running example, a simplified statecharts meta-model. Section 5.3 describes the design and implementation of our technique in more detail and presents the developed tool and its functionalities while Section 5.4 report the results of several research questions investigated regarding the restrictiveness, complexity, and performance. We discuss related work in Section 5.5 and conclude in Section 5.6.
5.2
Running Example
To illustrate the behavior of our developed technique, we use a simple Statecharts meta-model displayed in Figure 5.1.
Figure 5.1: A simple Statecharts meta-model
A StateMachine contains at least one Region and potentially Pseudostates of a kind such as initial. A Region contains Transitions and Vertices. Vertex is an abstract class
with concrete subclasses State and Pseudostate. A State can again contain Regions and Pseudostates to support the specification of state hierarchies. FinalState inherits from State. Transitions connect between Vertices.
A basic constraint on statecharts, which is not expressible by just the graphical struc- ture of the meta-model or by multiplicities is the constraint no outgoing transitions: A FinalState has no outgoing transition. This constraint can be specified in OCL as follows:
c o n t e x t F i n a l S t a t e i n v a r i a n t n o o u t g o i n g t r a n s i t i o n s : s e l f . o u t g o i n g>
i s E m p t y ( ) ;
Our technique can translate this constraint into the graph constraint in Figure 5.2. The graph constraint states that a FinalState does not have an outgoing transition. Node names signify inclusions of graphs along the nesting structure.
∀self:FinalState
,
@self:FinalState outgoing var9:Transition
Figure 5.2: Graph constraint
no outgoing transitions Figure 5.3: Transformation rule
Figure 5.3 shows a simple transformation rule in Henshin. The rule inserts an edge of type outgoing between a Vertex and a Transition which both have to exist before rule application and are preserved.
As a second capacity, our technique can adapt a given transformation rule such that it is not applicable if the result would violate a graph constraint. This behavior is achieved by integrating a new application condition into the rule. Integrating, e.g., the constraint no outgoing transitions into the rule insert outgoing transition results in the application condition displayed in Figure 5.4. The upper part forbids node rv:Vertex being matched to a FinalState. The lower part requires that the rule is matched to consistent models only, i.e., not containing already a FinalState with an outgoing Transition. It may be omitted if consistent input models can always be assumed.
@ rv:FinalState rt:Transition ,∃ rv:FinalState rt:Transition var9:Transition outgoing ∨ ∃ rv:FinalState rt:Transition ∧ @ rv:Vertex rt:Transition self:FinalState ,∃ rv:Vertex rt:Transition
self:FinalState outgoing var9:Transition ∨ ∃
rv:Vertex
self:FinalState outgoing rt:Transition
Figure 5.4: Application condition for the rule insert outgoing transition after inte- grating the constraint no outgoing transitions