Sobre las relaciones de poder

In amodel-baseddevelopment process, the models are used to bridge the gap between the real world, i.e. the requirements on the software system, and its final implementation. This allows explicitly

capturing and understanding the system and planning and structuring the implementation. Model-

driven development(MDD, or model-driven software development MDSD) goes a step further and uses models as primary artifacts in the development process. More specifically, the primary artifacts in a model-driven development process are

1. models which conform to metamodels and 2. explicit transformations between them.

The OMG specifies the Model Driven Architecture (MDA, [Miller and (Eds.)03]), a concrete

framework for the realization of model-driven development. The current working definition [OMGa] defines MDA according to [Obj04b]:

MDA is an OMG initiative that proposes to define a set of non-proprietary standards that will specify interoperable technologies with which to realize model-driven develop- ment with automated transformations. Not all of these technologies will directly concern the transformations involved in MDA.

MDA does not necessarily rely on the UML, but, as a specialized kind of MDD (Model Driven Development), MDA necessarily involves the use of model(s) in devel- opment, which entails that at least one modeling language must be used. Any modeling language used in MDA must be described in terms of the MOF language, to enable the metadata to be understood in a standard manner, which is a precondition for any ability to perform automated transformations.

Figure 3.3 shows the general idea of MDA: during the development process different models (conform to metamodels) are used, starting with abstract, platform-independent models (PIM) via

transformations to an arbitrary number of different platform-specific models (PSM) which are finally transformed into the final implementations.

A model transformation is “the production of a set of target models from a set of source models, according to a transformation definition” [Sottet et al.07a]. They are executed by atransformation engine. [Czarnecki and Helsen06] provides a classification of transformation languages. Important classes are graph-transformation based approaches and hybrid approaches.

Graph-transformation-based approachesspecify transformation rules in terms of typed, attributed labeled graphs [Rozenberg97]. A rule consists of a left-hand-side (LHS) and a right-hand-side (RHS). The LHS is matched in the source model and replaced by the corresponding RHS in place. The LHS consists of the matched pattern in terms of a graph, conditions, and some additional logic. Basically, the graph patterns can be expressed in the abstract or the concrete syntax of the source and the target

language. Examples for Graph-transformation-based approaches areAGG[Taentzer00, AGG],Atom3

[Vangheluwe et al.03, ATo], andVIATRA[Csertán et al.02, VIA].

The hybrid approaches combine several different paradigms, like declarative and imperative state- ments. Two important languages are classified by [Czarnecki and Helsen06] into this category: QVT

and ATL.QVT(Query/Views/Transformations, [Obj07a]) is a standard defined by the OMG support-

ing queries on models, views on metamodels, and transformations of models. It includes two declar- ative components on different abstraction levels,CoreandRelations, and a mapping between them (RelationsToCoreTransformation). Imperative logic is supported by the imperative componentOper- ational Mappingsand the componentBlack Boxwhich allows the integration of complex algorithms written in any other language. As QVT standard definition is currently finalized, first implementations are still under development, e.g. as part of theEclipse model-to-model transformation(M2M) project [Eclc]. A hybrid language with tool support is theAtlas Transformation Language(ATL, [Jouault and Kurtev05, AMM]). It also provides declarative and imperative statements and is relatively close to the QVT standard (see discussion in [Jouault and Kurtev06]). It has been integrated into the Eclipse M2M project as well. In particular, there is a library with ATL transformations at [ATLa]. More details on ATL can be found in section 7.

A transformation can be seen as a model as well. Thus, QVT has been defined in terms of MOF- compliant metamodels. As transformation languages and transformation engines are defined system- atically they provide additional useful properties (in contrast to e.g. proprietary code generators). Basic properties a transformation should fulfill are [Kleppe et al.03]:

1. Tunability, i.e. the possibility to adapt the transformation by parameters for the transformation. 2. Traceability, i.e. the possibility to trace one element in the target model back to its causing

element in the source model.

3. Incremental consistency, i.e. information added manually to the target model is protected and not overwritten if the transformation is executed again later (e.g. after the model has been updated).

Another property with low priority isbidirectionality, which means that the transformation can be applied not only from source to target but also backwards from target to source. However, this property is rarely applicable in practice and thus often ignored.

The OMG specifies various concepts for model-driven development, including XML Metadata

Interchange(XMI, [Obj07b]) an XML-based exchange format for any kind of MOF-based model, the

Object Constraint Language(OCL) [Obj06b], a formal language allowing the definition of constraints

and conditions in models, and theQVT language (Query/View/Transformation, [Obj07a]) which al-

MOF Model

UML Metamodel

IDL Metamodel

UML Models IDL Interfaces

M0 Layer M1 Layer

M2 Layer

M3 Layer

Figure 3.4: OMG Metadata Architecture according to [Obj05]

specifications base on the common meta-metamodel defined by the OMG, calledMeta Object Facil-

ity (MOF, [Obj06a]). All OMG modeling languages like UML and others (e.g. CWM [Obj03]) are

defined by a MOF-compliant metamodel. Traditionally the OMG illustrates the relationships between models, metamodels, and the MOF by the “four layer metadata architecture” shown in figure 3.4: Layer M3 contains the meta-metamodel MOF. Layer M2 contains the MOF-conformant metamodels defined by the OMG or third parties. Layer M1 contains the models which conform to the metamodels of M2. Finally, M0 contains the data of the real-world which is described by the models of M1.

In the past, the four-layer-architecture caused several problems and misunderstandings. In earlier versions the relationships between the model layers were called instantiation relationships, e.g. a class in an UML model was supposed to be an instantiation of the metaclass “Class”. This kind of instantiation has not been distinguished from object-oriented instantiation as defined e.g. within UML models. An object in a UML diagram would then be instance of multiple elements: On the one hand an instance of a class in the UML model and on the other hand an instance of the metaclass “Object” in the UML metamodel. Several publications, e.g. by Atkinson and Kühne [Atkinson and Kühne01, Atkinson and Kühne03], discuss such problems and show that they lead to inconsistencies, concluding that the basic definitions have to be improved, e.g. by introducing the conformance relationship as defined above. It is also important to understand, that layer M0 contains only the real-world objects at runtime. The objects in a model (e.g. in a UML object diagram) are only snapshots of them and part of the model and thus reside in layer M1. Moreover, as also mentioned in the latest MOF specification, the number of model layers is not necessarily restricted to four layers.

In general, Bézivin [Bézivin05] shows that modeling concepts have to be clearly distinguished from object-oriented concepts. Moreover, the more general paradigm of models can replace object- orientation. While the existing paradigm of object-orientation “Everything is an Object” failed to enclose all important concepts from software engineering, the new paradigm “Everything is a Model” seems to be general enough for this purpose. This is illustrated by fig. 3.5 showing the application of MDE concepts on differenttechnical spacesas described in [Kurtev et al.02, Kurtev et al.06]. As

an XML Docum ent XML Metaschem a

an RDF Docum ent UML Metam odel an XML Schem a

a Java Program an RDF Schem a Java Gram m ar a UML Model RDF Schem a MOF EBNF conformsTo conformsTo conformsTo conformsTo

conformsTo conformsTo conformsTo

conformsTo

conformsTo conformsTo

conformsTo conformsTo

Figure 3.5: Technical Spaces according to [Kurtev et al.06]

in practice often one single technology is insufficient, the concepts from MDE can be used to bridge between them [Kurtev et al.06]. Another important related technology are ontologies ([Bechhofer et al.04, Bodoff et al.05] which can be integrated into the MDE concepts as well [Gasevic et al.07, Obj07e].

The area ofModel Driven Engineering(MDE, see e.g. [Pla]) deals with the general concepts of MDD. The problems discussed in context of the MOF four layer metadata architecture show that the foundations of MDE requires further investigation and a more precise definition. Favre discusses the MDE theory ([Favre04b, Favre04a, Favre and Nguyen05]) and specifies them in terms of a model, the so-calledmegamodel[Favre04c] (see also e.g. [Bézivin et al.04]) where the extract in fig. 3.1 is taken from.