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 programming 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 programming. 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

More generally, what can be done from model to code is not necessarily possible between model layers:  as each layer embodies specific information, some derived, some decided, transformation policies will have to fence off what is added at each stage, together with its associated rationale.

Transformation Profiles

While the interpretations of CIMs and PIMs may be surprisingly diverse, there is a broad consensus about what platform  specific models are about, how to build them, and how to use them to implement system components.  Given the combined benefits of PSMs, design patterns and code generation, it may be tempting to generalize this approach by applying automated transformation to computation independent and platform independent models. But that would rely on the implicit assumption that there is no added value between models; or put in other words, that engineering processes are pointless.

Hence the need of explicit rationales based upon models contents:

  • Technical: uses the same functional models to target different platforms (a).
  • Development: uses models to support the collaboration of different teams within the same business units (b).
  • Enterprise: uses models to support the consolidation of different business processes within the same functional architecture (c).
ccccccc

Transformation Profiles

Further readings

External Links

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s


Follow

Get every new post delivered to your Inbox.

Join 303 other followers

%d bloggers like this: