Explication
Les événements métier représentent d'importantes occurrences dans les tâches quotidiennes de l'entreprise. Il y a bien
sûr des milliers de choses qui se passent chaque jour dans et autour de l'entreprise. Les événements métier nous
permettent de gérer la complexité en ce concentrant sur ce qui est vraiment important. Ils sont, en ce sens-là,
importants au niveau de l'architecture. Ils possèdent les caractéristiques suivantes :
-
Ils représentent une occurrence significative, c'est-à-dire importante.
-
Ils apparaissent de manière aléatoire ou, tout au moins, de manière imprévisible.
-
Ils se produisent indépendamment les uns des autres.
-
Ils ont pour résultat une action immédiate de l'entreprise.
Un événement métier ne possédant pas l'une de ces caractéristiques est suspect.
Ces événements sont déclenchés et reçus par les acteurs métier, les travailleurs métier et les entités métier, dans le
cadre de leurs interactions menant à la réalisation de cas d'utilisation métier. Ils peuvent être déclenchés par :
-
Les acteurs métier pour indiquer le début ou la fin d'un cas d'utilisation métier. Par exemple, lorsqu'un
fournisseur livre ses marchandises, un événement métier livraison indique le début du cas d'utilisation métier
livraison de marchandises.
-
Les entités métier pour indiquer un changement d'état. Par exemple, pour un cas d'utilisation métier recrutement
des employés, un événement métier CandidatQualifié indiquerait que les références d'un employé potentiel ont été
vérifiées.
-
Les travailleurs métier pour indiquer un point précis dans une réalisation de cas métier. Par exemple, pour une
fusée qui vient d'être lancée, un événement métier Lancement indiquerait que le suivi de la trajectoire de la fusée
peut démarrer.
-
L'écoulement du temps. Par exemple, six heures après qu'un patient soit sorti de la salle d'opération, un événement
métier EtatPatient indiquerait qu'une infirmière doit vérifier l'état du patient.
Modélisation d'événements métier
Les événements métier peuvent contenir des informations qui fournissent davantage de contexte sur l'occurrence que
l'événement représente. Ces informations sont modélisées en tant qu'attributs de la classe d'événement métier, comme le
montre cette figure. Les attributs d'un événement métier peuvent être déterminés en considérant quelles informations
les récepteurs de l'événement requièrent pour prendre des mesures.
Il y a une association entre les événements métier qui représentent les changements dans l'état des entités métier et
l'entité métier à laquelle ils sont liés, comme le montre cette figure. Cela permet aux récepteurs de l'événement
métier d'accéder à l'entité métier en question et de récupérer les informations nécessaires.
Les acteurs métier, travailleurs métier et entités métier peuvent à la fois déclencher et recevoir les événements
métier. La classe qui déclenche un événement métier est appelée éditeur, alors que la classe qui reçoit un
événement métier est appelée abonné.
Un éditeur nécessite une dépendance de type <<envoyer>> aux événements métier qu'il va déclencher, comme le
montre cette figure.
Un abonné nécessite une opération de type <<événement métier>>, portant le même nom que l'événement métier
et des paramètres qui correspondent aux attributs de ce dernier, comme le montre cette figure. Notez bien que la
signature des opérations doit toujours être cohérente avec le nom et les attributs de l'événement métier.
Une autre approche est d'inventer une dépendance de type <<recevoir>>, de l'abonné à l'événement métier,
bien que ce ne soit pas conforme au langage UML. Les signatures de l'opération peuvent se déduire de toutes les
dépendances <<recevoir>>. Vous trouverez dans la figure un exemple de cette approche non standard.
Le déclenchement des événements métier est montré dans les diagrammes d'interaction ou les diagrammes d'activité. Dans
les diagrammes d'interaction, l'éditeur envoie un message asynchrone au récepteur avec le nom de l'événement métier.
Vous trouverez un exemple dans la figure. Notez que le message est asynchrone. Cela indique que l'éditeur n'attend pas
que l'abonné ait fini de traiter l'événement métier pour continuer. L'éditeur déclenche plutôt l'événement métier et
continue directement ce qu'il était en train de faire. L'abonné quant à lui commence à traiter les événements métier
dès leur réception. Cela représente davantage la réalité que les messages synchrones.
Dans les diagrammes d'activité, l'éditeur déclenche l'événement métier. Le récepteur reçoit l'événement métier, soit
dans le même diagramme, soit dans un diagramme différent. Vous trouverez un exemple dans la figure.
Recherche d'événements métier
Lorsqu'on donne un nom à une association entre un acteur métier et un cas d'utilisation métier, un événement métier
correspondant peut être utilisé pour signaler le moment où le cas d'utilisation métier est initié, ce qui serait une
occurrence significative pour l'entreprise.
Analysez les interactions entre les travailleurs métier dans les diagrammes de séquence. Pour chaque message entre les
travailleurs métier, considérez les points suivants :
-
Localisation - Les messages passés entre deux travailleurs métier situés à des endroits différents sont des
événements métier potentiels.
-
Temps - Les messages dans lesquels le temps écoulé entre le déclenchement et la réception est important sont des
événements métier potentiels.
-
Objectif - Les messages ayant pour résultat des actions dont l'objectif diffère selon les actions qui ont déclenché
les événements métier sont des événements métier potentiels.
-
Responsabilité - Les messages établis par un travailleur métier avec différentes responsabilités sont des
événements métier potentiels.
L'analyse des frontières des systèmes métier aide à identifier les différences au niveau des objectifs et des
responsabilités.
Dans les diagrammes d'activité, vous devez considérer si une action est requise directement avant ou après chaque
tâche, ou s'il faut notifier une partie du résultat d'un point de décision.
Les entités métier fournissent aussi des indices sur les événements métier. Toutes les opérations importantes d'une
entité métier sont des événements métier potentiels. Les diagrammes état-transition pour les entités métier sont très
utiles. Les transitions d'état indiquent les événements métier potentiels car ils peuvent représenter un changement
d'état métier.
Lorsqu'on identifie les événements métier, il est utile d'imaginer un bureau dans lequel les entités métier sont les
dossiers, et où les employés lisent, modifient ces dossiers et les transportent de boîtes en boîtes. Dès qu'il faut
faire des copies d'une partie d'un dossier pour pouvoir l'envoyer vers des destinations différentes, vous pouvez avoir
découvert un événement métier - il y a en effet plusieurs destinataires. De même, lorsqu'un travailleur métier doit
écrire une note après avoir exécuté une tâche, dont l'objectif est d'informer d'autres personnes, cette tâche doit
aussi être qualifiée en tant qu'événement métier. Bien sûr, les dossiers ne traînent pas sur les bureaux toute la
journée ; ils sont classés. Lorsque vous devez prendre un dossier dans le classeur de rangement ou ranger un dossier
dans ce classeur, considérez ce qui vous a mené à prendre ou à ranger ce dossier. L'occurrence qui vous a mené à
prendre ou ranger un dossier peut être un événement métier.
Généralisation d'événements
métier
On peut regrouper les événements métier en catégories ou groupes de "familles" d'événements en définissant des
relations de généralisation entre des événements métier plus généraux et des événements métier plus spécialisés. Cela
permet aux parties qui ne sont pas intéressées par les différents sous-types d'événements métier de traiter plusieurs
types d'événements de la même façon.
Le diagramme ci-dessus montre que la maladie, l'absence ou le décès sont des versions spécialisées de l'absence d'un
employé. En définissant l'absence comme supertype, cela permet à chacun des trois sous-types d'être traité comme une
absence. Dans une société de conseil, par exemple, le responsable de clientèle doit informer le client qu'un employé
est absent et le faire remplacer, sans tenir compte de la raison de cette absence. Le responsable de clientèle
s'intéresse donc seulement à l'événement métier Absence. La réceptionniste, par contre, peut être amenée à effectuer
une action particulière si un employé tombe malade, comme appeler un médecin ou faire envoyer des fleurs. Le
responsable des ressources humaines et le supérieur de l'employé doivent être informés si l'employé décède.
Dans cet exemple, nous voyons que la spécialisation des événements métier est utile lorsque différentes parties doivent
entreprendre des actions différentes en réponse à des circonstances différentes (particulières). La généralisation des
événements métier est utile lorsque certaines parties répondent à certains événements métier de la même façon, sans
tenir compte des circonstances particulières.
En pratique, bien sûr, la partie concernée sera probablement avertie de l'événement (spécialisé) réel. Si un employé
décède, le responsable clientèle sera bien sûr aussi averti, mais l'action entreprise sera la même. La hiérarchisation
d'un événement métier permet de créer un modèle d'analyse métier plus simple et plus compréhensible.
Automatisation des événements métier
Cela paraît logique d'automatiser la définition, le déclenchement et la propagation des événements métier mais ce n'est
pas toujours pratique à faire. Il est parfois plus cher de construire un système permettant cette automatisation que
d'envoyer un e-mail à un collègue. Les questions à prendre en compte lorsque vous envisagez l'automatisation des
événements métier sont les suivantes :
-
le coût d'achat ou de l'implémentation et de la maintenance d'un système qui automatise les aspects de la gestion
des événements
-
la faisabilité au niveau technique d'une solution automatisée
-
le coût de solutions alternatives non-automatisées
-
l'impact de ne pas déclencher ou recevoir certains événements
-
la possibilité que certains événements dépassent les frontières métier à l'avenir
-
les canaux de notification disponibles actuellement
Dans une architecture orientée services, les messages servent à découpler certains systèmes logiciels les uns des
autres et à les découpler des localisations physiques. Les messages asynchrones peuvent aussi être utilisés pour
découpler les systèmes logiciels dans le temps. Les événements métier seront implémentés en tant que messages dans ces
types de systèmes logiciels, bien que tous n'auront certainement pas un événement métier associé. Une application très
utile des événements métier est l'EAI (intégration d'applications d'entreprise). Chaque application définit ici un
nombre d'événements métier auxquels d'autres applications peuvent s'abonner. Cela permet aux applications d'interagir
sans que l'interaction soit directe.
Considérez par exemple une compagnie d'assurance ayant une application de guichet pour gérer les interactions des
clients, les offres et les contrats. Elle a aussi une application de traitement des opérations pour gérer les produits
et les polices d'assurance. Lorsqu'un client demande une proposition, l'application de guichet collecte les
informations nécessaires concernant le client et l'objet assuré. A partir de ces informations, le système
d'administration des produits calcule alors les primes et délivre une police d'assurance préliminaire liée à une
proposition. Lorsque le client accepte l'offre, le système d'administration des polices doit finaliser la police
d'assurance. Dans cet exemple, deux messages sont déconnectés au niveau du temps, de la localisation et de la
responsabilité : CalculerPrime et FinaliserPolice. Cependant, seul le message FinaliserPolice serait modélisé en tant
qu'événement métier car il demeure un élément important en dehors du contexte actuel.
|