Towards an Advanced Model Driven Engineering Toolbox Frédéric Jouault
Jean Bézivin
Mikaël Barbero
AtlanMod team, INRIA & EMN {frederic.jouault,jean.bezivin}@inria.fr,
[email protected] Abstract Model Driven Engineering (MDE) is frequently presented as an important change in software development practices. However behind this new trend, one may recognize a lot of dierent objectives and solutions. This paper rst studies the multiple facets of MDE, and its evolution in the recent period. Several new usage scenarios (i.e., reverse engineering, and models at runtime), which have appeared following the initial forward engineering scenario (i.e., PIM to PSM), are described. Then, the MetaBoxed modeling toolbox is introduced, and some of its applications to these scenarios are described.
1
Introduction
In this paper we refer to the OMG MDA
TM (Model
Driven Architecture) proposal as the initial
initiative that triggered a broader area of research in the automation of model processing.
We
consider MDE (Model Driven Engineering), as being the more general approach, including but not limited to MDA. MDE encompasses other non-OMG projects like Microsoft DSL Tools, Eclipse
1
Modeling Project (EMP), Vanderbilt University Generic Modeling environment (GME), and many other initiatives making explicit references to software and system modeling. MDA originally tackled the forward engineering problem of building complex systems from models.
Recently, other scenarios have appeared:
reverse engineering (i.e., discovering relevant and
understandable models from complex systems), and models at runtime (i.e., managing complex systems using a synchronized runtime model representing their state). Broadening the application scope of MDA to cover these new scenarios requires speci c tool support. In order to enable these three scenarios, we introduce here the MetaBoxed modeling toolbox. This paper is organized as follows. The three considered usage scenarios of MDE are described in Section 2, which concludes by identifying a list of implementation problems.
The MetaBoxed
platform is described in Section 3, which also shows how it addresses the problems identi ed in Section 2.4. Section 4 concludes.
2
MDE Scenarios
It is not fair to date the origins of MDE only to the announcement date of the MDA proposal in November 2000 [1]. Many previous contributions were already going in this direction well before this period. Acronyms like AD/Cycle, CDIF, GraphTalk, OIS, sNets, MetaCASE among others testify of a previous very strong activity in this domain.
The story of all in uences that have helped to
shape the modern history of MDE has still to be written and is not the subject of this paper. We consider here the recent history of MDE, starting from the initial OMG MDA proposal [1]. We are interested in the evolution of its application scope. Since this initial OMG proposal, MDA has come to mean a lot of dierent things to dierent people. This situation of diversity is sometimes creating confusion. The goal of the present section is to study some of the dierent meanings of MDE and to propose some de nitions and clari cations
2
Figure 1: Basic relations of representation and conformance in MDE
that may help the mutual recognition of the variety of goals in the model engineering community. This presentation is further detailed in [2]. In order to clarify as much as possible the discussion, we will distinguish between the principles, the standards, and the tools. One assumption on which this work is based is that there is a common and minimal set of basic MDE principles. The common principles are becoming widely accepted. As presented in Figure 1, we can summarize them by stating that MDE relies on two basic facts (1) the representation of any kind of system by models and (2) the syntactic conformance of any model to a metamodel. Within this context, models are intended to be automatically processed by a set of operators. One of the major automatic operations for a model is a transformation [3]. MDE promotes the usage of models as rst class entities [4]. Any model used to represent a given system conforms to a precise metamodel [5]. Some models may be obtained from other models by chains of transformations or other automated operations on models (composition, dierence, etc.). We call them derived models. However other models have to come from somewhere in the rst place: we call them initial models.
In classical forward engineering, many initial models are created by
human operations. In reverse engineering, initial models may sometimes be produced from systems
3
Figure 2: The three main families of MDE applications
by automatic or semi-automatic means. This is for example the case when a model is created from legacy code by a speci c parser. In addition to forward engineering where systems are created from models and to reverse engineering where models are extracted from systems, there is a new area of application of MDE where the system and the model coexist in time and are kept synchronized. We refer to this application area by models at run time in Figure 2. This expression was coined in to state that a dynamic system may have at execution time a knowledge, and operational access to various models representing it. These models are kept in synchronization with the current state of the system. One important idea in this work is based on the dichotomy between what we call systems and what we call models. A system lies in the real world while a model lies in the modeling world. This distinction is absolutely essential to any MDE conceptual framework. This allows distinguishing the three cases presented in Figure 2:
• Forward engineering • Reverse engineering • Models at run-time
where a system is created from a model,
where a model is created from a system,
where a model coexists with the system it represents.
Note that the conformance relation between the model and the system holds in the three cases.
4
2.1
Forward engineering
MDE was initially intended to provide some high-level compilation process between platformindependent business situations expressed in the UML language into platform-dependent executable programs. The basic idea proposed in the MDA approach is to translate from an abstract Platform Speci c Model (PIM) expressed in UML into a more concrete Platform Speci c Model (PSM). When the PSM is obtained, then we still need to generate code. This is stated in the MDA whitepaper [1]. The PSM contains platform information not present in the PIM. This platform information is captured in a Platform Description Model (PDM) probably also expressed in UML. So the initial goal could be summarized as follows:
(P IM, P DM ) → P SM → Code This means that from a PIM and a PDM, both expressed in UML, it should be possible to generate a synthesized PSM, also expressed in UML. The initial PIM was supposed to be developed by hand, from the observation of the contextual business and application requirements. Since the publication of the initial whitepaper, the OMG has been constantly updating, improving, and extending its very ambitious vision. There are many ideas in this proposal and this explains its high popularity. Some of these ideas have been implemented while others still stay at the level of open research problems:
•
The PIM to PSM translation problem, when both are expressed in UML (or pro les dialects of UML), has prompted the study of model transformation techniques. The natural way was to follow a declarative expression of rule-based declarative model-to-model (M2M) transformation programs. This gave birth to the QVT recommendation.
•
The integration of platform knowledge (coded as a PDM) into a PIM in order to get a PSM is still out of reach for several reasons. The rst one is that we do not have yet a su cient understanding of what is platform knowledge. The second reason is that even if we had, we
5
do not understand clearly how to compose a PIM with some platform knowledge encoded as a PDM. It seems that this is more complex than just M2M transformation.
•
The more mature part is the PSM to code that is achieved by so-called M2T (model-to-text) transformations. This achieves for example the generation of Java code from a PSM. Presently this represents a major part of practical applications claiming to follow an MDA approach.
Another important contribution to MDE was the MDA manifesto [6] written in 2004 by a group of authors from IBM. One central message in this contribution is about domain modeling. The strong idea that comes out of this manifesto is the need for DSLs (Domain-Speci c Languages). It is worth noting this important evolution since this was not very apparent in rst generation MDA projects.
Separating platform dependent from platform independent aspects was the rst
goal. Rapidly it appeared that these aspects were not the only ones to be dealt with in a software system. Using UML as a general purpose modeling language to describe at the same time business systems, functional requirements, quality of services, platforms, processes, etc. started to become problematic, even with the pro ling mechanisms. The idea of using dierent languages to describe dierent aspects of the system made its way quite rapidly, through DSLs. The abstract syntax of these DSLs could be easily implemented by MOF metamodels [7]. This gave much more impact to MDE approaches, since they could be much useful, for example within the context of a single stable platform. The M2M transformation was easy to adapt to exogenous transformations, i.e. the case when the source and the target models conform to dierent metamodels. Furthermore, the transformation language itself could be associated to another DSL, with a speci c metamodel. As a consequence, transformation programs could be considered as models which gave easy ways to deal with higher order transformation, producing or consuming other transformations. So we see how the search for a general solution to platform independence gave birth to a general
6
solution, capable to solve much wider problems. And this was only the rst period in the development of modern MDE practices.
2.2
Reverse engineering
Many of the OMG MDA recommendations like UML, MOF, QVT, etc. have been elaborated in the ADTF internal group (Analysis and Design Task Force). A new group named ADM (for Architecture Driven Modernization) soon started working on reverse engineering solutions.
Very naturally it
started using modeling techniques that had been found useful in forward engineering. Legacy systems are complex systems because they are voluminous (they have been developed over periods of 10, 20 years or sometimes more) and heterogeneous (they are composed of a lot of dierent technologies from pre-COBOL to post-Java). They need to be understood, modernized, and migrated. MDE provides powerful techniques to represent dierent facets of these legacy systems that will allow understanding, modernizing, and migrating them to new technologies. The rst solution is to use UML to extract models from legacy systems. For example UML use case diagrams, activity diagrams, state diagrams, class diagrams could be extracted from legacy systems as suggested in [8]. But sometimes one would like to extract more speci c models from a legacy system. This is why the ADM group has de ned several metamodels to this purpose, the most known being KDM and ASTM. The Knowledge Discovery Metamodel (KDM) standard, provides a comprehensive high-level view of the application behavior, structure, and data, but does not represent application models below the procedural level.
It corresponds to a coarse grain representation of a given legacy portfolio.
The Abstract Syntax Tree Metamodel (ASTM) deals with constructs within programming languages ( ne grain, syntactical), while the KDM models structural, behavioral and data information about
7
Real World
Modeling World Metamodel Metamodel Driven
System S
c2 (conforms To)
MMi
repOf (representation of)
Model Mi Discoverer Discovery
Figure 3: Metamodel-driven model discovery in MoDisco
application portfolios. The ASTM is expected to complement the KDM as an element of the ADM Roadmap to express fully detailed models of application artifacts. The approach taken in the MoDisco Eclipse project [9] is even more general because it assumes that you may use any kind of DSL (associated to a metamodel) to describe the facet you want to extract from a given legacy. For example if you want to extract models from a Java or COBOL program, from the Web, from a database, from a UNIX system, etc. you will use adapted metamodels. Furthermore MoDisco provides a toolbox that facilitates the building of model discovers from the de nition of the target metamodels Figure 3. It is interesting to note that the systems from which we are extracting models may be of dierent kinds.
It may be static or dynamic.
program.
An example of a static legacy system is the code of a Java
An example of a dynamic system is one execution of a Java program.
A trace of the
dynamic behavior of this program may produce a model, conforming to a given metamodel.
8
2.3
Models at Run time
One emerging area of application of MDE is related to complex systems. This is broader than software engineering and addresses the goals of systems engineering. Systems engineering may be de ned as an emerging discipline whose responsibility is creating and executing an interdisciplinary process to ensure that the customer and stakeholder's needs are satis ed in a high quality, trustworthy, cost e cient and schedule compliant manner throughout a system's entire life cycle. One of the main challenges of computer science is how to build, to maintain, to manage, and to monitor highly complex world-wide distributed systems made of many parts, continuously running, and constantly being maintained. These systems are sometimes called systems of systems. It seems that MDE, with its capability to capture several aspects of the same system, based on dierent DSLs, is one of the few possible ways to capture this complexity. In this view, a system will coexist with a set of models of it with the following properties:
•
Each model is constantly kept updated of the latest changes of the system.
•
Each model represents a particular aspect related to the dynamic behavior of the system, to its static architecture, to its evolution, to its maintenance data, to its health measured by some precise constraints, etc.
The cost of direct access to the system with the diversity of
the technologies used for its various components is much too high to allow direct monitoring and control operations. The idea is to provide some kind of uniform representation knowledge capturing the various facets of the system, from design data to maintenance and run time information.
There are several important projects currently investigating these possibilities. To name two of them, Microsoft DSI (Dynamic System Initiative) with its latter SML proposal [10] addresses self managing dynamic systems while the IBM Rainforest project aims to facilitate the deployment and con guration of complex J2EE applications in heterogeneous and constrained environments [11].
9
DSI is about building software that enables knowledge of an IT system to be created, modi ed, transferred, and operated on throughout the life cycle of that system.
Knowledge in this sense
includes knowledge of the designers' intent for those systems, knowledge of the environment in which the systems operate, knowledge of IT policies that govern those systems, and knowledge of the user experience associated with those systems. This knowledge is captured in software models using a variety of authoring and development tools. The Rainforest project employs model transformations, search, and planning techniques to handle con guration management of distributed applications and services in large, heterogeneous, and constrained environments. Systems at run time solutions aim to provide external MDE capabilities reminiscent of re ection in classical object-oriented programming languages with a completely dierent technology.
The
possibility of introspection is replaced by the capacity of systems to concretely access their models during their execution.
For example, during the execution of a given distributed system, in an
exception situation, this system could be allowed to access the design data corresponding to state diagrams. These capabilities obviously strongly require a complete and permanent synchronization and update of the various models to represent the latest version of the systems' components.
If
introspection is one of the important applications of these techniques, it is not clear if intercession based techniques could also be of interest here. With these new possibilities, any stakeholder could check the relevant information not by directly accessing the system itself, but by accessing the various updated models of the system. Furthermore classical model transformation techniques easily allow providing dierent views on the system. This nicely complements the fact that the system also accesses similar information. These techniques may have a high potential impact on the way new complex distributed systems are designed.
10
2.4
Problems
The previous sections have presented three MDE scenarios. In this section, we identify ve problems related to the implementation of these scenarios:
• Model-to-model Transformations.
A PSM is created by transforming a PIM and a PDM.
Reverse engineering roughly corresponds to the opposite operation of transforming a PSM into a PIM. Runtime models need to be analyzed (e.g., using policies) in order to act on the system. This may be considered as a transformation to a speci c diagnostic model. Transformation is therefore one of the most common operations on models.
• Heterogeneity.
Although MDE is about homogenizing all software artifacts as uniform models
(i.e., all de ned using the same metametamodel), concrete systems make use of a large number of dierent technologies (e.g., XML, Grammarware). It is thus necessary to be able to handle transformations between MDE and other technologies.
• Complexity.
Many modern software systems are large and complex, and are getting larger
and more complex. Although corresponding models are by de nition simpler than the systems they represent, model complexity is going to be an issue, if it is not already.
• Model discovery.
Building models from systems can be a relatively complex operation. It is
relatively easy to create large models that represent low-level aspects of a system (e.g., models of source code), but it is much more di cult to create high-level, meaningful, and understandable models. Model discovery is only useful if high-level models can be created from complex systems (statically in reverse engineering scenarios, or dynamically in models at runtime scenarios).
• System-model synchronization.
In order for a model to be useful for the purpose of man-
aging a running system, it must contain a correct representation of this system. Because a full
11
model cannot be discovered each time a small change occurs, model discovery for system-model synchronization has more requirements than model discovery for reverse engineering.
Note that this list of problems is by no means a complete list, and that future works will most likely extend it.
3
The MetaBoxed Modeling Toolbox
Section 2.4 has presented a list of problems for which MDE tools must provide solutions. The AMMA platform [12] has been providing solutions to many of these problems in the form of tools like KM3 [5], ATL [13], AMW [14], and TCS [15].
AMMA has evolved through the years from an initial
version supporting only ATL, to its current state of providing a collection of powerful tools. This history created some integration problems between the tools. Therefore, we are now introducing a more stable and robust modeling toolbox called MetaBoxed that leverages the experience we gained working on AMMA, as well as the tools that have been developed as part of it. Sections 3.1 through 3.4 describe the MetaBoxed platform, and Section 3.5 shows how it addresses the problems identi ed in the section 2.4.
3.1
Overview
Coming after sNets [16] and AMMA [12], MetaBoxed is a third-generation modeling toolbox.
It
crystallizes the ideas matured while working on its predecessors, and addresses their limitations. It is designed to broaden the MDE spectrum so as to fully cover forward and reverse engineering, as well as models at runtime problems. MetaBoxed provides high integration of its constituent tools into a coherent and understandable toolbox. It exhibits the following three main qualities:
12
• Robustness.
Model engineers need tools on which they can rely.
This not only implies
thorough testing, but also support for ne-grained error reporting.
• Portability.
One of the initial objectives of MDA is portability (i.e., PIM to PSM). However,
most current modeling tools fall in one of a couple of camps (e.g., C++ for GME, Java for EMF, .Net for Microsoft DSL Tools). MetaBoxed is designed from the beginning to be highly portable: most of it is bootstrapped, and only depends on a small kernel. This kernel has few external dependencies.
• Scalability and performance.
Even though MDE is not mainstream yet, there are already
relatively large models on which complex operations must be performed. A modern modeling toolbox must therefore scale to large models, and be able to operate on them e ciently.
The architecture of MetaBoxed is depicted on Figure 4, which shows its four main components:
• Kernel Modeling Framework (KMF).
MetaBoxed is based on KMF, which provides low-
level operations on models to upper layers: creating and deleting elements as well as setting and getting property values.
• Common Modeling Runtime (CMR).
CMR abstracts KMF operations into bytecodes.
This is similar to the way the Java Virtual Machine, and the .Net CLR work.
The main
dierence is that CMR deals with models, whereas the JVM and the CLR deal with objects. One of the main advantage of this approach is that operations on models may be de ned independently of the underlying platform running MetaBoxed.
• Projectors.
MetaBoxed provides bridges to other technologies (e.g., XML, Grammarware) in
the form of technical projectors.
• Global Model Management (GMM).
This upper layer is responsible for high-level model
13
Global Model Management Common Modeling Runtime
Projectors
Kernel Modeling Framework Figure 4: MetaBoxed core platform
handling (e.g., dependencies, versions). We are currently working on a prototype called AM3 (see [17]).
Detailed descriptions of KMF, CMR, and projectors are given in the following sections.
3.2
Kernel Modeling Framework
There are already several modeling framework like:
GME (in C++), Netbeans MDR (in Java),
Eclipse EMF (in Java), and Microsoft DSL Tools (on .Net).
KMF may seem like yet another
modeling framework, but it has speci c properties:
• No early mapping.
All modeling frameworks must map the modeling concepts they oer
to lower-level concepts (e.g., C structs, C++, Java, or .Net objects). Frameworks like MDR and EMF rely on a Java mapping, which concretely corresponds to the generation of Java code (source or bytecode) from metamodels. Metamodel code generation is mandatory with MDR, and optional with EMF (but required for advanced usage). With KMF, metamodel-code generation is deprecated (although still possible). There are three main reasons for this choice:
To increase portability.
Because there is no early mapping to object concepts and lan-
guages, it is possible to concretely map modeling concepts to what a given platform oers.
14
Also, while EMF oers the possibility to extend (and sometimes violate) its semantics with user Java code, KMF forbids this.
To speed up metamodel prototyping and deployment.
There is no need for syn-
chronization between metamodel speci cation and metamodel-code.
To make versions management easier.
There is only one artifact to track.
MetaBoxed is a proof that this property of no early mapping may be achieved with no signi cant performance penalty.
• Scalable and performant.
KMF can typically handle relatively large models containing
around ve million elements.
An example is a model of the whole Eclipse SDK 3.4 source
code conforming to a Java AST metamodel. Dealing with larger models will be possible using dynamic projectors (i.e., without loading whole models into memory). KMF is fast, and small: its memory footprint is around three times smaller than EMF's.
• Metametamodel agnostic.
KMF is structured in dierent layers (e.g., interfaces, imple-
mentation), and can therefore be used at dierent levels.
Client code depends only on the
interfaces. A default implementation based on the KM3 [5] metametamodel is provided. However, other implementations based on dierent metametamodels can be supported.
KMF is
therefore metametamodel agnostic (i.e., it may be used with dierent metametamodels). Figure 5 shows that, for instance, implementations based on MOF 1.4 (like MDR) or Ecore (like EMF) can be created.
3.3
Common Modeling Runtime
Several model transformation languages are available: ATL, QVT Relations, QVT Operational, etc. Several implementation platforms need to be supported (e.g., C++, Java, .Net).
15
At some level,
Kernel Model Framework
KM3
Ecore
DSLDM
…
Figure 5: KMF is metametamodel agnostic
all model transformation languages perform similar operations on models (e.g., create element, set property). Object technology has faced a similar problem that has been solved by using a Virtual Machine (VM) architecture: the Java VM supports Java, JRuby, Jython, Rhino (ECMAScript), etc., while the .Net CLR supports C#, C++ (managed), Visual Basic, J#, etc. The ATL VM [18] has been using a similar approach. The main dierence is that it is based on models, and operations on model elements instead of being based on objects. In MetaBoxed, CMR is an improved version of the ATL VM that has been renamed into CMR (Common Modeling Runtime) to insist on its independence with respect to ATL (i.e., other languages than ATL can be compiled to CMR). CMR supports execution, and bytecode-level as well as sourcelevel (i.e., transformation program) debugging independently of the actual transformation language. Any transformation language may be compiled into CMR bytecodes.
3.4
Projectors
A modeling framework uses an internal representation of models (e.g., an object graph representing the model element graph). It also needs means to load and save models from external representations (i.e., concrete syntaxes). For instance, MDR stores models in an ad-hoc repository or in XMI concrete syntax, and EMF stores resources (roughly equivalent to models) with speci c factories (mostly XMI).
16
With KMF, models are only abstract entities (i.e., not tied to physical representations). Concrete syntaxes of models are not in the scope of KMF. This is where the
projectors
brick comes into play:
it provides bridges between the internal representation of models and various concrete syntaxes. An
injector
is a tool that can transform a software artifact (e.g., a le) de ned using a speci c
technology (e.g., XML, Grammarware) into a corresponding model. opposite operation:
An
extractor
performs the
transforming a model into a corresponding software artifact de ned using a
speci c technology. The generic term
projector
is used to denote either an injector, an extractor, or
a bidirectional tool (i.e., that can both inject and extract). Any software artifact can be injected into a model, and any model can be extracted into a software artifact, provided the corresponding projectors are de ned. With a single brick in the MetaBoxed core platform (see Figure 4), we support: XMI projectors, textual projectors, and speci c binary projectors.
There are three core metamodel-independant
projectors:
• XML Metadata Interchange (XMI).
Interoperability with other modeling tools (e.g.,
EMF, MDR-based modelers) is supported via XMI: version 1.2 (NetBeans/MDR), 2.0 and 2.1 (Eclipse/EMF). But, only a small part of actual data and software artifacts are represented in XMI.
• Textual Concrete Syntax (TCS).
TCS [15] supports mappings between grammars and
metamodels. It provides injection and extraction capabilities from and to programs (i.e., strings conforming to context-free grammars).
• Binary Model Syntax (BMS). Boxed.
BMS is an open model binary format introduced in Meta-
Initial experiments show that BMS les are typically three times smaller than cor-
responding XMI les. BMS also enables ne-grained lazy loading and persistent indexes for e cient access (e.g., for transformations, and queries).
17
Other projectors may be built on top of KMF. For instance, a Java injector (based on the MoDisco [9] discoverer) takes an Eclipse workspace as input and produces a Java AST model as output. It supports:
external libraries, dierent JRE versions, and full Java type resolution (the type of a
variable refers to its class, and the type of an expression refers to its type declaration). We expect this projector layer to support upcoming challenges like: more con gurable projectors (à la TCS) for other concrete syntaxes (e.g., XML or binary formats), lazy injections, in nite models, etc.
3.5
MetaBoxed Solutions
The previous sections described the architecture of MetaBoxed in details. In this section, we explain how it addresses the ve problems listed in Section 2.4:
• Model-to-model Transformations
is handled by CMR, and the transformation languages
built on top of it (e.g., ATL, QVT Relations). Transformation problems are of dierent kinds (e.g., refactoring, language translation, re nement). Having a modular execution engine (based on a VM) enables MetaBoxed to oer several transformation languages across all the platforms on which CMR is ported:
there is no need to port the execution engine of each language.
Because language compilers typically also run on CMR, there is no need to port them as well.
• Heterogeneity.
The projectors oered by MetaBoxed make it possible to deal with models
that are stored in dierent concrete syntaxes. Additionally, having the projectors brick on top of KMF makes it extensible to support more kinds of projectors.
• Complexity
may be considered as dierent sub-problems: large models, multi-level models.
The scalability of MetaBoxed makes it especially appropriate to handle large models.
For
instance, it is capable of injecting a full model of the Eclipse SDK 3.4 source code (see Section
18
3.2) that may later be processed using code analyzing transformations. Ongoing experiments on AM3 (the prototype of GMM) show that it is possible to use multi-scale models (i.e., models of models of models) to represent complex multi-level systems. These results will be integrated in MetaBoxed.
• Model discoverers can be built by combining injectors, and transformations that analyze the injected models. We have already conducted such experiments (e.g., to compute metrics), which results are available on Eclipse.org. A related problem is to deal with composite transformations (i.e., consisting of several projectors and model transformations).
This problem is already
tackled by AM3, and GMM will inherit from this experience.
• System-model synchronization.
Typical injectors (e.g., parsers) are not suitable for system-
model synchronization. However, the architecture of MetaBoxed makes it possible to implement dynamic projectors, which may forward queries to or receive events from the actual system.
Although the current version of MetaBoxed is not complete yet, the initial results we obtained are promising. MetaBoxed is built on sound principles, and bene ts from the experience gained while working on its two predecessors (sNets, and AMMA). It will be further extended in the near future by several research works based on it.
4
Conclusions
Considering the rapid and important evolution of MDE described in Section 2, there was no chance that a technical support platform de ned several years ago could still be relevant for many use cases. The second part of the paper (Section 3) has outlined what such a generic platform could look like. This has been illustrated by the MetaBoxed proposal that we are currently building. There are still several necessary improvements, but we can see how such an MDE toolbox may ful l the
19
requirements of forward and reverse engineering as well as of models at runtime. MetaBoxed has the main facilities to deal with these three fundamental aspects of MDE.
5
Acknowledgements
This work has been supported by the ModelPlex European integrated project FP6-IP 034081 (Modeling Solutions for Complex Systems).
References [1] Soley, R., the OMG Sta Strategy Group: omg/2000-11-05. (2000). Available at
Model Driven Architecture, OMG Document
http://www.omg.org/cgi-bin/doc?omg/2000-11-05
[2] Bézivin, J., Barbero, M., Jouault, F.: On the Applicability Scope of Model Driven Engineering. In: 4th International Workshop on Model-based Methodologies for Pervasive and Embedded Software (MOMPES 2007) (2007) 37
[3] Bézivin, J.:
From Object Composition to Model Transformation with the MDA. In: TOOLS
'01: Proceedings of the 39th International Conference and Exhibition on Technology of ObjectOriented Languages and Systems (TOOLS39), Washington, DC, USA, IEEE Computer Society (2001) 350
[4] Bézivin, J.: On the Uni cation Power of Models. Software and System Modeling (SoSym)
4(2)
(2005) 171188
[5] Jouault, F., Bézivin, J.:
KM3: a DSL for Metamodel Speci cation.
In: Proceedings of 8th
IFIP International Conference on Formal Methods for Open Object-Based Distributed Systems, LNCS 4037, Bologna, Italy (2006) 171185
20
[6] Booch, G., Brown, A., Iyengar, S., Rumbaugh, J., Selic, B.:
An MDA Manifesto. In Frankel,
D.S., Parodi, J., eds.: The MDA Journal: Model Driven Architecture Straight from the Masters. Meghan Kier Press, Tampa, FL (2004)
[7] DSTC, IBM, ICL, Objectivity, Oracle, SSA, Unisys: Meta Object Facility (MOF) Speci cation, OMG Document ad/1997-08-14. (1997). Available at
http://www.omg.org/cgi-bin/doc?ad/
1997-08-14 [8] Soley, R., Oara, M.: Extracting UML from Legacy Applications. SOA World Magazine (2006) Available at
http://soa.sys-con.com/node/275129.
[9] Eclipse.org: The GMT MoDisco Web site. (2008). Available at
http://www.eclipse.org/gmt/
modisco/ [10] Microsoft:
Dynamic System Initiative. (2008).
Available at
http://www.microsoft.com/
windowsserversystem/dsi/default.mspx [11] IBM:
The
Rainforest
project.
(2008).
Available
at
http://www.research.ibm.com/
rainforest/index.html [12] Kurtev, I., Bézivin, J., Jouault, F., Valduriez, P.: Model-based DSL Frameworks. In: Companion to the 21st Annual ACM SIGPLAN Conference on Object-Oriented Programming, Systems, Languages, and Applications, OOPSLA 2006, October 22-26, 2006, Portland, OR, USA, ACM (2006) 602616
[13] Jouault, F., Allilaire, F., Bézivin, J., Kurtev, I.: of Computer Programming
72(3,
ATL: a Model Transformation Tool. Science
Special Issue on Second issue of experimental software and
toolkits (EST)) (2008) 3139
21
[14] Fabro, M.D.D., Bézivin, J., Jouault, F., Valduriez, P.: Applying Generic Model Management to Data Mapping. In: Proceedings of the Journées Bases de Données Avancées (BDA05). (2005)
[15] Jouault, F., Bézivin, J., Kurtev, I.:
TCS: a DSL for the Speci cation of Textual Concrete
Syntaxes in Model Engineering. In: GPCE'06: Proceedings of the fth international conference on Generative programming and Component Engineering, Portland, Oregon, USA. (2006) 249 254
[16] Bézivin, J.: sNets: A First Generation Model Engineering Platform. In Bruel, J.M., ed.: Lecture Notes in Computer Science, Volume 3844, Satellite Events at the MoDELS 2005 Conference, Montego Bay, Jamaica, Springer-Verlag (2006) 169181
[17] Barbero, M., Jouault, F., Bézivin, J.: plementing the Macroscope's vision.
Model Driven Management of Complex Systems: Im-
In: Proceedings of the 15th Annual IEEE International
Conference and Workshop on Engineering of Computer Based Systems (ECBS 2008), 31 March - 4 April 2008, Belfast, Northern Ireland, IEEE Computer Society (2008) 277286
[18] Jouault, F., Kurtev, I.: On the Architectural Alignment of ATL and QVT. In: Proceedings of the 2006 ACM Symposium on Applied Computing (SAC 06), Dijon, France, ACM Press (2006) 11881195
22
