AMF : un modèle d'architecture multi-agents multi …pascal.joyeux.free.fr/PROBATOIRE/GenerationAutomatique...AMF : des Agents Multi-Facettes 5 5 C'est ce choix d'homogénéité qui

RECHERCHE

AMF : un modèle d'architecturemulti-agents multi-facettes

Franck Tarpin-Bernard* — Bertrand David**

Laboratoire GRACIMP, Groupe de recherche ICTT* INSA de Lyon20 avenue Albert Einstein, 69621 Villeurbanne [email protected]** Ecole Centrale de Lyon36 avenue Guy de Collongue, 69131 Ecully [email protected]

RÉSUMÉ. Dans le génie logiciel moderne, les modèles d'architecture jouent un rôle essentielcar ils influent fortement sur l'efficacité des méthodes et outils de développement associés.Dans ce cadre, le modèle multi-agents multi-facettes AMF présente de nombreux atouts.L'expressivité de son formalisme graphique en terme de modélisation du contrôle desinteractions et d'explicitation des relations entre agents en fait un support intéressant pour laspécification, la conception et la mise en œuvre, ainsi que pour la compréhension dessystèmes complexes. En explicitant les mécanismes internes de fonctionnement d'AMF, nousmontrons également qu'il peut être directement utilisé pour la mise en œuvre des logiciels.Enfin, AMF est un support efficace de définition de motifs de conception réutilisables.

ABSTRACT. In modern software engineering, architectural models are essential because theystrongly affect the efficiency of their associated methods and development tools. In thiscontext, AMF, a multiagent multifacet model, has many advantages. Thanks to theexpressiveness of its graphical formalism, in terms of interaction control modeling andexplicitation of relations between agents, AMF is a very interesting support for specification,design and understanding of complex systems. While we describe in detail the internalmechanisms of AMF, we also show that it can be used directly to implement software. Finally,we present AMF as a good support for design patterns definition.

MOTS-CLÉS : Modèle d'architecture, multi-agent, AMF, motifs de conception, IHM.

KEY WORDS : Architectural model, multiagent, AMF, design pattern, HCI.

Technique et science informatiques. Volume – n°5 /1999 , pages

2 Technique et science informatiques. Volume – n°5 /1999

2

1. Introduction

Le modèle d'architecture logicielle constitue un des éléments indispensables dutriplet Méthode - Modèle - Outils sur lequel s'appuie le génie logiciel moderne. Ilsystématise à la fois l'élaboration et l'utilisation des logiciels et joue un rôleprimordial dans leur qualité et leur efficacité. Garlan & Perry [GAR 95] soulignentle fait que l'utilisation de modèles d'architecture peut avoir des effets bénéfiques surau moins cinq aspects du développement des logiciels :

1. La compréhension est simplifiée en présentant la structure de grandssystèmes à un niveau d'abstraction adapté. Les contraintes sur la conception ainsique les raisons des choix de conception peuvent être mieux explicitées.

2. La réutilisation peut être favorisée à de nombreux points de vue. Bien sûr, laréutilisation des composants est largement encouragée par la définitiond'architectures, mais il est également possible de réutiliser des structures pluscomplexes définies sous forme de motifs de conception ou design patterns.

3. L'évolution et la maintenance profitent largement de la définitiond'architectures logicielles. En permettant de comprendre les ramifications et lesconnexions de chaque composant, il est beaucoup plus facile de déterminer a prioriles coûts potentiels devant être associés à toute modification.

4. L'analyse des systèmes est grandement facilitée. Suivant les modèles utilisés,on peut envisager des formes de vérification de cohérence, de respect de styles, desatisfaction de critères de qualité voire d'adaptation à des domaines spécifiquesd'application.

5. La gestion des projets industriels doit s'appuyer sur cet élément essentielpour déterminer au plus tôt la viabilité des options choisies, les pré-requisindispensables et les perspectives d'évolution.

Nous adhérons à l'analyse de Garlan et Perry et nous considérons que, par lerapprochement du modèle de fonctionnement et du modèle d'utilisation, ledécoupage en entités autonomes peut servir de support d'explication et être utile nonseulement aux concepteurs mais également aux utilisateurs. En intégrant lesmécanismes et contraintes du système ils peuvent mieux se l'approprier. L'ensemblede ces constats nous conduit à considérer que le modèle d'architecture constitue lepivot des activités d'élaboration (spécification, conception et réalisation). Nous luidonnons le triple objectif suivant :

− servir de support lors de la spécification,− constituer l'ossature de la réalisation,− servir de guide d'utilisation.Après avoir rapidement décrit les principaux modèles d'architecture proposés

pour les logiciels interactifs, cet article présente en détail le modèle AMF. Cemodèle multi-agents vise à satisfaire le triple objectif précédent. Il repose sur quatrepropriétés principales : la structuration des agents en facettes, la réification desinteractions, le passage de la conception sous forme graphique à l'implémentationpar la génération automatique de code, et enfin le support dynamique desmodifications structurelles lors de l'exécution. Dans la dernière section, nousdécrivons comment AMF permet la définition de design patterns et constitue ainsiun outil prometteur pour la conception de logiciels interactifs complexes.

AMF : des Agents Multi-Facettes 3

3

2. Des modèles d'architecture caractéristiques

Les modèles d'architecture constituent un des centres d'intérêt des recherches eninterface homme-machine depuis une bonne quinzaine d'années. Les analysescomportementale et structurale en sont les deux principales approches. La premièrepropose des modèles en se basant sur le comportement tel qu'il est perçu etexpérimenté par l'utilisateur final. La seconde propose des modèles qui reflètent lavue du concepteur du logiciel. Ceci correspond respectivement aux deux types demodèles d'interaction que distinguent Hartson et Hix [HAR 89] : les modèles dedescription générale de l'interaction Homme-Machine et les modèles d'architectureproprement dits. Les premiers décrivent directement l'interaction en termes demanipulation de l'utilisateur, de messages du système et d'enchaînements entre lesséquences d'interaction. Les seconds sont proposés dans le but de décrire, dans uncontexte architectural, les relations de l'interface utilisateur avec le reste du systèmeinteractif. Ils décrivent la structure interne de l'interface utilisateur : identificationdes composants et de leur organisation (relations, protocole de communication).

Dans les deux cas, la modélisation des interactions constitue un élémentfondamental nécessaire à la compréhension de la nature de la communicationhomme-machine ainsi qu'au processus de développement d'interfaces. Elle décrit leprocessus général de l'interaction Homme-Machine, c'est-à-dire la structure deséchanges de l'utilisateur avec la machine. Elle identifie les éléments de dialogue telsque les entrées, les validations, les échos, les messages et leurs relations.

Les modèles d'architecture des applications interactives peuvent être classés endeux grandes catégories : les modèles à couches (modèles “centralisés” tels queSeeheim [GRE 85] ou Arch [KAZ 93]) et les modèles multi-agents (modèles“distribués” tels que MVC [GOL 84], GwUims [SIB 86], Tube [HIL 90] ou PAC[COU 87, 90]). Par ailleurs, des modèles mixtes tel que PAC-Amodeus [NIG 93]tentent de tirer partie des avantages respectifs de ces deux approches.

Tous ces modèles ont déjà donné lieu à de nombreuses publications et nous nouscontentons ici de rappeler les caractéristiques essentielles des modèles les plusreprésentatifs que sont Arch et PAC. Nous exposerons ensuite en détail le modèleAMF et ses avantages.

2.1. Les modèles en couches - exemple : Arch

Le modèle Arch s’appuie sur les composants conceptuels du modèle Seeheim(figure 1). On y retrouve les notions de noyau fonctionnel, de contrôleur de dialogueet de présentation. Les pieds de l’arche constituent les composants imposés par laréalité : le noyau fonctionnel réalise les concepts du domaine et le composantd’interaction, en contact direct avec l’utilisateur, est mis en œuvre au moyen desobjets d’interaction d’une boîte à outils. En clé de voûte, le contrôleur de dialoguegère l’enchaînement des actions ainsi que les liens entre les objets situés dans lesdeux composants voisins : l’adaptateur de domaine et la présentation.

L’adaptateur de domaine sert, pour l’essentiel, à ajuster les différences demodélisation des objets conceptuels entre le noyau fonctionnel et le contrôleur dedialogue. Symétriquement, le composant de présentation permet au contrôleur dedialogue de s’affranchir du fonctionnement de la boîte à outils du niveau interaction.


4

Il peut se voir comme une boîte à outils virtuelle qui implémente des objets deprésentation concrétisés in fine par les objets d’interaction d’une boîte à outil réelle.

ComposantContrôleur de Dialogue

ComposantAdaptateur de domaine

ComposantPrésentation

Composantd'Interaction

ComposantNoyau Fonctionnel

Objets du domaine Objets de présentation

Objets d'interactionObjets du domaine

Figure 1. Les composants du modèle Arch

2.2. Les modèles multi-agents - exemple : PAC

Pour éclaircir la notion d'agent, nous partons de la définition de Ferber quidéfinit un agent comme une entité informatique, réelle ou abstraite, indépendante àdurée de vie limitée, capable d'agir sur elle-même et son environnement [FER 95].Un agent communique avec ses pairs et son comportement est la conséquence de sesobservations, de sa connaissance et de ses interactions avec les autres agents.

En réalité, au sein de la communauté informatique, il existe deux approchesassez différentes des univers multi-agents. Ainsi, les chercheurs qui travaillent dansle domaine de l'intelligence artificielle construisent des univers composés d'agentscognitifs qui possèdent chacun des connaissances sur un domaine particulier. Cesagents sont généralement des entités de taille assez importante qui coopèrent pourrésoudre des tâches complexes. La modélisation des relations entre les agentsconstitue alors un problème à part entière. Des méta-modèles basés sur les conceptsorganisationnels de groupes, rôles et agents permettent une description simple deformes de coordination et de négociation [FER 98]. En parallèle, les chercheurs quitravaillent dans la modélisation des interfaces homme-machine considèrent lesapplications interactives comme étant des univers composés d'agents réactifs. Unagent réactif ou interactif est alors défini comme un agent dont le comportement estla conséquence de ses observations et de ses interactions avec l'utilisateur. A ladifférence des agents cognitifs, la granularité des agents réactifs peut être très petite(un agent réactif peut être réduit à un simple bouton et son intelligence est alors trèsrestreinte). Bien sûr, les deux approches ne sont pas complètement antinomiquespuisque les modèles cognitifs peuvent être pris en compte pour la constitution desagents réactifs. C'est d'ailleurs ce rapprochement qui permet d'envisager l'émergencede systèmes interactifs auto-adaptatifs (s'adaptant automatiquement à l'utilisateur).

En examinant plus en profondeur ces deux approches, on constate que lessystèmes multi-agents peuvent être abordés de deux façons différentes. On peut soitchercher à identifier des agents spécialisés hétérogènes, soit essayer de construiredes agents ayant une structure plus homogène.


5

C'est ce choix d'homogénéité qui est adopté dans le modèle PAC [COU 87, 90].Ce modèle décompose l'application interactive en une hiérarchie d'agents interactifs(figure 2) structurés en trois facettes :

− le composant Présentation est chargé de la transmission (visuelle, sonore, etc.)des informations à l'utilisateur et de l'acquisition des entrées de l'utilisateur ;

− le composant Abstraction contient les données et les traitements sémantiques ;− le composant Contrôle est le moteur des dialogues qui s'établissent entre

l'agent et l'utilisateur, et entre l'agent et les autres agents.PAC permet un dialogue multi-fils (plusieurs dialogues en parallèle) grâce à

l’autonomie relative des agents dans l'interprétation des événements et dans lagestion de leur état.

PC

A

Système interactif

PC

A PC

A PC

A

P C A P C A P C A

Figure 2. Structure d'une application interactive PAC

Les modèles multi-agents procèdent donc à une décomposition de l'applicationen plusieurs entités autonomes et coopératives. Cette nouvelle décomposition permetd’accélérer les retours de l'application à l'utilisateur, indispensables pour lamanipulation directe. Si les modèles multi-agents présentent de nombreuxavantages, ils subissent l'effet contraignant d'une forte dispersion de l'interfaceglobale. En effet, la perception de l'interface globale est difficile pour le concepteurde nouvelles applications car elle est répartie entre les différents composantsPrésentation de chaque agent. Pour remédier à cet inconvénient, les modèles multi-agents doivent être couplés à des environnements de développement d'interfacesutilisateur (type builder). Le concepteur peut alors construire une interface globalepar assemblage de composants de présentation. Ces éléments d'interaction sontensuite affectés à chaque agent de l'application.

2.3. Des modèles mixtes

Dans certains cas, il apparaît souhaitable de combiner les modèles à couchesavec les modèles multi-agents pour essayer de tirer partie de leurs avantagesrespectifs. Ainsi, pour la modélisation des applications multimodales, le modèle


6

PAC-Amodeus [NIG 93] reprend le découpage en couches de Arch tout enexprimant le composant contrôleur de dialogue sous la forme d'agents PAC. Il peutainsi facilement exprimer le parallélisme de contrôle des différentes modalités.

D'une façon plus générale, les composants Abstraction et Présentation dumodèle PAC peuvent être rapprochés des composants Adaptateur de domaine etPrésentation du modèle Arch. Dans ce cas, ils constituent des adaptateurspermettant de combiner une modélisation multi-agents de l'application et l'utilisationde boites à outils spécialisées (pour le traitement du noyau fonctionnel ou pourl'interface utilisateur). Ainsi, il est possible de concevoir des logiciels hétérogènesutilisant à la fois l'approche multi-agents et l'approche en couches et faisant appel àdifférents langages de programmation ou boites à outils.

3. Le modèle AMF

Depuis plusieurs années, notre équipe travaille sur la définition d’un modèlemulti-agents qui remplisse l’ensemble des objectifs cités en introduction. Ce modèle,appelé AMF (Agent Multi-Facettes [OUA 94]), est né d’une double constatation :

1. La décomposition Abstraction / Présentation est généralement insuffisantepour les applications complexes. Des fonctionnalités relevant de thématiquesdistinctes se retrouvent mélangées dans des composants trop macroscopiques.

2. Les formalismes de modélisation des composants Contrôle sont rares etgénéralement limités. Pourtant, ces composants constituent la clé de voûte desmodèles d’architecture et il est indispensable de fournir un outil de modélisationperformant.

3.1. Une structuration Facette - Agent - Agent composé

Pour répondre à la première limite, le modèle AMF propose une décompositionplus fine que PAC des agents interactifs. Chaque agent est structuré en facettes. Surle plan conceptuel, une facette est un composant contenant l'ensemble desdonnées et traitements relevant d'une même thématique fonctionnelle. Leurnombre n'est pas limité et aucune facette n'est obligatoire (lorsque la granularité dedécomposition des agents est très fine, certains agents peuvent ne contenir qu'uneseule facette spécialisée).

En général, parmi les facettes des agents AMF, on retrouve les composantsclassiques de présentation et d'abstraction complétés par de nouvelles facettespouvant provenir :

− de l'identification de fonctions spécifiques des agents comme la gestion dumodèle de l'utilisateur ou la communication dans un contexte multi-utilisateurs,

− d'une duplication des facettes classiques (ex : plusieurs facettes présentationpour représenter plusieurs vues différentes de l'agent),

− d'une décomposition des facettes Contrôle des autres modèles qui sont tropsouvent des “fourre-tout” contenant tout ce qui ne relève pas des autres composants.


7

A titre d’exemple, dans une application mono-utilisateur classique, un agentAMF standard pourra être constitué des facettes suivantes :

− présentation (la gestion de l'interaction avec l'utilisateur),− abstraction (les données logiques et les traitements associés),− évaluation (la capture des actions de l’utilisateur pour une évaluation et une

adaptation de l'IHM, à la volée si l'agent est intelligent ou a posteriori),− erreur (les procédures et messages contextualisés de traitement d'erreurs),− aide (les aides en ligne et contextuelles couplées au traitement des erreurs).

Comme dans PAC, les agents sont organisés hiérarchiquement selon des règlesde composition qui traduisent le fait qu'un agent parent contient un certain nombred'agents enfants. De fait, pour toute application modélisée avec AMF, il existe unagent racine (généralement appelé “application”) qui est l'ancêtre commun de tousles agents de l'application. Notons que “ancêtre” est ici utilisé au sens de la relationde composition : tout agent de l'application est un composant direct ou indirect decet agent ancêtre.

La représentation graphique AMF traduit les relations entre les classesd'agents. Le plus souvent elle utilise des relations d’emboîtement (figure 3a).Lorsque les schémas deviennent trop complexes, et donc difficiles à lire, unereprésentation relationnelle sous forme de graphes peut être utilisée (figure 3b).

Agent Composé

Facette A

Facette P

Facette A’ Facette P’

Facette A Facette P

Agent

Facette A’ Facette P’ contient

(a)

(b)

Agent Composé

Agent

Figure 3. Représentation emboîtée (a) et relationnelle (b) des agents AMF

3.2. Un formalisme d’expression du contrôle de l’interaction

Le composant de contrôle de l'agent constitue le cœur de l'agent. C'est l’élémentqui gère les communications entre les facettes des agents. Tout formalisme supportde ce contrôle doit être capable de traduire des relations de type :

« La facette A veut invoquer le service f de la facette B. »


8

Notons que “Service” est un vocable générique similaire à la notion defonctionnalité. Nous le préférons au mot “fonction” appartenant au vocabulaire deslangages et que nous réservons à l'implémentation du service. A titre d’exemple,supposons que l’action de l’utilisateur sur un bouton de l'interface doive conduire lafacette présentation (A) de l’agent considéré à invoquer le service sémantiqueassocié (f) contenu dans la facette abstraction (B).

Lorsqu’aucun composant de contrôle n’est utilisé, une programmation objetclassique (type C++) conduit à la présence d’instructions de type « B.f » dans lecorps de fonctions membres de la classe de A (si l’on associe une classe d'objet àchaque facette). De tels mécanismes imposent que A connaisse exactement B oudans le cas du polymorphisme que A connaisse exactement une classe générique B0.Le lien fort entre les deux entités empêche toute évolution dynamique de leurrelation (f → f'). Sur le plan méthodologique, une telle contrainte doit être évitée.

Pour représenter les concepts et les mécanismes de contrôle dans unearchitecture AMF, le modèle repose sur un formalisme performant de représentationdes techniques de contrôle s’appuyant sur des éléments situés à deux niveaux :

− Au niveau des facettes, les ports de communication définissent les servicesproposés et les services utilisés.

− Au niveau des agents, les composants de contrôle appelés par extensionfacettes Contrôle sont définis par le regroupement d'entités de contrôle élémentairesappelées administrateurs de contrôle.

3.2.1. Les ports de communication

Les ports de communication constituent les interfaces des facettes. A ce titre, ilsexpriment non seulement les services proposés par chaque facette, mais aussi lesservices indispensables à leur fonctionnement. En fait, on distingue trois types deports (figure 4) :

− port d’entrée (service offert),− port de sortie (service nécessaire),− port d’entrée / sortie (service offert dont l'activation se conclu par l’invocation

d’un autre service distant créant ainsi un phénomène de diffusion. Un exemple seradonné plus loin sur la figure 13).

L’activation d’un port de sortie conduit à l’émission d’un message qui sera reçupar un port d’entrée.

Facette

message

message 2message 1

message

Port d'entrée

Port de sortie

Port d'E/S

Figure 4. Représentation des ports de communication d'une facette AMF


9

A chaque port de communication est associée une fonction particulière appeléedémon. Ce démon se déclenche automatiquement à chaque activation du port. Ondistingue trois situations :

− Lorsque le port activé est un port d’entrée, ce démon correspond à la fonctionmembre de la facette qui remplit effectivement le service. Dans l’exempleélémentaire proposé au début de cette section : « La facette A veut invoquer leservice f de la facette B. », la facette B de l'agent considéré contient un port d’entréequi est associé au démon f. C'est ce démon qui traite les informations contenues dansle message émis par A.

− Lorsque le port activé est un port de sortie, ce démon est souvent un démonpar défaut qui ne fait aucun traitement particulier puisque l'objectif de ce port est deservir de point de départ pour l'invocation d'un service distant. Dans certains cas, undémon spécifique peut cependant être utilisé par un port de sortie pour effectuer despré-traitements avant l'émission du message.

− Lorsque le port activé est un port d’entrée/sortie, il se comporte tout d'abordcomme un port d'entrée avant d'être considéré comme un port de sortie. Son démonest activé lors de la réception du message. Celui-ci effectue les traitements qui luisont propres puis il transmet un nouveau message (éventuellement le même) auxadministrateurs de contrôle qui lui sont connectés en sortie.

Lorsqu'un port de sortie d'une facette doit accéder à un service d'un autre agent,ou si un port d'entrée peut être activé par d'autres agents, ces ports decommunication sont dits exportés. Cette exportation est extrêmement importante carl'ensemble des ports exportés constitue l'interface fonctionnelle visible de l'agent. Onnotera que cette interface contient non seulement la liste des services proposés parl'agent, mais aussi la liste des services dont il a besoin pour fonctionner. Pour mettreen évidence cette interface fonctionnelle, de petits cercles situés à la frontière desagents traduisent ces exportations sur les représentations graphiques (figure 5).

Agent

Facette

Service Proposé

Le serviceproposé est

exporté

Figure 5. Exportation d'un port de communication

3.2.2. Les facettes Contrôle

Les “facettes” Contrôle sont différentes des autres facettes car elles n'ont pasvéritablement d'existence propre et ne présentent pas de ports de communication. Eneffet, une facette Contrôle est constituée d'entités élémentaires de contrôle appelées“administrateurs de contrôle” qui sont gérées par l'agent lui-même. Il est bien sûrpossible d'imaginer une adaptation de notre modèle en construisant une véritable


10

facette de contrôle qui ne laisse aux agents qu'un simple rôle de conteneur defacettes. Quelle que soit l'approche retenue, nous avons choisi de conserver levocable facette afin de laisser une trace visible d'un composant de contrôle essentielsur le plan conceptuel.

Les administrateurs de contrôle des agents gèrent les liens entre les ports decommunication des facettes. La notion d’administrateur de contrôle peut êtrerapprochée de la notion de connecteur telle qu’elle est décrite par Allen [ALL 97].Un administrateur de contrôle joue trois rôles :

− un rôle de connexion qui consiste à gérer les relations logiques pouvantexister entre les ports de communication qui lui sont attachés (sources ð cibles) ;

− un rôle comportemental qui exprime les règles d’activation del'administrateur, c'est-à-dire sous quelle condition et à quel moment les messagesémis par les ports sources seront transmis aux ports cibles ;

− un rôle de traduction qui consiste à transformer les messages émis par lesports sources en messages compréhensibles par les ports cibles.

En considérant le rôle comportemental, le modèle propose pour les interactions“classiques” les types d'administrateurs suivants (figure 6) :

− Un administrateur simple représente une relation orientée entre un port sourceA et un port cible B, équivalente à l'assertion : si A est activé alors activer B.

− Un administrateur itératif indique la nécessité d'avoir une répétition de nactivations du port source avant d'avertir le port cible.

− Un administrateur de séquence permet de représenter soit une relation d'attented'activation entre plusieurs ports sources A1, A2, ..., An et un port cible B équivalenteà l'assertion : Si A1 puis A2 puis ... An alors B, soit une relation inverse équivalente àl'assertion : Si A1 alors B1 puis B2 puis ... Bn.

− Les administrateurs conjonctif et disjonctif offrent le moyen de décrirerespectivement une relation de conjonction sans contrainte d'ordre, et unedisjonction équivalentes à : si A1 et A2 et ... An alors B, et si A1 ou A2 ou ... An alorsB.

Cette liste comportementale ne prétend pas être exhaustive. En particulier, enétendant AMF au contexte du travail coopératif [TAR 97a], nous avons été amenés àdéfinir de nouveaux comportements liés à la communication entre les participants.

AdministrateurSimple

AdministrateurIteratif

n

AdministrateurDisjonctif

AdministrateurConjonctif

12

34

Administrateurde Séquence

ordre d’activation

Figure 6. Représentation schématique des principaux administrateurs de contrôle


11

En considérant le rôle de traduction de l'administrateur, on peut identifier lestypes d'administrateurs suivants :

− Un administrateur de transfert transporte directement les données issues duport source vers le port cible sans modification.

− Un administrateur de conversion transforme les données issues du port sourceen données compréhensibles par le port cible (ex : entier en chaîne de caractères).C'est le type d'administrateur le plus courant avec l'administrateur de transfert.

− Un administrateur de correspondance effectue une correspondance entrel'ensemble des valeurs des ports sources et celui des valeurs du port cible.

− Un administrateur d'assemblage rassemble les données issues des ports sourcespour les transporter sous une forme structurée vers le port cible.

− Un administrateur de calcul arithmétique applique des opérations sur lesdonnées des ports sources pour calculer la donnée à envoyer au port cible.

− Un administrateur de traitement applique un algorithme sur les données desports sources pour obtenir la donnée à transmettre au port cible.

Un administrateur réel est une combinaison de ces administrateurs élémentaires(comportementaux et traducteurs) qui permet la connexion entre des ports decommunication. Dans le cadre de la construction d'un atelier graphique deconception, et pour faciliter l'apprentissage du modèle, il est nécessaire que lesreprésentations incluent aussi le rôle de traduction des administrateurs en utilisantdes symboles additionnels (figure 7). Cependant, la surcharge visuelle et cognitiveintroduite par ces symboles est difficile à concilier avec la représentation standarddes administrateurs disjonctifs ou de séquence. Aussi, par souci de simplicité, lareprésentation graphique classique des administrateurs exprime uniquement le rôlede connexion et le rôle comportemental des administrateurs réels.

F(x)

Transfert Conversion Correspondance Assemblage Calcul Traitement

Figure 7. Représentation du rôle de traduction des administrateurs de contrôle

Pour illustrer l'utilisation de notre formalisme graphique, reprenons lamodélisation de la relation élémentaire : « la facette A veut invoquer le service f dela facette B ». Cette relation se traduit par l’utilisation d’un administrateur simpleentre un port source de la facette A et un port cible de la facette B. La fonction fdevient le démon du port d’entrée de la facette B (figure 8). Pour une plus grandeclarté de la modélisation, c’est le choix des noms des ports de communication quidoit exprimer la sémantique du service f.

On peut remarquer sur cette figure que la facette Contrôle est représentée par unrectangle en pointillé. Ceci traduit le fait que cette facette est effectivementdifférente des autres facettes puisqu'elle ne possède pas d'existence propre.


12

Agent

A

Déclenche_f

B

Faire_f

Contrôle

Pas de démon associéà ce port de sortie

f est le démon associéà ce port d’entrée

Figure 8. Modélisation AMF de la relation « A veut invoquer le service f de B »

3.2.3. Un mécanisme d’activation

Dans la programmation événementielle classique, lorsqu'un événement produitpar l'utilisateur ou le système est reçu par une application, une fonction particulièreest automatiquement invoquée. Celle-ci effectue des traitements internes puis faitappel à d'autres services. Dans une architecture AMF, cette fonction call-back quiest liée à la boite à outil graphique utilisée (OWL en Borland C++, MFC en VisualC++ ou AWT en Java) va demander l'activation d'un port de sortie adéquat par appelde la fonction Active(NomPort, message) sur laquelle nous reviendrons plusloin. Le mécanisme d’activation utilisé ensuite est le suivant :

1. Lorsqu'un port de communication est activé, son démon se déclenche puisl'activation est transmise à l'agent qui réveille tous les administrateurs de contrôlesur lesquels le port est connecté en tant que source. Si le port est exporté (susceptibled'être connecté à d'autres agents), l'activation est aussi transmise récursivement àl'agent composé parent. Ainsi, pour que deux agents communiquent, ils doiventobligatoirement avoir un ancêtre commun (au sens de la composition).L'administrateur de contrôle utilisé est alors placé au niveau de cet agent parent.

2. Chaque administrateur de contrôle ainsi réveillé examine alors si sesconditions d'activation sont remplies, auquel cas, il traduit les messages se trouvantsur chacun des ports sources pour constituer un nouveau message qui est transmis àtous les ports cibles de façon séquentielle (l'ordre correspond à l'ordre de connexionà l'administrateur). Si l'on désire que les ports cibles soient activés en parallèle, ilfaut que ces ports déclenchent des processus indépendants en utilisant destechniques de cheminement multiple (multi-threading). Si les ports cibles se situentsur des agents composants, les activations sont propagées aux composants.L’activation de ces ports cibles déclenche les démons qui leur sont associés.

3. Après traitement, tous les ports cibles renvoient un message d'accusé deréception à l'administrateur qui les a sollicités. A son ton tour, l'administrateurretourne un tel message au port source qui a déclenché l'activation. Dans le casgénéral, ces messages ne sont pas traités par le port source. Pourtant, si l'on désireutiliser AMF pour modéliser complètement une application, on s'aperçoit que cettepropriété peut être utilisée pour invoquer un service distant dont on attend uneréponse. Bien que l'administrateur utilisé ne présente pas de différence avec les


13

autres administrateurs simples, il nous semble intéressant pour le concepteur de faireapparaître visuellement cette caractéristique (symbole noir). Nous parlons alorsd'administrateur avec retour. Par exemple, cette propriété peut être utilisée quandune facette Présentation a besoin de connaître la valeur d'une donnée caractéristiquede l'agent gérée par la facette Abstraction afin de pouvoir la visualiser (figure 9).

Agent Interactif

Facette Présentation

Lit_Valeur

Facette Abstraction

Donne_Valeur

Contrôle

Administrateur simpleavec retour

Figure 9. Représentation d'un administrateur avec retour

Les concepts introduits par AMF peuvent être rapprochés de ceux utilisés par latechnologie Java Beans [ENG 97]. En effet, les facettes des agents constituent descomposants logiciels (Beans) capables de se présenter (liste des services offerts etattendus) et qui communiquent par l'envoi de messages ou événements. Les portssont les entités qui sont à l'écoute de ces événements. Ils jouent donc le rôle deslisteners Java. Les administrateurs de contrôle gèrent les liens entre les ports et secomportent comme des adaptateurs. Notons que dans Java Beans, ces conceptsrestent sous forme d'interface type (prototype fonctionnel) ce qui laisse un travailconsidérable au programmeur. C'est pourquoi nous avons choisi de les enrichir pourconstruire une implémentation Java de AMF [POQ 98].

3.3. Extension d'AMF

A ce stade, AMF est capable de modéliser des interactions homme-machine. Ilpermet de mettre en évidence les séquences d’activation des services et de modéliserune grande majorité des situations. Cependant, pour pouvoir l'utiliser commesupport global de modélisation des logiciels, il est nécessaire d'introduire lesextensions suivantes :

− Les activations déclenchées par l'utilisateur et les activations internes,− Les administrateurs de contrôle cascadés,− Les instanciations multiples d’agents,− L'héritage d'agent.


14

3.3.1. Les activations déclenchées par l'utilisateur et les activations internes

Pour que AMF serve vraiment de guide à l'utilisation, il nous semble intéressantde faire apparaître sur les schémas les ports de communication qui sont directementactivés suite à une action de l'utilisateur. Un petit éclair en trait fin situé à côtédu port concerné traduit cette caractéristique (figure 10). En outre, comme nous leverrons à travers un exemple concret plus complexe (§ 3.4), il est égalementfréquent que l'activation d'un port de sortie A ne soit pas déclenchée par l'utilisateur,mais qu'elle soit produite par le démon associé à un autre port d'entrée B de la mêmefacette. De petites flèches fines, internes à la facette (ici de B vers A), serontutilisées pour exprimer ces relations de causalité.

Agent Interactif


Déclenche_Action

Echo_Action

Facette Abstraction

Faire_Action

Contrôle

Figure 10. Une interaction élémentaire modélisé avec AMF

3.3.2. Les administrateurs de contrôle cascadés

Dans certains cas, le concepteur peut vouloir constituer des administrateurs decontrôle complexes résultant de la mise en cascade d'administrateurs de contrôle debase. Un exemple simple d'utilisation consiste à considérer une situation danslaquelle une action doit être déclenchée selon une relation booléenne complexe :« Déclencher F si F1 et (F2 ou F3) ». Pour mettre en œuvre simplement une relationde ce type, il faut autoriser la connexion d'un administrateur de contrôle en sortied'un autre administrateur. Dès qu'un message est émis par le premier administrateur,il est reçu du second comme s'il provenait d'un port de communication (figure 11).

Agent

A

F1

B

F

Contrôle

F2

F3 A1

A2

Figure 11. Mise en cascade de plusieurs administrateurs de contrôle


15

3.3.3. Les instanciations multiples d’agents

Les agents représentés jusqu'à présent sur les schémas AMF correspondent enfait à des classes d'agents dont l'instanciation n'est pas obligatoirement unique.Plusieurs agents de la même classe doivent pouvoir co-exister. Les instances d’unemême classe d’agents composants constituent des familles d’agents gérées par leuragent composé. Par défaut, tout agent composé contient au moins une famille decomposants. Pour permettre une bonne compréhension du fonctionnement desapplications, il est indispensable de traduire sur les schémas AMF l'existence desinstanciations multiples. Lorsque la situation se présente, la classe correspondanteest représentée avec une bordure en relief (figure 12).

Agent à instanciations multiples

Figure 12. Représentation d'un agent à instanciations multiples

Notons que ces instanciations sont déclenchées par d'autres agents (ancêtres ouayant un lien de parenté au sens de la composition), mais que la phased’instanciation n’apparaît pas explicitement sur les schémas de modélisation puisqueceux-ci expriment essentiellement un état structurel statique de l'application. Ils nepermettent donc pas de représenter la dynamique du système. Cependant, l'opérationd'instanciation est généralement produite au sein d’un service proposé par un autreagent. Ainsi, dans un éditeur, la création d'un nouveau document peut êtrereprésentée par un port Nouveau_Document (activé lors du choix du menucorrespondant) dans la facette Présentation de l'agent composé Application. Ce portest relié à un port Crée_Document dans la facette Abstraction car c'est le noyaufonctionnel qui gère l'ensemble des documents. En pratique, l'instanciation dunouvel agent Document sera donc réalisée par le démon associé au portCrée_Document.

La possible existence d'instances multiples d'une même classe d'agent conduit lemécanisme interne de fonctionnement des administrateurs de contrôle à activersystématiquement les ports cibles de toutes les instances concernées. Cette propriétéest très intéressante pour diffuser un message, mais elle ne permet pas d'activer uneinstance particulière. Pour permettre un tel filtrage, nous avons ajouté un paramètreoptionnel à la fonction d'activation qui permet de spécifier le nom de l'agent ciblevisé. L'identité de l'agent concerné ne pouvant être connue a priori, c'est lors del'exécution que le filtrage est réalisé. Il ne s'agit donc pas d'une nouvelle formed'administrateur de contrôle, mais bien d'une forme particulière d'activation.Pourtant, pour une meilleure compréhension du schéma de modélisation, il noussemble intéressant de faire apparaître visuellement cette caractéristique. Dans ce but,une barre verticale en sortie de l'administrateur indique qu'il y a un filtrage del'activation et qu'une seule instance est concernée par le message (cf. figure 13).


16

Figure 13. Représentation du filtrage des messages

L’existence simultanée de plusieurs instances d’une même classe d’agents peutconduire à des situations dans lesquelles une des instances veut activer un serviced’une autre instance de la même classe. Dans ce cas, nous sommes amenés àconstruire des schémas dans lesquels un administrateur simple relie deux ports decommunication de la même facette, mais où un filtrage de cet administrateur traduitcette forme particulière d’activation (figure 14).

Agent Composé

Agent Composant

Facette

Service_Nécessaire

Service_Proposé

Contrôle

Figure 14. Une interaction entre deux instances d’une même classe

3.3.4. L'héritage d’agent

Nous ne reviendrons pas ici sur l'intérêt de la notion d'héritage introduite par leslangages objets. Les relations d’héritage peuvent être dues à des enjeux demodélisation ou à des enjeux de capitalisation. Dans le contexte du modèle AMF, ilnous a paru intéressant d'introduire également une notion d'héritage d'agent. Eneffet, la mise en œuvre du modèle AMF induit des séquences relativement longuesde déclaration de ports ou d’administrateurs. Pour capitaliser ces informations il peutalors être utile de définir des classes génériques. Nous avons donc défini la notiond’héritage d’agent ainsi :

Si la classe d'agent B hérite de la classe d'agent A, alors :− un agent de la classe B hérite de la structure en facettes et de l'ensemble des

administrateurs de contrôle de la classe A ;− chaque classe facette de B hérite de la classe facette de A associée.

Cet héritage complexe n'existe bien sûr pas de façon naturelle dans les langagesde programmation classique. Il est obtenu en reprenant automatiquement lesséquences de déclaration et d'instanciation des facettes contenues dans leconstructeur de la classe agent parente (voir § 3.6 pour le détail de ces séquences).


17

Pour illustrer l'héritage d'agent, considérons le cas d'un éditeur graphique. Il estutile de définir une telle relation d’héritage entre une classe agent Forme génériqueet des classes d'agents spécifiques Carré, Cercle, Polygone, etc.. En effet, tous leséléments d'un dessin doivent être dessinés, déplacés, et peuvent voir leurs attributsde couleur et d’épaisseur modifiés. De fait, il est intéressant de définir une classeparente Forme qui contient les facettes (Abstraction A0 et Présentation P0) avecleurs ports de communication (Dessiner, Déplacer, Colorier, etc.) et lesadministrateurs de contrôle adéquats (représentés par le facette Contrôle C0). Lesclasses d’agent Carré, Cercle et Polygone héritent de la classe Forme (figure 15).Elles héritent donc de sa structure en facettes et de l'ensemble des administrateurs decontrôle (les “facettes” Contrôle Ci héritent de C0). De même, leurs facettesAbstraction Ai et Présentation Pi héritent des facettes A0 et P0 de la classe Forme.L'ensemble du “cablage” des services de Forme (ports de communication etadministrateurs de contrôle) est ainsi transmis à ses descendants.

Forme

A0 P0

A1 P1 A2 P2 A3 P3

PolygoneCarré Cercle

C0

C1 C2 C3

Figure 15. L’héritage d’agent

Comme nous adoptons systématiquement cette forme d'héritage, l’héritage desfacettes est implicite et seul l’héritage des agents apparaît sur les schémas AMF.

3.4. Un exemple de modélisation AMF

Pour illustrer les principaux concepts proposés par AMF, nous présentons unexemple de modélisation d'un logiciel interactif relativement simple. Il s'agit d'uneapplication rudimentaire de gestion d'un agenda ayant le cahier des charges suivant :

− L'agenda gère des rendez-vous qui peuvent être créés, modifiés, déplacés etsupprimés. Ces opérations d'édition sont réalisées par manipulation directe.

− Le calendrier utilisé par l'agenda peut être présenté sous différentes formes :jour, semaine, mois et année (figure 16).


18

Figure 16. Les différents modes de visualisation de l’exemple Agenda

Pour assister le concepteur dans la construction d'une architecture AMF, nousavons élaboré une méthode simple permettant de partir d'une conception généralepour aboutir progressivement à une conception détaillée [TAR 97a]. La démarcheproposée se structure en six phases que nous allons très rapidement couvrir :

1. Identification et hiérarchisation des classes d’agents2. Identification des services3. Identification des facettes4. Définition des ports de communication5. Définition des relations d’héritage6. Choix des administrateurs et des connexions

Identification et hiérarchisation des classes d’agentsLa phase d'analyse conceptuelle fait clairement apparaître 3 types d'agents :− Agenda : agent parent qui correspond à notre application. C'est lui qui reçoit

les commandes de l'utilisateur (action sur des menus ou sur la souris).− Calendrier : agent gérant les références temporelles qui est capable de se

présenter sous les différents modes de visualisation requis.− Rendez-vous : agent contenant des données telles que la référence temporelle

(date, jour, heure de début, durée) et le motif du rendez-vous.


19

Notre application est donc constituée d'un agent agenda qui contient un agentCalendrier et un ensemble quelconque d'agents Rendez-vous créés par l'utilisateur.

Identification des services− Agenda : ajouter, supprimer, sélectionner, modifier (éditer le contenu ou

déplacer) un rendez-vous, se dessiner.− Calendrier : changer de mode de visualisation, convertir une position écran

en référence temporelle, se dessiner.− Rendez-vous : s'éditer, tester si l'on est concerné par une sélection, se

dessiner.

Identification des facettesEtant donné la simplicité de l'application, les seules facettes devant être

impérativement définies sont les facettes Abstraction et Présentation de ces troistypes d'agent. Pour ne pas surcharger la modélisation et conserver le caractèrepédagogique de cet exemple, nous nous en tenons donc à ces deux types de facette.

Définition des ports de communication− Agenda : la facette Abstraction gère les rendez-vous en cours. Elle propose

des ports permettant de modifier le nombre de rendez-vous (par création oudestruction) et des ports permettant de retrouver un rendez-vous à partir d'uneréférence temporelle. La facette Présentation contient sept ports de sortiecorrespondant aux actions de l'utilisateur. L'utilisation de noms de services clairspermet une meilleure compréhension du fonctionnement sous-jacent de l'application.

− Calendrier : les services se traduisent par des ports d'entrée de laprésentation (Change_Mode, Calc_Ref_Temp et Affiche) et le calcul de laconversion est effectué par l'abstraction via les ports Calc_Date. Notons que le portd'entrée / sortie Affiche dessine le calendrier, puis diffuse la demande d'affichage àtous les rendez-vous en leur indiquant le mode courant.

− Rendez-vous : les services se traduisent par des ports d'entrée de l'abstraction(Change_infos et Sélection_RV) et de la présentation (Affiche). En outre des portsinternes (non exportés) Lit_Infos et Donne_Infos permettent à la présentationd'obtenir de l'abstraction les données du rendez-vous pour son affichage.

Définition des relations d’héritageDans notre cas, il n'y en a pas. On pourrait en avoir si l'on gérait des classes de

rendez-vous variées (périodiques, inamovibles, etc.).

Choix des administrateurs et des connexionsLe choix des administrateurs et des connexions est généralement assez simple

car il repose sur des motifs de conception sur lesquels nous reviendrons dans lasection 4.2. Seuls les mécanismes permettant la sélection d'un rendez-vous à partirde l'analyse des coordonnées du clic de la souris méritent d'être commentés plus endétail. Lorsque l'utilisateur clique sur l'écran pour sélectionner un rendez-vous, lecall-back de la Présentation de l'agenda active le port Calc_Pos_Clic qui demandeau calendrier la référence temporelle associée, puis active le port Recherche_RV quidétermine le rendez-vous correspondant par l'interrogation systématique de tous lesagents rendez-vous. Ce mécanisme de recherche est détaillé dans la figure 20.


20

A partir de tous ces éléments, nous pouvons construire la modélisation graphiquede l'architecture AMF de cet exemple d'agenda (figure 17).

Rendez-vous

Lit_Infos

Abstraction

Donne_Infos

Contrôle

Calendrier

Calc_Date

Abstraction

Calc_Date

Contrôle

Change_RV

Abstraction Contrôle

Agenda

Présentation

Présentation

Présentation

Calc_Pos_Clic

Affiche

Affiche Change_Infos

Calc_Ref_Temp

Change_Mode Change_Mode

Ajoute_RV

Supprime_RV

Test_RV

Sélection_RV

Ajoute_RV

Supprime_RV

Affiche_Tout

Recherche_RV

Recherche_RV

Conversioncoordonnée écran óréférence temporelle

Conversion numéroordinal ó format

JJ/MM/AA

Change moded'affichage

Figure 17. Modélisation AMF d'un logiciel de gestion d'agenda

On peut envisager une deuxième modélisation dans laquelle il existe une facettePrésentation pour chaque mode de représentation du calendrier au lieu d’avoir uneseule facette capable de gérer les quatre modes. Dans ce cas, le changement de modese traduit par la déconnexion de la facette Présentation courante de l’agentCalendrier puis par la connexion d’une nouvelle facette Présentation plus adéquate.Cependant, ce mécanisme dynamique ne peut être modélisé sur un schéma statique.

3.5. Une modélisation OMT de AMF

Comme nous l'avons indiqué en introduction, un modèle d'architecture ne doitpas se contenter d'être un bon support pour la formalisation. Il doit aussi constituerl'ossature de la réalisation. Dans cette optique, nous proposons sur la figure 18 unemodélisation OMT [RUM 95] de AMF qui présente les classes génériques définies,ainsi que les principaux services qui leurs sont associés.


21

Agent

NomListe_Ports_ExpAjoute(Facette)Supp(Facette)Ajoute(Admin)Supp(Admin)Exporte(NomPort)Active_Admins()Envoie(Msg)Reçoit(Msg)AvertirCible(Msg)

Facette

NomAjoute(Port)Supp(Port)Active(NomPort, Generic)Envoie(Msg)Reçoit(Msg)...

Administrateur

NomAjouteSource(Port)SuppSource(Port)AjouteCible(Port)SuppCible(Port)Active(Msg)SourcesActives?()Traduit(Msg)

admins

agent

agent

facettes

Agent Composé

Ajoute(Agent, Famille)Supp(Agent, Famille)Ajoute(Famille)Supp(Famille)

ports

facette

Port

NomDémonActive(Generic)

PortS

Active(Generic)

composants

parent

PortE

Active(Generic)

PortES

Active(Generic)

Itératif

Active()

Séquentiel

Active()

sources

cibles

Msg

Nom_Port_DestNom_Facet_DestNom_Agent_DestData

Référence de la fonction à activer

Generic est un typede donnée générique(en C++, ex : void*)

messages_source

Références nominatives de ports

Figure 18. Représentation OMT des éléments du modèle AMF

Cette modélisation nous a permis de construire des classes génériques en C++ eten Java. Les caractéristiques de ces deux langages étant légèrement différentes, enparticulier par le fait que Java n'autorise pas d'héritage multiple, nous avons puvalider deux techniques de mise en œuvre de AMF. La première (en C++) consiste àconstruire les applications en instanciant des classes spécifiques dérivées des classesgénériques AMF (agent, facette, etc.), la seconde (en Java) consiste à mettre enrelation les instances des classes spécifiques aux applications avec les instances desobjets AMF représentant la structure de l'application (voir figure 19).

Quelle que soit la solution retenue, l'objectif est d'être capable de générer uneapplication exécutable à partir d'un schéma conceptuel AMF. Chaque classe d'agentou de facette va donner naissance à une classe dérivée ou associée aux classesgénériques. Les constructeurs de ces nouvelles classes contiennent lesinstructions de fabrication de leurs composants. L'exécution de l'applicationconduit à l'instanciation de l'agent racine qui à son tour fabrique en cascade tous lesautres agents. Pour comprendre le principe de fonctionnement d’une applicationAMF et justifier le choix des services apparaissant sur la figure précédente, il fautsavoir que la vie d'une application AMF se déroule principalement en deux temps.


22

La première phase que nous venons d'évoquer est une phase de construction del’architecture. La deuxième phase est une phase d’utilisation qui se traduit par desactivations de ports de sorties résultant d’actions de l’utilisateur ou du système.

Approche par héritage (C++)

#include <amf.h>

class PresRdV : public Facette{ PresRdV(String Nom) : Facette (Nom) { Ajoute( new PortE("Affiche", ...)); ... } ...};

class RdV : public Agent{ RdV(String Nom) : Agent (Nom) { Ajoute( new PresRdV("Presentation")); ... } ...};

Approche par association (Java)

import amf.*

public class PresRdV{ public Facette facette;

PresRdV(String Nom) { facette = new Facette (Nom, this); facette.Ajoute( new PortE("Affiche", ...)); ... } ...}

public class RdV{ public Agent agent;

RdV(String Nom) { agent = new Agent (Nom, this); PresRdV pres = new PresRdV("Presentation"); agent.Ajoute( pres.facette); ... } ...}

Extraits simplifiés des programmes sources del'exemple Agenda en C++ et en Java.

Les références aux démons se font par pointeur enC++ et par nom en Java.

Figure 19. Deux approches pour l'implémentation du modèle AMF

3.6. Vie d’une application AMF

Sur la figure 20, nous récapitulons la succession des primitives devant êtreutilisées durant les deux phases essentielles de la vie d’une application AMF. Lastructuration hiérarchique de cette liste exprime l’ordre et le niveau de granularitédes opérations. Les opérations de construction correspondent aux invocations desconstructeurs des objets (au sens C++). Les opérations complémentaires de mise enplace des liens entre les objets (agents, facettes, ports et administrateurs) sontcomplétées du nom du service devant être utilisé. Ces noms sont ceux utilisés sur lamodélisation OMT présentée précédemment. Un programme source AMF utilisel'ensemble des fonctions présentées dans ce synoptique (hors II-C).

On remarque rapidement que l'ensemble des opérations de la phase I estautomatisable. Ainsi, à partir d'un schéma de modélisation AMF, nous pouvons fairegénérer par programme le squelette de l'application. Il restera au concepteur à définirles attributs des nouvelles classes produites et à écrire le corps des démons associésaux ports de communication afin de constituer la sémantique de l'application (Cf.§4.2). Une fois cette phase de construction achevée, l'application est prête àfonctionner et à répondre à toute activation d'un port de sortie (phase II).

Notons que la phase I constitue un point de départ. A chaque instant,l'architecture de l'application peut évoluer par ajout ou suppression d'entités (port,administrateur, facette ou agent).


23

I. Construction de l'architecture AMF :A. Construction de l'agent composé racine

1. Construction des agents composantsa) Construction des facettes des agents

(1) Construction des ports de communication(2) Ajout de ces ports aux facettes : AjoutePort(Port)

b) Ajout de ces facettes aux agents : Ajoute(Facette)c) Enregistrement des ports exportables : Exporte(NomPort)d) Construction des administrateurs de contrôle

(1) Ajout des ports sources : AjouteSource(Port)(2) Ajout des ports cibles : AjouteCible(Port)

e) Ajout des administrateurs de contrôle aux agents : Ajoute(Admin)2. Création éventuelle de nouvelles familles d'agents : Ajoute(Famille)3. Ajout des agents composants : Ajoute(Agent, Famille)

B. Si les agents composants sont eux-mêmes composés, on reproduitrécursivement la phase A pour ces agents.

II. Utilisation de AMF - Mécanisme d'activation d'un port de sortie :A. Constitution de la donnée à transmettre (de type Generic)B. Activation du port de sortie à partir de la facette propriétaire :

Active(NomPort, Generic, <NomAgent>). Le troisième argumentest optionnel. Il spécifie le nom de l'agent destinataire si l'appel est filtrant.

C. Mécanisme interne d'activation (n'apparaît pas dans le code source) :1. Déclenchement du démon associé au port de sortie : Active(Generic)2. Constitution d'une structure Message (encapsulation de la donnée).3. Transfert du message de la facette vers le contrôle de l'agent :

Envoie(Msg). Si le port est exporté, le message est aussi transmis àl'agent composé parent.

4. Réveil de tous les administrateurs de l'agent propriétaire de la facette :ActiveAdmins().Pour chaque administrateur dont le port activé est un port source :a) Test si les conditions d'activation sont réunies : SourcesActives?()

Si c'est le cas, on continue, sinon pour certains administrateurs (ex :conjonctif) le message peut être archivé dans MessagesSource.

b) Traduction du message à transmettre aux ports cibles : Traduit(Msg)c) Envoi du message aux facettes propriétaires des ports cibles :

AvertirCible(Msg). Si un port cible provient d'une exportation,le message est transmis aux agents composants concernés.

d) Réception du message par la facette destinataire : Reçoit(Msg)e) Déclenchement du démon associé au port d'entrée: Active(Generic)

D. Récupération de la donnée de retour si nécessaire sous forme d'unedonnée Generic

Figure 20. Les deux phases distinctes de la vie d'une application AMF


24

3.7. Un exemple d'implémentation

Le modèle AMF respecte les objectifs que nous avons fixés pour un modèled'architecture. Ainsi, il ne se contente pas de servir de support à la spécification desapplications, mais il permet aussi de constituer l'ossature de la réalisation. Commenous l'avons annoncé précédemment, une implémentation en C++ de AMF a étéréalisée en définissant les classes génériques correspondant à la modélisation OMTprécédente. Le détail des classes (Agent, Facette, Administrateur, Port, etc.) et deleurs fonctions membres est décrit dans [TAR 97a]. Par ailleurs une implémentationen Java de AMF a été réalisée [POQ 98]. Elle repose sur la même structuration touten exploitant les caractéristiques propres de Java (Beans, Listeners, Interfaces, etc.).

Les implémentations du modèle AMF sont particulièrement intéressantes carelles sont complètement dynamiques. En effet, durant la vie d’une application AMF,on peut modifier la structure de l’architecture. Ceci signifie qu'à chaque instant,pendant l'exécution, il est possible d'instancier de nouveaux éléments (agent, facette,port ou administrateur) ou d'en supprimer. En ce qui concerne les administrateurs decontrôle, il est aussi possible de modifier à la volée leurs connexions (changer lesports sources ou cibles).

De plus, comme les liens entre les ports de communication sont gérés par lesadministrateurs de contrôle, il est possible d’interchanger rapidement deux éléments(invocation des fonctions Supprime et Ajoute) sans avoir à explicitement vérifier etmodifier tous les liens sur les ports de communication affectés. Ainsi, on peutéchanger deux ports de communication pour substituer un traitement à un autre (ex :algorithme de calcul). Dans certains cas, on peut aussi utiliser cette capacité pouréchanger deux éléments de taille beaucoup plus importante comme des facettesentières (ex : les facettes présentation du calendrier dans l'exemple Agenda). Eneffet, grâce à l'utilisation de références nominatives (chaînes de caractères servantd’identificateur), il suffit que les éléments interchangés présentent une interfacecommune définie par des noms de port de communication identiques. L'utilisationde références nominatives est utilisée classiquement dans les langages objetsdistribués respectant la norme CORBA [SIE 96] pour la flexibilité qu'elle introduit.Les performances sont bien sûr un peu affectées, mais par l'utilisation de techniquede hash coding, les résultats obtenus sont tout à fait satisfaisants. En outre, avecl'évolution permanente des matériels, il nous semble plus intéressant de mettrel'accent sur la réutilisatibilité et la modularité des modèles plutôt que sur leursperformances, en particulier dans le domaine des applications interactives.

4. Des outils de mise en œuvre du modèle

Pour aider les concepteurs de logiciels à utiliser le modèle AMF, nous avonsétendu nos recherches selon deux axes complémentaires. Ainsi, nous avons identifiédes motifs de conception récurrents réutilisables (design patterns) et nous avonsconçu un outil de génération de code permettant de passer automatiquement d'unemodélisation graphique à un squelette d'application.


25

4.1. Construction de design patterns

Pour concevoir une application interactive complexe, on ne peut plus sesatisfaire de méthodes dans lesquelles les concepteurs construisent les logiciels de Aà Z. Aujourd'hui, il est de plus en plus conseillé de s'appuyer sur un ensemble demotifs de conception ou design patterns [GAM 95] pour effectuer les choixarchitecturaux. Ainsi, la phase de conception ne s'effectue pas en partant de zéro,mais à partir de modèles éprouvés.

La granularité de ces motifs est très variable. Ils peuvent permettrent de résoudredes problèmes ponctuels ou faciliter l'architecture globale de l'application. Dansnotre contexte, il peut s'agir de motifs de structuration des agents ou de motifs decoopération entre agents. Ainsi, à partir de notre expérience d'utilisation de AMF,nous avons pu identifier plusieurs motifs élémentaires récurrents [TAR 97b]. Denouveaux motifs restent bien sûr à découvrir. A titre d'illustration, nous présentonsdeux motifs de conception classiques.

4.1.1. L’interaction simple

Le premier motif de conception que nous avons identifié est celui utilisé pour lesinteractions simples. Comme le soulignent les recommandations ergonomiques deconception d'une interaction homme-machine, toute action de l’utilisateur doitconduire à un feedback perceptible, ce qui induit un aller-retour entre la présentationqui communique avec l'utilisateur et l'abstraction siège de l'intelligence duprogramme. La figure 20 présente les deux variantes qui peuvent être utilisées pourcette modélisation.

Agent Interactif


Déclenche_Action

Echo_Action

Facette Abstraction

Faire_Action

Contrôle

A1

A2

(a)

Agent Interactif


Déclenche_Action

Echo_Donnée

Facette Abstraction

Modif_Donnée

Contrôle

A1

A2

Faire_Action(b)

Figure 20. Deux design patterns de modélisation d'une interaction élémentaire


26

Dans le premier cas, la modélisation d'une action élémentaire conduit à unestructure déjà commentée précédemment qui contient trois ports de communicationet deux administrateurs de contrôle (figure 20a). En revanche, lorsque plusieursactions peuvent modifier une donnée gérée par la facette Abstraction, il estpréférable de complexifier la modélisation en séparant en deux ports distincts le portd’entrée / sortie Faire_Action (figure 20b). Le port d’entrée Faire_action activealors le port de sortie Modif_Donnée pour que l’écho soit transmis. Ainsi, la prise encompte d’une autre action se fera simplement par la définition de deux nouveauxports de type Déclenche_Action et Faire_Action. Cette situation est plus fréquentedans les applications complexes. Ainsi, nous l’avons fréquemment rencontrée dansle cadre de la conception de CinémaTek [TAR 97c], un logiciel de construction deschémas cinématiques pour la mécanique.

4.1.2. La recherche d'un composant

Dès que l'on est en présence d'un agent composé qui contient de zéro à ncomposants, nous sommes confrontés au problème de la recherche du (ou des)composant(s) vérifiant une propriété particulière. La méthode généralement retenueconsiste pour l'agent composé à demander à tous les composants quel est celui quivérifie la propriété. La figure 21 présente le motif de conception associé.

Agent Composant

Agent Interactif

Facette Abstraction

Test_composant

Facette Abstraction

Test

Contrôle

Recherche


RechercheA1

A2

Figure 21. Recherche des composants vérifiant une propriété particulière

Pour illustrer cette figure, reprenons l'exemple Agenda et considérons qu'ilpropose un menu qui fait apparaître une boite de dialogue permettant de fixer descritères pour sélectionner des agents composants de l'agent principal (ex : les rendez-vous avec M. Dupond). Lorsque l'utilisateur déclenche l'action de recherche (ex : ilappuie sur un bouton), le port Recherche de la facette Présentation est activé.L'administrateur avec retour A1 active le port Recherche correspondant dans lafacette Abstraction car c'est elle qui gère la liste des composants. Le démon associéà ce port active alors itérativement le port Test_composant en filtrant l'activation afin


27

que chaque composant soit atteint. Grâce à l'administrateur A2, chaque composantvoit le port Test de sa facette Abstraction activé. Le démon associé teste si le critèretransmis dans le message est vérifié. Comme l'administrateur A2 est unadministrateur avec retour, la réponse (oui ou non) est retournée à la fonction derecherche qui compile les réponses de toutes les activations et retourne la réponsevia A1 à la facette Présentation.

Dans certains cas, comme la recherche du rendez-vous situé sous le pointeur dela souris dans l'exemple Agenda, il est nécessaire de mettre en œuvre un pattern unpeu plus complexe (figure 22). En effet, lorsque l'on veut modéliser la sélectiongraphique d'un composant, le critère recherché n'est pas uniquement lié à la facettePrésentation. Ainsi, lorsqu'un agent composé reçoit dans sa facette Présentation unesollicitation de l'utilisateur sous forme d'un click sur un bouton de la souris, il doitdéterminer l'agent composant se situant sous le pointeur de la souris. L'interlocuteurdu port Test_ composant est ici un port de la facette Présentation, car c'est elle quisait comment et où est représenté l'agent composant, bien qu'elle ait besoin de lafacette abstraction pour connaître les caractéristiques de l'agent (ex : durée durendez-vous).

Agent Composant

Agent Interactif

Facette Abstraction

Test_composant


Test

Contrôle

Recherche


Recherche

Facette Abstraction

Fournit_donnée Récup_donnée

Contrôle

A1

A2

A3

Figure 22. Recherche des composants vérifiant une propriété de présentation

4.2. Un générateur de squelette d'application

Le modèle d'architecture AMF est un méta-modèle générique qui est adapté à laconstruction automatique d'application. En effet, la modélisation rigoureuse desmécanismes de contrôle à partir de composants standards (administrateurs decontrôle et ports de communication) ainsi que le découpage fin des agents enfacettes permet d'envisager cette automatisation.


28

Actuellement, nous avons conçu le premier prototype d’un outil de construction(Builder) permettant de passer d'un schéma de conception à la génération d'unsquelette d'application.

Chaque agent ou facette du modèle défini graphiquement par le concepteurconduit à la définition automatique d'une classe C++ particulière héritant des classesde base de notre bibliothèque générique (Agent, Facette). Les constructeurs de cesnouvelles classes sont alors enrichis par les instructions de construction del'application : Ajoute_Facette, Ajoute_Port, etc. (cf. §3.6).

Une fois le squelette généré, le concepteur n'a plus qu'à écrire le corps desfonctions démons associés aux ports de communication et bien sûr à définir lesdonnées membres de chaque classe afin d'exprimer la sémantique de l'application.

Jusqu'à présent, la représentation graphique du modèle AMF offre une visionstructurelle. On peut ainsi faire apparaître toutes les facettes susceptibles d'êtreutilisées comme par exemple les différentes facettes Présentation correspondant àdifférents modes de visualisation. Il est cependant difficile de faire apparaître sur cemême schéma les évolutions dynamiques (substitution de facette, changement deconnexion des administrateurs, etc.). L'outil actuel ne prend pas encore en comptecet aspect évolutif de fonctionnement. Celui-ci doit être ajouté manuellement dans lecorps du programme, mais nous travaillons sur la formalisation de cette dynamique.

Nous étudions aussi comment intégrer à ce Builder un catalogue de designpatterns. En particulier nous sommes conscient de la double difficulté que constituele choix d'un pattern et l'adaptation de ce pattern à un contexte d'exploitationparticulier. Un effort tout particulier sera porté sur l'interface de sélection et de miseen œuvre des patterns.

Enfin, fortement intéressé par les générateurs d'applications interactives commele BDK (Bean Development Kit) de Java qui permet d'assembler des composantslogiciels interactifs, nous étudions comment notre Builder pourrait être couplé à unoutil de génération d'interface.

5. Conclusion

La conception de logiciels interactifs complexes nécessite l'utilisation d'unmodèle d'architecture présentant de bonnes caractéristiques d'expressivité et deréutilisabilité. En outre, pour être réellement intéressant, le modèle d'architecture nedoit pas se contenter d'être un bon support de la conception. Il doit aussi constituerun support de la mise en œuvre, c'est-à-dire être directement utilisable pourl'implémentation des logiciels. Enfin, nous souhaitons que le modèle d'architecturereflète également la structure et le comportement du logiciel afin qu'il puisse êtreutilisé comme guide en facilitant sa compréhension auprès des utilisateurs, voirecomme support de manipulation de l’architecture permettant ainsi des ajustementsdynamiques de l’interface homme-machine.

Selon nous, le modèle multi-agents AMF couvre ces trois champs d'utilisation etprésente des atouts majeurs vis-à-vis des autres modèles. En proposant un nombrede facettes variable pour chaque agent du système informatique modélisé, il permetde mettre en évidence des thématiques fonctionnelles particulières liées au domaine


29

d'application considéré. On peut donc décliner le modèle en versions spécifiques.Ainsi, dans le domaine des collecticiels (groupware), thème de rechercheparticulièrement développé au sein de notre laboratoire, cette propriété est très utilecar plusieurs facettes liées aux processus de coopération ont été identifiées pourdonner naissance au modèle AMF-C [TAR 98]. Dans le domaine des interfaceshomme-machine auto-adaptatives nous avons également identifié des facettesspécifiques chargées de la gestion du modèle de l'utilisateur et de la capture de sesinteractions. Nous avons appelé cette déclinaison AMF-I (pour Intelligent). Ledeuxième atout du modèle AMF est qu'il impose non seulement une explicitationdes services proposés par chaque agent mais aussi une explicitation des servicesnécessaires. Ce dernier point est particulièrement important si l'on veut encouragerla définition d'agents facilement réutilisables. Le troisième atout du modèle AMF estqu'il propose des éléments de modélisation du contrôle de l'interaction (ports decommunication et administrateurs de contrôle) qui permettent d'exprimer lesrelations entre les différents services proposés par les facettes des agents. Grâce àeux, le contrôle peut être modélisé de façon systématique. Il n'est plus un composant“fourre-tout”, mais un composant formalisable. On peut ainsi automatiserl'implémentation des applications à partir des modélisations graphiques AMF etenvisager des techniques de vérification automatique de la cohérence du système. Lequatrième atout du modèle AMF tient à la dynamicité qu'il introduit. Tout élémentdu modèle peut être créé, modifié ou supprimé à chaque instant. Les relations entreles ports de communication peuvent être modifiées et des facettes peuvent êtreinterchangées. Cette souplesse s'avère particulièrement utile dans le contextecoopératif où l'on sait que les rôles des participants et les vues qu'ils portent sur lesobjets modélisés sont amenés à évoluer régulièrement. En plus, nous pensons que,dans une certaine mesure, le formalisme est manipulable directement par l’utilisateurfinal qui pourra ainsi personnaliser son interaction avec le groupe.

Comme la plupart des modèles proposant un formalisme graphique, AMFprésente cependant le défaut de produire des schémas dont la taille pourrait rendredifficile l'exploitation dans un contexte d'envergure. En fait, ce défaut peut être trèslargement atténué selon deux procédés. Le premier consiste à considérer que lavisualisation d'un schéma global ne présente d'intérêt que si la granularité deséléments présentés n'est pas trop fine. Ainsi, le choix d'un niveau de visualisationdes agents (on ne représente pas les agents composants de certains agents composés)permet d'effectuer un filtrage des schémas AMF. La deuxième approche consiste àfaire des schémas partiels dans lesquels n'apparaissent que les éléments relatifs à unproblème donné. C'est cette approche que nous adoptons lorsque nous représentonsdes motifs de conception.

Aussi performant que soit un modèle d'architecture, il est indispensable defournir une méthodologie de conception adaptée pour pouvoir mettre en pratiqueles concepts proposés dans le cadre de logiciels complexes. Un premier pas danscette direction a été franchi dans [TAR 97a] à partir de l'analyse des expériences dedéveloppement déjà réalisées.

Enfin, pour pouvoir utiliser un modèle d'architecture comme support de mise enœuvre, il est nécessaire de proposer des outils de conception. La modélisation desfacettes de contrôle permet non seulement de concevoir des outils de manipulation


30

des schémas AMF, mais aussi d'automatiser la génération de squelettesd'application. En outre, l'expérience de modélisation acquise durant nos années derecherche nous a permis de constituer un catalogue de motifs de conception (designpatterns) contenant un certain nombre de solutions pouvant être apportées à desproblèmes récurrents dans la conception des logiciels. AMF constitue un bonexemple de framework [FAY 97] [JOH 97] car il se prête particulièrement bien à ladéfinition de patterns et à la réutilisation de composants logiciels. On peut imaginerque des ateliers de génie logiciel couplant à la fois des outils de constructionassociés à des bibliothèques de motifs de conception, et des systèmes de générationd'applications permettraient d'accroître encore la qualité et la vitesse dedéveloppement en encourageant la réutilisation de composants.

6. Remerciements

A Kamel Ouadou qui a construit les premières bases du modèle AMF, ainsi qu’àtous les membres du GDR-PRC CHM qui ont manifesté de l’intérêt pour notretravail et dont les remarques nous ont permis d’améliorer notre modèle.

7. Bibliographie

[ALL 97] ALLEN R., GARLAN D., « A Formal Basis for Architectural Connection », ACMTransactions on Software Engineering, vol. 7, n° 3, July 1997.

[COU 87] COUTAZ J., « PAC, an Implementation Model for Dialog Design », Proceedings ofInteract'87, Stuttgart, 431-436, 1987.

[COU 90] COUTAZ J., « Architecture Models for interactive software: Failures and Trends »,in Engineering for Human-Computer Interaction, G. Cockton Ed., Elsevier Science Publ.,137-153, 1990.

[DAV 91] DAVID B.T., OUADOU K., SADOU S. VIAL C., « A Framework for intelligent userinterfaces, Proceedings of OZCHI’91, Sydney, Australie, 27-29 novembre 1991.

[ENG 97] ENGLANDER R., JAVA Beans - Guide du programmeur, O'Reilly, Paris, 1997.

[FAY 97] FAYAD M.E., SCHMIDT D.C., « Object-Oriented Application Frameworks »,Communications of the ACM, Oct., vol. 40, n° 10, 32-38, 1997.

[FER 95] FERBER J., Les systèmes Multi-agents : vers une intelligence collective,Interéditions, 1995.

[FER 98] FERBER J., GUTKNECHT O., « Aalaadin: a meta-model for the analysis and design oforganizations in multi-agent systems », ICMAS'98, 1998.

[GAM 95] GAMMA E., HELM R., JOHNSON R., VLISSIDES J., Design Patterns : Elements ofReusable Object-Oriented Software, Addison Wesley, Reading, MA. 1995.

[GAR 95] GARLAN D., PERRY D., « Introduction to the Special Issue on SoftwareArchitecture », IEEE Transactions on Software Engineering, April 1995.


31

[GOL 84] GOLDBERG A., Smalltalk-80: The interactive programming environment, Addison-Wesley Publ., 1984.

[GRE 85] GREEN M.W., « The design of graphical interfaces », PhD, Tech. report CSRI-170,Computer Systems Research Institute, University of Toronto, Canada, 1985.

[HAR 89] HARTSON H.R. & D. HIX, « Human-computer interface development : concepts andsystems for its management », ACM Computing Surveys, vol. 21, n° 1, March 1989.

[HIL 90] HILL R., HERMANN M., « Abstraction and declarativeness in user interfacedevelopment - the methodological basis of composite object architecture », Engineeringthe human-interface, North-Holland, March 1990.

[JOH 97] JOHNSON R.E., « Frameworks = Components + Patterns », Communications of theACM, Oct., vol 40, n° 10, 39-42, 1997.

[KAZ 93] KAZMAN R., BASS L. & al., « Analyzing the properties of user interface software »,Technical report CMU-CS-93-201, School of Computer Science, Carnegie MellonUniversity, 1993.

[MAG 94] MAGNAN M., « Réutilisation de composants : les exceptions dans les objetscomposites », Thèse de doctorat, Université de Montpellier II, 1994.

[NIG 93] NIGAY L., COUTAZ J., « A Design Space for Multimodal Systems: ConcurrentProcessing and Data Fusion », Proceedings of InterCHI'93, Amsterdam, 172-178, 1993.

[OUA 94] OUADOU K., « AMF : Un modèle d'architecture multi-agents multi-facettes pourInterfaces Homme-Machine et les outils associés », Thèse de doctorat, Ecole Centrale deLyon, 1994.

[OUS 97] OUSSALAH C., Ingénierie objet : Objets, techniques, concepts, Interéditions, 1997.

[PFA 85] PFAFF G.E., ed. User Interface Management Systems, Eurographics Seminars,Springer-Verlag, New-York, 1985.

[PRE 98] PREE W., Design Patterns et Architectures logicielles, Vuibert Informatique, 1998.

[POQ 98] POQUET J., « Architecture AMF des systèmes interactifs : Conception d'un moteurde gestion d'interactions en Java », Mémoire de DEA, Ecole Centrale de Lyon, 1998.

[RUM 95] RUMBAUGH J. & al., OMT Modélisation et conception orientée objet, Masson Eds,Prentice Hall, 1995.

[SIB 86] SIBERT J.L., HURLEY W.D., BLESER T.W., « An object-oriented user interfacemanagement system, proceedings of SIGGRAPH'86, August 1986.

[SIE 96] SIEGEL J., CORBA - Fundamentals and Programming, John Wiley Eds,1996.

[TAR 97a] TARPIN-BERNARD F., « Travail coopératif synchrone assisté par ordinateur :Approche AMF-C », Thèse de doctorat, Ecole Centrale de Lyon, 1997.

[TAR 97b] TARPIN-BERNARD F., DAVID B.T., « AMF : a new design pattern for complexinteractive software ? », proceedings of International HCI’97, San Francisco, 351-354,1997.


32

[TAR 97c] TARPIN-BERNARD F., DAVID B.T., « Expression and Recognition of DesignIntentions - The contributions of multimodality », Integrated Design and Manufacturingin Mechanical Engineering, Eds Chedmail & al., Kluwers, 1997, 113-120.

[TAR 98] TARPIN-BERNARD F., DAVID B.T., PRIMET P., « Frameworks and patterns forsynchronous groupware : AMF-C approach », EHCI'98, IFIP Working Conference onEngineering for HCI, Greece, Sept. 1998 , 13 pages.

Franck Tarpin-Bernard est ingénieur et docteur de l'Ecole Centrale de Lyon en ingénierieinformatique. Il est actuellement maître de conférences en informatique à l'Institut Nationaldes Sciences Appliquées de Lyon. Ses activités de recherche concernent l'interaction homme-machine et le génie logiciel. Son domaine d'étude privilégié est le travail coopératif assistépar ordinateur.

Bertrand David est professeur des universités de l'Ecole Centrale de Lyon en informatique. Ilest co-directeur du laboratoire GRACIMP. Ses activités de recherche portent sur l'interactionhomme-machine et sur le travail coopératif avec comme principaux domaines d'applicationsl'ingénierie concourante et l'enseignement coopératif à distance.

Documents

AMF : un modèle d'architecture multi-agents multi …pascal.joyeux.free.fr/PROBATOIRE/GenerationAutomatique...AMF : des Agents Multi-Facettes 5 5 C'est ce choix d'homogénéité qui