Le mécanisme de réaction aux événements est le processus qui commence à la génération d’un événement, et se termine quand l’exécution de tous les gestionnaires d’événement est 4. Dans l’implémentation décrite au chapitre6par exemple, cette notification est faite avec une requête HTTP de type POST.
terminée. Afin d’expliquer ce mécanisme, nous introduisons les concepts de hiérarchie de parenté d’éléments et de remontée d’événement.
5.5.1 Hiérarchie de parenté d’éléments
Un lien de parenté est défini entre éléments d’un modèle CMSPEM, selon les règles sui-vantes :
– Chaque élément de modèle a au plus un élément “parent”.
– Les éléments qui n’ont pas de parent sont appelés “éléments de premier niveau”. – Si un élément A est le parent d’un élément B, B est appelé “élément fils” de A.
– Un élément A est appelé “ancêtre” d’un élément B si, et seulement si, A est l’élément parent de B, ou s’il existe un élément C, tel que C est le parent de B et A est ancêtre de C.
– Chaque modèle a un unique “élément racine”, qui est élément “ancêtre” de tout autre élément5.
Les règles de parenté dans CMSPEM sont comme suit : – Tout❘♦❧❡❯s❡ est parent des ❆❝t♦r associés.
– Tout❲♦r❦Pr♦❞✉❝t❯s❡ est parent des ❆❝t♦r❙♣❡❝✐✜❝❆rt✐❢❛❝t associés. – Tout❚❛s❦❯s❡ est parent des ❆❝t♦r❙♣❡❝✐✜❝❲♦r❦ associés.
– Toute relation❈▼❙P❊▼ (❆❝t♦r❘❡❧❛t✐♦♥s❤✐♣, ❆❝t♦r❙♣❡❝✐✜❝❆rt✐❢❛❝t❘❡❧❛t✐♦♥s❤✐♣, ❆❝t♦r✲ ❙♣❡❝✐✜❝❲♦r❦❘❡❧❛t✐♦♥s❤✐♣, ❲♦r❦❆ss✐❣♥♠❡♥t, ❆rt✐❢❛❝t❖✇♥❡rs❤✐♣, ou ❆rt✐❢❛❝t❯s❡) est élément fils de chacun des concepts qu’il lie.
5.5.2 Remontée d’événement
Un événement peut être traité, non seulement par les gestionnaires définis sur la source de l’événement, mais aussi par des gestionnaires définis sur n’importe quel ancêtre de la source de l’événement. En effet, un événement généré par un élément est aussi généré par tous ces ancêtres. On dit que l’événement “remonte” vers le haut. Ce mécanisme est inspiré du modèle DOM (Document Object Model) utilisé dans les navigateurs internet.
La remontée d’événement est nécessaire pour rendre compte de la nature évolutive des modèles de processus logiciel, qui peuvent être enrichis à tout moment par de nouveaux élé-ments de modèle. Pour pouvoir écouter un événement, il faut spécifier l’élément qui génère cet événement. Il est donc impossible, à priori, de spécifier qu’un écouteur est intéressé par les événements qui peuvent être émis par un élément de modèle qui n’est pas présent dans le modèle lors de la souscription. Par exemple, un gestionnaire peut demander à être noti-fié chaque fois qu’un attribut est modinoti-fié sur un ActorSpecificWork qui est contenu dans un 5. Cet élément peut être défini librement par chaque implémentation. Dans le prototype décrit dans le chapitre
certain TaskUse. Sans la remontée d’événement, ceci peut être fait seulement pour les Ac-torSpecificWorks déjà présents dans le modèle. Avec la remontée d’événement, le gestionnaire d’événement peut tout simplement écouter l’événement sur le TaskUse. Tous les événements6 générés par un ActorSpecificWork présent ou futur, ayant le TaskUse comment parent, attein-drons le TaskUse.
Quand un événement remonte vers les ancêtres de l’élément source, un ancêtre sur lequel aucun gestionnaire n’a été défini ne réagira tout simplement pas.
FIGURE5.1 – Exemple de prise en compte d’événement
La figure 5.1 montre un exemple des différentes étapes de prise en compte d’un événe-ment. E est un type d’événement, et e un événement spécifique de type E. H1 et H2 sont des gestionnaires d’événement. S1 et S2 sont des sources d’événement, et S2 est l’ancêtre de S1. Sub1 et Sub2 sont des souscriptions d’événement. Les étapes, depuis la souscription jusqu’à la prise en compte de l’événement e sont les suivantes :
1. Sub1 est défini comme une souscription sur la source S1, pour les événements de type E, et H1 est spécifié comme gestionnaire. De même, Sub2 est défini comme une sous-cription sur la source S2, pour les événements de type E, et H2 est spécifié comme gestionnaire. L’ordre dans lequel les souscriptions Sub1 et Sub2 sont définies n’a aucune importance. La seule contrainte est que les souscriptions Sub1 et Sub2 soient définies avant que l’événement e ne se produise.
2. L’événement e (de type E) se produit, et S1 est sa source. 6. Du type approprié, spécifié lors de la souscription.
3. Les souscriptions d’événement ayant S1 comme source sont consultées. Pour chacune de ces souscriptions, dont le type d’événement associé est E, le gestionnaire associé est invoqué, avec les paramètres propres à l’événement e. Dans le cas de la figure5.1, H1 est le seul gestionnaire correspondant. Si plusieurs gestionnaires étaient définis, ils seraient invoqués l’un après l’autre, dans l’ordre de définition.
4. Tous les gestionnaires invoqués dans l’étape précédente terminent leur exécution. Dans ce cas, l’exécution de H1 se termine.
5. Si le gestionnaire H1 a mis fin à la remontée de l’événement e, la prise en compte de l’événement s’arrête ici. Sinon, l’événement e remonte.
6. L’événement e est envoyé à l’élément parent de S1. La procédure de l’étape 3 est répétée pour toutes les souscriptions dont la source est le parent de S1. Quand la prise en compte est terminée sur le parent de S1, l’événement remonte de nouveau.
7. L’événement finit par atteindre l’ancêtre S2 de S1. Les souscriptions d’événement dont la source est S2 sont consultées. Pour chacune de ces souscriptions dont le type d’évé-nement associé est E, le gestionnaire associé (H2 dans ce cas) est invoqué. Chaque ges-tionnaire est invoqué avec les paramètres de l’événement e.
Les événements peuvent avoir des paramètres arbitraires, selon leur type. Cependant, pour les besoins de la remonté d’événement et la réaction aux événements, deux paramètres stan-dards sont toujours transmis aux gestionnaires :
source
L’élément (EventSource) sur lequel le gestionnaire a été défini. Quand l’événement re-monte, ce paramètre est continuellement mis à jour. Sa valeur correspond toujours à l’élément sur lequel le gestionnaire en cours d’exécution a été défini.
originalSource
L’élément sur lequel l’événement s’est produit à l’origine, avant toute remontée. Pour chaque événement, la valeur de ce paramètre reste la même, même quand l’événement est traité par des gestionnaires définis sur les ancêtres, lors de la remontée d’événement. Quand un événement est généré initialement par une source, source et originalSource sont identiques. Ils diffèrent seulement lors de la remontée d’événement, quand l’événement est traité par des gestionnaires définis sur des ancêtres de sa source originale.
Dans l’exemple de tableau de bord introduit dans les sections5.4.3 et5.4.4, la remontée d’événement entre en jeux. En effet, une seule souscription S à l’événement ActorSpecific-WorkStart est définie, et l’élément racine du modèle est spécifiée comme source. Le tableau de bord TB est défini comme EventHandler. A chaque début d’❆❝t♦r❙♣❡❝✐✜❝❲♦r❦ (événement e de type ActorSpecificWorkStart, associé à un ❆❝t♦r❙♣❡❝✐✜❝❲♦r❦ ASW), une souscription spécifiant ASW comme source est recherchée. Dans ce cas, il n’en existe pas. L’événement e remonte donc, l’un après l’autre, les éléments parents de ASW. Éventuellement, l’élément ra-cine est atteint. Lors de la recherche de souscriptions ayant pour source cet élément rara-cine, la souscription S est trouvée. Le type d’événement de e (ActorSpecificWorkStart) correspondant à celui de la souscription S, l’EventHandler associé (TB, le tableau de bord) est notifié.