- Structuration de l'IHM : le SNI - |
|
Le Schéma Navigationnel d'IHM (SNI) permet de représenter toutes les possibilités offertes aux utilisateurs pour leur permettre d'accéder aux fonctions du logiciel. Le SNI pourrait être vu comme un amalgame du diagramme d'activités et du diagramme de séquences mais il possède l'avantage d'être parfaitement adapté aux problèmes spécifiques des IHM (il s'agit en fait d'un DSL : Domain Specific Language) qui doivent astucieusement combiner la présentation de résultats, la saisie de données et la commande du logiciel. Le SNI est présenté ici. Rappelons simplement qu'un SNI est constitué par un graphe d'unités de dialogues (UD).
Nous allons étudier ici la manière de construire le SNI le mieux adapté aux utilisateurs en tenant compte des divers éléments d'information dont nous disposons à ce niveau du projet. S'il existe plusieurs profils d'acteurs fonctionnant dans des sessions différentes, on peut construire plusieurs SNI, chacun donnant lieu au développement d'une application spécifique. Par exemple il est courant de construire un SNI correspondant au profil administrateur et un autre pour les autres profils d'acteurs. La réalisation du SNI peut s'effectuer suivant deux approches : à partir des cas d'utilisation et des fonctions ou à partir du diagramme des classes métiers. En partant des cas d'utilisation on favorise l'accès par les traitements (approche action-objet) alors qu'en partant des classes métiers on met plutôt l'accent sur les objets (approche objet-action). Il est aujourd'hui reconnu qu'une approche objet-action est préférable car elle est plus naturelle. Dans la vie courante on a l'habitude d'observer les objets avant de les manipuler. Dans la suite, nous partirons donc du diagramme des classes métiers pour construire un squelette du SNI qui sera enrichi progressivement par ajout des fonctions utilisateur mises en évidence dans l'architecture fonctionnelle et présentes dans les classes en tant que méthodes. La reconnaissance de certains types de structures dans le diagramme des classes métiers permet de définir des patrons d'IHM (Design Patterns ou formes de conception) qui seront modélisés par des structures particulières de SNI. La démarche préconisée pour la construction du SNI se déroulera en huit phases de la façon suivante. Phase 1 : Ciblage des classes de premier niveauPatron "racine"Un diagramme des classes métiers peut comporter de nombreuses classes qui n'ont pas toutes besoin d'apparaître directement aux yeux des utilisateurs. Nous dirons qu'une classe est au premier niveau de l'IHM si son nom apparaît dès les premiers menus proposés à l'utilisateur. L'accès aux objets des autres classes se fera alors de façon indirecte en utilisant les relations d'associations ou de composition. Le choix des classes de premier niveau doit se faire en étroite collaboration avec les acteurs principaux car il conditionne leur méthode de travail avec le logiciel qui devra rester proche de leurs habitudes. Afin de repérer quelles sont les classes de premier niveau, on positionnera un stéréotype en forme de cible à côté de leur nom dans le diagramme des classes métiers. Si les classes ont été réparties dans des paquetages, il faudra sélectionner au moins une classe de premier niveau dans chaque paquetage et s'assurer que toutes les autres classes sont atteignables à partir de celle-ci. Dans le cadre du projet Assurance-Auto, le ciblage peut être mis sur les classes Contrat, Dossier, Compagnie et "montant" qui est une classe association mettant en relation les types de contrats et las catégories de véhicules. Phase 2 : Création de la première unité de dialogue d'options (menu général)Elle est réalisée à partir des classes ciblées dont chacune constituera une option du menu général. Dans certains cas, si le nombre d'options devient important, on pourra en regrouper plusieurs dans une sous-UD d'options comme le montre la figure ci-dessous.
Phase 3 : Rajout des listes d'objets des classes de premier niveauChaque classe évoquée dans le menu général sera représentée par une liste de ses objets. Si la classe comporte peu d'attributs on indiquera seulement son nom. Dans le cas contraire, on portera la liste des attributs les plus représentatifs en soulignant celui sur lequel les objets seront triés (tri initial). Si une classe est liée à un seul objet d'une autre classe (multiplicité maximum égale à un), on pourra ajouter un identifiant de cet objet dans la liste des attributs. C'est par exemple le cas de numContrat et nomAssuré dans la liste Dossiers de la figure ci-dessous. Le SNI obtenu ainsi représente un premier patron d'IHM que nous appellerons racine.
Phase 4 : Ajout des UD de présentation des détailsPatron "détail"Chaque fois qu'une liste ne comporte pas la totalité des attributs de la classe, on lui rajoutera une option permettant d'afficher le détail d'un objet sélectionné dans la liste. Si la classe est liée à une autre par une relation de composition (losange noir) on rajoutera dans l'UD de présentation la liste des objets inclus. La partie de SNI obtenue par ajout du détail d'une classe constitue un deuxième patron d'IHM appelé détail. Dans l'exemple ci-dessous, la liste des compagnies n'étant pas représentée par la totalité de ses attributs puisque seule la raison sociale est affichée dans la liste, on lui adjoint une option permettant de détailler une compagnie lorsqu'elle est sélectionnée. Une compagnie d'assurances étant composée de tiers externes (association de composition), on fait également apparaître la liste des tiers qu'elle assure sous la forme d'une collection dans la même UDC. Pour éviter d'encombrer le SNI, les classes Contrats et Dossiers seront présentées dans deux planches différentes (non présentées ici).
Phase 5 : Ajout des liens vers les autres classesPatron "liaison"Pour chaque classe de premier niveau on indique les liens qu'elle peut avoir avec les autres classes sous la forme d'une UD d'options accolée à la liste. Si la classe destinatrice a déjà été définie dans le SNI mais placée trop loin (dans une autre planche par exemple) on placera une étiquette vers cette dernière. L'étiquette sera présentée en indiquant la ou les premières lettre(s) de la classe destinatrice suivie(s) d'une ou plusieurs lettres de la classe d'origine. Le troisième patron d'IHM correspond donc à la prise en compte d'une association entre deux classes. Il sera appelé liaison. La figure ci-dessous montre qu'à partir du détail d'un véhicule, l'utilisateur pourra afficher la liste des dossiers accident s'il en existe pour ce véhicule.
Phase 6 : Interprétation des généralisations-spécialisationsPatron "aiguillage"Les généralisations (héritages) de classes sont représentées dans le SNI par un aiguillage automatique vers un chemin ou un autre en fonction du type d'objet sélectionné par l'utilisateur. La description des sous-classes ne devra pas oublier les attributs des super-classes. On indiquera par une condition le type d'objet correspondant. Si des relations sont issues de la super-classe, on ajoute un lien sur chacune des UD. Un quatrième patron d'IHM permet de faire apparaître les généralisations sous la forme d'un chemin suivi par l'utilisateur en fonction du type d'objet qu'il a sélectionné. Ce patron sera appelé aiguillage. La figure ci-dessous illustre l'aiguillage dans le cas des deux types de tiers (internes et externes) pouvant être impliqués dans un accident.
Phase 8 : Ajout des fonctions utilisateur interactives et des droits d'accèsChaque fonction utilisateur a été rattachée à une classe sous la forme d'une méthode. Il faut maintenant indiquer l'accès à ces fonctions dans le SNI. Nous avons vu que certaines méthodes peuvent faire référence à plusieurs classes et qu'elles ont été placées dans la classe qui minimise les accès aux données. Au niveau du SNI, il n'est pas certain que cette classe corresponde à la meilleure ergonomie pour l'utilisateur c'est pourquoi faudra-t-il peut-être repenser le positionnement de ces fonctions. Les fonctions très générales qui portent sur de nombreuses classes seront positionnées dans le menu général ou l'un de ses sous-menus. C'est le cas de la fonction Consult-07 (véhicules impliqués en tant que tiers) qui est placée au niveau du menu général.Le SNI complet du projet Assurances-Auto a été construit en cinq planches avec l'outil VisualSNI. Il est visible ici au format PDF. Les fonctions qui correspondent à des consultations déjà prises en compte dans le SNI n'ont pas besoin d'être rajoutées. C'est par exemple le cas des fonctions Consult-03 (affichage des tarifs à partir du type de contrat) ou Consult-04 (affichage des tarifs à partir d'une catégorie). Remarquons également que certaines fonctions de consultation pourront se traduire par de simples filtres à placer sur les listes correspondantes. La fonction Consult-02 d'affichage de la liste des contrats impayés est indiquée en plaçant le filtre "DatePaiementPrime = NULL" sur la liste des contrats. Certaines fonctions sont des sous-fonctions de fonctions plus générales. Les fonctions SDoss-01, SDoss-02, SDoss-03 et SDoss-04 sont des sous-fonctions de SDoss-05 qui correspond à la saisie d'un dossier accident. Dans ce cas on n'indiquera dans le SNI que l'accès à la fonction principale. Enfin les droits et les conditions d'accès doivent être rajoutés sous la forme d'une expression entre crochets sur toutes les branches et sur toutes les arrivées latérales des branches protégées. Administration du projetPatron "administration"En plus des quatre acteurs principaux qui seront utilisateurs du logiciel, il faut définir un profil administrateur qui gèrera toutes les classes du point de vue de la création, modification et suppression d'objets. De façon standard ces opérations se présenteront toujours de façon similaire pour chaque classe du SNI. Ce qui nous amène à définir un cinquième patron d'IHM appelé administration. A titre d'exemple la figure ci-dessous montre quelle pourrait être l'IHM correspondant la gestion par l'administrateur de la classe contrats.
|
 |
