Methode d’implementation efficace des modeles PAC etPAC-Amodeus

Thierry DuvalIRISA

Campus de Beaulieu35042, Rennes, Francethierry.duval@irisa.fr

RESUMECe tutorial propose une methode permettant de mettre enœuvre efficacement les modeles PAC et PAC-Amodeus enutilisant des patrons de conception bien connus. Cettemethode est presentee ici en deux etapes : tout d’abord pourvisualiser graphiquement des concepts d’un noyau fonc-tionnel initial, en creant de nouveaux composants servantde proxys a certains composants applicatifs et associes ades composants de presentation, et ensuite pour rendre in-teractifs ces nouveaux composants, par heritage des com-posants illustres. Pour ne pas compliquer inutilement lesexemples nous nous focaliserons essentiellement sur cettepremiere etape de visualisation, qui sera abordee de troisfacons differentes, afin de montrer plusieurs mises en œu-vres possibles des modeles PAC et PAC-Amodeus. La sec-onde etape, qui consiste a rendre interactifs les composantsainsi rendus visibles, sera ensuite la meme pour les trois ap-proches. L’exemple utilise pour decrire les methodes em-ployees sera celui des tours de Hanoı, que l’on concevratout d’abord d’un point de vue logique (c’est-a-dire nongraphique et non interactif), puis que l’on fera evoluer enune version illustree, puis finalement en une version interac-tive ou l’utilisateur pourra deplacer les anneaux d’une toura une autre en mode glisser - deposer (Drag’n Drop). Larealisation se fera en utilisant le langage java et son APIgraphique Swing.

Mots ClésImplementation de modeles d’architecture pour les IHM, Pa-trons de conception pour les IHM

ABSTRACTThis aim of this tutorial is to propose a methodology to im-plement efficiently the PAC and PAC-Amodeus software ar-chitectural models for Graphical User Interfaces. The ideais to be able to associate to these two models the use of wellknown sofware design patterns. First, we propose a method-ology able to visualize the concepts embedded in an object

oriented kernel : we present three ways to create new com-ponents that will serve as proxys to the initial objects wewant to visualize. Then, we propose a way to extend theseproxys to make interactive the initial software. Showing howto solve the HanoıTowers problem is the example taken to il-lustrate this methodology. This software is first designed toprint to the screen how to solve the problem, then we pro-pose a graphical visualisation to the solving of the problem,and last we propose the user to solve the problem by him-self, by interactively dragging and dropping the rings fromone tower to another, thanks to direct manipulation of therings.

KeywordsImplementation of Software Architectural Models for GUI,Design Patterns for GUI

CATEGORIES AND SUBJECT DESCRIPTORSD.1 [Software] : Programming Techniques; D.2 [Software] :Software Engeenering; H.5 [Information Systems] : Infor-mation Interfaces and Presentation

GENERAL TERMSDesign

INTRODUCTIONCe tutorial propose une methode permettant de mettre enœuvre efficacement les modeles PAC [1] et PAC-Amodeus[8] (l’extension du modele PAC inspiree du modele Arch[9]) en utilisant des patrons de conception bien connusdetailles dans le “GoF” [5]. Ces patrons de conception sontprincipalement le “Proxy” (GoF207), le “Template Method”(GoF325), “l’Abstract Factory” (GoF87), le “Singleton”(GoF127), et egalement “l’Observer” (GoF293). On pourraaussi comparer ceci a l’usage d’autres patrons de conceptionpresentes dans [6] tels que l’Interface et le Delegation.

Cette methode est presentee en deux temps. Tout d’abordpour visualiser graphiquement des concepts d’un noyaufonctionnel initial, en creant de nouveaux composants ser-vant de proxys (patron “Proxy” (GoF207)) a certains com-posants applicatifs et associes a des composants de presenta-tion. Ensuite nous montrons comment rendre interactifs cesnouveaux composants, par heritage des composants illustres.

L’idee est ici de definir les services rendus par les elementsapplicatifs a l’aide d’interfaces que ces elements doivent

alors implementer (patron “Template Method” (GoF325),ou tout simplement le patron Interface). Cela permet alorsd’utiliser des fabriques de composants (patron “AbstractFactory” (GoF87)) pour creer ces composants de facon a ceque des composants visuels ou interactifs associes soient lesplus independants possible de l’implementation effective descomposants applicatifs.

Pour chaque composant applicatif a rendre interactif, il estalors possible de fournir un proxy qui va etre un composantcharge de gerer l’acces au composant applicatif et de met-tre en place une infrastructure permettant de repercuter vi-suellement les evolutions de ce composant applicatif via uncomposant de presentation qui lui sera associe plus ou moinsdirectement selon le modele d’architecture choisi.

Si le modele d’architecture retenu est PAC, le composant ser-vant de proxy sera la facette controle d’un composant PAC,le composant applicatif etant alors la facette abstraction cor-respondante.

Si le modele d’architecture choisi est PAC-Amodeus, lecomposant servant de proxy sera un composant Adaptateurde Noyau Fonctionnel, lequel sera ensuite rattache a unefacette abstraction d’un composant PAC. On a vu dans [3]et [4] qu’une telle decomposition pouvait ensuite etre opti-misee pour supprimer le composant ANF ainsi que la facetteabstraction, on se retrouve alors dans un schema equivalenta celui obtenu avec le modele PAC.

Dans le patron de conception Proxy, le composant proxya exactement la meme interface que le composant dont ilregule l’acces. Ici, dans nos differents cas d’utilisation, noscomposants proxy auront une interface etendue pour perme-ttre une utilisation dans le cadre des IHM, pour permettrenotamment l’acces a leur composant de presentation associe.

On parlera egalement ici de l’usage du patron de concep-tion Singleton (GoF127) pour que les composants qui enont besoin puissent facilement acceder a la fabrique de com-posants, comme evoque dans [2].

L’exemple utilise pour decrire les methodes employees seracelui des tours de Hanoı, que l’on concevra tout d’abord d’unpoint de vue logique (c’est-a-dire non graphique et non inter-actif), puis que l’on fera evoluer en une version illustree, puisfinalement en une version interactive ou l’utilisateur pourradeplacer les anneaux d’une tour a une autre en mode glisser- deposer (Drag’n Drop). La realisation se fera en utilisantle langage java et son API graphique Swing.

PREMIERE SOLUTION : PAC ET PROXY CONTROLE PAR

DELEGATIONNous ferons ici l’usage du concept bien connu d’Interface,tel qu’il est decrit dans [6] (le patron du GoF qui s’en rap-proche le plus est le Template Method), nous utiliseronsegalement le concept de Proxy, en l’implementant sous saforme classique qui est proche du patron de conception Del-egation. Enfin, les proxys se substitueront a leurs objetsdelegues grace a l’utilisation du concept d’Abstract Factory.

Le principeLes composants de controle associes a des objets applicat-ifs sont concus sur la base du patron de conception Proxy :chaque composant controle sera donc charge du filtrage descommunications entre son composant applicatif associe etles autres composants, comme illustre figure 1. Dans cetteutilisation on peut egalement considerer qu’on fait usage dupatron de conception Delegation decrit dans [6].

Figure 1. Patron de conception Proxy

De plus, pour eviter une trop grande dependance du proxyvis a vis de son composant associe, on utilise le patron deconception Template Method (GoF325) comme illustre fig-ure 2 (ou tout simplement l’Interface) et on force ainsi leconcepteur a definir l’interface d’acces a chacun de ses com-posants applicatifs.

Figure 2. Patron de conception Template Method

Indirectement, cette approche permet alors un premier us-age du patron de conception Abstract Factory pour permet-tre une evolution du comportement des composants applicat-ifs independamment des composants de controle associes.Cette premiere fabrique de composants sera ici essentielle-ment utilisee dans les classes de controle clientes des classesapplicatives.

Par la suite, on demande egalement que chaque composantcontrole implemente l’interface de son composant applicatifassocie, conformement au patron de conception Proxy. Uneseconde utilisation du patron Abstract Factory, illustre fig-ure 3 dans ce contexte, permet alors de substituer a chaque

Figure 3. Patron de conception Abstract Factory

composant applicatif initial son composant proxy associe.Dans notre cas cela va donc permettre de passer facilementd’un composant applicatif a un composant de controle prevupour une simple illustration, puis a un nouveau composantde controle prevu pour offrir une interaction a l’utilisateur(ici en mode Drag’n Drop). Ce seront toutes les autresclasses clientes (autres que des controles) des classes d’unnoyau initial, donc les classes qui feront egalement partie dunoyau initial, qui doivent faire appel a cette seconde fabriquede composants, pour creer des composants de controle a laplace des composants applicatifs et ainsi obtenir des appli-cations graphiques interactives.

Nous ferons donc la difference entre ces deux fabriquesde composants, et il devra etre possible d’obtenir l’une oul’autre selon les besoins des composants :

• les composants de controle auront a leur disposition unemethode permettant d’obtenir explicitement une fabriquede composants applicatifs, et egalement une methodepermettant d’obtenir explicitement une fabrique de com-posants de controle,

• les composants applicatifs utiliseront quant a eux unetroisieme methode qui leur permettra d’obtenir une seulefabrique de composants. Celle-ci sera une fabrique decomposants de controle lorsque les composants serontutilises dans un contexte interactif, et une fabrique de

composants applicatifs lorsque les composants seront u-tilises dans leur contexte initial non interactif.

Ces methodes utiliseront le patron de conception Singleton,illustre figure 4, pour d’une part assurer de ne creer qu’unefabrique de chaque type, et d’autre part pour faciliter l’accesa ces fabriques sans avoir a parametrer par une fabriquechaque composant susceptible d’en avoir l’usage.

Figure 4. Patron de conception Singleton

Enfin, il en sera de meme pour les composants de presenta-tion : il sera ici encore fait usage d’interfaces et d’unefabrique de composants de presentation. Ceci se fera viaune quatrieme methode permettant d’acceder cette fois aune fabrique de composants graphiques, destinee aux com-posants de controle pour creer leurs facettes presentation as-sociees, mais sans etre dependants de l’API graphique effec-tivement utilisee.

On voit donc ici l’interet de l’usage des patrons de concep-tionsuivants : Proxy (GoF207) (et Delegation), TemplateMethod (GoF325) (ou plus simplement Interface) et Ab-stract Factory (GoF87) pour faciliter les evolutions d’uneapplication a plusieurs niveaux :

• independance vis-a-vis des changements dans le noyauapplicatif (evolutions du noyau applicatif),

• passage d’un mode non graphique a un mode graphique(passage au modele PAC : remplacement des composantsapplicatifs par des composants de controle),

• passage d’un mode illustre a un mode interactif (evolutionsdu controle et de la presentation),

• independance vis-a-vis des API graphiques utilisees (evo-lutions de la presentation).

On voit egalement l’interet du patron de conception Single-ton (GoF127) pour faciliter l’acces aux differentes fabriquesde composants.

L’implementation en javaLe package des interfaces des composants applicatifsCe package regroupe seulement quatre interfaces : IAnneau,ITour, IHanoi et IFactory, comme on peut le voir figure 5.

Les interfaces IAnneau et ITour vont decrire les fonction-nalites essentielles des anneaux et des tours que l’on utilis-

Figure 5. Modelisation UML du package interface del’application

era pour realiser l’application de resolution du probleme destours de Hanoı. L’interface IHanoi va decrire les fonction-nalites d’une classe de resolution du probleme lui meme.Enfin l’interface IFactory va decrire les methodes a utiliserpour creer ces anneaux, tours et objet de resolution.

Le package applicatifOn y trouve simplement les quatre classes correspondant auxinterfaces precedentes : AAnneau, ATour, AHanoi et AFac-tory, qui implementent les interfaces decrites precedemment,comme on peut le voir figure 6. A noter qu’ici la classeAFactory est construite suivant le patron de conception Sin-gleton de facon a ce que tous les objets applicatifs qui en ontbesoin puissent facilement acceder a une instance unique decette classe de creation de composants.

L’utilisation des composantsLa methode de resolution “automatique” du probleme destours de Hanoı sera une methode de la classe AHanoi :

protected void hanoi (ITour d,ITour i,ITour a,int n) {

if (n > 0) {hanoi (d, a, i, n - 1) ;IAnneau anneau = d.getSommet () ;d.depiler () ;a.empiler (anneau) ;hanoi (i, d, a, n - 1) ;

}}

Notons que cette procedure ne manipule que des interfaces etpourra donc etre reutilisee par la suite pour manipuler toutessortes de classes implementant ces interfaces.

Une instance de la classe AHanoi pourra etre construiteainsi :

public AHanoi (int n) {IFactory f = concreteFactory.

ConcreteFactory.getFactory () ;this.n = n ;d = f.newTour ("d", n) ;i = f.newTour ("i", n) ;

Figure 6. Modelisation UML du package applicatif

a = f.newTour ("a", n) ;for (int ii = n ; ii > 0 ; ii --) {

d.empiler (f.newAnneau (ii)) ;}

}

Notons ici l’appel a une fabrique de composants pour ne pasdependre directement des composants utilises effectivement.Il faudra que cette fabrique ait ete initialisee correctement.

Moyennant cela, la methode de resolution pourra etre ap-pelee de l’exterieur a l’aide de cette methode qui utilise lestours declarees dans la classe de resolution.

public void solve () {hanoi (d, i, a, n) ;

}

La classe MainHanoi qui fait la creation effective de la fab-rique de composants, qui la place en position d’etre accessi-ble, puis qui cree une application de resolution, se resume acela :

public class MainHanoi {

public static void main (String a []) {int n = 3 ;if (a.length > 0) {

n = Integer.parseInt (a [0]) ;}concreteFactory.

ConcreteFactory.setFactory (abstraction.

AFactory.getInstance ()) ;

IHanoi h = concreteFactory.ConcreteFactory.getFactory ().

newHanoi (n) ;h.solve () ;

}

}

On trouve bien ici l’obtention d’une fabrique de composantsAFactory, placee dans une instance de ConcreteFactory afinde pouvoir etre accessible par la suite. Il est aussitot fait us-age de cette AFactory via une demande explicite a l’instancede ConcreteFactory, afin de creer une instance d’une classequi implemente l’interface IHanoi : ce sera ici une in-stance de AHanoi, a qui on pourra demander d’effectuer uneresolution du probleme.

Notons donc ici l’usage du patron de conception Singletonde facon a ne creer qu’une seule fabrique de composantsainsi que le stockage de cette fabrique dans un composantcharge de fournir la “bonne” fabrique de creation des “bons”composants.

Le package des interfaces des composants presentationCe package regroupe quatre interfaces :

• les deux qui sont destinees a decrire les presentations decomposants anneaux et tours qui permettront d’illustrer laresolution du probleme des tours de Hanoı : IPAnneau etIPTour,

• une troisieme, IPHanoi, destinee a fournir un receptaclepermettant d’accueillir ces presentations de tours et d’an-neaux,

• une quatrieme, IPFactory, qui decrit les methodes per-mettant de creer ces presentations d’anneaux, de tours, etd’application de resolution.

L’interface IPAnneau decrit les services essentiels a la visu-alisation d’un anneau :

• setLocation : pour positionner precisement l’anneau,

• slipTo : pour faire glisser un anneau de sa position actuellevers une position donnee,

• getHeight : pour obtenir la hauteur en pixels de l’anneau,servira a recalculer la position du sommet d’une tour.

L’interface IPTour decrit les services essentiels a la visuali-sation d’une tour :

• empiler : pour visualiser l’arrivee d’un nouvel anneau ausommet de la tour,

• depiler : pour visualiser le depart de l’anneau au sommetde la tour.

L’interface IPHanoi decrit le service essentiel a la visualisa-tion de l’application de resolution du probleme des tours deHanoı :

• ajouter : pour accueillir la visualisation d’une tour.

Le package de presentationCe package regroupe quatre classes. Les deux premieres,PAnneau et PTour, implementent, a l’aide de l’API Swing,les interfaces IPAnneau et IPTour decrites dans le packageinterfacePresentation. La classe PHanoi sera ici un con-tainer permettant d’accueillir essentiellement des instancesde PTour. Ces trois classes sont associees a la classe PFac-tory, qui implemente l’interface PFactory et qui permet decreer des instances de composants de presentation. Ceci estillustre figure 7.

Figure 7. Diagramme de classes du package presentation

La classe PAnneau va implementer l’interface IPAnneau etderiver de JPanel, c’est elle qui va decider :

• du nombre de pixels utilises pour representer la hauteurde l’anneau et l’unite de largeur de l’anneau,

• de la facon dont on positionne un anneau : setLocationagira ici au niveau du centre de l’anneau,

• de la facon dont on fait glisser un anneau d’une position aune autre : slipTo determine le temps de glissement.

La classe PTour va implementer l’interface IPTour et deriverde JPanel, c’est elle qui va decider :

• de la taille de la tour, relative au nombre maximumd’anneaux a accueillir,

• de la facon de visualiser l’arrivee d’un nouvel anneauau sommet de la tour : la methode empiler fera glisserl’anneau jusqu’aux coordonnees du dessus de la tour ex-primees dans le repere du container de la tour, elle ac-cueillera ensuite (d’un point de vue Swing, via un add) lapresentation de l’anneau, puis repositionnera cet anneau

relativement au systeme de coordonnees de la tour, et ferafinalement glisser l’anneau a sa place au sommet de latour, en coordonnees relatives a la tour.

• de la facon de visualiser le depart de l’anneau au sommetde la tour : la methode depiler va faire glisser l’anneauau dessus de la tour en coordonnees relatives a la tour,elle va ensuite abandonner l’anneau (d’un point de vueSwing, via un remove), et le replacera finalement dans lecontainer de la tour en le repositionnant au meme endroit,avec cette fois de nouvelles coordonnees exprimees dansle systeme de coordonnees de ce container.

La classe PHanoi va implementer l’interface IPHanoi etderiver de JFrame, c’est elle qui va decider de la facond’ajouter une visualisation de tour, en s’assurant qu’elle soitplacee, bien visible, a la suite des tours deja presentes, en seredimensionnant de facon adequate.

Le package des interfaces des composants controlesDans un premier temps, pour simplement obtenir une visu-alisation graphique des anneaux et des tours, on a seule-ment besoin de definir des interface ICAnneau, ICTour etICHanoi qui vont deriver respectivement des interfaces IAn-neau, ITour et IHanoi, comme illustre figure 8. Ces inter-faces ajouteront uniquement la declaration d’une methodepermettant de recuperer le composant de presentation as-socie.

Il n’y a pas besoin ici de definir une interface pour unenouvelle fabrique de composants de controle : l’interfacea utiliser sera imperativement celle du package interfaceAb-straction : IFactory.

Le package de controleIl va etre totalement independant de l’implementation choisiepour les composants abstraction car il les connaıtra seule-ment par l’interface que chaque composant de controle valui aussi implementer. Chaque composant de controle devracreer son composant applicatif associe en utilisant la fab-rique de composant applicatifs correspondante. Le choix decette fabrique est effectue dans le programme principal.

De meme, ce package va rester totalement independant del’implementation choisie pour les composants presentation,car ici encore il les connaıtra seulement par une interface, cescomposants de presentation seront egalement crees en util-isant la fabrique de composant presentation correspondante.Encore une fois le choix de cette fabrique est effectue dansle programme principal.

Ces composants de controle pourront donc etre associes adifferentes implementations de composants applicatifs et/oude presentation.

Les constructeurs des composants controle seront du memetype que le constructeur de CTour :

public CTour (String nom, int nbAnneauxMax) {abstraction = ConcreteFactory.

getAFactory ().

Figure 8. Modelisation UML du package interfacecontrole

newTour (nom, nbAnneauxMax) ;presentation = ConcreteFactory.

getPFactory ().newPTour (nbAnneauxMax, this) ;

}

On peut voir ici la facon dont les facettes abstraction etpresentation sont creees, grace a l’usage des fabriques decomposants adequates.

Les autres methodes des composants controle seront le plussouvent semblables a cette methode de la classe CTour :

public void empiler (IAnneau aa) {abstraction.empiler (aa) ;presentation.empiler (

((ICAnneau)aa).getPresentation ()) ;

}

On voit ici dans le cas de cette methode empiler que letraitement effectif est delegue au composant applicatif, etqu’ensuite on maintient la coherence entre partie applica-tive et partie presentation en empilant le composant depresentation de l’anneau sur le composant de presentationde la tour.

Ceci peut paraıtre etre une entorse au modele PAC carce dernier stipule que les composants de presentation nedoivent pas communiquer, mais cet ajout est indispensable,et ici l’initiative de l’ajout est laissee au composant controle,ce qui est conforme a la logique du modele PAC.

Notons au passage que pour pouvoir faire cela, il est neces-saire d’operer un transtypage de l’anneau a empiler en uncomposant interface de controle d’anneau ICAnneau afin depouvoir recuperer sa presentation associee.

Enfin, notons que le fait de faire glisser en douceur lesanneaux d’une position a une autre (plutot que de dis-paraıtre soudainement d’un endroit pour reapparaıtre toutaussi soudainement ailleurs) est laisse a la responsabilite descomposants de presentation : les composants de controle seconcentrent seulement sur l’essentiel, l’ordonnancement desactions.

Les diagrammes de classes de ces composants controles sontpresentes figures 9, 10 et 11.

Figure 9. Modelisation UML du controle d’anneau

Par ailleurs, il serait possible de faire des controles comple-mentaires au niveau des methodes des composants controle,pour prevoir une utilisation plus generale des ces com-posants. Dans le cas de la methode empiler de la classeCTour, il faudrait soit verifier qu’un anneau est bien empil-able avant de l’empiler effectivement (c’est-a-dire tester uneprecondition), soit verifier que l’anneau a bien ete empileavant de repercuter l’empilement au niveau de du composantpresentation (c’est-a-dire tester une postcondition), soit en-core faire les deux verifications.

Figure 10. Modelisation UML du controle de tour

A condition qu’elle existe dans le composant abstraction as-socie, l’utilisation d’une precondition se ferait de la faconsuivante :

public void empiler (IAnneau aa) {if (abstraction.isEmpilable (aa)) {

abstraction.empiler (aa) ;presentation.empiler (

((ICAnneau)aa).getPresentation ()) ;

}}

Si une telle precondition n’existe pas, ce peut etre aucontrole de la definir, jouant ainsi son role de regulation del’acces a son composant abstraction associe.

L’autre solution a base de postcondition, toujours a conditionqu’une telle postcondition existe dans le composant abstrac-tion associe, aurait la forme suivante :

public void empiler (IAnneau aa) {abstraction.empiler (aa) ;if (abstraction.vientDEtreEmpile (aa)) {

presentation.empiler (((ICAnneau)aa).

getPresentation ()) ;}

}

Dans ce dernier cas, il est fort probable que ce type depostcondition n’existe pas, c’est alors encore au controle dedefinir cette notion, en verifiant que l’element que l’on es-saie d’empiler se trouve effectivement au sommet de la tourapres avoir delegue l’empilement au composant abstractionassocie. Cela peut se faire ici de cette facon :

public void empiler (IAnneau aa) {abstraction.empiler (aa) ;if (abstraction.getSommet () == aa) {

Figure 11. Modelisation UML du controle de resolution

presentation.empiler (((ICAnneau)aa).

getPresentation ()) ;}

}

Utilisation des composants controlesLe programme principal devient donc responsable du choixdes differentes fabriques de composants qu’il doit mettre ala disposition des composants qui en auront besoin : lescomposants de controle et la classe Hanoi, puisqu’elle de-vra creer des tours et des anneaux :

• dans le cas de la classe Hanoi, c’est pour obtenir une fab-rique qui va creer des composants de controle a la placedes composants applicatifs initiaux : des ITours et desIAnneaux qui seront maintenant en pratique des instancesde CTour et CAnneau,

• dans le cas des composants de controle c’est soit pourcreer les bonnes instances de composants applicatifs etde presentation qui leur seront associes, soit pour creerd’autres composants de controle.

Pour une simple demonstration, on devra donc determinerles fabriques de composants a utiliser : une fabrique de com-posants applicatifs (a l’usage des composants de controlepour creer leurs abstractions associes), une fabrique de com-posants de controle (a l’usage de la classe Hanoi car c’estelle qui cree tous les composants de controle, mais ceserait aussi a la disposition des composants de controle quisouhaiteraient creer d’autres composants controles) et unefabrique de composants de presentation (a l’usage des com-posants de controle pour creer leurs presentations associees).

La classe permettant d’acceder ensuite a ces differentes fab-riques est ici la classe ConcreteFactory, elle propose quatremethodes pour obtenir des fabriques de composants :

• getAFactory,

• getCFactory,

• getPFactory,

• getFactory.

Figure 12. Modelisation UML de la classe ConcreteFac-tory

Les trois premieres methodes sont destinees a etre utiliseespar des composants de controle, elle vont permettre d’obtenirrespectivement des instances de composants applicatifs, decomposants de controle, et de composants de presentation.La quatrieme, c’est-a-dire la methode getFactory, est quanta elle destinee aux composants applicatifs initiaux : elle re-tourne en priorite la CFactory ou par defaut la AFactory siaucune CFactory n’a ete designee. C’est donc cette methodequi doit etre utilisee par les composants applicatifs (quidoivent pouvoir etre utilises en dehors d’un implementationPAC) et par la classe Hanoi pour creer les differents com-posants necessaires a la resolution du probleme. Ceci a pourresultat de substituer aux composants applicatifs initiaux descomposants de controle quand c’est possible, afin d’obtenirdes applications graphiques interactives a la place des appli-cations non graphiques initiales.

Voici les choix a realiser pour obtenir une illustration gra-phique de la resolution des tours de Hanoı :

import interfaceAbstraction.IHanoi;

public class MainHanoiPAC {

public static void main (String args []) {int n = 5 ;if (args.length > 0) {

n = Integer.parseInt (args [0]) ;}concreteFactory.ConcreteFactory.

setAFactory (abstraction.AFactory.getInstance ()) ;

concreteFactory.ConcreteFactory.setCFactory (controle.CFactory.

getInstance ()) ;concreteFactory.ConcreteFactory.

setPFactory (presentation.PFactory.getInstance ()) ;

IHanoi h = concreteFactory.ConcreteFactory.getFactory ().

newHanoi (n) ;h.solve () ;

}

}

Conclusions a propos de cette premiere methodeAvec cette premiere methode, il y a beaucoup de classes acreer pour realiser une application visualisable a partir d’unnoyau applicatif non graphique. Par contre, cette methodeinduit des dependances minimales entre les differents com-posants, en particulier grace au melange des patrons de con-ception Proxy (avec Delegation) et Template Method (ou In-terface), ainsi bien sur qu’a l’utilisation du patron AbstractFactory. Le patron de conception Singleton, qui garantitl’usage d’une seule fabrique par type de composants, fa-cilite par ailleurs l’acces aux differentes fabriques a partirdes composants qui en ont besoin.

SECONDE SOLUTION : PAC ET PROXY CONTROLE PAR

HERITAGE

Le principeL’idee est ici de voir s’il est possible d’etre plus effi-cace au niveau de l’implementation du patron de concep-tion Proxy. Au lieu de deleguer certains traitements a uncomposant applicatif, chaque composant controle qui sertde proxy a un composant applicatif va directement heriterde ce composant. Nous utilisons donc tout simplement lemecanisme d’heritage au lieu du patron de conception Dele-gation, comme on peut le voir figure 13.

Figure 13. Patron de conception Proxy avec heritage

Comme les composants de controle vont maintenant heriterdes classes de l’abstraction, on va avoir une plus grandedependance du controle vis a vis de l’application.

Par contre, il y aura moins de code a ecrire car toutes lesmethodes des composants de controle qui n’etaient que desimples relais vers des methodes des composants applicatifs

pourront etre reutilisees telles-quelles, sans etre redefinies auniveau des composants de controle.

L’implementation en javaOn utilisera les trois memes packages d’interfaces de com-posants, ainsi que le package applicatif et le package depresentation, seul le package d’implementation des com-posants de controle va changer.

Le nouveau package de controleIl va maintenant dependre directement de l’implementationchoisie pour les composants abstraction car les composantsde controle lies a des objets applicatifs a visualiser vontderiver de ces objets, comme illustre figure 14.

Figure 14. Modelisation UML du package controle-Heritage

Chaque composant de controle va donc devoir importer saclasse ancetre (par exemple ATour pour le controle CTour),et son constructeur devra invoquer le constructeur de son

ancetre puis creer un composant de presentation. Le con-structeur de CTour est tout a fait representatif d’un tel con-structeur :

public CTour (String nom, int nbAnneauxMax) {super (nom, nbAnneauxMax) ;presentation = ConcreteFactory.

getPFactory ().newPTour (nbAnneauxMax, this) ;

}

L’usage d’une fabrique de composants adequate ne permetmaintenant plus que d’etre independant vis a vis des classesd’implementation de la presentation.

Les autres methodes des composants controle feront typ-iquement l’appel a la methode correspondante du composantancetre, puis maintiendront la coherence avec le composantde presentation. Ces methodes seront le plus souvent sem-blables a cette methode de la classe CTour :

public void empiler (IAnneau aa) {super.empiler (aa) ;presentation.empiler (

((ICAnneau)aa).getPresentation ()) ;}

Comme c’etait le cas avec la premiere methode d’imple-mentation presentee, il serait ici encore possible de fairedes verifications complementaires au niveau des methodesdes composants controle, pour prevoir une utilisation plusgenerale de ces composants.

Conclusions a propos de cette seconde methodeIl y a toujours autant de classes a creer, mais elles sont unpeu plus simples que dans le cas precedent, car pour beau-coup de methodes des composants controle on peut reutilisertelles-quelles les methodes du composant applicatif dont onherite. Par contre on induit des dependances fortes entre lescomposants controle et les composants applicatifs dont ilsderivent : chaque package de controle ainsi defini depend di-rectement de l’implementation de l’abstraction a controler :il faudra donc un nouveau package de controle pour chaquenouvelle implementation du noyau applicatif.

Cette methode peut egalement etre utilisee en cas d’absencede definition d’interfaces pour les composants applicatifs etde controle : le fait que les composants de controle heritentdes composants applicatifs permet de substituer ces com-posants applicatifs par leurs composants controles heritiers.Ce peut donc etre une solution permettant un deploiement dumodele PAC moins perenne qu’avec la premiere methode,mais sensiblement plus rapide.

TROISIEME SOLUTION : PAC-AMODEUS, PROXY ANF

PAR HERITAGE ET PROXY CONTROLE PAR DELEGATIONLe principeEnfin, l’idee est ici de voir ce qu’une implementation dif-ferente, en faisant usage du patron de conception Ob-server (GoF293) pour l’adaptation des composants applicat-ifs sous forme de composants, peut apporter au niveau del’independance entre noyau fonctionnel et IHM.

Lors d’un changement d’etat susceptible d’etre visualisegraphiquement, un composant applicatif devrait prevenir au-tomatiquement les composants de controle qui peuvent etreinteresses par ce changement d’etat. Il faut donc mettre enplace un mecanisme de souscription d’abonnement a deschangements et de diffusion des changements aupres desabonnes, en suivant le patron de conception Observer illustrefigure 15.

Figure 15. Patron de conception Observer

Comme les composants applicatifs ne savent a priori pasfaire ceci, conformement au modele PAC-Amodeus cela vaetre a des composants d’un Adaptateur de Noyau Fonction-nel (ANF) d’adapter les composants applicatifs pour leurfaire remplir ces nouvelles fonctionnalites : permettre desouscrire un abonnement a des changements et diffuser ef-fectivement ces changements aux abonnes. Ces composantsANF vont donc en quelque sorte etre des proxys (au sens denotre seconde methode) des composants applicatifs.

Les composants de controle devront alors etre capables desouscrire un abonnement aupres du composant de l’ANF quileur sera associe, et implementer les methodes leur permet-tant de recevoir les changements d’etats auxquels ils aurontsouscrit. Ici encore ces composants de controle seront desproxys (au sens de notre premiere methode) des composantsANF.

L’implementation en javaOn utilisera ici encore les trois memes packages d’interfacesde composants, ainsi que le package applicatif et le pack-age de presentation. Le package d’implementation des com-posants de controle va etre different, et on va creer un nou-veau package ANF pour adapter les composants applicatifsqui en ont besoin. On creera egalement un nouveau packageinterfaceANF pour y decrire les nouvelles fonctionnalitesqui devront etre proposees par les composants du packageANF.

Les packages d’adaptation du noyau fonctionnelUne seule classe du noyau applicatif devra etre adaptee pourpropager ses changements d’etats : la classe tour. Cela vase faire a l’aide de l’interface IANFTour (illustree figure 16)et de la classe ANFTour (illustree figure 17). En effet, afin

de pouvoir diffuser les arrivees et les departs d’anneaux versd’eventuels observateurs ayant souscrit un abonnement a ceschangements, il va falloir effectuer deux types d’ajouts :

• la possibilite de souscrire a la diffusion de ces evenements,

• la diffusion effective des evenements a chaque change-ment d’etat suite a l’empilement ou au depilement d’unanneau.

Figure 16. Modelisation UML du package interfaceANF

Figure 17. Modelisation UML du package ANF

Il faut bien entendu egalement fournir ici une fabrique decomposants, qui creera une instance d’ANFTour lorsqu’onlui demandera de creer une tour, et qui s’appuiera sur lepackage applicatif initial pour creer des instances de AAn-neau et de AHanoi (classes inchangees du noyau fonction-nel) lorsqu’on lui demandera de creer des anneaux ou biendes objets de resolution du probleme des tours de Hanoı.

Le package de controleComme pour le package ANF associe, on n’a ici a redefinirqu’une seule classe : la classe de controle de tour, CTour,dont le modele UML est presente figure 18. Bien entenduon doit aussi fournir une fabrique de composants qui vas’appuyer sur les classes du package de controle initial pourcreer les objets qui n’ont pas besoin d’etre en relation avecles objets de l’adaptateur de noyau fonctionnel : les in-stances d’anneau et d’objet de resolution.

Le constructeur de la nouvelle classe CTour va etre un peuplus complexe que les precedents car il va devoir s’abonneraux nouveaux services decrits par l’interface IANFTour :

Figure 18. Modelisation UML du package controleANF

public CTour (String nom, int nbAnneauxMax) {abstraction = (IANFTour)ConcreteFactory.

getAFactory ().newTour (nom, nbAnneauxMax) ;

presentation = ConcreteFactory.getPFactory ().

newPTour (nbAnneauxMax, this) ;// abonnement aux evenements propages// par l’abstraction associeeabstraction.addDepilerListener (this) ;abstraction.addEmpilerListener (this) ;

}

Cela se fait a l’aide des nouvelles methodes decrites dansl’interface IANFTour : addDepilerListener et addEmpil-erListener. Cela n’est possible que parce que cette classeCTour implemente egalement une nouvelle interface (icil’interface PropertyChangeListener) qui lui permettra d’etreprevenue lors des changements d’etats de la tour associee viaun appel a la methode propertyChange.

L’avantage de ce principe est que les methodes de type em-piler et depiler sont maintenant de simples relais vers le com-posant applicatif associe (en pratique, une instance de ANF-Tour) :

public void empiler (IAnneau aa) {abstraction.empiler (aa) ;

}

public void depiler () {abstraction.depiler () ;

}

Enfin, il faut implementer la methode propertyChange, ap-pelee lors de la diffusion des changements d’etats de l’abs-traction. Cette diffusion est realisee sur le modele des

java beans, en s’appuyant donc sur les interfaces Property-ChangeEvent et PropertyChangeListener :

public void propertyChange (PropertyChangeEvent evt) {if (evt.getPropertyName ().

equals ("empiler")) {ICAnneau a = (ICAnneau)evt.

getNewValue () ;presentation.empiler (

a.getPresentation ()) ;} else if (evt.getPropertyName ().

equals ("depiler")) {ICAnneau a = (ICAnneau)evt.

getNewValue () ;presentation.depiler (

a.getPresentation ()) ;}

}

L’implementation de la diffusion des changements d’etatspeut se faire de differents facons, en se basant comme ici surdes services existants (les PropertyChangeSupport des javabeans) ou bien en creant soi-meme de nouveaux protocolesde communication entre objets applicatifs qui diffusent leurschangements et objets de controle qui recoivent ces change-ments.

Conclusions a propos de cette troisieme methodeBien que l’implementation de cette methode soit assezdifferente des deux precedentes pour la seule classe con-cernee, CTour, cette methode semble quand meme equiva-lente a la premiere en termes de fonctionnalites : on gardela meme independance du controle vis a vis du noyau appli-catif.

Par contre, cette methode alourdit quelque peu le codage acause des protocoles a mettre en place entre composants ap-plicatifs et composants de controle.

Les ajouts de code restent ici limites car d’une part une seuleclasse est concernee et d’autre part on peut se reposer surune implementation du patron Observer qui est celle des javabeans.

Enfin, par rapport aux deux premieres methodes presentees,cette methode ajoute quelques traitements supplementairesa chaque modification visuelle a apporter a un composantinteractif. En effet, de part son aspect tres generique, quipermet de mettre a jour de la meme facon n’importe quelleevolution grahique, il y a des operations ou verificationssupplementaires a realiser a chaque fois. Ici ce sont des testsa effectuer afin de savoir quelle action realiser ; et dans lecas “canonique” de ce patron de conception, ce sont des in-vocations de methodes supplementaires de la part des com-posants observateurs vers les composants observes. Cecin’est pas penalisant dans le cas classique d’une IHM pi-lotee principalement par l’utilisateur, par contre cela peutamener des pertes d’efficacite dans le cas d’applications pi-lotees plutot par un grand nombre d’elements qui evoluent etqu’il faut visualiser en temps reel, comme c’est le cas dansdes visualisations d’applications de simulation ou encore desapplications de realite virtuelle.

PASSAGE A LA MANIPULATION DIRECTELe principePour les trois cas vus precedemment, on peut passer d’unmode demonstration a un mode interaction par manipulationdirecte de la meme facon, en creant de nouvelles classes decontrole qui derivent des classes qui ont ete presentees, et enen faisant de meme pour les classes de presentation. Nouspresenterons donc ici comment realiser cette extension dansle cas ou l’on utilise la premiere methode presentee : utili-sation du modele PAC avec composants de controle qui sontdes proxys des composants applicatifs et qui utilisent effec-tivement une instance de composant applicatif selon le pa-tron Delegation.

Conformement aux recommandations du modele PAC, nousallons essayer de rendre les composants de controle les plusindependants possibles des couches de presentation utiliseespour obtenir la manipulation directe (ici les packages dndet datatransfer de java). Ceci va nous conduire a definir unprotocole precis entre les composants de controle et les com-posants de presentation pour gerer finement cette manipula-tion directe et confiner dans les composants de presentationtous les details relatifs au mecanisme de drag’n drop proposepar java.

Nouveaux besoins au niveau des composants de controleOn va devoir decrire les nouveaux services necessaires a unemanipulation directe des anneaux et des tours dans le cadrede la resolution manuelle du probleme des tours de Hanoı.En pratique, rien de nouveau pour l’objet de resolution duprobleme, mais de nouveaux besoins au niveau :

• des anneaux : il faut pouvoir les rendre selectionnables oupas, et pouvoir les rendre selectionnes ou pas selon qu’unutilisateur les manipule ou pas,

• des tours : il faut pouvoir savoir si un anneau est empilableou pas sur une tour, et pouvoir savoir si un anneau estdepilable ou pas d’une tour.

Ceci est necessaire pour des raisons fonctionnelles maisaussi afin de pouvoir offrir une retroaction maximale (se-mantique) a un utilisateur lors des deplacements des anneauxd’une tour a une autre.

Il faudra aussi etre capable de prendre en compte le debutet la fin d’une manipulation d’anneau de type Drag’n Dropd’une tour sur une autre.

Nouveaux besoins au niveau des composants de presentationOn va retrouver ici des besoins de services similaires a ceuxdes composants de controle :

• pour les anneaux : il faut pouvoir visualiser qu’un an-neau est selectionnable (ou non), et pouvoir le visualiserselectionne ou non selon qu’un utilisateur le manipule oupas,

• pour les tours : il faut pouvoir visualiser qu’un anneau estempilable ou pas sur une tour, et pouvoir visualiser qu’unanneau est depilable ou pas d’une tour.

On va avoir egalement besoin de services qui permettrontd’obtenir des composants sur lesquels il sera possible d’agirdirectement, et dont on pourra changer l’aspect en fonctionde l’etat du composant applicatif associe. Dans le cas des an-neaux, il s’agit simplement de pouvoir obtenir le composantde controle associe, pour lui indiquer qu’il a un debut dedrag’n drop a traiter.

Dans le cas des tours, il s’agit de pouvoir visualiser :

• qu’un anneau sort de la zone correspondant a la tour as-sociee,

• que le debut de drag’n drop reconnu sur la tour associeeest valide ou non,

• que le drag’n drop qui s’est termine sur la tour associeeest valide ou non.

L’implementation en java

Nouvelles interfaces de controleComme indique precedemment et illustre figure 19, nous de-vrons proposer deux nouvelles interfaces dans le packageinterfaceControle, conformement aux besoins exprimes auniveau des composants de controle : ICAnneauInter et IC-TourInter.

Figure 19. Modelisation UML du package interfaceCon-trole incluant les classes d’interaction

L’interface ICAnneauInter decrit des services qui permet-tent :

• de rendre selectionnable ou non un anneau selon quel’anneau se trouve ou non au sommet d’une tour,

• de rendre selectionne ou non un anneau selon qu’un util-isateur le manipule ou pas.

L’interface ICTourInter decrit des services qui permettent :

• de dire si l’empilement ou le depilement d’un anneau estpossible ou non,

• de traiter l’arrivee ou le depart d’un composant anneausuite a une manipulation directe :

– debutDnDDrag : quand on a reconnu, cote depart(forcement !), le debut d’une manipulation d’anneau,

– finDnDDrag : quand on a reconnu, cote depart, la find’une manipulation d’anneau,

– entreeDnDDrop : quand on a reconnu, cote arrivee,qu’un anneau vient d’entrer dans la tour,

– sortieDnDDrop : quand on a reconnu, cote arrivee,qu’un anneau vient de sortir de la tour,

– finDnDDrop : quand on a reconnu, cote arrivee, lafin d’une manipulation d’anneau.

En effet, une tour est a la fois un receptacle de depart etun receptacle d’arrivee pour une manipulation directe.

Nouvelles classes de controleOn n’aura donc que deux nouvelles classes a implementerdans le package controle : CAnneauInter et CTourInter,comme illustre figure 20 et 21, en plus de la fabrique de com-posants permettant de creer des composants de controle des-tines a des interactions en manipulation directe (qui creerapar ailleurs des instance de CHanoi).

Figure 20. Modelisation UML de la classe de controled’anneau interactif

Conformement a l’interface ICAnneauInter qu’elle imple-mente, la classe CAnneauInter permet de rendre selection-nable ou non un anneau et de rendre selectionne ou non unanneau, et ce en visualisant a chaque fois de facon adequatela presentation d’anneau associee, et en lui demandant d’etrecapable le cas echeant de traiter des demandes de manipula-tion directe en provenance de l’utilisateur.

De meme, la classe CTourInter va permettre de dire sil’empilement ou le depilement d’un anneau est possible, ellepourra aussi traiter l’arrivee ou le depart d’un composant an-neau suite a une manipulation directe, le tout en appelant lesmethodes adequates declarees dans l’interface ICAnneauIn-ter selon qu’un anneau est empile ou depile, et entre ou sortde la tour lors d’une manipulation directe.

Figure 21. Modelisation UML de la classe de controle detour interactive

Nouvelles interfaces de presentationLe package des interfaces de presentation regroupe main-tenant deux interfaces supplementaires, IPAnneauInter etIPTourInter, derivees des interfaces IPAnneau et IPTour,comme illustre figure 22. Ces nouvelles interfaces decriventdes services qui permettront d’obtenir des composants surlesquels il sera possible d’agir directement, et dont on pourrachanger l’aspect en fonction de l’etat du composant appli-catif associe.

L’interface IPAnneauInter decrit des services qui permet-tent :

• de visualiser selectionnable ou non un anneau, et de lerendre designable ou pas par l’utilisateur,

• de visualiser selectionne ou non un anneau,

• d’obtenir le composant de controle associe.

L’interface IPTourInter decrit des services qui permettent :

• de visualiser si l’empilement ou le depilement d’un an-neau est possible ou non,

• de visualiser de facon adequate l’arrivee ou le depart d’uncomposant anneau suite a une manipulation directe.

Figure 22. Modelisation UML du package interfacePre-sentation incluant les classes d’interaction

Nouvelles classes de presentationOn y trouve donc les classes PAnneauInter et PTourInter quiimplementent respectivement les interfaces IPAnneauInter etIPTourInter, et qui derivent respectivement des classes PAn-neau et PTour. Ces deux classes sont associees a la classePFactoryInter (qui ici encore implemente l’interface PFac-tory), qui permet de meme d’en creer des instances. Cettefabrique de composants se contente par ailleurs de creerdes instances de PHanoi car il n’y a pas de nouvelle classePHanoiInter.

La classe PAnneauInter, illustree figure 23, herite des ser-vices fournis par la classe PAnneau et implemente en plus lesservices decrits par l’interface IPAnneauInter qui permettentde visualiser de facons differentes un anneau selon son etatselectionnable ou non, selectionne ou non, en changeant lecurseur de la souris et en changeant la couleur de l’anneau.Elle implemente egalement d’autres methodes decrites parl’interface Transferable de facon a pouvoir etre manipuleepar drag’n drop, qui ont essentiellement pour but d’obtenirla donnee a transferer lors de la manipulation directe : ici cesera l’instance de presentation elle-meme.

De meme, La classe PTourInter, illustree figure 24, heritedes services fournis par la classe PTour et implemente enplus les services decrits par l’interface IPTourInter. Elle vatout d’abord devoir redefinir les services d’empilement et dedepilement : lors d’un empilement ou d’un depilement, unanneau ne devra plus glisser jusqu’au sommet de la tour,mais devra aller directement a son nouvel emplacement.Cette classe va egalement devoir creer des classes (et lesinstancier) permettant de gerer le drag’n drop a l’aide deSwing, c’est-a-dire :

• un DragGestureListener : pour reconnaıtre un debut dedrag’n drop,

Figure 23. Modelisation UML de la classe depresentation interactive d’anneau

• un DragSourceListener : pour traiter les evenementssouris (appui et relachement) lies au depart d’un anneau,

• un DragSourceMotionListener : pour traiter les evenementsde deplacement souris lies au mouvement d’un anneau audepart de la tour : l’anneau doit suivre le curseur de lasouris,

• un DropTargetListener : pour traiter les evenements lies al’arrivee d’un anneau.

Les methodes de ces classes auront la charge d’appeleraux endroits adequats les methodes suivantes du composantcontrole associe (apres avoir transtype ce composant controleen ICTourInter) : debutDnDDrag, finDnDDrag, entreeDnD-Drop, sortieDnDDrop et finDnDDrop. Il est a noter qu’achaque fois le composant anneau qu’on est en train de ma-nipuler est une instance de Transferable ou de JComponent,qu’il faut donc d’abord transtyper en IPAnneauInter, a quion peut ensuite demander son composant controle (declareICAnneau donc a transtyper egalement en ICAnneauInter) atransmettre au composant ICTour associe, lui aussi transtypeen ICTourInter. On aura donc du code ressemblant a ceci :

public void dragGestureRecognized (DragGestureEvent event) {selected = null ;try {

selected =(PAnneauInter)getComponentAt (

event.getDragOrigin ()) ;} catch (Exception e) {}if (selected != null) {

...

Figure 24. Modelisation UML de la classe depresentation interactive de tour

((ICTourInter)controle).debutDnDDrag (

(ICAnneauInter)selected.getControle()) ;

...}

}

En retour, ces differentes methodes du composant controleassocie invoqueront une des methodes de PTourInter decritesdans l’interface IPTourInter :

• visualiserEmpilable : pour visualiser si un anneau est em-pilable ou non sur la tour,

• visualiserSortieDnD : pour visualiser qu’un anneau sortde la zone correspondant a la tour,

• debutDnDValide, debutDnDInvalide : pour visualiser quele debut de DnD reconnu sur la tour est valide ou pas,

• finDnDValide, finDnDInvalide : pour visualiser que leDnD qui s’est termine sur la tour associee est valide oupas.

Utilisation des packages interactifsOn a ensuite tres peu de changements a effectuer pourobtenir une application interactive permettant a un utilisa-teur d’essayer de resoudre le probleme des tours de Hanoıpar manipulation directe des anneaux en les depilant d’unetour et en les empilant sur une autre : il suffit ici encore dedeterminer les bonnes fabriques de composants a utiliser..

public static void main (String a []) {int n = 3 ;if (a.length > 0) {

n = Integer.parseInt (a [0]) ;}concreteFactory.ConcreteFactory.

setAFactory (abstraction.AFactory.

getInstance ()) ;concreteFactory.ConcreteFactory.

setCFactory (controle.CFactoryInter.

getInstance ()) ;concreteFactory.ConcreteFactory.

setPFactory (presentation.PFactoryInter.

getInstance ()) ;IHanoi h = concreteFactory.

ConcreteFactory.getCFactory ().newHanoi (n) ;

//h.solve () ;}

Ici l’appel a la methode solve disparaıt pour laisser le choixde resolution a l’utilisateur.

Cette procedure est presque identique a la precedente, seulesles fabriques de composants controles et presentations sontdifferentes car elles permettent de creer des composants des-tines a supporter une manipulation directe de l’utilisateur.

Conclusion sur le passage au mode interactifNous avons choisi ici de creer de nouveaux composantsde controle et de presentation par heritage des composantsutilises pour obtenir une visualisation a partir d’un pack-age applicatif. Cette methode est compatible avec les troisfacons d’obtenir une visualisation a partir d’un package ap-plicatif que nous avons presentees dans ce document.

Le but etait ici de pouvoir gerer la manipulation directeau niveau des composants de controle en restant le plusindependant possible de l’implementation java du drag’ndrop. Pour cela il a fallu definir de nouvelles interfaces pourles composants de controle interactifs et pour les nouveauxcomposants de presentation interactifs, afin de pouvoir met-tre en place un dialogue entre composants de controle etleurs composants de presentation associes. Ceci a permisde restreindre la connaissance des classes java de gestiondu drag’n drop aux seuls composants de presentation. Lesnouveaux composants de controle interactifs ainsi definis de-vraient pouvoir etre reutilises en cas de changement d’imp-lementation des couches “basses” de presentation.

CONCLUSIONLes trois methodes presentees pour deployer une applicationinteractive selon le modele PAC ou le modele PAC-Amodeussont viables. Elles offrent differents degres d’independancedu controle de l’IHM par rapport a un noyau applicatif arendre interactif. Dans un premier temps ces methodesont ete comparees sur un exemple d’application a illustrergraphiquement.

La premiere methode offre la meilleure independance ducontrole, mais demande de creer beaucoup de classes etd’interfaces. Cela conduit a des dependances minimalesentre les differents composants, en particulier grace aumelange des patrons de conception Proxy (et Delegation)et Template Method (ou Interface), ainsi bien sur qu’al’utilisation du patron Abstract Factory.

La seconde methode peut permettre de limiter le nombrede classes a creer, qui de plus sont un peu plus simplesque dans le cas precedent, car pour beaucoup de methodesdes composants controle on peut reutiliser telles-quelles lesmethodes du composant applicatif dont on herite. Par con-tre on induit des dependances fortes entre les composantscontrole et les composants applicatifs dont ils derivent. Cettesolution conduit donc a un deploiement du modele PACmoins perenne qu’avec la premiere methode, mais sensible-ment plus rapide.

L’implementation proposee dans la troisieme methode estassez differente des deux premieres, mais elle semble fonc-tionnellement equivalente a la premiere methode, meme sielle alourdit quelque peu le codage a cause des protocoles amettre en place entre composants applicatifs et composantsde controle. Notons enfin que cette troisieme methode risqued’etre moins efficace pour visualiser l’evolution d’un grandnombre d’objets interactifs autonomes.

Pour le passage de l’illustration graphique a l’interactionpar manipulation directe des presentations associees auxcomposants applicatifs, ces trois methodes sont en faitequivalentes, et on n’a donc presente ce passage que dans lecadre de la premiere methode. Dans cette partie nous avonsessaye d’assurer la meilleure independance possible entre lescomposants de controle et les composants de presentation,pour rendre la partie de controle independante de la couchegraphique utilisee.

Nous esperons que ce document permettra aux developpeursd’IHM de mettre en oeuvre plus facilement un modeled’architecture de type PAC ou PAC-Amodeus pour rendreinteractif un noyau applicatif a l’aide d’un langage objetcomme Java ou C++, en s’appuyant sur les patrons de con-ception adequats.

REFERENCES1. Coutaz J. Interfaces homme-ordinateur, conception et

realisation, Dunod informatique, 1990.

2. Degrigny F., Duval T. Utilisation du modelePAC-Amodeus pour une reutilisation optimale de codedans le developpement de plusieurs versions d’un

logiciel commercial In Actes de la 16eme ConferenceFrancophone sur l’Interaction Homme-Machine(IHM’04), Namur, Belgique, septembre 2004, 149–156.

3. Duval T, Nigay L. Implementation d’une application desimulation selon le modele PAC-Amodeus In Actes de la11eme Conference Francophone sur l’InteractionHomme-Machine (IHM’99), Montpellier, France,novembre 1999, 86–93.

4. Duval T., Pennaneac’h F. Using the PAC-AmodeusModel and Design Patterns to Make Interactive anExisting Object-Oriented Kernel In Proceedings of theTOOLS EUROPE 2000 Conference, Mont Saint-Michel,France, IEEE, juin 2000, 407–418.

5. Gamma E., Helm R., Johnson R., Vlissides J. DesignPatterns : Elements of reusable Object-OrientedSoftware, Addison-Wesley, 1995.

6. Grand M. Patterns in Java Volume 1 : A Catalog ofReusable Design Patterns Illustrated with UML, WileyPublishing Inc., 2002.

7. Jezequel J.M., Train M., Mingins, C. Design Patternsand Contracts, Addison-Wesley, octobre 1999.

8. Nigay L. Conception et modelisation logicielle dessystemes interactifs : application aux interfacesmultimodales

These de Doctorat de l’Universite de Grenoble 1, IMAG,1994.

9. The UIMS Workshop Tool Developers. ARCH : AMetamodel for the Runtime Architecture of anInteractive System In SIGCHI Bulletin, 24, 1, pp. 32-37,1992.