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

IDM & Passage à lEchelle Xavier Blanc Université Pierre & Marie Curie.

Présentations similaires


Présentation au sujet: "IDM & Passage à lEchelle Xavier Blanc Université Pierre & Marie Curie."— Transcription de la présentation:

1 IDM & Passage à lEchelle Xavier Blanc Université Pierre & Marie Curie

2 RAPPELS CIM, PIM, PSM, Méta-modèle, modèle, etc.

3 Lapproche Architecture MDA Modèle dexigences: représente lapplication dans son environnement. Modèle danalyse et de conception abstraite: représente larchitecture de lapplication. Modèle de code: représente la construction de lapplication. Code de lapplication et fichier de configuration.

4 Architecture Architecture MDA CIMPIMPSM Code Application Informatique MOF M2QVT M2

5 Modèle = Graphe Typé

6 FORMALISATION & ILLUSTRATION Formalisation simple mais précise

7 Principes LIDM consiste à utiliser les modèles dans toutes les taches du cycle de vie dun système informatique (ex: exigence, conception, production) Dans lIDM, le processus contrôlant le cycle de vie est lui-même un modèle ! Grâce au support des modèles, lobjectif est dautomatiser massivement les taches pouvant lêtre

8 Méta-modèle de processus Objectifs: Standard, Expressivité, Formalisation, Exécutabilité Références : SPEM (OMG), LittleJil (Osterweil), UML4SPM (Bendraou)

9 Un modèle de processus Objectif: Capitalisation des savoirs-faires, Suivi du processus Références: Sommerville, SWEBOOK, CMMI

10 Un méta-modèle dexigence Objectif: Formalisation Référence: Doors?

11 Un modèle dexigences Objectif: Tracabilité IdNamePriorityParent 1Système de gestion des notes des étudiantsSevère1 2Les étudiants peuvent obtenir leurs notesHaute1 3Les enseignants peuvent saisir les notes des étudiants Haute1 4Les responsable dUE peuvent ajouter des contrôles Haute1

12 Un méta-modèle de design Objectif: Standard, Formaliser, Vérification, Automatisation. Références: UML, ….

13 Un modèle de Design Objectifs: Communication, Vérification, Guider la production Références: Gamma, Larman,

14 Un méta-modèle de production Objectifs: ?, tracabilité Références: ? Remarque: La grammaire Java nest pas suffisante, il faut prendre en compte les artefacts de déploiement

15 Synthèse Même si en théorie il est possible de définir un méta-modèle pour chaque activité et même un méta-modèle pour le processus, en pratique cela savère très complexe Considérons que nous sommes un monde idéal nous disposons donc Dun processus modélisé Des méta-modèles de tous les modèles à construire Des automatisations exploitables (vérification, génération)

16 DÉROULEMENT DUN PROCESSUS

17 Gestion du contrôle Chaque développeur a ses responsabilités. Il doit intervenir à un certain moment pour réaliser son activité. => Comment réguler et organiser (contrôler) les différents travaux que peuvent/doivent effectuer les développeurs – Comment gérer les actions de chaque développeur ? – Comment assurer la synchronisation de léquipe? => Ces problèmes sont-ils propres à lIDM ?

18 Gestion des données Chaque tache dispose de modèles en entrée et en sortie, ces modèles font partie du modèle global Chaque développeur durant la réalisation dune tache va lire des modèles et/ou les modifier => Comment assurer laccès aux modèles? => Comment garantir lintégrité des modèles?

19 Environnement de développement Réparti Dynamique Hétérogène Mr Exigence Mme Design Mr Code

20 Un peu de concret 1.Mr Exigence veut construire son modèle dexigences et prévenir Mme Design. Le modèle dexigence peut être validé (pas dexigences contradictoires). 2.Mme Design veut lire le modèle dexigences et construire son modèle de design. Le modèle de design doit couvrir toutes les exigences. 3.Mr Exigence veut rajouter une exigence et modifier une exigence qui existait, puis il veut informer Mme Design 4.Mr Code veut lire le modèle de design et construire son modèle de code. 5.…

21 Un peu de concret (2 ème lecture) 1.Tant que Mr Exigence na pas terminé, Mme Design na pas le droit de lire le modèle dexigence. Lopération de vérification dun modèle dexigence est automatisée. 2.Mr Exigence na pas le droit de modifier son modèle pendant que Mme Design travaille. Mme Design doit pouvoir vérifier que son modèle couvre bien toutes les exigences (opération automatisée). 3.Mr Exigence a le droit de modifier son modèle après que Mme Design ait terminé son travail. 4.Mr Code na pas le droit de lire le modèle de design tant que Mme Design na pas terminé de travailler. 5.…

22 Et le passage à léchelle alors ? Taille des modèles – La taille globale se mesure maintenant en Go – Les modèles sont partagés entre les différents développeurs Taille des équipes et fréquence des interventions – Les équipes sont composées de plusieurs développeurs (10 -> 1000) – Les équipes sont répartie sur plusieurs sites (5-10) – Les modifications sont fréquentes et peuvent avoir des impacts importants Taille des projets et partage des ressources – Certains modèles sont utilisés dans plusieurs projets

23 APPROCHE CENTRALISÉE

24 Référentiel + Moteur Workflow

25 Référentiel Problématique: Stockage des modèles et gestion des accès IdId NamePriorit y Parent 1Système de gestion des notes des étudiantsSevère1 2Les étudiants peuvent obtenir leurs notesHaute1 3Les enseignants peuvent saisir les notes des étudiantsHaute1 4Les responsable dUE peuvent ajouter des contrôlesHaute1

26 Référentiel On sait – Stocker un modèle dans un fichier Grace à XMI – Assurer une gestion de version sur un fichier Utiliser les systèmes de gestion de version – Donner des droits daccès sur un fichier Utiliser les systèmes dauthentification On sait moins – Stocker des morceaux de modèles Plusieurs fichiers XMI ? Quelle granularité ? – Assurer un accès à une sous partie dun modèle Un modèle étant un graphe déléments de modèle il est délicat de limiter le parcours du graphe – Assurer la cohérence des données Verrous ou diff/merge

27 Moteur de Workflow Synchroniser Notifier Suivre Problème: Assurer que les développeurs respectent le processus

28 Moteur de Workflow On sait – Exécuter automatiquement un workflow – Assurer les interactions avec les développeurs – Offrir une visibilité sur létat davancement On sait moins – Exécuter un processus de génie logiciel tout en assurant la souplesse (CMMi) – Coupler le suivi du processus avec le référentiel

29 Exercice Mise en œuvre du scénario concret – Comment stocker les 3 modèles ? – Comment assurer les droits daccès ? – Comment mettre en œuvre les opérations automatisées ? – Comment assurer la coordination des développeurs ? – Comment assurer la cohérence des modèles ? Imaginer le passage à léchelle

30 Synthèse Lapproche centralisée est envisageable – Référentiel CVS pour les modèles + moteur de workflow Reste des problèmes majeurs à régler – Comment passer du modèle au fichier ? Faut-il changer les référentiel CVS? – Comment assurer un suivi flexible du processus Adaptation du processus pendant lexécution! – Comment assurer le lien CVS + Workflow

31 APPROCHE MODELBUS Bus de modèles

32 Vision Services UML Repository OCL Checker Q/V/T Engine check get transform get

33 Problématique Connecter les services: Nécessité de définir un système de typage pour les modèles – Quest-ce quun type de modèle (conformance)? Nécessité de définir les accès aux services – Est-ce similaire à un accès WS ou Java? – Encoder les modèles, XMI est-il lunique solution?

34 Système de typage pour les modèles Ex: diagramme de classes Doit-on accepter un package qui contient un acteur ?

35 Système de typage pour les modèles ModelModelType conformance Quest-ce quun modèle? Extent (MOF2.0 Life Cycle) Quest-ce quun méta-modèle? Quest-ce quun type de modèle? Un meta-model? Quest ce que la conformité ?

36 Laccès check Web Service Access + XMI Java Access + JMI Comment échanger les modèles? XMI, Java, CORBA Quelle sémantique dappel? Error, Exception, Reference

37 Functionnal Description Metamodel

38 Role de ladapter Ladapter assure les échanges réseaux / outil et soccupe de laccès aux modèles ModelBus supporte 2 modes daccès au modèles 1.Le consommateur récupère ses modèles et les transmet au service 2.Le consommateur transmet la référence du modèle et le service récupère les modèles

39 Les Adapters dans ModelBus Cet outil propose un service permettant de vérifier des contraintes OCL sur un modèle UML Son concepteur doit élaborer la description de loutil (en élaborant un modèle) Ladapter est généré Ladapter senregistre dans lannuaire des services disponibles

40 Exercice Mise en œuvre du scénario concret – Comment stocker les 3 modèles ? – Comment assurer les droits daccès ? – Comment mettre en œuvre les opérations automatisées ? – Comment assurer la coordination des développeurs ? – Comment assurer la cohérence des modèles ? Imaginer le passage à léchelle

41 Synthèse Lapproche ModelBus a été prototypée dans deux projets Européens de recherche – Difficulté de convaincre les clients (grand groupe) Reste des problèmes majeurs à régler – Comment assurer un suivi du processus Recherche effectuée pour brancher un moteur de workflow sur ModelBus – Comment assurer la gestion de version

42 APPROCHE PRAXIS Une approche décentralisée

43 Opération de construction Operations nécessaire à la construction – Create a model element – SetProperty assign a property value to a model element – SetReference assign a reference value to a model element – Delete a model element Un modèle est représenté par une séquence de construction

44 01. create(c1,Class) 02. setProperty(c1,name, {PetStore}) 03. create(uc1,UseCase) 04. setProperty(uc1,name, {Buy eBasket})) 05. create(uc2,UseCase) 06. setProperty(uc2,name,{Create eBasket}) 07. create(uc3,UseCase) 08. setProperty(uc3,name,{Cancel eBasket}) 09. setReference(c1,ownedUseCase,{uc1,uc2,uc3}) 10. create(a1,Actor) 11. setProperty(a1,name, {Customer}) 12. setReference(a1, usecase, {uc1,uc2,uc3})

45 Répartition des séquences 01. create(c1,Class) 02. setProperty(c1,name, {PetStore}) 03. create(uc1,UseCase) 04. setProperty(uc1,name, {Buy eBasket})) setReference(c1,ownedUseCase,{uc1}) 10. create(a1,Actor) 11. setProperty(a1,name, {Customer}) 12. setReference(a1, usecase, {uc1}) 01. create(c1,Class) 02. setProperty(c1,name, {PetStore}) create(uc2,UseCase) 06. setProperty(uc2,name,{Create eBasket}) 07. create(uc3,UseCase) 08. setProperty(uc3,name,{Cancel eBasket}) 09. setReference(c1,ownedUseCase,{uc2,uc3}) 10. create(a1,Actor) 11. setProperty(a1,name, {Customer}) 12. setReference(a1, usecase, {uc2,uc3}) 1.Comment Echanger ? 2.Comment assurer la cohérence ?

46 Comment Echanger Un groupe = Un projet (une séquence) Ordre total des opérations (horloge de Lamport) Possibilité de regarder la séquence dun membre Sabonner aux éléments du modèle – Réception des opérations les concernant – Filtrage à la réception (pour les références)

47 Comment assurer la cohérence ? Principe: Détecter les incohérences Incohérence structurelle: – Propriété structurelle observable sur le modèle (similarité avec les contraintes OCL) Incohérence méthodologique: – Propriété observable sur la façon dont on a construit le modèle

48 Incohérence structurelle Définies par des prédicats sur la séquence. Préfix last pour identifier les actions qui ont un impact sur le résultat (create sans delete) EX: a use case should not own a use case if a = lastCreate (me, UseCase) then ! o uc, o = lastSetReference(me,ownedUseCase, R) and R.

49 Incohérence méthodologique Définies par des prédicats sur la séquence. < pour spécifier lordre des opérations EX: Assign its name just after the creation of a use case a σ, if a = create(me,UseCase) then c σ, c = setProperty(me,name, NameVal) and ! b σ, a < b < c

50 Mise en œuvre Praxis Une opération de construction est un fait Prolog Une séquence est une base de faits Les incohérences sont les requêtes Prolog – Qui cherche les opérations source dincohérence – Leurs variables servent au diagnostic analysis(X,Y) :- lastCreate(X,usecase), lastSetReference(X,ownedusecase,Y).

51 Exercice Mise en œuvre du scénario concret – Comment stocker les 3 modèles ? – Comment assurer les droits daccès ? – Comment mettre en œuvre les opérations automatisées ? – Comment assurer la coordination des développeurs ? – Comment assurer la cohérence des modèles (couverture) ? Imaginer le passage à léchelle

52 Synthèse Lapproche Praxis est une approche de recherche – Le vérificateur local de contraintes (basé sur Prolog) a été développé – Léditeur pair-à-pair de modèles UML a été développé Un support aux contraintes méthodologiques est en cours dintégration La validation reste à définir

53 CONCLUSION

54 Synthèse LIDM ne doit pas être disponible seulement à un développeur utilisant son propre outil de modélisation (D. Schmidt) Les environnements IDM (MDSE) ont leurs propres problématiques – Gestion des modèles & gestion du contrôle Les solutions actuelles ne sont pas adaptées ! Les travaux de recherche permettent de mesurer les difficultés de ce domaine

55 Et en plus (on) veut La traçabilité Lanalyse dimpact La résolution automatique Etc.

56 Références Peri L. Tarr, Harold Ossher, William H. Harrison, and Stanley M. Jr. Sutton. N degrees of separation: Multi-dimensional separation of concerns. In Proc. Int'l Conf. Software Engineering, pages , Takafumi Oda and Motoshi Saeki. Generative technique of version control systems for software diagrams. In Proc. International Conf. Software Maintenance (ICSM '05), pages 515{524, Washington, DC, USA, IEEE Computer Society. L. Osterweil. Software processes are software too. In Proc. Int'l Conf. Software Engineering (ICSE '87), pages 2{13, Los Alamitos, CA, USA, IEEE Computer Society Press. Douglas C. Schmidt. Guest editor's introduction: Model-driven engineering. IEEE Computer, Xavier Blanc, Marie-Pierre Gervais, and Prawee Sriplakich. Model bus: Towards the interoperability of modelling tools. In MDAFA, volume 3599 of Lecture Notes in Computer Science, pages Springer, Anthony I. Wasserman. Tool integration in software engineering environments. In Proc. Int'l workshop on environments on Software engineering environments, pages Springer, M. N. Wicks and R. G. Dewar. Controversy corner: A new research agenda for tool integration. J. Syst. Softw., 80(9):1569{1585, Prawee Sriplakich, Xavier Blanc, and Marie-Pierre Gervais. Supporting collaborative development in an open mda environment. In ICSM, pages IEEE Computer Society, September 2006.


Télécharger ppt "IDM & Passage à lEchelle Xavier Blanc Université Pierre & Marie Curie."

Présentations similaires


Annonces Google