Instructions: Evénement métier
Les événements métier représentent d'importantes occurrences dans les tâches quotidiennes de l'entreprise. Ces instructions expliquent comment les modéliser.
Relations
Eléments connexes
Description principale

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. 

Exemple UML accompagnant le texte.

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.

Exemple UML accompagnant le texte.

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.

Exemple UML accompagnant le texte.

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.

Exemple UML accompagnant le texte.

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.

Exemple UML accompagnant le texte.

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.

Exemple UML accompagnant le texte.

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.

Exemple UML accompagnant le texte.

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.

Exemple UML accompagnant le texte.

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.