Les liens entre les concepts

D’après le méta-modèle de la crise, nous pouvons constater qu’un risque est traité par une activité, qui elle-même est réalisée par un acteur de la cellule de crise. Les liens entre risque et activité ainsi qu’entre partenaire et activité sont définis via des mécanismes exposés dans les travaux de thèse de [Mu, 2012] et [Boissel-Dallier, 2012] dans le cadre du projet MISE. La Figure III.3 positionne l’étape de préparation et de réponse à la crise par rapport au projet MISE. Nous pouvons voir qu’en phase de préparation les ontologies et la doctrine fournissent des éléments de réponse théoriques à des problèmes : soit sous forme de correspondance {activité ; problème}, soit sous forme de processus. En phase de réponse, le modèle de la crise permet de définir les problèmes réels ainsi que les composants du système étudié.

FigureIII.3 – Positionnement de l’étape d’obtention des liens entre problèmes et solu-

tions dans MISE

A partir des données provenant du modèle et de la phase de préparation, les processus collaboratifs de réponse à la crise sont déduits. Puis le passage des processus métier aux workflows exécutables est rendu possible grâce à la réconciliation sémantique1_{. Cette}

1. Il s’agit ici d’un abus de langage, car les travaux de [Boissel-Dallier, 2012] portent sur la réconci- liation syntaxo-sémantique.

dernière s’appuie sur la gouvernance fonctionnelle et non-fonctionnelle des services, afin de réaliser le meilleur choix possible pour affecter un (ou des) service technique à une (ou plusieurs) activité métier (correspondance n-m entre les activités et les services). A ce stade là de la conception du SI de médiation, nous connaissons les liens entre les services et les activités, ainsi que les liens entre les activités et les problèmes identifiés dans la situation de crise. Il est donc possible de connaître les liens entre les risques/conséquences (problèmes) et les services (ou solutions) qui vont tenter de les résoudre.

La définition de tous ces liens est accessible à tout moment à partir du fichier XML

ServiceChoose.xml dans laquelle elle est enregistrée (voir Code III.1).

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>

<serviceChoose xmlns="http://www.enstimac.fr/mise/demio/crisis/servicechoose"> <problemes>

<probleme id="Contamination" name="Contamination" type="Risk" state="ko" priority="1"/>

<probleme id="Intoxiques_Lourds" name="Intoxiques_Lourds" type="Consequence" state="ko" priority="2"/>

</problemes> <solutions>

<solution id="Decontaminer" name="Decontaminer" state="selected" actor="SAMU" tx_acc="1.0" wip="wait"/>

<solution id="Soigner" name="Soigner" state="possible" actor="SAMU" tx_acc=" 1.0" wip="wait"/>

</solutions> <linkPBSols>

<linkPBSol id="DecontaminerContamination" service="Decontaminer" probleme=" Contamination" confiance="1" state="possible"/>

<linkPBSol id="DecontaminerIntoxiques_Lourds" service="Decontaminer" probleme ="Intoxiques_Lourds" confiance="1" state="selected"/>

</linkPBSols> <linkSolSols>

<linkSolSol id="Decontaminer&amp;Soigner" from="Decontaminer" to="Soigner" type="post"/>

</linkSolSols> <linkSolConds>

<linkSolCond id="DecontaminerVictime(s) evacuee(s)" service="Decontaminer" condition="Victime(s) evacuee(s)" type="needs"/>

<linkSolCond id="DecontaminerVictime(s) decontaminee(s)" service="

Decontaminer" condition="Victime(s) decontaminee(s)" type="fulfills"/> </linkSolConds>

</serviceChoose>

CodeIII.1 – Exemple de fichier des liens entre risque, conséquence et service • <problemes> : il regroupe toutes les instances de <probleme> qui représentent

les risques et conséquences à traiter. L’attribut state permet de savoir si une solution a été trouvée pour répondre au problème de façon couvrante (ok), de façon partielle (okcould) ou si aucune solution n’a été trouvée (ko). Par défaut, en sortie du moteur d’inférence, la valeur est égale à ko [Truptil, 2011],

• <solutions> : il contient les éléments <solution> qui décrivent les services des partenaires via un nom, un état de sélection (sélectionné, possible), le partenaire propriétaire de ce service, un état d’avancement de l’exécution du service et un taux d’accessibilité. L’accessibilité traduit l’existence de pré-requis et/ou de post- requis pour la solution. S’il n’y en a pas, la valeur est fixée à 1.

• <linkPBSols> : les éléments <linkPBSol> qu’il contient permettent de faire le lien entre un problème donné et une solution donnée (le problème et la solution doivent exister dans le fichier ServiceChoose.xml). L’élément <linkPBSol> per- met de savoir si l’association problème-solution a été retenue (attribut d’état) et la confiance que l’on donne dans cette association.

• <linkSolSols> : il permet de spécifier les pré-requis et post-requis d’une activité. Par exemple, on ne peut exécuter la solution Soigner que si l’on a exécuté la solution Décontaminer au préalable,

• <linkSolConds> : il détaille les conditions ou pré-requis (needs) et les réalisations (fulfills) d’une solution.

L’obtention du fichier ServiceChoose.xml se fait de manière semi-automatique (voir les travaux de [Truptil, 2011], [Mu, 2012] et [Boissel-Dallier, 2012]). Le modèle de la situation de crise (qui représente le système étudié) ainsi que la liste des acteurs et de leurs compétences sont injectés dans une ontologie. L’exécution du moteur d’inférence permet d’obtenir le fichier ServiceChoose.xml. Ce dernier propose à chaque acteur une liste de problèmes à trier en fonction de sa criticité ainsi qu’une liste de solutions, c’est-à- dire une liste de compétences pouvant résoudre les problèmes identifiés. Les acteurs de la cellule de crise (les décideurs plus précisemment) affinent les propositions en attribuant une criticité à chaque problème et en validant ou non les propositions de solution. Une fois ce fichier paramétré par les acteurs, il sert d’entrée pour les outils de déduction des processus collaboratifs. Le fichier XSD définissant le format du fichier ServiceChoose.xml est disponible en Annexe E.