1 / 42

MDA en action Ingénierie logicielle guidée par les modèles

MDA en action Ingénierie logicielle guidée par les modèles. Xavier Blanc Université Pierre et Marie Curie Xavier.Blanc@lip6.fr. Plan. MDA: Model Driven Architecture Pérennité des savoir-faire Architecture de métamodélisation UML, OCL, AS XMI Gains de productivité JMI & EMF

vega
Download Presentation

MDA en action Ingénierie logicielle guidée par les modèles

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. MDA en actionIngénierie logicielle guidée par les modèles Xavier Blanc Université Pierre et Marie Curie Xavier.Blanc@lip6.fr

  2. Plan • MDA: Model Driven Architecture • Pérennité des savoir-faire • Architecture de métamodélisation • UML, OCL, AS • XMI • Gains de productivité • JMI & EMF • Transformation de modèles • Outils • Prise en compte des plates-formes d’exécution • Profils de plate-forme • Métamodèle de plate-forme • Etude de Cas: PetStore

  3. MDA: Model Driven Architecture Vue macroscopique

  4. Modèles Architecture MDA • « Modéliser est le futur, et je pense que les sociétés qui travaillent dans ce domaine ont raison »  B. Gates • « Obtenir du code à partir d’un modèle stable est une capacité qui s’inscrit dans la durée » R. Soley • « A quoi bon modéliser puisque in fine il faudra toujours écrire du code? » • « Un bon schéma vaut mieux qu’un long discours … sauf qu’à un schéma (UML) correspond plus d’un long discours ! » Besoin de bonnes pratiques et d’objectifs précis

  5. Pratiques & Objectifs Architecture MDA Pratiques • Décomposer en niveaux d’abstraction • Automatiser les relations inter/intra niveaux • Formaliser les informations contenues dans les niveaux Objectifs • Élaboration de nouvelles applications • Évolution d’applications existantes • Maîtriser l’impact des nouvelles technologies

  6. Modèle d’exigences: représente l’application dans son environnement. Modèle d’analyse et de conception abstraite: représente l’architecture de l’application. Modèle de code: représente la construction de l’application. Code de l’application et fichier de configuration. L’approche Architecture MDA

  7. Code CIM PIM PSM Architecture Architecture MDA MOF M2 QVT M2 Application Informatique

  8. Les moyens Architecture MDA • Définition de tous les métamodèles de manière uniforme • Le standard MOF définit le langage de définition des métamodèles • Format standard d’import et d’export des modèles • Le standard XMI définit les moyens d’import et d’export de tous les modèles selon le format XML • Langage de manipulation des modèles • Les frameworks JMI/EMF définissent les moyens de représentation des modèles à l’aide de langages de programmation objet. • Langage dédié au transformation de modèles • Le standard QVT définit le langage d’expression de transformations de modèles

  9. Les résultats Architecture MDA • Pérennité des savoir-faire • L’ambition du MDA est de faire en sorte que les modèles (CIM, PIM) aient une durée de vie supérieure au code. • L’objectif est donc de fournir des langages de modélisation supportant différents niveaux d’abstraction. • Gains de productivité • MDA vise à apporter des gains de productivité en automatisant les opérations sur les modèles. • L’objectif est donc de faciliter la création d’opérations de production sur les modèles (du contemplatif au productif) • Prise en compte des plates-formes d’exécution • MDA veut rendre explicite la prise en compte des plates-formes d’exécution dans le cycle de vie des applications. • L’objectif est donc de construire des langages permettant de modéliser les plates-formes et de lier ces modèles aux modèles des applications.

  10. Les 3 axes du MDA Architecture MDA pérennité • Pour mettre en œuvre le MDA il faut fixer ses priorités selon ces trois axes • Il est actuellement trop tôt pour utiliser UML2.0 et être productif. • Il est actuellement trop tôt pour pouvoir dire que EMF est pérenne. • Il est actuellement trop tôt pour pouvoir expliciter la plate-forme sous forme de modèle. UML2.0 QVT MOF2.0 XMI2.1 GenDoc Profil QoS UML1.4 MOF1.4 EMF Profil EJB JMI Profil Corba productivité UML->Java UML/EJB->J2EE Plate-forme

  11. Pérennité des savoir-faire Architecture et Standard

  12. Métamodèle Pérennité Un métamodèle est essentiellement la définition d’un ensemble de concepts et de leurs relations à l’aide d’un diagramme de classes. Un métamodèle ne définit que la structure et pas la sémantique. Un modèle est une instance d’un métamodèle s’il respecte la structuration définie par le métamodèle. Le métamodèle UML définit les concepts UML et leurs relations. Un modèle UML doit respecter la définition du métamodèle.

  13. Le MOF définit le langage permettant de définir des métamodèles Les concepts du MOF sont les concepts de métaclasse, méta-attribut, méta-association, etc. MOF peut être défini à l’aide d’un diagramme de classe. Ce diagramme est le métamétamodèle Le métamétamodèle s’auto-définit. Métamétamodèle Pérennité

  14. Les relations entre les niveaux méta sont des relations de définition de structure Les relations entre les niveaux méta ne sont pas des relations d’abstraction. Les relations entre les niveaux méta sont semblables aux relations entre les grammaires (BNF, ou XML Schema) MOF UML Modèle Modèle Modèle UML UML Niveaux Méta Pérennité Métamétamodèle Métamodèle Modèle

  15. UML définit les concepts nécessaires à l’expression des diagrammes de classe MOF définit les concepts nécessaires à l’expression des diagrammes de classe => Capitaliser sur les concepts nécessaires à l’expression des diagrammes de classe : Infrastructure MOF Infra UML Infrastructure 2.0 Pérennité L’infrastructure n’a pas de niveau fixe. Cela dépend de qui l’utilise.

  16. UML2.0 Pérennité • UML2.0 fait rentrer UML dans MDA, il est bien plus qu’une évolution de UML1.4. • UML est actuellement le métamodèle le plus important de l’approche MDA. Sa conception est le fruit de plus de 3 ans de travail collaboratif des meilleurs experts du domaine. • C’est le métamodèle qui définit la structuration des modèles des applications informatiques • UML2.0 est un métamodèle instance de MOF2.0. • La sémantique de UML2.0 est définie à l’aide de langage naturel • Les diagrammes UML2.0 sont définis à partir du métamodèle • UML2.0 supporte différents niveaux d’abstractions et différents points de vue • Cas d’utilisation, Séquences, Structuration Interne, Etats, Déploiement, etc.

  17. Composant UML2.0 Pérennité UML2.0 permet la modélisation intégrale d’applications à base de composants. De l’analyse/conception au déploiement

  18. UML dans MDA Pérennité • UML permet principalement de construire des modèles d’applications informatiques indépendants des plates-formes d’exécution (phase d’analyse et de conception abstraite) • UML est donc le métamodèle naturel pour les PIM (Platform Independant Model) • UML permet aussi de représenter une application dans son environnement afin d’en faire ressortir les exigences (cas d’utilisation) • UML peut être utilisé pour les CIM (Computational Independant Model) • UML peut être profilé afin de cibler des plates-formes d’exécution (ex: profil pour CORBA, profil pour EJB) • UML peut être utilisé pour les PSM (Platform Specific Model) Il serait donc possible d’appliquer MDA en utilisant uniquement UML

  19. PropertyCallExp > Literal -1000 ModelPropertyCall solde Object Constraint Language Pérennité • OCL définit la structuration des modèles représentant des contraintes sur les applications informatiques • Invariant, Pré-post conditions • OCL est un métamodèle instance de MOF • OCL est fortement couplé au métamodèle UML • OCL définit sa sémantique à l’aide d’un métamodèle (opération sans effet de bord) • OCL définit une syntaxe concrète permettant de facilement saisir les contraintes

  20. Action Semantics Pérennité • AS définit la structuration des modèles représentant des séquences d’instructions • AS est un métamodèle qui a été totalement intégré à UML2.0 • AS n’a pas de syntaxe concrète propre (utilisation des diagrammes dynamiques UML) • La sémantique d’AS n’est pas formellement définie (RFP en cours)

  21. XMI Pérennité Fonctionnement • Le standard XMI (XML Metadata Interchange) permet le passage des modèles aux documents XML • Il définit des règles permettant de construire des schéma XML à partir de métamodèle • Ainsi il est possible d’encoder un modèle dans un document XML XMI et UML • XMI se décline en 6 versions et UML se décline en 4 versions • Cela explique pourquoi l’échange de modèle UML en XMI pose quelques problèmes XMI et diagrammes • DI (Diagram Interchange) est une extension à XMI et UML qui permet la représentation des diagrammes UML sous forme de document XML.

  22. Synthèse sur la pérennité Pérennité • MOF permet de décrire les métamodèles uniformément • Permet la définitions de structuration et leur standardisation (ex: réseaux de Petri) • Le métamodèle UML est le métamodèle le plus abouti pour élaborer des modèles d’applications informatiques • Les modèles UML sont de très bons PIM (complets et indépendants des plates-formes). • OCL et AS sont les métamodèles permettant la définition précise de comportements • Ils permettent la construction de modèles UML très précis. • XMI permet l’échange de n’importe quel modèle sous forme de document XML • Les modèles MDA ont tous une représentation concrète standard

  23. Gains de productivité Framework et outils

  24. API de manipulation Production • MDA définit les principes de génération d’API de manipulation de modèles • A chaque métamodèle correspond une API de manipulation des modèles instances • Les frameworks définissent aussi des API réflectives pour tout métamodèle Métamodèle Interface Java Objets Java modèles

  25. Élaboration d’un métamodèle (instance de Ecore) Génération de l’API Interface de manipulation Classes dans l’environnement Eclipse Classes d’éditeur graphique Utilisation directe dans un nouveau environnement Eclipse Eclipse Modeling Framework Production

  26. Transformation de modèles Production • Les transformations de modèles sont le cœur des aspects de production de MDA • CIM vers PIM, PIM vers PSM, PSM vers code (sens inverse). • Les transformations de modèles sont basées sur les métamodèles • Tout composant UML se transforme en une classe PHP. • Les constructeurs de plate-forme devraient produire les transformateurs permettant d’exploiter les plates-formes • UML vers EJB • Les sociétés devraient pouvoir adapter les transformateurs selon leurs propres expériences et leurs propres besoins • Ex: ne pas utiliser de composant EJB Entity! • Actuellement les transformations de modèles peuvent s’écrire selon trois approches • Programmation, Template, Modélisation

  27. PetStore PetStore PHP UML PHP Programmation Production • La transformation est un programme qui utilise les API de manipulation des modèles APIUML APIPHP écrire lire ProgrammeJava

  28. PetStore PetStore PHP UML PHP Template Production • La transformation est un template écrit dans un langage dédié Template pour UML vers PHP Interpréteurde template

  29. PetStore PetStore PHP UML PHP QVT Modélisation Production • La transformation est un modèle instance du métamodèle QVT Modèle Transfo Programme

  30. Outils industriels Production • Actuellement plusieurs outils clament leur adhérence à MDA. • Au déla de savoir ce qu’est un outil MDA, il est intéressant de voir que les fournisseurs d’outils sont très actifs sur ce domaine. • Nous avons particulièrement pu apprécier deux outils: • RSA (Rational Software Architecte) qui supporte MDA en offrant un modeleur UML2.0 et en permettant la définition de transformations de modèles (approche par programmation). • Objecteering/MDA Modeler qui supporte MDA en offrant des avantages considérables pour le développement et le packaging d’opérations de production sur les modèles.

  31. Synthèse sur la productivité Production • MDA fait passer les modèles du contemplatif au productif • Les API de manipulation de modèles sont totalement utilisables en contexte industriel • Les transformations de modèles sont réalisables même si actuellement seule l’approche par programmation est pleinement exploitable. • Il est important de souligner l’engagement des éditeurs d’outils

  32. Prise en compte des plates-formes d’exécution Framework et outils

  33. PIM PIM PIM PSM PSM PM PM Cycle en Y et plate-forme Plate-forme Besoins Techniques Exigence Analyse Architecture Technique Conception (Abstraite) Explicitation de la plate-forme Conception (concrète) Prise en compte de la plate-forme Conception (fine) Code

  34. Profil ou métamodèle Plate-forme • Il n’existe pas de métamodèle permettant de modéliser les plates-formes • Un métamodèle de plate-forme définit plutôt la structure de modèles d’applications utilisant les fonctionnalités de la plate-forme • On appelle donc ces métamodèles des métamodèles de PSM • par exemple le métamodèle EJB définit la structure de modèles d’applications utilisant les fonctionnalités de la plate-forme EJB • La transformation cœur de l’approche en Y est donc une transformation entre deux métamodèles (métamodèle du PIM vers métamodèle du PSM) • D’où la nécessité de paramétrer le modèle PIM afin de préciser la façon dont utiliser la plate-forme (notion de modèle intermédiaire). • Comment savoir si un composant UML doit se transformer en un bean Entity ou Session?

  35. Métamodèle de PSM Plate-forme • Approche par profil • Le métamodèle de PSM est un profil UML • La plate-forme doit donc être proche de UML (orientée objet) • Les transformations PIM vers PSM sont facilitées car il existe une sémantique commune (UML) • Approche par métamodèle • Le métamodèle de PSM est un métamodèle MOF • La plate-forme peut donc être très éloignée de UML • Les transformations PIM vers PSM sont moins facilitées car les sémantiques PIM et PSM ne sont pas communes • Cette approche rend possible les transformations PSM vers PSM (migration de plates-formes)

  36. Étude de Cas PetStore

  37. PetStore selon MDA Étude de Cas CIM & PIM en UML Intervention Humaine Modèle de transformation PIM vers PSM PSM JavaProfil UML PSM PHP Méta-modèle PIM vers PSM Java avec MDA Modeler PIM vers PSM PHP avec RSA public class { } php { }

  38. Pérennité Étude de Cas • L’application PetStore a pu être modélisée entièrement en UML2.0 • Use Case de l’application • Composants de l’application • Contrainte OCL sur les opérations (notamment les opérations de recherche) • AS pour le comportement (notamment grâce aux nouveaux diagrammes de séquences) • Modèle entièrement indépendant des plates-formes d’exécution • Modèle échangeable(?) grâce à XMI

  39. Productivité Étude de Cas • Le modèle UML de l’application PetStore a pu être manipulé automatiquement pour générer du code et de la documentation • RSA: Manipulation Java avec assistants • MDA Modeler: Manipulation J avec assistants • Malheureusement, il n’est pas encore possible de pouvoir capitaliser les opérations de production

  40. Plate-forme Étude de Cas • Réalisation de PetStore sur J2EE/EJB • Définition du profil EJB • Construction des transformations avec MDA Modeler • Définition d’un profil de modèles intermédiaires permettant de préciser les choix de transformation • Réalisation de PetStore sur PHP • Définition d’un métamodèle PHP • Construction de générateur de code et de transformation de modèles avec RSA • Définition d’un profil de modèles intermédiaires permettant de préciser les choix de transformation

  41. Conclusion

  42. MDA entre dans une phase d’industrialisation La pérennité est aujourd’hui totalement atteinte grâce aux standards MOF, UML, OCL, AS et XMI La productivité des modèles est une réalité. Les progrès annoncés laissent entrevoir un essor considérable (MOF2.0 QVT) La prise en compte des plates-formes reste encore trop à la charge de celui qui met en place l’approche MDA MDA en action

More Related