Dans cette section, nous allons introduire les principes du calcul de la divergence. Dans le Chapitre II, nous avons choisi l’outil XMLUnit afin de détecter les différences entre deux arbres XML non ordonnés. Cependant, calculer une divergence ne se limite pas à détecter des différences. Il faut pouvoir donner un sens à ces différences afin de pouvoir obtenir la distance « réelle » entre les deux arbres XML (i.e. les modèles attendu et terrain). Le calcul de la distance entre les modèles attendu et terrain fait à la fois appel aux notions de coût, c’est-à-dire au coût minimal des opérations pour passer du modèle attendu au modèle terrain, et d’importance, c’est-à-dire à l’importance que l’on peut donner à une différence détectée plutôt qu’à une autre.
IV.2.1 Le calcul de la divergence
Une approche du calcul de la divergence peut consister à ne comptabiliser que le nombre d’opérations nécessaires sur les caractères pour passer d’une chaîne A à une chaîne B, comme le propose la distance de Levenshtein [Levenshtein, 1966]. Cependant, dans notre cas, cette approche peut se révéler fastidieuse pour rechercher les différences entre des modèles et exploiter le résultat du calcul de la distance. Une autre approche du calcul de la distance d’édition a été généralisée aux arbres et formalisée par [Tai, 1979]. La distance entre deux arbres4
ordonnés est définie comme étant le coût minimal des
opérations (insertion, suppression, modification d’un nœud) à effectuer pour passer d’un modèle à l’autre. Cette expression de la distance est présentée dans le Lemme 1. Plus la distance est petite, plus les arbres sont similaires.
Lemme 1 δ(F, G) = min csuppression(ΓF) + δ(F−ΓF,G); (1) csuppression(ΓG) + δ(F,G−ΓG); (2) cmodif ication(ΓF, ΓG) + δ(T(ΓF) − ΓF,T(ΓG) − ΓG) + δ(F−T(ΓF),G−T(ΓG)); (3) Où :
• F et G sont deux forêts,
• ΓF (respectivement ΓG) est le nœud racine de l’arbre situé le plus à droite de la
forêt F (respectivement G),
• F -T (ΓF (respectivement G-T (ΓG) est la forêt obtenue après entière suppression
de l’arbre le plus à droite de F (respectivement G), • csuppression(v) est de le coût de la suppression du nœud v,
4. Un arbre est un graphe acyclique organisé de manière hiérarchique à partir d’un nœud appelé racine.
• cmodif ication(a,b) est le coût du renommage d’un nœud a pour le transformer en
un nœud b,
• δ(F ,G) est la distance d’édition entre les arbres F et G. Elle est évaluée récursi- vement,
• Les trois opérations de la distance d’édition (1), (2) et (3) représentent respecti- vement la suppression du nœud le plus à droite de F , du nœud le plus à droite de
Get du renommage du nœud le plus à droite de F par le nœud le plus à droite
de G.
Nos arbres de données XML ne sont pas ordonnés donc cette démarche de calcul de la distance d’édition par la droite et toutes celles qui en découlent (comme la stratégie de décomposition par la gauche de [Zhang and Shasha, 1989]) ne nous intéressent pas pour une application directe. En revanche, nous allons nous inspirer de cette démarche en intégrant de coût de l’opération pour toute différence de type ajout, suppression ou modification de nœud. L’aspect désordonné de nos arbres ne pose pas de problème dans la recherche de différences car XMLUnit permet d’ignorer les différences d’ordre dans les relations frères-soeurs lors de la recherche d’écart entre deux arbres XML.
IV.2.2 Le coût de l’opération
Si le coût d’une insertion, suppression ou modification est généralement égal à 1, cette évaluation du coût d’une opération ne convient pas dans le cadre de ces travaux. En effet, compte tenu du contexte dans lequel ce calcul de distance est effectué (à savoir déterminer les évolutions du contexte d’exécution des processus), il serait naturel de différencier ces coûts suivant le type de propriété du contexte concerné (risque, conséquence, service, etc.). En effet, l’ajout d’un risque dans le modèle terrain indique que la situation de la collaboration est potentiellement en train de se dégrader et a donc un impact plus important dans le calcul de la distance que l’ajout d’un service, élément potentiellement bénéfique et avec une portée sur la pertinence des processus collaboratifs a priori plus réduite.
Autrement dit, le coût de l’opération unitaire (insertion, suppression, modification) doit s’exprimer en fonction de l’élément sur lequel l’opération porte.
On peut ainsi définir le coût de l’opération de la façon suivante :
Formule 3 coûtopération = f (operation, concept)
Où :
• L’opération est le type d’édition permettant de passer d’un document à l’autre. Les valeurs possibles sont insertion, suppression, modification.
• Le concept est le type de caractéristique de l’instance du modèle de la situation qui est impacté. Il prend pour valeur l’un des concepts existant dans le modèle de la situation considéré. Dans le cas de la situation de crise nucléaire, les valeurs peuvent être : risque, conséquence, facteur de gravité, facteur de complexité, service, etc.
Par convention, le coûtopération n’est jamais égal à 0 car même si la différence identifiée
est considérée comme mineure, elle existe et ne doit pas être annulée dans le calcul du
delta. L’évaluation se fait sur une échelle ouverte débutant à 1 (coût minimum), le pas
étant de 1.
Les valeurs sont définies par les partenaires de la collaboration, au moment de la caractérisation de la situation collaborative. Ces valeurs peuvent être modifiées au cours du cycle de vie de la collaboration si nécessaire. La liste des coûts peut être représentée par une matrice {operation × concept} contenant l’ensemble des valeurs des coûts en fonction des concepts et des opérations, de la manière suivante :
Table IV.1 – Matrice {operation × concept}
Opération
C
on
ce
p
t Insertion Suppression Modification
Partner 1 4 3
Resource 1 3 1
Service 1 3 2
Risk 3 1 2
. . . .
Cette matrice devient un paramètre d’entrée dans la détection des différences entre les deux documents : dès qu’une différence est détectée par le moteur de XMLUnit et que cette différence est validée par notre algorithme, le coût de l’opération (vis-à-vis du concept impacté) est lu dans la matrice et enregistré pour qualifier la différence.
Dans notre prototype, la matrice est implémentée sous forme de fichier XML, conçu de la façon suivante (Code IV.3).
1 <?xml version="1.0" encoding="UTF-8"?> 2 <parameters>
3 <threshold>5</threshold>
4 <weight id="partner" added="1" deleted="4" updated="3"/> 5 <weight id="resource" added="1" deleted="3" updated="1"/> 6 <weight id="service" added="1" deleted="3" updated="2"/> 7 <weight id="risk" added="3" deleted="1" updated="2"/> 8 </parameters>
Code IV.3 – Extrait du fichier XML contenant les valeurs de la matrice {operation x concept} ainsi que la valeur du seuil δseuil
L’élément weight possède quatre attributs : id qui prend pour valeur le nom du concept,
added, deleted et updated qui prennent respectivement les valeurs du coût de l’opération
IV.2.3 L’importance de l’instance
La nature même des données sur lesquelles nous travaillons nous amène au constat suivant : deux instances d’un même concept peuvent avoir une importance différente, qui exprime leur poids dans le calcul de la distance entre les deux modèles.
Par exemple, prenons deux risques qui sont ajoutés dans le modèle terrain : le pre- mier concerne un risque de contamination de la population par le virus Ebola, le second un risque de contamination de la population par un simple rhume. Il est évident que le risque de contamination par Ebola est plus grave que le risque de contamination par un rhume. Son critère d’importance sera plus élevé que celui du risque de rhume.
L’introduction d’un critère d’importance mi permet de représenter le caractère in-
dispensable ou grave d’une instance de concept, et de classer les instances de concepts entre elles. Ce critère mia une valeur comprise entre 0 (valeur exclue) et 1 (valeur inclue).
Cependant, cette matrice de l’importance des instances est sensible à l’environnement de la collaboration — plus exactement à deux de ses composantes : le temps et le contexte. Elle n’est pas figée une fois pour toutes. Il est possible de la faire évoluer au fur et à mesure du cycle de vie de la collaboration, pour refléter les évolutions des appréciations des éléments caractéristiques de la situation collaborative.
IV.2.3.1 Sensibilité au temps
La sensibilité au temps retranscrit le fait qu’entre l’instant t0 et l’instant t, la façon
dont une instance est perçue peut changer. Par exemple, au début de la réponse à une crise nucléaire, le partenaire IRSN a une valeur plus importante que le partenaire Police
municipale : expert scientifique, le rôle de l’IRSN est indispensable pour aider à la prise
de décision concernant l’établissement d’un périmètre de sécurité. Par contre, à la fin de la gestion de la crise, l’importance de la Police municipale devient plus importante (pour refléter son rôle de protection de la population pour la ramener dans ses habitations, réguler les problèmes de trafic) et celle de l’IRSN décroît.
IV.2.3.2 Sensibilité au contexte
La sensibilité au contexte s’intéresse à la perception de l’instance par rapport aux conditions dans lesquels la collaboration s’effectue. Comme tenu du contexte, une ins- tance peut alors être considérée comme neutre (sans effet notable sur la collaboration et ses workflows), soit positive, soit négative. Prenons l’exemple d’un Risque de pluie. Dans le cas de la réponse à un incendie de grande ampleur, ce risque va avoir une faible importance. Par contre, dans le cas de la réponse à des inondations, cette instance de risque n’est pas négligeable. En effet, l’arrivée de ce nouveau risque peut compromettre la poursuite de la réponse à la crise, voire empirer la situation de crise actuelle.
IV.2.3.3 Stockage
La valeur de l’importance pourrait être indiquée directement dans la définition de l’instance lors de son ajout au modèle. L’utilisation d’une ontologie permettrait de capi- taliser la connaissance sur les critères d’importance en fonction des estimations effectuées par les partenaires de la collaboration lors des collaborations passées et de déduire la valeur de la gravité des nouvelles instances si aucune information sur leur importance n’a été donnée.
Typiquement, si un nouveau service Eteindre un feu de maison est introduit dans le modèle terrain et qu’aucune information n’a été donnée quant à la valeur de son im- portance, le raisonnement sur l’ontologie permet de retrouver le service le plus proche de Eteindre un feu de maison (comme Eteindre un feu domestique) et d’en récupérer la valeur du critère d’importance pour l’affecter à Eteindre un feu de maison.
Ceci étant, la solution du stockage des importances dans une ontologie rend difficile cette prise en compte du temps et du contexte. Dans un premier temps, une solution est de définir manuellement un fichier contenant les tuples {instance ; importance}. Lors du calcul du δ, l’outil de détection ira lire les valeurs des importances pour chacune des instances présentes dans le modèle de la situation
IV.2.4 Le calcul de la distance
Compte tenu des considérations précédentes, nous pouvons proposer la formule de calcul de la distance entre deux modèles suivantes :
Formule 4 δ= n � i=0 δi , avec δi= wi× mi Où :
• δ est la distance globale entre les deux modèles,
• δi est la distance en un point donné entre les deux modèles,
• wi est le coût de l’opération compte tenu du concept auquel appartient l’instance
(i.e. le noeud XML) concernée par la différence détectée, avec wi ∈ N∗,
• mi est l’importance donnée à l’instance, avec 0 < δi �1,
• n est le nombre de différences constatées entre les deux modèles.