Structure des Diagrammes d'interaction

Les Diagrammes d'interaction donnent au concepteur une possibilité unique de voir la séquence complète des évènements du service avec un point de vue global. Le concepteur peut rapidement se faire une idée de la progression de la séquence d'événements sur les objets participants au service. On peut aussi voir la structure du service, ce qui nous donne beaucoup d'information sur les caractéristiques de réalisation du service. Nous pouvons en principe ici valider la structure défini dans le MDA.

Nous allons étudier deux conceptions différentes d'un même service. Le service est basé sur une application réelle où l'on doit gérer un entrepôt équipé de chariots automatiques de transport de palettes. Un technicien dicte des déplacements sous la forme position de départ, position d'arrivée. Toutes les charges sont sur des palettes déplacées automatiquement. Ceci nous amène à vouloir vérifier régulièrement (tout les 10 déplacements) si la charge est encore bien positionnée sur la palette. Nous conservons donc le nombre de déplacements réalisé par la palette. Décrivons maintenant le service déplacement palette. Pour cela dessinons le diagramme d'interaction et regardons deux variantes de conception.

Première version Figure 1.12 transporteur1L'objet transporteur controle le flot d'évènements.

le service débute quand le technicien envoit un message à transporteur. Transporteur demande à palette combien de fois elle à été déplacé depuis la dernière vérification de la charge. Si elle a été déplacée le nombre de fois maximum alors on teste si la destination du déplacement est la station de vérification. Auquel cas le déplacement est autorisé, sinon le déplacement est refusé. dans les autres cas le déplacement est autorisé. Nous pouvons voir dans le diagramme d'interaction que tous est géré par l'objet transporteur. C'est lui qui contrôle le flot d'évènements et qui opère sur les autres objets et qui prend des décisions. C'est l'objet transporteur qui contient les règles de déplacements. Nous avons se que l'on appel une structure centralisée. transporteur2Palette sait si elle peut être bougée.

Dans la seconde version Figure 1.13 nous avons délégué à l'objet palette la décision de savoir si elle pouvais être bougée ou non. transporteur de fait que demander si le déplacement est possible. palette vérifie si elle peut être déplacé ou si la destination est la station de vérification. Palette répond uniquement oui ou non. Transporteur ne réalise que la déplacement si il est possible. Ici nous avons décentraliser les décisions en les plaçant dans les unités qui stocke l'information, c'est à dire ici palette. Transporteur ne s'intéressent qu'a l'autorisation de déplacement et ne s'encombre pas de connaître les conditions de déplacement. Nous avons ici une structure décentralisée.

La différence entre ces deux conceptions est fondamentale. Nous L'avons déjà rencontrée. Quand nous avons allouer les objets d'analyse aux services. Laquelle des conception est la meilleur: la plus résistante au changements ? Supposons que nous voulons manipuler des bicyclettes peintes dans notre entrepôt. Les bicyclettes ne doivent pas être déplacées avant que la peinture soit sèche disons pendant 6 heures après la peinture. Nous devons donc ajouter un test : la charge de la palette est elle constitué de bicyclettes si oui depuis combien de temps elles ont été peintes. ces attributs sont dans un objet bicyclette que connaît palette. Dans notre première version nous devons changer palette, transporteur et créer un nouveau stimulus de transporteur vers palette (que transporte palette?). dans la seconde version seul palette change.

Dans un Diagframme d'interaction nous pouvons lire la structure d'un service (ou d'un bloc) d'un seul coup d' il. Le diagramme d'interaction nous permet de mesurer la décentralisation du système. Distinguons les deux cas extrêmes de la structure des Diagrammes d'interaction. 1.14. conception.centraliseLe diagramme d'interaction montre clairement la structure. Le premier extrême est un diagramme en peigne. Ce type est caractérisé par un objet qui agit comme une araignée sur sa toile est contrôle tous les autres objets. Une grande partie des comportements est placé dans l'objet central qui doit connaître tous les autres et les utilisent pour des commandes ou des questions directes. Le diagramme en peigne indique une structure centralisé. La séquence de contrôle est placée dans un objet (en général un contrôle . Les autres objets sont juste des transporteurs d'information ou des interfaces pour un utilisateur. Une structure en peigne place énormément de responsabilités sur le concepteur de l'objet central qui devient beaucoup plus complexe que les autres.

L'autre extrême est le diagramme en escalier. Ce type est caractériser par une forte délégation des responsabilités. Chaque objet ne connaît qu'un petit nombre d'objets et ceux qui peuvent l'aidé pour un comportement spécifique. Nous n'avons pas d'objet central. Les escalier indique souvent une structure décentralisée. Chaque objet a une tâche séparée et seul les objets avoisinants sont nécessaires pour la réalisée. Quel type de conception doit on choisir ?
Lequel est le meilleur ?
on dit souvent que les escalier sont plus orientés objets et donc meilleur. Plus les responsabilités sont distribuées meilleur c'est. Ce n'est malheureusement pas toujours le cas. Ce que nous voulons c'est être capable d'introduire des changements facilement et de construire des objets réutilisables ainsi que des messages réutilisables. Or différents types de changements peuvent avoir lieux. Pour gérer la réorganisation d'une séquence, nous devons encapsuler la séquence ainsi nous obtenons une structure décentralisée. Par contre si c'est l'ordre des opérations qui varient il est plus facile de travailler avec une structure centralisée, ainsi les changements seront localisés dans un objet. Les deux structure ont leurs avantages. Ce qui est crucial dans le choix de la structure c'est l'existence ou non d'une forte connexion entre l'objets.

il existe une forte connexion entre objets si

• Les objets forment une hiérarchie "consite-en" comme pays-département-commune.
• Les objets forment une hiérarchie d'information comme document-chapitre-section-paragraphe
• Les objets représentent une relation chronologique fixe comme publicité-commande-facture-payment-livraison
• Les objets forment une hiérarchie conceptuelle comme Animal-mamifère-chat

Nous avons les règles empiriques suivantes :

• On utilise une structure de controle en escalier quand les opérations ont une forte connexion. les opérations seront toujours réalisées dans le même ordre.
• On utilise une structure de contrôle en peigne quand les opérations peuvent changer d'ordre de nouvelles opérations peuvent être ajoutées

Il est naturel de conclure, que les deux types de structures devrons en pratique être utilisées pour obtenir une structure robuste et stable.

Notons ici que l'ordre des opérations peut être u facteur important de changement. Nous ne pouvons nous restreindre au point de vue des données et des comportements, il faut aussi regarder l'ordre. La solution naturelle reste d'encapsuler les choses qui peuvent changer. Nous cherchons donc a encapsuler l'ordre. C'est ce qui est fait dans une structure centralisée ou les instruction liées à l'ordre des opération sont placées dans un seul objet.