Evolution d’une instance de la tˆ ache Find Use Cases en tˆ ache collaborative

Durant l’ex´ecution, comme nous l’avons vu dans le chapitre 3, il peut arriver que l’une des instances d’une tˆache ait besoin de devenir collaborative pour diverses raisons, par exemple pour avoir recours `a l’expertise d’un acteur suppl´ementaire. Dans notre cas, supposons qu’Alice ait besoin d’un autre analyste, Victor, pour l’aider dans sa tˆache. La commande split permet de d´ecomposer l’instance de tˆache afin de la rendre collaborative, et donc n´ecessite patron de collaboration pour son d´eploiement. Si nous consid´erons que Alice et Victor vont travailler en s´equentiel, Alice d´emarrant et Victor utilisant le produit fourni par Alice pour l’affiner, nous pouvons appliquer le patron Refinement. L’´evolution d’une STI en CTI se fait suivant les mˆemes ´etapes que l’instanciation d’une tˆache. Cela veut dire qu’il faut aussi assigner un patron de collaboration `a la nouvelle CTI et choisir les produits en entr´ee comme en sortie. Ces ´

etapes sont pr´esent´ees sur la figure 6.24. Cette nouvelle CTI prend comme entr´ee la deuxi`eme composante des exigences (requirements 2).

Figure 6.24: Instanciation de la nouvelle tˆache collaborative issue de l’´evolution de Find Use Cases inst 2.

cette figure, nous pouvons voir la nouvelle tˆache collaborative Find use cases inst 2 `a droite avec de nouvelles options permettant notamment de voir la liste de ses instances apr`es son instanciation.

Figure 6.25: Nouvelle liste des instances apr`es ´evolution en CTI d’une instance de la tˆache Find Use cases.

La liste des instances de cette nouvelle tˆache collaborative ainsi obtenue est repr´esent´ee sur la figure 6.26.

Etant donn´e le patron refinement, qui implique un ordonnancement s´equentiel, Victor ne peut d´emarrer sa tˆache tant qu’Alice n’a pas fini la sienne. Cela est indiqu´e par la couleur gris´ee du bouton ”Start task” au niveau de l’instance de tˆache de Victor et le libell´e ”Previous task” qui pr´ecise qu’effectivement la tˆache pr´ec´edant la tˆache de Victor est bien celle d’Alice. Apr`es ex´ecution de cette nouvelle tˆache collaborative, le produit de sortie obtenu est la seconde partie de la liste des cas d’utilisation avec la participation de Victor maintenant (voir figure 6.27).

6.5 Discussion et limites de la validation

L’objectif de ce chapitre ´etait de valider notre approche `a travers un outil support op´erationnel et une ´etude de cas significative. Pour l’´etude de cas, nous avons utilis´e le processus RUP-A qui est un processus collaboratif repr´esentatif et qui a fait ses preuves dans le domaine de la conception logicielle. Nous avons montr´e comment certaines tˆaches de ce processus pouvaient ˆ

Figure 6.26: Liste des instances de la nouvelle tˆache collaborative apr`es ´evolution.

Figure 6.27: R´esultat obtenu en sortie de l’ex´ecution de la nouvelle tˆache collaborative.

Grˆace `a ECPML, l’ex´ecution des diff´erentes tˆaches du RUP-A peut se faire de fa¸con flexible. En effet, il n’est pas n´ecessaire d`es le d´ebut de d´efinir de fa¸con rigide tout le cheminement de l’ex´ecution. Le focus est mis sur le contexte d’ex´ecution permettant de connaˆıtre la nature des produits d’entr´ee et de sortie et la disponibilit´e des acteurs.

pour l’instanciation d’une tˆache collaborative par l’interm´ediaire d’un patron de collaboration. Toutefois, cet algorithme est limit´e aux strat´egies de collaboration actuellement d´efinies. De plus, notre approche n’a pas ´et´e test´ee avec un r´eel projet industriel. Cela tient notamment `a la difficult´e d’obtenir des informations d´etaill´ees concernant le processus de d´eroulement d’un projet industriel.

6.6 Conclusion

Ce chapitre a tout d’abord pr´esent´e l’impl´ementation r´ealis´ee pour supporter notre approche. Le prototype CPE a ´et´e d´evelopp´e, avec pour objectif de supporter les diff´erentes ´etapes de l’ex´ecution d’un processus. La principale ´etape au niveau de ce prototype est l’instanciation d’une tˆache collaborative avec un patron de collaboration. Apr`es instanciation, chaque instance ´

evolue conform´ement `a une machine `a ´etats d´efinissant son comportement comme d´efini dans le chapitre 5.

L’utilisation des patrons montre la pertinence d’avoir une approche flexible. Grˆace `a cela, nous sommes capables de g´erer dynamiquement les relations entre les STIs d’une tˆache collaborative et de les faire ´evoluer en cours d’ex´ecution. Cette ´evolution suit les diff´erents changements de contexte qui peuvent se produire (exemples : d´ecomposition d’un produit pour le rendre composite, d´efection d’un acteur, ajout d’un acteur). Une fois la tˆache instanci´ee, nous pouvons g´erer l’ex´ecution des diff´erentes STIs en accord avec l’ordonnancement d´efini par le patron. Une ´etude de cas a ´et´e d´evelopp´ee pour valider notre d´emarche. Cette ´etude de cas a consist´e `a d´erouler un sous-ensemble du processus RUP-A pour la conception d’une application de gestion de missions. L’activit´e de RUP-A sur laquelle nous nous sommes concentr´ee est Find Actors and Use Cases. Nous avons d´eroul´e cette tˆache au sein de CPE pour illustrer notre approche.