IDM & Passage à l’Echelle

Xavier BlancUniversité Pierre & Marie Curie

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

L’approcheArchitecture 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.

ArchitectureArchitecture MDA

CIM PIM PSM Code

Application Informatique

MOF

M2 QVT M2

Modèle = Graphe Typé

FORMALISATION & ILLUSTRATIONFormalisation simple mais précise

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 1

2 Les étudiants peuvent obtenir leurs notes Haute 1

3 Les enseignants peuvent saisir les notes des étudiants

Haute 1

4 Les responsable d’UE peuvent ajouter des contrôles

Haute 1

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

RépartiDynamiqueHétérogène

Mr Exigence

Mme Design Mr Code

Un peu de concret

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

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

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

Un peu de concret (2ème lecture)

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

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

3. Mr Exigence a le droit de modifier son modèle après que Mme Design ait terminé son travail.

4. Mr Code n’a pas le droit de lire le modèle de design tant que Mme Design n’a pas terminé de travailler.

5. …

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 1

2 Les étudiants peuvent obtenir leurs notes Haute 1

3 Les enseignants peuvent saisir les notes des étudiants Haute 1

4 Les responsable d’UE peuvent ajouter des contrôles Haute 1

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

Moteur de Workflow

Synchroniser

Notifier

Suivre

• Problème: Assurer que les développeurs respectent le processus

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

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

APPROCHE MODELBUSBus de modèles

Vision Services

UML Repository

OCL Checker

Q/V/T Engine

check

get

transform

get

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

NewClass NewUseCase

• Ex: diagramme de classes

NewClass NewUseCase

Doit-on accepter un package qui contient un acteur ?

Système de typage pour les modèles

Model ModelTypeconformance

conformance

• 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

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èlesModelBus supporte 2 modes d’accès

au modèles1. 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

Les Adapters dans ModelBusCet outil propose un service permettant de vérifier des contraintes OCL sur un modèle UML

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

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

APPROCHE PRAXISUne approche décentralisée

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

1. Comment Echanger ?2. 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.