Événement de signal

Un événement de signal est un cercle avec un marqueur triangle. Un événement de signal *qui lève* diffuse un signal nommé ; un événement de signal *qui rattrape* attend ce signal. Contrairement à un message — qui a exactement un destinataire — un signal est fire-and-anyone-catches : toute instance de processus (dans n'importe quel processus, dans n'importe quelle piscine) en attente d'un événement de signal rattrapeur portant le même nom va réagir.

Les signaux sont l'équivalent BPMN d'un bus d'événements en architecture logicielle. C'est la façon de modéliser « quand cela arrive, tous ceux qui s'y intéressent le savent » sans lister chaque destinataire explicitement. Un message vous obligerait à dessiner un flux de message par destinataire ; un signal permet à un seul événement d'atteindre tous.

• Annonces à l'échelle de l'entreprise — « produit lancé », « acquisition finalisée », « incident déclaré ». Tout processus à l'écoute réagit.
• Patterns pub/sub — plusieurs écouteurs, un émetteur, et l'émetteur n'a pas besoin de savoir qui écoute.
• Coordination cross-processus — un signal déclenché dans le processus A est rattrapé par B et C sans dessiner de flux de message explicite entre eux.
• Annulation diffusée — un signal arrête-tout tue chaque instance en attente. Utile pour « stopper toute activité, urgence ».

LucidFlow émet des événements de signal quand le document source décrit des notifications un-vers-plusieurs (« annoncer à toutes les équipes », « notifier toute l'organisation »). Chaque signal reçoit un nom canonique dérivé du déclencheur ; les événements rattrapeurs correspondants dans différents diagrammes partagent ce nom et donc la même sémantique de broadcast dans le XML exporté. Le tableau de bord des coûts ne multiplie pas le coût du signal par le nombre d'écouteurs — c'est une propriété logique du broadcast, pas physique — mais la durée de chaque instance rattrapée est suivie séparément.