Ingénierie des Modèles Logiciels Cours #6

Ingénierie des Modèles Logiciels Cours #6
La transformation de modèles Jean Bézivin Equipe ATLAS (INRIA & IRIN), Nantes

Les trois générations de transformation
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 … Raffinement procédural Composition d'objets
1980 1995 2000 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
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 Framework de Transformation ?

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; }

Generation 2 : XSLT ou XQuery
<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 Quantity: <xsl:value-of </xsl:for-each> </BODY> </HTML> </xsl:template> <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>

Generation 3 : MDA Graphe Graphe Graphe

Transformation par compilation dans un autre espace

Le cadre global du MDA

Système de transformation de modèles
MOF MMa MMb Ma Mb Mt MMt

Systèmes de transformation de modèles

La transformation de base
Mb  f (MMa, MMb, Mt, Ma)

UPM UML MOF UTL Le moteur du MDA UML 2.0 SPEM MOF 2.0 QVT RFP
MDA model UPM UTL UML Meta-model UML 2.0 SPEM UML UPM 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

Fragment d'un méta-modèle UML

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

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 Pascal

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

Endogeneous transformations
MMab sem T sem source cible Ma Mb

Exogeneous transformations
MMa MMb sem T sem source cible Ma Mb

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; MMa  MMb  MMb  MMa 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
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/ MOF 1.4 Specification: OMG document ptc/ UML 2.0 Infrastructure RFP: OMG document ad/ XML Metadata Interchange 1.2: OMG document ptc/ Java Metadata Interface: XMI Production of XML Schema: OMG document ad/ UML 2.0 OCL RFP: OMG document ad/ MOF 2.0 Core RFP: OMG document ad/ MOF 2.0 IDL RFP: OMG document ad/ MOF 2.0 XMI RFP: OMG document ad/ MDA - A Technical Perspective: OMG document ormsc/ CWM 1.0: OMG document formal/ CWM 1.1: OMG document ptc/ UML Action Semantics: OMG document ptc/ OQL: SQL3: XSLT: CWM Metadata Interchange Patterns RFP: OMG document ad/

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 extending generic 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.

Initial Submission List

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)

L'organisation générale de MTRANS (Mikael Peltier)

OpenQVT

ATL/G et MIA

OIM/Tfm

Exemples de Transformations
transfos

Quelques exemples de transformation
Objectif: Illustrer les caractéristiques des différentes approches sur un jeu commun de "benchmarks" Montrer l'intérêt de pouvoir combiner des transformations et de construire des bibliothèques hiérarchisées de composants de transformation.

MMa = Modèle de Classe +Modèle d'états
Le pattern State MMa = Modèle de Classe +Modèle d'états MMb = Modèle de classe Mt

Le pattern State

Le pattern State copy Ma in Mb;
forEach stateClass in StateMachine.allInstances() { forEach stateClass in stateMachine.context forEach state in stateClass.behavior.top.subvertex; create Class in newClass; set newClass.name = concat(state.name,stateClass.name); create Generalization in newGene; set newGene.parent = stateClass; set newGene.child = newClass; }

UML2Java MMb MMa

UML2Java public class MaClasse { int attrib [ ] } import java.util.*;
Collection attrib; }

UML2Java public interface A {} public class AImpl implements A {}
A.java public interface B {} public class BImpl implements B {} B.java public interface C extends A,B {} public class CImpl implements C {} C.java

UML2UML (refactoring)

Privatisation d'attributs
UML2UML (refactoring) Privatisation d'attributs

Privatisation d'attributs

Privatisation d'attributs en ATL

M.Belaunde & M.Peltier France Telecom R&D
EDOC to CCM EDOC/CCA My COM+ Component My EJB My CCM My conceptual Mappings From EDOC components to CCM components : A precise mapping specification FASE’ 2002 M.Belaunde & M.Peltier France Telecom R&D

La gestion de compétences
SPEM to HR/XML Super SPEM XML/HR La gestion de compétences Transfos possibles : Spem  Infra Infra

UML2RDBMS

UML2RDBMS Transformation Engine instance instance instance
MOF Méta-Modèle instance instance instance Modèle UML Modèle RDBMS Modèle Transformation Modèle source Modèle cible instance instance instance UML Spécification UMLToRDBMS Transformation RDBMS Spécification Class Table Attribute Column Association FreignKey entrée règles sortie Transformation Engine

Package SimpleUML

Package SimpleRDBMS

UML2RDBMS

Package UMLClassesToRDBMS

Model-in-Action MIA MIA-Transformation 3.0

La suite Model-in-Action
MIA-Generation Transformation de modèle à code MIA-Transformation Transformation de modèle à modèle MIA-Transformation … SPEM MIA-Generation code documentation …

Règles de transformation
Architecture Une architecture ouverte Editeur de règles (IDE) Méta-modèle (ex : UML 1.3) fichier XMI Port XMI Méta-modèle X Moteur de transformation fichier XMI Port XMI Méta-modèle Y fichier XMI Port XMI Règles de transformation

Introduction Transformation de modèles à modèles
S ’inscrit pleinement dans l ’initiative MDA Forme une suite d ’outils MDE avec MIA-Generation MIA-Transformation est livré en standard avec : le méta-modèle UML 1.3 un import/export XMI 1.0 Organisation des règles de transformation en projets Un projet regroupe des : Rule Sets ensembles de règles de transformations Service Sets ensembles de services réutilisables Scénarios descriptions d ’enchaînements de transformations

Fonctionnalités > Rule Set
Un Rule Set déclare les modèles (et méta-modèles) qu’il souhaite manipuler Exemples : 1 modèle cible créé à partir d’1 modèle source 2 modèles fusionnés dans un 3ème 1 modèle lu en entrée et directement modifié 1 modèle cible créé à partir d’1 modèle source, avec création d ’un modèle de traçabilité etc. Déclaration d ’un modèle : méta-modèle + identifiant + type d ’accès

Fonctionnalités > Rule Set
Un Rule Set déclare ensuite : des règles de transformations, qui exploitent les modèles déclarés des services qui pourront être appelés par les règles de transformations

Fonctionnalités > Règles
Une règle de transformation déclare : un contexte d’évaluation les variables (et leurs types) qui seront utilisées dans la règle une requête recherche d ’objets de modélisation qui vérifient une certaine contrainte une action création de nouveaux objets de modélisation et de liens entre ces objets

Fonctionnalités > Règles > Langages
3 langages de transformations pour définir requêtes et actions : RL-TL et MIA-TL syntaxes simples utilisables pour la plupart des transformations Java pour réaliser dans les règles des traitements complexes Partage de variables via le contexte d ’évaluation de la règle

Fonctionnalités > Règles > Hiérarchie
Hiérarchie de règles : chaque règle peut avoir des sous-règles Une sous-règle n ’est évaluée que si la requête de la règle parente a été exécutée Une sous-règle s ’exécute dans le contexte d ’évaluation de la règle parente Dans la pratique : + de lisibilité - de parcours dans les modèles

Fonctionnalités > Appels de Rule Sets
Un Rule Set peut appeler d ’autres Rule Sets Permet de : décomposer une transformation complexe isoler des transformations basiques réutilisables

L ’appel de Rule Set peut s ’effectuer à tout moment de la transformation (ex : entre deux règles) On définit un mapping de modèles

On peut définir un mapping de contextes = passage de paramètres Un Rule Set peut déclarer des paramètres attendus

Fonctionnalités > Services
Un service : isole un traitement réutilisable déclare des paramètres et un type de retour peut être défini en RL-TL, MIA-TL ou Java peut être appelé depuis une règle ou un autre service

Fonctionnalités > Services
Exemples de services : traitements de chaînes de caractères création d ’un objet complexe Création d ’une Association UML code répétitif création d ’une TaggedValue UML

Fonctionnalités > Services Sets
Un Service Set : déclare un ensemble de services Service Set = librairie déclare éventuellement les méta-modèles requis ex : services facilitant l ’exploitation de modèles UML peut être importé par un Rule Set ou un autre Service Set nécessaire pour qu’une règle ait accès aux services d ’un Service Set

Fonctionnalités > Scénarios
Un scénario déclare : les modèles qu ’il souhaite exploiter des enchaînements de lecture et d ’écriture de modèles, et d’ appels de Rule Sets Permet de packager une transformation assemblage de transformations unitaires C ’est ce que voit l ’utilisateur final

Mapping avec QVT MIA QVT Rule QVTOperation RuleSet QVTUnit Service
ServiceSet Project QVTModule Scenario QVTComponent

Présentation du TD #3 TD #3

Présentation du TD3 Piloter l'outil propriétaire Microsoft MSProject par un diagramme d'activités UML. Comme on veut factoriser, on passera par l'intermédiaire d'un modèle pivot exprimé en SPEM Prérequis: Compréhension des diagrammes d'activité de UML Compréhension de SPEM Compréhension de MSProject Modèle SPEM Méta-modèle Méta-modèle UML Modèle MSProject Méta-modèle Diagrammes activité

Rappels sur le TP 2 UML2HTML by XSLT ObjectByDesign

Rappels sur le TP 2

MS Project : Un méta-modèle

MS Project MS Project uses a special chart for most of its planning and scheduling, called a Gantt chart (see below). The Gantt chart consists of a table of task information and a bar chart that graphically displays your project schedule. An adjustable divider bar separates the Gantt table on the left from the Gantt chart on the right.

MSProject

Rappels sur les diagrammes d'activité (UML 1.5)

Rappels sur SPEM

Model Management By model we mean a complex structure that represents a design artifact, such as a relational schema, object-oriented interface, UML model, XML DTD, web-site schema, semantic network, complex document, or software configuration. Many uses of models involve managing changes in models and transformations of data from one model into another. These uses require an explicit representation of mappings between models. We propose to make database systems easier to use for these applications by making model and model mapping first-class objects with special operations that simplify their use. We call this capacity model management P.A. Bernstein, A.L. Levy & R.A. Pottinger MSR-TR

Fin du cours Merci Questions ? Commentaires ? Jean Bézivin
Equipe ATLAS, INRIA & IRIN, Nantes

Ingénierie des Modèles Logiciels Cours #6

Présentations similaires

Présentation au sujet: "Ingénierie des Modèles Logiciels Cours #6"— Transcription de la présentation:

Présentations similaires

Notre projet

Feed-back

Entrer

S'autoriser via un réseau social:

Ingénierie des Modèles Logiciels Cours #6

Présentations similaires

Présentation au sujet: "Ingénierie des Modèles Logiciels Cours #6"— Transcription de la présentation:

Présentations similaires

Notre projet

Feed-back