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

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

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.

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

Modèle = Graphe Typé

Formalisation & Illustration Formalisation simple mais précise Formalisation & Illustration

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

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

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

Un méta-modèle d’exigence Objectif: Formalisation Référence: Doors?

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

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

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

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

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)

Déroulement d’un processus

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 ?

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?

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

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

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

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

Approche Centralisée

Référentiel + Moteur Workflow

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

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

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

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

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

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

Bus de modèles Approche ModelBus

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

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?

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

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é ?

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

Functionnal Description Metamodel

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

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

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

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

Une approche décentralisée Approche Praxis

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 

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})

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 ?

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)

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

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 ≠ .

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

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

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

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

Conclusion

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

Et en plus (on) veut La traçabilité L’analyse d’impact La résolution automatique Etc.

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 107-119, 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, 2005. 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, 1987. 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 17-32. Springer, 2004. Anthony I. Wasserman. Tool integration in software engineering environments. In Proc. Int'l workshop on environments on Software engineering environments, pages 137-149. 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 244-253. IEEE Computer Society, September 2006.