Cette section décrit quelques cas pratiques d’utilisation du serveur CMSPEM, ainsi que les différentes actions correspondantes sur le serveur.
6.4.1 Flux de données et de contrôle
6.4.1.1 Lecture de modèle
1. Un outil externe fait une requête de lecture à l’API CMSPEM. 2. Le serveur authentifie la requête, et vérifie les autorisations.
3. La couche d’accès aux données charge éventuellement le modèle XMI en mémoire, et extrait les données demandées.
4. L’API CMSPEM convertit les données extraites dans le format de sortie (JSON) et les renvoie à l’outil externe.
7. ❤tt♣s✿✴✴❣✐t❤✉❜✳❝♦♠✴❣❤✐❧❧❛✐r❡t✴❡♠❢❥s♦♥
8. Scala est un langage de programmation qui peut être compilé vers du bytecode Java. Voir❤tt♣✿✴✴✇✇✇✳ s❝❛❧❛✲❧❛♥❣✳♦r❣✴.
6.4.1.2 Modification de modèle
1. Un outil externe fait une requête de modification de modèle à l’API CMSPEM. 2. Le serveur authentifie la requête, et vérifie les autorisations.
3. La couche d’accès aux données charge éventuellement le modèle XMI en mémoire. 4. Les données sont modifiées en mémoire.
5. La couche d’accès aux données sauvegarde éventuellement les données modifiées sur le disque.
6. L’API CMSPEM convertit éventuellement les données associées à l’élément modifié vers le format de sortie (JSON), et le renvoie à l’outil externe.
7. Le serveur déclenche les événements liés à la modification, et notifie les éventuels ges-tionnaires d’événement définis.
6.4.1.3 Souscription d’événement par un outil tiers
1. Un outil tiers lit éventuellement les éléments disponibles dans le modèle, et les événe-ments disponibles sur ces éléévéne-ments.
2. L’outil tiers envoie une requête de souscription à l’API CMSPEM, précisant, entre autres, l’adresse de notification.
3. L’API CMSPEM authentifie et autorise éventuellement la requête. 4. La couche d’accès aux données charge le modèle XMI en mémoire.
5. La couche d’accès aux données enregistre la souscription dans la base de données. 6. Le serveur CMSPEM confirme la souscription à l’outil tiers.
6.4.1.4 Notification d’événement par le serveur CMSPEM
1. Il se produit sur le modèle un événement pour lequel il existe des souscriptions (modifi-cation de modèle).
2. Pour chacune des souscriptions existantes, le serveur CMSPEM :
(a) Rassemble les paramètres de l’événement, et les convertit au format d’échange (JSON).
(b) Lance une requête HTTP de type POST sur l’URL spécifiée lors de la souscription, avec les paramètres de l’événement.
6.4.2 Exemples de requêtes sur le serveur CMSPEM
Le serveur CMSPEM implémente trois principales familles de cas d’utilisation10 :
10. Les exemples sont donnés en ligne de commande, avec un utilitaire d’envoi de requêtes HTTP nommé ❤tt♣ (❤tt♣s✿✴✴❣✐t❤✉❜✳❝♦♠✴❥❦❜r✴❤tt♣✐❡). De plus, la variable❈▼❙P❊▼❴❑❊❨ contient la clé d’API de l’utilisateur effectuant la requête.
– L’obtention d’informations sur le modèle de processus. Par exemple, une requête sur
✴♣r♦❥❡❝ts✴❳❳❳✴❛s✇♦r❦s✴❨❨❨ renvoie des données (attributs et valeurs, ansi que des références vers d’autres éléments de modèle) au sujet de l’❆❝t♦r❙♣❡❝✐✜❝❲♦r❦ identifié par YYY, dans le projet identifié par XXX (Figure6.11).
✩ ❤tt♣ ●❊❚ ❭ ❤tt♣✿✴✴❝♠s♣❡♠✳❤❡r♦❦✉❛♣♣✳❝♦♠✴♣r♦❥❡❝ts✴✶✴❛s✇♦r❦s✴❴②♥❡❍❊◗❢▼❊❡❑s❜t❳❇✽♣❴✉✐❆ ❭ ❳✲❆P■✲❑❊❨✿✩❈▼❙P❊▼❴❑❊❨ ④ ✧✐t❡♠✧✿ ④ ✧❞❡❛❞❧✐♥❡✧✿ ✧✷✺✴✶✶✴✷✵✶✷✧✱ ✧♥❛♠❡✧✿ ✧❈r❡❛t❡ ❲✐r❡❢r❛♠❡✧✱ ✧t❛s❦✧✿ ④ ✧✉r❧✧✿ ✧❤tt♣✿✴✴❝♠s♣❡♠✳❤❡r♦❦✉❛♣♣✳❝♦♠✴♣r♦❥❡❝ts✴✶✴t❛s❦s✴❴❊♠✇❍♦❆❝❴❊❡❑✶qt❋❦❈❲❦❏❇❆✧ ⑥✱ ✧✉r❧✧✿ ✧❤tt♣✿✴✴❝♠s♣❡♠✳❤❡r♦❦✉❛♣♣✳❝♦♠✴♣r♦❥❡❝ts✴✶✴❛s✇♦r❦s✴❴②♥❡❍❊◗❢▼❊❡❑s❜t❳❇✽♣❴✉✐❆✧ ⑥✱ ✧✉r❧✧✿ ✧❤tt♣✿✴✴❝♠s♣❡♠✳❤❡r♦❦✉❛♣♣✳❝♦♠✴♣r♦❥❡❝ts✴✶✴❛s✇♦r❦s✴❴②♥❡❍❊◗❢▼❊❡❑s❜t❳❇✽♣❴✉✐❆✧ ⑥
FIGURE6.11 – Exemple d’extraction d’information de processus à partir d’un modèle CMSPEM. – La modification des informations du modèle de processus. Une requête de type POST sur✴♣r♦❥❡❝ts✴❳❳❳✴t❛s❦s✴❨❨❨par exemple peut être utilisée pour modifier la deadline d’un❆❝t♦r❙♣❡❝✐✜❝❲♦r❦ (Figure6.12). ✩ ❤tt♣ ✲❢ P❖❙❚ ❭ ❤tt♣✿✴✴❝♠s♣❡♠✳❤❡r♦❦✉❛♣♣✳❝♦♠✴♣r♦❥❡❝ts✴✶✴❛s✇♦r❦s✴❴②♥❡❍❊◗❢▼❊❡❑s❜t❳❇✽♣❴✉✐❆ ❭ ❞❡❛❞❧✐♥❡❂✧✵✺✴✵✼✴✷✵✶✸✧ ❭ ❳✲❆P■✲❑❊❨✿✩❈▼❙P❊▼❴❑❊❨ ④ ✧✐t❡♠✧✿ ④ ✧❞❡❛❞❧✐♥❡✧✿ ✧✵✺✴✵✼✴✷✵✶✸✧✱ ✧♥❛♠❡✧✿ ✧❈r❡❛t❡ ❲✐r❡❢r❛♠❡✧✱ ✧t❛s❦✧✿ ④ ✧✉r❧✧✿ ✧❤tt♣✿✴✴❝♠s♣❡♠✳❤❡r♦❦✉❛♣♣✳❝♦♠✴♣r♦❥❡❝ts✴✶✴t❛s❦s✴❴❊♠✇❍♦❆❝❴❊❡❑✶qt❋❦❈❲❦❏❇❆✧ ⑥✱ ✧✉r❧✧✿ ✧❤tt♣✿✴✴❝♠s♣❡♠✳❤❡r♦❦✉❛♣♣✳❝♦♠✴♣r♦❥❡❝ts✴✶✴❛s✇♦r❦s✴❴②♥❡❍❊◗❢▼❊❡❑s❜t❳❇✽♣❴✉✐❆✧ ⑥✱ ✧✉r❧✧✿ ✧❤tt♣✿✴✴❝♠s♣❡♠✳❤❡r♦❦✉❛♣♣✳❝♦♠✴♣r♦❥❡❝ts✴✶✴❛s✇♦r❦s✴❴②♥❡❍❊◗❢▼❊❡❑s❜t❳❇✽♣❴✉✐❆✧ ⑥
FIGURE6.12 – Exemple de requête de mise à jour d’un modèle CMSPEM.
– Le traitement des souscriptions à des évènements de processus, et l’envoi de notifica-tions quand ces évènements se produisent. Une requête sur✴♣r♦❥❡❝ts✴❳❳❳✴t❛s❦s✴❨❨❨✴ s✉❜s❝r✐♣t✐♦♥speut être utilisée pour demander à être notifié quand la tâche YYY se termine par exemple (Figure6.13). Quand l’évènement concerné se produit, le serveur CMSPEM envoie une requête au gestionnaire (l’adresse URL spécifiée en paramètre lors de la souscription).
✩ ❤tt♣ ✲❢ P❖❙❚ ❭ ❤tt♣✿✴✴❝♠s♣❡♠✳❤❡r♦❦✉❛♣♣✳❝♦♠✴♣r♦❥❡❝ts✴✶✴t❛s❦s✴❴❊♠✇❍♦❆❝❴❊❡❑✶qt❋❦❈❲❦❏❇❆✴s✉❜s❝r✐♣t✐♦♥s ❭ ❤❛♥❞❧❡r❂✧❤tt♣✿✴✴❝♠s♣❡♠✲❤❡❧♣❡r✳❤❡r♦❦✉❛♣♣✳❝♦♠✴t❛s❦✴♥❡✇✧ ❭ ❡✈❡♥t❂❡♥❞ ❭ ❳✲❆P■✲❑❊❨✿✩❈▼❙P❊▼❴❑❊❨ ④ ✧✐t❡♠✧✿ ④ ✧❝♦rr❡❧❛t✐♦♥■❞✧✿ ♥✉❧❧✱ ✧❝r❡❛t❡❞✧✿ ✶✸✹✽✻✻✵✸✺✷✶✽✽✱ ✧❡✈❡♥t✧✿ ✧❡♥❞✧✱ ✧❡✈❡♥ts♦✉r❝❡✧✿ ✧✴♣r♦❥❡❝ts✴✶✴t❛s❦s✴❴❊♠✇❍♦❆❝❴❊❡❑✶qt❋❦❈❲❦❏❇❆✴s✉❜s❝r✐♣t✐♦♥s✧✱ ✧❡✈❡♥ts♦✉r❝❡■❞✧✿ ✧❴❊♠✇❍♦❆❝❴❊❡❑✶qt❋❦❈❲❦❏❇❆✧✱ ✧❤❛♥❞❧❡r✧✿ ✧❤tt♣✿✴✴❝♠s♣❡♠✲❤❡❧♣❡r✳❤❡r♦❦✉❛♣♣✳❝♦♠✴t❛s❦✴♥❡✇✧✱ ✧✐❞✧✿ ✧✷✶✧✱ ✧✉♣❞❛t❡❞✧✿ ✶✸✹✽✻✻✵✸✺✷✷✼✾✱ ✧✉r❧✧✿ ✧❤tt♣✿✴✴❝♠s♣❡♠✳❤❡r♦❦✉❛♣♣✳❝♦♠✴♣r♦❥❡❝ts✴✶✴t❛s❦s✴❴❊♠✇❍♦❆❝❴❊❡❑✶qt❋❦❈❲❦❏❇❆✴s✉❜s❝r✐♣t✐♦♥s✴✷✶✧ ⑥✱ ✧✉r❧✧✿ ✧❤tt♣✿✴✴❝♠s♣❡♠✳❤❡r♦❦✉❛♣♣✳❝♦♠✴♣r♦❥❡❝ts✴✶✴t❛s❦s✴❴❊♠✇❍♦❆❝❴❊❡❑✶qt❋❦❈❲❦❏❇❆✴s✉❜s❝r✐♣t✐♦♥s✴✷✶✧ ⑥
FIGURE6.13 – Exemple de souscription à un évènement de processus.
6.5 Conclusion
Le présent chapitre a présenté les divers outils de support au méta-modèle CMSPEM, réa-lisés dans le cadre du travail de thèse. D’une part, des éditeurs de modèle ont été réaréa-lisés sous la plate-forme Eclipse. D’autre part, un serveur de modèles de processus, communiquant via le protocole HTTP, et gérant les données et événements de processus, a été développé.
Les fonctionnalités de consultation de modèle (langage de requête) sont présentes dans une moindre mesure dans les éditeurs graphiques et textuels développés. Cependant, c’est le serveur CMSPEM qui offre véritablement un langage de requête pour extraire de manière précise l’information de processus, grâce à son API HTTP/REST. L’association faite entre les URLs du serveur et les éléments de modèle permet d’avoir un accès direct à chacun de ces élé-ments, ce qui permet au serveur de mettre à disposition des liens profonds vers l’information de processus. De plus, la spécification du format de données utilisé par le serveur, et l’utili-sation systématique des liens profonds pour désigner les références entre concepts, permet à tout outil tiers de naviguer facilement à travers le modèle de processus11.
La modification de modèle est implémentée via un éditeur graphique implémenté sous GMF, et un éditeur textuel implémenté sous XTEXT. L’éditeur graphique est optimisé pour la manipulation intuitive, alors que l’éditeur textuel ouvre la possibilité de générer certaines parties d’un modèle de processus CMSPEM à partir de sources de données externes. L’éditeur textuel a aussi été muni d’une fonctionnalité d’extraction de visualisations personnalisées, permettant de mettre en valeur un aspect particulier du modèle de processus.
11. Ceci correspond à l’acronyme HATEOS (Hypertexte As The Engine Of Application State), utilisé pour décrire les systèmes REST. En effet, cette conception permet à un outil automatisé de parcourir et manipuler le modèle de processus en suivant les liens inclus dans les représentations renvoyées par le serveur.
Une des responsabilités principales du serveur de processus CMSPEM développé est de permettre la réaction aux événements de processus, grâce aux crochets. Une API de souscrip-tion aux événements a ainsi été mise en place, et la technique des web-hooks a été utilisée pour notifier les outils tiers des occurrences d’événement.
Les outils décrits dans le présent chapitre constituent une instanciation du modèle concep-tuel défini dans le chapitre 3. Le chapitre7 exploite ces outils sur un ensemble d’exemples, afin d’illustrer l’utilisation des données et événements de processus dans le support du déve-loppement collaboratif.
Chapitre
7
Validation de l’approche
7.1 Introduction
Le chapitre3a présenté un modèle conceptuel du support au développement collaboratif, qui repose sur la mise à disposition des données (chapitre4) et événements (chapitre5) des diverses préoccupations de développement collaboratif, dont les processus logiciels. Le cha-pitre6a, pour sa part, décrit l’implémentation des différentes fonctionnalités prévues par ce modèle conceptuel. Dans le présent chapitre, nous illustrons le méta-modèle sur un exemple, et présentons un ensemble de validations de l’approche proposée.
En premier lieu, nous décrivons les résultats d’une étude des données de listes de discus-sion d’un ensemble de 219 projets open source [Kedj 13]. Le but de cette étude est d’illustrer comment les concepts de “lien profond” et de “crochet” structurent l’intégration des outils de support au développement collaboratif, afin de valider l’approche conceptuelle du chapitre3. En second lieu, nous montrons, sur des cas pratiques, comment le serveur ❈▼❙P❊▼ dont l’implémentation a été décrite au chapitre 6, grâce au support des “liens profonds” et des “crochets”, peut être exploité dans le support automatisé au développement collaboratif [Kedj 12a,Kedj 13]. Pour ce faire, nous présentons quelques utilitaires dont certains ont été développés et démontrés sur des exemples.