Rubriques

Introduction Haut de la page

Dans la majorité des cas, nous utilisons un diagramme de fonctionnement pour illustrer les réalisations de cas d'utilisation (voir Artefact : Réalisations de cas d'utilisation), c'est-à-dire pour montrer comment les objets interagissent pour effectuer le comportement dans l'intégralité ou une partie d'un cas d'utilisation. Un ou plusieurs diagrammes de fonctionnement peuvent illustrer les interactions d'objet qui déterminent un cas d'utilisation. Généralement, l'organisation consiste en un diagramme de fonctionnement pour le flot principal d'événements et un diagramme de fonctionnement pour chaque sous-flot indépendant du cas d'utilisation.

Les diagrammes de fonctionnement sont particulièrement importants pour les concepteurs car ils éclaircissent les rôles des objets dans un flot et fournissent ainsi des données de base pour déterminer les responsabilités et les interfaces des classes.

Contrairement à un diagramme de communication, un diagramme de fonctionnement comporte des séquences chronologiques, mais n'inclut pas de relations d'objet. Les diagrammes de fonctionnement et de communication expriment des informations similaires, mais les montrent de manière différente. Les diagrammes de fonctionnement montrent la séquence explicite de messages et sont préférables lorsqu'il est important de visualiser le classement chronologique des messages. Lorsque vous vous intéressez aux relations structurelles entre les instances d'une interaction, utilisez un diagramme de communication. Voir Principes et conseils : Diagrammes de communication pour plus d'informations.

Contenu des diagrammes de fonctionnement Haut de la page

Les diagrammes de fonctionnement peuvent contenir des instances d'objet et d'acteur, ainsi que des messages décrivant comment ils interagissent. Le diagramme décrit ce qui a lieu dans les objets participants, en terme d'activations, et de communication des objets par l'envoi de messages les uns aux autres. Vous pouvez réaliser un diagramme de fonctionnement pour chaque variante du flot d'événements d'un cas d'utilisation.

Diagramme décrit dans le texte d'accompagnement.

Un diagramme de fonctionnement qui décrit une partie du flot d'événements du cas d'utilisation Emettre un appel local dans un simple centre d'hébergement des communications.

Objets Haut de la page

Un objet est montré en tant que trait discontinu vertical appelé "ligne de vie". La ligne de vie représente l'existence de l'objet à un moment donné. Un symbole d'objet est dessiné en en-tête de la ligne de vie, mentionnant le nom de l'objet et sa classe soulignés et séparés par deux points :

nomobjet : nomclasse

Vous pouvez utiliser des objets dans les diagrammes de fonctionnement de la manière suivante :

  • Une ligne de vie peut représenter un objet ou sa classe. Ainsi, vous pouvez utiliser une ligne de vie pour modéliser le comportement de classe et d'objet. Cependant, une ligne de vie représente généralement tous les objets d'une classe donnée.
  • La classe d'un objet peut être non spécifiée. Normalement, vous créez un diagramme de fonctionnement, en utilisant d'abord des objets, et vous spécifiez leurs classes ultérieurement.
  • Les objets peuvent être non nommés, mais vous devez les nommer si vous souhaitez différencier les différents objets d'une même classe.
  • Plusieurs lignes de vie du même diagramme peuvent représenter différents objets de la même classe ; mais, comme nous l'avons précisé plus tôt, les objets doivent être nommés pour que vous puissiez les différencier.
  • Une ligne de vie qui représente une classe peut exister en parallèle avec des lignes de vie représentant des objets de cette classe. Le nom d'objet de la ligne de vie qui représente la classe peut avoir le même nom que la classe.

Acteurs Haut de la  page

Normalement, une instance d'acteur est représentée par la première ligne de vie (de poids fort) du diagramme de fonctionnement, comme l'auteur de l'appel de l'interaction. Si vous avez plusieurs instances d'acteurs dans un même diagramme, essayez de les conserver dans les lignes de vie de poids fort ou de poids faible.

Messages Haut de la  page

Un message est une communication entre des objets transmettant des informations en attendant que l'activité s'ensuive ; dans les diagrammes de fonctionnement, un message apparaît en tant que flèche pleine horizontale de la ligne de vie d'un objet à la ligne de vie d'un autre objet. Dans le cas d'un message d'un objet à lui-même, la flèche peut commencer et se terminer sur la même ligne de vie. La flèche est marquée du nom du message et de ses paramètres. La flèche peut également être marquée d'un numéro de séquence pour montrer la séquence du message de l'interaction globale. Les numéros de séquence sont souvent omis dans les diagrammes de fonctionnement dans lesquels l'emplacement physique de la flèche montre la séquence relative.

Un message peut être sans affectation, ce qui signifie que son nom est une chaîne temporaire qui décrit le sens global du message et qu'il ne s'agit pas du nom du fonctionnement de l'objet destinataire. Vous pouvez ultérieurement attribuer le message en spécifiant le fonctionnement de l'objet de destination du message. Le fonctionnement spécifié remplacera ensuite le nom du message.

Scripts Haut de la  page

Les scripts décrivent le flot d'événements de façon textuelle dans un diagramme de fonctionnement.

Vous devez placer les scripts à la gauche des lignes de vie afin de pouvoir lire le flot complet de haut en bas (voir figure ci-dessus). Vous pouvez attacher des scripts à un message spécifique, afin de vous assurer que le script bouge avec le message.

Distribuer le flot de contrôle dans les diagrammes de fonctionnement Haut de la page

Un contrôle centralisé d'un flot d'événements ou d'une partie du flot d'événements signifie que quelques objets régissent le flot en envoyant et en recevant des messages d'autres objets. Ces objets de contrôle décident de l'ordre dans lequel les autres objets seront activés dans le cas d'utilisation. L'interaction entre le reste des objets est très limitée ou inexistante.

Exemple

Dans un système de recyclage le cas d'utilisation Imprimer compte-rendu quotidien suit- entre autres - le nombre et le type d'objets renvoyés, et rédige le comptage sur un reçu. L'objet de contrôle Générateur de compte-rendu décide de l'ordre dans lequel les sommes seront extraites et rédigées.

Diagramme décrit dans le texte d'accompagnement.

La structure de comportement du cas d'utilisation Imprimer le rapport quotidien est centralisée dans l'objet de contrôle Générateur de compte-rendu.

Il s'agit d'un exemple de comportement centralisé. La structure de contrôle est centralisée principalement car les différentes phases de sous-événements du flot d'événements ne dépendent pas les unes des autres. Le principal avantage de cette approche est que chaque objet n'a pas besoin de suivre le comptage du prochain objet. Pour changer l'ordre des phases de sous-événements, il vous suffit d'effectuer le changement dans l'objet de contrôle. Vous pouvez également ajouter une autre phase de sous-événement si, par exemple, un nouveau type d'élément de renvoi est inclus. Un autre avantage de cette structure est qu'elle permet de réutiliser facilement les différentes phases de sous-événements dans d'autres cas d'utilisation car l'ordre du comportement n'est pas inséré dans les objets.

Le contrôle décentralisé a lieu lorsque les objets participants communiquent directement les uns avec les autres, et non par le biais d'un ou plusieurs objets de contrôle.

Exemple

Dans le cas d'utilisation Envoyer une lettre quelqu'un envoie une lettre à un autre pays par le biais d'un bureau de poste. La lettre est d'abord envoyée au pays du destinataire. Dans le pays, la lettre est envoyée dans une ville spécifique. Ensuite, la ville envoie la lettre au domicile du destinataire.

Diagramme décrit dans le texte d'accompagnement.

La structure de comportement du cas d'utilisation Envoyer une lettre est décentralisée.

Le comportement de cas d'utilisation est un flot décentralisé d'événements. Les phases de sous-événements forment un ensemble. L'expéditeur de la lettre parle d'"envoyer une lettre à quelqu'un." Il ne souhaite pas et n'a pas besoin de savoir en détails comment les lettres sont transférées dans les pays ou les villes. (Il est probable qu'une partie de ces actions n'auraient pas lieu si quelqu'un envoyait une lettre dans le même pays.)

Le type de contrôle utilisé dépend de l'application. En général, essayez d'obtenir des objets indépendants, c'est-à-dire de déléguer différentes tâches aux objets les plus adaptés pour les exécuter.

Un flot d'événements avec un contrôle centralisé aura un diagramme de fonctionnement "en fourchette". Au contraire, un diagramme de fonctionnement "en escalier" illustre le fait que la structure de contrôle est décentralisée pour les objets participants.

Diagramme décrit dans le texte d'accompagnement.

Une structure de contrôle centralisée dans un flot d'événements produit un diagramme de fonctionnement "en fourchette". Une structure de contrôle décentralisée produit un diagramme de fonctionnement "en escalier".

La structure de comportement d'une réalisation de cas d'utilisation consiste généralement en un mélange de comportement centralisé et décentralisé.

Une structure décentralisée est appropriée :

  • Si les phases de sous-événements sont étroitement connectées. Ce sera le cas si les objets participants :
    • Forment une hiérarchie de tout à partie, comme Pays - Etat - Ville ;
    • Forment une hiérarchie d'information, comme Directeur général - Responsable de division - Responsable de section ;
    • Représentent une progression chronologique fixe (la séquence de phases de sous-événement sera toujours effectuée dans le même ordre), comme Publicité - Commande - Devis - Livraison - Paiement ; ou
    • Forment une hiérarchie d'héritage conceptuel, comme Animal - Mammifère - Chat.
  • Si vous souhaitez encapsuler, et donc faire des abstractions de la fonctionnalité. C'est pratique pour quelqu'un qui souhaite toujours utiliser l'intégralité de la fonctionnalité, car celle-ci peut être trop difficile à comprendre si la structure de comportement est centralisée.

Une structure centralisée est appropriée :

  • Si l'ordre d'exécution des phases de sous-événements est susceptible de changer.
  • Si vous prévoyez d'insérer de nouvelles phases de sous-événements.
  • Si vous souhaitez que des parties de la fonctionnalité soient réutilisables en tant que pièces séparées.


RUP (Rational Unified Process)   2003.06.15