Ne pas se tromper de cible
Faut-il faire porter l'information par les acteurs ou par les objets ?
Examinons le précédent diagramme de collaboration[1].
Il reflète la réalité de ce qui se passe sur le chantier : le chef orchestre, c'est le chef d'équipe qui donne ses ordres à chacun de ses hommes et par délégation au grutier.
Ce diagramme serait pertinent si l'objectif était d'étudier uniquement l'enchaînement des tâches d'occupation d'une équipe, son emploi du temps détaillé. Dans ce cas, il est vrai que c'est l'équipe et son chef en tant que classes d'objets qui doivent porter l'information. L'équipe change d'état à chaque changement d'activité. Le poteau, non porteur d'informations, n'est pas impliqué dans les évènement[2] !
Mais notre objectif n'est pas celui-là. Revenons au scénario « couler un poteau en béton ».
Ce qui nous intéresse, c'est de pouvoir gérer les objets du chantier pour la rotation des coffrages, mettre à jour les travaux à exécutés, vérifier les plannings d'avancement, calculer le quantitatif, les situations instantanées, les stocks, les commandes ...
Ce sont donc les classes de ces objets qui doivent porter l'information, déclencher des actions[3], même si en réalité ils sont inertes. La modélisation du bâtiment ne décrit plus la réalité ergonomique ou humaine du chantier, mais une réalité comptable !
C'est une faute fréquente chez le débutant de se tromper de cible, et de confondre l'acteur et ses objets.
Le diagramme de collaboration fidèle à notre scénario est donc le suivant :
Les évènements[2] changent l'état du poteau, lequel libère en dernier le coffrage (type x) en le marquant disponible dans sa classe.
Dans un diagramme où les ressources en main d'œuvre ne sont pas gérées, on pourrait intégrer la grue à l'équipe, et même supprimer l'équipe du diagramme.
Ce serait alors à la classe des poteaux de gérer par des messages les classes armatures et béton.
Nota : Nous avons noté les messages par une numérotation continue de 1 à 12.
En utilisant une numérotation en arbre, on peut traduire un diagramme de collaboration en une arborescence de messages. Cela n'a d'intérêt que pour gérer les évènements en concurrence.
C'est une représentation très utile pour les informaticiens.
Par exemple, après avoir coulé un groupe de 4 poteaux, l'équipe peut selon le contexte
recommencer un autre groupe de poteaux
décoffrer un groupe de poteaux coulés il y a plus de 21 jours,
se déplacer pour couler des poutres ...
