Instructions: Association d'abonnement
L'association d'abonnement précise qu'un objet doit être averti chaque fois qu'un événement particulier se produit dans l'objet d'entité associé. Ces instructions expliquent comment utiliser cette relation.
Relations
Description principale

Explication

Il arrive qu'un objet soit dépendant d'un événement déterminé se produisant dans un autre objet. Si l'événement a lieu dans un objet frontière ou de contrôle, celui-ci informe simplement l'autre objet de ce qui se passe. En revanche, si l'événement se produit dans un objet d'entité, la situation est différente. Un objet d'entité peut en effet ne pas pouvoir informer d'autres objets s'il n'est pas sollicité pour le faire.

Exemple

Imaginez un système modélisé avec la capacité de retirer de l'argent d'un compte bancaire via des transferts. Si une tentative de retrait entraîne un solde négatif sur le compte, une notification doit immédiatement être rédigée et envoyée au client. Le compte, modélisé comme un objet d'entité, ne doit pas être impliqué dans la notification éventuelle du client. Un objet frontière s'en charge à la place.

Dans l'exemple ci-dessus, l'objet frontière devrait poser la question "l'événement attendu s'est-il produit ? " à plusieurs reprises à l'objet d'entité. Pour que la situation soit plus claire et pour reporter les détails d'implémentation jusqu'à la phase de conception, une association spéciale est utilisée pour exprimer l'association d'abonnement.

L'association d'abonnement, qui associe n'importe quel objet à un objet d'entité, signale que l'objet d'association sera informé lorsqu'un événement particulier se produit dans l'objet d'entité. Nous vous conseillons d'utiliser l'association uniquement pour associer des objets d'entité, sachant que la nature passive de ces objets crée le besoin d'association. Les objets d'interface et de contrôle sont pour leur part autorisés à établir une communication. Par conséquent, il est inutile de s'y abonner et ils peuvent assumer leurs responsabilités d'autres façons.

Diagramme UML décrit ci-dessous.

L'association d'abonnement associe n'importe quel objet à un objet d'entité. L'objet d'association est averti lorsqu'un événement particulier se produit dans l'objet d'entité associé.

Vous remarquez que le sens de l'association montre que seul l'objet d'abonnement a connaissance de la relation entre les deux objets. La description de l'abonnement reste dans le cadre de l'objet d'abonnement. L'objet d'entité associé est quant à lui défini de façon habituelle sans considérer que d'autres objets peuvent être intéressés par sa tâche. Un objet d'abonnement peut donc aussi être ajouté ou supprimé du modèle sans modifier l'objet auquel il est abonné.

Une multiplicité est attribuée à l'association d'abonnement pour indiquer combien d'instances de l'objet ciblé peuvent être associées simultanément par l'objet d'association. Ensuite, une ou plusieurs conditions sont décrites dans l'association et indiquent ce qui doit se produire pour que l'objet d'association soit informé. L'événement peut correspondre à un changement de la valeur d'une association ou d'un attribut, ou bien (une partie de) l'évaluation d'une opération. Quand l'événement a lieu, l'objet d'abonnement est informé que quelque chose s'est passé. Aucune information sur les résultats de l'événement n'est transmise, mais seulement sur le fait qu'il a eu lieu. Si l'objet d'association veut connaître l'état résultant de l'objet d'entité après l'événement, il doit interagir avec cet objet de façon habituelle. Pour ce faire, il a aussi besoin d'une liaison à cet objet.

Exemple

Dans le système de gestion de dépôt, des vérifications ponctuelles doivent être effectuées pour les palettes afin d'évaluer leur durée de vie. Par conséquent, au bout de cent mouvements d'un endroit à l'autre du dépôt, une palette subit une vérification à un poste spécial de test. L'opération est modélisée par une association d'abonnement, du vérificateur de palettes de la classe de contrôle à la palette de la classe entité. Chaque instance de palette compte le nombre de fois qu'elle est déplacée à l'aide d'un attribut de compteur. Au bout de cent déplacements, le vérificateur de palettes est averti en raison de la condition de l'association d'abonnement. Il crée alors une tâche spéciale transportant la palette au poste de test. Le vérificateur de palettes n'a pas besoin de liaison, mais il lui faut une tâche pour l'initialisation.

Diagramme décrit dans le texte d'accompagnement.

Une fois une palette déplacée cent fois, le vérificateur de palettes crée une nouvelle tâche.

Les conditions de l'association d'abonnement doivent être exprimées en termes de caractéristiques abstraites, au lieu d'attributs ou d'opérations spécifiques. Ainsi, l'objet d'association reste indépendant du contenu de l'objet d'entité associé, qui peut très bien changer.

L'association d'abonnement n'associe pas toujours deux instances d'objet. Elle est également valide d'une classe vers une instance (métarelation). Vous en trouverez la description dans les sous-sections qui viennent. Il arrive aussi que la classe d'un objet soit associée par une association d'abonnement : par exemple, si l'événement particulier correspond à l'instanciation de la classe.

Utilisation

Associations d'abonnement à partir de classes frontière

Il est parfois nécessaire pour un objet frontière d'être informé si un événement a lieu dans un objet entité. Il faut alors une association d'abonnement.

Exemple

Prenez le cas d'un retrait d'un compte bancaire au moyen de transferts. L'objet de contrôle du gestionnaire de transferts se charge alors des opérations sur l'objet d'entité du compte. Si le solde du compte s'avère négatif, le client reçoit une notification préparée par l'objet frontière du rédacteur de notifications. Cet objet a donc une association d'abonnement au compte. La condition énoncée est que le solde est inférieur à zéro. Dès que l'événement se produit, le rédacteur de notifications est averti. Cette association d'abonnement est une association d'instance, vu qu'une instance du rédacteur de notifications recherche constamment des découverts dans les instances du compte.

Si le client ne doit recevoir aucune information sauf la notification que le solde est bas, cette démarche est suffisante. S'il doit en revanche savoir dans quelle mesure ce solde est bas, le rédacteur de notifications doit réaliser une opération sur le compte pour connaître le montant exact. Pour ce faire, il doit posséder une liaison au compte.

Diagramme décrit dans le texte d'accompagnement.

La classe frontière du rédacteur de notifications s'abonne à l'événement de solde passant en dessous d'un certain niveau dans l'objet d'entité de compte. Si le rédacteur de notifications doit également connaître la quantité exacte de découvert, il lui faut une liaison au compte.

Exemple de méta-association d'une classe frontière : un événement dans un objet d'entité provoque l'ouverture d'une nouvelle fenêtre. Une classe d'objet/d'interface s'abonne alors aux instances de l'objet d'entité.

Associations d'abonnement à partir de classes entité

Exemple

Dans un système gérant un réseau, des postes fonctionnent comme des noeuds dans le réseau et des lignes les connectent entre eux. Chaque poste est connecté à d'autres via plusieurs lignes. La capacité d'un poste dépend du nombre de lignes actives. Si plus de 80 % des lignes fonctionnent, la capacité du poste est élevée ; si moins de 20 % fonctionnent en revanche, la capacité est faible. Entre ces deux valeurs, elle est moyenne. Dans notre modèle de système figurent deux objets d'entité que sont Poste et Ligne, sachant que Poste possède une association d'abonnement à Ligne. La condition de l'association est que Poste soit informé lorsque que le statut de Ligne change (activé ou désactivé).

Par ailleurs, un objet de contrôle qui s'abonne à Poste est informé si la capacité du poste devient faible. Vous trouverez la description ci-dessous avec la suite de cet exemple.

Diagramme décrit dans le texte d'accompagnement.

Une instance Poste est avertie dès que le statut de l'une des instances Ligne change.

Une association d'abonnement entre des classes entité est presque toujours une association d'instance, sachant qu'elle concerne en général des instances existant déjà. Toutefois, il peut arriver qu'une instance de l'objet d'entité d'abonnement soit créée lorsque l'événement indiqué se produit dans l'objet d'entité associé. Dans ce cas, l'association va d'une classe à une instance et il s'agit donc d'une méta-association. Il est aussi possible qu'une instance d'un objet d'entité donné souhaite être informée de la création d'une nouvelle instance d'un autre objet d'entité.

Associations d'abonnement à partir de classes de contrôle

Exemple

Dans l'exemple précédent, l'objet d'entité Poste a une association d'abonnement à celui Ligne. Il est donc informé chaque fois que le statut d'une instance Ligne change. Ce changement de statut modifie la capacité du poste. Si la capacité devient faible (moins de 20 % de ses lignes fonctionnent), le système doit trouver de nouveaux chemins sur le réseau afin que ce poste soit évité. Cette tâche ne concerne évidemment pas Poste, mais elle doit être exécutée par l'objet de contrôle Superviseur de postes, qui possède une association d'abonnement à chaque instance de Poste.

Diagramme décrit dans le texte d'accompagnement.

L'objet de contrôle Superviseur de postes s'abonne à l'objet d'entité Poste, lequel s'abonne à son tour à l'objet d'entité Ligne.

Le plus souvent, une association d'abonnement depuis un objet de contrôle se fera d'une classe à une instance ou inversement (méta-association). En général, l'instance de l'objet de contrôle qui traitera l'événement dans l'objet d'entité n'est pas créée tant que l'événement ne s'est pas produit. Il est aussi possible qu'une instance d'un objet de contrôle souhaite par exemple être informée de la création d'une nouvelle instance d'un certain objet d'entité. Aussi, dans certains cas, l'association d'abonnement peut être une association d'instance.

Exemple

Dans l'exemple ci-dessus, l'association d'abonnement du superviseur de postes au poste présente les caractéristiques d'une méta-association : il s'agit en effet de la classe Superviseur de postes informée lorsque la capacité du poste devient faible. Lorsque le superviseur de postes reçoit ce message, il crée une instance traitant l'événement.