Comme nous l’avons souligné dans le chapitre précédent, le résultat δ de la compa- raison des modèles terrain et attendu contient des informations sur les origines de la divergence entre les deux modèles. Il faut donc analyser le contenu du δ pour pouvoir conseiller une adaptation possible des processus collaboratifs, en vue d’atteindre le but de la collaboration.
Dans cette section, nous allons présenter les trois types de recommandations d’adap- tation candidates : la caractérisation de la situation collaborative, la redéfinition du réseau collaboratif et la réexécution d’un service. Pour chaque type d’adaptation, nous exposerons les conditions dans lesquelles il est recommandé. Nous détaillerons également les algorithmes d’appel des fonctions associées aux trois types de recommandation.
Ce travail préparatoire nous permettra d’aborder la Section V.4 en ayant les clés de compréhension nécessaires pour définir les mécanismes de choix d’une recommandation d’adaptation compte tenu des évolutions détectées dans les modèles terrain et attendu.
V.3.1 Caractérisation de la situation collaborative
A ce niveau là de l’adaptation, il convient de caractériser la situation collaborative sur la base des éléments transmis par le terrain afin d’en avoir une photographie réaliste représentant la situation collaborative telle qu’elle est à l’instant t.
Il est tout à fait possible de réutiliser le modèle terrain obtenu lors de l’exécution du Service d’Agilité (dans la phase de mise à jour des modèles). En effet, ce modèle est mis à jour à l’aide des événements émis par le terrain de la collaboration et se veut être l’image la plus fidèle possible de la réalité. Ce modèle terrain est injecté en entrée du modeleur.
Adaptation_Caracterisation(mT errain)
Cet algorithme permet de redéfinir le modèle de la collaboration
Paramètres : mTerrain : le modèle terrain de la situation collaborative Début
Si (mTerrain <> vide) Alors
Action : TransformerModele(mTerrain) Action : OuvrirModeleur(mTerrain) Sinon
Action : Afficher(’Le fichier est vide, merci de changer de fichier’)
mTerrain ← Action : Action : valeur_saisie() Adaptation_Caracterisation(mTerrain)
Fin Si Fin
L’algorithme Adaptation_Reseau est appelé si la recommandation d’adaptation re- tenue correspond à la redéfinition totale du réseau collaboratif. Dans ce cas, le Service d’Agilité bascule vers le modeleur de la situation collaborative afin que l’utilisateur puisse éventuellement enrichir ou modifier la caractérisation de la situation. L’utilisa- teur ne part pas d’un modèle vide (le Service d’Agilité vérifie ce point en amont). Le modeleur est initialisé avec le modèle terrain existant à l’instant où la détection d’une divergence a déclenché une adaptation (OuvrirModeleur(mTerrain)).
Il est à noter que le modèle terrain –qui est un flux XML respectant le formalisme dé- fini dans le Chapitre III– doit être transformé (TransformerModele(mTerrain)) de façon à respecter le format d’entrée du modeleur (format JSON), permettant ainsi l’affichage des éléments graphiques symbolisant les données contenues dans le modèle terrain.
V.3.2 Redéfinition du réseau collaboratif
Compte tenu de sa structure, la dynamique collaborative peut être affectée par les modifications apportées aux acteurs et/ou à leurs services. Par exemple, la disparition ou l’ajout d’un partenaire de la collaboration a un impact sur la situation collaborative par suppression ou apport de services mis à disposition de la dynamique collaborative.
L’évolution des compétences mises à disposition de la collaboration peut donc se traduire par une remise en cause partielle ou totale des choix effectués quant à la sélection des activités et leur ordre d’exécution. Il faut noter que l’évolution du catalogue des activités disponibles peut avoir des impacts :
• Négatifs : typiquement avec la disparition d’une activité utilisée dans les proces- sus. Il faut donc trouver une activité ou une combinaison d’activités permettant d’atteindre les objectifs (dans le cadre de la gestion de crise, prévenir un risque ou traiter un fait),
• Mélioratifs : la mise à disposition d’une nouvelle activité peut conduire au rem- placement d’une activité sélectionnée auparavant par cette nouvelle activité, si celle-ci présente une couverture plus étendue ou plus adaptée quant au problème qu’elle doit traiter.
Adaptation_Reseau(mT errain, services, ontologie, liensM T ) Cet algorithme permet de redéfinir la dynamique collaborative
Paramètres : mTerrain : le modèle terrain de la situation collaborative
services : la liste des Web Services à remplacer ontologie : l’ontologie de collaboration
liensMT : la liste des liens entre les activités métier et les Web Services
Début
Si (mTerrain <> vide ET ontologie <> vide ET liensMT <> vide ET services <>
vide) Alors
Action : OuvrirModeleur(mTerrain, services, ontologie, liensMT) Sinon
Action : Afficher(’Les fichiers sont vides, merci de changer de fichiers’) Fin Si
Fin
L’algorithme Adaptation_Reseau est appelé si la recommandation d’adaptation re- tenue correspond à la redéfinition partielle du réseau collaboratif. Dans ce cas, le Ser- vice d’Agilité bascule vers l’outil de réconciliation syntaxo-sémantique (OuvrirMode-
leur(mTerrain, services, ontologie, liensMT)). Cet outil prend en entrée les informations
concernant la caractérisation de la collaboration (modèle terrain), l’ontologie de collabo- ration, la liste des Web Services qu’il faut éventuellement remplacer, et enfin la liste des liens entre activités métier et Web Services (issue de la réconciliation syntaxo-sémantique précédente).
V.3.3 Réexécution d’un service
Dans ce type d’adaptation, il ne s’agit pas de modifier la dynamique collaborative établie, mais d’en exécuter à nouveau une certaine partie afin de répondre à un dysfonc- tionnement dans le déroulement des workflows de réponse à la crise. Le dysfonctionne- ment recouvre deux notions :
d’obtenir le résultat escompté (cas du largage d’eau censé refroidir les réacteurs de Fukushima Daiichi),
• La panne d’un service : ce dernier n’a pu s’exécuter correctement, pour des raisons diverses.
La différenciation entre la panne et l’inefficacité est possible en regardant l’état du service incriminé. Si le service est à l’état terminé, et que l’élément qu’il devait traiter (risque, conséquence, facteur aggravant ou de complexité) est toujours présent dans le modèle terrain, alors on peut en déduire qu’il s’agit d’une inefficacité du service. La cause peut en être une description initiale partielle de la situation collaborative ou une évolution majeure de la situation collaborative, conduisant ainsi au choix d’un service inadapté au contexte réel. Si le service est à l’état failed, la cause est la panne du service. Cette différenciation est importante pour permettre la capitalisation de connaissances et l’apprentissage sur la réponse à la crise.
Adaptation_Execution(mT errain, services)
Cet algorithme permet de redéfinir le modèle de la collaboration
Paramètres : mTerrain : le modèle terrain de la situation collaborative
services : tableau contenant les clés-valeurs (identifiant, état) des services à réexécuter
Début
Si (services <> vide) Alors
Action : Afficher(’Les services suivant sont à l’état de :’)
– ∴ – Tous les services et leurs états respectifs sont listés à l’utilisateur
Action : Afficher(’Pour exécuter à nouveau les services, taper 1, sinon taper
2’) choix ← Action : Action : valeur_saisie()
Si (choix == 1) Alors Action : Administration_Processus(services) Sinon Action : Adaptation_Reseau(mTerrain) Fin Si Sinon
Action : Afficher(’Le tableau des Services est vide, adaptation interrompue’) Fin Si
Fin
L’algorithme Adaptation_Execution présente le comportement du Service d’Agilité quand la recommandation d’adaptation retenue est de type réexécution de service. Après avoir vérifié qu’il existe au moins un service à réexécuter, le Service d’Agilité présente à l’utilisateur la liste des services concernés et lui propose de les exécuter à nouveau. Si l’utilisateur accepte cette solution, le Service d’Agilité va appeler l’outil de suivi et d’administration des workflows2 . Cela permet à l’utilisateur de demander une seconde
2. Cet outil est proposé par l’orchestrateur fractalisé [Faure et al., 2009] et lui fournit la liste des services concernés à travers la fonction Administration_Processus(services). Il permet non seulement de
exécution des services concernés dans les processus collaboratifs.
Si l’utilisateur refuse cette possibilité (car il y a un nombre trop important de ser- vices inefficaces ou en panne, par exemple), le Service d’Agilité va alors proposer de re- venir au niveau de la caractérisation de la dynamique collaborative du SIM en appelant la fonction Adaptation_Reseau(mTerrain) (dont nous avons détaillé le fonctionnement précédemment). L’utilisateur reprendra la main sur la sélection des services et leur ordre d’exécution, afin de modifier les workflows déployés. Ces workflows exécutables suivent la logique décrite dans les processus BPMN et ne la modifient pas.