From Web services to Ubiquitous computing Study and application of Model Driven Development Approach   From Web services to Ubiquitous computing Slimane Hammoudi ESEO Angers, France slimane.hammoudi@eseo.fr http://perso.eseo.fr/~shammoudi/ 1

Contents Introduction: Web Services, MDA and MDE Transformation process: mapping versus transformation MDA for Web services Conclusion on MDA for Web services Ubiquitous computing and context–aware services (CWS) Context and context-awareness Conceptual architecture for CWS MDA for CWS Transformation process: merging versus parameterization Conclusion on MDA for CWS Towards adaptable SOA : MDD, context and aspects Towards a semi automatic transformation process in MDD 2

1. Introduction Before the Web Middleware « Era »  Web Services for E-Applications (B2B, B2C,…etc). XML-RPC DCOM/COM+ CORBA-IIOP EDI-standards HTTP/HTML CGI RPC Java RMI Before the Web Middleware «  Era  » - Interoperability on Internet ? - One Unique Middleware? ? Internet/ Intranet Travel Agency Airlines Network RentCar Client [Time - 0:53] Dans les derniers années, l’Internet a connu une croissance énorme et de plus en plus les systèmes logiciels sont présents soit dans les entreprises comme dans la vie quotidienne. Par exemple, une agence de voyages, qui vend des billets d’avion, loue des voitures et réserve des chambre d’hôtels, doit utiliser un intergiciel pour permettre l’interopérabilité entre son système et les systèmes d’autres entreprises. ► Dans un premier temps, les intergiciels traditionnels tels que CORBA et DCOM ont été adapté pour travailler sur l’Internet. Cependant, ceci était une adaptation et non un intergiciel fait pour l’Internet. Ainsi, l’envie de créer un intergiciel unificateur et qui proposerai l’interopérabilité sur l’Internet a stimulé l’apparition des services Web. Client Web Services ! Standard (XML, SOAP, WSDL et UDDI) W3C, OASIS Client Hotel 3

1. Introduction:Web Services  Web Services : Main Technologies - Standard SERVICE XML EVERYWHERE 4

1. Introduction:Web Services 5

1. Introduction: Model Driven Architecture Bézivin, Guest Talk, UML’03 First crisis: 1965 Main problem: collective programming Solutions: (NATO Summer School 1967 & 1968 in Garmisch-Partenkirchen) "Software engineering" "Structured programming" "Top-down approaches“ Second crisis: 2000 Main problem: rapid platform evolution but, more generally, complexity management Solutions: (OMG November 2000 white paper): MDA : Decouple neutral business models from variable platforms From code-centric to model-centric approaches "Transformations as assets" 6

How Systems will be Built 1. Introduction: Model Driven Architecture How Systems will be Built Raising Abstraction Level to Models Applications are constructed from models Less implementation effort Whole system is represented in a model Code generators generate executable systems MDA OMG (MOF, UML, CWM) Model Driven Engineering More generic, not OMG specific 7

Models as first class entities 1. Introduction : Model Driven Architecture Models as first class entities PIM Platform Independent Model (PIM) PIM has role of source code Platform Specific Models (PSM) Platform code generated from PSM PSM (1) Relational-DB PSM (2) EDOC_CCA PSM (3) Web Service System Code Oracle/DB2 System Code EJB/CORBA-CCM System Code .NET/J2EE 8

Write Once, Run Anywhere Model Once, Generate Anywhere 1. Introduction : Model Driven Architecture [Bézivin 2003] Write Once, Run Anywhere Model Once, Generate Anywhere Platform-Independent Model PIM Multi-target code generation etc. data grid computing pervasive computing cluster computing CORBA SMIL/Flash Java/EJB C#/DotNet Web/XML/SOAP + SVG, GML, Delphi, ASP, MySQL, PHP, etc. 9

1. Introduction : Model Driven Architecture Platform Independant Models UML/MOF Abstract Modeling Space JSR #40 Java User Community (Sun) XMI/XSLT projection Concrete Execution Spaces Java/EJB IDL XML/SOAP C#/DotNet CORBA Platform Specific Models 10

1. Introduction : Model Driven Architecture But also backward PIM PSM PSM Platforms of the present Platforms of the past Platforms of the future Java, EJB, J2EE, etc. ???? Grid, Cluster, P2P architectures Legacy, Cobol, ADA, etc. 11

1. Introduction : Model Driven Architecture From MDA to MDE DBWare OntoWare ModelWare …………… Different framework Different technological spaces 12

1. Introduction : Model Driven Architecture  MDA Overview: (3 + 1 ) layers of Architecture conformsTo Level M3 The MOF MMM P I M Versus S conformsTo conformsTo conformsTo The EDOC MM The UML MM The CWM MM Level M2 conformsTo conformsTo A UML model m1 A UML model m2 Level M1 representedBy representedBy A particular use of m1 Another use of m1 Real World Level M0 MMM : metametamodel MM : metamodel m : model 13

 The Metamodelling Stack & Main Technologies 1. Introduction : Model Driven Architecture  The Metamodelling Stack & Main Technologies MOF Class M3 MOF, UML, CWM Modeling Baseline XMI Representation for MOF/UML models JMI, EMF APIs for Java, XMI OCL Enhances models with formal descriptions QVT - A standard for model transformation conformsTo UML Class M2 conformsTo ID: string Type: string Car M1 representedBy Peugeot H-1234 M0: Objects/Data 14

Transformation Metamodel 1. Introduction : Transformation in MDA  Transformation : The Heart of MDA M3 MOF ConformsTo ConformsTo ConformsTo Source Transformation Metamodel (ATL,…etc.) Target M2 Metamodel Metamodel ConformsTo to ConformsTo from ConformsTo P I M Source Target P S M Transformation M1 Model Model (Program) Model exec source Transformation Transformation engine target M0 Engine 15

1. Introduction : Transformation in MDA « The concept of Transformation is not so clear, since this term can refer to many different concepts » [ Favre, UML 04] Transfo. Instance Transfo. function Transf. model Transfo. program Transfo Progra. lang. Transfo Meta- model Transfo. Interpret er MDA GUIDE 1.0 Transfo. Mapping Instance Mapping Model Mapping langage MDA DISTILLED Mapping Mapping rule Mapping function MDA EXPLAINED Mappi/Transf rule Transfo. definition Transfo tool QVT DSTC «Tracking» Transfo. rule TransfoModel Transf. engine QVT Partners Transfo. Relation Mapping Relation [Judso &al 03] Transfo. Pattern [Caplat 03] Model of Mapping Mapping formalism [Peltier 03] Transfo Process Transfo descr 16

2. Mapping Versus Transformation in MDA DB Field : Model Management Project [P.Bernstein, MS Research ] «We define a mapping to be a set of mapping elements, each of which indicates that certain elements of schema S1 are mapped to certain elements in S2. « ...transformation between models, requires an explicit representation of mappings, which describe how two models are related to each other ». Ontology Field : OntoMerge Project [D.McDermott, Yale Univ] «It's important to distinguish ontology translation from ontology mapping, which is the process of finding correspondence (mappings) between the concepts of two ontologies. If two concepts correspond, they mean the same thing, or closely related things. 17

Transformation Definition 2. Mapping Versus Transformation in MDA +attrA11:Type1 +attrA12:Type2 A1 +attrA21:Type3 +attrA22:Type4 A2 +attrB11:Type5 +attrB12:Type6 B1 +attrB21:Type7 +attrB22:Type8 B2 A2B Aa2Bb Source metamodel Target Mapping Me source target Mapping Element composition  Mapping versus Transformation [Lopes 2005]  In MDA, MDE Mapping Specification Transformation Definition 18

GeneralizableElement 2. Mapping Versus Transformation in MDA A Graphical formalism for Mappings Package NameSpace 0..1 0..* +namespace +ownedElement AssociationEnd Attribute Parameter DataType ModelElement GeneralizableElement Generalization +specification +generalization +parent +child Interface Method Operation Class +method JavaElement JavaPrimitiveType JavaMethod JavaParameter JavaInterface JavaClass +implementedby +implements +owner +parameter JavaPackageElement JavaPackage JavaClassifier +modifier:Modifier +visibility:Visibility +super +sub +isOfType JavaField Ae2F G2s A2F Dt2Pt P2P C2C Pr2Pr OM2M UML meta-model Java meta-model Mappings I2I 19

3. MDA for Web Services  Approach Overview [Lopes 2005] B2B/B2C as privileged applications WEB SERVICES as implementation platforms MDA as a development approach Source M (UML / EDOC) PIM Model-to-Model Transformations Target M (WS) Target M (J2EE) Target M (dotNet) PSM Model-to-Code Transformations Source code (XML) « WSDL document » «  BPEL document  » Source code (XML) « WSDL document » «  BPEL document  » Source code (Java), Deployment files, etc. Source code(C#), Deployment files, etc. Code 20

3. MDA for Web Services  Case study Travel Agency AirLinesService HotelService Hotel CarHire Bank AirLines Travel Agency TravelService AirLinesService RentingCarService BankService 21

3. MDA for Web Services  Methodology UML(EDOC) Web Services Definition of Metamodels for PIMs Definition of Metamodels for PSMs Mapping Specification Between PIMs and PSMs -Metamodels Transformation Definition Generation Transformation Definition Execution (PIM to PSM) -Models [PSM is complete] [Time - 01:03] L’apparition de services Web comme l’intergiciel plus adapté pour l’Internet a résolu des problèmes au niveau de l’exécution, mais n’a pas des avantages par rapport à ses prédécesseurs du point de vue de développement de logiciel. Ainsi, les services Web constituent un intergiciel de plus. Dans ce contexte, le génie logiciel doit fournir des solutions viables pour maîtriser la complexité de développement, de maintenance et d’évolution de systèmes logiciels. Récemment, l’OMG a proposé l’utilisation de modèles dans tout les cycles de vie de développement des systèmes. Les premières tentatives d’utiliser les modèles tels que OMT, Booch et UML ont fournis de résultats limités, suivant servaient pour la documentation initiale d’un système, puis ils étaient oubliés. Ainsi, une désynchronisation entre modèles et le code source était courrant. Maintenant, c’est différent. MDA démontre comment utiliser les modèles dans le cycle de vie de développement de logiciel. Dans cette approche, les modèles sont au centre de développement de logiciels de A à Z. [No] Complete the PSM [Yes] Code Generation, scripts, Deployment Files, etc (PSM to code) 22

<<boundary>> <<boundary> 3. MDA for Web Services WSDL metamodel EDOC-CCA metamodel WSDLElement Documentation Type Part Message Operation PortType Binding BindingOperation Port Service Definition +_targetNameSpace +name +types 0..1 +part 0..* +message +operation +portType +type +binding +boperations +port +service Package DataElement DataType Attribute <<boundary>> FlowPort <<boundary> ProtocolPort PortOwner ProcessComponent CompositeData +owner +feature 1..* OperationPort +ports 23

3. MDA for Web Services WSDL metamodel EDOC- CCA Mappings metamodel Package P2D WSDLElement Documentation +type Type DataElement De2T +types +types Part 0..1 DataType 0..* +part A2P Message +message CompositeData 0..* Operation +owner 1..* +feature F2M +operation 0..* Attribute PortType Definition +_targetNameSpace +name <<boundary>> FlowPort +type 0..* +portType 1..* O2O 0..* +binding +ports <<boundary>> Port Binding 0..* +boperations BindingOperation <<boundary>> OperationPort P2PB Port <<boundary> ProtocolPort 0..* +port PortOwner Pc2S Service +service 0..* ProcessComponent 24

 Service composition and orchestration: 3. MDA for Web Services  Service composition and orchestration: - From UML (Activity diagramm, V1.4) to BPEL problem: - semantic gap from UML to BPEL solution: - profiles and Tagged values Activity diagram Example: 25

3. MDA for Web Services  J2EE platform (Java + JWSDP) - Java Metamodel JWSDP Metamodel JWSDP template Mapping UML to JAVA  dotNET platform (C# + dotNET framework) - C# Metamodel dotNET Metamodel dotNET template Mapping UML to C# 26

4 . Prototyping: A Plug-in for Eclipse EDOC metamodel WSDL Mapping WSDLElement Documentation Type Part Message Operation PortType Binding BindingOperation Port Service Definition +_targetNameSpace +name +types 0..1 +part 0..* +message +operation +portType +type +binding +boperations +port +service ModelElement Namespace Package AssociationEnd Class Interface Attribute Method Parameter DataType +specification +method C2S P2Part O2O M2Bo Dt2T P2D A2T module UML2WSDL; create OUT : WSDL from IN : UML; rule C2S{ from c : UML!Class to s : WSDL!Service( name <- 'Service' + c.name, owner <- c.namespace, port <- pt ),*** } *** Specification of Mappings Transformation Definition 0..* 1 +spec ? Generated from [Time – 0:58] Précédemment, j’ai montré notre approche MDA appliqué à la plate-forme de services Web. La différence entre « Spécification de Correspondances » et « Définition de transformations » a été fréquemment illustré avec des exemples, ► comme celui: le métamodèle de UML à gauche, la correspondance au milieu et le métamodèle de WSDL. En fait, la correspondance est un modèle. Ainsi, la spécification de correspondance est une logique métier (c’est-à-dire, le métier de établir des relations entre les éléments de métamodèles), et la définition de transformation est un PSM (c’est-à-dire, la plate-forme qui va faire l’exécution de la logique métier). ► La question est comment créer un outil qui permet la création et l’édition d’un modèle de correspondance. Et, à partir de ce modèle de correspondance générer la « définition de  transformations ». 27

4 . Prototyping: A Plug-in for Eclipse A Metamodel for Mapping Specification 28

4 . Prototyping: A Plug-in for Eclipse Mapping Specification: MMT Tool from EDOC to WSDL 29

4 . Prototyping: A Plug-in for Eclipse  Transformation Process ATL (Atlas Transformation Language), OCL based and MOF/QVT compliant 30

4 . Prototyping: A Plug-in for Eclipse 31

5 . Conclusion & Perspectives UML (version 1.4) EDOC (profil UML) EDOC (métamodèle) WSDL normal complex** straightforward (almost) BPEL complex* - J2EE (Java + JWSDP) dotNET (C# + API) PIM PSM - EDOC versus UML - dot NET versus J2EE * Tagged values ** Profiles and stereotypes 32

-lessons from the past 5 . Conclusion & Perspectives Model Driven Architecture allows the development of services by describing their technology-independent and technology- specific aspects in separate models. EDOC (CCA) is closer to WSDL than the UML metamodel and seems more suitable for the modeling of internet applications implemented on Web Services Platforms. « MDA could be the best answer for the development of future Internet Applications on Web Services Platforms » -lessons from the past «  There are no (lasting) one-fits-all technology solutions, and therefore technologies will always differ and evolve »[OMG 05] 33

MDA and Ubiquitous computing (Weiser Vision 1991) Ubiquitous Computing: Weiser introduced the area of ubiquitous computing (ubicomp) and put forth a vision of people and environments augmented with computational resources that provide information and services when and where desired [Weiser 1991]. Ubiquitous Information Systems: The vision, where computers are everywhere and a person interacts (anytime and anywhere) with portable devices that are sensitive and responsive to him, has become a reality nowadays. [Satyanarayanan, 01]. 34

MDA and Ubiquitous computing Computer Systems Research Problems [Satyanarayanan, 01]. Context aware mobile applications 35

Context aware mobile applications  Many different definitions for context “Any information that can be used to characterize the situation of an entity. An entity is a person, place, or object that is considered relevant to the interaction between a user and an application, including the user and application themselves” [Dey 2001]  Context information are not universal but relative to some situation (application specific) Weather Holiday Planning 36

Context aware mobile applications  Context awareness “a system is context-aware if it uses context to provide relevant information and/or services to the user, where relevance depends on the user’s task”.  Four main features of CW applications: Contextual sensing Contextual adaptation Contextual resource discovery Contextual augmentation 37

Context aware mobile applications Conceptual Framework for Context aware systems [Badaulf, 07] A separation between detecting and using context is necessary to improve extensibility and reusability of systems.  From a collection of different sensors to context aware services 38

Context aware mobile services Provide relevant information/services to users using context information More friendly, adapted, and intelligent services restaurant finding service museum guide service road search service (maintained and considering road conditions in a real time ) Most promising technology for mobile services A context aware service is considered as a smart Web service defined as: "a web service that can understand situational context and can share that context with other services" [Manes, 01] 39

Context aware mobile services  Basic components in a Web service-based context-aware system. [Truong, 09] Context-aware services and applications: Supporting components for context-awareness: 40

MDA for context aware mobile service COMODE: Principle and architecture. Separation of concerns (business logic versus context) Development process Five views 41

MDA for context aware mobile service Development process 42

MDA for context aware mobile services Context view. Context metamodel (CM) ContextView ContextEntity Actor Environnement Time Location Climate MobileDevice Profile 1..* * uses captures belongsTo involves ComputationalEntity user centered mobile applications 43

MDA for context aware mobile services Context weaving and transformations Business Model (PIM) Context Model (CM) Contextual Platform Independant Model (CPIM) Contextual Platform Specific Model (CPSM) XML Web services concrete platform M O D E L S C O D E Parameterized transformation Classical transformation MDD Approach For Service Adaptability Main models & Main Transformation Techniques 44

MDA for context aware mobile services Context weaving and transformations A separation between context information and business logic in individual models, The integration of the context model into the business logic using suitable transformation techniques, The mapping of the contextualized business logic model into a web service platform. Two transformation techniques for context weaving: Model composition (Merging) Parametrized Transformation 45

Context weaving and transformation Source Metamodel Transformation Metamodel Target Metamodel Model composition Parametrized transformation CPSM Model context model input Transformation Model input PIM Model CPIM Model output 46

Context weaving and transformation Model composition: a signature based approach [Redhu 05] 47

Context weaving and transformation Parametrized transformation: [Frankel 02] Parametrized Transformations allow a designer to mark in the application model (PIM) the properties that will receive context information. These properties are the context_aware properties. 48

Conclusion and Perspectives COMODE (Context Aware Model Driven Development) advocates Model Driven Development to promote reuse, adaptability and interoperability for context-aware applications development on a service platform. Using model driven development, context models are built as independent pieces of application models and at different abstraction levels then attached by suitable transformation techniques. Parameterized transformation technique allows the binding of context information to a service at a model level, and therefore, allows specifying which behavior should be weaved at execution level. 49

Towards Adaptable SOA: Model Driven Development, Context and Aspect Slimane HAMMOUDI ESEO, Computer Science Department Angers, France slimane.hammoudi@eseo.fr Valérie MONFORT Université Paris 1 - Panthéon – Sorbonne Université Paris Dauphine LAMSADE CNRS, France valerie.monfort@univ-paris1.fr 50

Motivations (1): Technologies are in constant evolution and Companies are often changing their organisation Companies have to communicate with external Information Systems (IS) as clients, providers, partners using heterogeneous IS SOA driven by a global methodology, seems the best solution for Companies to : Limit impacts of changes in there IS - Provide interoperability between heterogeneous IS 51

Motivations (2): Web service appears as the simplest solution to integrate IS; Web services promote interoperability because they are based on XML standards: XML EVERYWHERE So, Web services seem to be the ideal solution for companies, The fitted technical solution used to support SOA. but ... 52

Problems met with Web services in SOA context  Code is monolithic mixing concerns Any change requires re deployment and is time consuming Not a full flexibility and poor adaptability Hence, SOA Applications are faced to some important limitations concerning their adaptability to Business requirements changes 53

Aspect Oriented Programming (1) AOP is a paradigm that enables the modularization of crosscutting concerns into single units called aspects; AOP allows to encapsulate the code of aspects into separate module –and then apply the code where it is needed. AOP allows adding new behavior to an application without touching the base source code 54

Aspect Oriented Programming (2) 55

Aspect Oriented Programming (3) Aspect-oriented languages are implemented over a set of definitions: Joinpoints : Pointcuts : Advices : Weaver merge aspect to base code 56

Aspect Service Weaver (1) 57

Conclusion of this technical research work In this first approach using AOP, a pragmatic solution for adaptable Web service was developed with server and client adaptability However, This technical solution is very complex for neophyte and requires to be a specialist : so one alternative would be to abstract technical complexity 58

MDA and context for adaptable services Context weaving and transformations Business Model (PIM) Context Model (CM) Contextual Platform Independant Model (CPIM) Contextual Platform Specific Model (CPSM) XML Web services concrete platform M O D E L S C O D E Parameterized transformation Classical transformation MDD Approach For Service Adaptability Main models & Main Transformation Techniques 59

Context_Aware MDD & Aspects as a new research direction  Key Points 60

Key Points Context modeling allows providing information and situation which intervene in the process of service adaptability. Using model driven development, context models are built as independent pieces of application models and at different abstraction levels then attached by suitable transformation techniques. Services are unaware of their context and the aspects adapt them to the current environment according to the current context. Context-dependant behaviors are extracted into aspects and weaved with the base service during execution. Parameterized transformation techniques allow binding context information to a service at a model level, and should help to determine which aspect should be weaved at execution level. 61

First Ideas Web Services Abstract Platform Business Model (PIM) Context Model (CM) Aspect Model (AM) Contextual Platform Independant Model (CPIM) XML Contextual Platform Specific Model (CPSM) Run-time repository CW Service mngt repository Web Services Abstract Platform Web Services Concrete Platform 62

Conclusion We are convinced MDD is the fitted solution to abstract the complexity of our aspect based solution. We have to clarify and formalize the process of « Aspect derivation » from a given context model. We have to take into account dynamic models, weaving and composition. We have to define models transformations and the fitted plate form to support our approach. 63

Towards a semi automatic transformation process in MDA: Slimane HAMMOUDI ESEO, Computer Science Department Angers, France slimane.hammoudi@eseo.fr Marianne Huchard Université de Montpellier II -LIRMM – France huchard@lirmm.fr 64

Motivations La Transformation de modèle dans MDA/MDE Ecriture manuelle des règles Maîtrise du langage de transfo et des métamodèles PIM et PSM Les techniques de “matching”. Les techniques sont matures et la recherche est très active: En Bases de Données  “schema matching” P. Bernstein & al. En Ontologies  “techniques d’alignement d’ontologies ” J.Euzenat & al. Vision très simplifiée d’un processus “Semi-automatic” Mapping = Matching + Adaptation  «Sur les métamodèles » Transformation = Mapping + Dérivation  «Génération des règles de transfos» PSM = PIM + Transformation  «Exécution des règles de transfos» 65

Sommaire Processus de Transformation dans MDA Concepts clés et principaux problèmes Une extension à l’architecture de base du processus Une 1ère Extension: Mapping Versus Transformation Découverte des mappings: “techniques de matching” Une 2ème Extension: Matching, Mapping et Transformation Méthodologie pour un processus semi-automatique Les acteurs Processus de transformation: les différentes activités Activités et acteurs Adaptation et Dérivation Prototypage Conclusion & Travaux en cours 66

Processus de Transformation dans MDA MOF ConformsTo ConformsTo ConformsTo Source Transformation Metamodel (ATL,…etc.) Target M2 Metamodel Metamodel ConformsTo to ConformsTo from ConformsTo P I M Source Transformation Target P S M M1 Model Model (Program) Model exec source Transformation Transformation engine target M0 Engine 67

Une 1ère extension à l’architecture de base  Mapping versus Transformation [Lopes 2005]  En IDM 68

Une 1ère extension à l’ architecture de base  Mapping versus Transformation dans l’IDM Les mappings  spécification Définis entre métamodèles Spécifiés « idéalement » de manière déclarative (graphiquement) Un langage type OCL pour exprimer et compléter des mappings complexes Peuvent être découverts par un processus de matching Les transformations  implémentation Les règles sont générés automatiquement à partir des mappings Sont conformes à un métamodèle de transformation type MOF/QVT Exécutés à partir d’un modèle source PIM pour produire un modèle équivalent cible PSM. Rule C2T { from Class: UML!Class to Table: Oracle!Table ( name  Class.name …………………………………… ) class table c2t 69

Une 2ème extension à l’ architecture de base  Découverte des mappings : « les techniques de matching » produce Mapping derive Matching Transformation update/adapt Approche Limites Real Matches Derived Matches Schema matching DBWare Ontology matching ontoWare B A C structural semantic D A = True Positives B = False Negatives C = False Positives D = True Negatives Metamodel matching modelWare 70

Une 2ème extension à l’architecture de base  Trois métamodèles: Le métamodèle de matching: techniques et algorithmes de matching Le métamodèle de mapping: formalisme de spécification des correspondances Le métamodèle de transformation: syntaxe abstraite du langage de transfo (QVT) 71

Méthodologie pour un processus semi automatique  Principaux utilisateurs (Gavras, 2004) Knowledge builders: build knowledge repositories 2 types d’utilisateurs 1) expert Versus 2) concepteur Platform Quality Methodology Architects experts engineers experts Knowledge facilitators: assemble, combine and deploy knowledge Project manager Quality engineers Knowledge users: apply knowledge Designers Software engineers 1) Gestion des métamodèles et des règles de transformations 2) Gestion des modèles métiers et transformation sur plateforme cible 72

Méthodologie pour un processus semi-automatique  Processus de transformation 1) Phase de préparation (l’Expert) Définition du métamodèle PIM métier de l’entreprise à partir des standards de MDA tels qu’UML ou EDOC (ou des profils).  PIM metamodel specification Définition du métamodèle de la plateforme cible d’exécution PSM. Celui-ci est spécifié dans le même formalisme que le PIM,  PSM metamodel specification Activité cruciale qui vise à sélectionner les algorithmes de matching appropriés afin de générer des mappings  Apply the matching techniques L’expert valide ou modifie les mappings obtenus, il spécifie éventuellement des mappings que les techniques de matching n’ont pas pu déterminer.  Adapt and validate mappings Génération automatique des règles de transformations à partir des mappings. Ces règles sont spécifiées conformément au standard MOF2.0-QVT de l’OMG.  Generation of transformation rules Transformation program 73

Méthodologie pour un processus semi-automatique  Processus de transformation 1) Phase d’Exécution (Concepteur) Edition, vérification et complétion du PSM    Executable Model Y Complete PSM N [PSM is complete] le programme de transformation obtenu dans la 1ère partie prend en entrée le modèle PIM et produit un PSM équivalent.  Edition of a PSM Model Transformation program Execution Conformément au métamodèle PIM, un concepteur définit le modèle métier indépendant de toute plate-forme technique.  Specification of a PIM Model 74

Méthodologie pour un processus semi-automatique  Activités et utilisateurs Exécution Utilisateurs Métamodèles PIM & PSM manuel (éditeur graphique) utilisateur-expert Techniques de Matching automatique programme de matching (utilisateur-expert) Validation/Mise à jour des mappings Génération de règles de Transformation programme de génération (utilisateur-expert) Modèle PIM utilisateur-concepteur Exécution des règles de Transformation programme de transformation (utilisateur-concepteur) PSM Final manuel (éditeur de texte) 75

Adaptation & Dérivation l’ utilisateur expert doit : valider les mappings considérés comme corrects corriger éventuellement les mappings incorrects spécifier les mappings non trouvés  Dérivation On devrait être capable de : générer automatiquement des règles de transformation à partir des mappings complétés Exprimer la sémantique des mappings en utilisant le langage OCL. 76

Prototypage: MT4MDE MT4MDE: UML and C# metamodel (fragment) 77

Prototypage MT4MDE: validation process for matched elements 78

Prototypage UML-C# UML-Java UML-WSDL Schema similarity Precision 0.74 0.84 Precision 0.71 0.86 1.0 Recall 0.68 0.62 F-Measure 0.69 0.76 Overall 0.40 0.57 [Hammoudi, 2010] 79

Conclusion Aujourd'hui, les règles de transformation sont spécifiées manuellement: Travail fastidieux et enclin aux erreurs (coût en terme d’efficacité) Bonne maîtrise du langage de transformation Bonne connaissance des métamodèles Spécification des correspondances entre les métamodèles. La semi-automatisation: une première approche Une architecture intégrant le Matching et Mapping (entités de 1er Classe) Une méthodologie permet d’identifier les activités ainsi que les acteurs: activités automatisables et manuelles experts et concepteurs Les acteurs et leurs activités La semi-automatisation: Vrai défi Algorithmes de matching pour les métamodèles Formalisme adéquat pour le mapping et processus de validation Génération automatique des règles de transformation 80