4.3.2.1 Principe
La phase de conception de l’architecture de l’interaction a pour but de raffiner les briques dédiées à l‟interaction de la version instanciée du pattern architectural Arch. Cette conception reprend l‟architecture définie dans la phase de conception de l‟architecture de l‟application et détaille les briques «Présentation» et «Boîtes à outils».
Comme nous voulons pouvoir structurer les composants d‟interaction d‟entrée et de sortie de manière indépendante, nous nous basons sur le modèle Arch étendu tel que présenté dans [Navarre05] qui a pour principale propriété de séparer les briques «Présentation» et «Boîtes à outils» en deux canaux représentant le sens du flux d‟informations :
Le flux des événements de l‟utilisateur vers le système interactif, Le flux de rendu du système interactif vers l‟utilisateur.
Tout comme pour la partie application, la communication entre ces composants exploite les protocoles de communications identiques à ceux présentés lors de la conception de l‟architecture de l‟application (communication par appels de méthodes et communication par événements) mais également pour cette partie interaction, les fonctions d‟activation et de rendu.
Nous pouvons voir ici la nécessité d‟avoir opté pour le pattern architectural Arch pour réaliser la conception de l‟architecture de notre application. En effet, contrairement à Seeheim [Pfaf85] par exemple, Arch définit plus clairement la partie présentation. Ceci permet facilement de pouvoir séparer les différents composants lorsque les techniques d‟interaction deviennent complexes.
Figure 4.20 Le modèle Arch (version étendue) [Navarre05]
4.3.2.2 Application du principe à l’exemple Entrée
Les entrées de cette phase sont :
l‟architecture conçue dans la phase de conception de l‟application,
la technique d‟interaction définie durant la phase de design de l‟interaction qui est ici un « glissé-déposé » pour la suppression des icônes sur une interface à manipulation directe. Activités
Comme pour la phase de conception de l‟application, il convient de noter que notre processus étant fortement itératif, nous présentons l‟architecture définitive de l‟interaction qui prend en compte les dernières évolutions des modèles de la partie application.
L‟architecture de la partie interaction est composée de quatre composants :
Le premier composant est le driver souris (CPN Mouse [Beaudouin-Lafon00a]). Il est chargé de recevoir les événements provenant de la souris et les transmettre au modèle suivant. Ces événements sont de deux types : changements d‟états des boutons (pressed, released) et déplacements.
Le deuxième composant Transducer Component se charge de transformer les événements bruts de la souris provenant du modèle Mouse Driver en événements destinés à la brique dialogue.
Le composant Renderer Component dédié au rendu de l‟interface. Ce modèle est abonné aux différents changements d‟états de places et de transitions du modèle Dialog Component ainsi que du modèle Transducer Component et permet de mettre à jour le rendu de l‟interface tel que l‟ajout ou la suppression d‟icônes sur la fenêtre.
Le composant de rendu bas-niveau (ici la librairie java.awt)
Figure 4.21 ARCH instancié de la partie Interaction
La communication entre ces différents modèles est présentée à l‟aide du diagramme Figure 4.22. Nous pouvons remarquer que le modèle d‟interaction (Transducer Component) reçoit les événements mousePressed, mouseReleased et mouseMove provenant du driver souris (CPN Mouse) et envoie les événements createObject, selectObject et selectTarget au modèle de dialogue (Dialog Component).
Figure 4.22 Diagramme des composants de la partie Interaction
La conception de l‟architecture de l‟interaction nous donne alors l‟architecture complète de notre exemple présentée en Figure 4.23.
Nous pouvons remarquer que tout comme lors de la conception de l‟architecture de l‟application, notre architecture permet facilement de modifier certains aspects de notre interaction sans devoir la reconcevoir complètement. Ainsi, s‟il était nécessaire de changer le périphérique d‟entrée, il suffirait de créer un autre composant de type Transducer Component qui serait abonné au driver de ce système d‟entrée. Ce changement de modèle n‟impacterait ni le composant Renderer Component, ni les autres parties de notre système comme le dialogue ou la base de données. De la même manière, on pourrait aisément modifier la façon d‟effectuer le rendu sans impacter la partie interaction ou la partie application de notre système.
Figure 4.23 ARCH instancié de l’application et de l’interaction
Productions
Cette phase a pour production l‟architecture complète de l‟application comprenant la définition des briques «Boites à outils» et «Présentation» pour chacun des deux canaux (entrée et sortie).
4.3.2.3 Avantages
Cette conception de l‟architecture en couches a les mêmes avantages que la phase de conception de l‟architecture côté application à savoir :
Réutilisabilité : Notre conception de l‟architecture nous permet de réutiliser facilement les composants déjà créés. Dans le cas de l‟architecture de notre exemple, le composant Dialog Component pourrait être réintégré facilement dans une architecture ayant un autre type de rendu ou un autre type d‟interaction.
Modifiabilité : La conception de l‟architecture en différents composants nous permet de pouvoir modifier (tuner) certains paramètres sans que cela impacte les autres composants. Grâce au découpage en composants, nous pouvons faire abstraction du fonctionnement des autres composants (à condition de respecter certaines règles telles que les noms d‟événements à recevoir ou à envoyer et le nom de méthode à appeler) lors de la modification ou du paramétrage d‟un composant. Par exemple, dans le composant Dialog Component, on peut faire abstraction de la manière dont a été conçu l‟événement (type de périphérique, fusion de deux événements, ..) et on peut donc modifier les modèles CPN Mouse et Transducer Component sans que cela n‟impacte Dialog Component.
Lisibilité : La décomposition en différents composants plus petits permet de diminuer la complexité des composants et de cette façon d‟assurer une meilleure lisibilité des modèles de ces composants dans le cas de discussions entre différentes parties prenantes (designers, futurs utilisateurs, programmeurs, …).
Analyse : La décomposition en différents composants plus petits permet aussi de simplifier les analyses de type algèbre linéaire sur les modèles de ces composants.