Download
1 / 104
1.05k likes | 1.25k Views
Ingénierie des Modèles Logiciels Cours #6 La transformation de modèles Jean Bézivin Jean.Bezivin@irin.univ-nantes.fr Equipe ATLAS (INRIA & IRIN), Nantes. Plan du cours #6. Les trois générations de transformation Transformations de fichiers Transformations d’arbres
E N D
Ingénierie des Modèles Logiciels Cours #6 La transformation de modèles Jean BézivinJean.Bezivin@irin.univ-nantes.fr Equipe ATLAS (INRIA & IRIN), Nantes
Plan du cours #6 • Les trois générations de transformation • Transformations de fichiers • Transformations d’arbres • Transformations de graphes • Les trois principes • Les sept niveaux de transformation • L'appel à propositions QVT • Quelques réponses à l'appel QVT • Quelques exemples de transformation, • Présentation de MIA • Présentation du TD #3
De l'OMA vers le MDA 2000 1980 1995 Technologie procédurale Technologie des objets Technologie des composants Technologie Des modèles Procédures, Pascal, C, ... Objets, Classes, Smalltalk,C++, ... Paquetages, Frameworks, Patrons, … Modèles, Méta-Modèles, UML, MOF, XML, XMI, XSLT, … Raffinement procédural Composition d'objets Transformation de modèles
Trois générations des systèmes de transformation • Génération 1 • Transformation de structures séquentielles d'enregistrement • Exemple : le système UNIX • Exemple : AWK • Un script spécifie déclarativement comment un fichier d'entrée se réécrit en un fichier de sortie. Un fichier est composé d'enregistrements ou lignes. Un enregistrement est composé de champs. Une ligne d'entrée peut produire plusieurs lignes en sortie. • Génération 2 • Transformation d'arbres • Exemple : les documents XML • Exemples : XSLT ou XQuery • Un arbre en entrée est parcouru et ce parcours génère des fragments de l'arbre de sortie. • Génération 3 • Transformations de graphes • Exemple : MDA /QVT • Un modèle en entrée (un graphe orienté étiqueté) est transformé en un modèle en sortie. La transformation est spécifiée par un autre modèle.
Trois générations des systèmes de transformation • Il y a de nombreuses leçons à tirer des précédents efforts et réalisation dans les systèmes de transformation, par exemple : • Quelles sont les similarités et les différences de ces trois cadres de transformation (transformation frameworks) ? • Que peut-on apprendre des cadres de transformation de première et deuxième génération lors de la mise en place des cadres de troisième génération ? • Quelle est la nécessité de et la plus-value des cadres de troisième génération ?
Le cadre Unix • Une commande peut être constituée d'autres commandes • Les commandes peuvent être chaînées • Il est possible de spécifier des structures de contrôle sur l'exécution des commandes • Il est possible de tester le résultat d'une commande
Un script awk AWK : un générateur de rapport par Alfred Aho, Peter Weinberg & Brian Krnigham AWK recherche des motifs dans un fichier et exécute des actions lors de la rencontre de lignes correspondantes à ces motifs BEGIN { sum = 0; count = 0; } /pattern*/ {sum = sum + $1; count++; } END { average = sum / count; print average; }
<HTML> <HEAD> <TITLE>Welcome</TITLE> </HEAD> <BODY> Welcome $name! <br /> List items: <ul> #foreach ( $item in $items ) <li>Type: $item.type, Quantity: $item.quantity #end </BODY> </HTML> <xsl:template match="/doc"> <HTML> <HEAD> <TITLE>Welcome</TITLE> </HEAD> <BODY> Welcome <xsl:value-of select="name"/>! <br/> List items: <ul> <xsl:for-each select="items"> <li>Type: <xsl:value-of select="@type"/>, Quantity: <xsl:value-of select="@quantity"/>, </xsl:for-each> </BODY> </HTML> </xsl:template> Generation 2 : XSLT ou XQuery
Generation 3 : MDA Graphe Graphe Graphe
MOF MMt MMa MMb Mt Ma Mb Système de transformation de modèles
La transformation de base Mb f (MMa, MMb, Mt, Ma)
MDA model Meta-model UML UPM UTL Le moteur du MDA UML 2.0 SPEM UPM UML MOF UTL MOF 2.0 QVT RFP UML : description des artefacts logiciels à objets UPM : comment les utiliser et les produire UTL : comment générer des modèles à partir d'autres modèles
UML2Java Méta-modèle Java Méta-modèle UML
Exemple d'un méta-modèle Java élémentaire Le nom du constructeur est celui de la classe qui le définit : Constructor self.name = self.ClassOrInterface.name
Fragment d'un méta-modèle UML Un constructeur ne renvoie pas de résultat (pas de valeur retournée) : Context Constructor self.methodSignature.result.size() = 0
Exemple d'un méta-modèle Java élémentaire Une méthode ne peut prendre deux paramètres de même nom : Method self.methodSignature.parameter->forAll(P1,P2) P1.name <> P2.name
Un exemple : méta-modèle du langage C# MMs: - infra-syntaxique - "full syntaxique" - sémantique (heuristiques)
Les trois principes du MDA • [P1] Les modèles sont des citoyens de première classe • [P2] Les transformations sont des modèles • [P3] Les modèles sont capitalisables • [C1] HOT • [C2] les transformations sont composables et spécialisables • etc.
Différentes formes de transformations MMab MMa MMa sem sem sem sem Ma Mb Ma Mb Tab Tab Transformation endogène Transformation exogène
MMab Ma Mb Endogeneous transformations T sem sem source cible
MMa MMb Ma Mb Exogeneous transformations T sem sem source cible
Sept niveaux de systèmes de transformation • Niveau# 7: Ma->Mb; MMa = Mc; MMb = MMc • Niveau# 6: Ma->Mb; MMa ∩ MMb = Ø • Niveau# 5: Ma->Mb; MMa ∩ MMb ≠ Ø • Niveau# 4: Ma->Mb; MMaMMb MMbMMa • Niveau# 3: Ma->Mb; MMb= MMa' • Niveau# 2 Ma->Mb; MMa=MMb • Niveau# 1 Ma->Ma; • Remarques: • Il s'agit d'une classification préliminaire • Il peut y avoir d'autres niveaux • Certains niveaux vont être décomposés • Les profils n'ont pas été pris en compte
MOF/QVT : Spectroscopie d'un RFP QVT Une analyse de l'appel à proposition pour le nouveau standard MOF/QVT (Queries/Views/Transformations)
Specific Requirements on Proposals • MOF is the standard facility of the OMG to define metamodels for languages. E.g. UML and CWM are formally defined in MOF. The MOF 2.0 and UML 2.0 RFPs require that both technologies are based on the same core. • The MDA Technical Perspectives white paper states that relationships between models should be defined at the same level of abstraction as their metamodels. Given that all the OMG metamodels are defined using MOF, this enables a single transformation language to define mappings between any pair of models expressed in these languages. Furthermore, mappings may be defined in this single language to any non-OMG language for which a MOF metamodel is defined. For example, mappings are facilitated between UML and the CORBA Component Model (as it is a standard MOF metamodel), between models expressed in UML 1.4, and models expressed in UML 2.0 (as it will have a MOF metamodel). Other examples include mappings between EDOC-ECA and EAI, UML and EJB, etc…
Problem Statement • This RFP addresses the need for standardizing the way mappings are achieved between models whose languages are defined using MOF. In addition the RFP calls for a standard way of querying MOF models, and creating views onto these models. This is similar to the need for XSLT for XML, where an XSLT script defines the mapping between a pair of DTDs and dictates how XMLs (compliant with the DTDs) are transformed. • Queries on MOF models are required both to filter and select elements from a model on an ad-hoc basis, as well as to select elements that are the sources for transformations. This is similar to the need for XPath within XSLT. • A view reveals specific aspects of a modeled system. A view is a model that is derived from another model. This RFP requests a mechanism for creating views. The RFP also addresses a common problem in current OMG specifications (such as MOF 1.x, XMI 1.x) and in many emerging Java Community Process JSRs (such as JMI). In these specifications transformation rules are described in English text, BNF and other mechanisms and there is no single standard way of defining them formally.
Scope • The following family of ‘proposed’ MOF 2.0 RFPs is planned over the next 12 to 18 months based on ADTF member’s feedback. Because of the wide range of interests in the MOF community, it was decided to have a number of narrowly focused RFPs, rather than having one or two general RFPs that cover many different topics. This document is the sixth of the MOF 2.0 RFPs: • MOF 2.0 Core RFP • XMI for MOF 2.0 RFP • MOF 2.0 to CORBA IDL mapping RFP • MOF 2.0 to Java (JMI2) mapping. (This is expected to be handled through a new JSR issued under the Java Community Process umbrella to revise JMI 1.x) • MOF 2.0 Versioning and Life Cycle Management RFP • MOF 2.0 Query/Views/Transformations RFP (This document) • MOF 2.0 Federation/Facility/Directory RFP
Scope • This RFP depends on the details to be determined by the MOF 2.0 Core RFP process. • This RFP does not request a solution to render concrete syntaxes into the actual files; nor does it request mappings to other non-MOF technologies.
Relationship to Existing OMG Specifications • MOF 1.x uses OCL (defined in UML 1.x) for defining constraints and operation semantics. MOF 2.0 will be depend even more on the UML 2.0 infrastructure. It is likely that OCL plays an important role in queries on metadata. While issuing this RFP there is another RFP for UML 2.0 OCL in progress. • Many OMG specifications and proposed specifications (e.g. MOF 1.x, EDOC and EAI) have defined transformation rules on metadata. These transformations should be definable in a standard way using the proposed solution. • CWM has a transformation model. The experience gained in the CWM transformation model is worth investigating. • UML Action Semantics contains mechanisms for manipulating object state. Some of these mechanisms should be considered for re-use. • Transformations and mappings are key aspects of MDA since many PIMS and PSMs will be standardized over the next several years. Submitters should be familiar with the MDA terminology by reviewing the MDA Technical perspectives and related white papers. • The in-progress CWM Metadata Interchange Patterns RFP includes a request for “a generic mechanism for expressing CWM metadata interchange patterns” which “must be specified in terms of MOF concepts”. There is potential for common approaches between this and the definition of MOF-based queries and views in response to this RFP.
Related Documents and Standards • MOF 1.3 Specification: OMG document formal/2001-10-41 • MOF 1.4 Specification: OMG document ptc/2001-10-04 • UML 2.0 Infrastructure RFP: OMG document ad/00-09-01 • XML Metadata Interchange 1.2: OMG document ptc/2001-08-22 • Java Metadata Interface: http://jcp.org/jsr/detail/40.jsp • XMI Production of XML Schema: OMG document ad/2001-06-12 • UML 2.0 OCL RFP: OMG document ad/00-09-03 • MOF 2.0 Core RFP: OMG document ad/01-11-14 • MOF 2.0 IDL RFP: OMG document ad/01-11-07 • MOF 2.0 XMI RFP: OMG document ad/01-11-13 • MDA - A Technical Perspective: OMG document ormsc/01-07-01 • CWM 1.0: OMG document formal/2001-10-01 • CWM 1.1: OMG document ptc/2002-01-04 • UML Action Semantics: OMG document ptc/2002-01-09 • OQL: http://www.odmg.org/ • SQL3: http://www.ansi.org/ • XSLT: http://www.w3.org/TR/xslt • CWM Metadata Interchange Patterns RFP: OMG document ad/2001-04-11
Mandatory Requirements • Proposals shall define a language for querying models. The query language shall facilitate ad-hoc queries for selection and filtering of model elements, as well as for the selection of model elements that are the source of a transformation. • Proposals shall define a language for transformation definitions. Transformation definitions shall describe relationships between a source MOF metamodel S, and a target MOF metamodel T, which can be used to generate a target model instance conforming to T from a source model instance conforming to S. The source and target metamodels may be the same metamodel. • The abstract syntax for transformation, view and query definition languages shall be defined as MOF (version 2.0) metamodels. • The transformation definition language shall be capable of expressing all information required to generate a target model from a source model automatically. • The transformation definition language shall enable the creation of a view of a metamodel. • The transformation definition language shall be declarative in order to support transformation execution with the following characteristic: • Incremental changes in a source model may be transformed into changes in a target model immediately. • All mechanisms specified in Proposals shall operate on model instances of metamodels defined using MOF version 2.0.
Optional Requirements • Proposals may support transformation definitions that can be executed in two directions. There are two possible approaches: • Transformations are defined symmetrically, in contrast to transformations that are defined from source to target. • Two transformation definitions are defined where one is the inverse of the other. • Proposals may support traceability of transformation executions made between source and target model elements. • Proposals may support mechanisms for reusing and extendinggeneric transformation definitions. For example: Proposals may support generic definitions of transformations between general metaclasses that are automatically valid for all specialized metaclasses. This may include the overriding of the transformations defined on base metaclasses. Another solution could be support for transformation templates or patterns. • Proposals may support transactional transformation definitions in which parts of a transformation definition are identified as suitable for commit or rollback during execution. • Proposals may support the use of additional data, not contained in the source model, as input to the transformation definition, in order to generate a target model. In addition proposals may allow for the definition of default values for this data. • Proposals may support the execution of transformation definitions where the target model is the same as the source model; i.e. allow transformation definitions to define updates to existing models. For example a transformation definition may describe how to calculate values for derived model elements.
Issues to be discussed • The OMG CWM specification already has a defined transformation model that is being used in data warehousing. Submitters shall discuss how their transformation specifications compare to or reuse the support of mappings in CWM. • The OMG Action Semantics specification already has a mechanism for manipulating instances of UML model elements. Submitters shall discuss how their transformation specifications compare to or reuse the capabilities of the UML Action Semantics. • How is the execution of a transformation definition to behave when the source model is not well-formed (according to the applicable constraints?). Also should transformation definitions be able to define their own preconditions. In that case: What's the effect of them not being met? What if a transformation definition applied to a well-formed model does not produce a well-formed output model (that meets the constraints applicable to the target metamodel)? • Proposals shall discuss the implications of transformations in the presence of incremental changes to the source and/or target models.
Evaluation Criteria • Proposals are preferred that support transformations of relatively high complexity. A simple transformation is for example, a transformation of one instance of "model.Attribute" (the source) to one instance of "uml.foundation.core.Attribute" (the target), both having an attribute called "name". A more complex transformation would be transforming an object-oriented model into a relational model including the mapping of the same attribute to different columns for foreign key membership. • Proposals shall be preferred that support reusable transformation definitions. For example, by supporting inheritance of transformation rules templates, or patterns. • Proposals shall be preferred that support extendable transformation definitions. In real-world situations users of an "off-the-shelf transformation" want to be able to override or extend aspects of that definition.
Quelques réponses Transformation: The missing link of MDA A.Gerber, M. Lawley, K. Raymond, J. Sterlle, A. Wood CRC for Enterprise Distributed systems (DSTC)
