7.4 A Flexible Modeling Tool System
7.4.4 Building the Model Transformation
First the participants met a couple of times to agree on the scope of the study, its goals, etc. After that they met roughly once a week in a room with a whiteboard. The whiteboard was used heavily to draw correspon-dence examples, metamodel and model fragments and to write patterns and consistency rules. The whiteboard was photographed when a session ended and when the whiteboard got full. The Transformation Architect then trans-lated the information in the photographs into the DReAMT process artefacts offline. One of the photographs is shown in Figure 7.7.
The Design Phase Expert and the Transformation Architect focused on crafting the relaxed metamodel and listing correspondence examples, consis-tency rules and reactions to the violations of the rules. A correspondence example represents a fragment of the source model(s) and a fragment of the target model(s). In this case the source models are the normal and relaxed metamodel and the target model is the consistency rule model. The source model fragments express a class of conflicts between the metamodels. They were given as class diagram fragments. The consistency rules and the reac-tions were just written as text.
For instance, the correspondence example in Figure 7.8 shows a case where the metamodel requires an instance of a type (Y in the figure) to be always be contained within an instance of another type (X), but the relaxed meta-model permits stand-alone instances. A concrete example is the metameta-model requiring class properties to be placed within classes.
When a designer is creating the consistency rules, they need to consider many things. Although a conflict between the actual metamodel and the relaxed metamodel always means that a model can be inconsistent, it does not necessarily mean that a rule should be generated.
The rule checker component will need to react to the modeling tool user’s actions very fast and without slowing down the computer. The designer may deem that checking for some particular conflict would likely happen too frequently or be too slow to be suitable for an interactive application. Other conflicts might be unimportant or so frequent that notifying the tool user would be annoying instead of being helpful. It could also be, that checking for one conflict can be combined with checks for other conflicts or in general needs to be handled in an exceptional way. For these reasons, the model transformation can not be automatic.
Figure 7.7: Whiteboard full of correspondence examples, rules and fragments
Figure 7.8: Correspondence example for mandatory/optional container The Design Phase Expert already knew before the transformation devel-opment process even started that some consistency rules were going to be needed. They were collected and they acted as a rough measure of how com-plete the transformational pattern system is, because all the rules should be found during the consistency rule creation process. If they are not found with the help of the patterns, then the designer has to discover them manually.
Some correspondence examples were found by analyzing concrete conflicts between the normal and relaxed metamodel. Because there was no concrete relaxed metamodel, this step was not systematic. Correspondence examples were also found by looking at the list of consistency rules that should be found and trying to find a reasoning for them in the differences between the metamodels. In total about a dozen correspondence examples were found and refined into transformational patterns and implementation.
Because there was no explicit relaxed metamodel, there was nothing to execute the model transformation against. For this reason, the model trans-formation implementation step was skipped for the first few iterations. In-stead, the transformational patterns were applied manually to selected parts of the metamodels by drawing the result on the whiteboard.
7.4.5 Observations and Conclusions
The iterations took roughly a week each, and both participants were busy with many other things at the same time. Having concrete artefacts in the form of correspondence examples and transformational patterns helped con-tinue the work where it had been stopped the last time.
A fully automatic model transformation could not have been used in this case, because the designer’s decision in two identical looking situations can be different. In fact, the designer needs to make quite many decisions. If the relaxed metamodel is changed, the validity of these decisions needs to be checked somehow. Decision context provided a convenient way to express validity conditions for decisions.
Because the transformational patterns were based on clearly specified
conflicts between two metamodels, the decision contexts were easy to define and they were very small. For example, in the case of mandatory/optional containment, the conflict is the multiplicity of 1..1 in the metamodel and 0..1 in the relaxed metamodel. If the multiplicity on either metamodel changes, the association is no longer a containment association or the association is not between the same metaclasses, the decision becomes invalid, otherwise it is valid. This can be captured in a decision context.
Chapter 8
Related Work
“There’s ninety thousand of them, mind,” said another wizard.
“I always heard there was no end to ’em,” said another. “It’s all down to dimensions, I heard, like what we see is only the tip of whatever, you know the thing that is mostly underwater—”
“Hippopotamus?”
“Alligator?”
“Ocean?”
– Terry Pratchett,Sourcery, 1988
8.1 Model Transformation Development
There is no end to the model transformation solutions available; languages, tools and techniques. What is discussed here is only the tip of the iceberg.
The solutions do not always address model transformation development di-rectly, but offer features that support one way over another. Because there is so little work directly on model transformation development, we explore also the indirect route.
In this dissertation we present an iterative process where a model trans-formation is developed in parallel with the application (RQ1). An incomplete but usable model transformation is produced in each iteration and used in the application development.
B´ezivin et al. [5] present reflective MDE, where a model transformation is developed by first defining it in a transformation technology independent language and then specializing it into a model transformation for a concrete tool. The concrete transformation (a model) is derived from the abstract
transformation (another model) according to some rules, so MDE is applied to applying MDE, hence the name.
They do mention that the model transformation development may take place during the application development. It is not clear, however, if only the finished model transformation is used in the application development.
It is possible, that the use of unfinished versions of model transformations is allowed, because the concept of a model transformation is very liberal.
A model transformation may be a collection of documentation, wizards and scripts—anything that helps the application designer.
Mellor and Watson [31] examine how the software development process and its roles change when MDE is applied. They do not add new roles, but instead add new responsibilities and skill requirements to the existing roles. Unlike in our approach, the model transformation development does not happen in parallel as a separate process, but merged into the applica-tion development process. In the architecture phase the architect decides the macro-process and selects the modeling languages and the model transforma-tions in addition to designing the application’s architecture. The individual model transformations and code generators are developed and tuned by the programmers.
Staron [41] presents results and conclusions drawn on applying MDE into industrial environments where there is a large base of legacy code. He relies on his and other researchers’ studies when he concludes, that MDE should not be applied in one go, but in stages. Models and modeling should be introduced into the macro-process gradually and in limited places in the process. Once the first models are in place, their role and expressiveness is increased until they are the main artefacts in the software development cycle.
This kind of adoption of MDE seems to imply that until the transition is finished, the modeling languages are going to be changing and the mod-els do not contain all the necessary information. We believe our approach is suited for such situations, because model transformations, too, can then be introduced into the macro-process gradually, assisting the designers with just a few activities in the beginning, but then with more activities, as the understanding grows and the transformation matures.