La m�thode de g�nie logiciel MACAO, M�thode d?Analyse et de Conception Orient�e-Objet, (Crampes, 2003), (JBCC, 2008) propose une d�marche it�rative bas�e sur la conception et le d�veloppement de prototypes incr�mentaux. Elle pr�conise une participation active des utilisateurs � chaque it�ration en positionnant l?Interface Homme-Machine (IHM) comme une composante majeure de la d�marche. La prise en compte de cet aspect impose la d�finition d?un mod�le commun utilisateur?concepteur afin de dialoguer de fa�on constructive pour l?acquisition et la compr�hension des exigences.

Actuellement, divers mod�les sont utilis�s pour la mod�lisation des IHM. On trouve les diagrammes d?activit�s, d?�tats-transitions (Wasserman, 1995), (Horrocks, 1999), d?interaction, les r�seaux de P�tri (Palanque et Bastide, 1995). Tous ces mod�les, tr�s g�n�raux, proposent des repr�sentations souvent complexes et difficilement utilisables lors d'un dialogue avec un utilisateur. Une tentative d'adaptation d'UML � la mod�lisation des IHM a �t� faite par Paulo da Silva avec UMLi �(Pinheiro Da Silva et Paton, 2001). Cependant, cette mod�lisation ne semble pas satisfaisante en mati�re de lisibilit� par l'utilisateur final car elle ne fait que rajouter de nouveaux symboles (triangles, cubes?) aux mod�les UML souvent d�j� surcharg�s.

C?est dans ce contexte que nous proposons le mod�le SNI (Sch�ma Navigationnel d?Interactions) qui devient un support de communication suppl�mentaire pour les intervenants d'un projet et dont les objectifs essentiels sont :

• proposer un langage commun adapt� � la communication entre les r�alisateurs et les utilisateurs,

• mod�liser l?IHM en termes de navigation entre ses diff�rents objets, de droits d?acc�s et de couverture fonctionnelle du logiciel,

• permettre une g�n�ration quasi-automatique du code de l?IHM conform�ment � l?approche MDA (Miller et al., 2003) (Dupuy-Chessa et Dubois, 2005) (Sedogbo, Grisvard et al., 2006) en utilisant les transformations de mod�les. Le passage du SNI au code est r�alis� via un mod�le interm�diaire adapt� � chaque type d?IHM.

Dans la m�thode MACAO, les mod�les d?IHM sont utilis�s lors de l?�tape d?analyse globale pour l?acquisition des exigences, lors de la conception globale pour d�crire l?architecture de l?IHM et lors du d�veloppement, pour r�aliser des maquettes et g�n�rer le code du logiciel. Ces mod�les vont dans le sens d'une am�lioration de l'utilisabilit� des logiciels comme expos� en (Constantine et Lockwood, 1999), (Crampes et Nonne, 2005)

�et (Nielsen 2003). Pour cela, MACAO propose deux niveaux de mod�les dont l'int�r�t est de pouvoir pr�ciser les fronti�res de l?IHM entre le ��Quoi-Fonctionnel�� de la phase d?analyse-conception et le ��Comment-Technologique�� de la phase de r�alisation 1:

C?est au niveau de l'analyse que l?on capture les exigences du client et que l?on d�finit la navigation globale dans l?IHM. Le SNI utilis� en mode "esquisse" (trac� en temps r�el au fur et � mesure de la d�couverte des besoins) est le mod�le adapt� � ce niveau. Utilis� en mode conception, mettant en ?uvre des patrons de conception, il permet de structurer compl�tement la navigation dans l'IHM.

La r�alisation raffine le niveau pr�c�dent et permet de prendre en consid�ration des domaines technologiques sp�cifiques. Ainsi, le Sch�ma d?Encha�nement des fen�tres (SEF) et le mod�le D�finition de Fen�tres (DEF) sont-ils adapt�s � la repr�sentation d?une IHM de type fen�tr� (client lourd ou riche) alors que le Sch�ma d?Encha�nement des pages Web (SEP) et le mod�le D�finition des pages (DEP) sont mieux adapt�s � la repr�sentation Web (client l�ger). Enfin, le Sch�ma d?Encha�nement Multimodal (SEM) et le mod�le DEfinition Multimodale (DEM) sont utilis�s pour d�crire des IHM faisant intervenir plusieurs modalit�s telles que le vocal ou le tactile (type iPhone d'Apple). Le passage d?un niveau � l?autre se fait au moyen d?outils et de langages de transformation de mod�les pour permettre de g�n�rer in fine le squelette du code source d'un logiciel interactif.

La suite de cet article est structur�e en cinq sections :

• une pr�sentation du formalisme SNI en section 2,

• un descriptif de son m�ta mod�le en section 3,

• une pr�sentation du mod�le logique SEF et de son m�ta-mod�le en section 4,

• un examen rapide des r�gles de transformation du SNI en SEF ou en JSF, en section 5,

• une br�ve description du module Visual-SNI de l?AGL MACAO en section 6.

Le SNI est d�fini comme un profil UML d�riv� du diagramme d?activit� UML 2.0 (Fowler, 2004). C'est un mod�le de haut niveau d?abstraction permettant de repr�senter uniquement les exigences fonctionnelles, le "quoi" de l'analyse-conception. De ce fait, il est compl�tement ind�pendant de la plateforme physique et en particulier du type d?IHM envisag� pour la r�alisation (Windows, Web, Mobile, Multimodal ou autres). De m�me, il ne repr�sente ni les moyens d?interaction (menu d�roulant, bouton poussoir, glisser-d�poser, etc.), ni les aspects mat�riels mis en ?uvre (clavier, type d?�cran, souris, etc.) qui sont du ressort du niveau r�alisation. Par ailleurs, il ne prend pas en compte l?ex�cution des traitements (calcul, acc�s aux donn�es, etc.).

Le SNI s?appuie sur le concept d?Unit� de Dialogue (UD) qui repr�sente une vue �l�mentaire de l?interaction homme-machine. Il existe deux types d?unit�s de dialogue, les �l�mentaires et les compos�es.

Les unites de dialogue �l�mentaires (UDE)

Une UD est dite �l�mentaire si elle correspond � une op�ration d?IHM ind�composable. Le tableau 2 d�crit une classification des UDE en cinq cat�gories telle qu?elle appara�t dans MACAO et illustre chaque UDE avec un exemple.L?exp�rience acquise dans de nombreux projets concrets a montr� que ces cinq cat�gories �taient n�cessaires et suffisantes pour mod�liser conceptuellement tout type d?IHM quelle que soit sa nature et sa complexit�. Paulo da Silva dans UMLi est d'ailleurs arriv� � la m�me conclusion en proposant une cat�gorisation semblable pr�sent�e � la 2^�me remarque de la section 3.1.

Les unit�s de dialogue compos�es (UDC)

Plusieurs UD �l�mentaires peuvent �tre regroup�es pour constituer une UD compos�e. Une UD compos�e permet, d?une part, de regrouper plusieurs informations de nature proche pour optimiser le travail de l?utilisateur, et d?autre part, de parall�liser plusieurs interactions conform�ment � la fa�on de proc�der de l?utilisateur dans l?ex�cution de ses t�ches.

Dans les diagrammes SNI, la composition de plusieurs UD peut �tre r�alis�e simplement par juxtaposition de deux UDE �ou en utilisant une bo�te de groupage. Ces deux repr�sentations sont s�mantiquement proches (cf. section 3.1). L'utilisation de l'une ou de l'autre d�pend essentiellement d'une facilit� de repr�sentation dans le SNI.

La figure 1 montre la juxtaposition d'un affichage et d?une saisie pour former une UDC de modification.

La composition d?une UDC par groupage est illustr�e en figure 2 avec l?affichage simultan� d?un annonceur et de la liste des voitures �mises en vente.

Pour illustrer notre propos, prenons l?exemple d?une classe "V�hicule" enregistr�e dans une base de donn�es de ventes de v�hicules d'occasion.

L'administration de cette classe doit permettre � une personne autoris�e, l'administrateur, d'afficher tous les v�hicules propos�s � la vente, de modifier ou de supprimer un v�hicule donn� et d?ajouter des v�hicules. Il pourra �galement imprimer la liste des v�hicules mis en vente. Toutes ces op�rations sont repr�sent�es par le SNI de la figure 4.

Des concepts suppl�mentaires ont �t� d�finis dans le mod�le SNI pour d?une part, permettre la prise en compte d?exigences particuli�res des utilisateurs du logiciel concernant l'IHM, et d?autre part d?int�grer �de la flexibilit� dans la structuration des diagrammes.

Les compl�ments li�s aux exigences des utilisateurs sont�:

• l?utilisation de fonctions "FILTRE" et "TRI" lors de l?affichage d'une collection d'objets,

• la notion de "r�le" indiquant les autorisations ou les interdictions de parcours de certaines branches du SNI suivant le type d?utilisateur,

• la notion de condition ou "garde" permettant de parcourir certaines branches en fonction de l?�tat des objets.

Les compl�ments li�s � la flexibilit� d'�criture des diagrammes�concernent l?invocation d?un sous-SNI �� plusieurs niveaux ainsi que la d�cision et la jonction qui permettent de parcourir diff�rentes branches sous des conditions ind�pendantes des choix utilisateur. Il s?agit aussi du d�coupage en planches permettant de construire un SNI complexe tout en gardant une bonne lisibilit�, et des �tiquettes de branchement sur une UD ou une planche particuli�re.

Le m�tamod�le du SNI se pr�sente sous forme de trois paquetages le SNI_UD, le SNI_N?ud et le SNI_Port. Remarquons que, pour simplifier sa pr�sentation, nous n'avons pas fait appara�tre ici les compl�ments de mod�lisation.

Ce paquetage pr�sente la structuration des diff�rentes unit�s de dialogues compos�es et �l�mentaires du mod�le SNI. La m�taclasse UDE est directement d�riv�e de la m�taclasse UML 2.0 "Action" �(OMG, 2004). Il en est de m�me pour UDC qui d�rive de "Structured-ActivityNode".

Comme nous venons de le voir, les �l�ments de base du SNI sont des UDE et des UDC. Les UDE repr�sentent les actions du diagramme d'activit�. Une UDC est compos�e de plusieurs UD. Une UDC peut �tre sp�cialis�e en juxtaposition (UDC_J) ou groupage (UDC_G). Une UDE peut se sp�cialiser en Menu, Saisie ou Pr�sentation. La pr�sentation peut elle-m�me se sp�cialiser en Message, Collection et Objet. La m�taclasse Menu repr�sente un ensemble d?options propos�es de fa�on simultan�e � l?utilisateur. Un menu est compos� de groupes d?options actives sous la m�me condition. Par exemple,�dans la figure 4, les options Nouveau et Imprimer repr�sentent un premier groupe d?options activables dans tous les cas. Par contre, le groupe compos� de la seule option "D�tail" n?a d'existence que si un v�hicule a �t� s�lectionn� dans la liste.

Remarques :

a. Bien que le SNI soit en r�alit� un diagramme d'activit�s UML profil�, il a �t� n�cessaire d'en r�aliser un m�tamod�le (DSL) complet car les premiers essais de mise en ?uvre r�alis�s en profilant simplement le diagramme d'activit�s dans l'AGL "Together" de Borland ont montr� de gros probl�mes d'utilisabilit�.

b. Les concepts d'UD, d'UDE et UDC se retrouvent dans le mod�le UMLi de Paulo da Silva (Pinheiro Da Silva et Paton, 2001). Ils sont appel�s respectivement InteractionObject, Primitive-InteractionObject et Container. Les PrimitiveInteractionObjects recouvrent les Inputters (Saisie), Displayers (Pr�sentation), Editors (Modifications : combinaison d'une pr�sentation et d'une saisie) et ActionInvokers (Menu).

Le paquetage SNI_N?ud structure les objets de connexion comme le montre la figure 6. Il existe trois types de n?uds dans le SNI : la D�cision, la Jonction et l?Invocation qui d�rivent directement des m�taclasses "DecisionNode", "MergeNode" et "CallBehaviourAction" du diagramme d?activit� UML 2.0.

Un port est un objet abstrait attach� � une UD ou � un n?ud permettant d?�tablir les connexions. Chaque ObjetSNI peut comporter un ou plusieurs ports d?entr�e (IN) et un ou plusieurs ports de sortie (OUT). Par exemple,�un menu comporte un port d?entr�e et N ports de sortie qui correspondent aux options du menu.

A un port d?entr�e, il est possible d?associer une pr�condition qui joue un r�le de garde en interdisant l?entr�e dans un objet. De la m�me mani�re, � un port de sortie, on peut associer une postcondition qui bloque la sortie tant quelle n'est pas v�rifi�e. Par exemple, dans un site de e-commerce, le client ne peut pas commander si son panier est vide.

En figure 7, le paquetage SNI_Port montre qu'il existe deux types de ports, les ports d'entr�e (In) et les ports de sortie (Out). Un port d'entr�e peut �tre connect� � un port de sortie par un lien qui d�rive de la m�taclasse UML "ObjectFlow". A un port d'entr�e, on peut attacher une pr�condition et � un port de sortie une postcondition. L?une et l?autre sont des expressions UML2.0.

Alors que le mod�le de haut niveau (SNI) manipule des unit�s de dialogue (UD), les mod�les de niveau logique mettent en ?uvre des composants d'IHM (ou Unit�s Logiques de Dialogue) qui repr�sentent la mise en ?uvre des UD sur une plateforme technique sp�cifique (Domain?Specific Language) : fen�tre pour les IHM de type Windows, page pour les IHM de type WEB, message vocal pour les IHM multimodales, toucher pour les entr�es tactiles, etc.

Le niveau logique se compose en r�alit� de deux types de mod�les. Le Sch�ma d'Encha�nement (SE) mod�lise la dynamique d'ouverture des composants en r�ponse aux �v�nements tels que une action utilisateur, une condition remplie, la d�tection d'une erreur ou une interruption syst�me.Le 2^�me mod�le intitul� ��D�finition des Composants�� (DC) d�crit d'une part, le contenu statique des composants en termes de widgets �(menus, contr�les, textes, ic�nes, messages vocaux, entr�es vocales?), et d'autre part, leur positionnement dans le composant. Dans cet article, nous ne nous int�resserons qu'� l'aspect dynamique des IHM de type Windows (GUI). Dans ce contexte, les composants d'IHM sont les fen�tres et la mod�lisation de leur encha�nement est r�alis�e gr�ce � un profil UML sp�cifique appel� ��Sch�ma d'Encha�nement des Fen�tres�� (SEF).

Classiquement, les IHM GUI sont compos�es de deux grandes cat�gories d'objets � savoir les conteneurs qui repr�sentent les composants (menu ou fen�tre) et les contr�les qui sont les objets �l�mentaires d'interaction avec l'utilisateur.

Nous distinguons quatre types de fen�tres : Fen�tre Primaire (FP ou Principale de l'application), Fen�tre Secondaire (FS), Bo�te de Dialogue (BD) et Bo�te de Message (BM). �Les cinq types de menus sont :

• la Barre d'actions (BA),

• la Barre d'Outils (BO),

• le Menu d�roulant (MD),

• le Menu Contextuel (MC),

• le Groupe d'Onglets (GO).

Les contr�les se r�partissent en diverses classes telles que :

• Statiques (STC pour Statique Texte Constant, STV pour Statique Texte Variable?).

• Boutons (BP pour Bouton Poussoir, BC pour Bouton Case � cocher, BR pour Bouton Radio).

• Entr�es telles que l?Entr�e Simple (ES) et l?Entr�e Multi-lignes (EM).

• Listes et Collections qui regroupent la Liste d�roulante Simple(LS), la Liste d�roulante D�veloppable (LD), la Liste Combin�e (Combo) Simple (LCS), la Liste Combin�e D�veloppable (LCD), la Table, l?Arbre, etc.,

• Options regroupant les diverses options de Menu, Onglet, Ic�ne, etc.

Cette liste bien qu?elle soit non exhaustive car d'autres types de contr�les personnalis�s peuvent �tre d�finis en fonction des exigences des utilisateurs, sera la base pour l'�laboration du m�ta-mod�le.

Le SEF permet de repr�senter la dynamique d'ouverture des fen�tres de l'application. Il n'utilise qu'un seul type de symbole graphique pour repr�senter les conteneurs : un rectangle divis� verticalement en deux parties. La partie gauche contient les caract�ristiques g�n�rales du conteneur telles que le type (FP, FS, BD, BM, MD, MC), le nom, les droits d'acc�s ou les param�tres d'ouverture. La partie droite est divis�e en autant de lignes que de contr�les ou d'options situ�s dans le conteneur.

Si le nombre de contr�les est trop important, on n'indiquera que ceux qui participent � un �v�nement utilisateur impliquant l'ouverture d'un nouveau conteneur. Un dessin de fen�tre (DEF) est alors r�alis� pour pr�senter la totalit� d'entre eux ainsi que leur disposition g�ographique dans la fen�tre.

Les �v�nements sont repr�sent�s par des liens ayant pour origine les contr�les ou options g�n�rateurs d'�v�nements et pour destination les conteneurs � ouvrir. Les types d'�v�nements sont indiqu�s sur les liens (l'�v�nement par d�faut est le clic gauche souris). Des param�tres peuvent �galement �tre transmis � la fen�tre destinataire. Ils sont indiqu�s sur le lien, entre parenth�ses.

La �figure 8 illustre une fen�tre dans le SEF de type ��bo�te de dialogue�� qui �pr�sente le d�tail d'un v�hicule. Le Dessin (DESSIN) explicite le contenu de la bo�te de dialogue.

Reprenons, � titre d'exemple, le SNI de l'administration de la classe "V�hicule" vue en figure 4. �L'administration s'effectue en trois bo�tes de dialogue. Les UD de cr�ation et de modification d'un v�hicule ont �t� regroup�es en une seule bo�te de dialogue : BD-CreModifV�hicule. Les bo�tes de dialogue BD-D�tailV�hicule et BD-CreModifV�hicule sont incompl�tes, c'est pourquoi elles seront d�taill�es par un dessin non pr�sent� ici. La bo�te de dialogue CreModifV�hicule comporte un param�tre optionnel (entre crochets) selon qu'elle est ouverte � la suite d'une cr�ation (aucun param�tre) ou une modification (l'objet "v�hicule" doit �tre pr�sent).

L'impression est repr�sent�e par le m�me symbole que dans le SNI car il ne met pas en jeu de fen�tre si ce n'est une bo�te de dialogue commune non envisag�e ici, de choix de l'imprimante et des options d'impression.

Remarquons la pr�sence du param�tre "v�hicule" qui permet de r�aliser la liaison entre les fen�tres.

Comme pour le SNI, nous ne pr�senterons ici qu'une partie du m�ta mod�le afin de ne pas alourdir l'article. Sa totalit� pourra �tre fournie � la demande.

Le m�ta mod�le pr�sente les principaux objets graphiques composant le SEF. Les liens peuvent connecter tout type de contr�le ou d'option de menu � un conteneur (menu ou fen�tre). La classe des contr�les est sp�cialis�e en quatre sous-classes comportant des objets de diff�rents types (par exemple STC pour Statique Texte Constant ou ES pour Entr�e Simple). La classe Conteneur se sp�cialise en Menu et Fen�tre. Un menu peut �tre contextuel (MC), d�roulant (MD, une barre d'actions (BA) ou un groupe d'onglets (GO).

Deux types de transformation sont actuellement en cours de d�veloppement :

• SNI > SEF

• SNI > pages JSP dans le framework JSF de Sun.

Le but de cette transformation est de g�n�rer automatiquement le SEF � partir du SNI d'une application de fa�on � g�n�rer dans un deuxi�me temps le code du squelette du logiciel � r�aliser. Remarquons que le SEF reprend toutes les informations du SNI (sans perte) mais qu'il s'enrichit de sp�cificit�s li�es aux IHM GUI (type de contr�le, de fen�tre, de menu, etc.) auxquelles il faut ajouter la structuration des fen�tres (pr�sence d'un dessin de fen�tre) et des informations de navigation (�v�nement d�clencheur, param�tres).

Un ensemble de r�gles permet une transformation quasi-automatique du SNI en SEF. Cependant, l'intervention de l'utilisateur est parfois n�cessaire pour, par exemple, d�cider du type de contr�le � utiliser ou pour choisir le type de repr�sentation d'une collection sous la forme d'une liste d�roulante, d'une table ou d'un arbre. Par souci de concision, nous ne pr�senterons pas ici la totalit� des r�gles de transformation mais seulement celles qui permettent d'en expliquer le principe.

Le tableau 3 ci-dessous indique dans la colonne de gauche les types d'UD du SNI et dans la colonne de droite les objets graphiques correspondants. Chaque objet graphique est constitu� d'un conteneur suivi entre parenth�ses des objets qu'il contient (contr�les, barre d'outils, barre d'actions?). Lorsqu'un objet graphique n'appara�t qu'une seule fois dans un conteneur, il est pr�c�d� du chiffre "1" (par exemple, 1BA signifie une seule barre d'action). S'il peut appara�tre plusieurs fois, il est pr�c�d� du signe "*". Par exemple, *BO signifie aucune ou plusieurs barres d'outils alors que 1*BP signifie un ou plusieurs boutons poussoirs.

La pr�sence d'un "ou" indique que l'utilisateur devra faire un choix parmi plusieurs options possibles.

L'objectif de cette transformation est de g�n�rer automatiquement une maquette de site WEB dans le framework JSF de Sun. L'int�r�t est de pouvoir montrer rapidement � l'utilisateur quel est le r�sultat final obtenu afin d'apporter imm�diatement les modifications �ventuelles au SNI et de converger ainsi plus rapidement vers une solution satisfaisante en termes de couverture fonctionnelle, d'encha�nement des fonctions, de droits d'acc�s.

Remarquons que le choix de JSF en tant que langage cible a �t� dict� par son adoption dans la plupart des projets d'Airbus Industrie, principal client de Capgemini Sud.

A partir d'un SNI, le g�n�rateur SNI2JSF est capable de construire une maquette utilisateur avec les pages WEB et leur encha�nement. En fait, il g�re la partie visuelle de l'application. Dans l'approche MVC, ceci correspond � d�crire la partie "View". Dans une applicathttps://em>tiers, cela correspond � la couche pr�sentation. �

Comme le montre la figure 11, le g�n�rateur SNI2JSF transforme un SNI en un ensemble structur�https://es JSP du framework JSF en utilisant le m�ta-mod�le du SNI (SNI-MM) et un Template d�crivant la forme g�n�rale des pages JSP � g�n�rer. Les templates sont des patrons de g�n�ration �crits dans le langage Xpand2 qui int�grent le savoir-faire des concepteurs-d�veloppeurs en mati�re de pr�sentation finale des pages. En changeant de fichier Template, il est possible de g�n�rer des pages avec des formats diff�rents suivant les besoins de l'utilisateur.

La m�thode de transformation s'appuie sur le framework oAW (open Architecture Ware) du projet Eclipse GMT (Generative Modeling Technologies) (cf. https://www.eclipse.org/gmt/oaw/).

Un premier prototype du g�n�rateur SNI2JSF a �t� r�alis� en collaboration avec Capgemini Sud et est en cours de validation.

Le m�tamod�le du SNI a permis la r�alisation d'un �diteur graphique de SNI qui a �t� d�velopp� sous la forme d'un plugin Eclipse sous le nom de VisualSNI. Cet �diteur est disponible en licence GPL � l'adresse suivante : https://sourceforge.net/projects/visual-sni/.

Les trois paquetages du m�tamod�le ont �t� fusionn�s afin qu?on puisse les reprendre par EMF (Eclipse Modeling Framework) (Moore, Dean and al., 2004) pour g�n�rer l'ensemble des classes Java n�cessaires d'une part, � la construction graphique d'un SNI, et d'autre part � la gestion de la persistance du mod�le sous forme de fichiers XMI (XML Model Interchange).

L'�diteur graphique a �t� construit en utilisant le framework GEF (Graphic Editor Framework) (Moore, Dean et al., 2004) selon une architecture de type MVC qui permet de d�coupler l'�dition graphique, r�alis�e par le plugin Draw2D, de la gestion des mod�les r�alis�e par EMF.

Comme le montre la figure 14, l'�diteur VisualSNI est un plugin Eclipse permettant, dans le cadre d'un projet Java, de g�n�rer des planches de SNI, graphiquement dans une zone d'�dition et sous forme de fichiers au format XMI.

Comme le montre la figure 14, l'�diteur VisualSNI est compos� d'une zone de gestion des ressources (1), d'une barre d'outils (2), d'une zone d'�dition graphique (3), d'une vue globale ou Outline (4), d' une palette d'outils (5) et d'une zone d'�dition des propri�t�s des objets (6). Les planches de SNI apparaissent sous forme d'onglets (7).

La figure 15 montre la structure du fichier XMI g�n�r�e lors de la construction du SNI pr�sent� � la figure 14. On peut y voir la description des deux premiers objets : "Debut" (bulle 1) et "AffListe" (bulle 2).

La mise en ?uvre de MACAO et de ses mod�les d'IHM, principalement le SNI, dans divers projets industriels (CNES, Capgemini Sud, Branche Recouvrement de la S�curit� Sociale regroupant une centaine d'URSSAF), a permis de mettre en �vidence trois types d'utilisation :

• aide � l'acquisition et � la compr�hension des exigences,

• conception d�taill�e de l'IHM (Rocques, 2006),

• refactoring de l'IHM.

a) Aide � l'acquisition des exigences

Au travers de plusieurs projets r�cents (comme PDA de la soci�t� SICLI, suivi d'exp�riences � l'INRA, SARSAT pour l'arm�e), Capgemini Sud a pu constater que l'utilisation du SNI en tant que langage de dialogue avec les clients lors de la phase d'acquisition des exigences, a am�lior� de fa�on sensible la compr�hension mutuelle des besoins concernant les interactions homme-logiciel. En effet, la plupart des logiciels actuels s'articulent autour d'une IHM complexe (graphique, multimodale, multim�dia, etc.), s?encha�nant suivant une logique choisie par l'utilisateur et int�grant de nombreux objets de dialogue et des r�sultats pouvant rev�tir une grande vari�t� de formes (fen�tres Windows, pages WEB, outils sp�cialis�s de visualisation ou de saisie, etc.). La r�alisation de telles IHM est parsem�e de pi�ges qui sont g�n�rateurs de risques importants pour la rentabilit� du projet en cours. Les pi�ges sont g�n�ralement de deux natures :

• l'IHM est la seule partie du logiciel visible par l'utilisateur et c'est donc sur elle que se focalisera son attention,

• un logiciel est rarement utilis� par une seule personne (diversit� de points de vue), aussi faudra-t-il obtenir un modus vivendi d'autant plus difficile � atteindre que l'aspect "artistique" d'une IHM joue souvent un r�le important. Le choix des couleurs, des polices, des ic�nes, l'incrustation d'images et d'animations, la disposition des objets, sont autant de motifs de m�sentente et donc de d�rapage du projet.

Afin de limiter ces inconv�nients, il est essentiel d'�tablir un dialogue constructif avec les utilisateurs. Ceci n�cessite l'utilisation d'un langage commun de communication permettant non seulement d'acqu�rir et de d�crire leurs exigences mais encore de leur rendre compte (feed-back) de la compr�hension des choses et des solutions propos�es.

Le SNI a permis d'am�liorer ce dialogue mais a montr� certaines limites, notamment celle d'une trop grande abstraction, m�me utilis� en mode esquisse (cf. section 1.2). C'est pour cette raison que la r�alisation d'un g�n�rateur de maquettes JSF a �t� entreprise. Ce g�n�rateur �tant actuellement en cours de r�alisation, il n'a malheureusement pas pu, � ce jour, �tre �prouv� en situation r�elle.

b) Conception d�taill�e de l'IHM

Le projet CARINS (CAlcul de R�seaux en r�gime INStationnaire) du Centre National d'Etudes Spatiales a pour objectif de r�aliser un logiciel modulaire permettant de rendre compte des �volutions temporelles des grandeurs physiques caract�risant les syst�mes propulsifs de lanceurs spatiaux pendant les diff�rentes phases de leurs missions.

Le logiciel permet de construire graphiquement un r�seau maill�, appel� "synoptique moteur" o� chaque branche contient un objet du syst�me propulsif �tudi� (vanne, canalisation, chambre de combustion, etc. ). La repr�sentation math�matique de chacun de ces objets doit se pr�senter sous la forme d?un syst�me d?�quations diff�rentielles explicites issues des lois d'�volution relatives aux diff�rents ph�nom�nes de transfert thermodynamiques. CARINS doit ensuite produire le syst�me d?�quations g�n�ral, c'est-�-dire finalement construire le simulateur math�matique du syst�me propulsif �tudi�.

Le logiciel CARINS �tant destin� aux ing�nieurs motoristes de la Direction des Lanceurs du CNES, il �tait indispensable que son IHM leur soit parfaitement adapt�e tant du point de vue de son ergonomie que de sa structure. Cela �tait d'autant plus complexe � obtenir que la premi�re version de CARINS comprenait plus de 500 fonctions utilisateur r�parties dans 43 cas d'utilisation.

La m�thode MACAO a permis de construire un SNI complet de l'IHM en �troite collaboration avec les motoristes du CNES. Ce SNI se d�veloppe sur 35 planches avec le logiciel VisualSNI, chacune pr�sentant un aspect particulier de l'IHM. Gr�ce � lui, il a �t� possible de d�velopper le logiciel en respectant � la fois les d�lais impartis et les besoins exprim�s.

c) Refactoring de l'IHM

Un besoin de plus en plus fr�quent r�side dans la reprise d'un logiciel ancien ayant une technologie d'IHM d�pass�e (par exemple de type client lourd ou riche) dans le but de la moderniser dans le cadre des nouvelles technologies (par exemple de type client l�ger WEB) et cela sans modifier ses fonctionnalit�s (isofonctionnalit�).

L'utilisation du SNI en tant que langage pivot permet de r�aliser une telle op�ration avec un minimum de risques.

Comme l?illustre la figure 16, le processus de refactoring d�bute par une r�tro conception de l'IHM existante de fa�on � traduire l'ensemble des ses fonctionnalit�s et leur encha�nement sous forme de SNI. A partir du SNI obtenu, on peut alors entreprendre une phase classique de construction de la nouvelle IHM en passant par le SEF (Windows-like) ou le SEP (WEB) suivant le type d'IHM souhait�.

Ce travail de refactoring a �t� r�alis� dans la Branche Recouvrement o� une centaine d'URSSAF utilisaient le logiciel de Workflow WATT sous Lotus-Notes et Domino. Voulant �voluer vers un moteur de Workflow utilisant les standards actuels du BPM (SGBD relationnel, client l�ger, SOA-BPEL, Java?), il a fallu reprendre enti�rement l'IHM Notes qui s'exprimait en termes de vues et de masques pour la traduire en pages JSP. Le passage par le SNI a permis de faciliter grandement cette migration qui a �t� r�alis�e en isofonctionnalit�.