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

Présentation au sujet: "MDA en action Ingénierie logicielle guidée par les modèles"— Transcription de la présentation:

1 MDA en action Ingénierie logicielle guidée par les modèles
Xavier Blanc Université Pierre et Marie Curie

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 Besoin de bonnes pratiques et d’objectifs précis
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 Pratiques Décomposer en niveaux d’abstraction
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 L’approche Architecture MDA
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.

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

8 Les moyens Définition de tous les métamodèles de manière uniforme
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 Pérennité des savoir-faire Gains de productivité
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 Métamétamodèle Pérennité 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.

14 Niveaux Méta Pérennité MOF 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) Métamétamodèle UML UML UML Métamodèle Modèle Modèle Modèle Modèle

15 Infrastructure 2.0 Pérennité 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 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 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 PropertyCallExp > Literal -1000 ModelPropertyCall solde

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é
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 Eclipse Modeling Framework
Production É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

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 Programmation Production La transformation est un programme qui utilise les API de manipulation des modèles UML PHP API UML API PHP lire écrire PetStore PetStore PHP Programme Java

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

29 Modélisation Production La transformation est un modèle instance du métamodèle QVT UML QVT PHP Modèle Transfo PetStore PetStore PHP 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 Cycle en Y et plate-forme
PIM PM Besoins Techniques Exigence PIM Analyse PM Architecture Technique PIM Conception (Abstraite) Explicitation de la plate-forme PSM Conception (concrète) Prise en compte de la plate-forme PSM 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 Approche par profil Approche par métamodèle
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 PIM vers PSM Java avec MDA Modeler
CIM & PIM en UML Intervention Humaine Modèle de transformation PIM vers PSM PSM Java Profil 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 Réalisation de PetStore sur J2EE/EJB
É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

41 Conclusion

42 MDA en action 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