La mise à jour du modèle terrain

Le modèle terrain MT est maintenu à jour uniquement grâce aux événements pro-

venant du terrain : Mesure, Alerte, Demande, Offre, Statut de ressource, Instruction, Rapport. Le CEP va analyser, filtrer et/ou dériver ces événements entrants et émettre des événements sortants. Ces événements sortants sont construits en fonction des règles métier décrites dans le CEP (ces règles sont dépendantes de la situation collaborative

considérée) et contiennent les informations nécessaires pour modifier le modèle terrain. Nous avons vu que le modèle terrain est un flux XML contenant une liste hiérarchisée d’éléments tels que des partenaires (partner), des services (services), des biens matériels (goods), etc. Chacun de ces éléments (que nous appellerons instance par la suite) contient à minima deux informations : un identifiant unique, un nom. Or les événements émis par le CEP (sur le sujet eventField) ont pour but la mise à jour du modèle terrain et donc de modifier ou supprimer des instances existantes ou de créer de nouvelles instances dans ce modèle. Chaque événement émis sur le sujet eventField va contenir l’identifiant unique de l’instance contenue dans le modèle.

Ces événements sont récupérés par l’outil de mise à jour à travers son abonnement au sujet eventField mis à disposition par le CEP. L’outil de mise à jour va pour chaque événement reçu rechercher l’existence de l’instance du concept correspondante dans le modèle, grâce à son identifiant unique (transmis par l’événement). Si l’instance existe, cela signifie que ses caractéristiques seront à mettre à jour (modification ou suppression) en fonction des données portées par l’événement. Si l’instance n’est pas retrouvée, alors elle n’existe pas dans le modèle terrain et l’outil de mise à jour des modèles va la créer. L’identifiant unique de l’instance provient des données portées par l’événement. Il ne faut surtout pas le confondre avec l’identifiant unique de l’événement (qui permet de l’identifier dans le nuage des événements, lors d’un envoi ou d’une réception, etc.). Par exemple, dans le cas d’un événement Alerte (qui hérite de Situation), l’identifiant de l’instance est la propriété ComponentSEID (Identifiant du composant du Système Etudié). Si l’instance est concernée par un événement de type Instruction ou Rapport, son identifiant sera la propriété ActivityID.

L’algorithme de mise à jour du modèle MT est le suivant (Algorithme MAJMode-

leTerrain(mTerrain, evenement)). On suppose qu’à la réception de la notification de

l’événement, ce dernier est extrait de « l’enveloppe » de la notification (qui est au for- mat XML) et est transformé en l’objet Java correspondant. La manipulation de l’objet Java facilite l’accès aux propriétés de l’événement, telles que son type (Risque, Consé-

quence, ...), etc.. Ces informations sont nécessaires pour créer ou mettre à jour l’instance

concernée par l’événement.

M AJ M odeleT errain(mT errain, evenement)

Cet algorithme permet de mettre à jour le modèle terrain

Paramètres : mTerrain : le modèle terrain de la situation collaborative

evenement : l’objet événement, transmis par le CEP

Variables : tablInstancesIds : le tableau de chaînes, qui contient les identifiants de

tous les éléments composant le modèle terrain

instanceId : l’identifiant de l’instance d’un élément du modèle terrain, concerné par l’événement

drapeau : booléen permettant de vérifier si on a retrouvé l’instance (indiquée dans l’événement) à l’intérieur du modèle terrain

Début

instanceId ← Action : Récupérer l’identifiant de l’instance porté par l’événement

...suite...

tablInstancesId ← Action : Récupérer les identifiants des éléments du modèle ter- rain

drapeau ← FAUX

Si (tablInstancesIds <> vide) Alors

Pour i variant de 1 à taille(tablInstancesIds) Faire Si (instanceId == tablInstancesIds[i]) Alors

Action : MAJElement(instanceId, evenement, mTerrain)

– ∴ – On change la valeur du drapeau à VRAI drapeau ← VRAI

Fin Si Fin Pour

Si (drapeau<>VRAI) Alors

Action : CreerElement(instanceId, evenement, mTerrain) Fin Si

Fin Si Fin

Cet algorithme prend donc en entrée le modèle terrain et l’événement reçu. Il va tester l’existence de l’élément concerné par l’événement dans le modèle terrain. Par exemple, si l’événement concerne une instance d’identifiant H2G2_42, l’algorithme va chercher l’existence d’une instance d’identifiant H2G2_42 dans le modèle terrain. Si l’instance existe, alors l’action à mener est de type mise à jour (ce qui signifie modification ou sup- pression, suivant les autres données contenues dans l’événement). Si l’instance n’existe pas, cela signifie qu’il faut l’ajouter au modèle, et donc la créer.

Afin de savoir sur quel concept (Service ? Risque ? Consequence ? etc.) s’appuyer pour créer une nouvelle instance dans le modèle terrain MT, ou pour modifier les propriétés

d’une instance existante dans le modèle terrain MT, les méthodes MAJInstance() et

CreerInstance() prennent en paramètre l’objet evenement.

Le paramètre instanceId sert à indiquer l’identifiant de l’instance à mettre à jour ou à créer, selon le cas. Enfin, on passe également en argument le modèle terrain tel qu’il est juste avant la mise à jour.

A partir de cet objet, il est aisé de retrouver le type de l’événement et par là même le concept dont hérite l’instance concernée par l’événement. Les méthodes d’accès aux propriétés de l’objet événement permettent de récupérer les valeurs de ses attributs et de les affecter aux propriétés pertinentes de l’instance considérée.

Une table de correspondance entre les caractéristiques de l’événement entrant et les composants du modèle a été réalisée. Elle permet de retranscrire les informations portées par l’événement afin de mettre à jour les éléments concernés dans le modèle. Eût égard à son volume, l’ensemble de cette table de correspondance n’est pas présentée dans le corps de texte du manuscrit. Elle est disponible en Annexe J. Seul un extrait est présenté ci-dessous (Figure III.10).

Figure III.10 – Correspondance entre l’événement Alert généré par le CEP et les élé- ments du modèle terrain

Cet extrait de la table de correspondance montre les équivalences entre les propriétés de l’événement Alert et les propriétés des éléments du modèle terrain qui sont concernés, à savoir Risk ou Consequence et link. La valeur de ComponentSEID portée par l’évé- nement correspond à la valeur de l’élément concerné côté modèle terrain. Si jamais cet élément n’existe pas dans le modèle, cela signifie que l’événement va provoquer la créa- tion de cet élément dans le modèle terrain. Dans ce cas, pour savoir quel type d’élément créer, il suffit de récupérer la valeur de la propriété Type de l’événement (qui prend pour valeur soit Risk soit Consequence).

En outre, un Risk ou une Consequence s’appliquant sur un composant du système étudié, un lien doit être créé entre le nouveau Risk (ou Consequence) créé et le Goods (ou People, NaturalSite, CivilianSociety) impacté. Pour cela, un élément link sera éga- lement créé dans le modèle terrain et ses attributs from et to prendront les valeurs de

ComponentSEID et de ImpactedComponentSEID.

Conclusion intermédiaire Compte tenu des considérations architecturales précé-

dentes et de la présentation des moyens mis en œuvre pour réaliser la mise à jour des modèles, nous pouvons compléter la Figure III.4 vue en Section III.1.4 par la Figure III.11

Les événements émis par la collaboration et son environnement sont collectés par le moteur de CEP (via abonnement aux huit types d’événements propres au contexte de la crise). Les EPA du CEP se partagent deux rôles : celui de simplement filtrer les événements typés Activité, et celui de filtrer puis créer de nouveaux événements sur la base de ceux entrants (de type autre qu’Actitivé). Ces événements filtrés ou produits par le CEP sont respectivement émis sur les sujets eventExpected et eventField.

L’outil de mise à jour des modèles s’abonne à ces deux sujets. Suivant le sujet dont est issu l’événement reçu, l’outil va mettre à jour soit le modèle attendu (événement dont le sujet d’abonnement est eventExpected) soit le modèle terrain (événement dont le

FigureIII.11 – Des évéments à la mise à jour des modèles : un traitement de type CEP et une analyse des événements émis par le CEP

sujet d’abonnement est eventField). Pour chaque modèle, l’outil de mise à jour dispose de règles de traitement qui font appel à la correspondance entre les informations portées par les événements entrants et le contenu du modèle.