Lors de l'étape de conception globale, il a été établi un SNI (Schéma Navigationnel d'IHM) pour l'ensemble de l'application. Dans le cadre de la conception détaillée, il est nécessaire de réaliser quatre actions concernant l'étude de l'IHM limitée au prototype courant :
- définir le sous-SNI associé au prototype,
- construire le SEF (Schéma d'Enchaînement des Fenêtres) ou le SEP (Schéma d'Enchaînement des Pages),
- dessiner les boîtes de dialogue ou les pages WEB complexes,
- ajouter les classes techniques d'IHM dans le diagramme des classes.
Le SNI du prototype
En partant du SNI global il faut maintenant mettre en évidence les unités de dialogue (UD) correspondant au prototype en cours d'étude. Pour cela, nous devons partir du périmètre fonctionnel du prototype et rechercher dans le SNI où se situent les UD correspondant au lancement de chacune des fonctions.
On éliminera du SNI toutes les UD et leurs chemins d'accès qui ne correspondent à aucune fonction mise en œuvre dans le prototype.
Lors du premier prototype, on conservera la structure générale des menus (menu général et sous-menus qui lui sont associés) même si certaines options n'aboutissent momentanément à aucune UD. Pour indiquer qu'une option est actuellement un cul-de-sac, on placera une croix sous le nom de l'option.
Les SNI des prototypes suivants seront obtenus tout simplement en complétant le SNI précédent avec les nouvelles UD.
Si le découpage initial du SNI en diverses planches de présentation a été bien fait, nous devrions retrouver un découpage presque équivalent dans les prototypes obtenus. Si ce n'est pas le cas, il est souhaitable de procéder à une nouvelle répartition des UD dans les planches afin d'avoir une certaine correspondance.
Illustrons cette opération avec le cas Assurance-Auto.
Le premier prototype implémente les fonctions correspondant à la gestion des contrats : consultation des tarifs, consultation des contrats, saisie des paiements des primes. Son SNI comportera donc la première planche dont on ne conserve que les options Tarif et Contrat, et la deuxième planche dans son intégralité (mis à part l'accès aux dossiers depuis un véhicule). On peut remarquer les croix pour indiquer que les options Compagnies et Dossiers sont pour l'instant des culs-de-sac.
A partir du SNI constitué pour un prototype, on réalise le Modèle Logique d'IHM (MLI) qui correspond à l'adaptation du SNI à une technologie d'IHM particulière (Windows, WEB, Multimedia). Dans le cadre de ce site nous ne nous intéresserons qu'à la seule technologies GUI] et la réalisation du SEF (Schéma d'Enchaînement des Fenêtres). La prise en compte des technologies WEB [PUI] avec la réalisation du SEP (Schéma d'Enchaînement des Pages) et les dessins de pages WEB complexes est présentée dans l'ouvrage "Méthode orientée-objet intégrale MACAO" de Jean-Bernard Crampes, éditée aux éditions Ellipses.
En ce qui concerne les technologies multimedia (entrée et sortie vocale, écrans tactiles, joystick...) des pages spécifiques seront présentées ultérieurement sur ce site.
En préambule nous considèrerons ici que l'IHM GUI à réaliser respectera les standards qui mettent en oeuvre les contrôles habituels.
Avec cette contrainte, la transformations du SNI en SEF s'effectue en appliquant des règles de transformation qui donnent la correspondance entre les UD (UDE et UDC) et les fenêtres GUI. Pour comprendre le fonctionnement de ces règles examinons les deux premières :
Menu de premier niveau --> FP (1BA, *BO)
Signifie que le menu de premier niveau (menu principal) sera transformé en une fenêtre primaire (FP) composé d'une barre d'actions obligatoire (BA) et d'aucune ou plusieurs barres d'outils (*BO)
|
|
Menu autre niveau --> MD ou MC ou GO
Signifie qu'un menu quelconque (autre que le menu principal) sera transformé soit en un menu déroulant (MD), soit en un menu contextuel (MC), soit en un groupe d'onglets (GO) qui correspond à une boîte de dialogue à onglets. Le choix de la solution est laissé à l'appréciation du concepteur éventuellement aidé par l'utilisateur.
|
|
Saisie --> BD de saisie(*contrôle, 1 BP_Valider,
1 BP_Annuler
Signifie qu'une saisie se traduira par une boîte de dialogue de saisie comportant un nombre variable de contôles divers plus un bouton Valider et un bouton Annuler
|
|
A titre d'exemple construisons le SEF correspondant au SNI ci-dessus (planche 1 du projet "Assurance auto").
Conception des boîtes de dialogue complexes
Lorsqu'une boîte de dialogue comporte un nombre important de contrôles (plus de huit par exemple), il n'est pas conseillé de tous les indiquer dans le SEF car d'une part, les figures vont devenir énormes au détriment de la lisibilité du SEF qui, rappelons le, est plus orienté vers la navigation entre les fenêtres que sur leur contenu, d'autre part il est bon de pouvoir d'ores et déjà réfléchir à l'organisation des contrôles dans les fenêtres, même si cela doit être remis partiellement en question au moment du codage pour des problèmes ergonomiques et esthétiques.
