Model Driven Engineering for Distributed Real-Time Embedded Systems 2009

Advances, Standards, Applications and Perspectives

Jean-Philippe Babau, Mireille Blay-Fornarino, Jöel Champeau, Sylvain Robert, Antonino Sabetta, Jean-Philippe Babau, Mireille Blay-Fornarino, Jöel Champeau, Sylvain Robert, Antonino Sabetta

• Publisher: Wiley-ISTE
• Year: 2013
• Print ISBN: 9781848211155
• eBook ISBN: 9781118619551
• Edition: 1
• Topic: Biological Sciences
• Subtopic: System Theory
• Index: Biological Sciences

Model-based development methods, and supporting technologies, can provide the techniques and tools needed to address the dilemma between reducing system development costs and time, and developing increasingly complex systems. This book provides the information needed to understand and apply model-drive engineering (MDE) and model-drive architecture (MDA) approaches to the development of embedded systems. Chapters, written by experts from academia and industry, cover topics relating to MDE practices and methods, as well as emerging MDE technologies. Much of the writing is based on the presentations given at the Summer School "MDE for Embedded Systems" held at Brest, France, in September 2004.

Chapter 1

Model Transformation: A Survey of the State of the Art ¹

Rien ne se perd, rien ne se crée, tout se transforme.
(Nothing is lost, nothing is created, everything is transformed)
Antoine-Laurent de Lavoisier (1743-1794)

1.1. Model-driven engineering

Model-Driven Engineering (MDE) is an approach to software development where the principle artefacts are models (as opposed to source code). It is a natural next step in the evolution of software development to continue to raise the level of abstraction in order to tackle increasingly complex problems. The main goal is to reduce the accidental complexity [BRO 86] of software, caused by the technology, methods and programming languages used to develop software. Of course, the essential complexity that is inherent to the problem to be solved cannot be reduced, no matter which approach, technology or language is adopted.

The basic principle behind MDE is that everything is a model. As such, it provides a generic approach to deal with all possible software artefacts used and produced during the software development life-cycle (e.g. requirement specifications, analysis and design documents, test suites, source code, and so on). Even the languages used to specify the models can be considered as models too, which are referred to as metamodels.

The current state-of-the-practice of tool support for MDE is still in the round-trip engineering stage: the models and the code co-exist, and a change to either of the two artefacts requires a synchronization of the other. Ideally, this synchronization is automated, but in practice there is often some manual effort involved as well. In contrast, the state of the art in MDE support is model centric, where the code can be fully generated from the models [RAI 04].

Accepting the basic idea that everything is a model, and adopting a model-centric view, we need techniques and tools that allow us to manipulate and reason about such models. The technique that can be used to achieve this is commonly referred to as model transformation. According to [SEN 03, GER 02], model transformation is the heart and soul of model-driven software development. It is needed for supporting a wide range of model-driven activities such as code generation, model extraction, model refactoring, model verification, model simulation, and many more.

1.2. Model transformation

1.2.1. Definitions

Kleppe et al. [KLE 03] provide the following definition of model transformation: a transformation is the automatic generation of a target model from a source model, according to a transformation definition. A transformation definition is a set of transformation rules that together describe how a model in the source language can be transformed into a model in the target language. A transformation rule is a description of how one or more constructs in the source language can be transformed into one or more constructs in the target language.

This definition is very general, and covers a wide range of activities for which model transformation can be used: automatic code generation, model synthesis, model evolution, model simulation, model execution, model quality improvement (e.g. through model refactoring), model translation, model-based testing, model checking, model verification, and many more. For some types of activities we would like to support, the definition needs to be extended, in order to allow for model transformations that take more than one source model as input and/or produce multiple target models as output. The different source (resp. target) models do not even need to be described in the same modeling language. Examples of activities where we need more than one source or target model are model merging (in the context of collaborative modeling), model weaving and model composition [FLE 07, HID 09].

In order to support this variety of model transformation activities, we need to put in place a number of different mechanisms. Obviously, we need transformation languages that describe how to specify model transformations. This will be the topic of section 1.3. For those languages that have an underlying formal foundation, we need formal methods and theories to rely on. We also need tools that implement and support these languages and formalisms. A wide variety of such tools is available, research prototypes as well as commercial tools. Methodologies or processes are needed in order to help us to use all of these mechanisms in an efficient way. Examples are the Rational Unified Process (RUP, [KRU 03]) and the Executable UML methodology based on the Schlaer-Mellor method [RAI 04]. To facilitate communication and interoperability, standards are needed for all of the above. The most obvious standards are those proposed by the OMG (e.g. UML, XMI, QVT, MOF, OCL, SysML and many more). Other de facto “standards” are those proposed by the Eclipse community (e.g. EMF, ECore, and so on).

1.2.2. Taxonomy

[MEN 06c] proposed a taxonomy of model transformation. Many of the ideas in this taxonomy were based on the discussions of a working group of a 2004 Dagstuhl seminar on Language Engineering for Model-Driven Software Development. We briefly review the essential parts of this taxonomy here.

Endogenous versus exogenous transformations

In order to transform models, these models need to be expressed in some modeling language (e.g. UML). A distinction can be made between endogenous and exogenous transformations, depending on the language(s) used to express source and target models involved in the model transformation. Endogenous transformations are transformations between models expressed in the same language. Exogenous transformations are transformations between models expressed using different languages.

A typical example of an exogenous model transformation is model synthesis, in which a design model is extracted from source code. The inverse exogenous transformation is code generation to transform the design models into source code. Another well-known example of exogenous model transformation is model translation, in order to transform some representation of a model into an equivalent representation expressed in a different modeling language (e.g. UML to XMI, or class diagrams to entity-relationship diagrams).

A typical example of endogenous transformation is optimization: it aims to improve certain operational qualities (e.g. performance), while preserving the semantics of the model. A related endogenous transformation is model refactoring, which aims to improve the model structure.

Horizontal versus vertical transformations

An orthogonal way to classify model transformation is by looking at the abstraction level of its source and target models. For horizontal transformations, the source and target models must reside at the same level of abstraction. Typical examples are model refactoring (an endogenous transformation) and model translation (an exogenous transformation). For vertical transformations, the source and target models must reside at different abstraction levels. A typical example is refinement, where a specification is gradually refined into a full-fledged implementation, by means of successive refinement steps that add more concrete details [BAC 98].

1.3. Model transformation languages

Model transformation languages serve to specify the syntax and semantics of model transformations, and are essential if we want to provide automated support for model transformation. A wide variety of model transformation languages exist. Many of them have emerged from the academic community, while others originate from industry. In the latter category we find, for example, OMG’s QVT specification [OBJ 08], which is compatible with the MDA approach based on MOF and UML. The academic languages include, without attempting to be complete: ATL, Kermeta, Tefkat, SiTra and many languages that are based on the underlying approach of graph transformation (e.g. ATOM3, AGG, Fujaba, GReAT, MOFLON, VIATRA2).

Due to this wealth of transformation languages, it is necessary to provide a taxonomy that allows us to assess the conceptual commonalities and differences between these languages. This is the purpose of the current section.

Declarative versus operational

A first criterion to compare transformation languages is whether they rely on a declarative or an operational (a.k.a. imperative or constructive) specification.

Declarative approaches focus on what needs to be transformed into what by defining a relationship or mapping between the source and target models. These approaches are attractive because they tend to be easier to write and understand by software engineers. In addition, desirable services such as source model traversal, traceability management and bidirectional transformations may be offered by the underlying transformation engine.

Operational approaches focus on how the transformation needs to be performed by specifying the steps that are required to derive the target models from the source models. Such approaches may be required to implement transformations for which declarative approaches fail to guarantee their services. Especially when the application order of a set of transformations needs to be controlled explicitly, an imperative approach is more appropriate thanks to its built-in notions of sequence, selection and iteration. Such explicit control may be required to implement transformations that reconcile source and target models after they have been both heavily manipulated outside the transformation tool.

Interestingly, the QVT specification [OBJ 08] offers two different language...

Table of contents

• Cover
• Title Page
• Copyright
• Chapter Summary
• Chapter 1: Model Transformation: A Survey of the State of the Art
• Chapter 2: Model-Based Code Generation
• Chapter 3: Testing Model Transformations: A Case for Test Generation from Input Domain Models
• Chapter 4: Symbolic Execution-Based Techniques for Conformance Testing
• Chapter 5: Using MARTE and SysML for Modeling Real-Time Embedded Systems
• Chapter 6: Software Model-Based Performance Analysis
• Chapter 7: Model Integration for Formal Qualification of Timing-Aware Software Data Acquisition Components
• Chapter 8: SoC/SoPC Development using MDD and MARTE Profile
• List of Authors
• Index