Model Transformations
Scope
Starting with the report of the Dagstuhl Seminar on Language Engineering for Model-Driven Software Development, model transformation may be considered from two different perspectives, one targeting languages, the other dealing with contents. That distinction is critical and should provide the basis of process design and automation policies.
M.C. Escher’s Metamorphosis
When source and target models use the same language, transformations (aka endogenous) are performed within a single semantic envelop, and contents supported by a consistent set of concepts. Providing suitable traceability mechanisms, original contents can be restored by reversing decisions taken along the development path, among them: target parameters, design patterns, functional consolidations, functional or business requirements.
Things are more complex if source and target models are built using different languages, each with its own concepts and semantics. Corresponding transformations (aka exogenous) call for a mapping that will necessarily entails some loss in translation. That difficulty can be illustrated by the difference between code generation and “reverse” engineering: given that programing languages are a subset of modeling ones, the former can be seen as endogenous; that is not the case for the latter because the semantics of design models are not limited to programing. As a consequence, backtracking (aka round-tripping) from programs to models will have to fill the conceptual gap that separate models and programs (quoting Brian Selic, how do you build a pig from its sausages?).
Sequenced vs Continuous Metamorphosis
Models are built on purpose, using universal or specific languages. Regarding software engineering, initial models are meant to capture requirements, final ones to specify software components, and models in between to manage whatever steps are deemed necessary by contexts and/or methods. When milestones can be avoided, “agile” development may take the shortcut and iterate between requirements and deliveries. Otherwise the sequence of models must take into account the different stakeholders and manage their respective inputs all along the development process. Those inputs constitute the original contents of models. Following the model driven engineering paradigm, such sequences can be regrouped into three model layers: computation independent, platform independent, and platform specific.
Having properly identified and organized the original contents meant to be added at each layer, the question is to what extent and on what conditions could model contents be “engineered”, by transformation or any other means.
Model Transformations: carry over (a), translation (b), mapping (c).
Given those constraints, model transformation can be used for three kinds of purpose:
- To carry over non original contents across models, e.g data types and formats.
- To translate model contents into a different modeling language, e.g business rules.
- To map model contents across different contexts according to analysis or design decisions, e.g business entities into relational tables.
While model transformations can be used at any level, they are especially beneficial when applied selectively to architecture layers.
Meta-Models
Model transformation may appear under different guises yet most make use of meta-models, usually based upon the Meta Object Facility (MOF) proposed by the OMG. Meta-models are models of models, in other words they single out a subset of relevant features and get rid of the leftovers. As any model, meta ones are meant to meet some purpose, and that purpose should be, by nature, different of the purpose of the primary model. So what could that be ? There are basically two possibilities:
- Separation of concerns: since models can take into account more than a single concern (e.g business and technical), meta-models can be used to refine perspectives.
- Language translation: in that case the objective is to single out language constructs in order to transfer model contents into another language.
When meta-models objectives are not properly defined there is a risk of “flight for abstraction”: a model will forfeit its grasp of its original concern without catching a substitute.
Functional vs Generative Solutions
Following the parallel with linguistics, meta-models can be understood as functional or formal grammars:
- Functional approaches take languages as the outcome of evolutionary processes bound by human speaking capabilities and driven by social necessities. Along that perspective translations are performed at word (or artifact) level.
A functional approach of transformation through metamorphosis
- Formal approaches, e.g Chomskyan generative grammars, assume that language is a structure of the human mind based upon a single inner grammar shared by all human beings. Along that understanding, translations are performed at phrase (or model) level, assuming it should be possible to extract supporting structures based upon some universal (modelling) language.
A Chomskyan approach of transformation through supporting structures
While the Meta Object Facility (MOF) belongs to the functional paradigm, a generative approach would take the problem from the other side by assuming that, given a set of concerns, all models share some common semantics which can be interpreted by a virtual machine.
Functional approach: spoken words and translation rules.
Just like models describe business domains and applications, meta-models refer to model artifacts, whose syntax and semantics are described using a single metalanguage. As with language grammars, meta-models provide the basis for model transformation independently of contents semantics.
Generative approach: written symbols and shared meanings
Assuming that system engineering could provide a comprehensive, consistent and non ambiguous set of concerns, any model build within such framework could then be parsed into a generic representation before being processed. In order to describe such supporting structures (“charpentes” in french), a kernel of UML (UML#) is to be circumscribed.
UML# and layered transformations
Extension, Construction, Transformation
Model Driven Engineering is first and foremost about process management. In other words whatever operation is performed on models should be defined by modeling constraints on one hand, organizational responsibilities on the other hand.
- Inputs are provided by stakeholders responsible for domains, use cases, architectures, platforms, and configurations.
- Constructions (analysis or design) may be partially supported by automated tools yet they entail explicit responsibilities as set by contracts.
- Transformations don’t entail responsibilities and therefore can be fully supported by automated tools providing the used parameters are explicitly documented.
Operations on Models: inputs (+), construction (#), transformation (>).
Transformation vs Refactoring
Model transformation follows the arrow of time, taking expectations and commitments one step further towards application deployment, refactoring goes the other way, taking back past implementations in a bid to understand their purpose and to reinstate them. Whereas the former, by going forward, may change the contracts, the latter, by looking backward, is meant to freeze whatever was agreed in the past:
- Implementation: legacy code is wrapped and redeployed as it was.
- Source: legacy code is refactored and redeployed.
- Functionalities: applications are re-engineered.
Refactoring deals with the legacy of time
