Transformación de modelos dirigida por atributos de calidad

UNIVERSIDAD POLITÉCNICA DE VALENCIA ESCUELA TÉCNICA SUPERIOR DE INFORMÁTICA APLICADA TÍTULO: Transformación de Modelos Dirigida por Atributos de Calidad Autor: Javier González Huerta Directores: Emilio Insfran Silvia Abrahão 2 Transformación de Modelos Dirigida por Atributos de Calidad © Javier González Huerta Valencia, Enero de 2009 3 4 En la preparación de este proyecto recibí ayuda y aliento de muchas personas. No tendría suficiente espacio para mencionarlos a todos. Hay una enorme lista de personas que me han brindado su apoyo y ayuda y de los cuales recibí importantes aportaciones. A todos ellos: GRACIAS 5 Abstract Model Transformations are one of the most important artifacts in the Model-Driven Software Development (MDSD) lifecycle. A model transformation is a process of converting one model to another model. A model may be transformed to multiple models that are functionally equivalent but very different with regard to their quality properties. Alternative models are generated since alternative transformations may appear during the transformation process. In the literature, several proposals try to integrate quality in model transformation processes. However, none of them provides a rigorous solution to tackle this problem. Thus, there is a needed to define transformation processes that are able of ensuring some desired properties in the target model. In this project, we define an architecture for quality-driven model transformations. The main goal of the architecture is to define a set of artifacts (mainly composed of model and metamodels) and a process which allows the definition and execution of model transformations in which the selection of alternative transformations are takenis done based on quality attributes. The rationale of this approach is to be able to automatically select the alternative transformation that an experienced software developer would select if the transformation process were manually applied. The architecture proposed in this final project is applied in a proof of concept where sequence diagrams from a requirements model is will be transformed into UML class diagrams. 6 Resumen Las transformaciones de modelos son uno de los recursos más importantes con los que cuenta el Desarrollo de Software Dirigido por modelos. Una transformación de modelos es el proceso por el cual un modelo puede convertirse en otro nuevo modelo. Un modelo puede ser transformado en varios modelos que, siendo funcionalmente equivalentes son diferentes en con respecto a sus atributos de calidad. Los distintos modelos se generan puesto que durante el proceso de transformación aparecen distintas alternativas, y en función de cuál sea la alternativa seleccionada en cada caso se generara un modelo distinto. En la literatura hay varias aproximaciones que intentan integrar la calidad en los procesos de transformación de modelos, pero ninguna de ellas ofrece una solución rigurosa para atajar este problema. Todo ello hace necesario la definición de procesos de transformación que sean capaces de asegurar que los modelos destino de dichas transformaciones tengan las propiedades deseadas. En este proyecto definimos una arquitectura para guiar las transformaciones de modelos basándonos en los atributos de calidad. El principal objetivo de esta arquitectura será la definición de los artefactos y procesos necesarios para poder diseñar transformaciones de modelos en los que las selección de transformaciones alternativas se lleva a cabo basándose en atributos de calidad. La base de esta propuesta es que automáticamente se puedan seleccionar las mismas transformaciones alternativas que un desarrollador experto seleccionaría si el proceso fuese llevado a cabo de forma manual. La arquitectura propuesta en este proyecto fin de carrera será aplicada a un caso de estudio donde se transformarán diagramas de secuencia, extraídos de la especificación de requerimientos de un sistema real en diagramas de clase UML, y podrá verse como seleccionando unos u otros atributos de calidad, el proceso de transformación cambia y los modelos generados tendrán efectivamente esos atributos de calidad. 7 Index 1. Introduction ........................................................................................................................ 11 1.1 Problem Statement ......................................................................................................... 11 1.2 The Approach .................................................................................................................. 12 1.3 Project Context ................................................................................................................ 12 1.4 Outline of the final project .............................................................................................. 13 2. Foundations ......................................................................................................................... 14 2.1 Introduction .................................................................................................................... 14 2.2 MDE ................................................................................................................................. 14 2.3 Model Dive Architecture (MDA) ...................................................................................... 15 2.4 Models in MDA ................................................................................................................ 15 2.5 Kind of models:................................................................................................................ 16 2.5.1 Computation Independent Model (CIM) ............................................................ 16 2.5.2 Platform Independent Model (PIM) .................................................................... 16 2.5.3 Platform Specific Model ...................................................................................... 16 2.5.4 Platform Model ................................................................................................... 16 2.6 Metamodels .................................................................................................................... 17 2.7 Meta-Object Facility (MOF) ............................................................................................. 17 8 2.8 Model Transformations ................................................................................................... 20 2.9 Model Transformation Taxonomy: ................................................................................. 21 2.9.1 Program Transformations and Model Transformations ..................................... 21 2.9.2 Number of source and target models: ................................................................ 21 2.9.3 Endogenous and exogenous transformations: ................................................... 22 2.9.4 Horizontal and vertical transformations: ............................................................ 22 2.9.5 Syntactical versus Semantical transformations: ................................................. 22 2.9.6 Mechanisms used for model transformations: ................................................... 22 2.9.7 Mechanisms used for model transformation...................................................... 23 2.10 QVT (Query/View/Transformation) ................................................................................ 24 2.10.1 QVT Two Level Declarative Architecture ............................................................. 24 2.10.2 QVT Relations ...................................................................................................... 25 2.10.3 QVT Core ............................................................................................................. 25 2.10.4 QVT Imperative Implementations ....................................................................... 25 2.10.5 Operational Mappings ......................................................................................... 25 2.10.6 The QVT Relations Language ............................................................................... 26 2.10.7 QVT Graphical Syntax .......................................................................................... 28 2.10.8 Implementations ................................................................................................. 31 2.11 Object Constraint Language (OCL) .................................................................................. 32 2.12 Technological Spaces ....................................................................................................... 32 2.12.1 Eclipse .................................................................................................................. 32 2.12.2 Eclipse Modeling Framework (EMF) .................................................................... 33 2.12.3 Medini QVT .......................................................................................................... 34 2.13 Conclusions ..................................................................................................................... 35 3. State-of-the-Art ................................................................................................................... 36 4. Quality-Driven Model Transformations .............................................................................. 40 4.1 Introduction .................................................................................................................... 40 9 4.2 Architecture Overview .................................................................................................... 41 4.3 Evolution of the architecture: ......................................................................................... 42 4.4 Model Definition: ............................................................................................................ 44 4.5 Strategy: .......................................................................................................................... 46 Step 1: Rule Analysis ............................................................................................................ 47 Step 2: Transformation ........................................................................................................ 49 4.6 Users of the transformation process .............................................................................. 51 4.7 Granularity of the transformation alternatives .............................................................. 51 5. Application to an Specific Domain ...................................................................................... 53 5.1 Introduction .................................................................................................................... 53 5.2 The requirements model ................................................................................................. 53 5.3 Requirements Metamodel .............................................................................................. 55 5.4 The UML Class Diagram Metamodel ............................................................................... 55 5.5 Defining transformations: ............................................................................................... 57 5.5.1 Non Alternative Transformations: ...................................................................... 57 5.5.2 Alternative Transformations: .............................................................................. 59 6. Proof of Concept ................................................................................................................. 68 6.1 Introduction .................................................................................................................... 68 6.2 Step 1: Rule Analysis ....................................................................................................... 70 6.3 Step 2: Model Transformation ........................................................................................ 73 6.4 Conclusions ..................................................................................................................... 74 7. Conclusions ......................................................................................................................... 75 7.1 Conclusions and Future Work ......................................................................................... 75 7.2 Results obtained .............................................................................................................. 76 Appendix A: Model Transformations .......................................................................................... 77 8. Bibliography ........................................................................................................................ 97 16 2.5 Kind of models: MDA standard (OMG, 2002)defines four kinds of models into the lifecycle of Model Driven Development: 2.5.1 Computation Independent Model (CIM) A computation independent model is a view of a system from the computation independent viewpoint, which it focuses on the environment and the requirements of the system; structural or processing details of the system are hidden or as yet undetermined. A CIM does not show details of the structure of systems. A CIM is sometimes called a domain model and a vocabulary that is familiar to the practitioners of the domain in question is used in its specification (OMG, 2002). Focuses on the Environment of the system and the requirements the user has on the system; the description provides what the system is expected to do. 2.5.2 Platform Independent Model (PIM) The platform independent model focuses on the operation of a system while hiding the details necessary for a particular platform. A PIM exhibits a specified degree of platform independence so as to be suitable for use with a number of different platforms of similar type. It is also a representation of business functionality and behavior, undistorted by technology details. It shows the part of the complete specification that does not change from one platform to another. The objective is to postpone in the development process the creation of models that take into account technological aspects of a platform as much as possible. The main advantage is to be able to react efficiently and with low costs to technology changes. 2.5.3 Platform Specific Model A Platform Specific Model Is a combination of a PIM with additional details of the system’s specific platform. 2.5.4 Platform Model Finally platform models are the representation of technical concepts of platform’s parts, the services provided by that platform, and for further use in PSM’s, concepts which models the use of the platform by the applications. 17 2.6 Metamodels At this level appears a doubt: how to ensure that the structure of a model is correct, how to make the assumptions explicit, automatically checkable etc?. When modeling is needed to model the structure and well formedness of rules of the language in which de models are expressed. Such models are called metamodel. A precise metamodel is a prerequisite for performing automated model Transformation and for defining accurate models. A metamodel is a specification model for which the system that describes is models in a certain modeling language. A metamodel says what can be expressed in a valid model of the modeling language. The interpretation of a metamodel is a mapping of elements of the metamodel to elements of the modeling language. The truth-value of statements in the metamodel can be determined for any model expressed in the modeling language. Since the metamodel is the models specification, a model in the modeling language is valid only if none of these statements are false. Since a metamodel is also a model, it will be expressed in some modeling language. A metamodel for a modeling language could use the same modeling language. The statements in the metamodel are expressed in the same language as is being described by the metamodel. This is called reflexive metamodel. 2.7 Meta-Object Facility (MOF) MOF is a standard proposed and defined by OMG (Object Management Group) for supporting MDA. This standard proposes four levels meta-modeling architecture with four metal-layers. Those metalayers are the metamodel of the constructs in the layers above. Each layer is described as follows: M3 meta-metamodel layer: In this layer resides the meta-metamodel, a language for defining level M2 metamodels. In OMG standard, MOF is the language defined in this layer. M2 Metamodel layer: M2 Metamodels are used for describing M1 Models. OMG’s UML Metamodel will describe UML constructs. M1 Model layer: At these level models is where we define models. A model is an instance of a M2 metamodel. I.e., if in M2 layer resides UML metamodel in M1 we could have one of its models: Class Diagram, Activity Diagram, Sequence Diagram and so on. M0 Instance layer: in this layer objects of the real world are defined. 18 Illustration 2: MOF layers architecture MOF is closed metamodeling architecture. This means that M3 level could be defined with instances of M3 elements. This implies that whit MOF we can define MOF. In addition MOF provides concepts to define a language: • Classes, which model MOF metaobjects. • DataTypes (property), which model needed descriptive data (i.e., primitive types). • Associations (property), which model binary relationships between metaobjects. • Packages, which modularize the models. OMG has defined two MOF variants: EMOF for Essential MOF. Is a subset of MOF constructs with the main purpose of providing a framework for mapping MOF models into implementation as JMI or XMI for simpler metamodels. CMOF for Complete MOF. The CMOF model is used for defining metamodels as UML2. Is built from EMOF metamodels and the UML Core:Constructs. M3 •Meta-Metamodel M2 •Meta-Metamodel M1 •Model M0 •Instances MOF UML Metamodel UML Models Objects 19 There are some differences between the UML metamodel to the MOF meta-metamodel which in which the nature of MOF can be observed: • MOF only supports binary associations while UML supports 'N-ary' associations. • MOF does not support UML AssociationClasses or qualified Associations. These constructs can be simulated in a MOF metamodel. • MOF supports the concept of a Reference which allows direct navigation from one Classifier to another. The UML metamodel uses the Target AssociationEnd's for the same purpose. • Some concepts such as Generalization, Dependency, and Association are reified as classes in UML, but implemented just as Associations in the MOF. (MOF does not require the richness of UML in these areas). 20 2.8 Model Transformations Model Transformation: is the process of converting one model to another model of the same system (OMG, 2002). One model may be transformed to several alternative models that can maintain the semantics but with different syntax. The mappings and relations are defined as specializations of transformations. Illustration 3: Model transformation definition A transformation definition consists of a collection of transformation rules which are unambiguous specifications of the way that (a part of) one model can be used to create a part of another model. The transformations are defined in terms of the metamodels involved in the transformation process. Transformation, transformation definition and transformation rule can now be defined. “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” (Kleppe, 2003) The most important characteristic of a transformation it is the fact that a model transformation should maintain the meaning between the source and the target model. At this point it must be said that the meaning of the model can only be preserved as it can be 21 expressed in both source and target model. Part of information should be lost if target language is less expressive than source language. A mapping is defined as a unidirectional transformation in contrast to a relation that defines a bi-directional transformation. 2.9 Model Transformation Taxonomy: When talking about abstract concepts another way to defining a clarifying terms is to introduce taxonomy as organizing things into groups of thing based on different criteria. 2.9.1 Program Transformations and Model Transformations Program transformation is a transformation where source and target artifacts are programs (Tom Mens). Model Transformation is a transformation where source and target artifacts are models. (Tom Mens). 2.9.2 Number of source and target models: A model transformation should be applicable to a multiple source models and/or multiple target models. (Tom Mens) Illustration 4: Different typologies of Multimodel Transformations Technical Space: A technical space is a model management framework containing tools, mechanisms, techniques and languages and formalisms associated to a particular technology. A technical space is determined by the metamodel that is used (M3 Level). For example W3C promotes the XML technical, which uses XML Schema as meta-metamodel (every model will be expressed in terms of this meta-metamodel) and OMG promotes MDA technical space with uses the MOF as meta-metamodel. 22 A transformation can work with models belonging to the same or different technical spaces, but in the latter case we need tools and/or techniques to define transformations in the board of both technical spaces. Those techniques can consist in translations from models in one technical space to the other or to have the entire metamodel of one technical space expressed in terms of the metamodel of the second technical space (Tom Mens). 2.9.3 Endogenous and exogenous transformations: Endogenous transformations are transformations between models expressed in the same language (Tom Mens). Exogenous Transformations are transformations between models expressed using different languages (Tom Mens). 2.9.4 Horizontal and vertical transformations: Horizontal transformation is a transformation where source and target models reside at the same abstraction level (Tom Mens). Vertical Transformation is a transformation between models that reside at different abstraction levels (Tom Mens). 2.9.5 Syntactical versus Semantical transformations: A syntactical transformation is a transformation that merely transforms the syntax (Tom Mens). A Semantical transformation is one that takes the semantics of the model into account (Tom Mens). 2.9.6 Mechanisms used for model transformations: The major distinction between transformation mechanisms is whether they rely on a declarative or an operational (or imperative) approach. Declarative approaches focus on what needs to be transformed into what by defining a relation between the source and target models. Operational approaches focus on the how the transformation itself needs to be performed by specifying the steps that are required to derive the target models from the source models. On One hand declarative approaches are interesting because some aspects are made implicit in the transformation language as navigation lf a source model, creation of target model and order of rule execution. As such, declarative transformations are easier to write and understand by transformation’s domain experts. Declarative approaches also offer services as:  Traceability in the transformation process: during and after the transformation there will be links between models and its parts. 23  Bidirectionality of transformations: A Language or tools that have the property of bidirectionality require fewer transformation rules, since each transformation can be used in two different directions. In Declarative approaches the bidirectionality is assured even when there aren’t explicit bidirectional declarations. On the other hand we have operational (or constructive) approaches that will be useful when Declarative approaches fail to guarantee their services or when the order of a set of transformation needs to be controlled explicitly. Operational approaches will deal with concepts as selections, iterations, sequences and so on (Tom Mens). 2.9.7 Mechanisms used for model transformation Mechanisms should be interpreted here in a broad sense. They include techniques, languages, methods, and so on. To specify and apply a transformation, ideas from any of the major programming paradigms can be used .One can borrow techniques from the procedural, objectoriented, functional or logic paradigms, or even use a hybrid approach combining any of the former ones. Nevertheless, it is important to note that a model transformation tool should be dedicated to the construction and modification of models. In this sense, a dedicated domain-specific programming language, preferably even restricted to the technical space of interest, is likely to be more effective than a full-fledged general-purpose programming language. The major distinction between transformation mechanisms is whether they rely on a declarative or an operational (or imperative) approach. Declarative approaches focus on the What aspect, i.e., they focus on what needs to be transformed into what by defining relations between source and target models. Operational approaches focus on the how aspect, i.e., they focus on how the transformation itself needs to be performed by specifying the steps that are required to derive the target models from the source models. Declarative approaches are attractive because particular services such as source model traversal traceability management and automatic bidirectionality can be made implicit in a transformation language: navigation of a source model, creation of target model an order of rule execution. As such, declarative transformations tend to be easier to write and understand by software engineers. Operational (or constructive 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 iterations. Such explicit control may be required to implement transformations that reconcile source and target models after they were both heavily manipulated outside the transformation tool. 24 2.10 QVT (Query/View/Transformation) QVT is a Model Transformation standard defined by the Object Management Group and related to the MOF architecture. The QVT specification (OMG, 2008) (OMG, 2008) (OMG, 2008) (OMG, 2008) has a hybrid declarative/imperative nature, with the declarative part being split into a two-level architecture. The two-level architecture of the declarative part forms the framework for the execution semantics of the imperative part. 2.10.1 QVT Two Level Declarative Architecture The declarative parts of this specification are structured into a two-layer architecture. The layers are: • A user-friendly Relations metamodel and language that supports complex object pattern matching and object template creation. Traces between model elements involved in a transformation are created implicitly. • A Core metamodel and language defined using minimal extensions to EMOF and OCL. All trace classes are explicitly defined as MOF models, and trace instance creation and deletion is defined in the same way as the creation and deletion of any other object. Illustration 5: Relationships between QVT Metamodels 25 2.10.2 QVT Relations The Relations language supports complex object pattern matching, and implicitly creates trace classes and their instances to record what occurred during a transformation execution. Relations can assert that other relations also hold between particular model elements matched by their patterns. The semantics of Relations are defined in a combination of English and first order predicate logic, as well as by a standard transformation for any Relations model to trace models and a Core model with equivalent semantics. It can be used purely as a formal semantics for Relations, or as a way of translating a Relations model to a Core model for execution on an engine implementing the Core semantics. 2.10.3 QVT Core The Core language is a small model/language that only supports pattern matching over a flat set of variables by evaluating conditions over those variables against a set of models. It treats all of the model elements of source, target, and trace models symmetrically. It is equally powerful to the Relations language, and because of its relative simplicity, its semantics can be defined more simply, although transformation descriptions described using the Core are therefore more verbose. In addition, the trace models must be explicitly defined, and are not deduced from the transformation description, as is the case with Relations. The core model may be implemented directly, or simply used as a reference for the semantics of Relations, which are mapped to the Core, using the transformation language itself. 2.10.4 QVT Imperative Implementations In addition to the declarative Relations and Core Languages that embody the same semantics at two different levels of abstraction, there are two mechanisms for invoking imperative implementations of transformations from Relations or Core: one standard language, Operational Mappings, as well as non-standard Black-box MOF Operation implementations. Each relation defines a class that will be instantiated to trace between model elements being transformed, and it has a one-to-one mapping to an Operation signature that the Operational Mapping or Black-box implements. This language is specified as a standard way of providing imperative implementations, which populate the same trace models as the Relations Language. It provides OCL extensions with side effects that allow a more procedural style, and a concrete syntax that looks familiar to imperative programmers. 2.10.5 Operational Mappings Operational Mappings Language can be used to implement one or more Relations from a Relations specification when it is difficult to provide a purely declarative specification of how a Relation is to be populated. Mappings Operations invoking other Mappings Operations always involves a Relation for the purposes of creating a trace between model elements, but this can be implicit, and an entire transformation can be written in this language in the imperative 32 2.11 Object Constraint Language (OCL) This section introduces the Object Constraint Language (OCL), as it was defined (OMG, 2003) (OMG, 2003) (OMG, 2003) is a formal language used to describe expressions on UML models. These expressions typically specify invariant conditions that must hold for the system being modeled or queries over objects described in a model. Note that when the OCL expressions are evaluated, they do not have side effects; i.e. their evaluation cannot alter the state of the corresponding executing system. OCL expressions can be used to specify operations / actions that, when executed, do alter the state of the system. UML modelers can use OCL to specify application-specific constraints in their models. UML modelers can also use OCL to specify queries on the UML model, which are completely programming language independent. OCL not only can be applied in UML models but also it can be applied into UML or MOF metamodels, since are expressed in UML or a subset of UML. Hereby OCL can be used to restrict metamodel semantics, for example by means of stereotypes or DSL’s. In MDA context, OCL can be used in three ways:  Precise modeling in MOF M1 level.  Definition of modeling languages.  Definition of transformations. 2.12 Technological Spaces 2.12.1 Eclipse Eclipse is an open source community, whose projects are focused on building an open development platform comprised of extensible frameworks, tools and runtimes for building, deploying and managing software across the lifecycle. Its most relevant project is The Eclipse Platform. As defined at (Eclipse.org, 2003)The Eclipse platform is designed for building integrated development environments (IDEs) that can be used to create applications as diverse as web sites, embedded Java(TM) programs, C++ programs, and Enterprise JavaBeans (TM). The Eclipse Platform is built on a mechanism for discovering, integrating, and running modules called plug-ins. A tool provider writes a tool as a separate plug-in that operates on files in the workspace and surfaces its tool-specific UI in the workbench. When the Platform is launched, the user is presented with an integrated development environment (IDE) composed of the set of available plug-ins. The Eclipse Platform's principal role is to provide tool providers with mechanisms to use, and rules to follow, that lead to seamlessly-integrated tools. These mechanisms are exposed via 33 well-defined API interfaces, classes, and methods. The Platform also provides useful building blocks and frameworks that facilitate developing new tools. This modularity is an advantage against other monolithic IDE’s where no extra functionalities can be added. Eclipse is an Open, Flexible and general purpose IDE. For this work we have special interest in Eclipse Modeling Framework (EMF), a subproject of Eclipse. EMF is a framework that allows defining and working with models and is capable of generating code from a model specification. 2.12.2 Eclipse Modeling Framework (EMF) EMF is a modeling framework and code generation facility for building tools and other applications based on a structured data model. From a model specification described in XMI, EMF provides tools and runtime support to produce a set of Java classes for the model, a set of adapter classes that enable viewing and command-based editing of the model, and a basic editor. Models can be specified using annotated Java, XML documents, or modeling tools like Rational Rose, then imported into EMF. Most important of all, EMF provides the foundation for interoperability with other EMF-based tools and applications. EMF started with the Meta Object Facility standard of OMG, and was progressed within the Java Community Process to produce the Java Metadata Interface standard. It is a Java framework and code generation facility for building tools and other applications based on a structured model. EMF provides a mechanism to easily create, save, and restore instances of the classes in your model. This makes it very easy to share data across different applications (Maddeh Mohamed, 2007). The metamodel based on MOF Core is called Ecore, illustration 7 shows the main components of Ecore. 34 1 Illustration 7: Ecore Components In the MOF 2.0 proposal the Essential MOD (EMOF), a similar subset of MOF model have been segregated. There are some differences between EMOF and Ecore, mainly at the names of the entities; however EMF Ecore is capable to read and write EMOF. 2.12.3 Medini QVT Medini QVT is a QVT transformation engine wich implements the OMG’s QVT relations specification in a powerful QVT engine. This standard is designed for model-to-model transformations to allow fast development, maintenance and customization of process specific transformation rules. Highlights among the supported features are:  Execution of QVT transformations shown the textual concrete syntax of the relations language.  Editor with code assistant.  Integrated debugging which allows to run the relations step by step.  Trace management enabling incremental updates during transformations.  Key concept enabling incremental updates as well as the transition from manual modeling to automatic transformations.  Bidirectional transformations.  Multimodel transformations, multiple source or/and target models. 1 Figure from The Eclipse Foundation, 2009 35 There are two ways of working with Medini QVT a standalone version, an Eclipse-like standalone executable or a Eclipse Plug-in. In the standalone version EMF editors and the transformation engine are available for defining transformations, designing models and metamodels. The Eclipse Plug-in integrates QVT relations Engine in the Eclipse IDE. Once the plug-in has been activated the QVT transformations are available as another Eclipse functionality. The selection of Mediny QVT against other transformation engines for this project is based on:  Multimodel transformations support.  Complaint with OMG’s QVT Relations standard.  Bidirectional transformations.  Eclipse Integration.  EMF compatible. 2.13 Conclusions In this chapter we have introduced key concepts to understand the conceptual framework of this project. We have briefly described the paradigms involving this work and the technological spaces we’d used to support it. Model Driven Software Development is a software engineering approach that promotes the use of models and model transformations as primary artifacts, rising up the abstraction level. This allows improving aspects as interoperability, reusability, maintainability and team productivity. Our work will adopt MDA architecture, the DSDM approach proposed by OMG. This approach comprises the use of models in all the steps of a software development project, until the delivery of the software on a given platform. A MDA development process basically transforms a platform-independent model (PIM) into one or more platform-specific models (PSM), which are transformed into code (code model – CM). The CM is just the actual code generated from PSMs through transformation. Those models are defined well defined with metamodeling techniques and are transformed automatically. The mechanisms introduced by OMG to solve those issues are MOF, UML, QVT, OCL etc. Focusing on the technological space, this proposal will be based in Eclipse developing. We will use Eclipse Modeling Framework to deploy metamodeling techniques and model definition and the transformation will be defined using QVT relations and the Medini™ QVT Engine. 36 3. State-of-the-Art In this chapter we describe the related works dealing with quality of model transformations focusing our attention in approaches trying to guide or drive those transformations based on quality attributes. In the last few years, some proposals that deal with the quality of model transformations from the perspective of a quality attribute have been proposed. An organized chronological summary of these studies is presented in Table 1. Zou and Kontogiannis (2003) proposed a quality-driven reengineering framework for objectoriented migration. Analysis tools, transformation rules, and non-functional requirements for the target migration systems characterize this framework. During the migration process, the source-code transformation rules are associated with quality features of the target system (i.e., coupling and cohesion). This approach was applied to transform a set of GNU AVL libraries into an UML class diagram. 37 Table 2 Comparison approaches for quality in model-driven development Röttger and Zschaler (2004) proposed an approach for refining non-functional requirements based on the definition of context models and their transformations. This approach has been defined in a software development process that separates the roles of the measurement designer and the application designer. It is the measurement designer’s responsibility to specify measurements, context models and transformations among these models. Then, the application designer can apply the transformations when developing a system. Röttger and Zschaler defined a XML-based language for the specification of transformations between abstract and concrete context models. The transformations used the response time quality attribute Merilinna (2005) proposed a tool for quality-driven model transformations for software architectures. Two types of quality attributes are considered: attributes related to software execution (e.g., performance, availability, reliability) and attributes related to software evolution (e.g., maintenance, modifiability, reusability). The transformations are described according to MDA and a proprietary transformation rule language. The approach only considers horizontal transformations (PIM-to-PIM transformations). 38 Kurtev (2005) proposed a formal technique for the definition of transformation spaces that support the analysis of alternative transformations for a given source model. This technique provides operations for the selection and reduction of transformation spaces based on certain desirable quality properties of the resulting target model. Specifically, this approach deals with the adaptability of model transformations. To generate the transformation space, the process takes a source model and its metamodel, the target metamodel, and the quality properties as input. The proposal has been applied to a set of transformations to obtain XML schemas from UML class diagrams. Markovic and Baar (2005) defined a set of transformation rules for the refactoring of UML class diagrams. The rules have been defined using the Query/View/Transformation (QVT) standard of OMG (OMG, 2005). The refactoring is applied to UML class diagrams containing annotated OCL constraints that are preserved when the transformations are applied. Therefore, the syntactical correctness of the target model is preserved. Similar to this proposal, Ivkovic and Kontogiannis (2006) presented an approach for the refactoring of software architectures using model transformations and semantic annotations. In this approach, the architectural view of a software system is represented as a UML profile with its corresponding stereotypes. Then, the instantiated architectural models are annotated using elements of the refactoring context, including soft goals, metrics, and constraints. Finally, the actions that are most advisable for a refactoring context are applied after being selected from a set of possible refactorings. The proposal has been applied to a case study to demonstrate that the refactoring transformations improve the maintenance, performance and the security of a software system. Sottet et al. (2006) proposed an approach for model-driven mappings for embedding the description and control of usability. A mapping describes a model transformation that preserves properties. The mapping properties provide the designer with a means for both selecting the most appropriate transformation and previewing the resulting design. A case study that illustrates an application of the mapping metamodel using usability criteria compatibility, error protection, and homogeneity-consistency) was presented. Kerhervé et al. (2006) proposed a general framework for quality-driven delivery of distributed multimedia systems. The framework focuses on Quality of Services (QoS) information modeling and transformations. The transformations between models express the relationships among the concepts of the different quality information models. These relationships are defined in quality dimensions and are used to transform instances of a source model to a target model. Different types of transformations are applied to different layers and services: vertical transformations are applied to transform information between the different layers (user, service, system, and resource), and horizontal transformation are applied to interchange information between services of the same layer. In summary, some proposals focus on defining horizontal transformations for model refactoring (Merilinna 2005) (Markovic & Baar 2005) (Ivkovic & Kontogiannis 2006). Other proposals are aimed at providing vertical transformations for model refinement (Rottger & Zschaler, 2004), synthesis 39 (Kerhervé et al., 2006) (Kurtev, 2005), or reverse engineering (Zou &Kontogiannis, 2003). Of these studies, only the one by Kurtev (2005) presents a more systematic approach for selecting alternative transformations according to a given quality attribute. All these approaches propose quality criteria that can be used to drive the transformations, but very few of these approaches (Kurtev, 2005) (Markovic & Baar, 2005) illustrate them by means of practical examples. With the exception of Markovic and Baar (2005) and Kurtev (2005), the transformations are poorly defined. Therefore, more systematic approaches to ensure quality in MDA processes are needed. Another weakness of these proposals is that they are not empirically validated. The practical applicability of model transformations is reported based on the intuition of the researcher. As pointed out by Czarnecki and Helsen (2006), there is a lack of controlled experiments to fully validate the observations made by the researchers. Finally, Abrahão et al. (2008) had proposed an approach to drive the model transformations based on quality attributes. This approach have been empirically validated in an specific set of transformation rules in order to obtain UML Class diagrams starting from a requirements model. The main objective of the experiments were obtaining empirical evidence about the appropriate rule selection and how this selection can improve the understandability of the obtained UML Class Diagrams. The transformation rules where defined using MOMENT platform. In this work, the authors present a generic architecture for quality-driven model transformations. Using a controlled experiment empirically validates that alternative transformations can affect to the quality of the output artifacts and uses the information gathered during these controlled experiments as additional inputs of the transformation process. This information will feed the transformation process with the criteria to choose the alternative transformation that maximize the selected quality attribute. Although the approach could evaluate more than one quality attribute the experiments were performed evaluating the understandability of UML Class diagrams. Since the architecture proposed was theoretically defined but no infrastructure was developed, the transformations were performed by a transformation engine but no additional models were added to hold the additional quality information and the feedback to the process. 40 4. Quality-Driven Model Transformations This Chapter presents an architecture for quality model transformations capable of hold and express transformations between source and target models in which the choice between alternative transformations is made based on quality attributes. In this section we will define the artifacts need to express the extra information required to assure the quality guidance of the transformation process. Moreover the transformation process has been decomposed to allow users and domain experts to interact with the proposed transformation architecture. 4.1 Introduction In MDSD software development process models are transformed to other models to finally achieve a set of models containing enough details to implement the system. A model may be transformed to multiple models that are functionally equivalent but very different with regard to their quality properties. The selection of a particular model should then be determined based on quality requirements of the output model. The transformation is executed based on a transformation definition as seen in section 2. Transformation definition contains transformation rules that relate constructs in the source model to the constructs in the target model. Alternative transformations will appear every time a single (or complex) construct in the source model could be transformed into multiple alternative constructs in the target model. The source and target models are at level M1 according to the MOF terminology and their source and target metamodels are defined in the level M2. The transformation is defined at M2 level and executed at M1 level. The source model MA is an instance of the source meta-model MMA. Assume that MA contains three elements a1, a2, and a3 shown as rectangles with relations among them. MA has to be transformed to a model that is an instance of the target meta-model MMB. The two meta-models can be used to determine the possible transformations rules. MMA contains two constructs: A1 and A2. MMB contains four constructs: B1, B2, B3, and B4. 41 Illustration 8 Alternative transformations for a given source model Generally for a given construct or set of constructs in the source metamodel there are multiple constructs in the target model to which can be mapped. Assume that the construct A1 in the source meta-model can be alternatively mapped to the three constructs B1, B2, and B3 in the target meta-model. This introduces alternative mappings for each instance of A1 in the source model MA. lustration 8 shows one possible mapping in which a1 is mapped to an instance of B2 and a2 is also mapped to an instance of B2. Other combinations are generally possible and this results in multiple target models. Those alternative target models are functionally equivalent but can be very different with regard to their quality properties. For a concrete problem the software engineer must be able to identify the transformations that lead to a model with the desired quality properties. This chapter will define a an architecture which will help Domain Experts, starting with alternative transformations, to associate them based with specific quality attributes of the resulting models and to define priorities of those quality attributes on a given Domain. The transformation user will be then able to select the quality attributes to be maximized on the resulting model and executing the transformation to get a model with the selected quality attributes. 4.2 Architecture Overview In this section we will describe the main components of the architecture and the global process. The domain expert chooses which quality attribute would maximize. He makes the selection based in his experience or previous empirical studies. The quality attributes selection drives the selection of alternative transformations. A quality attribute is a measurable physical or abstract property of an entity (e.g., conceptual model) [ (SQuaRE, 2005) The whole process have been divided in two phases: i) rule analysis, and ii) transformations phase. Each one has a model transformation process. 48 and we put the alternatives as leaf nodes. This decomposition allows decision makers to better understand every part of a complex problem. The second step is to build the pair-wise comparisons matrix. For each quality attribute, the stakeholders provide the preferences on the alternatives comparing pairs of alternatives giving a weight in the AHP scale Table 3. This comparison is used to determine how important an A alternative, over a B alternative for a given quality attribute. We put the results in a comparison matrix and then we normalize. The score for each alternative is given by the average of each row in the normalized comparison matrix. A consistency check can be done to detect possible inconsistencies in the values. 49 Table 3 AHP weighting scale If A is … as (than) B Quantitative Weight equally important 1 equality to moderate preferred 2 moderately more important 3 moderately to strong preferred 4 strongly more important 5 strongly to very strongly preferred 6 very strongly more important 7 very strongly to extremely preferred 8 extremely more important 9 The process done in the step 2 is repetead to elicit the importance for each quality attribute. The result es a comparation matrix with the relative importance of each quality attribute to the stakeholder. Automatic Rule Transformations At this stage we take as input two models: the quality model, and the transformation model. The quality model is composed by a hierarchy with three levels: characteristics, subcharacteristics and attributes. The transformation model contains for each artifact: the possible alternatives rules and the quality attributes to maximize for it. Based on the information extracted from the trade-off analysis, we include for each rule the relative weight for a given attribute, and the relative weight for each quality attributes. These models are used to obtain an active rules set to apply. In order to obtain these rules, we apply a QVT transformation which chose the best rule for each artifact. Step 2: Transformation The second step is the original model transformation in the sense that takes the source model as input (and the active rules set) and converts it to the target model. In this step when a 50 structural pattern with alternative transformations is found in the source model the rules associated to this structural pattern in the active rules set will be applied. The behavior on the second phase will be distinct if the set of constructs of the source model has or not alternative transformations. If the structural pattern have no alternative transformations the rule will perform the transformation with no references to the active rules set, these transformations are performed deterministically in the sense that are performed every time the estructural pattern is found in the source model (a source math has been found). On the other hand we have the estructural patterns that had alternative transformations. When one estructural patterns is found on the source model only the rules that match with the active rules set for this pattern will be fired. The transformation rule for these artifacts will be decomposed into two kinds of rules. The first will be auto-fired rule and the second will be a set of rules called from the first. The auto-fired rule has two left sides, a left side for the source model domain in which the structural pattern of the source model is defined, and a left side for the active rules domain. The second left side domain checks that the artifact with the given name will be transformed by means of rules that will be called from this rule. I.E: Let’s suppose we have a rule transforming Source “A1” into Target “B1”. And lets suppose that “A1” can also be transformed into “B2”. We will define in the transformation model two rules A1ToB1 and A1ToB2 and also we define the artifact A1 with two alternatives called A1B1 and A1B2. The A1B1 alternative is associated to the rule A1ToB1 and the A1B2 alternative is associated to the rule A1ToB2. When we execute the first step of the transformation rule we will have an active rule set containing the artifact “A1” with the rule A1ToB1 or the rule A1ToB2 but never both (those rules never will appear simultaneously in the active rule set).The definition of rule A1ToB1 will be formed by the domain that searches the “A1” in the source model and by a domain that searches for the name “A1ToB1” in the active rule set. There will be another domain for “B1” . Illustration 13: different alternative transformations 51 When a auto-fired rule has been fired having found a source match, then will call to the rules which will perform the transformation. The auto-fired rule will call to the entire set of rules associated to the structural pattern in the active-rules set. The set of rules forming the different alternatives should cover the same portion of the input model. This concept is asociated to the completeness of the transformation. If one alterative cover less portion of the source model than the others when this alternative is selected a portion of the source model will not have correspondance in the target model. 4.6 Users of the transformation process This architecture has three kinds of users or actors, the MDA User, The MDA Expert and the Domain Expert. The Domain Expert will define the quality attributes that will be applicable for the domain, and will assign weights to each attribute. Those weights will be used in a trade off process which populates the weights for the associations between quality attributes and the different alternative transformations. The User of the transformation typically will select the quality attributes in the quality model and will start the second phase of the transformation with a given source model. The MDA Expert will define the transformations, identifying the structural patterns of the source model and its equivalents in the target model. He also builds the transformation model, identifying alternative transformations for a given structural pattern. MDA Expert maintains the different artifacts and takes care of the result of the whole process. Finally the domain expert will evaluate the whole process. This evaluation can be made applying different metrics to the output models. He can measure different quality attributes over the target model and make comparisons with the expected values. Those metrics may differ of the expected values. In this case the Domain Expert should review the association weights for alternatives and quality attributes. If those weights are incorrect the decision of what alternative should be also incorrect and perhaps this quality attributes aren’t present in the output model. The process of correcting the weights for a given association between quality attributes and alternative transformations can be seen as a feedback for correcting the deviation between real metrics and expected values for those metrics. The decision of what metrics should be applied for measuring a given quality attributes on a given model is taken by a MDA-Quality Expert, which may (or not) be the same than MDAExpert. 4.7 Granularity of the transformation alternatives At the architecture definition we had modeled the quality guidance defining a set of alternatives for transforming a set of constructs of the source model into constructs into the target model. Also we had considered the fact that the different alternatives must cover the same portion of the input model. In case of alternative transformations, this can be performed 52 by one or more rules (an alternative has a set of rules). This relaxes the restriction mentioned above, about the source model coverage. But at this point we can see another issue, which is the granularity between estructural patterns. We define Granularity of a transformation as the size of the source model portion covered by the left side of the rule. A rule has high granularity if covers a wide structural pattern in the source model and another has low granularity if it covers a little number of constructs in the source model. The left side of a rule also includes a checking for assuring that this artifact is not contained by a bigger artifact. The transformation model allows a given structural pattern been transformed by means of a set of rules. If a domain expert had defined that a big artifact should be transformed by means of a rule set and this alternative have been selected then this transformation should be applied as far as possible. It is possible for the domain expert to define big patterns been transformed into a complex pattern in the target model or into a wide set of simpler patterns, based on quality improvement of different attributes. If a given structural pattern in the source model is included into a bigger structural pattern the source match must be done with the biggest artifact. Once the MDA expert had defined a big structural pattern this must be taken into account as first priority (we make the supposition that a Domain Expert define high granularity patterns with the evidence or expecting that those transformations will improve the quality of the output model). 53 5. Application to an Specific Domain This chapter shows how the architecture is applied to a specific domain: transformations between Requirements Model Sequence Diagrams to UML Class diagrams. The source and target models are presented and the different alternative transformations are defined. 5.1 Introduction In this work we have chosen the transformations from Requirements model to UML Class Diagrams which is the same used in (Abrahão, 2008). We base our decision in two reasons, first is that both source and target domains are well known and the examples can be easy to understand and the traceability in the transformation process is easy to read and the second is that using the same specific domain than the work that described the problem will allow us to test our proposal and at the end we will be able to generalize our results. 5.2 The requirements model The requirements model (Insfran, 2003) (E. Insfran, 2002) defines the structures and the process followed to capture the software requirements. It is composed of a Functions Refinement Tree (FRT) to specify the hierarchical decomposition of the system, a Use Case Model to specify the system communication and functionality, and Sequence Diagrams to specify the required object-interactions that are necessary to realize each Use Case. Consequently, as only functional software requirements are gathered (business requirements are excluded), the Requirements Model can be placed at the PIM level. The Requirements Model is supported by a Requirements Engineering Tool2 (RETO). Following a MDA strategy of model transformation, once the Requirements Model has been specified, a conceptual model including a UML class diagram can be obtained by applying a set of transformation rules from a Transformation Rules Catalog3 (Insfran, 2003). These transformations establish traceability relationships between the Requirements Model and the UML class diagrams. 2 RETO web site: http://reto.dsic.upv.es 3 The Transformation Rules Catalog can be found in http://www.dsic.upv.es/~einsfran/thesis 54 According to the MOF terminology, the Requirements Model and the UML class diagram are located in the M1 level and their metamodels are located in the M2 level. The definition of a transformation is performed at the M2 level and implies that “a certain structural pattern is identified in the source model (Requirements model), which corresponds to a valid structure in the target model (UML class diagram)”. Illustration 14 Traceability from Requirements to Conceptual Models The figure above shows simplified traceability relationship map to go from the set of specified requirements to specific elements in the conceptual schema. These traceability relationships may be simple (one-to-one relationships). Traceability relationships can also be many-to-many relationships. This is due to the variability of the transformations, which allows multiple possible representations in the UML Class diagram that satisfy a given requirement pattern identified in the Requirements Model. When this occurs, this pattern will be represented by an artifact instance, and all the possible representations will be represented as alternatives with the related rules which will be applicable when the pattern is detected in the source model. Finally, single alternative mapping will be selected, based on the rules associated to the pattern on the Active Rules Set. 55 5.3 Requirements Metamodel The Illustration 15shows an excerpt of the relevant parts of the Requirements Metamodel used as source in the transformation process. The Use Case class represents the functions of the system. Each Use Case will be specified in detail by means of one or more sequence diagrams. A Sequence Diagram is formed by Entities (Actor, Interfaces or classes) and Messages. The Actor represents de user of the system; Interface represents the system boundary; Class represents the different entity classes that participle in the realization of the Use Case. In order to characterize the interaction between objects, we identify four types of messages: Signal, Service, Query, and Connect. Signal Messages represent the interaction between actors and the interface. Service messages represent object interactions with the purpose of modifying the system (creation, deletion or update). Query messages represent object interactions to query the state of an object or a set of objects. Connect messages represent object interactions to establish a relationship between them. Illustration 15 Requirements Metamodel 5.4 The UML Class Diagram Metamodel Once the source metamodel is defined, the UML target metamodel (OMG, 2006) must also be defined. At least three alternatives are possible:  To use the UML2 metamodel directly. This has the advantage that the result can be used by all the tools that use this metamodel. However, the problem is the size of the metamodel and its complexity. The use of the UML2 metamodel makes transformation rules difficult to specify and understand.  To use the Ecore metamodel. This has the advantage that many tools directly use this metamodel, and it is also very well integrated in the Eclipse environment (www.eclipse.org). However, we could not represent two of the three types of 56 relationships (association class and aggregation) that we needed to generate in this metamodel.  To use the class diagram metamodel defined in the MOF QVT Final Adopted Specification (OMG, 2005). This metamodel is well known, simple, and it has the advantage that it can specify almost all the characteristics that are needed. Finally, we decided to use a modified version of the class diagram of the MOF QVT specification, which we refer to as UMLite. Illustration 16shows the modified UMLite metamodel. The main part of the metamodel is the same as the metamodel defined in the QVT specification (OMG, 2008) A Package is formed by a set of PackageElements. Usually, an information system is formed by a set of Packages. A PackageElement can be a Classifier or a Relationship. Classifier is the generic name given to everything that can have attributes and operations. PrimitiveDataTypes and Classes are both Classifiers. The class PrimitiveDataType defines the Abstract Data Types used in the definition of a system. Typical PrimitiveDataTypes are integers, doubles, strings, and so on. Instances of the Class class will belong to a specific Package. A Class is formed by a set of Attributes. Each one of the Attributes has a name inherited from UMLModelElement (in fact, everything has a name because every class inherits from the UMLModelElement class) and its type must be a Classifier that was previously defined. The IS-A relationship between classes is maintained with the reflexive association relationship defined in the Class class. The Relationship class defines the relationships that can exist between two classes (the source and the destination classes). In order to be able to define the characteristics of relationships between classes, two modifications have been added to the metamodel:  An attribute named kind in the Relationship class to express the kind of relationship between two classes (association, aggregation, or composition).  A new relationship between the Relationship and Class classes to express that a relationship has an association class. 57 Illustration 16 The UMLite Metamodel Even though there are no tools that use UMLite as their metamodel, it is still useful. Since the main concepts of UMLite are almost the same as the concepts in Ecore and UML2, they can be easily transformed to these metamodels. 5.5 Defining transformations: 5.5.1 Non Alternative Transformations: The generation of classes for the UML class diagram is a process that is based on the analysis of participating actors and classes in all the Sequence Diagrams. It includes the application of the following Transformation Rules (TR), stated here in natural language:  TR 1. For every distinct actor class participating in any Sequence Diagram, a class will be generated in the UML class diagram.  TR 2. For every distinct class participating in any Sequence Diagram, a class will be generated in the UML class diagram.  TR 3. The boundary classes (usually called Interface or System) in Sequence Diagrams will not have an explicit representation in the UML class diagram. Those transformations are fired with no alternatives. For example the Rule 2 (TR2.) will be applied deterministically for every distinct class on the source model, and will transform this class into a UML class when the sequence diagram containing the class have been previously transformed. This transformation rules will not be present in the transformation model nor in the active rules set. The non-alternative transformation are applied every time the structural pattern is found in the source model and without performing validations against the active rules set. 64 When Where ServiceNew reqs:useCase AEntity: ClassSD name= nameAEntity BEntity: ClassSD name= nameBEntity <<domain>> a:Artifacts Name= “ServiceNew” <<domain>> uml:Package AClass: Class BClass: Class <<domain>> rules:Rules UseCaseToPackage(reqs, uml); EntityToClass (AEntity,A_Class); EntityToClass (BEntity,B_Class); not(ServiceNewCheckForAssociationClassMessages(AEntity,BEntity)) if (a.rules->select(r|r.Id='TR14').size()=1) then ServiceNewToAssociation(m,rel) else ServiceNewToAgregation(m,rel) endif; m:Service Source= AEntity, Target=BEntity m:Relation Source= AClass, Target=BClass Size=1 EC reqs:RetoMODEL UML: UMLLite EC A:RulesModel UML: UMLLite Illustration 22: Service-New Rule in QVT Graphical Notation In our case, non top relations are characterized by left sides with a unique domain (the target domain), there’s no need of active rules set references since those relations are directly (or recursively) invoked from the top relations where the references to the active rules set is defined. In our non top relations there´s no need of where clauses, these non top relations are defined in order to improve the reusability and the maintainability of the rules. Since there are many structural patterns which at last are transformed in combinations of little number of different elements (associations, aggregations, association-class etc) and the rules transforming into these elements can be reused, been invoked from the top level rules. 65 Illustration 23 shows the QVT graphical notation for the Service-New to Aggregation Rule, the Left side with the requirements domain, the right side of the rule with the UML domain and the where clause in which previous transformations are defined. These non top relations finally perform the transformation from the requirements metamodel pattern into the UML Class diagrams metamodel in the alternative transformations. When ServiceNewToAggregation reqs:useCase AEntity: ClassSD name= nameAEntity BEntity: ClassSD name= nameBEntity <<domain>> uml:Package <<domain>> UseCaseToPackage(reqs, uml); EntityToClass (AEntity,A_Class); EntityToClass (BEntity,B_Class); m:Service Source= AEntity, Target=BEntity rel:Relation Source= AClass, Target=Bclass, Kind=aggregation, Namespace=uml, Name=nameAEntity+’_’ +nameBEntity+’_agre’ EC reqs:RetoMODEL UML: UMLLite AClass: Class name= nameAEntity BClass: Class name= nameBEntity Illustration 23: Service New To aggregation Rule in QVT Graphical Notation The rule transforming a Service New Message into a Association will be very similar to the rule shown in the Illustration 23. The main difference between ServiceNewToAggregation and ServiceNewToAsociation is the enforce domain, the kind of the relation which is created changes from aggregation to association. Both the ServiceNewToAggregation and the ServiceNewToAggregation, and others as ConnectToAssociation can be called from higher granularity rule. This bigger pattern rules can transform the structural source pattern into a structural pattern with high granularity or into a set of low granularity structural patterns. Those low granularity structural patterns can be associations or aggregations. For example the Structural Source Pattern defined in the left side of the rule 40 can be transformed into an Association-Class (as defined in the rule 40) but also can be transformed into two associations or an association and an aggregation. 66 If the domain expert decides to define bigger source structural patterns, then the target pattern will be combination of the rules presented at this point as set of rules associated to the source structural pattern in the transformation model at the step 1. When Where Connect_A_B_ServiceNew_B_C CEntity: ClassSD name= nameBEntity a:Artifacts Name= “ServiceNew_A-B_AndConnection_B-C” <<domain>> uml:Package BClass: Class CClass: Class <<domain>> rules:Rules UseCaseToPackage(reqs, uml); EntityToClass (AEntity,A_Class); EntityToClass (BEntity,B_Class); EntityToClass (CEntity,C_Class); if (a.rules->select(r|r.Id='TR14').size()=1) then ServiceNewToAssociation(m2,rel2) else ServiceNewToAgregation(m2,rel2) endif; ConnectionToAssociation(m1,rel1); m2:Service Source= AEntity, Target=BEntity rel2:Relation Source= AClass, Target=BClass Size=2 EC reqs:RetoMODEL UML: UMLLite EC A:RulesModel UML: UMLLite reqs:useCase AEntity: ClassSD name= nameAEntity BEntity: ClassSD name= nameBEntity <<domain>> m1:Connection Source= AEntity, Target=BEntity uml:Package AClass: Class BClass: Class <<domain>> rel1:Relation Source= AClass, Target=BClass Illustration 24: Connection A B and Service New B C in QVT Graphical notation The Illustration 24 shows the rule for transforming a structural pattern with the granularity of an association-class into two low-granularity structural patterns (can be two associations or an association plus an aggregation). This rule is fired whenever the active rules set has two rules for the structural pattern “Connection_A-B_ServiceNewAnd_B-C” and this structural pattern is in the source model (without being included into bigger structural patterns). 67 When Where ServiceNew_AB_TwoConnects_BC_CD AEntity: ClassSD name= nameBEntity a:Artifacts Name= “ServiceNew_AB_AndTwoConnections_B-C_C-D” <<domain>> uml:Package BClass: Class CClass: Class <<domain>> rules:Rules UseCaseToPackage(reqs, uml); EntityToClass (BEntity,B_Class); EntityToClass (CEntity,C_Class); EntityToClass (DEntity,D_Class) AEntity.OclIsTypeOf(Interface); ConnectionToAssociation(m2,rel2); ConnectionToAssociation(m2,rel2); m2:Service Source= AEntity, Target=BEntity rel2:Relation Source= BClass, Target=CClass Size=2 EC reqs:RetoMODEL UML: UMLLite EC A:RulesModel UML: UMLLite reqs:useCase CEntity: ClassSD name= nameCEntity BEntity: ClassSD name= nameBEntity <<domain>> m2:Connection Source= BEntity, Target=CEntity uml:Package BClass: Class DClass: Class <<domain>> rel1:Relation Source= BClass, Target=DClass DEntity: ClassSD name= nameDEntity m3:Connection Source= BEntity, Target=DEntity Illustration 25: Service New A B and Two connections B C and BD in QVT Graphical notation Illustration 25 shows the rule for transforming a structural pattern with the granularity of an association-class into two low-granularity structural patterns. This rule is fired whenever the active rules set has two rules for the structural pattern “ServiceNew_A-B_AndTwoConnects_BC” and this structural pattern is in the source model (without being included into bigger structural patterns). 68 6. Proof of Concept This chapter shows how the alternatives are applied in a transformation process and how a sequence diagram generates different UML class diagrams. In order to illustrate the transformation process and the alternative transformations we had used a example taken from the specification of a Hotel Management System. 6.1 Introduction To specify the object interactions to realize the Use Case Room Rental that is initiated by the the employee actor we had used a Sequence Diagram. This Use Case represents the rent of a room by a customer. Illustration 26 shows the sequence diagram for the Room Rental use case. First the actor starts the process, the system ask the actor for the User’s Id. Once the user has entered the required data then system performs a searching for the system. Once the customer has been retrieved, ask for the rental data (start date and end date). The system then performs a search for free rooms. If there are free rooms in the hotel in the given dates then the user selects one and creates the Rental. The Rental object will be then associated with the customer and the room. Finally the system creates the cost of this room (the invoicing data for the room) and associates this cost with the rental. The Illustration 27 shows an excerpt for the representation of this sequence diagram according with the RETO Metamodel. Messages which generates no transformations have been excluded from this representation in order to clearify the models. 69 Illustration 26: Interactions for the Use Case Room Rental Illustration 27: Ecore representation of the Room Rental Sequence Diagram defined according with RETO Metamodel : Employee : Rental : Customer : System <<interface>> : Room : Cost : CostType 1 : roomRental <<signal>> 2 : CustomerID? <<signal>> 3 : customer(id) <<signal>> 4 : idCustomer := searchCustomer(id) <<query>> 5 : rentalData? <<signal>> 6 : rentalData(initDate,endDate) <<signal>> 7 : searchForFreeRoom() <<query>> 8 : showFreeRoms <<signal>> 9 : chooseRoom(Room) <<signal>> 10 : createRental(Room, initDate, endDate, customerId) <<service: new>> 11 : AssignRoom(Room) <<connect>> 12 : AssignCustomer(idCustomer) <<connect>> 13 : newCost(description, value, costType) <<service: new>> 14 : assignCostType <<connect>> 15 : AssignToRent <<connect>> 70 6.2 Step 1: Rule Analysis In our approach this information, together with the transformation and the quality models will be used to transform the requirements specification into a UML class diagram. There are alternative transformations which can be applied, and as result of the model transformation process different output models could be generated. Our Quality Model is based on the Square standard [ (SQuaRE, 2005)]. For this domain, we choose two characteristics to compare: Operability (referred as Usability in the ISO 9126-1) and Maintainability. We made this selection; due the fact the Operability is one of the main factors influencing the Maintainability. Applying the AHP technique, the expert domain decides the rates for the quality attributes and the alternatives for each quality attribute. There are two rather different interpretations of how the MDA vision might be achieved. These two schools of thought have been termed “elaborationist” and “translationist” (McNeile, 2003) In the elaborationist approach, the definition of the application is built up gradually as you progress through from PIM to PSM to Code. In the other hand, in the translationist approach the PIM is translated directly into the final code of the system by code generation. Clearly, in the elaborationist approach, the generated artefacts (the PSM and the Code) must be understandable to the developer; otherwise modification (elaboration) would be not being possible. For our case study we use an elaborationist approach, due the fact that the target model is not directly transformed to a code model. For this reason we assign the weights in the way stated above (see table 4). 71 Table 5 Quality Model Weights Quality Attribute Weight Appropriateness Recognisability Efficiency 0,40 Appropriateness Recognisability Effectiveness 0,35 Changeability Efficiency 0,15 Changeability Effectiveness 0,10 The second step in the AHP application is to give weights to the alternatives. In our case study we consider two alternatives to the structural pattern: “For every message with the stereotype «service/new» from the class A to the class B, and two messages with the stereotype «connect» starting from the class B to the classes C and D respectively”. In the first, the whole source pattern is transformed into two associations (the A entity is an interface and then the service new will not be transformed) by a call to the rule TR15. The alternative is that the whole source pattern is transformed into a new association class (called B) AND also an association relationship between C and D related to the new association class B will be generated with a call to the rule TR39. 72 Table 6: Alternative transformations based on the output construct Alternatives Transformation Rules A1 (association) TR 14. For every message between two classes labeled with the stereotype «service/new» where both classes are distinct from the “interface” class THEN an association relationship between these classes will be generated. TR 15. For every message between two classes labeled with the stereotype «connect», THEN an association relationship between these classes will be generated. TR 16. For every message with the stereotype «service/new» or «connect» where classes using role names appears THEN an association relationship between these classes will be generated using these role names on the ends of the relationship. A2 (aggregation) TR 28. For every message with the stereotype «service/new» between two classes A and B, which are distinct from the “interface” class, THEN an aggregation relationship between these classes will be generated. A3 (association class) TR 39. For every message with the stereotype «service/new» from the class A to the class B, if there exist two messages with the stereotype «connect» starting from the class B to the classes C and D respectively, THEN a new association class will be generated (called B) AND also an association relationship between C and D related to the new association class B will be generated. TR 40. For every message with the stereotype «connect» from the class A to the class B, if there exist a message with the stereotype «service/new» starting from the class A or B to the class C THEN a new association class will be generated (called C) AND also, an association relationship between A and B related to the new association class C will be generated.. The alternative weights were given by the domain experts based in two empirical experiments. In the first work by Abrahão et al. (Abrahão, 2008), is presented a controlled experiment to determine which of the transformation rules for structural relationships: association (A1), aggregation (A2), or association class (A3), obtained the easiest to understand UML class model. The results show a slight tendency to favor the transformations related to associations (A1). Based in this study we can conclude that the diagrams generated applying the rule TR15 has a better Appropriateness Recognisability over the rule TR39. The second work (Marcela Genero, 2007) demonstrates with an empirical experiment that the Number of Associations (NAssoc) of one Class Diagram is related with the Maintainability. This fact implies that the TR15 generated model has a worst Maintainability compared with the TR39 generated one. The table 3 show the weights assigned to the alternatives according with the empirical experiments. 73 Table 7 Rule Weights Rule Appropriateness Recognisability Changeability Efficiency Effectiveness Efficiency Effectiveness TR15 0,40 0,35 0,25 0,14 TR39 0,36 0,30 0,40 0,37 6.3 Step 2: Model Transformation As an alternative solution to the transformation process based on the entities and messages contained on the sequence diagram shown on the Illustration 26 and together with transformation and quality models two possible output models are shown on Table 86. Those output models have been generated applying the transformations defined in section 5.5.1 and 5.5.2. The alternative output class models shown in the Table 8 can be obtained by applying the alternative transformations associated to the structural pattern “ServiceNewAB_Connects_BC_BD” who has been matched twice. In the first match the messages involved are 10 (Service), 11 and 12 (Connects). In the second match the messages involved are 13 (Service), 14 and 15 (Connects). It is obvious that other low granularity patterns can be recognized in the sequence diagram. Although in section 4.7 we establish that the match must be against the high granularity rule in order to avoid inconsistencies. Once the source models structural patterns and the matches have been defined, the fired rules will depend on the selection made by the rule analysis. With the rules defined at this moment we have two alternatives:  The whole source pattern is transformed into two associations (the A entity is an interface and then the service new will not be transformed) by a call to the rule 15  The whole source pattern is transformed into a new association class (called B) AND also an association relationship between C and D related to the new association class B will be generated with a call to the rule 39. If the selection in the rule analysis was (a) the message 11 will be transformed into an association to relate the Room rented with the Rental. The message 12 will be transform into an association to relate the Customer with the Rental. In the same way the message 14 will became an association to relate Cost with the Rental and the 15 will became an association to relate Cost with the CostType. If the selection in the rule analysis was (b) the messages 10, 11 and 12 will be transformed into an association class (named Rental) to relate the Room rented with the Customer. Moreover the messages 13, 14 and 15 will be transformed into an as an association class (named Cost) to relate the CostType with the Rental. 80 /*el UseCase es comprobado contra la clausula del when*/ useCases= reqs:metaRETOv01::useCaseDiagram::UseCase{} } , sourceMessage=m2:metaRETOv01::sequenceDiagram::Service { target= CEntity: metaRETOv01::sequenceDiagram::ClassSD { name=nameCEntity } } }, target=BEntity: metaRETOv01::sequenceDiagram::ClassSD { name=nameBEntity } }; checkonly domain rul a: MyRulesModel::Artifacts { Name='ServiceNew_A-B_AndConnection_A-C' }; enforce domain uml rel: MyUMLite::Relationship{ namespace= PaqUml: MyUMLite::Package{} }; when { m2.id_message=m1.id_message+1; a.rules->size()=1; a.rules->select(r|r.Id='TR40').size()=1; UseCaseToPackage(reqs, PaqUml); } where { ConnectionAndServiceNewToAssociationClass(m1,m2,rel); } } top relation ServiceNewAndTwoConnects_AsocClass { id_mess1, id_mess2, id_mess3: Integer; 81 checkonly domain reqs m1:metaRETOv01::sequenceDiagram::Service { id_message=id_mess1, source= AEntity: metaRETOv01::elements::Entity { sequence_diagram=s: metaRETOv01::sequenceDiagram::SequenceDiagram { /*el UseCase es comprobado contra la clausula del when*/ useCases= reqs:metaRETOv01::useCaseDiagram::UseCase{} } }, target=BEntity: metaRETOv01::sequenceDiagram::ClassSD { sourceMessage= m2: metaRETOv01::metaRETOv01::sequenceDiagram::Connection { id_message=id_mess2, target =CEntity: metaRETOv01::sequenceDiagram::ClassSD { } } } }; checkonly domain reqs m3: metaRETOv01::metaRETOv01::sequenceDiagram::Connection { id_message=id_mess3, target =DEntity: metaRETOv01::sequenceDiagram::ClassSD { } }; enforce domain uml rel: MyUMLite::Relationship { asociation_class= B_Class: MyUMLite::Class{}, source=C_Class:MyUMLite::Class{}, destination= D_Class:MyUMLite::Class {}, kind = KindOfRelationShip :: asociation, namespace= PaqUml: MyUMLite::Package { } }; checkonly domain rul a: MyRulesModel::Artifacts { 82 Name='ServiceNew_A-B_And2Connection_B-C_C-D' }; when { EntityToClass (BEntity,B_Class); EntityToClass (CEntity,C_Class); EntityToClass (DEntity,D_Class); m3.source=BEntity; m2<>m3; id_mess1<id_mess3; id_mess2<id_mess3; id_mess3<id_mess1+3; a.rules->size()=1; a.rules->select(r|r.Id='TR39').size()=1; CEntity<>DEntity; (AEntity.oclIsTypeOf(metaRETOv01::useCaseDiagram::Interface)) or (AEntity.oclIsTypeOf(metaRETOv01::sequenceDiagram::ClassSD) ); UseCaseToPackage(reqs, PaqUml); } where { ServiceAndTwoConnectionsToAssociationClass(m1,m2,m3,rel); } } top relation ServiceNewAndTwoConnectsNoInterface { id_mess1, id_mess2, id_mess3: Integer; checkonly domain reqs m1:metaRETOv01::sequenceDiagram::Service { id_message=id_mess1, source= AEntity: metaRETOv01::elements::Entity { sequence_diagram=s: metaRETOv01::sequenceDiagram::SequenceDiagram { /*el UseCase es comprobado contra la clausula del when*/ useCases= reqs:metaRETOv01::useCaseDiagram::UseCase{} } }, target=BEntity: metaRETOv01::sequenceDiagram::ClassSD { sourceMessage= m2: metaRETOv01::metaRETOv01::sequenceDiagram::Connection { id_message=id_mess2, target =CEntity: metaRETOv01::sequenceDiagram::ClassSD 83 { } } } }; checkonly domain reqs m3: metaRETOv01::metaRETOv01::sequenceDiagram::Connection { id_message=id_mess3, target =DEntity: metaRETOv01::sequenceDiagram::ClassSD { } }; enforce domain uml rel1: MyUMLite::Relationship { source=A_Class:MyUMLite::Class{}, destination=B_Class:MyUMLite::Class{}, namespace= PaqUml: MyUMLite::Package { } }; enforce domain uml rel2: MyUMLite::Relationship { source=B_Class:MyUMLite::Class{}, destination=C_Class:MyUMLite::Class{}, namespace= PaqUml: MyUMLite::Package { } }; enforce domain uml rel3: MyUMLite::Relationship { source=C_Class:MyUMLite::Class{}, destination=D_Class:MyUMLite::Class{}, namespace= PaqUml: MyUMLite::Package { } }; checkonly domain rul a: MyRulesModel::Artifacts { Name='ServiceNew_A-B_And2Connection_B-C_C-D' }; when { EntityToClass (AEntity,A_Class); EntityToClass (BEntity,B_Class); EntityToClass (CEntity,C_Class); EntityToClass (DEntity,D_Class); m3.source=BEntity; 84 m2<>m3; id_mess1<id_mess3; id_mess2<id_mess3; id_mess3<id_mess1+3; a.rules->size()=2; CEntity<>DEntity; (AEntity.oclIsTypeOf(metaRETOv01::sequenceDiagram::ClassSD) ); UseCaseToPackage(reqs, PaqUml); } where { if (a.rules->select(r|r.Id='TR14').size()=1) then ServiceNewToAssociation(m1,rel1) else ServiceNewToAgregation(m1,rel1) endif; ConnectionToAssociation(m2,rel2); ConnectionToAssociation(m3,rel3); } } top relation ServiceNewAndTwoConnectsInterface { id_mess1, id_mess2, id_mess3: Integer; checkonly domain reqs m1:metaRETOv01::sequenceDiagram::Service { id_message=id_mess1, source= AEntity: metaRETOv01::elements::Entity { sequence_diagram=s: metaRETOv01::sequenceDiagram::SequenceDiagram { /*el UseCase es comprobado contra la clausula del when*/ useCases= reqs:metaRETOv01::useCaseDiagram::UseCase{} } }, target=BEntity: metaRETOv01::sequenceDiagram::ClassSD { sourceMessage= m2: metaRETOv01::metaRETOv01::sequenceDiagram::Connection { id_message=id_mess2, target =CEntity: metaRETOv01::sequenceDiagram::ClassSD { } } 85 } }; checkonly domain reqs m3: metaRETOv01::metaRETOv01::sequenceDiagram::Connection { id_message=id_mess3, target =DEntity: metaRETOv01::sequenceDiagram::ClassSD { } }; enforce domain uml rel2: MyUMLite::Relationship { source=B_Class:MyUMLite::Class{}, destination=C_Class:MyUMLite::Class{}, namespace= PaqUml: MyUMLite::Package { } }; enforce domain uml rel3: MyUMLite::Relationship { source=C_Class:MyUMLite::Class{}, destination=D_Class:MyUMLite::Class{}, namespace= PaqUml: MyUMLite::Package { } }; checkonly domain rul a: MyRulesModel::Artifacts { Name='ServiceNew_A-B_And2Connection_B-C_C-D' }; when { EntityToClass (BEntity,B_Class); EntityToClass (CEntity,C_Class); EntityToClass (DEntity,D_Class); m3.source=BEntity; m2<>m3; id_mess1<id_mess3; id_mess2<id_mess3; id_mess3<id_mess1+3; a.rules->size()=2; CEntity<>DEntity; (AEntity.oclIsTypeOf(metaRETOv01::useCaseDiagram::Interface)); UseCaseToPackage(reqs, PaqUml); } where { 86 ConnectionToAssociation(m2,rel2); ConnectionToAssociation(m3,rel3); } } top relation Connection_A_B_AndServiceNew_B_C { nameAEntity, nameBEntity, nameCEntity: String; checkonly domain reqs m1:metaRETOv01::sequenceDiagram::Connection { source= AEntity: metaRETOv01::sequenceDiagram::ClassSD { name=nameAEntity, sequence_diagram=s: metaRETOv01::sequenceDiagram::SequenceDiagram { /*el UseCase es comprobado contra la clausula del when*/ useCases= reqs:metaRETOv01::useCaseDiagram::UseCase{} } }, target=BEntity: metaRETOv01::sequenceDiagram::ClassSD { name=nameBEntity, sourceMessage=m2:metaRETOv01::sequenceDiagram::Service { target= CEntity: metaRETOv01::sequenceDiagram::ClassSD { name=nameCEntity } } } }; checkonly domain rul a: MyRulesModel::Artifacts { Name='ServiceNew_A-B_AndConnection_B-C' }; enforce domain uml rel1: MyUMLite::Relationship{ source=A_Class:MyUMLite::Class {}, destination= B_Class:MyUMLite::Class{}, namespace= PaqUml: MyUMLite::Package{} 87 }; enforce domain uml rel2: MyUMLite::Relationship{ source=B_Class:MyUMLite::Class {}, destination= C_Class:MyUMLite::Class{}, namespace= PaqUml: MyUMLite::Package{} }; when { a.rules->size()=2; UseCaseToPackage(reqs, PaqUml); EntityToClass (AEntity,A_Class); EntityToClass (BEntity,B_Class); EntityToClass (CEntity,C_Class); } where { if (a.rules->select(r|r.Id='TR14').size()=1) then ServiceNewToAssociation(m2,rel2) else ServiceNewToAgregation(m2,rel2) endif; ConnectionToAssociation(m1,rel1); } } top relation ServiceNew { nameAEntity, nameBEntity: String; checkonly domain reqs m:metaRETOv01::sequenceDiagram::Service { source= AEntity: metaRETOv01::sequenceDiagram::ClassSD { name=nameAEntity, sequence_diagram=s: metaRETOv01::sequenceDiagram::SequenceDiagram { /*el UseCase es comprobado contra la clausula del when*/ useCases= reqs:metaRETOv01::useCaseDiagram::UseCase{} } }, target=BEntity: metaRETOv01::sequenceDiagram::ClassSD 88 { name=nameBEntity } }; checkonly domain rul a: MyRulesModel::Artifacts { Name='ServiceNew' }; enforce domain uml rel: MyUMLite::Relationship{ source=A_Class:MyUMLite::Class {}, destination= B_Class:MyUMLite::Class{}, namespace= PaqUml: MyUMLite::Package{} }; when { a.rules->size()=1; UseCaseToPackage(reqs, PaqUml); EntityToClass (AEntity,A_Class); EntityToClass (BEntity,B_Class); not(ServiceNewCheckForAssociationClassMessages(AEntity,BEntity)) ; } where { if (a.rules->select(r|r.Id='TR14').size()=1) then ServiceNewToAssociation(m,rel) else ServiceNewToAgregation(m,rel) endif; } } top relation Connection { nameAEntity, nameBEntity: String; checkonly domain reqs m:metaRETOv01::sequenceDiagram::Connection { /* Message's Source Entity*/ source= AEntity: metaRETOv01::sequenceDiagram::ClassSD { name=nameAEntity, sequence_diagram=s: metaRETOv01::sequenceDiagram::SequenceDiagram { useCases= reqs:metaRETOv01::useCaseDiagram::UseCase{} } }, 89 /* Message's Target Entity*/ target=BEntity: metaRETOv01::sequenceDiagram::ClassSD { name=nameBEntity } }; /* This rule must be the selected for the construct set in the active rules set*/ checkonly domain rul a: MyRulesModel::Artifacts { Name='Connection' }; /* Target Construct Set */ enforce domain uml rel: MyUMLite::Relationship{ source=A_Class:MyUMLite::Class {}, destination= B_Class:MyUMLite::Class{}, namespace= PaqUml: MyUMLite::Package{} }; when { /* this only will be applicable whe the source construct set is transformed with a single rule*/ a.rules->size()=1; /* the Source's Use Case have been previously transformed into a Package*/ UseCaseToPackage(reqs, PaqUml); /* Entities of the source model have been transformed into target's model classes*/ EntityToClass (AEntity,A_Class); EntityToClass (BEntity,B_Class); /* the message is'nt a part of a bigger construct (it will be transformed using another rule*/ not(ConnectionCheckForAssociationClassMessages(AEntity,BEntity,m )); } where { /*It will perform the transformation*/ ConnectionToAssociation(m,rel); } } relation ConnectionToAssociation { nameAEntity, nameBEntity: String; checkonly domain reqs m1:metaRETOv01::sequenceDiagram::Connection { source= AEntity: metaRETOv01::sequenceDiagram::ClassSD { name=nameAEntity, 96 ) or ( (AEntity.targetMessage->exists(m: metaRETOv01::sequenceDiagram::Message|m.oclIsTypeOf(metaRETOv01::seque nceDiagram::Service) and (m.id_message < asoc.id_message))) and (AEntity.sourceMessage->exists(m: metaRETOv01::sequenceDiagram::Message|m.oclIsTypeOf(metaRETOv01::seque nceDiagram::Connection )implies m.target<>BEntity )) ) ) then true else false endif } } 97 8. Bibliography Abrahão S., Insfran, E., Genero, M. Carsí, J. A., Ramos, I. y Piattini, M. Quality-Driven Model Transformations: From Requirements to UML Class Diagrams [Journal] // Model-Driven Software Development: Integrating QUality Assurance / ed. IGI-Global. - [s.l.] : Bunse, Jorg Rech Christian, 2008. - 302-326. Bézibvin et. al. First experiments with the ATL model transformation languaje: transforming XSLT into XQuery [Book]. - [s.l.] : 2nd OOPSLA Workshop on Generative Techniques in the context of MDA, 2003. Bézivin J.,Gerbé,O.: Towards a precise definition of the OMG/MDA framework [Book]. - [s.l.] : .In:Proc.16thInt’lConf.AutomatedSoftwareEngineering,IEEE, 2001. E. Insfran O. Pastor, R. Wieringa Requirements Engineering-Based Conceptual Modelling [Journal]. - [s.l.] : Springer-Verlag, 2002. Eclipse.org Eclipse Platform Technical Overview [Online]. - Eclipse Foundation, February 2003. - 2.1. - December 2009. - http://eclipse.org/whitepapers/eclipse-overview.pdf. Insfran E. A Requirements Engineering Approach for Object-Oriented Conceptual Modeling // Phd Thesis. - Valencia : DSIC Valencia University of Technology, 2003. Kleppe Warmer, Bast MDA explained: the model driven architecture: practice and promise [Book]. - [s.l.] : Addison-Wesley, 2003. - Vol. 032119442X. Koch Nora UWE, Transformation Techniques in the Model-Driven Development Process of [Book]. - [s.l.] : ICWE'06 Workshops, July 10-14, 2006, Palo Alto, CA, 2007. Kurtev Ivan PhD Thesis. Adaptability of Model Transformations [Book]. - Enschede , the Netherlands : Febodruk BV, 2005. Maddeh Mohamed Mohamed Romdhani, Khaled GHEDIRA MOF-EMF Alignment [Conference] // Third International Conference on Autonomic and Autonomous Systems (ICAS'07). - 2007. Marcela Genero Esperanz aManso , Aaron Visaggio, Gerardo Canfora, Mario Piattini Building measure-based prediction models for UML class diagram maintainability [Journal]. - [s.l.] : SpringerScience BusinessMedia, LLC2007, 2007. - Vols. DOI10.1007/s10664-007-9038-4. 98 McNeile Ashley MDA: The Vision with the Hole? Ashley McNeile [Book]. - [s.l.] : (http://www.metamaxim.com/download/documents/MDAv1.pdf). (2003), 2003. OMG MDA Guide V1.0 .1 [Book]. - [s.l.] : http://www.omg.org/cgi-bin/doc?omg/03-06-01.pdf, 2002. OMG Object Management Group Meta Object Facility (MOF) 2.0 Query/View/Transformation Specification [Online]. - april 2008. - 1.0. - 2009. - http://www.omg.org/spec/QVT/1.0/PDF. OMG Object Management Group UML 2.0 OCL Specification [Online]. - 14 10 2003. - 2.0. - 2009. - http://www.omg.org/spec/OCL/2.0/. Seidewitz What models mean [Book]. - [s.l.] : IEEESoftware 20, 2003. SQuaRE ISO/IEC Software Product Quality Requirements and Evaluation (SQuaRE) [Journal]. - [s.l.] : ISO/IEC. Software Engineering, 2005. Tom Mens Pieter Van Gorp A Taxonomy of Model Transformation [Book]. - [s.l.] : Electronic Notes in Theoretical Computer Science. Völter Markus and Sthal Thomas Model Driven Software Development [Book]. - [s.l.] : Wiley, 2006.