IDM & Passage à l’Echelle

1. IDM & Passage à l’Echelle Xavier Blanc Université Pierre & Marie Curie

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

3. 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

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

5. Modèle = Graphe Typé

6. Formalisation simple mais précise Formalisation & Illustration

7. Principes • L’IDM consiste à utiliser les modèles dans toutes les taches du cycle de vie d’un système informatique (ex: exigence, conception, production) • Dans l’IDM, le processus contrôlant le cycle de vie est lui-même un modèle ! • Grâce au support des modèles, l’objectif est d’automatiser 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 d’exigence • Objectif: Formalisation • Référence: Doors?

11. Un modèle d’exigences • Objectif: Tracabilité

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 n’est 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 s’avère très complexe • Considérons que nous sommes un monde idéal nous disposons donc • D’un 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 d’un 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 à l’IDM ?

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 d’une tache va lire des modèles et/ou les modifier => Comment assurer l’accès aux modèles? => Comment garantir l’intégrité des modèles?

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

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

21. Un peu de concret (2ème lecture) • Tant que Mr Exigence n’a pas terminé, Mme Design n’a pas le droit de lire le modèle d’exigence. L’opération de vérification d’un modèle d’exigence est automatisée. • Mr Exigence n’a 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). • Mr Exigence a le droit de modifier son modèle après que Mme Design ait terminé son travail. • Mr Code n’a pas le droit de lire le modèle de design tant que Mme Design n’a pas terminé de travailler. • …

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

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 d’accès sur un fichier • Utiliser les systèmes d’authentification • On sait moins • Stocker des morceaux de modèles • Plusieurs fichiers XMI ? Quelle granularité ? • Assurer un accès à une sous partie d’un 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 • 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 d’avancement • 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 d’accè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 • L’approche 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 l’exécution! • Comment assurer le lien CVS + Workflow

31. Bus de modèles Approche ModelBus

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

33. Problématique Connecter les services: • Nécessité de définir un système de typage pour les modèles • Qu’est-ce qu’un 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 l’unique solution?

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

35. Système de typage pour les modèles conformance conformance Model ModelType • Qu’est-ce qu’un modèle? • Extent (MOF2.0 Life Cycle) • Qu’est-ce qu’un méta-modèle? • Qu’est-ce qu’un type de modèle? • Un meta-model? • Qu’est ce que la conformité ?

36. L’accès check Web Service Access + XMI Java Access + JMI • Comment échanger les modèles? • XMI, Java, CORBA • Quelle sémantique d’appel? • Error, Exception, Reference

37. Functionnal Description Metamodel

38. Role de l’adapter L’adapter assure les échanges réseaux / outil et s’occupe de l’accès aux modèles ModelBus supporte 2 modes d’accès au modèles Le consommateur récupère ses modèles et les transmet au service Le consommateur transmet la référence du modèle et le service récupère les modèles

39. Son concepteur doit élaborer la description de l’outil (en élaborant un modèle) L’adapter est généré L’adapter s’enregistre dans l’annuaire des services disponibles Les Adapters dans ModelBus Cet outil propose un service permettant de vérifier des contraintes OCL sur un modèle UML

40. Exercice • Mise en œuvre du scénario concret • Comment stocker les 3 modèles ? • Comment assurer les droits d’accè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 • L’approche 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. Une approche décentralisée Approche Praxis

43. Opération de construction • Operations nécessaire à la construction • Createa model element • SetPropertyassign a property value to a model element • SetReferenceassign a reference value to a model element • Deletea 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’})) 05. 06. 07. 08. 09. 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’}) 03. 04. 05. 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}) Comment Echanger ? 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 d’un membre • S’abonner 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édicatssur 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édicatssur la séquence. • “ < ” pour spécifierl’ordre 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 • Uneopération de construction est un fait Prolog • Uneséquenceestune base de faits • Les incohérencessont les requêtes Prolog • Qui cherche les opérations source d’incohérence • Leurs variables servent au diagnostic analysis(X,Y) :- lastCreate(X,usecase), lastSetReference(X,ownedusecase,Y).