Activité :
|
Objet
|
|
Rôle : Concepteur | |
Fréquence : Une fois par itération, pour un ensemble de Artefact : Concevoir les réalisations de cas d'utilisation. | |
Etapes
|
|
Artefacts d'entrée : | Artefacts de sortie : |
Guides d'utilisation de l'outil : | |
Plus d'informations : | |
détails de l'enchaînement des activités : |
Le comportement d'un système peut être décrit en utilisant un certain nombre de techniques - des collaborations ou des interactions. Cette activité décrit l'utilisation des interactions, en particulier des diagrammes de fonctionnement, afin de décrire le comportement du système. Les diagrammes de fonctionnement sont très utiles lorsque le comportement du système ou du sous-système peut être principalement décrit comme une messagerie synchrone. La messagerie non-synchrone, en particulier dans les systèmes déclenchés par l'événement, est souvent décrite plus facilement en terme d'automates à états et de collaborations, ce qui permet de définir de façon compacte les interactions potentielles entre les objets.
L'Artefact : Réalisation de cas d'utilisation permet de suivre le comportement du modèle de conception jusqu'au modèle de cas d'utilisation, et organise des collaborations dans le modèle de conception autour du concept de cas d'utilisation.
Créez une réalisation de cas d'utilisation de conception dans le modèle de conception pour chaque cas d'utilisation à concevoir. Le nom de la réalisation de cas d'utilisation de conception doit être le même que le cas d'utilisation associé, et une relation de "réalisation" doit être établie de la réalisation de cas d'utilisation de conception à son cas d'utilisation associé.
Pour chaque réalisation de cas d'utilisation, vous devez illustrer les interactions entre les objets de conception qui y participent en créant un ou plusieurs diagrammes de fonctionnement. Des versions préliminaires de ces diagrammes peuvent avoir été créées pendant l'Activité : Analyse de cas d'utilisation. Des "versions d'analyse" des réalisations de cas d'utilisation de ce type décrivent les interactions entre les classes d'analyse. Elles doivent être modifiées pour décrire les interactions entre les éléments de conception.
La mise à jour des diagrammes de fonctionnement inclut les étapes suivantes :
Notez qu'il s'agit ici de diagrammes de fonctionnement au niveau du système montrant comment les instances des éléments de conception de haut niveau (généralement les sous-systèmes et les interfaces de sous-système) interagissent. Des diagrammes de fonctionnement montrant la conception interne des sous-systèmes sont produits séparément, dans le cadre de l'Activité: Conception de sous-système.
Notez que les interactions des objets actifs sont généralement décrites en utilisant des collaborations de spécification et des automates à états. Elles doivent être utilisées pour montrer comment les messages peuvent être envoyés à des objets actifs par d'autres éléments du système dans une réalisation de cas d'utilisation de taille plus importante. Généralement, les objets actifs sont encapsulés dans des sous-systèmes pour effectuer cette activité ; ainsi la réalisation de cas d'utilisation consiste en un ensemble de sous-systèmes interagissant ensemble. Les interactions définissent les responsabilités et les interfaces des sous-systèmes. Dans le cadre des sous-systèmes, les objets actifs représentent des fils d'exécution concurrents. Les sous-systèmes permettent de diviser le travail entre les équipes de développement, les interfaces servants de contrats formels entre les équipes.
Commentaire accessoire sur l'affichage des messages provenant des sous-systèmes : le fait de réduire les messages aux interfaces réduit le couplage entre les éléments de modèles et améliore l'élasticité de la conception. Dans la mesure du possible, tentez d'atteindre cet objectif, et lorsqu'il existe des messages provenant de sous-systèmes et destinés à des éléments de modèles ne faisant pas partie de l'interface, essayez de les changer en messages destinés à des interfaces pour améliorer le découplage dans le modèle.
Vous documentez le comportement de cas d'utilisation effectué par les objets dans un diagramme de fonctionnement.
Lorsque vous avez un comportement distribué entre les objets, prenez en compte la manière dont le flot sera contrôlé. Vous avez trouvé les objets en supposant qu'ils interagiraient d'une certaine manière dans la réalisation du cas d'utilisation, et qu'ils auraient un certain rôle. Lorsque vous distribuez le comportement, vous pouvez commencer à tester ces suppositions. Dans certaines sections du flot, vous pouvez décider d'utiliser une structure décentralisée ; dans d'autres, vous pouvez préférer une structure centralisée. Pour obtenir des définitions de ces variantes et des recommandations sur le moment où vous utiliserez les deux types de structure, voir Principes et conseils : Diagrammes de fonctionnement.
Vous aurez peut-être besoin de nouveaux objets à ce stade, par exemple si vous utilisez une structure centralisée et avez besoin d'un nouvel objet pour contrôler le flot. Souvenez-vous que tout objet que vous ajoutez au modèle de conception doit répondre aux exigences faites sur le modèle d'objet.
Pendant l'Activité : Analyse architecturale, des mécanismes d'analyse ont été identifiés. Pendant l'Activité : Identifier des mécanismes de conception, les mécanismes d'analyse ont été affinés en mécanismes de conception, le mappage des mécanismes d'analyse aux mécanismes de conception est consigné dans le document d'architecture logicielle, et les mécanismes de conception sont documentés dans les Principes et conseils relatifs au projet.
Pendant cette activité, la conception des cas d'utilisation, tous les mécanismes de conception applicables sont intégrés aux réalisations de cas d'utilisation. Le concepteur examine les mécanismes de conception disponibles et détermine ceux qui s'appliquent à la réalisation du cas d'utilisation actuellement développé, en travaillant dans le cadre des recommandations et des conseils documentés dans le document d'architecture logicielle et les recommandations de conception.
Commentaire : Un mécanisme de conception applicable peut avoir été identifié dans Activité : Analyse de cas d'utilisation, durant laquelle les classes d'analyse peuvent avoir été "référencées" à un mécanisme d'analyse spécifique, indiquant qu'une fonctionnalité spécifique devait être prise en charge dans la conception. Dans ce cas, les mécanismes de conception applicables sont ceux qui sont associés aux mécanismes d'analyse auxquelles les classes d'analyse participant à la réalisation de cas d'utilisation ont été référencées.
Le concepteur intègre les mécanismes de conception applicables aux réalisations de cas d'utilisation en incluant les éléments de conception et les interactions d'éléments de conception nécessaires dans les réalisations de cas d'utilisation, en suivant les règles d'utilisation documentées dans les recommandations de conception.
Vous devez décrire chaque variante de flot dans un diagramme de fonctionnement séparé. Les diagrammes de fonctionnement sont généralement préférables aux diagrammes de communication car ils sont généralement plus faciles à lire, le diagramme devant contenir le niveau de détails que nous souhaitons généralement lors de la conception du système.
Commencez par décrire le flot de base, qui est le flot d'événements le plus commun ou le plus important. Puis décrivez des variantes comme des flots exceptionnels. Il n'est pas utile de décrire l'intégralité des flots d'événements dans la mesure où vous utilisez et donnez des exemples de toutes les opérations des objets participants. De ce fait, des flots très triviaux peuvent être omis, comme ceux ne concernant qu'un seul objet.
Etudiez le cas d'utilisation pour voir s'il existe d'autres variantes de flot outre celles déjà décrites dans l'analyse et la consignation des exigences, par exemple, ceux dépendant de l'implémentation. En identifiant de nouveaux flots, décrivez chacun d'entre eux dans un diagramme de fonctionnement. Parmi les flots exceptionnels, on peut noter les exemples suivants.
Vous pouvez décrire un chemin alternatif d'un flot en tant que flot optionnel plutôt que comme variante. La liste suivante comporte deux exemples de flots optionnels.
Si vous souhaitez qu'un flot optionnel, ou tout sous-flot complexe, soit particulièrement perceptible, utilisez un diagramme de fonctionnement séparé. Chaque diagramme de fonctionnement séparé doit être renvoyé au diagramme de fonctionnement décrivant le flot principal d'événements par le biais de scripts, de texte dans la marge du document ou de commentaires afin d'indiquer où a lieu le comportement optionnel ou sous-flot.
Dans les cas où le comportement de flot optionnel ou exceptionnel peut avoir lieu partout, par exemple un comportement qui s'exécute lorsqu'un événement spécifique a lieu, le diagramme de fonctionnement du flot principal d'événements doit être annoté pour indiquer que lorsque l'événement a lieu, le comportement décrit dans le diagramme de fonctionnement optionnel/ exceptionnel sera exécuté. Dans le cas contraire, si le comportement est événementiel, envisagez l'utilisation d'un diagramme d'état-transition pour décrire le comportement du système. Pour plus d'information, voir Principes et conseils : diagramme d'état-transition.
Lorsqu'un cas d'utilisation est réalisé, le flot d'événements est généralement décrit selon les objets exécutants, c'est-à-dire comme une interaction entre les objets de conception. Pour simplifier les diagrammes et identifier le comportement réutilisable, vous devrez peut-être encapsuler un sous-flot d'événements dans un sous-système. Ensuite, d'importantes sous-sections du diagramme de fonctionnement sont remplacées par un seul message au sous-système. Dans le sous-système, un diagramme de fonctionnement séparé peut représenter les interactions internes du sous-système qui fournissent le comportement requis (pour plus d'information, voir Activité : Conception de sous-système).
Des sous-séquences de messages dans les diagrammes de fonctionnement doivent être encapsulées dans un système quand :
Une réalisation de cas d'utilisation peut être décrite, si nécessaire, à différents niveaux de la hiérarchie du sous-système. Les lignes de vie du diagramme du milieu représentent des sous-systèmes ; les interactions dans les cercles représentent l'interaction interne des membres des sous-systèmes en réponse au message.
Les avantages de cette approche sont les suivants:
Exemple :
Examinez le diagramme de fonctionnement suivant, qui fait partie d'une réalisation du cas d'utilisation appel local :
Dans ce diagramme, les classes en gris appartiennent au sous-système de prise en charge réseau ; les autres classes appartiennent à un sous-système de prise en charge de la souscription. Cela implique qu'il s'agit d'un diagramme de fonctionnement à multi-sous-systèmes, c'est-à-dire un diagramme dans lequel tous les objets participant au flot d'événements sont inclus, que leurs classes se situent dans des sous-systèmes différents ou non.
Une alternative consiste à montrer l'appel d'un comportement dans le sous-système de prise en charge réseau, et l'exercice d'une interface spécifique sur ce sous-système. Supposons que le sous-système de prise en charge réseau fournit une interface ICoordinator, utilisée par le sous-système de prise en charge des souscriptions :
L'interface ICoordinator est réalisée par la classe Coordinator dans la prise en charge réseau. De ce fait, nous pouvons utiliser le sous-système de prise en charge réseau lui-même et son interface ICoordinator dans le diagramme de fonctionnement, plutôt que des instances de classes dans la prise en charge réseau :
Notez que les instances de classes Coordinator, informations numériques et réseau sont remplacées par le sous-système les contenant. Tous les appels au sous-système passent ainsi par l'interface ICoordinator.
Pour que les sous-systèmes réalisant la même interface puissent se substituer véritablement, seule leur interface doit être visible dans les interactions (et dans les diagrammes en général) ; sinon les interactions (ou les diagrammes) doivent être changées lorsque les sous-systèmes sont substitués l'un à l'autre.
Exemple :
Nous pouvons inclure uniquement l'interface ICoordinator, et non le sous-système qui la produit, dans un diagramme de fonctionnement :
L'envoi d'un message à une ligne de vie d'interface signifie que tout sous-système réalisant l'interface peut être remplacé par l'interface dans le diagramme. Notez qu'aucun message ne part de la ligne de vie de l'interface ICoordinator, dans la mesure où différents sous-systèmes réalisant l'interface peuvent envoyer différents messages. Cependant, si vous souhaitez décrire quels messages doivent être envoyés (ou doivent être autorisés à l'envoi) de n'importe quel sous-système réalisant l'interface, ces messages peuvent partir de la ligne de vie de l'interface.
Dans certains cas il peut être approprié de développer un sous-système plus ou moins indépendamment et parallèlement au développement d'autres sous-systèmes. Pour ce faire, nous devons d'abord trouver des dépendances de sous-systèmes en identifiant les interfaces entre elles.
Cette tâche peut être effectuée ainsi :
Vous pouvez aussi décider d'organiser les diagrammes de fonctionnement en terme de sous-systèmes ou seulement en terme de leurs interfaces. Dans certains projets, il peut même nécessaire d'implémenter les classes fournissant les interfaces avant de continuer avec le reste de la modélisation.
Le but du paradigme orienté objet est d'encapsuler les détails d'implémentation. Ainsi, en ce qui concerne la persistance, nous souhaitons qu'un objet persistant ait le même aspect qu'un objet transitoire. Nous ne devons pas être conscients que l'objet est persistant, ni le traiter différemment de tout autre objet. Du moins, c'est notre objectif.
En pratique, dans certains cas l'application doit contrôler divers aspects de la persistance :
Vous devez prendre en compte deux cas : le moment initial où l'objet est écrit dans la mémoire d'objet persistante, et les moments ultérieurs où l'application souhaite mettre à jour la mémoire d'objet persistante en changeant l'objet.
Dans les deux cas, le mécanisme spécifique dépend des opérations prises en charge par l'infrastructure préfabriquée de persistance. Généralement, le mécanisme utilisé consiste à envoyer un message à l'infrastructure préfabriquée de persistance pour créer l'objet persistant. Une fois qu'un objet est persistant, l'infrastructure préfabriquée de persistance est suffisamment intelligente pour détecter les changements ultérieurs faits sur l'objet persistant et pour les écrire dans la mémoire d'objet persistante si nécessaire (généralement lorsqu'une transaction est exécutée).
Vous trouverez ci-dessous un exemple d'un objet persistant créé :
L'objet PersistenceMgr est une instance de VBOS, une infrastructure préfabriquée de persistance. Le coordinateur de commande crée une commande persistante en l'envoyant comme argument à un message "créer objet persistant" au PersistenceMgr.
Il n'est généralement pas nécessaire de le modéliser de façon explicite à moins qu'il ne soit important de savoir que l'objet est stocké à un point spécifique d'une séquence d'événements. Si des opérations ultérieures doivent interroger l'objet, celui-ci doit exister dans la base de données, et il est donc important de savoir que l'objet existera à cet endroit.
Il est nécessaire de récupérer des objets de la mémoire d'objet persistante avant que l'application puisse envoyer des messages à cet objet. Rappelez-vous que le travail dans un système orienté objet est effectué en envoyant des messages aux objets. Mais si l'objet auquel vous souhaitez envoyer un message est dans la base de données mais pas encore en mémoire, c'est problématique : vous ne pouvez pas envoyer de message à quelque chose qui n'existe pas encore !
En résumé, vous devez envoyer un message à un objet qui sait comment interroger la base de données, récupérer l'objet correct, et l'instancier. Ensuite, et pas avant, vous pouvez envoyer le message d'origine de votre choix. L'objet qui instancie un objet persistant est parfois appelé une classe d'objets. Une classe d'objets est responsable de la création d'instances d'objets, y compris des objets persistants. Après être interrogée, la classe objet peut être conçue pour renvoyer un ensemble d'un ou plusieurs objets correspondant à la requête.
Les objets sont généralement largement connectés les uns aux autres par le biais de leurs associations, il est donc généralement suffisant de récupérer l'objet racine dans un graphique d'objet ; les autres sont essentiellement "retirés"de la base de données de façon transparente par leurs associations avec l'objet racine. (Un bon mécanisme de persistance permet d'effectuer cette action intelligemment : il ne récupère que les objets requis ; sinon, nous pourrions tenter d'instancier un grand nombre d'objets sans que cela ne soit nécessaire. Récupérer des objets avant qu'ils ne soient nécessaires est l'un des principaux problèmes de performance dus à des mécanismes de persistance simplistes.)
L'exemple suivant montre comment la récupération d'objets à partir de la mémoire d'objet persistante peut être modélisée. Dans un véritable diagramme de fonctionnement, le SGBD ne sera pas affiché, car il sera encapsulé dans la classe objet.
Le problème des objets persistants est très simple : ils persistent ! Contrairement aux objets temporaires qui disparaissent lorsque le processus qui les a créé meurt, les objets persistants existent jusqu'à ce qu'ils soient supprimés explicitement. Il est donc important de supprimer l'objet lorsqu'il n'est plus utilisé.
Le problème, c'est que c'est difficile à déterminer. Le fait qu'une application a fini d'utiliser un objet ne signifie pas que toutes les applications, présentes et futures, en ont terminé. De plus, dans la mesure où les objets peuvent avoir et ont effectivement des associations dont ils ne sont même pas conscients, ce n'est pas toujours facile de déterminer s'il faut supprimer un objet.
Pendant la conception, on peut représenter ce fait de façon sémantique en utilisant des diagrammes d'état : lorsque l'objet atteint l'état de fin, on peut le désigner comme libéré. Les développeurs responsables de l'implémentation des classes persistantes peuvent ensuite utiliser les informations du diagramme d'état-transition pour appeler le comportement de mécanisme de persistance approprié afin de libérer l'objet. Le concepteur de la réalisation du cas d'utilisation est chargé d'appeler les opérations appropriées pour que l'objet atteigne son état de fin lorsqu'il doit être supprimé.
Si un objet est largement connecté à d'autres objets, il peut être difficile de déterminer si cet objet doit être supprimé. Dans la mesure où une classe d'objets connaît la structure de l'objet ainsi que les objets auxquels il est connecté, il est souvent utile de charger la classe d'objets d'une classe de déterminer si une instance spécifique peut être supprimée. L'infrastructure préinstallée de persistance peut aussi prendre en charge cette capacité.
Les transactions définissent un ensemble d'interrogations d'opérations qui sont atomiques ; soit elles sont toutes effectuées, soit aucune d'entre elles n'est effectuée. Dans le contexte de la persistance, une transaction définit un ensemble de changements effectuée sur un ensemble d'objets qui sont soit tous exécutés soit aucun d'entre eux. Les transactions permettent une cohérence, en garantissant que des ensembles d'objets se déplacent d'un état cohérent à l'autre.
Il y a plusieurs possibilités pour afficher les transactions dans les réalisations de cas d'utilisation :
Représenter les frontières de transaction en utilisant des commentaires textuels.
Un diagramme de fonctionnement montrant des messages explicites pour débuter et terminer les transactions.
Si toutes les opérations définies dans une transaction ne peuvent pas être exécutées (généralement parce qu'une erreur a eu lieu), la transaction est abandonnée, et tous les changements faits pendant la transaction sont annulés. Les conditions d'erreurs prévues représentent souvent des flots d'événements exceptionnels dans les cas d'utilisation. Dans d'autres cas, les conditions d'erreur ont lieu à cause d'une défaillance du système. Les conditions d'erreur doivent être également documentées dans les interactions. Les erreurs et les exceptions simples peuvent être montrées dans l'interaction lorsqu'elles ont lieu ; les erreurs et les exceptions complexes peuvent nécessiter leurs propres interactions.
Les modes de défaillance d'objets spécifiques peuvent apparaître dans les diagrammes d'état. Le flot conditionnel de traitement du contrôle de ces modes de défaillance peut être montré dans l'interaction dans laquelle l'erreur ou l'exception a lieu.
La simultanéité décrit le contrôle de l'accès à des ressources systèmes vitales lors d'une transaction. Pour que l'état du système demeure cohérent, une transaction peut demander à ce que celui-ci ait un accès exclusif à certaines ressources clé du système. L'exclusivité peut inclure la capacité de lire un ensemble d'objets, d'écrire un ensemble d'objets ou à la fois de lire et d'écrire un ensemble d'objets.
Voici un exemple simple des raisons pour lesquelles nous pouvons être amenés à restreindre l'accès à un ensemble d'objets. Supposons que nous exécutons un simple système de saisie des commandes. Les clients appellent pour prendre commande, et nous traitons les commandes et les expédions. Nous pouvons considérer la commande comme un type de transaction.
Pour illustrer le besoin d'un contrôle de la simultanéité, supposons que j'appelle pour commander une nouvelle paire de chaussures de marche. Lorsque la commande est saisie dans le système, celui-ci vérifie que le type de chaussures de marche que je souhaite et que la taille correcte est en stock. Si c'est le cas, il faut réserver cette paire, afin que personne d'autre ne puisse les acheter avant que la commande ne soit envoyée. Une fois que la commande est envoyée, les chaussures sont supprimées du stock.
Entre le moment où la commande est prise et où elle est envoyée, les chaussures sont dans un état particulier—elles sont en stock, mais "portées" à ma commande. Si ma commande est annulée pour quelque raison que ce soit (j'ai changé d'avis, ou ma carte de crédit est périmée), les chaussures retournent en stock. Une fois la commande envoyée, nous supposons que notre petite entreprise ne souhaite pas garder de trace du fait qu'elle possédait les chaussures auparavant.
L'objectif de la simultanéité, comme des transactions, est de s'assurer que le système passe d'un état cohérent à un autre. De plus, la simultanéité s'attache à s'assurer qu'une transaction possède toutes les ressources nécessaires pour terminer son travail. Le contrôle de la simultanéité peut être implémenté de nombreuses différentes façons, y compris le verrouillage de ressource, les sémaphores, les verrous de mémoire partagée, et les espaces de travail personnalisés.
Dans un système orienté objet, il est difficile de déterminer, uniquement à partir des patterns de message, si un message spécifique entraînera un changement d'état dans un objet. De plus, les diverses implémentations peuvent prévenir le besoin de restreindre l'accès à certains types de ressources ; par exemple, certaines implémentations fournissent à chaque transaction sa propre vue de l'état du système au début de la transaction. Dans ce cas, d'autres processus peuvent changer l'état d'un objet dans affecter la "vue" de toute autre transaction exécutante.
Pour éviter d'entraver l'implémentation, pendant la conception nous souhaitons seulement indiquer les ressources auxquelles la transaction doit avoir un accès exclusif. En utilisant notre exemple précédent, nous souhaitons indiquer que nous avons besoin d'un accès exclusif aux chaussures que nous avons commandées. Une alternative simple consiste à annoter la description du message envoyé en indiquant que l'application requiert un accès exclusif à l'objet. L'implémenteur peut ensuite utiliser cette information pour déterminer la meilleure façon d'implémenter l'exigence de simultanéité. Un exemple de diagramme de fonctionnement montrant une annotation indiquant quels messages nécessitent un accès exclusif est montré ci-dessous. On suppose que tous les verrouillages sont supprimés lorsque la transaction est terminée.
Exemple montrant un contrôle d'accès annoté dans un diagramme de fonctionnement.
On ne limite pas l'accès à tous les objets nécessaires à une transaction car dans bien des cas seuls quelques objets doivent avoir des restrictions d'accès ; restreindre l'accès à tous les objets participant à une transaction gâche des ressources de valeur et pourrait créer, plutôt que d'éviter, des goulots d'étranglement de performance.
Dans le flot d'événements de la réalisation du cas d'utilisation vous devrez peut-être ajouter des descriptions supplémentaires aux diagrammes de fonctionnement, lorsque le flot d'événements n'est pas suffisamment clair à partir du simple examen des messages envoyés entre les objets participants. Des exemples incluent des cas où des commentaires au sujet du calendrier ou du comportement conditionnel ou des éclaircissements sur le comportement d'opération sont nécessaires afin de faciliter la lecture des diagrammes pour les observateurs externes.
Le flot des événements est initialement décrit dans l'Activité : Analyse de cas d'utilisation. Dans cette étape vous affinez le flot d'événements selon les besoins afin de clarifier les diagrammes de fonctionnement.
Souvent, le nom de l'opération ne suffit pas pour comprendre pourquoi l'opération est effectuée. Des commentaires textuels ou des scripts dans la marge du diagramme peuvent être nécessaires afin de clarifier le diagramme de fonctionnement. Il peut être également nécessaire d'utiliser des commentaires textuels et des scripts pour représenter le flot de contrôle comme les étapes décisionnaires, la mise en boucle et l'ébranchage. De plus, des balises textuelles peuvent s'avérer nécessaire afin de mettre en corrélation les points d'extension du cas d'utilisation et des emplacements spécifiques des diagrammes de fonctionnement.
Des exemples précédents de cette activité ont illustré un certain nombre de façons d'annoter les diagrammes de fonctionnement.
Au fur et à mesure que les cas d'utilisation sont réalisés, vous devez unifier les classes et les sous-systèmes de conception identifiés pour garantir l'homogénéité et la cohérence du modèle de conception.
Eléments à prendre en compte :
Vérifiez le modèle de conception à ce stade pour vous assurer que votre travail va dans la bonne direction. Il est inutile de réviser le modèle en détails, mais prenez en compte les Points de contrôle pour le modèle de conception lorsque vous travaillez sur celui-ci.
Voir en particulier points de contrôle pour les réalisations de cas d'utilisation dans l'Activité: Réviser la conception.
Vous pouvez utiliser une classe mandataire pour représenter le sous-système dans des diagrammes de fonctionnement. Cette classe mandataire est contenue dans le sous-système et est utilisée pour représenter le sous-système dans des diagrammes ne prenant pas en charge l'utilisation directe de packages et de sous-systèmes en tant qu'éléments comportementaux. Utilisez la classe mandataire dans les cas où vous souhaitez montrer qu'un sous-système spécifique répond à un message. Dans ce cas, vous pouvez montrer des messages envoyés du sous-système mandataire à d'autres objets.
Référez-vous à Différences entre UML 1.x et UML 2.0 pour plus d'informations.
RUP (Rational Unified Process)
|