Le diagramme de “collaboration”
Son nom n'indique pas entre qui est envisagé la collaboration.
On peut comprendre ce concept de collaboration de deux façons :
Collaboration entre plusieurs classes d'objets pour réaliser une fonction du système.
Synthèse de certaines informations issues du modèle statique et des diagrammes dynamiques précédents qui collaborent pour offrir une vue partielle plus opérationnelle de la même fonction.
Un diagramme de collaboration[1] assure la liaison entre les deux types de modèles.
Il contient une densité d'informations qui peut le rendre difficilement lisible.
On découpe les diagrammes en parties dont la granulométrie correspond à celle d'un scénario[2].
Pour une fonction donnée, et un degré de granulométrie donné, le diagramme de collaboration[1] contient deux types d'information : le contexte[3] et les interactions.
Le contexte
Le contexte[3] est tout simplement un extrait du modèle statique, un package, ou schéma qui ne réunit que les classes concernées, avec leurs associations, contraintes[4], attributs[5], opérations[6]. Pour une meilleure lisibilité, on ne détaille pas le contenu d'une classe.
Si, comme nous l'avons déjà évoqué, de nouveaux objets de classes naissent à l'occasion de la synthèse des aspects dynamiques avec le modèle statique, on note le commentaire « new » associé à la classe créée.
Les interactions
Une fois le contexte[3] mis en place, on recense dans les diagrammes de scénario[7] et d'état[8] les messages[9] qui sont nécessaires à l'exécution de la fonction, et on les ajoute au contexte[3]. L'ensemble de ces messages forment ce qu'on appelle les interactions.
Une ambiguïté subsiste alors : la description statique de la classe ne renseigne pas sur les différents états possibles des objets de la classe. On ne peut tout dire dans un seul diagramme !
Cependant, on améliore la connaissance de l'écoulement du temps, par la description chronologique des messages reportés dans le diagramme. Il suffit de les numéroter. Mais pas seulement avec un simple numéro d'ordre. Il convient de noter les messages[9] en concurrence[10], ce qui permettra de les dérouler dans une arborescence séparée qui permettra aux futurs logiciels d'exploitation une exploration algorithmique d'un arbre.
Pour bien comprendre, construisons un diagramme de collaboration[1] en trois étapes :
Tout d'abord, par exemple, isolons quelques entités du scénario de construction d'un poteau. Dans le diagramme qui suit, nous avons séparé l'équipe et son chef, qui émet les messages, ce qui est plus conforme à la réalité semble-t-il, que dans le scénario. Une analyse d'occupation des tâches a déterminé qu'une équipe devait s'occuper de 4 poteaux simultanément. Après le coulage, l'équipe a le choix entre passer à un nouveau groupe, ou bien passer à la construction de poutres, dont la présence est décrite dans le schéma par un package. Aux classes armatures, jeu de coffrage, béton sont en fait associés des hommes qui obéissent au grutier.
