ABSTRACT Aspects and Transformations to Support Evolution in(4)

A key benefit of system and software modeling is the ability to explore various design alternatives to reach a fixedpoint representation of a concrete system design. Among a diverse set of configuration possibilities, a model engineer must be able to explo

Sidebar: Model Transformation

As a core component of Model-Driven Engineering, model transformation represents the process of applying a set of transformation rules that take one or more source models as input to produce one or more target models as output [1]. There are two major categories of model transformation: model-to-code transformation and model-to-model transformation [2]. Model-to-code transformation generates source code (e.g., Java or C++) from models. The focus of such transformation is to generate artifacts at a lower level of abstraction that can be executed. Model-to-model transformation occurs at the same level of abstraction by translating between source and target models. Many modeling activities can be automated by model transformation to improve the productivity of model engineers and ensure the quality of models. Typical model transformation activities include model refactoring, model optimization, model refinement and model scalability.

To support the automation of model transformation, development tools need to offer a language for model engineers and developers to specify and execute the desired transformations. In general, there are three different approaches for defining transformations, as summarized from [1]:

Direct Model Manipulation – developers access an internal model representation and use a general purpose programming language

(GPL), such as Java or C++, to manipulate the representation from a set of procedural APIs provided by the host modeling tool.

Intermediate Representation – a modeling tool can export the model into an intermediate representation format (e.g., XML). Transformations can then be performed on the exported model by an external transformation tool (e.g., XSLT), and the output models can be imported back into the host modeling tool.

Specialized Transformation Language – a specialized transformation language provides a set of constructs for explicitly specifying the behavior of the transformation. A transformation specification can typically be written more concisely than direct manipulation with a GPL.

Currently, numerous specialized model transformation languages have been proposed by both academic and industrial researchers. These languages are used to define transformation rules and rule application strategies that can be either graphical or textual. Additionally, model transformation languages may be either imperative or declarative [2]. In addition to our C-SAW, some representative examples of other transformation systems follow:

Graph Rewriting and Transformation Language (GReAT) [3] is a graphical transformation language based on graph grammars and graph transformations. In this approach, models are treated as graphs and model transformations are specified as graph transformations. Graph transformations are realized by the application of transformation rules, which are rewriting rules for graphs. A transformation rule consists of two parts: the Left Hand Side (LHS) is a graph to match, and the Right Hand Side (RHS) is a replacement graph. If a match is found for the LHS graph, then the rule is fired, which results in the matched sub-graph of the graph under transformation being replaced by the RHS graph. GReAT provides graphical notations to specify graph patterns, model transformation rules and control flow of transformation execution.

ATLAS Transformation Language (ATL) [4] is a hybrid transformation language, which combines declarative and imperative constructs. Declarative constructs are used to specify source and target patterns as transformation rules (e.g., filtering model elements), and imperative constructs are used to implement sequences of instructions (e.g., assignment, looping and conditional constructs).

Although there exist different approaches to model transformation, the Object Management Group (OMG) initiated a standardization process by issuing a request for proposals on Query/Views/Transformations (QVT), which is near finalization [5].

References

1.

2.

3.

4.

5. S. Sendall and W. Kozaczynski, “Model Transformation - the Heart and Soul of Model-Driven Software Development,” IEEE Software, September/October 2003, pp. 42-45. K. Czarnecki and S. Helsen, “Classification of Model Transformation Approaches,” OOPSLA Workshop on Generative Techniques in the Context of Model-Driven Architecture, Anaheim, California, October 2003. A. Agrawal, G. Karsai, and A. Lédeczi, “An End-to-End Domain-Driven Software Development Framework,” 18th Annual ACM SIGPLAN Conference on Object-Oriented Programming, Systems, Languages, and Applications (OOPSLA), Anaheim, California, October 2003, pp. 8-15. I. Kurtev, K. van den Berg, and F. Jouault, “Rule-based Modularization in Model Transformation Languages Illustrated with ATL,” ACM Symposium on Applied Computing (SAC) - Model Transformation Track, Dijon, Bourgogne, France, March 2006. MOF 2.0 Query/Views/Transformations RFP, Object Management Group, 2002. /docs/ad/05-07-01.pdf.