IDM & Passage à l’Echelle

Présentation au sujet: "IDM & Passage à l’Echelle"— Transcription de la présentation:

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

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

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

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

5 Modèle = Graphe Typé

6 Formalisation & Illustration
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é Id Name Priority Parent 1
Système de gestion des notes des étudiants Sevère 2 Les étudiants peuvent obtenir leurs notes Haute 3 Les enseignants peuvent saisir les notes des étudiants 4 Les responsable d’UE peuvent ajouter des contrôles

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
Mme Design Réparti Dynamique Hétérogène 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
Id Name Priority Parent 1 Système de gestion des notes des étudiants Sevère 2 Les étudiants peuvent obtenir leurs notes Haute 3 Les enseignants peuvent saisir les notes des étudiants 4 Les responsable d’UE peuvent ajouter des contrôles

26 Référentiel On sait On sait moins 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 Synchroniser Notifier Suivre

28 Moteur de Workflow On sait On sait moins
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 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
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 Comment échanger les modèles? XMI, Java, CORBA
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 Les Adapters dans ModelBus
Son concepteur doit élaborer la description de l’outil (en élaborant un modèle) Cet outil propose un service permettant de vérifier des contraintes OCL sur un modèle UML L’adapter est généré Préparer les modèles descriptifs ainsi que les amorces L’adapter s’enregistre dans l’annuaire des services disponibles

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 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’})) 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é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 l’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 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 d’incohé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 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 (couverture) ? Imaginer le passage à l’échelle

52 Synthèse L’approche 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 d’intégration La validation reste à définir

53 Conclusion

54 Synthèse L’IDM 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é L’analyse d’impact
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 , 1999. 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, 2006. 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, 2004. Anthony I. Wasserman. Tool integration in software engineering environments. In Proc. Int'l workshop on environments on Software engineering environments, pages Springer, 1990. M. N. Wicks and R. G. Dewar. Controversy corner: A new research agenda for tool integration. J. Syst. Softw., 80(9):1569{1585, 2007. Prawee Sriplakich, Xavier Blanc, and Marie-Pierre Gervais. Supporting collaborative development in an open mda environment. In ICSM, pages IEEE Computer Society, September 2006.