Reliable model transformations are essential for agile modeling. We propose to employ a configurable-semantics approach to develop automatic model transformations which are correct by design and can be integrated smoothly into existing tools and work flows. Model management is an essential activity in a model-driven development process. This is especially true in an agile context where models are continuously refined, iterated and combined. It is a common misunderstanding that development by stepwise refinement, or use of component algebras, requires using a highly planned and waterfall-like development process. See for example the following quote: An important variant of the waterfall model is formal system development, where a mathematical model of a system specification is created. This model is then refined, using mathematical transformations that preserve its consistency, into executable code. Based on the assumption that your mathematical transformations are correct, you can therefore make a strong argument that a program generated in this way is consistent with its specification. [30, p.32] We will argue below that methods from model management and formal system development, when combined with and inspired by approaches originating in the area of formal interface and specification theories, can play an important role also in an agile context.
Within the context of model-driven engineering, automated model transformations such as merging, differencing and slicing are of great importance. This is especially true in the industrial context where models can easily get so large that the engineers only see them through viewpoints, or slices; indeed, an explicit system model may not even exist, so that the general model is only implicitly given as a collection of viewpoints.
When the system model is so complex that no single engineer has a
comprehensive view, it can be very challenging to ensure correctness of an applied model
transformation by inspection. (Even when the system model is less complex,
ensuring correctness by inspection may be a difficult and error-prone process and
require advanced tooling.) The use of model transformations which are
correctby-design, or at least checkable-by-design, hence becomes increasingly important.
This point of view has also been argued in [
A good example is given by one of the case studies in the MERgE ITEA2
project [
To put it succinctly, it is an important problem in model-driven engineering to ensure that model transformations are semantically correct or that, at least, their semantic correctness can be inferred by a combination of slicing and local inspection.
One basic model transformation is the one of differencing, i.e. assessing
differences between models. This is an important ingredient in version control and
essential in three-way merging, but can also be applied, more elementarily, to
inspect related models for their common points and differences. Semantically
correct differencing procedures, for class diagrams and activity diagrams
respectively, have been proposed in [
It is our point of view that any “bottom-up” approach to correct model transformations which uses a complete formal semantics as a starting point, such as the above-cited, is of doubtful use in practice. In practice, engineers develop models according to an intuitive understanding of how things work, and not according to a complete formal semantics (if indeed it exists at all).
Apart from being correct-by-design or checkable-by-design, we have also
argued in [
[
merge from the input language, which makes it impossible to integrate their tool into a standard work flow without additional processing steps.
Within the subject of interface and specification theories in formal
methods, semantic model transformations exist for many types of low-level
behavioral models [
Similarly in spirit, Maoz et.al. have in [
We have in [
manages * managedBy 0..2 Manager 1 1
Car
manages 1..7 managedBy 0..1
0..2 Task
1
Car
As an example, consider the following scenario: An engineer wants to perform a three-way merge of two models which have evolved from a common ancestor. She will first use her development tools to attempt an entirely syntactic merge, which will detect some conflicts which are inessential because they only amount to syntactic differences while being semantically equivalent (given the developers’ intuitive understanding of the semantics). These she can easily detect, and she can adjust her merge tool to take them into account (hence applying a partial semantics). However, due to semantic effects which propagate through the models, also the reverse may happen: there may be semantic conflicts which go undetected by the syntactic approach. These are more difficult to detect and require that even a merge which is syntactically correct be carefully checked by applying possibly several different semantics.
applet applet applet must-override destroy stop must-override init must-override init paint start init paint start destroy stop paint start destroy stop (d =) i) ^ (t =) i) (:m =) i) (:m =) i)