Chapitre 3 : UML
1. UML: Unified Modeling Language
UML est le résultat du travail initié par G. Booch et J. Rumbaugh en 1994. L’objectif de ce travail était d’unifier les méthodes de modélisation de:
Booch
OMT de Rumbaugh OOSE de Jacobson
La Version 1.0 d’UML apparaît en Janvier 1997.
L ’OMG a adopté UML comme langage de modélisation
1.1. Objectifs de UML
Les objectifs d’UML sont :
Modéliser des systèmes divers en utilisant des concepts orientés objets Établir un couplage entre les concepts et leur implantation
Aborder la description des problèmes d’échelle propres aux systèmes complexes Offrir une approche de description utilisable par les humains et les machines
1.2. Usages de UML
Systèmes d’information pour la présentation d ’informations diverses à des usagers Systèmes techniques pour la commande d’équipements
Systèmes temps-réel embarqués
Systèmes répartis sur des réseaux (locaux ou non)
Systèmes logiciels (exploitation, bases de données, interfaces GUI, …etc.)
Systèmes commerciaux (description de la structure et du fonctionnement des entreprises: règles,
stratégies, politiques, …etc.)
1.3. Étapes de développement d’un système
Analyse des besoins: recherche des points fonctionnels (Use Cases)
Analyse (recherche des abstractions principales composant le système: classes et objets) Conception des abstractions principales et implantation d’abstractions secondaires
Programmation des abstractions dans un langage orienté objet Tests du système
2. Types de visualisation dans UML
2.1. Visualisation « Use Cases »
Les cas d’utilisation (Use cases) décrivent la fonctionnalité d’un système. Ces diagrammes s’adressent aux clients, concepteurs, responsables du développement, responsables des tests Un Use Case décrit un point fonctionnel du système et le fonctionnement global du système est décrit par l’ensemble des Use Cases
2.1.1. Use Cases dans UML
Les use cases sont représentés par une ellipse dans laquelle est inscrit le nom du Use Case Ils sont généralement connectés à un acteur avec une association
2.1.2. Liens entre Use Cases
« extends » signifie qu’un Use Case est une spécialisation d’un autre Use Case plus général.
L’Use Case plus spécifique n’inclut pas nécessairement tout le comportement du Use Case qu’il spécialise
« uses » signifie qu’un Use Case utilise intégralement la fonctionnalité du Use Case plus général
2.1.3. Description d’un Use Case
Un use case est décrit par : Ses Objectifs
Le Flot des messages entre l’acteur et le Use Case
Le Flot secondaire des messages entre l’acteur et le Use Case
Les Condition de fin pour le Use Case et information retournée à l ’acteur lors qu’il se termine
2.1.4. Qu’est-ce qu’un bon Use Case
Un bon Use Case représente une fonctionnalité du système qui est complète du début jusqu’à la fin. Il doit normalement apporter quelque chose de valable à un acteur (i.e. un résultat tangible à une de ses commandes ou à une de ses actions sur le système).
Il n’y a pas de consensus sur la « grosseur » que devrait prendre un Use Case en termes de fonctionnalité.
2.2. Visualisation « Logique »
Il existe deux types visualisation logique : Visualisation statique et Visualisation dynamique La visualisation statique est décrite par les diagrammes de classes et d’objets.
La visualisation dynamique est décrite par les diagrammes d’états, séquentiels (de séquence), de collaboration et d’activité
2.2.1Vision statique
2.2.1.1. Diagrammes de classes
Classes et objets :
Une classe sert à décrire de manière générique une catégorie d’objets participant aux actions du système
Un objet est relié à une classe de la même manière qu’une variable est associée à un type de données dans un langage de programmation procédural
Les fondements de la programmation orientée objet sont les classes, les objets, et les relations entre eux.
Ces classes, objets, et relations sont représentés par des diagrammes en langage UML
Le diagramme de classes est un modèle statique du système qui décrit le système en termes de ses classes et des relations entre celles-ci. Il sert de base aux autres diagrammes où d’autres
facettes du système sont décrites (tels les diagrammes d ’états des objets ou les diagrammes de collaboration qui sont des diagrammes dynamiques)
Recherche des classes
La recherche des classes est une étape de création.
Pour trouver les classes pertinentes à un problème, il faut se poser les questions suivantes: – Est-ce qu’une information doit être analysée ou stockée?
– Est-ce que le système interagit avec d’autres systèmes?
– Existe-t-il des patrons, des librairies, ou des composantes réutilisables dans le système? – Le système doit-il manipuler des périphériques (devices)?
– Quels rôles les acteurs jouent-ils?
– Le système possède-t-il des pièces structurales (parts)?
Types classiques de classes
Entity: servent à modéliser des catégories d’objets qui ont une durée de vie importante dans le
système (i.e. elles sont des parties intégrantes du système)
Boundary: servent à faciliter la communication des classes Entity avec l’extérieur du système
(soit un autre système, avec l’utilisateur ou encore avec un périphérique)
Control: servent à coordonner les échanges de messages entre les autres classes pour réaliser un
Use case
Représentation des classes en UML
Une classe est représentée par un rectangle divisé en trois compartiments: – le compartiment du nom
– le compartiment des attributs
– le compartiment des méthodes (opérations)
La syntaxe dans les différents compartiments est indépendante des langages de programmation
a. Compartiment de nom
Il contient le nom de la classe. Il est centré dans le compartiment. Il est imprimé en caractères gras.
Le nom ne doit pas être ambigu et doit être tiré du domaine propre au problème.
b. Compartiment des attributs
Les attributs servent à décrire les caractéristiques des objets appartenant à la classe (i.e. décrivent l’état de l ’objet)
Chaque attribut possède:
Un type (primitif ou défini par l’usager)
Un niveau de visibilité (public (+), protected (#) ou private (-)) Une valeur par défaut
Optionnellement, on peut aussi indiquer qu’un attribut possède une portée s’appliquant à la
classe (class scope) ou une chaîne de propriétés indiquant les valeurs que peut prendre
l’attribut.
Exemples de classe avec attributs
c. Compartiment des opérations
Les opérations permettent de manipuler les attributs et d’effectuer d’autres actions. Elles sont appelées pour des instances (objets) de la classe.
La signature des opérations comprend: un type de retour
un nom
0 ou plus paramètres (ayant chacun un type, un nom et possiblement une valeur par défaut)
une visibilité (private(-), protected(#), public(+))
Les opérations constituent l’interface de la classe avec le monde extérieur Exemple de classe avec opérations
Spécification de l’opération
Une méthode (opération) est spécifiée par :
les Pré-conditions: doivent être vérifiées avant que l’algorithme ne s’exécute les Post-conditions: doivent être vraies une fois l’opération complétée
l’Algorithme: effet que l’opération a sur l’objet
Relations entre les classes
Un diagramme de classes montre les classes d’un système mais également les relations entre celles-ci.
On compte quatre principales catégories de relations entre classes : –les associations
–les généralisations (héritage) –les dépendances
–les raffinements
Les associations de classes
Il existe plusieurs types d’associations: normale
récursive
agrégation par référence agrégation par composition
a. Association normale
Une association normale est une connexion entre classes. - Elle possède un nom.
- Elle est généralement navigable de manière bidirectionnelle (dans ce cas elle a un nom dans les deux sens si nécessaire)
- Elle a une multiplicité - Elle peut être dotée de rôles
b. Association récursive
Une classe peut être connectée à elle-même via une association récursive. Elle représente une
connexion sémantique entre des objets mais avec la différence que ceux-ci appartiennent à la même classe
c. Agrégation par référence
Elle indique une relation tout-partie. Elle se représente par une ligne avec un losange du côté « tout » de l’agrégation. Ce losange ne peut apparaîtra qu’à une seule extrémité.
Une agrégation par référence possède des rôles, multiplicité, …etc., comme une association normale.
Elle indique une relation tout-partie avec inclusion « physique ». Elle se représente par une ligne avec un losange plein du côté « tout » de l’agrégation. Ce losange ne peut apparaîtra qu’à une seule extrémité.
Une agrégation par composition possède des rôles, multiplicité, …etc., comme une association normale
Les généralisations de classes
Une généralisation est une relation entre une classe générale et une classe plus spécifique. La classe spécifique est appelée sous-classe et la classe générale est appelée super-classe. La sous-classe hérite des attributs et opérations de la super-classe (en fonction de la visibilité de la généralisation)
une sous-classe peut être la super-classe d’une autre classe dans ce que l’on appelle une
hiérarchie
Représentation des généralisations
On représente les généralisations par une flèche allant de la classe spécifique à la classe générale.
Lorsqu’une classe spécifique hérite de plusieurs super-classes, on parlera d’héritage multiple
Les Interfaces
Les interfaces sont des classes contenant seulement des opérations sans implantation. Une classe peut implanter une interface.
Le symbole d’implantation est une flèche pointillée allant de la classe vers l ’interface Ici, la classe A implante les interfaces Storable et Runnable et B utilise ces implantations
2.2.1.2. Les Packages
Pour les systèmes comprenant plusieurs classes, il convient de regrouper celles-ci en entités logiques, les packages
Un package est un ensemble de packages et de classes reliés sémantiquement entre eux.
Chaque package est muni d’une interface (ses classes public) qui lui permet de communiquer sa fonctionnalité aux autres packages qui peuvent l’importer
Un package est représenté par un dossier (folder).
Les Packages ont eux aussi un niveau de visibilité est des relations qui sont ici: la dépendance, le
raffinement, et la généralisation
2.2.1.3. Les Templates
UML supporte les templates (aussi appelés « parameterized classes ») qui sont symbolisés par un symbole de classe avec un ajout identifiant le fait que le template doit être « instancié » avant de pouvoir créer des objets de la classe correspondant au template
2.2.1.4. Qualités d’un modèle statique
Un bon modèle statique doit répondre aux questions suivantes :
Le modèle a-t-il une utilité pour décrire le système?
Le modèle embrasse-t-il les caractères essentiels du système (permet-il entre autres de bien répéter les use-cases?
Les noms des classes du modèle reflètent-ils les noms des éléments du système (i.e. les noms sont-ils pertinents)?
Des modèles différents de la même chose sont-ils intégrés et coordonnés entre eux? Les modèles sont-ils simples (même pour les systèmes complexes)?
2.2.2. Visualisation « Dynamique »
La modélisation dynamique sert à montrer comment les objets d’un système collaborent pour réaliser une fonctionnalité du système. Elle montre comment les objets s’échangent des
messages (i.e. comment un objet, le client, invoque une opération sur un autre objet, le serveur).
Ces échanges sont appelés interactions.
Les interactions sont montrées via trois principaux diagrammes: séquence, collaboration,
activité.
Un autre diagramme, le diagramme d’état décrit le comportement d’un objet mais cette fois-ci pris isolément.
Diagramme d’états: décrit les états que peut prendre un objet durant son cycle d’existence et le comportement de ces états de même que les événements qui provoquent un changement d’état
de l’objet
Diagramme séquentiel : montre comment les objets interagissent et communiquent entre eux
pour accomplir une tâche du système. La variable indépendante est ici le temps.
Diagramme de collaboration: montre comment les objets interagissent et communiquent entre
eux pour accomplir une tâche du système. La variable indépendante est ici le l’espace. Par espace on entend ici les relations (liens) entre les objets dans le système.
Diagramme d’activité: montre comment les objets interagissent et communiquent entre eux
pour accomplir une tâche du système. La variable indépendante est ici le travail accompli par les
objets.
Interactions entre les objets (messages)
En programmation orientée objet, les interactions entre les objets sont modélisées comme des
messages envoyés d’un objet à un autre. Ces messages sont simplement des appels d’opérations
d’un objet par un autre avec le contrôle qui revient à l’objet appelant avec une valeur de retour
1. synchrone: l’objet appelant transmet le message et attend la réponse (i.e. la valeur de retour de
l’opération appelée) avant de poursuivre son activité;
2. asynchrone: l’objet appelant transmet le message et n’attend pas la réponse (i.e. la valeur de
retour de l’opération appelée) avant de poursuivre son activité. Cela implique par exemple que les objets peuvent s’exécuter sur des threads différents.
3. simple: message dont on ne spécifie pas la nature exacte (synchrone ou asynchrone);
4. synchrone avec retour immédiat: cas spécial de message synchrone pour lequel l’attente de la
2.2.2.1. Les diagrammes de séquence
Ils illustrent comment les objets interagissent entre eux. Ils se concentrent sur la séquence des
messages envoyés entre les objets (c’est-à-dire comment et quand les messages sont envoyés et
reçus entre les objets)
Ils possèdent deux axes: l’axe vertical montre le temps tandis que l’axe horizontal montre l’ensemble des objets en interaction dans un scénario ou une scène spécifique d’un scénario. Les diagrammes de séquence peuvent être utilisés sous deux formes:
– forme générique: elle décrit tous les déroulements possibles d’un scénario et peut contenir des
branchements, des conditions, et des boucles.
– forme d’instanciation: elle décrit le comportement du système pour un aspect spécifique d’un scénario et ne peut donc contenir aucun branchement et aucune condition ou boucle.
Les messages dans les diagrammes séquentiels
Ils représentent une communication entre objets véhiculant une information avec l’anticipation qu’une action sera entreprise.
La réception d’un message est généralement appelée événement.
Les messages ...
Quand un objet reçoit un message, on dit qu’il entre dans sa phase d’activation. Un objet dans cette phase peut:
– exécuter son propre code
– attendre les résultats retournés par un autre objet à qui il a envoyé un message
L’activation d’un objet est représentée par un rectangle étroit sur la ligne de vie de l’objet
Les messages les plus communs qu’un objet peut recevoir sont : • l’envoi d’un signal ;
• l’invocation d’une opération ;
• la création ou la destruction d’une instance.
L’envoi d’un signal déclenche une réaction chez le récepteur, de façon asynchrone et sans réponse : l’émetteur du signal ne reste pas bloqué le temps que le signal parvienne au récepteur et il ne sait pas quand, ni même si le message sera traité par le destinataire.
Plus encore que l’envoi d’un signal, l’invocation d’une opération est le type de message le plus utilisé en programmation objet. Si, par exemple, une classe C possède une opération op, l’invocation se fait par c.op(), où c est une instance de la classe C.
Notation
Un message synchrone se représente par une flèche à l’extrémité pleine qui pointe sur le destinataire du message. Ce message peut être suivi d’une réponse qui se représente par une flèche en pointillé.
Un message asynchrone se représente par une flèche à l’extrémité ouverte.
La création d’un objet est matérialisée par une flèche qui pointe sur le sommet d’une ligne de vie.
La destruction d’un objet est matérialisée par une croix qui marque la fin de la ligne de vie de l’objet.
Règles de cohérence (well-formedness rules)
– Chaque objet dans le diagramme de séquence doit être instance d'une classe dans le diagramme de classe
– Chaque message dans le diagramme de séquence doit correspondre à une opération dans le diagramme de classe
– ...
SYNTAXE DES MESSAGES
La syntaxe des messages est :
<nomDuSignalOuDeOpération> [’(’ [<argument>’,’ … ’)’] où la syntaxe des arguments est la suivante :
[ <nomDeParamètre> ’=’ ] <valeur de l’argument>
Par défaut, les paramètres transmis ne peuvent pas être modifiés par le récepteur (les arguments sont « en entrée »). Pour indiquer que des paramètres peuvent être modifiés (argument « en sortie » ou « en entrée/sortie »), il faut écrire :
<nomDuParamètreEnSortie> [’:’ <valeur de l’argument> ]
Exemple
Appeler( "Capitaine Hadock", 54214110 ) afficher( x, y )
initialiser( x = 100 ) est un message dont l’argument en entrée reçoit la valeur 100.
f( x :12 ) est un message avec un argument en entrée/sortie x qui prend initialement la valeur 12. La syntaxe de réponse à un message est la suivante :
[<attribut> ’=’] message [’:’ <valeur de retour> ] où message représente le message d’envoi.
Exemple
nombreLivres = chercher( "Tintin" ) : 42
CONTRAINTES SUR LES LIGNES DE VIE
Une contrainte est indiquée sur une ligne de vie par un texte entre accolades.
Une contrainte peut aussi être contenue dans une note attachée à l’occurrence de l’événement sur lequel elle agit.
Une contrainte est évaluée au cours de l’exécution de l’interaction. Si la condition de la contrainte n’est pas vérifiée, les occurrences d’événement qui suivent cette contrainte sont
considérées comme invalides, alors qu’une contrainte qui se vérifie rend valides les événements à suivre.
FRAGMENTS D’INTERACTION COMBINÉS
Un fragment combiné se représente de la même façon qu’une interaction : par un rectangle dont le coin supérieur gauche contient un pentagone. Dans le pentagone figure le type de la combinaison (appelé « opérateur d’interaction »).
Les opérandes d’un opérateur d’interaction sont séparés par une ligne pointillée. Les conditions de choix des opérandes sont données par des expressions booléennes entre crochets.
La liste suivante regroupe les opérateurs d’interaction par fonctions : • les opérateurs de choix et de boucle : alternative, option, break et loop ;
• les opérateurs contrôlant l’envoi en parallèle de messages : parallel et critical region ; • les opérateurs contrôlant l’envoi de messages : ignore, consider, assertion et negative ; • les opérateurs fixant l’ordre d’envoi des messages : weak sequencing, strict sequencing.
Opérateur alt
l’opérateur d’interaction alt indique que le fragment est un choix. Les deux options de choix sont appelées « opérandes de l’opérateur alt ».
Opérateur Loop
La syntaxe d’une boucle est la suivante : loop [’(’ <minint> [’,’ <maxint> ] ’)’ ]
où la boucle est répétée au moins minint fois avant qu’une éventuelle condition booléenne ne soit testée (la condition est placée entre crochets sur la ligne de vie) ; tant que la condition est vraie, la boucle continue, au plus maxint fois (minint est un entier supérieur ou égal à 0, maxint est un entier supérieur ou égal à minit).
loop( valeur ) est équivalent à loop( valeur, valeur ). loop est équivalent à loop( 0, * ), où * signifie « illimité »
L’opérateur par permet d’envoyer des messages en parallèle. Ses opérandes se déroulent en parallèle.
Opérateur ignore et consider
Les opérateurs ignore et consider permettent de focaliser l’attention du modélisateur sur une partie des messages qui peuvent être envoyés durant une interaction. Quand de nombreux messages sont possibles, certains sont importants, d’autres moins.
L’opérateur ignore définit l’ensemble des messages à ignorer, tandis que l’opérateur consider définit l’ensemble de ceux qu’il faut prendre en compte.
La syntaxe de l’opérateur ignore est :
ignore { listeDesNomsDesMessagesÀIgnorer } La syntaxe de l’opérateur consider est :
consider { listeDesNomsDesMessagesÀConsidérer } Dans les listes, les messages sont séparés par des virgules.
Opérateur strict sequencing
L’opérateur strict sequencing impose que ses opérandes se déroulent dans l’ordre strict de leur présentation, c’est-à-dire de haut en bas.
DÉCOMPOSITION D’UNE LIGNE DE VIE
Une décomposition est référencée dans le rectangle en tête de ligne de vie, sous le label ref. À la figure 3.26, la ligne de vie PointDAccès est décomposée en deux lignes p1 et p2. Cette notation est une autre manière de décomposer une ligne de vie dans un diagramme d’interaction.
Une porte est un point de connexion qui permet de relier un même message représenté par des flèches différentes dans plusieurs fragments d’interaction.
Exercice
Le programme suivant, écrit en pseudo-code, permet de calculer le factoriel d’un nombre n : int factoriel( int n ){
if( n == 0 ) return 1; return n * factoriel( n-1) ; }
où n 0 et factoriel( 0 ) = 1.
Représentez le programme précédent sur un diagramme de séquence.
2.2.2.2. Les diagrammes de collaboration
Tout comme un diagramme de séquence, un diagramme de collaboration décrit le déroulement d’une interaction entre plusieurs objets.
Sur un diagramme de collaboration, les objets constituent les nœuds d’un graphe dont les arcs correspondent aux actions (i.e., l’envoi de messages, l’instanciation et la destruction d’objets). Le temps n’est pas associé à une dimension particulière du diagramme, mais la chronologie de l’interaction est exprimée par des numéros de séquence qui accompagnent les actions.
Les diagrammes de collaboration montrent les interactions et les liens entre un ensemble d’objets participant à un scénario.
Ils focalisent leur attention sur l’aspect spatial des interactions.
Ils sont particulièrement utiles pour montrer la réalisation des use-cases (sans que les aspects temporels des interactions ne soient nécessairement rendus explicites).
Les objets sont dessinés comme des classes mais leurs noms sont soulignés.
Les liens sont illustrés par des lignes (qui ressemblent à des lignes d’associations dans les diagrammes de classes mais sans les informations de multiplicité).
Un lien entre deux objets dénote l’envoi d’un message ou une action d’instanciation ou de destruction.
Un message, accompagné d’une étiquette, peut être associé à un lien pour montrer le sens et l’ordonnancement de la transmission du message.
Les étiquettes des liens sont similaires à celles des transitions d’un diagramme de séquence. Elles sont cependant préfixées d’un numéro de séquence qui précise l’ordre dans lequel les actions sont effectuées. Ces numéros peuvent être imbriqués afin de mettre en évidence la structure de l’interaction.
NUMÉROS DE SÉQUENCE DES MESSAGES
Dans un diagramme de communication, les messages peuvent être ordonnés selon un numéro de séquence croissant. Quand plusieurs messages sont envoyés en cascade (par exemple quand une procédure appelle une sous-procédure), ils portent un numéro d’emboîtement qui précise leur niveau d’imbrication.
Exemple 1
Exemple pour l’ascenseur : Classes
Exemple 2
Exemple de gestion des commandes.
SYNTAXE DES MESSAGES
Les diagrammes de séquence permettent de représenter divers opérateurs (choix, boucle…) dans des fragments combinés. Il n’est pas permis d’utiliser les fragments combinés dans un diagramme de communication. Malgré tout, des choix et des boucles peuvent y figurer selon une syntaxe particulière.
* [ <clause d’itération> ] représente une itération. La clause d’itération peut être exprimée dans le format i := 1…n.
[ <clause de condition> ] représente un choix. La clause de condition est une condition booléenne.
La syntaxe complète des messages est (voir les exemples ci-après) : [ <numéro_séquence> ] [ <expression> ] : <message>
où message a la même forme que dans les diagrammes de séquence, numéro_séquence représente le numéro de séquencement des messages tel qu’il a été défini précédemment et expression précise une itération ou un embranchement.
Exemple
2 : affiche( x, y ) est un message simple. 1.3.1 : trouve("Hadock" ) est un appel emboîté.
4 [x < 0] : inverse( x, couleur ) est un message conditionnel. 3.1 *[i :=1..10] : recommencer() représente une itération.
Le branchement
Les différentes branches d’un choix conditionnel sont repérées par le même numéro de séquence auquel on ajoute un suffixe propre à la branche (e.g., 2a, 2b, 2c, . . . ).
Exemple :
Les liens dans les diagrammes de collaboration
Le rôle de chaque objet peut être inclus aux extrémités de la connexion avec les qualificatifs du lien (rappel: les rôles et qualificatifs sont aussi inclus dans le diagramme de classe)
Le stéréotype du lien peut aussi être inclus dans la connexion.
On compte les stéréotypes suivants: global, local, parameter, self, vote, broadcast
Les stéréotypes de liens
Global: associé à un rôle du lien pour montrer que l’instanciation en présence est globale (visible
dans tout le système). Le récepteur est un objet global. Ceci se produit lorsque la référence à l’objet peut être obtenue à l’aide d’une méthode statique. Le stéréotype à utiliser est «global», ou [G].
Local: associé à un rôle du lien pour montrer que l’instanciation est une variable locale dans une
opération. Le récepteur est contenu dans une variable locale de la méthode émettrice. Ceci se produit fréquemment lorsque l’objet a été créé par la méthode émettrice ou lorsqu’un résultat précédent a retourné un objet. Le stéréotype à utiliser est «local» ou [L].
Parameter: montre que l’instance est visible parce que c’est un paramètre d’une opération. Une
référence à l’objet récepteur a été reçue comme paramètre par la méthode émettrice. Le stéréotype à utiliser est «parameter» or [P].
Self: montre qu’un objet peut s’envoyer des messages
Vote: contrainte imposée à un message limitant l’éventail des valeurs de retour (spécifie que la
valeur de retour est choisie au vote majoritaire entre différentes valeurs de retour)
Broadcast: contrainte appliquée à un ensemble de messages pour signifier qu’ils ne sont pas
exécutés dans un ordre donné. Exemple
On remarque que, contrairement au diagramme séquentiel, le diagramme de collaboration inclut un objet de la classe File. En effet, dans l’interaction des objets de ce point fonctionnel, l’objet de la classe File ne reçoit aucun message et il n’est donc pas pertinent de le montrer dans le diagramme séquentiel. Par contre, l’objet de la classe File intervient dans la collaboration soit en tant qu’objet global que comme paramètre dans des messages. Le diagramme de collaboration rend explicite la présence de l’objet de la classe File et montre comment il intervient dans la collaboration. On remarque également les étiquettes avec leur numéro accompagnant les liens entre les objets d’une collaboration1. Il convient de remarquer que la classe File possède des liens avec les autres classes dans le diagramme de classes, ce qui permet d’inclure les mêmes liens entre les objets du diagramme de collaboration pour le point fonctionnel illustrant l’impression d’un fichier.
