La présentation est en train de télécharger. S'il vous plaît, attendez

La présentation est en train de télécharger. S'il vous plaît, attendez

Study and application of Model Driven Development Approach From Web services to Ubiquitous computing Slimane Hammoudi ESEO Angers, France

Présentations similaires


Présentation au sujet: "Study and application of Model Driven Development Approach From Web services to Ubiquitous computing Slimane Hammoudi ESEO Angers, France"— Transcription de la présentation:

1 Study and application of Model Driven Development Approach From Web services to Ubiquitous computing Slimane Hammoudi ESEO Angers, France 1

2 1.Introduction: Web Services, MDA and MDE 2.Transformation process: mapping versus transformation 3.MDA for Web services 4.Conclusion on MDA for Web services 5.Ubiquitous computing and context–aware services (CWS) 6.Context and context-awareness 7. Conceptual architecture for CWS 8. MDA for CWS 9.Transformation process: merging versus parameterization 10. Conclusion on MDA for CWS 11. Towards adaptable SOA : MDD, context and aspects 12. Towards a semi automatic transformation process in MDD Contents 2

3 Network Travel Agency Airlines RentCar Hotel Client - Interoperability on Internet ? - One Unique Middleware? ? ? ? ? ? ? ? Internet/ Intranet XML-RPC DCOM/COM+ CORBA-IIOP EDI-standards CORBA-IIOP DCOM/COM+ HTTP/HTML CGI RPC Java RMI EDI-standards CORBA-IIOP DCOM/COM+ Before the Web Middleware « Era » Web Services ! Standard (XML, SOAP, WSDL et UDDI ) W3C, OASIS 1. Introduction Web Services for E-Applications (B2B, B2C,…etc). 3

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

5 1. Introduction:Web Services 5

6 1. Introduction: Model Driven Architecture 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" Bézivin, Guest Talk, UML03 6

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

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

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

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

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

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

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

14 The Metamodelling Stack & Main Technologies Peugeot H-1234 UML Class MOF Class representedBy conformsTo M0: Objects/Data ID: string Type: string Car conformsTo Introduction : Model Driven Architecture M1 M2 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

15 MOF Transformation Metamodel (ATL,…etc.) Target Metamodel Transformation Model (Program) Source Model Target Model Transformation Engine Source Metamodel ConformsTo exec sourcetarget ConformsTo Transformation : The Heart of MDA M1 M2 M3 M0 ConformsTo from to PIMPIM PSMPSM Transformation engine 1. Introduction : Transformation in MDA 15

16 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 MappingMapping rule Mapping function MDA EXPLAINED Transfo.Mappi/Transf ruleTransfo. definition Transfo tool QVT DSTC «Tracking» Transfo. rule Transfo.TransfoModelTransf. engine QVT Partners Transfo. Relation Mapping Relation [Judso &al 03] Transfo.Transfo. Pattern [Caplat 03] MappingModel of Mapping Mapping formalism [Peltier 03] Transfo Process Transfo descr « The concept of Transformation is not so clear, since this term can refer to many different concepts » [ Favre, UML 04] 1. Introduction : Transformation in MDA 16

17 2. Mapping Versus Transformation in MDA 17 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.

18 Mapping versus Transformation [Lopes 2005] In MDA, MDE 2. Mapping Versus Transformation in MDA 18 Mapping Specification Transformation Definition +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 metamodel Mapping Me source target Mapping Element composition

19 A Graphical formalism for Mappings 2. Mapping Versus Transformation in MDA 19

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

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

22 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 Complete the PSM Code Generation, scripts, Deployment Files, etc (PSM to code) [PSM is complete] [Yes] [No] Methodology UML(EDOC) Web Services 3. MDA for Web Services 22

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

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

25 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

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

27 Specification of Mappings Transformation Definition 0..* 1 +spec Generated from EDOC metamodel WSDL metamodel Mapping WSDLElementDocumentation Type Part Message Operation PortType Binding BindingOperation Port Service Definition +_targetNameSpace +name +types types +part 0..* +message 0..* +operation0..* +portType0..* +type +binding 0..* +boperations 0..* +port 0..* +service 0..* ModelElement Namespace Package AssociationEnd Class Interface Attribute Operation Method Parameter DataType +specification +method ModelElement Namespace Package AssociationEnd Class Interface Attribute Operation 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 ),*** } *** 4. Prototyping: A Plug-in for Eclipse 27

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

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

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

31 4. Prototyping: A Plug-in for Eclipse 31

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

33 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] 5. Conclusion & Perspectives 33

34 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

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

36 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 Context aware mobile applications 36

37 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 users task. Four main features of CW applications: Contextual sensing Contextual adaptation Contextual resource discovery Contextual augmentation 37

38 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

39 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 Context aware 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

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

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

42 MDA for context aware mobile service Development process 42

43 MDA for context aware mobile services Context view. Context metamodel (CM) 43

44 Business Model (PIM) Context Model (CM) Contextual Platform Independant Model (CPIM) Contextual Platform Specific Model (CPSM) XML Web services concrete platform MODELSMODELS CODECODE 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

45 MDA for context aware mobile services 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

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

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

48 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. Context weaving and transformation Parametrized transformation: [Frankel 02] 48

49 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

50 Towards Adaptable SOA: Model Driven Development, Context and Aspect Slimane HAMMOUDI ESEO, Computer Science Department Angers, France Valérie MONFORT Université Paris 1 - Panthéon – Sorbonne Université Paris Dauphine LAMSADE CNRS, France 50

51 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 Motivations (1): 51

52 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... Motivations (2): 52

53 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 Problems met with Web services in SOA context 53

54 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 Aspect Oriented Programming (1) 54

55 Aspect Oriented Programming (2) 55

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

57 Aspect Service Weaver (1) 57

58 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 Conclusion of this technical research work 58

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

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

61 61 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. Key Points

62 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 Concrete Platform Web Services Abstract Platform First Ideas 62

63 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. Conclusion 63

64 Towards a semi automatic transformation process in MDA: Slimane HAMMOUDI ESEO, Computer Science Department Angers, France Marianne Huchard Université de Montpellier II -LIRMM – France 64

65 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 dalignement dontologies J.Euzenat & al. Vision très simplifiée dun processus Semi-automatic 1.Mapping = Matching + Adaptation «Sur les métamodèles » 2.Transformation = Mapping + Dérivation « Génération des règles de transfos» 3. PSM = PIM + Transformation «Exécution des règles de transfos» 65

66 Sommaire Processus de Transformation dans MDA Concepts clés et principaux problèmes Une extension à larchitecture 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

67 Processus de Transformation dans MDA MOF Transformation Metamodel (ATL,…etc.) Target Metamodel Transformation Model (Program) Source Model Target Model Transformation Engine Source Metamodel ConformsTo exec sourcetarget ConformsTo M1 M2 M3 M0 ConformsTo from to PIMPIM PSMPSM Transformation engine 67

68 Une 1 ère extension à larchitecture de base Mapping versus Transformation [Lopes 2005] En IDM 68

69 Une 1ère extension à l architecture de base Mapping versus Transformation dans lIDM 1. 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 2.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 dun modèle source PIM pour produire un modèle équivalent cible PSM. classtable c2t Rule C2T { from Class: UML!Class to Table: Oracle!Table ( name Class.name …………………………………… ) 69

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

71 Une 2 ème extension à larchitecture 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

72 Méthodologie pour un processus semi automatique Principaux utilisateurs Knowledge builders: build knowledge repositories Knowledge facilitators: assemble, combine and deploy knowledge Knowledge users: apply knowledge Architects Platform experts Quality engineers Methodology experts Project manager Quality engineers Designers Software engineers (Gavras, 2004) 2 types dutilisateurs 1) expert Versus 2) concepteur 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

73 Méthodologie pour un processus semi-automatique Processus de transformation 1) Phase de préparation (lExpert) PIM metamodel specification PSM metamodel specification Apply the matching techniques Adapt and validate mappings Generation of transformation rules Transformation program Définition du métamodèle PIM métier de lentreprise à partir des standards de MDA tels quUML ou EDOC (ou des profils). Définition du métamodèle de la plateforme cible dexécution PSM. Celui-ci est spécifié dans le même formalisme que le PIM, Activité cruciale qui vise à sélectionner les algorithmes de matching appropriés afin de générer des mappings Lexpert valide ou modifie les mappings obtenus, il spécifie éventuellement des mappings que les techniques de matching nont pas pu déterminer. 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 lOMG. 73

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

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

76 Adaptation & Dérivation 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 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

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

78 Prototypage MT4MDE: validation process for matched elements 78

79 Prototypage UML-C#UML-JavaUML-WSDL Schema similarity Precision Recall F-Measure Overall [Hammoudi, 2010] 79

80 Conclusion - La semi-automatisation: une première approche Une architecture intégrant le Matching et Mapping (entités de 1 er Classe) Une méthodologie permet didentifier les activités ainsi que les acteurs: activités automatisables et manuelles experts et concepteurs Les acteurs et leurs activités - Aujourd'hui, les règles de transformation sont spécifiées manuellement: Travail fastidieux et enclin aux erreurs (coût en terme defficacité) 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: 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


Télécharger ppt "Study and application of Model Driven Development Approach From Web services to Ubiquitous computing Slimane Hammoudi ESEO Angers, France"

Présentations similaires


Annonces Google