Ingénierie des Modèles Logiciels Cours #6 La transformation de modèles

Ingénierie des systèmes logiciels

© 2003 ATLAS Nantes. - 1 -

Ingénierie des Modèles Ingénierie des Modèles LogicielsLogiciels

Cours #6Cours #6 La transformation de modèlesLa transformation de modèles

Jean Bé[email protected]

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

Technologieprocédurale

Technologiedes composants

Technologiedes objets

Objets,Classes,

Smalltalk, C++,...

Procédures,Pascal,

C,...

Paquetages,Frameworks,

Patrons,…

1980 1995 2000

Raffinementprocédural

TechnologieDes modèles

Modèles, Méta-Modèles,UML, MOF,

XML, XMI, XSLT,

…

Compositiond'objets

Transformationde 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 Framework de Transformation ?



Un script awk

BEGIN { sum = 0; count = 0; }

/pattern*/ {sum = sum + $1; count++;

} END {

average = sum / count; print average; }

AWK : un générateur de rapport par Alfred Aho, Peter Weinberg & Brian Krnigham AWK recherche des motifs dans un fichieret exécute des actions lors de la rencontrede lignes correspondantes à ces motifs



Generation 2 : XSLT ou XQuery

<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 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 MbMt

MMt



Systèmes de transformation de modèles



La transformation de base

Mb f (MMa, MMb, Mt, Ma)



Le moteur du MDA

MOF

UTLU

PM

UM

LUML 2.0 SPEM

MOF 2.0 QVT RFP

UML : description des artefacts logiciels à objetsUPM : comment les utiliser et les produireUTL : comment générer des modèles à partir d'autres modèles

MDA model

UPM

UTL

UML

Meta-model



UML2Java

Méta-modèle UML

Méta-modèle Java



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 :

Constructorself.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 Constructorself.methodSignature.result.size() = 0




Une méthode ne peut prendre deux paramètres de même nom :

Methodself.methodSignature.parameter->forAll(P1,P2) P1.name <> P2.name



Un exemple : méta-modèle du langage Pascal

CalculAffectation Contrôle

For While Repeat

Argument

Instruction

Boucle

Bloc

{ordered}11

Conditionnelle

1..21..2

Procédure

11

Fonction

type de retour : Type

11

Programme

TypeVariable

nom11



Un exemple : méta-modèle du langage C#

Field

Constructor

Property

isReadable : BooleanisWritable : Boolean

Member

name : String

Assembly

name : String

Method

TypedAttribute

MethodBase

visibility : StringisAbstract : BooleanisFinal : BooleanisStatic : Boolean

Type

qualifiedName : StringisAbstract : Booleanvisibility : StringisSealed : Booleannamespace : String

0..1

0..*

owner

0..1

members

0..*

0..*

0..1

content

0..*

container0..1

0..1

0..*

super0..1

type

0..*

0..1

0..*

returnType

0..1

0..*

10..* type

10..*

Parameter

isIn : BooleanisOut : Booleanname : Stringposition : Integer

0..*

1

parameters0..*

method

1

1

0..*

type 1

0..*

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

Ma Mb

MMab

Transformationendogène

sem sem

Ma Mb

MMa

Transformationexogène

sem sem

MMa

Tab Tab



Endogeneous transformations

MMab

Ma Mb

sem semT

source cible



Exogeneous transformations

MMa MMb

Ma Mb

sem semT

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

QVT

Une analyse de l'appel à propositionpour 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:

1. MOF 2.0 Core RFP2. XMI for MOF 2.0 RFP3. MOF 2.0 to CORBA IDL mapping RFP 4. 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)

5. MOF 2.0 Versioning and Life Cycle Management RFP6. MOF 2.0 Query/Views/Transformations RFP (This document)7. 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

1. 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.

2. 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.

3. CWM has a transformation model. The experience gained in the CWM transformation model is worth investigating.

4. UML Action Semantics contains mechanisms for manipulating object state. Some of these mechanisms should be considered for re-use.

5. 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.

6. 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 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 MDAA.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

RuleSet

namefileversiononeLapsubRulesAreActions

(from StructurePackage))

RuleSet Lap

number


Action(from ActionPackage)

Rule

name


+SubRule

0..10..1

Context(from ContextPackage)

Transformation

toolNametransformationModelVersiontoolVersionauthorscenarioName

(from StructurePackage)



OpenQVT

Class(from InfrastructureLibrary)

Classifier(from InfrastructureLibrary)

Operation(from InfrastructureLibrary)

**

Constraint(from InfrastructureLibrary)

** *

* +postcondition

+precondition**

ProgramModule

TransformationUnit

actionKind : ActionKindQueryUnit

TransformationOperation

QueryOperation

Classifier(from InfrastructureLibrary)

0..1

*

0..1

*+context

+context

0..10..1

Unit

isExternal : Boolean

Package(from InfrastructureLibrary)

**

+feature*

*

*

*

MetaType

*

*

+source*

*

*

*

+target*

*

1

0..1

1

+metamodel

0..1

Profile(from InfrastructureLibrary)

*

*+appliedprofile

*

*



OpenQVT

RootRule

RuleSetCall

JavaServiceOCLService

RTransService

Variable

nametypevaluevis ibility

Context nnRule

11

n+SubRule

n+SuperRule

Service

vis ibilitysignature

nn

RulePart

11

Query Action

QARule

11 11

OCLFilter

RTransQuery

JavaQuery

RTransAction JavaAction

JavaFilter

RuleSet

11

11



ATL



ATL/G et MIA



OIM/Tfm

Element Dependency

ModelElementPackage

TypeTransformationPackage Member

Transformation

TransformationColumnGroup

TransformationTask

TransformationStepDependency

PrecedenceConstraint

TransformableObject

SourceTarget

Elements

Members

Elements

Transform

Target

Transform

SourceTarget

Source

Executes

TransformOjects

I nverseTransformation



Exemples de Transformations

Exemplesde

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.



Le pattern State

• MMa = Modèle de Classe +Modèle d'états

• MMb = Modèle de classe

Mt



Le pattern State

+Request()

«stereotype»Context_

+Handle()

«stereotype»ConcreteState

1

+state

1

request(){ state.Handle();}

«stereotype»State { interface }



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

MMa

MMb



UML2Java

public class MaClasse {int attrib [ ]

}

import java.util.*;public class MaClasse {

Collection attrib; }



UML2Java

public interface A {} public class AImpl implements A {}

public interface B {} public class BImpl implements B {}

public interface C extends A,B {} public class CImpl implements C {}

A.java

B.java

C.java



UML2UML (refactoring)



UML2UML (refactoring)

Privatisation d'attributs



Privatisation d'attributs



Privatisation d'attributs en ATL



EDOC to CCM

From EDOC components to CCM components :A precise mapping specification

FASE’ 2002M.Belaunde & M.Peltier France Telecom R&D My COM+

ComponentMy EJB

ComponentMy CCM

Component

Myconceptu

alCompon

ent

EDOC/CCA

Protocol

Interface

1

*

Choreography

PortOwner

*

1

Port

name : StringIsSynchronous : Booleantransactional : Booleandirection : DirectionTypepostCondition : Status

ProtocolPort OperationPort



SPEM to HR/XML

XML/HR

Super

SPEM

Infra

La gestion de compétences

Transfos possibles :

Spem InfraSpem Infra



UML2RDBMS

+Kind : string+name : string

UMLModelElemnt

Class PrimitiveDataType

Attribute

-type1

-typed

*

-owner1

-attribute*

Classifier Model-owner

1

-ownedElement

0..1



UML2RDBMS

-kind : String-name : String

RModelElemnt

ForeignKey Table key

-Type : String

Column

-owner

1-keyForeign* -owner

1

-key

*

-owner1

-column*

-referencedBy* -refersTo1

-Key0..1

-Column

*

-Key0..1

-Column

*

RDBMS

+owner

1

-ownerElement

*



UML2RDBMS

MOF Méta-Modèle

Modèle RDBMSModèle UML Modèle Transformation

instance

instance

instance

instance

instance

instance

TransformationEngine

sortieentrée règles

UMLToRDBMS Transformation

Modèle source Modèle

cible

RDBMS Spécification

UML Spécification

Class

TableAttribute Column

Association

FreignKey



Package SimpleUML

-Kind : string-name : string

UMLModelElemnt

Class PrimitiveDataType

Attribute

-type

1

-typed

*

-owner 1

*

Classifier

Association

+destination1

+reserve

*

+forward *

+source

1



Package SimpleRDBMS

RModelElemnt

ForeignKey Table key

Column

-owner

1-keyForeign* -owner

1

-key

*

-owner1

-column*

-referencedBy * -refersTo1

-Key0..1

-Column

*

-Key0..1

-Column

*



UML2RDBMS



Package UMLClassesToRDBMS

Shared

SimpleUML SimpleRDBMS

UML Rdbms

UMLToRDBMS

ClassToTable

AttributeToHomeColumn

+owner1

*

Class(from SimpleUML)

DrillDownContent

-class

1 *

Key(from SimpleRDBMS)

Table(from SimpleRDBMS)

Column(from Simple RDBMS)

*

+table

1

*

+primaryKey

1

-owner1

*

-Kind :-name :

AttributeRole

NonLeafAttribute

DrillDown

+owner1

+attributes*

-isNum : boolean

AttributeToColumn

*

+column

1

Atrribute(from SimpleUML)

*

+attribute1



Model-in-Action

MIAMIA-Transformation 3.0



La suite Model-in-Action

MIA-Generation

code documentation …

MIA-Transformation

…SPEM

MIA-MIA-GenerationGenerationTransformation de modèle à

code

MIA-MIA-TransformationTransformationTransformation de modèle à

modèle



Architecture

Règles de transformation

Editeur de règles (IDE)

Moteur detransformation

fichier XMI

Port XMI Méta-modèle(ex : UML 1.3)

fichier XMI

Port XMI Méta-modèleX

fichier XMI

Port XMI Méta-modèleY

• Une architecture ouverte



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



MIA

Ruleset

Selected rule

Rule documentation

Rule context

Rule query

Rule action



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 QVTOperation

ServiceSet QVTUnit

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

Diagrammesactivité

Méta-modèleUML Modèle

SPEM

Méta-modèleSPEM

ModèleMSProject

Méta-modèleMSProject



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)


© 2003 ATLAS Nantes. - 103 -

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. PottingerMSR-TR-2000-53


© 2003 ATLAS Nantes. - 104 -

Fin du cours

MerciQuestions ?Commentaires ?

Jean Bé[email protected] ATLAS, INRIA & IRIN, Nantes

Ingénierie des Modèles Logiciels Cours #6 La transformation de modèles

Documents

Transcript of Ingénierie des Modèles Logiciels Cours #6 La transformation de modèles