Rubriques

Explication Haut de la page

Dans certains cas, un objet dépend d'un événement spécifique ayant lieu dans un autre objet. Si l'événement a lieu dans une frontière ou un objet de contrôle, cet objet informe simplement l'autre objet à propos de l'événement ayant eu lieu. Mais si l'événement a lieu dans un objet d'entité, la situation est quelque peu différente. Un objet d'entité ne pourra peut-être pas informer d'autres objets sur quoi que ce soit si on ne le lui demande pas explicitement.

Exemple

Supposons qu'un système ait été modélisé pour pouvoir retirer de l'argent d'un compte en banque par le biais de transferts. Si une tentative de retrait entraîne un solde négatif sur le compte, un avis doit être immédiatement rédigé et envoyé au client. Le compte, qui est modélisé en tant qu'objet d'entité, ne doit pas se préoccuper du fait que le client soit ou non informé. Un objet frontière doit informer le client.

Dans l'exemple ci-dessus, l'objet frontière doit poser régulièrement la question "l'événement que j'attends a-t-il eu lieu ?" à l'objet d'entité. Pour éclaircir la situation, et repousser les détails d'implémentation jusqu'à la phase de conception, une association spécifique est utilisée pour exprimer ce fait, c'est-à-dire l' association de souscription.

L'association de souscription, qui associe un objet de tout type à un objet d'entité, exprime le fait que l'objet associant sera informé lorsqu'un événement spécifique aura lieu dans l'objet d'entité. Nous vous recommandons de n'utiliser l'association que pour associer les objets d'entité, car c'est la nature passive des objets d'entité qui entraîne le besoin d'une association. Les objets d'interface et de contrôle, cependant, sont tous deux autorisés à débuter la communication. Ainsi, ils n'ont pas besoin d'être "abonnés", mais peuvent exercer leurs responsabilités d'autres manières.

Diagramme UML décrit ci-dessous.

L'association de souscription associe un objet de tout type à un objet d'entité. L'objet associant sera informé lorsqu'un événement spécifique aura lieu dans l'objet d'entité associé.

Notez que la direction de l'association montre que seul l'objet abonnant connaît la relation entre les deux objets. La description de la souscription reste dans le cadre de l'objet abonneur. L'objet d'entité associé est ensuite défini normalement sans prendre en compte le fait que d'autres objets peuvent s'intéresser à cette activité. Cela implique également qu'un objet abonné peut être ajouté ou supprimé du modèle sans changer l'objet auquel il s'abonne.

On attribue à l'association de souscription une multiplicité qui indique à combien d'instances de l'objet cible l'objet associant peut s'associer simultanément. Puis une ou plusieurs conditions sont décrites sur l'association, indiquant ce qui doit avoir lieu afin que l'objet associant soit informé. L'événement peut être un changement de la valeur d'une association ou d'un attribut, ou (d'une partie de) de l'évaluation d'une opération. Lorsque l'événement a lieu, l'objet abonneur sera informé que quelque chose a eu lieu. Notez qu'aucune information au sujet des résultats de l'événement n'est transmise, uniquement le fait que l'événement a eu lieu. Si l'objet associant est intéressé par l'état atteint par l'objet d'entité après l'événement, il devra interagir avec l'objet d'entité de façon classique. Cela signifie qu'il lui faudra également posséder un lien avec lui.

Exemple

Dans le système de traitement des dépôts, des contrôles par sondage doivent être effectués sur les palettes afin de déterminer leur durée de vie. Ainsi, tous les cent déplacements d'une palette d'un endroit à l'autre du dépôt, la palette est vérifiée à une station d'essai spécifique. Ce fait est modélisé par une association de souscription de la classe de contrôle Contrôleur des palettes par sondage à la classe d'entité Palette. Chaque instance de Palette compte le nombre de fois où elle est déplacée, en utilisant un attribut de compteur. Lorsqu'elle a été déplacée cent fois le contrôleur des palettes par sondage en est informé du fait de la condition de l'association de souscription. Le contrôleur des palettes par sondage crée ensuite une Tâche spécifique qui transporte la palette à la station d'essai. Le contrôleur des palettes par sondage n'a pas besoin d'être lié à la palette, mais doit posséder un lien à la Tâche afin de la débuter.

Diagramme décrit dans le texte d'accompagnement.

Lorsqu'une palette a été déplacée cent fois, le contrôleur des palettes par sondage crée une nouvelle tâche.

Les conditions de l'association de souscription doivent s'exprimer en terme de caractéristiques abstraites, plutôt que selon ses attributs ou fonctionnements spécifiques. Ainsi, l'objet associant reste indépendant du contenu de l'objet d'entité associé, qui peut changer.

L'association de souscription n'associe pas toujours deux instances d'objet. Elle est également valide d'une classe à une instance, une méta-relation. Cette relation est décrite dans les sous-sections ci-dessous. Dans certains cas, la classe d'un objet est associée par une association de souscription, par exemple si l'événement spécifique est en fait l'instanciation de la classe.

Utilisation Haut de la page

Association de souscription des classes frontières Haut de la page

Parfois, un objet frontière doit être informé si un événement a lieu dans un objet d'entité. Une association de souscription est alors requise.

Exemple

Examinez le cas d'un retrait d'un compte en banque par le biais de transferts. Dans ce cas, l'objet de contrôle Gestionnaire des transferts effectue des opérations sur l'objet d'entité Compte. Si le solde du compte devient négatif, le client en sera informé par un avis préparé par l'objet frontière Rédacteur d'avis. Ainsi, cet objet possède une association de souscription au Compte. La condition exprimée est que le solde soit inférieur à zéro. Dès que cet événement a lieu, le Rédacteur d'avis est informé. Cette association de souscription spécifique est une association d'instance, dans la mesure où une instance de Rédacteur d'avis vérifie régulièrement l'existence de découverts dans les instances de Compte.

Si le client doit uniquement savoir que son solde est faible, c'est suffisant. Mais s'il doit également être informé du niveau de celui-ci, Rédacteur d'avis doit effectuer une opération sur Compte pour apprendre le montant exact. Pour ce faire, Rédacteur d'avis doit avoir un lien à Compte.

Diagramme décrit dans le texte d'accompagnement.

La classe frontière Rédacteur d'avis s'abonne à l'événement dans lequel le solde tombe sous un certain niveau dans l'objet d'entité Compte. Si Rédacteur d'avis doit également connaître la somme exacte du déficit, il doit posséder un lien à Compte.

Un exemple d'une méta-association d'une classe frontière est lorsqu'un événement dans un objet d'entité entraîne la présentation d'une autre fenêtre à l'utilisateur. Puis une classe d'objet interface s'abonne aux instances de l'objet d'entité.

Association de souscription des classes frontières Haut de la page

Exemple

Dans un système traitant un réseau, des stations fonctionnent en tant que noeuds dans le réseau, et des lignes les connectent entre eux. Chaque station est connectée à d'autres stations par le biais d'un certain nombre de lignes. La capacité d'une station est déterminée par le nombre de ses lignes qui fonctionnent. Si plus de 80% d'entre elles fonctionnent la capacité de la station est élevée, si moins de 20% fonctionnent elle est basse, les pourcentages intermédiaires représentant une capacité moyenne. Dans notre modèle du système, nous avons deux objets d'entité, Station et Ligne, où Station a une association de souscription à Ligne. La condition de l'association est que Station doit être informé lorsque le statut de Ligne, qui peut être activé ou désactivé, est modifié.

De plus, un objet de contrôle qui s'abonne à Station sera informé si la capacité de la station devient faible. Nous décrivons ce cas ci-dessous, en poursuivant cet exemple.

Diagramme décrit dans le texte d'accompagnement.

Une instance de Station est informée dès que le statut d'une de ses instances de Ligne est modifié.

Une association de souscription entre des classes d'entité est presque toujours une association d'instance, dans la mesure où les éléments impliqués sont généralement des instances déjà existantes. Cependant, dans certains cas une instance de l'objet d'entité abonnant peut être créée lorsque l'événement spécifique a lieu dans l'objet d'entité associé. Dans ce cas, l'association passe d'une classe à une instance, c'est-à-dire qu'il s'agit d'une méta-association. On ne peut que supposer lorsqu'une instance d'un objet d'entité spécifique veut être informée de la création d'une nouvelle instance d'un autre objet d'entité.

Association de souscription des classes frontières Haut de la page

Exemple

Dans l'exemple ci-dessus, l'objet d'entité Station possède une association de souscription à l'objet d'entité Ligne. Ainsi, Station sera informé chaque fois que le statut d'une instance de Ligne est changé. Un tel changement de statut changera la capacité de la station. Si la capacité devient faible, c'est-à-dire, si moins de 20% de ses lignes fonctionnent, le système doit trouver de nouveaux chemins adaptés dans le réseau pour éviter cette station. Cette tâche ne dépend évidemment pas de Station, mais doit être effectuée par l'objet de contrôle Superviseur de station, qui possède une association de souscription avec chaque instance de Station.

Diagramme décrit dans le texte d'accompagnement.

L'objet de contrôle Superviseur de station s'abonne à l'objet d'entité Station, qui s'abonne à son tour à l'objet d'entité Ligne.

Dans la majorité des cas, une association de souscription d'un objet de contrôle sera d'une classe à une instance, ou vice-versa, c'est-à-dire, une méta-association. Généralement, l'instance de l'objet de contrôle qui gérera l'événement dans l'objet d'entité n'est pas créée avant que l'événement ait lieu. Mais on peut supposer, par exemple, qu'une instance d'un objet de contrôle veut être informée de la création d'une nouvelle instance d'un objet d'entité spécifique. Ainsi, dans certains cas l' association de souscription peut être une association d'instance.

Exemple

Dans l'exemple ci-dessus, l'association de souscription de Superviseur de station à Station a les caractéristiques d'une méta-station, c'est-à-dire que c'est la classe Superviseur de station qui est informée lorsque la capacité de la Station devient faible. Lorsque Superviseur de station reçoit ce message, il crée une instance gérant l'événement.



RUP (Rational Unified Process)   2003.06.15