Un message spécifie l'expéditeur et le destinataire, ainsi que le type de communication ayant lieu entre les lignes de vie. Par exemple, une communication peut appeler une opération à l'aide d'un message d'appel synchrone ou d'un message d'appel asynchrone, lancer un signal à l'aide d'un signal asynchrone et créer ou détruire un participant.
Vous pouvez utiliser les cinq types de message répertoriés dans le tableau ci-dessous pour afficher la communication entre les lignes de vie au cours d'une interaction.
| Message | Description | Exemple |
|---|---|---|
| Message de création | Un message de création représente la création d'une instance au cours d'une interaction. Il est représenté par le mot clé «create». La ligne de vie cible commence au niveau du message de création. | Dans un scénario de banque, par exemple, le responsable peut commencer la vérification du crédit d'un client en envoyant un message de création au serveur. |
| Message de suppression | Un message de suppression représente la suppression d'une instance au cours d'une interaction. Il est représenté par le mot clé «destroy». La ligne de vie cible se termine au niveau du message de suppression. Elle est marquée par un X. | Après avoir commencé un contrôle de crédit, le responsable de la banque peut, par exemple, fermer ou détruire l'application du programme de crédit d'un client. |
| Message d'appel synchrone | Les appels synchrones, qui sont associés à une opération, comportent un message d'envoi et un message de réception. Un message est envoyé de la ligne de vie source vers la message cible. La ligne de vie source est bloquée jusqu'à ce qu'elle reçoive une réponse de la ligne de vie cible. | Le guichetier peut envoyer une demande d'approbation de crédit au responsable. Il doit alors attendre la réponse avant de pouvoir servir le client. |
| Message d'appel asynchrone | Les appels asynchrones, qui sont associés à une opération, ne comportent en général qu'un message d'envoi mais ils peuvent aussi comporter un message de réponse. Contrairement à la situation avec un message synchrone, la ligne de vie source n'est pas bloquée et peut donc recevoir et envoyer d'autres messages. Vous pouvez aussi déplacer individuellement les points d'envoi et de réception afin de retarder le délai entre des événements d'envoi et des événements de réception. Vous pouvez opter pour cette solution si une réponse ne dépend pas du temps ou d'un ordre particulier. | Par exemple, un client peut faire une demande de crédit et il peut recevoir des informations bancaires par téléphone ou retirer de l'argent à un GAB, tout en attendant toujours une réponse à sa demande de crédit. |
| Message de signal asynchrone | Messages de signaux asynchrones associés à un signal. La différence entre un signal et un message repose au niveau des opérations, aucune opération n'étant associée à un signal. Un signal peut représenter une interruption ou un cas d'erreur. Pour définir un signal, vous devez créer un appel asynchrone et en modifier le type dans la vue des propriétés de messages. | Une agence de crédit peut envoyer un message de signal d'erreur au responsable de la banque pour indiquer un problème de connexion au bureau des crédits. |
Le message asynchrone est le seul type de message dont vous pouvez déplacer individuellement le point d'envoi et le points de réception. Vous pouvez déplacer les points d'un message asynchrone pour manipuler le délai entre l'événement d'envoi et l'événement de réception. Le résultat obtenu est appelé message biaisé. Vous pouvez créer un message asynchrone avec ou sans spécification d'exécution de comportement.
Un message auto-dirigé est un message envoyé depuis la ligne de vie source à elle-même. Il peut s'agir d'un appel récursif, d'un appel à une autre opération ou d'un signal appartenant au même objet.
Le message envoyé par la ligne de vie source à la ligne de vie cible représente l'opération ou le signal que la ligne de vie cible met en oeuvre. Vous pouvez nommer et classer les messages. L'apparence de la ligne ou de la pointe de la flèche reflète les propriétés du message. Le tableau suivant décrit les graphiques correspondant aux différents types de message dans les diagrammes UML.
| Type | Graphique | Description | Représentation |
|---|---|---|---|
| Asynchrone | Une flèche dont la pointe est ouverte | Ce graphique représente un signal asynchrone ou un appel asynchrone, pour lequel l'objet source envoie le message et passe directement à l'étape suivante. | |
| Synchrone | Une flèche avec une pointe pleine dirigée vers la ligne de vie destinataire | Ce graphique représente une opération d'appel synchrone dans laquelle l'objet source envoie un message et attend un message de retour de la cible avant de poursuivre. | |
| Renvoi synchrone | |
Une flèche avec un trait tireté et une pointe pleine se dirigeant vers la ligne de vie d'origine | Ce graphique représente un message de retour, d'un appel vers une procédure. Lorsque vous créez un message synchrone, un message de retour est créé par défaut. Vous pouvez changer ce paramétrage par défaut dans la fenêtre Préférences. |
Un message représente soit un appel d'opération, soit l'envoi ou la réception d'un signal. Lorsque le message représente une opération, le nom de cette dernière identifie le message. Les arguments du message sont transmis à la cible. Le message de retour contient les arguments de l'appel d'opération résultant. Lorsqu'un message représente un signal, ce signal représente lui-même les arguments du message. Si le message est un appel synchrone, un message de retour est envoyé de la ligne de vie appelée vers la ligne de vie appelante avant que cette dernière puisse poursuivre.
Vous pouvez identifier les messages à l'aide d'un nom ou d'une signature d'opération. Un nom identifie seulement le nom du message qui n'est pas associé à une opération. Lorsqu'une opération est associée à un message, le nom de l'opération remplace ce nom. La signature de l'opération s'affiche pour permettre d'identifier le nom de l'opération. Vous pouvez utiliser les signatures dans les diagrammes lors de la phase de conception car elles donnent les informations nécessaires aux développeurs pour le codage de la conception.
