Thèse Doctorat - Approche Dirigée Par Les Modèles

THSE DE lUNIVERSIT DE SAVOIE
Spcialit : Informatique
prsente par
Selma AZAIEZ
pour obtenir le titre de
DOCTEUR DE LUNIVERSIT DE SAVOIE

(Arrt ministriel du 30 Mars 1992)
Approche dirige par les modles pour le dveloppement de systmes multi-agents
Soutenance prvue le 11 dcembre 2007 devant le jury compos de : Mme M. M. M. M. M. Nicole Levy Juan Pavon Mestras Yves Demazeau Vincent David Flavio Oquendo Marc-Philippe Huget Rapporteur Rapporteur Examinateur Membre Invit Directeur de thse Co-encadrant
A mon cher pre, il aurait t si er
Remerciements
Jadresse mes plus vifs remerciements M. Juan PAVON MESTRAS, Professeur lUniversidad Complutense de Madrid et Mme. Nicoles LEVY, Professeur lUniversit de Versailles Saint Quentin en Yvelines pour mavoir fait lhonneur dtudier mes travaux de thse et pour les avoir cautionns en qualit de rapporteurs. Je tiens galement remercier M.Yves DEMAZEAU, Directeur de Recherche au Laboratoire dInformatique de Grenoble (LIG) qui ma fait lhonneur de prsider le jury, ainsi que M. Vincent DAVID, Ingnieur Chercheur au CEA/Saclay pour avoir accept de faire partie de ce jury. Je tiens exprimer toute ma gratitude M. Flavio OQUENDO, Professeur lUniversit de Bretagne Sud, pour mavoir donn la possibilit deectuer cette thse et pour mavoir intgr dans le projet ArchWare qui a constitu une exprience professionnelle trs riche. Je tiens aussi le remercier pour ses nombreux conseils durant mes travaux de thse et la prparation de la soutenance. Je tiens galement remercier M. Marc-Philippe HUGET, Matre de Confrences lUniversit de Savoie, pour avoir accept de co-encadrer cette thse et pour avoir contribuer son aboutissement en apportant ses comptences dans le domaine des systmes multi-agents. Mes sincres remerciements vont Georges HABCHI, Magali PRALUS et Jihne TOUNSI pour leur travail collaboratif durant le projet BQR qui ma permise de valider mon approche. Je remercie galement Philippe BOLON et Patrice MOREAUX pour mavoir donn loccasion de naliser ma thse dans des conditions convenables. Un grand merci particulier mes amis et collgues de lex-quipe LLP. Je nomme particulirement Sorana CIMPAN, Ilham ALLOUI, Georges HABCHI, Herv VERJUS, Frdric POURRAZ, Lionel BLANC DIT JOLICOEUR et Fabien LEYMONERIE. Leurs nombreux encouragements, conseils ainsi que les nombreuses discussions ont t essentielles pour laboutissement de ces travaux. Un grand merci particulier Valrie BRAESCH pour sa bonne humeur, son dynamisme et la relecture de ce mmoire de thse. Enn, je remercie de tout mon coeur tous mes proches et amis et plus particulirement ma mre Nouayra et mon frre Ahmed pour leur conance, leur soutien et leur aide inconditionnels ainsi que leur prsence inestimable mes cots durant toute la dure de cette thse. Merci vous, je ny serais pas arriv sans vous ! 5
Table des matires

1 Introduction gnrale 1 Contexte et problmatique . . . . . . . . . . . . . . . . . . . . 2 Une dmarche de dveloppement exible et sre . . . . . . . . 3 Organisation du document . . . . . . . . . . . . . . . . . . . . 2 Etude du domaine 1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2 Paradigmes de dveloppement vs Ingnierie des systmes logiciels . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.1 Les paradigmes de dveloppement . . . . . . . . . . . 2.2 Les techniques dingnierie . . . . . . . . . . . . . . . . 3 Lvolution des paradigmes de dveloppement . . . . . . . . . 3.1 Le paradigme procdural . . . . . . . . . . . . . . . . . 3.2 Le paradigme orient objet . . . . . . . . . . . . . . . 3.3 Le paradigme orient composant . . . . . . . . . . . . 3.4 Le paradigme orient service . . . . . . . . . . . . . . 4 Positionnement du paradigme orient agent . . . . . . . . . . 4.1 Les problmatiques traites par le paradigme orient agent . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.2 Les freins lutilisation des systmes multi-agents . . 5 Lvolution des techniques dingnierie . . . . . . . . . . . . . 5.1 Les techniques dingnieries classiques . . . . . . . . . 5.2 Lingnierie des systmes bass sur le paradigme orient composant . . . . . . . . . . . . . . . . . . . . . . . . . 5.3 Lingnierie dirige par les modles . . . . . . . . . . . 5.4 Conclusions relatives lvolution des techniques dingnierie . . . . . . . . . . . . . . . . . . . . . . . . . . 6 Introduction la problmatiques de la thse . . . . . . . . . . 1 2 4 5 7 8 9 9 10 10 11 11 11 12 13 14 16 17 17 19 22 23 24
3 Ingnierie des Systmes Multi-agents 27 1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28 2 Les thories orientes agent . . . . . . . . . . . . . . . . . . . 29 2.1 La vue agent . . . . . . . . . . . . . . . . . . . . . . . 29
TABLE DES MATIRES 2.2 La vue environnement . . . . . . . . . . . . . . . . . . 2.3 La vue interaction . . . . . . . . . . . . . . . . . . . . 2.4 La vue organisation . . . . . . . . . . . . . . . . . . . Ingnierie des systmes informatiques selon le paradigme orient agent . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.1 Les langages de spcication . . . . . . . . . . . . . . . 3.2 Les mthodologies de dveloppement . . . . . . . . . . 3.3 Les plates-formes dimplmentation . . . . . . . . . . . Les langages de spcication orients agent . . . . . . . . . . 4.1 Les langages bass sur une extension dUML . . . . . . 4.2 Les langages raliss par cration de prol UML . . . . 4.3 Les notations graphiques . . . . . . . . . . . . . . . . . Les mthodologies orientes Agent . . . . . . . . . . . . . . . 5.1 La mthodologie ADELFE . . . . . . . . . . . . . . . 5.2 La mthodologie Gaia . . . . . . . . . . . . . . . . . . 5.3 La mthodologie Ingenias . . . . . . . . . . . . . . . . 5.4 La mthodologie PASSI . . . . . . . . . . . . . . . . . 5.5 La mthodologie Tropos . . . . . . . . . . . . . . . . . 5.6 Comparaison . . . . . . . . . . . . . . . . . . . . . . . 5.7 Unication des mtamodles . . . . . . . . . . . . . . . Les plates-formes orientes Agent . . . . . . . . . . . . . . . . 6.1 La plate-forme ZEUS . . . . . . . . . . . . . . . . . . . 6.2 La plate-forme JADE . . . . . . . . . . . . . . . . . . 6.3 La plate-forme MADKIT . . . . . . . . . . . . . . . . 6.4 La plate-forme AgentBuilder . . . . . . . . . . . . . . Analyse et conclusion . . . . . . . . . . . . . . . . . . . . . . 35 36 39 43 43 44 46 46 46 47 48 49 52 59 64 69 73 76 77 78 78 79 80 81 82 85 86 87 89 90 90 93 95 97 100 102 102 103 104 106 ii
4 Vers un dveloppement exible et sr 1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2 Problmatique et objectifs de la thse . . . . . . . . . . . . . 3 Le dveloppement dirig par les modles . . . . . . . . . . . . 3.1 Principes de lapproche . . . . . . . . . . . . . . . . . 3.2 Les quatre niveaux de OMG . . . . . . . . . . . . . . . 3.3 Les relations entre les modles . . . . . . . . . . . . . 3.4 La transformation de modles . . . . . . . . . . . . . . 3.5 Processus de dveloppement orient modles . . . . . . 3.6 Apports potentiels de lapproche oriente modles dans lingnierie des systmes multi-agents . . . . . . . . . . 4 Le dveloppement orient architecture . . . . . . . . . . . . . 4.1 Dnition dune architecture logicielle . . . . . . . . . 4.2 Mettre en uvre lapproche oriente architecture . . . 4.3 Processus de conception orient architecture . . . . . . 4.4 La notion de style architectural . . . . . . . . . . . . .
TABLE DES MATIRES 4.5 5 6 Apports potentiels de lapproche oriente architecture dans lingnierie des systmes multi-agents . . . . . . . 108 Combinaison des deux approches . . . . . . . . . . . . . . . . 108 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111 113 114 114 115 119 120 121 126 130 131 132 133 135 135 137 138 141 141 143 148 149 151 152 153 154 155 155 156 158 158 162 162
5 Lapproche ArchMDE 1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2 Lapproche ArchMDE . . . . . . . . . . . . . . . . . . . . . . 2.1 Les modles considrs . . . . . . . . . . . . . . . . . . 2.2 Le cycle de dveloppement ArchMDE . . . . . . . . . 3 Application du cycle de dveloppement ArchMDE . . . . . . 3.1 Construction du cadre de dveloppement par les experts de mtamodlisation . . . . . . . . . . . . . . . . 3.2 Utilisation du cadre de dveloppement par les dveloppeurs . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.3 Les besoins relatifs la mise en uvre de lapproche . 4 Lenvironnement ArchWare . . . . . . . . . . . . . . . . . . . 5 Les langages ArchWare . . . . . . . . . . . . . . . . . . . . . . 5.1 Le langage ArchWare ADL ( -ADL) . . . . . . . . . . 5.2 Le langage AAL . . . . . . . . . . . . . . . . . . . . . 5.3 Le langage ArchWare ASL . . . . . . . . . . . . . . . . 5.4 Le langage ArchWare ARL . . . . . . . . . . . . . . . 6 Les outils ArchWare . . . . . . . . . . . . . . . . . . . . . . . 7 Formalisation du mtamodle du domaine . . . . . . . . . . . 7.1 dataEntity . . . . . . . . . . . . . . . . . . . . . . . . . 7.2 taskEntity . . . . . . . . . . . . . . . . . . . . . . . . . 7.3 activeEntity . . . . . . . . . . . . . . . . . . . . . . . . 7.4 structureEntity . . . . . . . . . . . . . . . . . . . . . . 8 Le mtamodle orient agent . . . . . . . . . . . . . . . . . . 8.1 Formalisation du style agent ractif . . . . . . . . . . . 8.2 Dnition dune syntaxe . . . . . . . . . . . . . . . . . 8.3 Proprits dun agent ractif . . . . . . . . . . . . . . 9 Le processus dagentication . . . . . . . . . . . . . . . . . . . 9.1 Extension du langage ARL . . . . . . . . . . . . . . . 9.2 Le tissage des mtamodles . . . . . . . . . . . . . . . 10 Gnration de larchitecture . . . . . . . . . . . . . . . . . . . 11 Validation des proprits . . . . . . . . . . . . . . . . . . . . . 12 Gnration du code . . . . . . . . . . . . . . . . . . . . . . . . 13 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6 Validation de lapproche ArchMDE - Agentication dun systme de production 167 1 Prsentation du projet . . . . . . . . . . . . . . . . . . . . . . 168 2 Les systmes de production . . . . . . . . . . . . . . . . . . . 169 iii
TABLE DES MATIRES 3 Mtamodlisation dun SdP . . . . . . . . . . . . . . . . 3.1 LEntit Circulante (EC) . . . . . . . . . . . . . 3.2 Le Systme de Transformation du Produit (STP) 3.3 Le Centre de Pilotage . . . . . . . . . . . . . . . Agentication du systme de production . . . . . . . . . 4.1 La ressource EC . . . . . . . . . . . . . . . . . . 4.2 Les agents hybrides STP-Stock et STP-Machine . 4.3 Agentication des autres lments du SdP . . . . Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 171 171 172 178 182 183 184 189 191 193 194 196 196 197 197 199 200 203 204 205 210 212 212 213 213 215 217 217 218 218 219 220 221 223
7 Conclusions et Perspectives 1 Rappel de la problmatique . . . . . . . . . . . . 2 Contributions . . . . . . . . . . . . . . . . . . . . 2.1 Apports de lapproche IDM . . . . . . . . 2.2 Apports de lapproche centre architecture 2.3 Apports de la dmarche ArchMDE . . . . 2.4 Bilan . . . . . . . . . . . . . . . . . . . . . 3 Perspectives . . . . . . . . . . . . . . . . . . . . . A Description des langages ArchWare 1 Le langage ArchWare ADL . . . . . . . . . . 1.1 Comportement . . . . . . . . . . . . . 1.2 Les valeurs et les types . . . . . . . . . 2 Le langage ArchWare AAL . . . . . . . . . . 2.1 Les oprateurs et les quantieurs . . . 2.2 Prdicats et fonctions sur les donnes . 2.3 Prdicats sur les comportements . . . 3 Le langage ArchWare ARL . . . . . . . . . . 4 Le langage ArchWare ASL . . . . . . . . . . 4.1 description gnrale dun style . . . . . 4.2 Types . . . . . . . . . . . . . . . . . . 4.3 Styles . . . . . . . . . . . . . . . . . . 4.4 Les constructeurs . . . . . . . . . . . . 4.5 Les contraintes . . . . . . . . . . . . . 4.6 Les analyses . . . . . . . . . . . . . . . Bibliographie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
iv
Table des gures

2.1 2.2 2.3 3.1 3.2 3.3 3.4 3.5 3.6 3.7 3.8 3.9 3.10 3.11 3.12 3.13 3.14 3.15 3.16 3.17 3.18 3.19 3.20 3.21 3.22 4.1 4.2 4.3 4.4 4.5 4.6 La couche integiciel . . . . . . . . . . . . . . . . . . . . . . . . Le processus centr architecture . . . . . . . . . . . . . . . . . Lvolution de dveloppement des systmes informatiques . . Larchitecture de Brooks . . . . . . . . . . . Larchitecture MANTA [DCF95] . . . . . . Rduction de la charge des rseaux . . . . . Topologie structure hirarchique . . . . . Topologie structure de march . . . . . . . Topologie structure de communaut . . . Topologie structure de socit . . . . . . . Les branchements dnis dans AUML . . . Une classication des mthodologies . . . . Le mtamodle dADELFE . . . . . . . . . Le processus ADELFE . . . . . . . . . . . . Le mtamodle Gaia . . . . . . . . . . . . . Exemple de modle de rle [ZJW03] . . . . Exemple de modle dinteraction [ZJW03] . Le processus de dveloppement Gaia . . . . Un mtamodle Ingenias rsum [CBP05] . Un rsume du mtamodle Ingenias [Pav06] Le mtamodle PASSI [CBP05] . . . . . . . Le processus PASSI [CP01] . . . . . . . . . Le mtamodle Tropos . . . . . . . . . . . . Le mtamodle uni [CBP05] . . . . . . . . Le mtamodle AALAADIN . . . . . . . . . Les quatre niveaux de MDA La relation [BBB+ 05] . . La relation . . . . . . . . Migration de modle objet Le cycle de vie de MDA . . Le cycle de vie en Y . . . . . . . . . . un . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 20 24 32 33 35 40 41 41 41 47 51 54 58 60 61 62 63 65 67 70 72 73 77 81 92 93 94 97 98 99
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . modle relationnel . . . . . . . . . . . . . . . . . . . . . .
TABLE DES FIGURES 4.7 4.8 4.9 5.1 5.2 5.3 5.4 5.5 5.6 5.7 5.8 5.9 5.10 5.11 5.12 5.13 5.14 5.15 5.16 5.17 6.1 6.2 6.3 6.4 6.5 Un exemple de table de mapping PDM/PIM . . . . . . . . . . 100 Le processus centr architecture . . . . . . . . . . . . . . . . . 105 Le processus centr architecture [Ley04] . . . . . . . . . . . . 107 Arbres de drivation dune expression arithmtique La couche modle . . . . . . . . . . . . . . . . . . . Le processus de dveloppement ArchMDE . . . . . Dnition des rgles de transformation . . . . . . . Un mtamodle Orient Agent . . . . . . . . . . . La phase danalyse . . . . . . . . . . . . . . . . . . Application des rgles de transformation . . . . . . Le langage ASL . . . . . . . . . . . . . . . . . . . . Le langage ARL . . . . . . . . . . . . . . . . . . . . Le processus de vrication eectu par Analyser . Le code ASL de dataEntity . . . . . . . . . . . . . Mtamodle dAgent Ractif . . . . . . . . . . . . . Agentication dune activeEntity en agentReactif . Processus de gnration darchitecture . . . . . . . Gnration dun capteur dans un agent ractif . . . Vrication des proprits . . . . . . . . . . . . . . Vrication de linterblocage . . . . . . . . . . . . . Modle de Systme de Production . . . . . Les trois fonctions fondamentales dun STP Modle du CP . . . . . . . . . . . . . . . . . Le comportement du CP . . . . . . . . . . . Communication entre STP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 116 119 121 123 124 128 129 136 138 140 142 152 157 159 160 161 162 170 172 179 181 188
vi
Liste des tableaux

3.1 3.2 3.3 4.1 4.2 4.3 5.1 5.2 6.1 La notation AUML . . . . . . . . . . . . . . . . . . . . . . . . Les concepts manipuls par AORML . . . . . . . . . . . . . . Les concepts manipuls par OPM/MAS . . . . . . . . . . . . 48 49 50
Les apports relatifs lapplication de lapproche IDM dans le contexte multi-agents . . . . . . . . . . . . . . . . . . . . . . . 101 Les apports relatifs lapplication de lapproche centre architecture dans le contexte multi-agents . . . . . . . . . . . . 109 Combinaison de lapproche IDM et lapproche centre architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110 Mapping entre mtamodle du domaine et mtamodle orient agent . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 125 Mapping entre architecture en -ADL et code Java . . . . . . 163 Agentication de lAgent-CP . . . . . . . . . . . . . . . . . . 190
Chapitre 1 Introduction gnrale
CHAPITRE 1. INTRODUCTION GNRALE
Contexte et problmatique
Les systmes multi-agents constituent aujourdhui une nouvelle technologie pour la conception et le contrle de systmes complexes. Les solutions proposes par les systmes multi-agents sont prometteuses et permettent dobtenir des systmes exibles et volutifs. Cependant, leur mise en oeuvre reste dicile. Ceci est d au manque de standardisation des techniques dingnierie adaptes ce genre de systme et qui permettent un dveloppement able et cohrent. Le cadre gnral de cette thse est lingnierie des systmes multi-agents. Nous nous proposons dtudier les dirents moyens mis la disposition des dveloppeurs pour construire des applications bases sur lapproche oriente agent. Au niveau de ltat de lart, nous avons recens direntes techniques dingnierie. Ainsi, nous distinguons : les mthodologies orientes agents qui fournissent un cadre conceptuel et mthodologique visant guider les dveloppeurs des systmes multi-agents. Ces mthodologies structurent le processus dingnierie des systmes multi-agents en proposant direntes activits qui doivent tre menes lors du dveloppement de ces systmes. Certaines de ces mthodologies fournissent des notations adquates permettant de spcier les applications orientes agent. Elles fournissent aussi des outils supportant lapplication de ces notations direntes phases du cycle de dveloppement, les langages de modlisation orients agents qui tudient les direntes 2
CHAPITRE 1. INTRODUCTION GNRALE notations pouvant tre utilises pour modliser les systmes multiagents. Ces langages sont soit bass sur la notation UML, soit composs dun ensemble de notations graphiques. Certains parmi ces langages sont incorpors dans des mthodologies, les plates-formes orientes agents qui sont des supports daide la programmation. Elles fournissent une couche dabstraction permettant de faciliter limplmentation des concepts orients agents. Ltude des mthodologies, notations et plates-formes orientes agent ont fait ressortir plusieurs limites qui peuvent expliquer les dicults des systmes multi-agents percer dans le monde industriel. Ces limites sont essentiellement lies la diversit et parfois lambigut qui entoure les concepts orients agents. En eet, ces concepts sont abords diremment au niveau de chaque mthodologie, notation et plate-forme oriente agents. Cette ambigut rend dicile la comprhension de la smantique de ces concepts ainsi que leur application concrte. De plus, nous avons not que ces techniques dingnierie ne couvrent quune vue partielle des systmes multi-agents. De la mme manire, les mthodologies existantes ne considrent que certains aspects du cycle de vie (gnralement lanalyse et la conception). La phase dimplmentation est, quant elle, aborde par les plates-formes de dveloppement. Cependant, un large foss spare les phases danalyse/conception de la phase dimplmentation. Ce foss est dautant plus creus par lambigut relative aux concepts puisque la smantique adopte au niveau de la mthodologie est gnralement dirente de celle applique au niveau de la plate-forme dimplmentation. Nous avons galement constat que la plupart des mthodologies sont bases sur lapproche oriente objet. Cependant, cette approche nest pas bien adapte car elle a un bas niveau dabstraction par rapport aux concepts orients agents et risque dengendrer des systmes fortement coupls puisque lingnierie des systmes orients objet se base gnralement sur la desciption des invocations de mthodes [ZJW03]. Enn, trs peu doutils sont fournis pour aider le dveloppeur dans les direntes phases du cycle de vie. Pour pallier ces limites, nous avons tudi les direntes avances faites dans le domaine du gnie logiciel pour aborder lingnierie des systmes complexes bass sur des concepts ayant un haut niveau dabstraction et composs dlments ayant une forte interaction. Nous avons retenu deux techniques dingnierie ddies des niveaux dabstraction levs : lapproche centre architecture qui se concentre sur lorganisation des lments qui composent le systme. Larchitecture ore une vue globale du systme qui est lisible et qui expose les proprits les plus cruciales ; ce qui permet un dveloppement ecace. lapproche dirige par les modles (ou IDM) qui conoit lintgralit 3
CHAPITRE 1. INTRODUCTION GNRALE du cycle de vie comme un processus de production, de ranement itratif et dintgration de modles. Lutilisation des modles permet de capitaliser les connaissances et le savoir-faire dirents niveaux dabstraction quelles soient des connaissances du domaine mtier ou du domaine technique. Nous proposons dans cette thse une dmarche de dveloppement base sur la combinaison de ces deux approches an dadresser les dirents aspects de dveloppement des systmes multi-agents.
Une dmarche de dveloppement exible et sre
Bien quil existe plusieurs propositions intressantes aussi bien au niveau des mthodologies, des langages de spcication et des plates-formes dimplmentation, ces direntes propositions manquent de cohsion et font ressortir plusieurs dirences aussi bien au niveau de la smantique des concept utiliss mais aussi au niveau des dmarches de dveloppement. Notre but durant cette thse a t de proposer un cadre de dveloppement exible (prenant en compte la diversit des concepts orients agent) et cohrent (conservant la smantique des concepts tout au long du cycle de dveloppement) se basant sur une combinaison de lapproche centre architecture et de lapproche dirige par les modles. Lapproche centre architecture nous permet de raisonner sur les lments qui structurent le systme multiagents ainsi que leurs interactions. Notre but en appliquant cette approche est didentier les patrons architecturaux ncessaires au dveloppement des systmes multi-agents en prenant en compte les direntes vues du systme (vue organisationnelle, vue environnementale, etc.). Lapproche oriente modles nous permet dexprimer de faon explicite la manire de combiner ces patrons architecturaux an davoir une reprsentation globale du systme multi-agents. Dautre part, IDM permet de couvrir les direntes phases du cycle de dveloppement en adoptant une dmarche base sur la transformation de modles. Cette dmarche permet de garantir la cohrence du systme durant les direntes phases du cycle de vie. Par ailleurs, celle-ci ore lavantage de prserver le savoir-faire des dveloppeurs en exprimant explicitement les oprations dintgration (entre les patrons architecturaux) et de mapping (entre les modles de conception et les modles dimplmentation). Pour appliquer notre approche, nous utilisons un cadre de dveloppement formel. Le choix dun cadre formel vise rduire lambigut lie aux concepts multi-agents mais aussi garantir une conception sre an de produire des logiciels de qualit. Ainsi, lutilisation dun langage formel donne la possibilit dexprimer explicitement direntes proprits. Les outils accompagnant ce langage permettent de vrier et valider ces proprits. 4
Nous adoptons au cours de cette thse, le cadre de dveloppement ArchWare qui est bas sur le -calcul typ, polyadique et dordre suprieur [Mil99], ce qui permet de supporter les aspects communicatifs et volutifs des systmes multi-agents. Celui-ci ore dirents langages, que nous allons utiliser pour spcier les systmes multi-agents. Ces langages sont accompagns de dirents outils qui nous seront utiles pour mettre en uvre notre approche.
Organisation du document
Le suite de ce document est organise en cinq chapitres, qui sont organiss comme suit : Chapitre 2 : ce chapitre situe le cadre gnral de la thse. Nous distingons au niveau de ce chapitre la notion de paradigme de dveloppement et celle de techniques dingnierie. La premire partie de ce chapitre introduira les systmes multi-agents et les positionne par rapport aux paradigmes de dveloppement classiques. Au niveau de la deuxime partie, ce chapitre dcrit lvolution des techniques dingnierie. Cette description nous a permis de reprer les techniques dingnierie les plus adaptes au dveloppement des systmes multi-agents. Chapitre 3 : dans ce chapitre, nous passons en revue les dirents langages de modlisation, mthodologies et plates-formes dimplmentation proposs dans le domaine des systmes mult-agents. A la n de ce chapitre, nous analyserons les avantages et les inconvnients de ces direntes techniques et nous introduirons les besoins lis lingnierie des systmes multi-agents. Chapitre 4 : la premire partie de ce chapitre sera consacre une dcription dtaille de la problmatique et des objectifs de la thse. Par la suite, nous dcrirons et justierons notre approche base sur la combinaison de lapproche oriente architecture et de lapproche dirige par les modles. Chapitre 5 : ce chapitre dcrira la mise en uvre de notre approche que nous baptisons ArchMDE. La mise en uvre sera dabord dcrite de manire gnrique, par la suite de manire plus spcique en adoptant lenvironnement ArchWare. Chapitre 6 : dans ce chapitre nous validons lutilisation de ArchMDE en lappliquant dans le cadre dun projet BQR [HHP+ 07]. Ce projet tudie une nouvelle approche base sur les systmes multi-agents pour la simulation et le pilotage des systmes de production. Nous utilisons notre approche ArchMDE pour concevoir un simulateur des systmes de production appliquant le paradigme orient agent.
Chapitre 2 Etude du domaine
CHAPITRE 2. ETUDE DU DOMAINE
Introduction
De nos jours, les applications informatiques sont de plus en plus complexes et diciles raliser. Pour cette raison leur production doit tre de plus en plus assiste et rigoureuse. Le gnie logiciel est une discipline qui traite de la production et de la maintenance des logiciels. Elle a connu une grande volution depuis lapparition de linformatique. Au niveau de cette discipline, des rexions sont menes sur : la philosophie adopter pour reprsenter les objets du monde rel sous une forme virtuelle. Cette philosophie est introduite par les paradigmes de dveloppement, les cadres mthodologiques et techniques permettant de guider le dveloppeur durant les direntes phases de production du logiciel. Nous appelons ces cadres techniques dingnierie. Les techniques dingnierie sont direntes selon les paradigmes de dveloppement appliqus. Dans le cadre de cette thse, notre but est didentier les techniques dingnierie les plus adaptes aux paradigmes orients agent ainsi que la manire de les appliquer. An dviter toutes confusions, nous allons claircir dans ce chapitre la notion de paradigme de dveloppement et celle de technique dingnierie. Nous positionnons, par la suite, le paradigme orient agent par rapport aux paradigmes de dveloppement classiques. Nous tudierons enn, lvolution des techniques dingnierie qui a accompagn celles des paradigmes de d8
CHAPITRE 2. ETUDE DU DOMAINE veloppement. Cette tude nous permettra didentier les techniques les plus appropries pour appliquer le paradigme orient agent.
Paradigmes de dveloppement vs Ingnierie des systmes logiciels
La notion de paradigme de dveloppement et dingnierie de systmes sont intimement lies. Pendant que lun dnit la philosophie gnrale applique tout au long du cycle de vie an de reprsenter les objets du monde rel ; lautre dnit les techniques utiliser an dappliquer ces paradigmes. Nous clarions ces notions dans ce qui suit.
2.1
Les paradigmes de dveloppement
Ds lapparition des premiers ordinateurs, la fastidieuse entreprise dcrire des instructions et des donnes sous forme binaire, a fait natre le besoin davoir un langage intermdiaire, facile utiliser par lhomme et traduisible en langage machine. Depuis lors, plusieurs langages sont apparus, permettant de sabstraire de plus en plus de la structure matrielle et amliorant le pouvoir expressif. Ces langages appliquent des concepts introduits par les paradigmes de dveloppement. Un paradigme est un mode de pense qui permet de structurer nos connaissances, notre apprentissage et notre comprhension. Dans le contexte informatique, un paradigme de dveloppement est une manire de reprsenter le monde dans le but de concevoir un programme informatique. Depuis lapparition de linformatique, plusieurs paradigmes ont t adopts (paradigme procdural, paradigme orient objet, etc.). Chaque paradigme identie une classe de problmes et fournit des techniques permettant de traiter ces problmes. Par exemple, le problme trait par le paradigme procdural tait de sparer la reprsentation des donnes du traitement qui va tre eectu. An de rgler ce problme, ce paradigme introduit un ensemble de concepts. Ceux-ci permettent de structurer les programmes informatiques. Les concepts reprsentent des entits dnotes par un terme dans le langage et dont la smantique permettra de dcrire une partie de la philosophie introduite par le paradigme de dveloppement. Pour claircir ce point, prenons lexemple du paradigme procdural. Sparer la reprsentation des donnes des traitements qui vont tre eectus, ont men lintroduction des concepts de structure de donnes (pour reprsenter des donnes) et de procdures, fonction (pour reprsenter les traitement de donnes). Ces concepts ont t par la suite implants dans divers langage de 9
CHAPITRE 2. ETUDE DU DOMAINE programmation tel que Pascal, FORTRAN, C, etc.
2.2
Les techniques dingnierie
Les techniques dingnierie englobent les dirents moyens mis la disposition des dveloppeurs an de faciliter lapplication des paradigmes. Une bonne application des paradigmes est conditionne par le dveloppement de techniques dingnierie appropries fournissant des cadres conceptuels, technologiques et mthodologiques qui guident le dveloppeur lors des activits de dveloppement. Le dveloppement dune application informatique quelle quelle soit ncessite lapplication de direntes activits allant de la collecte et lanalyse des besoins jusquau dploiement et la maintenance du systme. Pour guider les dveloppeurs lors de ces activits, des mthodologies sont proposes. Booch dnie une mthodologie comme "un ensemble de mthodes appliques tout au long du cycle de dveloppement dun logiciel, ces mthodes tant unies par une certaine approche philosophique gnrale" [Boo92]. Lapproche philosophique gnrale est dnie par les paradigmes de dveloppement. Les mthodes quant elles dnissent la manire dappliquer cette approche en fournissant des notations et des modles permettant dexprimer les spcications relatives chaque activit (modle des besoins durant lactivit danalyse, modle architectural lors de lactivit de conception, code source lors de lactivit dimplmentation etc.). Les mthodes fournissent aussi des outils facilitant la production de ces systmes. Les outils sont gnralement intgrs dans des environnements de dveloppement qui se composent dditeurs, doutils de vrication, des machines virtuelles, etc. An de mieux comprendre la problmatique de cette thse, nous allons dans ce chapitre, positionner le paradigme orient agent par rapport aux principaux paradigmes de dveloppement existants. Pour chaque paradigme, nous allons exposer les problmatiques abordes ainsi que les solutions dingnierie qui ont t mises en place an de faciliter son application. Cette tude nous permettra dune part de montrer lutilit du paradigme orient agent dans le contexte informatique actuel ; dautre part, de mieux cerner les besoins relatifs lingnierie des systmes bass sur ce paradigme. Ltude des direntes techniques dingnierie nous permettra, par ailleurs, didentier celles qui peuvent tre rutilises dans le contexte orient agent.
Lvolution des paradigmes de dveloppement
Dirents paradigmes de dveloppement ont vu le jour, introduisant de nouveaux concepts permettant de structurer les programmes informatiques. Les paradigmes de dveloppement ainsi que les concepts quils introduisent permettent daugmenter le niveau dabstraction an de faciliter le dvelop10
CHAPITRE 2. ETUDE DU DOMAINE pement. Le passage dun paradigme un autre est justi par la ncessit dencapsuler certains mcanismes de bas niveau rendant la tche de dveloppement moins complexe. Ainsi, les dirents paradigmes de dveloppement sont en fait complmentaires et sinscrivent dans une logique de continuit.
3.1
Le paradigme procdural
Le paradigme procdural peut tre considr comme le paradigme de dveloppement le plus ancien. Il a permis de saranchir du code machine et de renforcer une sparation entre la reprsentation des donnes et les traitements faits sur ces donnes. Une rutilisation des sous-routines (procdures) a t obtenue. Cependant, le dveloppement des systmes complexes utilisant ce paradigme a gnr des structures en plats de spaghetti. En effet, linteroprabilit entre les procdures se fait par les variables globales qui sont accessibles par direntes procdures. Ceci a engendr des eets de bord : si on oublie de mettre jour certaines donnes partages, si lordre chronologique des assignations par les direntes parties du logiciel est incorrect, ou si une zone de mmoire a t dsalloue au mauvais moment, le programme se retrouve dans un tat imprvu. Lors de la maintenance, la modication dune procdure peut avoir des consquences inattendues sur le rsultat dautres fonctions ou procdures lies par des variables globales. Ainsi, la maintenance des systmes dvelopps avec le paradigme procdural est dicile et coteuse et la rutilisation du code se trouve souvent compromise. Un paradigme de dveloppement plus modulaire est devenu ncessaire. Cest ainsi que le paradigme orient objet a vu le jour.
3.2
Le paradigme orient objet
Le paradigme orient objet a permis une meilleure protection des donnes grce lencapsulation des donnes et une meilleure rutilisation et extension des systmes grce lhritage. Mais devant la complexit sans cesse croissante des systmes informatiques actuels, le paradigme orient objet na pas russi limiter les dicults de dveloppement inhrentes aux systmes distribus et concurrentiels compte tenu de sa faible granularit.
3.3
Le paradigme orient composant
Le passage au paradigme orient composant a permis daugmenter le niveau dabstraction et de changer la manire de dvelopper les systmes informatiques. Ceux-ci sont dsormais construits par assemblage de composants logiciels rutilisables. Lobjectif tant dindustrialiser la ralisation des systmes informatiques comme cest le cas dans dautres secteurs tel que 11
Fig. 2.1: La couche integiciel lautomobile, la construction, etc. Bien que cet objectif soit en partie atteint, lutilisation des intergiciels rend lapporche dicile appliquer. Les intergiciels visent assembler les composants et les rendre interoprables (gure 2.1). Mais, leur prolifration et le manque de standardisation rend dicile leur application. Ladministration des applications htrognes bases sur des composants distribus et utilisant des intergiciels htrognes soulve de nombreuses questions telles que le maintien de la cohrence, la scurit, lquilibre entre autonomie et interdpendance pour les dirents sous-systmes, la dnition et la ralisation des politiques dallocation de ressources, etc. De plus, la composition des composants est encore rigide et complexe ; base uniquement sur les protocoles dinteraction et les ux dentre et de sortie des composants.
3.4
Le paradigme orient service
An dassouplir les lourdeurs dans la gestion des interoprabilits et rduire le couplage entre les composants, le paradigme oriente service a t propos. Ce paradigme propose de dcouper les fonctionnalits dune application en services mtier, rutilisables dans dautres applications. Un service mtier peut tre dni comme une fonction de haut niveau. Les oprations proposes par cette fonction encapsulent plusieurs autres fonctions et oprent sur un primtre de donnes large. Ainsi, les services ont un niveau de granularit plus lev que les composants. La description dun service est compltement indpendant des plates-formes et outils.
12
CHAPITRE 2. ETUDE DU DOMAINE Dans le cas des services web, un service nest autre quune application expose par le biais dune interface XML, connue sous le nom de services Web. Les services Web sont des couches dinvocation comprhensibles potentiellement par lensemble des systmes. Les services Web interagissent les uns avec les autres par le biais denvoi de messages. De ce fait, la modlisation de services Web met en jeu la description dinteractions et de leurs interdpendances, aussi bien dun point de vue structurel (types de messages changs) que dun point de vue comportemental (ot de contrle entre interactions). Trois types de modles ont t distingus pour dcrire les interactions entre les services : la chorgraphie : il sagit de dcrire les interactions entre les services Web sans avoir de coordinateur central, linterface : il sagit de dcrire les actions denvoi et de rception de message pour chaque service. Une interface permet de spcier quelles sont les donnes ncessaires lexcution du service, et ce quil fournit en retour), Lorchestration : il sagit de dcrire un processus automatique dorganisation, de coordination, et de gestion des services Web. Les applications dveloppes selon le paradigme orient services prsentent de nombreux avantages parmi lesquels la exibilit et la ractivit. Cependant, certains obstacles ne sont pas encore surmonts. Le chantier de standardisation relatif lorchestration et la chorgraphie est loin dtre achev ce qui pose un problme dinteroprabilit. La mise en uvre dapplications orientes service soure dun manque doutils mthodologiques. Enn, les services ne sont pas conscients de leur environnement et ne peuvent ragir en cas dimprvus.
Positionnement du paradigme orient agent
Bien quil soit n dans les annes 80, le paradigme orient agent reste encore dactualit puisquil propose des mcanismes dabstraction qui permettraient probablement de rsoudre plusieurs problmatiques rencontres actuellement. En eet, les recherches menes autour de ce paradigme laborent des mcanismes pour la construction de systmes complexes voluant dans un environnement dynamique et ouvert (cest--dire dont la cardinalit et la topologie des composants le constituant peut tre variable). Ces systmes complexes comportent un grand nombre de composantes en interaction. Lorganisation de ces composantes peut tre priori inconnue. Le contle de tels systmes ne peut pas se faire de manire centralise. Pour traiter ce type de systme, le paradigme orient agent propose une nouvelle philosophie de dveloppement qui va au-del dune simple dcom13
CHAPITRE 2. ETUDE DU DOMAINE position conceptuelle ou fonctionnelle comme il se fait avec les paradigmes de dveloppement actuels. Suivant le paradigme orient agent, les composantes du systme appeles agents sont des entits [Fer95], [Pic04], [JSW98] : autonomes : dont le comportement est guid par des objectifs, ractives : capables de percevoir leur environnement et de ragir face aux vnements survenus dans celui-ci, proactives : capables dagir sur leur environnement, sociales : capables dinteragir et de communiquer avec dautres agents an de cooprer en vue datteindre un but global. Dautres caractristiques peuvent tre imputes aux systmes multi-agents ; selon le contexte, ces caractristiques ne sont pas toutes ncessaires. Lintgration de ces caractristiques dans le systme nal dpend des besoins fonctionnels et non fonctionnels lis chaque domaine. Nous recensons par exemple : le raisonnement : un agent peut dcider quel but poursuivre ou quel vnement ragir, comment agir pour accomplir un but, suspendre ou abandonner un but pour se ddier un autre, lapprentissage : lagent peut sadapter progressivement des changements dans des environnements dynamiques grce des techniques dapprentissage, la mobilit : dans certaines applications dtermines il peut tre intressant de permettre aux agents de migrer dun noeud un autre dans un rseau tout en prservant leur tat lors de leur migration. Dans ce qui suit, nous allons expliquer comment ces caractristiques peuvent tre utiles pour rpondre certaines problmatiques actuelles dinteroprabilit et dvolution dynamique. Nous allons ensuite prsenter les principaux freins empchant une utilisation grande chelle de ce paradigme.
4.1
Les problmatiques traites par le paradigme orient agent
Dans le contexte actuel, le paradigme orient agent trouve son utilit en sattaquant la modlisation de systmes ouverts, exibles et auto-adaptables. En eet, le paradigme orient agent cherche interconnecter des ressources logicielles de faon crer un systme intgr permettant de rsoudre des problmes complexes et de sauto-adapter direntes situations. Ainsi, les systmes multi-agents visent garantir : lextensibilit : elle peut correspondre de nouveaux objectifs pour le systme, ce qui induit lintgration de nouvelles entits qui vont cooprer avec celles qui existent (dans ce cas, les capacits sociales 14
CHAPITRE 2. ETUDE DU DOMAINE des agents sont trs utiles). Il pourrait sagir aussi dajouts progressifs dhypothses sur des comportements locaux au sein des agents (ceci est rendu possible grce notamment aux capacits cognitives des agents cest--dire les capacits de raisonnement et dapprentissage), la portabilit : cest--dire laptitude dun logiciel tre transfr dun environnement un autre. Les systmes multi-agents sont axs sur linteraction. Celles-ci se basent sur lutilisation de langages de communication normaliss tels que ACL/KQML qui dcrivent la smantique des messages. Ainsi, les interactions dpendront de la comprhension du contenu des messages et non de la conguration des messages changs. Ceci rduit fortement le couplage entre les composantes des systmes, la performance : celle-ci est lie aux possibilits intrinsques aux agents, dexcution parallle et dasynchronisme. La technologie agent doit aussi abiliser lexploitation des ressources disponibles en traitant les cas de concurrence entre agents, la robustesse et la tolrance aux pannes : celles-ci peuvent tre garanties par les capacits dadaptation des agents aux direntes situations qui peuvent surgir. Des tudes sont menes pour permettre lagent de diagnostiquer les pannes et dadapter son comportement par le choix des meilleures manires datteindre les buts en fonction du contexte. Nous pouvons donc conclure que le paradigme orient agent vise trouver des mcanismes permettant de simplier lutilisation et lintgration de plusieurs systmes htrognes. Il permet de rduire encore plus le couplage entre les direntes entits du systme puisque les agents ont des capacits cognitives leur permettant de grer leurs interactions. Les agents se distinguent aussi par leur capacit de perception de lenvironnement. Cette capacit nest pas prise en compte de manire explicite dans les autres paradigmes de dveloppement o la distinction entre entits actives du systme (qui vont correspondre aux agents) et entits passives du systmes (qui vont correspondre aux ressources) est peu explicite [ZJW03]. De cette manire, le paradigme orient agent peut permettre un dveloppement plus ais des applications du futur telles que celles traites au niveau de linformatique diuse (lUbiquitous Computing ). Ce domaine utilise la large diusion des processeurs dans les appareils de la vie courante (comme les chanes hi, les tlphones, les systmes domotiques, etc.) pour proposer des fonctionnalits avances obtenues par la composition de leurs fonctions en rponse aux dsirs des utilisateurs : par exemple couter du jazz avec une lumire tamise de manire automatique tout en coupant le tlphone, etc. Seulement la fonctionnalit dun tel systme dpend normment des utilisateurs, donc de lenvironnement, et reste dicilement spciable avec les paradigmes classiques. Les services Web ne permettant pas de raisonner sur linteraction avec lenvironnement, il est plus ais de traiter ce type de 15
CHAPITRE 2. ETUDE DU DOMAINE systme avec le paradigme orient agent. Le paradigme orient agent sest avr utile dans dautres domaines dapplication. Nous pouvons les classer selon trois familles [BGG04a] : les systmes purement informatiques, utiliss dans le domaine des tlcommunications et de la simulation. On y trouve notamment : les supports daide la dcision, le commerce lectronique, la supervision de rseaux, la simulation de systmes sociaux et naturels, etc. les systmes sociaux ncessitant une forte interaction avec ltre humain, tels que les collecticiels, le commerce lectronique, la recherche dinformation, lautomatisation des processus industriels ou administratifs etc. les systmes mcaniques qui intgrent des composantes mcaniques oprant dans le monde rel, tels que la robotique, les systmes industriels, les applications embarques et sans l etc. Ainsi, les systmes multi-agents peuvent tre utiles dans plusieurs contextes. Dailleurs, certains systmes industriels tels que la gestion des ressources hydrauliques [BAP02], le contrle du trac arien [LL92], les tlcommunications [EQ96] ont appliqu ce paradigme. Cependant, il existe encore plusieurs freins empchant leur utilisation grande chelle. Nous allons dcrire, dans ce qui suit, les principaux freins.
4.2
Les freins lutilisation des systmes multi-agents
Bien que certaines applications industrielles appliquant le paradigme orient agent aient commenc merger ; il manque encore lexprience pour la conception et la construction de ces systmes. La grande majorit des systmes multi-agents ont t construits de manire ad hoc sans utiliser des composants agents rutilisables. Il devient donc ncessaire de dvelopper des techniques dingnierie (mthodologies, mthodes, notations spciques, etc.) facilitant la ralisation de ces systmes. Ces techniques dingnierie seront dautant plus importantes quelles auront un rle pdagogique. En eet, en dehors du milieu acadmique, trs peu dexperts du paradigme orient agent existent de par le monde. Ce genre de formation est dispens au niveau du troisime cycle ; le manque de techniques dingnierie ne facilitant pas lacquisition des comptences ncessaires lapplication de ce paradigme. Dans le monde acadmique, plusieurs travaux sont proposs, tentant dabsorber ce problme. Ces travaux proposent gnralement : des mthodologies de dveloppement [IGG99, BCG+ 04, BKJT97, CP01, BPSM05, WJK00] qui permettent de guider les dveloppeurs durant les phases de dveloppement, 16
CHAPITRE 2. ETUDE DU DOMAINE des plates-formes orientes agents [BPR99, CNNL98, FG00] qui permettent de faciliter la phase dimplmentation, des langages de modlisation permettant de dcrire des modles selon les concepts orients agents [BMO01, CLC+ 01, SDS03, WT03]. La diversit et le manque de maturit des travaux mens font que la plupart ne soient utiliss que dans le milieu acadmique. La dicult provient essentiellement du manque de consensus concernant la smantique des concepts orients agent ainsi que leur utilisation concrte durant le cycle de dveloppement. Par exemple, il arrive souvent que certains concepts soient supports par certaines mthodologies ou plates-formes alors quils sont compltement omis par dautres. Ces omissions peuvent constituer un rel problme pour le dveloppeur qui se voit oblig de modliser ou dimplmenter certaines parties du systme de manire ad hoc. A cela se rajoute la quasi inexistence de liens entre les mthodologies et les plates-formes dimplmentation. Le passage des modles vers le code devient alors une lourde tche ralise pour la plupart du temps de manire manuelle par le dveloppeur. Il devient alors ncessaire dadopter une approche de dveloppement plus cohrente permettant dintgrer les direntes facettes du systme multiagent et de faciliter le travail des dveloppeurs tout au long du cycle de vie. Ceci constitue le but de cette thse. Pour y arriver, nous tudions dans la prochaine section les direntes techniques dingnierie existantes et choisir celles nous permettant de mieux grer lingnierie des systmes multi-agents.
Lvolution des techniques dingnierie
Dans les annes 80, le dveloppement tait principalement considr sous langle de la programmation. Il tait alors eectu en interne par une seule personne ou un petit groupe de personnes. On parlait de "programming in the small" [DK75]. Actuellement, les systmes sont amens devenir des systmes ouverts et coopratifs, en constante interaction les uns avec les autres. Nous sommes donc passs lre du "programming in the large" [DK75] o le dveloppement est considr large chelle cest--dire eectu par plusieurs quipes, parfois gographiquement loignes et faisant cooprer plusieurs applications distribues. Ce type de dveloppement ne peut plus se concentrer uniquement sur la phase dimplmentation. De nouveaux outils deviennent alors ncessaires pour faciliter le travail de dveloppement.
5.1
Les techniques dingnieries classiques
Depuis lavnement du paradigme procdural, plusieurs environnements de dveloppement intgrs (EDI) ont vu le jour. Ces environnements de dveloppement aidaient les programmeurs structurer leurs applications lors 17
CHAPITRE 2. ETUDE DU DOMAINE de la phase dimplmentation. La premire gnration dEDI ne supportait quun seul langage la fois. Avec les mutations technologiques des annes 90 (application de plus en plus tendue du paradigme orient objet), plusieurs ajouts fonctionnels amliorant la productivit des dveloppeurs ont t proposs. Ainsi, les environnements de dveloppement intgrs ne sont plus ddis un seul langage mais un ensemble de langages. Cest certainement, lenvironnement Eclipse qui a le plus marqu cette mutation. Son but tant de fournir une plate-forme modulaire pour permettre le dveloppement informatique de systmes complexes et de grande taille. Cet environnement, crit en Java, est extensible, universel et polyvalent, permettant de crer des projets mettant en uvre nimporte quel langage de programmation. Malgr lecacit des environnements de dveloppement de deuxime gnration ainsi que leurs direntes possibilits, leur aide reste limite, dans la mesure o ils nont pas la capacit de couvrir la totalit du cycle de dveloppement. En eet, ils restent pour la plupart ddis la phase dimplmentation. Une mutation actuelle des environnements de dveloppement vise intgrer les autres phases de dveloppement telles que lanalyse, la conception et la validation des systmes. Le principal but recherch est la gnration automatique du code partir de modles conceptuels vris et valids. Pour atteindre ce but, les EDI devraient permettre de couvrir la totalit du cycle de dveloppement ce qui nest pas actuellement le cas. Les premires phases de dveloppement telles que lanalyse et la conception sont gres par les Ateliers de Gnie Logiciel (aussi appels outils CASE - Computer Aided Software Engineering). Les ateliers de gnie logiciel (AGL) sont apparus dans les annes 80 pour mieux structurer le travail de dveloppement de logiciels durant les phases prliminaires de dveloppement (principalement lanalyse et la conception). Ils intgrent un ensemble doutils permettant de saisir les spcications relatives au systme en utilisant un formalisme graphique ou textuel. Le but recherch par ces outils est de prenniser le savoir-faire en gardant une trace des spcications ralises durant les direntes phases de dveloppement. Selon les outils disponibles dans lenvironnement, ces spcications peuvent tre visualises, valides et documentes par des rapports ou des dictionnaires de donnes. Certains AGL fournissent aussi des gnrateurs de code qui partir des spcications peuvent gnrer une partie du code (gnralement cest le squelette du code) dans un langage de programmation choisi. Lutilisation des AGLs a connu un grand engouement avec lapparition du paradigme orient objet et surtout lintroduction du formalisme UML (Unied Modelling Language) [BRJ00] qui est un langage uni de spcications des applications orientes objet. UML est compltement indpendant de tout langage de programmation mais il intgre tous les concepts communs des 18
CHAPITRE 2. ETUDE DU DOMAINE langages objets (hritage, appel de mthodes etc.). La simplicit du langage UML a vite conquis les industriels qui lutilisent pour spcier leurs applications. Cependant, malgr lexistence du standard UML, les spcications sont produites pour documenter lapplication et lessentiel du dveloppement reste concentr sur lactivit de codage. De plus, lavnement des nouveaux paradigmes de dveloppement a montr les limites de ces techniques dingnierie dans la modlisation de certains aspects tel que linteraction entre composants logiciels, la gestion de la concurrence et la synchronisation.
5.2
Lingnierie des systmes bass sur le paradigme orient composant
Lapplication du paradigme orient composant ncessite la spcication du systme un niveau dabstraction plus lev que les concepts objet. Un raisonnement approfondi sur les composants intgrer dans le systme, la manire de les assembler et les contraintes qui doivent tre respectes durant son excution ainsi que celles qui doivent tre conserves lors de son volution est ncessaire. Cest larchitecture logicielle qui permet de reprsenter ces dirents aspects. Au cours du dveloppement dun systme, sa comprhension diminue tandis que le cot d aux erreurs augmente. Le but dun dveloppement centr architecture (c.f. gure 2.2) est de prserver la comprhension du systme au cours du temps, de dtecter et de corriger les erreurs le plus tt possible. Ainsi, daprs la dnition fournie par dANSI/IEEE [Gro00], une architecture logicielle ne se contente pas de dcrire uniquement lorganisation des composants du systme en prcisant leurs relations ; larchitecture doit tre un cadre pour la satisfaction du cahier des charges. Elle est la base technique pour la conception comme la base gestionnaire pour lestimation des cots et du processus de gestion. Le but vis lors de la description de larchitecture est de permettre la prennisation du savoir-faire et laugmentation de la rutilisation. Pour reprsenter ces dirents aspects, on assiste, au dbut des annes 90, ltablissement dun domaine consacr au dveloppement centr architecture [PW92] [GS93]. Dans ce domaine, les recherches sont axes sur ltude des langages et formalismes ncessaires la reprsentation et la documentation des architectures logicielles. Actuellement, il nexiste pas de notation unique standardise permettant de reprsenter les architectures logicielles. Certains auteurs voient en UML un formalisme pertinent permettant de dcrire direntes vues du systme [Kru95]. Par exemple, Medvidovic et al. [MRRR02] proposent direntes manires de modliser les architectures logicielles en UML (version 1.5). Il sest avr, la suite de cette tude, que lutilisation dUML tel quel deve19
Fig. 2.2: Le processus centr architecture nait assez complexe, du fait quUML ne fournissait pas de moyens simples permettant de dcrire les composants, qui avaient un niveau dabstraction plus lev que les objets. Il a t alors ncessaire dtendre UML avec le mcanisme des strotypes, les valeurs marques et les contraintes OCL. Une deuxime approche a aussi t teste par ces mmes auteurs qui consiste tendre le langage UML avec de nouveaux concepts (mta-classes) pour les composants, les ports, les connecteurs, etc. Lutilisation des strotypes mais aussi des mta-classes a pour inconvnient de ne pas tre conforme aux spcications standardises dUML. De ce fait, les outils fournis par les environnements bass sur UML ne permettent pas de grer la description darchitectures logicielles. A loppos des formalismes bass sur UML, dautres types de formalismes ont vu le jour ; ce sont des Langages de Description dArchitecture (appels en anglais Architecture Description Languages ou ADL). Nous allons ici adopter cette appellation anglaise ADL, frquemment utilise dans la littrature. Un ADL fournit les abstractions selon lesquelles les architectures vont tre dcrites. Gnralement, il dcrit une architecture logicielle sous la forme de composants, de connecteurs et de congurations [MT00]. Les composants reprsentent les units de calcul et de stockage de donnes dans un systme logiciel. Linteraction entre ces composants est encapsule par les connecteurs. Dans la conguration, larchitecte instancie un nombre de composants et un nombre de connecteurs. Il les lie entre eux an de construire son systme. Il existe une multitude dADL dans le monde acadmique et industriel. Quelques exemples sont Wright, Darwin, ACME, Unicon, Rapide, Aesop, C2 SADL, MetaH, Archware, etc. Les concepts de composants, connecteurs et congurations sont abords de manire direntes selon le langage. En eet, il nexiste pas, de nos jours de standards xant une smantique exacte ces 20
CHAPITRE 2. ETUDE DU DOMAINE concepts. De plus, chaque ADL se focalise sur des aspects particuliers de la conception darchitectures logicielles. Par exemple, Darwin [MDEK95] est plus ax sur la modlisation darchitectures distribues et la prise en compte de leur reconguration dynamique. WRIGHT [All97] sintresse la formalisation des connexions entre composants, tandis que Acme [GMW00] ou ArchWare reprsentent des exemples dADL objectif gnral, cest--dire orant des abstractions gnriques permettant de dcrire direntes sortes darchitectures.
Certains ADL sont semi-formels (bass sur des notations graphiques normalises) alors que dautres sont strictement formels (disposant de rgles syntaxiques et smantiques ne sourant daucune ambigut). Selon le type de langage, les outils intgrs dans les environnements bass sur les ADLs peuvent changer. Un langage formel donnera plus de possibilit manipuler les spcications exprimes. En eet, les langages formels permettent dexprimer des proprits sur la structure et le comportement du systme. Dans ce cas, les environnements de dveloppement bass sur ces langages orent des outils permettant de vrier et valider les proprits. Etant donn que leurs syntaxes et smantiques sont formelles, certains environnements orent aussi des simulateurs (appels aussi animateurs) permettant larchitecte de simuler et valider le comportement dcrit au niveau de larchitecture. Dautres environnements proposent des machines virtuelles permettant dinterprter les spcications dcrites par lADL fourni. Enn, certains environnements orients architecture orent la possibilit de gnrer automatiquement lapplication correspondante (ventuellement aprs plusieurs tapes de ranement).
En se basant sur les avances faites au niveau des ADL, la nouvelle version 2.0 du langage UML apporte des avances signicatives la modlisation des systmes base de composants. Dans cette nouvelle version, un composant peut tre modlis tous les niveaux du cycle de dveloppement. La structure interne du composant est cache et accessible uniquement travers les interfaces fournies. Un modle de composant peut galement comporter une vue interne (ou bote blanche) sous la forme dun ensemble de classiers ralisant le comportement du composant (diagramme de structure composite).
Les ADLs orent de larges possibilits de modlisation. Ils ont permis un nouveau mode de dveloppement ax sur la phase de conception plutt que sur la phase dimplmentation. Lutilisation de ces langages pour la modlisation des systmes actuels est de plus en plus explore. 21
5.3
Lingnierie dirige par les modles
En parallle du dveloppement centr architecture, une autre technique dingnierie a vu le jour qui est lIngnierie Dirige par les Modles (IDM) ou Model Driven Engineering (MDE) en anglais. Ce domaine vise proposer une approche unicatrice base sur lutilisation systmatique des modles tout au long du cycle de dveloppement. Comme nous lavons dcrit depuis le dbut de cette section, chaque paradigme de dveloppement a t accompagn par des langages de spcication permettant de reprsenter et de raisonner sur le systme de manire abstraite. La nouveaut dans lapproche IDM consiste passer des modles purement contemplatifs aux modles productifs [BBB+ 05]. En eet, les techniques dingnierie traditionnelles prsentes tout au long de cette section ont souvent t dlaisses ou appliques de manire peu rigoureuse durant le cycle de dveloppement. Les modles taient produits dans le but de documenter lapplication en cours de dveloppement an de faciliter la comprhension et la communication entre les dirents participants au projet de dveloppement. Cependant, ces modles navaient pas de rle productif, dans le sens o ils taient dlaisss ds que lactivit de codage commenait. Cette activit constituait le cur du dveloppement, le code tant considr comme le seul reprsentant able du logiciel. Il arrivait souvent que des dcisions conceptuelles soient prises (ou soient modies) au cours de lactivit de codage sans que les modles soient remis jour. IDM vise fournir un cadre conceptuel, technologique et mthodologique dans lequel les modles sont au centre des activits de dveloppement. Comme le souligne Jean-Marc Jzquel [JGB06], chaque processus de dveloppement, quel que soit son type, comporte un certain nombre de phases (comme lexpression des besoins, lanalyse, la conception, limplantation ou encore la validation). Dans chaque phase un certain nombre de modles (appels aussi artefacts) sont produits qui peuvent prendre la forme de documents, de diagrammes, de codes sources, de chiers de conguration, etc. Ces modles qui reprsentent les direntes vues du systme, sont souvent produits de manire indpendante. Il est alors important de sassurer de la cohrence entre ces direntes vues. Ceci constitue le cheval de bataille du domaine de lingnierie dirige par les modles. Pour ce faire IDM propose de faire voluer lusage de ces modles en conservant une traabilit entre les lments des dirents modles et ceci quel que soit leur niveau dabstraction. Il devient alors indispensable de faire un travail de fond sur la smantique des modles mais aussi la smantique des langages avec lesquels ils sont exprims. Il est aussi ncessaire de travailler sur les techniques de composition, de tissage et de transformation de modles. Par exemple, il est utile de pouvoir exprimer explicitement les rgles permettant le passage de lexpression des besoins vers les modles concep22
CHAPITRE 2. ETUDE DU DOMAINE tuels ou architecturaux ainsi que celles permettant le passage des modles conceptuels ou architecturaux vers le code. Un autre volet du travail consiste raliser des avances dans lexpression de proprits qui seront attaches aux modles, leur prservation ou modication lors des oprations de composition/tissage/transformation avec dautres modles. Lvolution du dveloppement logiciel vers une vision centre modles ncessite donc des avances en matire de formalismes et outils supports : aux transformations de modles, la vrication dadquation entre les langages de modlisation et les applications elles-mmes, de compositions des modles Une dnition prcise du processus de dveloppement base de modles est aussi ncessaire prcisant les artefacts devant tre produits chaque phase de dveloppement, ainsi que les liens quils peuvent avoir avec ceux produits dans les autres phases. Cette approche pose explicitement les problmes rencontrs dans lapplication des mthodes dingnierie prcdentes. De plus, cette approche est base sur lintgration de modles dcrivant des vues direntes, ce qui fait delle une approche unicatrice pouvant intgrer des domaines dirents.
5.4
Conclusions relatives lvolution des techniques dingnierie
Lvolution des techniques dingnierie a suivi celle des paradigmes de dveloppement cf. gure 2.3. Avec laugmentation des niveaux dabstraction traits, les techniques dingnierie devaient sadapter de nouveaux besoins. Tout dabord, la passage dun dveloppement interne un dveloppement sur une petite chelle (utilisant le paradigme procdural) a ncessit lutilisation dEDI de premire gnration (pour la phase dimplmentation) et dAGL orients base de donnes (utiliss essentiellement au cours des phases danalyse/conception). Par la suite, lutilisation du paradigme orient objet sest accompagn par la possibilit dintgrer des applications dveloppes avec dirents langages de programmation. Les EDI de deuxime gnration sont apparus accompagns dAGL plus sophistiqus bass sur le paradigme objet. Lavnement du paradigme orient composant a permis une "industrialisation" de la production des logiciels en orientant le dveloppement vers une intgration des composants. Ceci a dirig les techniques dingnierie vers la prise en compte des architectures logicielles ds les premires phases de dveloppement. Les architectures logicielles permettent de spcier des systmes dynamique connue, cest--dire que les interactions entre les composants sont spcies priori. Cependant, cette approche a permis un dveloppement grande chelle o les composants logiciels sont produits par des quipes et organismes dirents et rassembls par la suite pour for23
Fig. 2.3: Lvolution de dveloppement des systmes informatiques mer une application. Cependant, partir des annes 2000, le dveloppement des systmes prend une autre tournure. Il soriente vers la prise en charge de systmes dynamique non programme dont lintgration doit tre plus exible an de prendre en compte lvolution rapide des processus mtier. A ce niveau, les paradigmes orients agent semblent tre les plus adquats pour rgler cette problmatique. Au niveau des techniques dingnierie, les travaux sorientent vers une approche base sur lingnierie dirige par les modles o un travail de fond est men pour xer la smantique des modles produits et la manire de les intgrer. Ainsi, cette technique dingnierie semble tre la plus adaptes pour rpondre aux problmatiques souleves dans le domaine des systmes multi-agents (c.f. section 4.2).
Introduction la problmatiques de la thse
Comme nous lavons mentionn prcdemment, lun des plus grand frein lutilisation du paradigme orient agent est le manque de techniques dingnierie standardises qui facilitent son application. Les recherches dans ce domaine est en plein foisonnement, conduisant llaboration dun thme de recherche appel AOSE (Agent Oriented Software Engineering). Durant les confrences organises autour de ce thme, plusieurs mthodologies, mtodes, notations et plates-formes dimplmentation ont t proposes. Nous allons dtailler quelques-uns de ces travaux dans le prochain chapitre. Cependant, celles-ci sourent de plusieurs limites qui peuvent expliquer les dicults des systmes multi-agents percer dans le monde industriel. An de pallier ces limites, nous pensons quil est judicieux de tirer prot 24
CHAPITRE 2. ETUDE DU DOMAINE des avances ralises au niveau des techniques dingnierie rcentes. Les systmes multi-agents traitent des systmes complexes bass sur des concepts ayant un haut niveau dabstraction. Lapplication de ces concepts peut faire appel dautres paradigmes de plus bas niveau tel que les objets, les composants et les services Web. De plus, le paradigme orient agent est destin dvelopper des systmes complexes ayant une forte interaction, aussi bien entre les composantes du systme quavec lenvironnement. Dans ce contexte, il est ncessaire de pouvoir exprimer et vrier les proprits fonctionnelles et non fonctionnelles lies ces systmes. Ces proprits devraient tre concerves tout au long du cycle de vie. Dans ce contexte, les techniques dingnierie les plus adaptes nous semble tre : lapproche centre architecture qui se concentre sur lorganisation des lments qui composent le systme. Larchitecture ore une vue globale du systme qui est lisible et qui expose les proprits les plus cruciales ; ce qui permet un dveloppement ecace. lapproche dirige par les modles (ou IDM) qui conoit lintgralit du cycle de vie comme un processus de production, de ranement itratif et dintgration de modles. Lutilisation des modles permet de capitaliser les connaissances et le savoir-faire dirents niveaux dabstraction quelles soient des connaissances du domaine mtier ou du domaine technique. Elle couvre ainsi les direntes vues du systme. Dans la suite de ce document, aprs une prsentation de ltat de lart des approches dingnierie orientes agent, nous allons expliquer comment nous pouvons utiliser lapproche centre architecture et lapproche dirige par les modles pour dvelopper des systmes bass sur le paradigme orient agent. Nous allons analyser lapport de ces direntes approches et explorer leurs principaux inconvnients. Par la suite, nous allons exposer notre approche base sur les techniques dingnierie cites ci-dessus.
25
26
Chapitre 3 Ingnierie des Systmes Multi-agents
CHAPITRE 3. INGNIERIE DES SYSTMES MULTI-AGENTS
Introduction
Actuellement, une large panopli de travaux sinteresse au paradigme orient agent. Tout au long de ce chapitre, nous allons les passer en revue. Dans la premire section, nous exposerons les direntes thories lies lapplication du paradigme orient agent. Ces thories englobent des modles, des concepts et des notions ayant t minutieusement tudis ou appliqus par certaines quipes de recherche. Ces thories visent tre rutilisables et fournir un rfrent pour les dveloppeurs. Les thories orientes agent modient les procds de production de logiciel. An de mieux apprhender lapplication de ces thories, un nouvel axe de recherche appel AOSE (Agent Oriented Software Engineering) est n. Celui-ci est compltement ddi la recherche des bonnes pratiques de dveloppement qui aident llaboration dun systme multi-agents. Cet axe de recherche couvre plusieurs aspects [BCP05] particulirement lis la dimension gnie logiciel (et plus prcisment aux techniques dingnierie). Ceci inclut la recherche de nouvelles mthodes, mthodologies, langages et outils adquats ncessaires lanalyse, la conception, limplmentation, ainsi que la vrication et la validation des systmes bass sur le paradigme orient agent. Dans ce chapitre nous allons particulirement nous intresser aux : langages spciques au paradigme agent qui facilitent la spcication des systmes multi-agents, mthodologies orientes agent qui guident les dveloppeurs durant les phases de dveloppement, 28
CHAPITRE 3. INGNIERIE DES SYSTMES MULTI-AGENTS plates-formes multi-agents qui facilitent limplmentation et le dploiement des systmes multi-agents. Pour chaque technique, nous avons tabli un cadre de comparaison qui nous permet de direncier les dirents travaux. A la n de ce chapitre, aprs une analyse de ces travaux, nous identierons les direntes problmatiques souleves (et non encore rsolues) lies lingnierie des systmes multi-agents.
Les thories orientes agent
Les systmes dvelopps selon le paradigme agent peuvent tre considrs comme plus complexes que ceux bass sur les paradigmes orients objets, orients composants et orients services. Cette complexit vient du fait que les systmes multi-agents couvrent plusieurs vues et plusieurs niveaux dabstraction. Pour grer cette complexit, il est prfrable de dcomposer les systmes multi-agents. Pour prsenter de manire structure les thories orientes agent, nous adoptons dans cette section, une dcomposition base sur quatre vues principales [Dem01] : une vue Agent, une vue Environnement, une vue Interaction, une vue Organisation. Direntes thories ont t proposes pour llaboration de chaque vue. Ainsi, plusieurs modles ou types dagents existent. Lenvironnement peut tre considr sous plusieurs angles. Les interactions peuvent tre modlises par des protocoles rutilisables dans dirents contextes. Enn, pour laborer lorganisation, plusieurs notions doivent tre prises en compte tel que lmergence, lauto-adaptation, la topologie, etc. Dans ce qui suit, nous exposerons, les direntes thories lies chaque vue.
2.1
La vue agent
Il nexiste pas, actuellement, une dnition de lagent qui fasse lunanimat. Pour avoir une bonne vision du concept agent, nous confrontons les dnitions les plus utilises dans la littrature. La plupart des travaux francophones font rfrence la dnition fournie par Ferber [Fer95] qui stipule quun agent est une entit physique ou virtuelle : qui est capable dagir dans un environnement, qui peut communiquer directement avec dautres agents, qui est mu par un ensemble de tendance (sous la forme dobjectifs individuels ou dune fonction de satisfaction, voire de survie, quelle cherche optimiser), 29
CHAPITRE 3. INGNIERIE DES SYSTMES MULTI-AGENTS qui possde des ressources propres, qui est capable de percevoir (mais de manire limite) son environnement, qui ne dispose que dune reprsentation partielle de cet environnement (et ventuellement aucune), qui possde des comptences et ore des services, qui peut ventuellement se "reproduire", qui a un comportement qui tend satisfaire ses objectifs, en tenant compte des ressources et des comptences dont elle dispose, et en fonction de sa perception, de ses reprsentations et des communications quelle reoit. Par ailleurs, une autre dnition frquemment cite est fournie par Jennings et al. [JSW98] qui stipule quun agent est un systme informatique, situ dans un environnement, et qui agit dune faon autonome et exible pour atteindre les objectifs pour lesquels il a t conu. Les notions "situ", "autonomie" et "exible" sont dnies comme suit : situ : lagent est capable dagir sur son environnement partir des entres sensorielles quil reoit de ce mme environnement. Exemples : systmes de contrle de processus, systmes embarqus, etc, autonome : lagent est capable dagir sans lintervention dun tiers (humain ou agent) et contrle ses propres actions ainsi que son tat interne, exible : par exibilit, les auteurs entendent : Ractivit : un systme ractif maintient un lien constant avec son environnement et rpond aux changements qui y surviennent. Pro-activit : un systme pro-actif gnre et satisfait des buts. Son comportement nest donc pas uniquement dirig par des vnements. Capacits sociales : un systme social est capable dinteragir ou cooprer avec dautres systmes. Ces dnitions sont cependant trop gnralistes et ne donnent pas une ide sur la manire dappliquer concrtement le concept agent. Pour avoir une meilleure vision de ce concept, nous explorons dautres travaux qui parlent de modles dagents, darchitectures dagents et dimplmentation dagents. Ces termes explicitent les dirents niveaux de description dun agent : le modle qui dcrit comment lagent est compris, ses proprits et comment on peut les reprsenter, larchitecture qui est un niveau intermdiaire entre le modle et limplmentation. Elle prcise la manire dont un modle peut tre appliqu en spciant explicitement ses composants, limplmentation qui soccupe de la ralisation pratique de larchitecture des agents laide de langages de programmation.
30
CHAPITRE 3. INGNIERIE DES SYSTMES MULTI-AGENTS Les modles dagents peuvent tre classs par famille. Chaque famille se focalise sur une ou plusieurs caractristiques que possde lagent. Il dnissent la manire de concevoir lentit agent. On trouve galement dans la littrature des architectures qui ranent les modles en donnant une ide plus concrte sur les composants ncessaires limplmentation. Ces architectures sont parfois prises en compte au niveau des plates-formes dimplmentation. Nous prsentons dans ce qui suit, les principaux modles dagents classs par famille. Ainsi, nous distinguons : les agents ractifs les agents cognitifs les agents hybrides les agents mobiles Modle dagents ractifs La structure des agents purement ractifs tend la simplicit. Ce sont des agents qui fonctionnent selon un mode stimuli/rponse. Ds quils peroivent une modication de leur environnement, ils rpondent par une action programme. Lagent ractif ne possde pas une reprsentation complte de son environnement et nest pas capable de tenir compte de ses actions passes. De ce fait, il ne peut avoir des capacits dapprentissage. Ainsi, les agents ractifs sont souvent considrs comme ntant pas "intelligents" par euxmmes. Chaque individu pris sparment possde une reprsentation faible de lenvironnement et na pas de buts. Mais ces derniers peuvent tre capables dactions volues et coordonnes. Cest le cas dune socit de fourmis, tudie par Alexis Drogoul [Dro93]. Quand on parle dagents ractifs, plusieurs travaux font rfrence larchitecture de Brooks [Bro86], appele architecture de subsomption. Une architecture de subsomption comporte plusieurs modules, quon appelle modules de comptence. Chaque module tant responsable de la ralisation dune tche spcique. Les couches de bas reprsentent des comportements primitifs, par exemple "viter les obstacles". Les couches de haut niveau correspondent des tches plus abstraites et sont prioritaires sur les couches de plus bas niveau. La gure 3.1 illustre un exemple dapplication de larchitecture de Brooks. Dans cet exemple, le robot peroit son environnement travers ses capteurs. Les capteurs transmettent linformation aux direntes couches. Cette information est ltre par un inhibiteur qui permet dintercepter les messages venant de la couche suprieure. Ceci provoque lannulation de la tche relative la couche de linhibiteur. A la sortie de chaque couche, un supresseur 31
Fig. 3.1: Larchitecture de Brooks intercepte les messages de la couche suprieur, ce qui a leet dannuler la tche de plus bas niveau. Larchitecture de Brooks est parmi celles qui ont t les plus utilises pour dvelopper des agents ractifs. Dautres architectures existent telles que larchitecture Manta [DCF95] dcrite dans la gure ci-dessous 3.2. Les travaux sur les agents ractifs ont fait apparatre des concepts devant tre pris en compte lors de llaboration de larchitecture interne de lagent tel que : les capteurs : qui servent dtecter un vnement survenu dans lenvironnement, les tches : qui dcrivent une partie du comportement de lagent, les eecteurs : qui permettent de raliser les tches. Plusieurs plates-formes implmentant ces concepts ont t proposes dans la littrature telles que MANTA [DCF95], DIET [MBWH03], SimuLE [MP05]. Modle dagents cognitifs Ils se basent sur un modle qui provient dune mtaphore du modle humain. Ces agents possdent une reprsentation explicite de leur environnement, des autres agents et deux-mmes. Ils sont aussi dots de capacits de raisonnement et de planication ainsi que de communication. Le travail le plus reprsentatif de cette famille dagent porte sur le modle BDI (Believe Desire Intention) [BIP88]. Les sources de ces travaux sont les sciences humaines et sociales. 32
Fig. 3.2: Larchitecture MANTA [DCF95]
La logique BDI (Belief, Desire, Intention) est nonce dans les annes 80 par [BIP88] et fait lobjet jusqu maintenant de plusieurs travaux. Ce modle se fonde sur trois attitudes qui dnissent la rationalit dun agent intelligent : B = Belief = Croyance : ce sont les informations que possde lagent sur son environnement et sur les autres agents agissant sur le mme environnement. Ceci constitue les connaissances supposes vraies de lagent. D = Desire = Dsir : ce sont les tats de lenvironnement et parfois de lui-mme, quun agent aimerait voir raliser. Ce sont les objectifs que se xe un agent. I = Intention = Intention : ce sont les actions quun agent a dcid de faire pour accomplir ses dsirs. Ils forment des ensembles de plans qui sont excuts tant que lobjectif correspondant nest pas atteint. Le modle BDI a inspir beaucoup darchitectures dagents cognitifs. Nous pouvons citer : PRS (Procedural Reasoning System) dveloppe par George et Lansky en 1987 [GL87]. dMARS (the distributed Multi-Agent Reasoning System) est une volution de larchitecture PRS, ralise par Wooldridge et al. en 1997 [dKLW97]. Enn, nous pouvons citer IRMA (Intelligent Resource-bounded machine Architecture) dveloppe par Bratman et al. en 1988 [BRA87], etc. 33
CHAPITRE 3. INGNIERIE DES SYSTMES MULTI-AGENTS Modle dagents hybrides Ce sont des agents ayant la fois des capacits cognitives et ractives. Ils conjuguent la rapidit de rponse des agents ractifs ainsi que les capacits de raisonnement des agents cognitifs. Ce modle a t propos par plusieurs auteurs an de palier aux problmes lis au temps de dcision et au temps daction relativement lev pour les agents ractifs. Dans ce type de modle, les agents sont conus comme tant composs de niveaux hirarchiques qui interagissent entre eux. Chaque niveau gre un aspect du comportement de lagent [OJ96] : bas niveau : couche ractive qui est en relation directe avec lenvironnement et qui raisonne suivant les informations brutes de ce dernier, niveau intermdiaire : couche mentale qui fait abstraction des donnes brutes et qui se proccupe dun aspect de lenvironnement plus volu, niveau suprieur : couche sociale qui tient compte de linteraction avec les autres agents. Pour illustrer cette famille, nous pouvons citer larchitecture ASIC [BD94] utilise pour le traitement numrique dimages, larchitecture ARCO [Rod94] cre dans le cadre de la robotique collective et larchitecture ASTRO [OBDK01] dveloppe pour tre utilise dans les systmes multi-agents soumis des contraintes de type temporel.
Modle dagents mobiles Un agent mobile est un agent capable de se dplacer dun site physique un autre. Ce type dagent soppose aux agents statiques (ou stationnaires), qui sexcutent seulement dans le systme o ils ont commenc leur excution. Les agents stationnaires communiquent avec leur environnement selon des moyens conventionnels tels que RPC (Remote Procedure Calling). Ces moyens peuvent tre coteux en terme de charge de communication. Par contre, un agent mobile nest pas li au systme dans lequel il dbute son excution [LO98]. Il est capable de se dplacer dun hte un autre dans le rseau. Il peut transporter son tat et son code dun environnement vers un autre o il poursuit son excution. Ceci a lavantage de rduire le transfert des ux de donnes volumineuses dans le rseau : quand un grand volume de donnes est stock dans un hte loign, ces donnes seront traites localement plutt que transfres travers le rseau. Il sagit donc de dplacer les traitements vers les donnes plutt que les donnes vers les traitements (gure 3.3). Un agent mobile peut avoir la mme architecture quun agent ractif ou 34
Fig. 3.3: Rduction de la charge des rseaux cognitif, bien quil y ait une ncessit davoir un module suprieur grant la mobilit de lagent. Il existe lheure actuelle beaucoup dimplmentations direntes des plates-formes agents mobiles mais qui sont incompatibles entre elles. Certaines crites en Java pur, bncient des avantages de ce langage (portabilit, scurit dexcution, chargement dynamique de classes, programmation multithread, etc.). Les plates-formes bases sur Java les plus connues sont Odyssey de General Magic Inc, Aglets dIBM, Concordia de Mitsubishi, Voyager de ObjectSpace. Dautres plates-formes ont t dveloppes avec dautres langages : Agent Tcl, Tacoma et Telescript (General Magic).
2.2
La vue environnement
Lenvironnement dun agent dsigne tout ce qui est extrieur lagent. Il dnit l espace commun aux agents du systme et est dot dun ensemble dobjets. Dans la littrature, lenvironnement est distingu sous plusieurs angles : environnement social (par opposition lenvironnement physique) : lenvironnement social correspond aux autres agents avec lesquels un agent est en interaction par envoi de message. Lenvironnement physique est quant lui constitu des ressources matrielles que lagent peut percevoir ou sur lesquels il peut agir. Par exemple, dans une socit de fourmis, lenvironnement physique est compos de nourriture et dobstacles. environnement accessible (par opposition "inaccessible") : le systme peut obtenir une information complte, exacte et jour sur ltat de 35
CHAPITRE 3. INGNIERIE DES SYSTMES MULTI-AGENTS son environnement. Dans un environnement inaccessible, seule une information partielle est disponible. Par exemple, un environnement tel que lInternet est inaccessible car il est impossible de tout connatre propos de lui. Un robot qui volue dans un environnement possde des capteurs pour le percevoir et, en gnral, ces capteurs ne lui permettent pas de connatre tout de son environnement qui est alors considr comme inaccessible. environnement continu (par opposition "discret") : dans certains environnements, le nombre dactions et de perceptions possibles est inni. Dans ce cas, lenvironnement est considr comme continu. A linverse, si le nombre dactions et de perceptions possibles est limit, lenvironnement est dit discret. Ceci est le cas dans un environnement simul tel quun co-systme. environnement dterministe (par opposition "non dterministe") : une action eectue dans un environnement dterministe a un eet unique et certain. Dans ce cas, ltat suivant de lenvironnement est compltement dtermin par ltat courant. Dans un environnement non dterministe, une action na pas un eet unique garanti. Par nature, le monde physique rel est un environnement non dterministe. environnement dynamique (par opposition "statique") : ltat de cet environnement dpend des actions des processus appartenant cet environnement mais aussi des actions dautres processus externes. Aussi, les changements ne peuvent pas tre prdits par le systme. Par exemple, lInternet est un environnement hautement dynamique, son changement nest pas simplement li aux actions dun seul utilisateur. Actuellement, lenvironnement est une dimension encore peu modlise dans les SMA quelques exceptions dans le domaine de la simulation. En fait, la modlisation de lenvironnement est souvent intgre dans les connaissances du domaine de lagent.
2.3
La vue interaction
Linteraction a comme objectif de mettre en relation dynamique deux ou plusieurs agents par le biais dune ou plusieurs actions rciproques. Elle peut se faire selon plusieurs manires suivant la situation travers laquelle interagissent nos agents. On distingue dirents types dinteraction que les agents peuvent adopter comme : la communication, la coopration, la ngociation et la coordination. Linteraction se base sur des protocoles qui permettront aux agents dchanger des messages structurs. Le fait dinteragir va permettre lagent de partager de linformation, dtre au courant de ce qui se passe autour de lui, datteindre ses buts et dviter 36
CHAPITRE 3. INGNIERIE DES SYSTMES MULTI-AGENTS autant que possible les conits [GHB00]. Dans ce qui suit, nous allons dtailler les dirents modes dinteraction qui sont voqus dans la littrature ainsi que les protocoles sur lesquels ils se basent.
La communication La communication est un des lments importants du systme multiagents. Elle permet lchange des informations, la coopration et la coordination. Dans la communication agent, lintention de communiquer est de produire un eet sur les destinataires : ils excuteront probablement une action demande par lmetteur ou rpondront une question [Hug05]. La communication entre agents peut tre une communication directe ou indirecte. La communication indirecte est adopte par les agents ractifs. Elle se fait travers lenvironnement ou bien par le biais dun tableau noir. Dans une communication par environnement, les agents laissent des traces ou des signaux qui seront perus par les autres agents. Dans ce genre de communication il ny a pas de destinataire bien dni. La communication directe, quant elle, est spcique aux agents cognitifs. Elle est intentionnelle et se fait par envoi de messages un ou plusieurs destinataires. La communication directe se base sur trois lments essentiels : le langage de communication : il permettent de structurer les messages changs entre les agents. Les langages de communication les plus utiliss et les plus connus sont KQML [FLM95] et FIPA ACL [FIP99]. Ils sont bass sur la thorie des actes de langages [Aus62],[Sea69]. lontologie : elle sert fournir un vocabulaire et une terminologie comprhensible par tous les agents. Cette smantique sera rgie par des rgles et des contraintes qui permettront de dnir un consensus sur le sens des termes. En eet, lontologie concernera les symboles nonlogiques du contenu du message. les mcanisme de communication : ils permettent de stocker, rechercher et adresser les messages aux agents. Ces mcanismes sont prsents dans les plates-formes multi-agents comme Jade (cf. section 6.2) ou MadKit ??. La coopration La coopration se traduit par le fait quun ensemble dagents travaillent ensemble pour satisfaire un but commun ou individuel. Lajout ou la suppression dun agent inue considrablement sur la performance du groupe. Le besoin de faire cooprer des agents, vient essentiellement du fait quun agent ne peut atteindre son objectif individuellement et a, par consquence 37
CHAPITRE 3. INGNIERIE DES SYSTMES MULTI-AGENTS besoin de laide des autres agents du systme. La coopration a comme devise "diviser pour rgner", cest--dire que la tche va tre dcompose entre plusieurs agents et ceci peut tre ralis par plusieurs mcanismes comme le Contract Net [Smi88] ou encore la planication multi-agents qui consiste en une technique adoptant un organe centralis qui se charge de la ralisation des plans et de la gestion des conits. La coordination La coordination [Cia96] est prsente lorsquil existe une interdpendance dans les actions des agents, leurs buts ou mme les ressources quils utilisent. A ce stade, coordonner les activits des agents devient un aspect essentiel an dviter des problmes dans le comportement global du systme. En eet, la coordination met de lordre dans le processus global eectu par des agents. Elle consiste synchroniser leurs activits ou rgler les conits qui existent entre eux. La ngociation Un systme multi-agents est compos de plusieurs agents. Ces derniers peuvent entrer en conit pour plusieurs raisons : conits dintrts ou de buts, accs des ressources ou proposition de plusieurs solutions direntes un seul problme. An de rsoudre ces conits et de trouver une situation qui satisfasse tout le monde, les agents ngocient entre eux en faisant des concessions ou en cherchant des alternatives. Dans la littrature, Smith [Smi88] dnit la ngociation par : "By negotiation, we mean a discussion in which the interested parties exchange information and come to an agreement. For our purposes negotiation has three important components (a) there is a two-way exchange of information, (b) each party to the negotiation evaluates the information from its own perspective, (c) nal agreement is achieved by mutual selection". A travers cette dnition, nous remarquons que les deux grands piliers de la ngociation sont la communication (a) et la prise de dcision (b) (c). An de rsoudre les conits, les systmes multi-agents peuvent adopter plusieurs mthodes que nous pouvons classer dans deux grandes familles : Les mthodes centralises : elles reposent sur la ngociation via un mdiateur ou sur des protocoles tels que le Contract Net Protocol, Les mthodes dcentralises : elles sont plus utilises par les agents BDI telles que la recherche ngocie (TEAM) [LL93], la mthode heuristique [JPSF00] ou encore la ngociation base sur largumentation (ANA) [JFL+ 01]. 38
CHAPITRE 3. INGNIERIE DES SYSTMES MULTI-AGENTS Les protocoles dinteraction An de structurer la communication entre les agents, des protocoles dinteraction sont labors. Les protocoles dinteraction permettent de dcrire explicitement les changes de messages entre les agents. Ils reprsentent un schma commun de conversation utilis pour excuter une tche ou appliquer une stratgie de haut niveau. Un protocole prcise qui peut dire quoi qui et les ractions possibles ce qui est dit. Il dcrit galement les enchanements de messages qui peuvent tre possibles entre les agents. Il existe dirents types de protocoles dinteraction, on cite particulirement : les protocoles de coordination, les protocoles de coopration, les protocoles de ngociation. Parmi les protocoles de coordination les plus utiliss et les plus connus dans le systme multi-agents, on trouve le Contract Net Protocol [Smi88] qui dcrit un protocole dont les agents coordonnent leurs activits en tablissant des contrats an datteindre leurs buts ou encore Auction protocol [HOB04] qui se base sur la notion denchres croissants (English Auction) ou enchres dcroissants (Dutch Auction).
2.4
La vue organisation
Lorganisation permet de structurer les direntes composantes du systme ainsi que leur mode de fonctionnement global. Lorganisation sintresse aussi aux dimensions sociales des agents [Hab68]. Elle peut tre considre comme une structure dcrivant les interactions et autres relations qui existent entre les membres de la dite organisation [Fox81] (dans le but dassouvir un objectif commun). Lorganisation peut donc apparatre comme une structure de coordination et de communication [Mal87]. Il existe de nos jours, deux principales visions du concept organisation [CSB05]. Dans la premire vision, lorganisation est une entit part entire qui est compose par un groupe dagents. La structure organisationnelle ainsi que le comportement global sont pr-tablis. Plusieurs contraintes peuvent tre exprimes au niveau de la topologie, des protocoles dinteraction, des normes utiliss ainsi que le droulement des activits [FGM03], [HSB02], [VSDD04]. Dans la deuxime vision, lorganisation merge du comportement global des direntes composantes du systme [Dro93], [RB98], [GGG05]. Les diffrents lments faisant partie de lorganisation sont pralablement connus et leur comportement individuel est spci. Cependant, le comportement 39
CHAPITRE 3. INGNIERIE DES SYSTMES MULTI-AGENTS global est inconnu. Ces cas sont surtout rencontrs dans les applications dingnierie sociale qui consistent tudier la dynamique des structures sociales. Lobjectif de ces applications est de dcouvrir le modle organisationnel gnr suite aux activits et dcisions des dirents acteurs sociaux ainsi que leur interaction. Nous pouvons citer par exemple, le cas des socits de fourmis [RB98]. Dans cette vision, il est intressant de spcier de manire explicite au niveau de lorganisation, les rgles de gestion de conits ou dinterfrences gnrs suite aux activits de chacun des agents. Quand on parle dorganisation au niveau des systmes multi-agents, diffrents aspects sont tudis en profondeur. Ce sont principalement : la topologie, lemergence, lauto-organisation.
Les topologies de lorganisation Les organisations multi-agents peuvent tre dcrites selon une certaine topologie. Ces topologies dcrivent les structures organisationnelles et permettent dimposer certaines contraintes au niveau des interactions entre les agents appartenant lorganisation. Dans sa thse, Le Strugeon [Str95] identie dirents types de topologies : les topologies structure hirarchique : ces organisations sont souvent rigides. Le contrle est centralis sur un agent qui communique les ordres aux autres agents qui se contentent de les excuter,
Fig. 3.4: Topologie structure hirarchique les topologies de type march : les organisations respectant ce type de topologie sont composes dagents coordinateurs et dagents excutants. Cette structure est un peu plus dcentralise autour de plusieurs objectifs oprationnels. Larchitecture MAGIQUE [RM01] se base sur ce type de topologie, 40
Fig. 3.5: Topologie structure de march les topologies de type communaut : le contrle est fortement distribu et dont les membres possdent les mmes capacits,
Fig. 3.6: Topologie structure de communaut les topologies de type socit : dans ces organisations, le contle est dcentralis. Les agents poursuivent chacun un objectif oprationnel et le comportement global est ajust par des principes de ngociation.
Fig. 3.7: Topologie structure de socit Lmergence Un systme multi-agents est un ensemble dagents situs dans un mme environnement et qui interagissent. De ces interactions peuvent merger diffrents phnomnes. Lmergence traite donc de lapparition soudaine non 41
CHAPITRE 3. INGNIERIE DES SYSTMES MULTI-AGENTS programme et irrversible de phnomnes dans un systme. Cette notion se base sur la maxime grecque "le tout est plus que la somme de chaque partie". Les phnomnes qui apparaissent peuvent tre classs en trois catgories [MC97] : lmergence structurelle, lmergence de comportements et lmergence de proprits. Une dnition fournie par Mller dans [Ml02], nonce quun phnomne est mergent si : il y a un ensemble dagents en interaction entre eux et via un environnement dont lexpression des tats et de la dynamique nest pas exprime dans les termes du phnomne mergent produire mais dans un vocabulaire ou une thorie D, la dynamique des agents en interaction produit un phnomne global qui peut tre une structure stable, une trace dexcution ou nimporte quel invariant statique ou dynamique, ce phnomne global est observ soit par un observateur extrieur (sens faible) soit par les agents eux-mmes (sens fort) en des termes distincts de la dynamique sous-jacente, cest dire avec un autre vocabulaire ou thorie D. Lobservation peut se faire par un observateur extrieur ou par les agents eux-mmes travers un mcanisme dinscription et dinterprtation fond sur une thorie de lmergence D. La raison dtre de cette thorie de lmergence tant dexprimer la faon de relier les thories D et D. Les travaux sur lmergence tentent de dvelopper des outils, des mthodes et des constructions qui rendent le processus dmergence moins opaque et par consquent plus comprhensible. Pour cela, ils se basent, entre autre, sur : la thorie des systmes complexes adaptatifs : lmergence fait rfrence aux patterns du macro niveau apparaissant dans les systmes dagents en interaction, la thorie des systmes dynamiques non linaires issue de la thorie du chaos. Le travail porte en grande partie sur les attracteurs, lcole synergtique fonde par Haken (1981) qui tudie lautoorganisation dans les systmes physiques, la thermodynamique Loin et autour de lquilibre introduite par Prigogine. Les phnomnes mergents sont les structures dissipatives apparaissant partir de conditions "loin de lquilibre". Lauto-organisation Plusieurs travaux se sont penchs sur ladaptation dans les systmes multi-agents et tudient de ce fait, leur capacit dauto-adaptation. Ces travaux considrent que le systme doit sadapter son environnement par 42
CHAPITRE 3. INGNIERIE DES SYSTMES MULTI-AGENTS auto-organisation des agents. Lorganisation nale observe est alors la plus adapte ltat courant de lenvironnement. Lauto-organisation a t initialement tudie et applique dans les secteurs de la biologie, de la physique et de la chimie. Lobjectif de lautoorganisation est de permettre lvolution dynamique de lexistant en fonction du contexte de faon assurer la viabilit du systme [Cam94]. Lautoorganisation est un mcanisme trs interessant permettant de raliser des systmes tolrant aux pannes. Ce mcanisme permet aussi aux composantes du systme de sadapter leur environnement soit par spcialisation des fonctions (apprentissage), soit par modication de la topologie de lorganisation. Les tudes sur lauto-organisation portent sur la dnition des critres de rorganisation.
Ingnierie des systmes informatiques selon le paradigme orient agent
Comme nous lavons mentionn dans la section 1, plusieurs techniques dingnierie orientes agent existent. Nous classions ces direntes techniques dans trois grandes classes : les langages de spcication orients agent, les mthodologies orientes agent, les plates-formes dimplmentation orientes agent. Avant de procder la prsentation et la comparaison des travaux portant sur ces direntes techniques, il convient de dnir ce que nous entendons par langages de spcication, mthodologie et plates-formes dimplmentation.
3.1
Les langages de spcication
Les langages de spcication (comme son nom lindique) permettent dexprimer les spcications lies un systme. Dirents types de notation existent. Elles vont des "plus naturelles" aux plus formelles. Les noncs informels Cette catgorie de notation se base sur des descriptions faites en langage naturel. Bien que pouvant tre standardises, elles sont bien souvent propres une entreprise voire un projet ou une quipe de dveloppeurs. Linconvnient majeur de ce type de techniques est d lambigut du langage. Des risques dincohrence, de non compltude, de dicult dorganisation et de redondance dinformation peuvent donc apparatre. Pour pallier lambigut, certains adoptent des prsentations formates telles que les dictionnaires de 43
CHAPITRE 3. INGNIERIE DES SYSTMES MULTI-AGENTS donnes ou glossaires, dans lesquels est dni le vocabulaire du domaine dapplication. Ceci reste cependant insusant et les risques cits prcdemment perdurent. Les notations semi-formelles Ces notations sont relativement simples et permettent ainsi aux dirents participants un projet de communiquer facilement et ecacement. Les reprsentations classiques de cette catgorie de notations sont : les diagrammes dtats-transitions dont lobjectif est, comme pour les tables tats-transitions, de reprsenter les dirents tats du systme et les vnements qui dclenchent les changements dtats, les diagrammes de ots de donnes qui intgrent les ots de donnes et des processus de transformation. Ils montrent comment chaque processus transforme les donnes quil reoit en ots de sortie, lensemble des notations utilises dans UML (diagramme de cas dutilisation, de squence, de collaboration, dtats-transitions, etc.). Les notations formelles Cette famille de notations qui repose sur les mathmatiques permet, lors dune tape de spcication, dliminer les ambiguts des notations informelles ou semi-formelles et les mauvaises interprtations qui en dcoulent. Les langages formels possdent trois composantes : une syntaxe qui prcise la notation utilise pour procder la spcication, une smantique qui donne une dnition non ambigu de cette syntaxe, un ensemble de relations qui dnissent les rgles donnant les proprits des objets mathmatiques satisfaisant la spcication. Des reprsentants des notations formelles sont, par exemple, LOTOS [Gar89], le langage B [Abr91], le langage Z [Spi92] et le -calcul [Mil99]. Certaines spcications non formelles peuvent se voir adjoindre des langages formels pour lexpression des contraintes. On peut citer par exemple OCL [BKPPT00]dans le cas dUML.
3.2
Les mthodologies de dveloppement
Souvent, il est dusage de confondre les termes mthodologie et mthode et de les utiliser comme signiant la mme chose. Cependant, ces termes sont dirents. Une mthode correspond en ralit une description tape par tape de ce qui doit tre fait pour accomplir une tche ; alors quune mthodologie dsigne un ensemble de principes gnraux qui guident le choix dune mthode adapte aux besoins dun projet ou dune tche. Dans son ouvrage "Fundamentals of Software Enginerring", Carlos Ghezzi et al. [GJM03] fait 44
CHAPITRE 3. INGNIERIE DES SYSTMES MULTI-AGENTS la distinction entre mthodes et mthodologies. Selon ces auteurs une mthode dtermine la manire deectuer une tche durant le dveloppement du logiciel. Elle peut tre compare une recette de cuisine qui indique les ingrdients ncessaires ainsi que la manire de les cuisiner an de russir un plat. Une mthodologie, quant elle, a t considre par ces mmes auteurs comme un systme de mthodes. Nous retiendrons la dnition propose par Booch [Boo92] , qui est plus explicite et qui stipule quune mthodologie est : "un ensemble de mthodes appliques tout au long du cycle de dveloppement dun logiciel, ces mthodes tant unies par une certaine approche philosophique gnrale". A titre de comparaison, une mthodologie va correspondre lensemble des recettes de cuisine qui vont tre utilises pour prparer et servir un grand repas organis selon un thme particulier. Ce thme correspond lapproche philosophique gnrale, adopte lors du dveloppement. Comme nous lavons dj mentionn dans le chapitre 2, ce sont les paradigmes de dveloppement qui dnissent cette approche philosophique. Ainsi, il existe par exemple des mthodologies lies au paradigme orient objet ( OMT (Object Modeling Technique) [RBE+ 95], OOSE (Object Oriented Software Engineering) [Jac93],etc.). De manire plus explicite, une mthode regroupe : une dmarche qui consiste en un ensemble ordonn de phases et dtapes dcrites en termes dactivits de production. La dmarche a pour but de guider le travail des dveloppeurs pour arriver un rsultat autrement dit un dlivrable, des concepts bass sur les paradigmes de dveloppement et qui permettent de crer des modles susamment explicites pour que lon en ait une reprsentation unique (exemple : une classe est un concept introduit par le paradigme orient objet), des notations qui permettent dintroduire une syntaxe et une smantique permettant dexprimer les spcications (voir section 3.1), des outils qui permettent la production des spcications selon des modles et des diagrammes dnis par les notations. Ces outils permettent davoir des spcications propres, lisibles, facilement modiables. Ils permettent aussi la vrication de leurs syntaxes, leurs cohrences et de leur compltude. Les outils peuvent tre regroups dans des environnements. Une mthodologie va regrouper direntes mthodes conformes un paradigme de dveloppement. Ces mthodes vont tre appliques tout au 45
CHAPITRE 3. INGNIERIE DES SYSTMES MULTI-AGENTS long du cycle de vie. Rappelons quun cycle de vie est un ensemble ordonn dtapes de dveloppement. Le cycle de vie de logiciel passe par direntes tapes concernant des points aussi divers que la faisabilit, la spcication, la production, les tests, lutilisation du logiciel, sa vente et sa maintenance. Le cycle de vie est souvent organis (de manire explicite ou pas) selon un modle qui peut tre en cascades [Boe76], en spirale [Boe88], en V, etc. Le modle de cycle de vie peut tre explicit ou pas au niveau de la mthodologie. Le modle de cycle de vie caractrise le processus logiciel qui dcrit lenchanement des tapes de la conception la maintenance dun produit logiciel. Une mthodologie peut couvrir une partie ou lensemble du processus de dveloppement.
3.3
Les plates-formes dimplmentation
Limplmentation dun systme consiste en sa ralisation pratique sur une plate-forme particulire. La plate-forme est une infrastructure de logiciels utilise comme environnement pour le dploiement et lexcution du systme. Elle doit fournir des manires confortables pour crer et tester des entits logiciels selon un paradigme de dveloppement particulier. Ainsi, nous trouvons des plates-formes ddies aux paradigmes procduraux, objets, composants, agents etc. Elle peut tre vu comme une collection de services oerts aux dveloppeurs, mais galement aux entits logicielles en excution. Ainsi, une plate-forme devrait agir en tant quun mdiateur entre le systme dexploitation et les applications dveloppes sur cette plate-forme. Les plates-formes peuvent tre considres comme des EDI ddis la phase dimplmentation du systme. Dans ce qui suit, nous allons prsenter un panorama comportant des exemples de langages, mthodologies et plates-formes orientes agents.
Les langages de spcication orients agent
Plusieurs langages de modlisation ont t proposs dans le contexte de lingnierie oriente agent. Dirents courants ont t appliqus pour la construction de ces langages. Ainsi, nous distinguons : les langages bass sur une extension dUML, par exemple AUML [BMO01], AML [CT04], les langages raliss par cration de prol UML, par exemple AORML [WT03], les notations graphiques, par exemple OPM/MAS[SDS03].
4.1
Les langages bass sur une extension dUML
Lextension du langage UML sobtient grce la notion de strotype. Un certain nombre de strotypes sont prdnis. Cest le cas par exemple 46
Fig. 3.8: Les branchements dnis dans AUML du strotype "interface", mais un utilisateur peut en dnir dautres en fonction de ses besoins. Ceci permet dtendre le nombre de diagrammes utilisables. Dans notre contexte, nous allons prendre lexemple de deux langages qui ont utilis cette alternative pour dnir une nouvelle notation supportant certains concepts des systmes multi-agents ; cest le cas notamment des langages AUML [BMO01], [HOB04] et AML[CTCG05]. AUML porte essentiellement sur les protocoles dinteractions entre agents. Ce langage a dni des types de branchements dans les diagrammes de squence an de prendre en compte lindterminisme du comportement dun agent. Ces branchements peuvent tre AND (ET logique), OR (OU logique) XOR (OU exclusif)(voir gure 3.8). AUML prend en compte dautres considrations telle la spcication des rles dans les dirents diagrammes, o les classes du diagramme de squences gnrique sont annotes Classe/Rle. Le tableau 4.1 rsume les concepts pris en compte dans la notation AUML. Du fait quAUML soit une extention dUML, il peut tre appliqu avec les outils UML classiques. De la mme faon, AML [CT04] [CTCG05] est aussi un langage de modlisation des systmes multi-agents bass sur une extension de UML 2.0. AML fournit un certain nombre dlments conus pour dcrire dirents aspects. On trouve notamment la modlisation des ontologies, des aspects sociaux et mentaux, des interactions, du comportement ainsi que la dcomposition du comportement sur plusieurs agents etc.
4.2
Les langages raliss par cration de prol UML
Une autre manire de crer des langages bass sur UML est de crer des prols. Un prol UML permet de spcialiser UML un domaine particulier. Un prol est compos de strotypes, de tagged values et de contraintes. Gnralement, la cration de prol UML est accompagne par la dnition de rgles de gnration de code. Par exemple, les prols standards (EJB, 47
CHAPITRE 3. INGNIERIE DES SYSTMES MULTI-AGENTS Concepts Modliss Agent Rle Interaction Notation AUML Diagramme de classes : strotype "Agent" description dtats, actions, mthodes, capabilit, protocoles supports, contraintes Diagramme de classes : strotype "Role" Spcication dun template UML Diagramme dinteraction tendu dune branche XOR pour prendre en compte lindterminisme Message asynchrone : che simple Message synchrone : che remplie Dcrite au niveau du diagramme de squences avec un rectangle aux angles arrondis Tab. 3.1: La notation AUML CORBA) proposent quasiment tous des rgles de gnration de code. Dans le contexte orient agent, nous pouvons prendre lexemple de AORML (pour Agent-Object Relationship Modeling Language) [WT03] qui utilise cette technique. AORML est un prol UML pour lanalyse et la conception de systmes dinformation organisationnels bass sur les agents. Deux sortes de modles sont proposs par cette notation : externes et internes. Les modles externes prsentent les interactions entre les agents ainsi que leur relation avec les objets de leur environnement. Les modles internes sont le moyen de dnir le comportement interne des agents . Les actions et comportements des agents, dans la vue interne, sont dcrits grce des rseaux de Petri. Par contre, cette notation ne prend pas en compte lauto-organisation ou la coopration. Le tableau 4.2 rsume les concepts pris en compte dans la notation AORML. Lapplication de cette notation se fait travers loutil Microsoft Visio template.
Message Action
4.3
Les notations graphiques
Ces notations ne sont pas bases sur le langage UML. Elles dnissent des icnes traduisant les concepts orients agent. Le langage graphique orient agent le plus connu est OPM/MAS [SDS03]. Celui-ci est considr comme un langage complet. En eet, plus dune vingtaine de types de ches, de 48
CHAPITRE 3. INGNIERIE DES SYSTMES MULTI-AGENTS Vue Externe Passage de messages Evnements non communicatifs Evnements de non action Evnements dactions Vue Interne Reprsentation interne de lenvironnement chez lagent Utilisation des rseaux de Petri
Interaction entre agents Interaction entre objets et agents
Agent Action
Tab. 3.2: Les concepts manipuls par AORML noeuds ou de liens ayant des sens dirents ou proches sont dnis par cette notation. Le langage supporte notamment la modlisation de la vue statique du systme ainsi que la vue dynamique. Une vue densemble sur les concepts supports par OPM/MAS ainsi que la smantique qui a t adopte est fournie dans le tableau 4.3. Ce langage a une grande expressivit mais il est trs dicile manipuler vu le nombre lev des lments graphiques qui le contituent. Son application demande donc du recul.
Les mthodologies orientes Agent
La particularit des concepts utiliss dans les systmes multi-agents rend lutilisation des mthodologies traditionnelles obsoltes. En eet, ces concepts ont particulirement lev le niveau dabstraction, ils couvrent une smantique trs large et ont des interrelations trs complexes. Ainsi, pour aider le concepteur dvelopper ce type de systme, plusieurs mthodologies orientes agent ont t proposes. Il nexiste pas lheure actuelle une mthodologie unie pour assister le dveloppement des systmes multi-agents. Actuellement, les travaux sur la dimension mthodologique prend en compte divers aspects. Il est dicile dans ce contexte de pouvoir les comparer. La problmatique de la comparaison des mthodes et mthodologies a t souvent souleve dans la littrature pour aider le concepteur choisir celles qui sont les plus adaptes au problme donn. Shehory et Sturm ou bien Dam et Winiko comparent les mthodes suivant quatre ou cinq axes : les concepts manipuls, les notations utilises, le processus de dveloppement et la pragmatique [SS03] [DW03]. Bernon et al. [BGPG02], utilisent huit critres pour comparer les mthodologies : ltendu de la couverture du processus, la spcialisation de la mthode une application, larchitecture dagent sous-jacente, lutilisation de notations existantes, le domaine dappli49
Organisation Socit Rle Protocole Faits Buts Services Rgles
Agents Tches
Messages
Vue statique compos dun ensemble de rles Exhibe des organisations, des agents et des rgles Le rle est jou dans des organisations par des agents et doit respecter les rgles de la socit Le protocole est exhib par des agents Peuvent reprsenter des croyances, des dsirs ou des intentions Les dsirs peuvent tre considrs comme des buts Ils sont exhibs par les agents et exhibent leur tour des taches. Un service peut tre compos par un autre service. Elles sont exprimes au niveau des socits et doivent tre respectes au niveau de llaboration des rles Vue dynamique Processus compos de tches et qui fournit des services, participe des protocoles et joue des rles Elles sont ralies par les rles ou les services. Une tche peut tre compose par une autre. Elles peuvent eectuer des changements sur les objets ou les faits. Pour leur excution, elles peuvent avoir besoin des conversations. Lance un processus messaging qui peut aecter des objets. Ce processus peut avoir besoin des protocoles et des conversations.
Tab. 3.3: Les concepts manipuls par OPM/MAS
50
CHAPITRE 3. INGNIERIE DES SYSTMES MULTI-AGENTS cation (dynamique ou non), le modle de rle, le modle de lenvironnement et lidentication des agents. Plus rcemment, Cernuzzi et al. [CCZ05] se focalise sur les modles de cycles de vie qui ont t adopts dans les direntes mthodologies. Ils ont aussi prcis le degr de recouvrement de chaque phase de dveloppement (voir gure 3.9).
[CCZ05] Fig. 3.9: Une classication des mthodologies Enn, nous pouvons aussi citer les travaux de Santos et al. [SRB06] qui proposent une table dvaluation multi-critres. Ces travaux peuvent tre considrs comme les plus complets. Ils se basent en eet sur 12 critres dvaluation qui sont : la dnition du processus, lutilisation dUML, la prise en compte des caractristiques dadaptation (lagent est-il capable de sadapter diverses situations en apprenant de son exprience ?), dapprentissage (lagent est-il capable dapprendre apprhender son environnement ?)et de composition (est-il possible de composer plusieurs agents dans un environnement ?), de mobilit (les agents sont-ils capables de migrer dune plate-forme une autre ?), la reprsentation explicite de la structure organisationnelle, 51
CHAPITRE 3. INGNIERIE DES SYSTMES MULTI-AGENTS le traage des modles (cest--dire garder la trace les dirents modles dvelopps tout au long du dveloppement), la capture des besoins, lidentication des agents, linteraction entre les agents, le modle interne des agents, la plate-forme dimplmentation, la modlisation du processus organisationnel, la structure des messages. Notre but dans cette tude est de vrier la compltude ainsi que la cohrence des mthodologies (aussi bien au niveau de la smantique des concepts quau niveau du dveloppement tout au long du cycle de vie). Nous allons nous focaliser sur les critres suivants : les types de systmes cibls : comme nous lavons vu, les systmes multi-agents traitent divers types de systmes comme les systmes adaptatifs, les systmes distribus, les systmes base de connaissances, etc. Certaines mthodologies sont prescrites pour traiter certains types de systmes alors que dautres sont plus gnralistes, le mtamodle : plusieurs concepts ont t introduits pour traiter les systmes multi-agents. Ces concepts sont dirents dune mthodologie une autre. Llaboration dun mtamodle associ chaque mthodologie a permis de dcrire les concepts qui y sont utiliss, les notations : les notations adoptes pour dcrire les modles orients agent sont direntes. Certaines se basent sur UML et les langages bass sur des extensions dUML, dautres se basent sur dautres langages formels ou informels, les outils : certaines mthodologies sont fournies avec des outils spciques, le processus de dveloppement : le processus de dveloppement (qui spcie la manire dont le dveloppement est organis en phases indpendamment du type de support technologique utilis dans le dveloppement [DKW99]) est dirent selon les mthodologies proposes. Dans notre comparaison, nous nous sommes focaliss sur des exemples de mthodologies tels que ADELFE [BCP05], Gaia [ZJW03], Ingenias [PGS03], PASSI [CGSS05] et Tropos [BPSM05].
5.1
La mthodologie ADELFE
ADELFE (Atelier pour le DEveloppement de Logiciels Fonctionnalit Emergente) [BCP05] est une mthodologie ddie la conception des systmes adaptatifs. Ces systmes sont capables de sadapter un environnement fortement dynamique. Leur conception impose une mthode rigoureuse qui se distingue de lapproche globale descendante. ADELFE est une mtho52
CHAPITRE 3. INGNIERIE DES SYSTMES MULTI-AGENTS dologie qui a pour but de guider les dveloppeurs lors du dveloppement de ces systmes en appliquant les thories adaptatives des systmes multiagents. Elle propose un processus, des notations et des outils.
Le mtamodle Les systmes adaptatifs sont bass sur des agents coopratifs qui exhibent des comportements sociaux. Lors du dveloppement, les dirents agents du systme sont dnis. Ceux-ci sont dots daptitude pour dcider de leurs interactions. Ainsi, le concepteur de lapplication implmente les agents ; puis le systme en fonctionnement se recongure de manire automatique par auto-organisation sans lintervention du concepteur. Pour dnir ce genre de systme, ADELFE se focalise principalement sur la constitution des agents coopratifs. Le mtamodle adopt par ADELFE (voir gure 3.10) met en vidence ce type dagents. Selon ce mtamodle, un systme multi-agent adaptatif est compos par un ou plusieurs agents coopratifs qui observent des rgles de coopration et qui ont une reprsentation du monde. Les rgles de coopration sont relies des situations non coopratives, cest--dire des situations qui ne sont pas prises en charge. Celles-ci peuvent tre de plusieurs types : incomprhension, ambigut, incomptence (la requte ne peut tre satisfaite), improductivit (ne sait pas traiter les informations perues), concurrence et conit. Quand lagent est face ces situations, il devrait tre capable de les rsoudre, en cas dincomprhension par exemple, il pourrait envoyer la requte vers un autre agent quil croit capable de la rsoudre. ADELFE considre que les agents ont une reprsentation du monde rel qui est constitue par sa perception de lenvironnement physique, ses croyances par rapport aux autres agents et sa perception de lui-mme. Cette perception est dcrite au niveau du composant "Representation". Les agents sont aussi constitus dautres composants : les aptitudes, les comptences, les caractristiques et les communications. Les aptitudes sont les capacits de raisonnement de lagent, elles sont exprimes soit par des systmes dinfrence soit par des donnes simples. Un agent a ses propres comptences qui lui permettent de raliser ses fonctions. Les caractristiques sont les proprits de lagent. Enn, le composant communication dcrit toutes les communications possibles entre les dirents agents. Les patterns de communication correspondants peuvent tre dnis au niveau des AIPs (Agent Interaction Protocol). Lenvironnement est explicitement dni dans le mtamodle ADELFE. Il contient un ou plusieurs lments que les agents peuvent percevoir. Ce 53
Fig. 3.10: Le mtamodle dADELFE
54
CHAPITRE 3. INGNIERIE DES SYSTMES MULTI-AGENTS mtamodle est intressant puisquil dcrit dune manire assez complte les caractristiques des agents coopratifs. Cependant, il reste trs spcique aux systmes bass sur la coopration des agents. Ce mtamodle nest donc pas gnrique. De plus, ADELFE ne peut pas tre considr comme un mtamodle exhaustif puisquil est principalement centr sur la coopration entre les agents. Il ne dcrit pas les autres concepts quon peut trouver dans la littrature tels que lorganisation, les plans, les tches, les actions.
Les notations Dans ADELFE, le choix a t fait dutiliser les notations ddies lobjet et plus particulirement la notation UML. Ce choix est justi par le fait quun agent peut tre vu comme une volution de lobjet et possde de nombreux points communs avec ce dernier [Ode02]. Cependant, lobjet, en tant que tel, nest pas susant pour exprimer les concepts propres aux agents. Dans ADELFE, les agents coopratifs sont composs de modules spciques, suivent un cycle de vie "perception-dcision-action" et peuvent participer des ngociations complexes dans lesquelles peuvent survenir des situations non coopratives. Ces aspects ont t traits en utilisant un prol UML [Des00] qui permet de dnir des strotypes de manire exible. Dans ADELFE, neuf strotypes ont t dnis pour exprimer comment un agent est form et/ou comment son comportement peut tre exprim. Ces strotypes permettent de traiter les agents comme des classes ayant une smantique particulire. Le strotype "cooperative agent" exprime quune classe est un agent qui a une attitude cooprative. Cette classe abstraite possde une opration run simulant le cycle de vie de lagent. Dautre part, cette classe possde galement les oprations perceive, decide et act. Lagent est activ par lopration run. Le strotype "characteristic" est utilis pour pointer les proprits intrinsques ou physiques dun agent coopratif. Un attribut ainsi strotyp reprsente la valeur de cette proprit. Une caractristique peut tre lue ou modie nimporte quel moment du cycle de vie de lagent ou par une opration galement strotype characteristic. Ce type dopration peut tre appel par les autres agents. Pour mieux expliciter la notion dun attribut strotyp characteristic, nous pouvons prendre comme exemple une application de robotique. Les robots peuvent tre modliss en tant quagents, les attributs caractristiques peuvent tre le nombre de roues, leur couleur, leur poids, leur position dans lespace, la vitesse maximum de dplacement, etc.
55
CHAPITRE 3. INGNIERIE DES SYSTMES MULTI-AGENTS Le strotype "perception" exprime la perception de lenvironnement physique ou social. Ce strotype sapplique sur les attributs et les oprations. Les attributs reprsentent les donnes provenant de lenvironnement alors que les oprations sont des moyens de mettre jour ces donnes. Le strotype "action" est utilis pour signaler un moyen dagir sur lenvironnement durant la phase daction. Les oprations sont les actions possibles pour un agent, alors que les attributs sont des paramtres de ces actions. Un agent est le seul pouvoir activer ses propres actions an de conserver son autonomie. Ainsi, une opration ou un attribut strotyp "action" est ncessairement priv. Le strotype "skill" est utilis pour tiqueter les comptences qui sont des connaissances spciques un domaine. Les oprations reprsentent les rgles de raisonnement que peuvent avoir les agents. Les attributs sont des donnes (ou faits) sur le monde ou les paramtres des oprations strotypes skill. Ces attributs ou oprations sont galement privs an de conserver lautonomie de lagent. Les oprations peuvent tre appeles uniquement lors de la phase de dcision de lagent. Le strotype "aptitude" exprime la capacit dun agent raisonner sur ses perceptions, ses connaissances et ses comptences. Les oprations expriment le raisonnement quun agent est capable de faire, par exemple de linfrence sur ses comptences (qui peuvent alors tre des rgles et des faits). Les attributs reprsentent les donnes de fonctionnement ou les paramtres du raisonnement. Une opration ou attribut strotyp aptitude peut seulement tre accessible lagent lui-mme, pour exprimer son autonomie de dcision. Le strotype "representation" est un moyen dindiquer les reprsentations du monde que possde lagent. Les attributs strotyp representation sont des units de connaissances. Les oprations representation sont des moyens de les manipuler. Etant donn que les connaissances dun agent sont locales et personnelles ( moins quil ne les communique via des messages par exemple), les attributs et les oprations representation sont privs. Le strotype "interaction" tiquette les outils qui permettent lagent de communication. Ainsi, les oprations interaction expriment la capacit dun agent interagir avec les autres alors que les attributs interaction reprsentent les donnes de fonctionnement ou les paramtres des interactions. Le strotype "cooperation" implante les rgles de rsolution des situations non coopratives. Ces rgles permettent la fois de dtecter ces situations et de les rsoudre. Les oprations cooperation sont prioritaires sur les 56
CHAPITRE 3. INGNIERIE DES SYSTMES MULTI-AGENTS actions choisies en cas de fonctionnement normal. Les aspects dynamiques ont t modliss grce des machines tats nis et des diagrammes dinteraction. Les machines tats nis modlisent le comportement interne de lagent. An de reprsenter les interactions entre les agents, ADELFE utilise la notation A-UML (c.f. section 4.1).
Les outils ADELFE possde deux sortes doutils : OpenTool pour prendre en charge les notations et AdelfeToolkit pour prendre en charge le processus. OpenTool qui a t propos par TNI(www.tni.fr), est un outil de conception UML semblable Rational Rose. Il a lavantage dtre facilement modiable en fonction des besoins des utilisateurs. Une version dOpenTool a pu ainsi tre modie pour rpondre aux spcications dADELFE : OpenTool UML1.4 / Adelfe 1.2. Cette modication concerne principalement lintgration des strotypes spciques ADELFE ainsi que leurs rgles de bonne utilisation et lintgration des diagrammes de protocole A-UML. Le suivi du processus de dveloppement est ralis par loutil AdelfeToolkit. Celui-ci permet de faire une synthse sur les tches dj ralises, les artefacts dj eectus et ceux qui restent faire.
Le processus de dveloppement Le processus de dveloppement dADELFE est bas sur le processus RUP(Rational Unied Process). Au niveau de la mthodologie ADELFE, quatre phases de dveloppement sont couvertes : la collecte des besoins prliminaires, la collecte des besoins naux, lanalyse et la conception. ADELFE a reprsent son processus de dveloppement de manire explicite en utilisant la notation SPEM (Software Process Engineering Meta-model) [Gro02] qui est un prol UML ddi la reprsentation des processus [GMP03]. La notation SPEM introduit trois concepts selon lesquels a t dcrit le processus ADELFE : dnitions de travail (WorkDenition ou WDi ) : pour reprsenter les phases du RUP (Expression des besoins, Analyse et Conception), activits (Activity ou Aj ) : qui dcomposition chaque phase en plusieurs activits, tapes (Step ou Sk ) : qui dcompose chaque activit en plusieurs tapes. 57
Fig. 3.11: Le processus ADELFE Pour tenir compte des spcicits des agents, certaines tapes et activits ont t rajoutes aux quatre phases cites pralablement. Le processus dtaill dADELFE est dcrit dans la gure 3.11 (dans cette gure, la notation utilise nest pas celle de SPEM). Analyse et conclusion ADELFE fournit une mthodologie interessante aidant au prototypage rapide des systmes multi-agents adaptatifs. Les modles de ADELFE sont exprims par une volution des langages UML et AUML. Ceci permet au dveloppeurs familiariss avec ces notations de facilement ladopter. De plus, contrairement certaines mthodologies, ADELFE modlise explicitement son processus de dveloppement. Le droulement de ce processus est pris en charge par loutil AdelfeToolkit, ce qui facilite sa mise en uvre et son suivi. Cependant, nous pouvons noter que le processus de dveloppement nest pas entirement couvert. Ainsi, les phases postrieures la conception telles que limplmentation ou la validation ne sont pas encore traites. Actuellement, le prototype dAdelfeTookit vrie uniquement la production, mais non la validit ou la pertinence des productions. Nous relevons donc labsence de 58
CHAPITRE 3. INGNIERIE DES SYSTMES MULTI-AGENTS vrication smantique. Dans les concepts introduits par ADELFE, nous remarquons labsence de laspect organisationnel (structure organisationnelle, rgles organisationnelles, rle etc.) ce qui oblige le concepteur assurer la synchronisation entre les dirents agents suivant leurs comportements et leurs comptences. Le concepteur doit exprimer sa structure organisationnelle sous forme de rgles de coopration propres chaque agent. Ainsi, lorganisation dans ADELFE est connue travers un comportement mergent. Enn, un des principaux points faibles est le manque de fondements thoriques formels sur lesquels ADELFE peut se reposer pour aider une conception sre en terme de spcication des comportements des agents. Ces fondements formels peuvent aider tudier les proprits des systmes multiagents et contribuer ainsi une meilleure matrise des thories de lmergence et de lauto-organisation.
5.2
La mthodologie Gaia
La mthodologie Gaia [WJK00] [ZJW03] utilise une approche centre sur lorganisation pour analyser et concevoir un systme multi-agents. Elle est considre comme une mthodologie gnrique permettant le dveloppement de tous types de systmes. Gaia prend en considration deux niveaux : un macro-niveau (qui modlise une socit dagents) et un micro-niveau (qui se focalise sur lagent).
Le mtamodle Le mtamodle fourni par Gaia (cf. gure 3.12) est principalement bas sur deux concepts : lorganisation et le rle. Un systme multi-agents est structur par une ou plusieurs organisations. Ces organisations dnissent des rgles organisationnelles telles que la vivacit et la sret. Ces rgles vont permettre de structurer les communications et les rles. Les organisations sont contenues dans une structure. Elles obissent une topologie et un rgime de contrle.
59
Fig. 3.12: Le mtamodle Gaia
Lorganisation contient plusieurs agents qui fournissent des services et qui collaborent entre eux. Un agent joue un ou plusieurs rles. Le rle a des responsabilits et respecte les proprits de vivacit et de sret. Le rle permet galement lagent - si la permission lui est accorde - daccder aux ressources de lenvironnement. Le rle dnit des activits. Selon la smantique adopte par Gaia, les activits sont lquivalent des mthodes dans le paradigme orient objet. Elles correspondent une unit daction que lagent excute sans quil nait recours une interaction avec un autre agent. Enn, le rle permet lagent de participer ou dtre linitiateur de communication. Ces communications sont structures selon un protocole qui est considr comme une activit qui ncessite linteraction avec dautres agents. 60
CHAPITRE 3. INGNIERIE DES SYSTMES MULTI-AGENTS Les notations
Gaia ne fournit pas de notations graphiques proprement parler. Elle fournit cependant des tables permettant de dcrire certains modles. En se basant sur le mtamodle prsent prcdemment, Gaia introduit six principaux modles danalyse et de conception : le modle de rle : il identie les dirents rles devant tre jous par les agents du systme. Le modle de rle est dcrit par une table comprenant quatre parties. La premire partie correspond une description textuelle du rle. La deuxime partie dcrit les activits et les protocoles correspondant au rle. La troisime partie dcrit les permissions. Dans cette partie les ressources sont reprsentes par des variables labellises et les permissions par des attributs dcrivant les droits octroys pour manipuler les ressources (lecture, criture, etc.). Enn la quatrime partie dcrit les responsabilits du rle travers des proprits de scurit et de sret. Celles-ci sont exprimes en utilisant les oprateurs de logique temporelle. Un exemple du modle de rle reprsentant le rle dun reviewer est donn dans la gure 3.13.
Fig. 3.13: Exemple de modle de rle [ZJW03]
le modle dinteraction : il dnit les protocoles de communication entre agents. Dans Gaia, un protocole dnit une action demandant une interaction entre deux agents. Le modle dinteraction est dni par une table comprenant un label, un expditeur, un rcepteur, une description, des entres et des sorties et une description textuelle. La gure 3.14 reprsente un exemple de table dinteraction illustrant la rception dun papier par un reviewer, 61
Fig. 3.14: Exemple de modle dinteraction [ZJW03] le modle dagent : il attribue les rles aux dirents agents du systme. Il identie les dirents types dagents et leurs instances. Ce modle est une arborescence dont les racines correspondent aux agents et les feuilles correspondent aux rles qui leur sont associs, le modle de service : il dnit les dirents services oerts par le systme. Un service est vu comme une fonction quun rle ore. Ainsi, chaque protocole identi dans le modle de rle va se transformer en service. Chaque service possde les caractristiques suivantes : des entres, des sorties, des pr-conditions dexcution et des post-conditions. Les pr et post-conditions sont extraites partir des proprit de sret dnies dans le modle de rle, le modle dorganisation ou daccointances : il dnit les liens de communication entre les dirents types dagents. La structure de lorganisation est reprsente par des graphes orients dont les nuds correspondent aux types agents alors que les arcs reprsentent les liens de communication entre ces noeuds, le modle environnemental : il dcrit les direntes ressources accessibles caractrises par les types dactions que les agents peuvent entreprendre pour les modier. La notation introduite par Gaia est considre comme semi-formelle. Elle a t applique avec une grande facilit et plusieurs exemples pdagogiques ont t publis (dont lorganisation dune confrence ou ltude dun systme manufacturier [ZJW03]). Nous remarquons dans cette notation que les aspects dynamiques ne sont pas rellement modliss. Ces aspects sont uniquement introduits au niveau des proprits de sret et de vivacit. Pour pallier ce problme, lutilisation de AUML a t suggre [CZ04]. Les outils A ce jour, il nexiste pas doutils supportant lapplication de la mthodologie Gaia. Par consquent, le dveloppeur ne peut pas exploiter ou rutiliser les modles Gaia. 62
CHAPITRE 3. INGNIERIE DES SYSTMES MULTI-AGENTS Le processus de dveloppement Tout comme ADELFE, le processus de dveloppement de Gaia ne couvre que quelques phases de dveloppement : la collecte des besoins, lanalyse et la conception. La gure 3.15 montre comment est organis ce processus et quels sont les modles laborer dans chaque phase.
Fig. 3.15: Le processus de dveloppement Gaia A partir de la collecte des besoins, le systme est divis en plusieurs sous-organisations. Pour chaque sous-organisation, les modles prliminaires de rle et dinteraction sont raliss ainsi que le modle denvironnement. Au niveau de ces dirents modles, les rgles organisationnelles (sret et vivacit) sont identies. Au niveau de la conception, les modles de rle et dinteraction sont rafns et les modles dagent, dorganisation et de service sont labors ce qui permet didentier les patterns organisationnels qui peuvent tre rutilisables. La phase dimplmentation est aussi mentionne bien quelle ne soit pas encore rellement traite. Moraitis et al. [MPS02] proposent cependant une dmarche qui permet de passer dune modlisation Gaia une implmentation avec la plate-forme JADE. Analyse et conclusion La mthodologie Gaia oriente le dveloppement vers la spcication des organisations, ce qui est considr comme une manire plus "naturelle" dap63
CHAPITRE 3. INGNIERIE DES SYSTMES MULTI-AGENTS prhender le dveloppement des systmes multi-agents [FGM03]. Les modles proposs par Gaia rendent la manipulation des concepts de base tels que lagent, lenvironnement, lorganisation et linteraction facile ce qui a certainement fait sa popularit. Le fait de pouvoir exprimer les proprits de vivacit et de sret permet davoir une conception prcise. Cependant, ceci ncessite une grande expertise de la logique temporelle. Par contre, plusieurs inconvnients peuvent tre relevs. Tout dabord la notation adopte dans Gaia est plutt limite. Elle peut tre bien adapte pour lanalyse des systmes mais ne peut couvrir une conception dtaille. Nous pouvons aussi noter que la gestion de la complexit organisationnelle ou fonctionnelle nest pas prise en compte. Gaia est limite aux applications agents forte granularit, peu nombreux, et avec une organisation statique, ce qui rend le passage lchelle dicile. De plus, elle ne peut permettre lapplication des thories dmergence, dauto-adaptation et dintelligence or ces thories constituent une forte valeur ajoute des systmes multi-agents. Le processus de dveloppement couvert par Gaia est trs limit et ne dpasse pas la phase de conception. Il ny a donc pas de phase de vrication/validation. La gestion de projet, comme celle labore dans ADELFE nest pas prise en compte. Nanmoins, les dlivrables et dirents modles fournir au cours du processus sont trs clairement dnis.
5.3
La mthodologie Ingenias
Dans Ingenias [PGS03], lapproche gnrale pour spcier un systme multi-agents consiste diviser le problme en plusieurs aspects plus concrets qui forment les direntes vues du systme. Le but global dIngenias est de fournir un ensemble de mthodes et doutils de dveloppement gnriques permettant le dveloppement des systmes multi-agents. Ingenias est fonde sur la dnition de mtamodles dcrivant les diffrents aspects dun systme multi-agents ainsi que leurs relations. Sur cet aspect, Ingenias sinscrit dans la continuit de la mthodologie MESSAGE [CLC+ 01] [FGSP04] qui a appliqu les techniques de mtamodlisation dans le domaine des systmes multi-agents. Ingenias a fait voluer les mtamodles en incorporant dautres concepts. Les modles sont ensuite construits avec des instances des entits mtamodles. Ainsi, le mtamodle est considr comme la dnition des langages de modlisation pour la description des systmes multi-agents. 64
CHAPITRE 3. INGNIERIE DES SYSTMES MULTI-AGENTS Le mtamodle Ingenias considre cinq perspectives (ou vues) dans un systme multiagents : lagent lorganisation les interactions les tches et les buts lenvironnement La gure 3.16 rsume les mtamodles adopts par Ingenias. En eet, au niveau de la mthodologie, chaque perspective est dcrite de manire dtaille par un mtamodle.
Fig. 3.16: Un mtamodle Ingenias rsum [CBP05] La perspective Agent dcrit lagent comme tant une entit autonome faisant parti dun groupe. Il est responsable de lexcution de certaines tches. Lagent a un tat mental et des buts qui permettent de dnir le contrle de lagent. Les entits mentales sont produites et consommes par les tches. Lagent peut initier ou collaborer une interaction. 65
La perspective Organisation tablit larchitecture du systme. La vision de lorganisation adopte dans Ingenias partage celle prsente par Ferber et Gutknecht [FG98] et qui stipule quil y a des relations structurelles qui ne peuvent pas tre restreintes des hirarchies entre rles. Ces structures sont dlgues des entits spcialises qui sont les groupes. Les groupes incluent des applications, des ressources, des agents et des rles. Il nexiste pas dans ce mtamodle de liens directs entre ces dirents concepts. Le lien se fait travers les tches. Ces tches sont dnies soit par les rles, soit par les agents. Pendant leur excution, celles-ci vont utiliser des applications, consommer des ressources, aecter et consommer des entits mentales et produire des interactions. Tout comme lagent, lorganisation est aussi considre comme une entit autonome poursuivant un but. Les fonctionnalits de lorganisation sont exprims par des workows qui montrent les associations producteur-consommateur entre tches ainsi que les responsabilits pour leur excution, et les ressources associes chacune. La perspective Environnement identie les ressources et les applications existantes. La perspective Buts-Tches identie les buts et les tches. La ralisation des buts seectue travers lexcution de certaines tches. Aussi, il faut identier les ressources ncessaires pour lexcution des tches ainsi que les composants logiciels (applications) ncessaires. Certaines tches produisent des interactions ncessaires la ralisation dun but. Enn, la perspective Interaction dcrit comment se ralise la coordination entre les agents. La rlisation dune interaction est motive par la ralisation dun but. Compte tenu quune interaction est ralise par une tche relie lagent ou au rle, celle-ci peut aecter ltat mental des agents. Ce mtamodle donne une vue globale des concepts associs Ingenias. Comme nous lavons mentionn au dbut du paragraphe, chaque perspective est dcrite par son propre mtamodle. Ceux-ci sont ensuite utiliss pour gnrer les modles correspondants. Cette opration nest cependant pas triviale vu les direntes dpendances qui existent entre les perspectives. Par exemple, les tches dans le workows du modle organisationnel devraient tre dcrites aussi dans la perspective buts-tches. Les notations Les perspectives dcrites prcdemment constituent la base du dveloppement et sont ranes tout au long du cycle de dveloppement. Ingenias nintroduit pas une notation spcique pour produire les spcications, mais 66
Fig. 3.17: Un rsume du mtamodle Ingenias [Pav06] se contente de bien dnir les smantiques des concepts qui vont tre utiliss. Ainsi, Ingenias ore une grande exibilit concernant les notations utiliser. Divers diagrammes peuvent tre utiliss pour dcrire les spcications. Ces diagrammes doivent respecter la smantique dcrite au niveau du mtamodle. Ingenias adopte deux sortes de notations : des notations bases sur une extension du langage UML, des icnes spciques respectant la smantique des concepts dcrits dans le mtamodle. Par exemple, pour dcrire la perspective Agent, Ingenias propose lutilisation des strotypes UML qui font rfrence aux entits de mtamodle, ou bien un ensemble dicnes spciques (cf. gure 3.17). De mme, la perspective interaction peut tre spcie avec direntes notations : avec un diagramme de collaboration dUML, le diagramme dinteraction de GRASIA (GRupo de Agentes Software :Ingenieria y Aplicaciones), ou avec un diagramme de protocole dAUML. Ceci fournit une grande exibilit aux dveloppeurs puisque ceux-ci peuvent utiliser les notations qui leur sont familires. Les outils Ingenias fournit un environnement de dveloppement appel IDK (Ingenias Development Kit). Ce kit est un ensemble ouvert doutils bass sur les mtamodles dIngenias. LIDK ore : lditeur Ingenias : cest loutil de dveloppement principal dIngenias. 67
CHAPITRE 3. INGNIERIE DES SYSTMES MULTI-AGENTS Cest un support de modlisation facilitant la cration et la modication des diagrammes. An de grer le grand nombre de diagrammes pouvant tre produits pour modliser un systme multi-agents, lditeur permet de les structurer en une hirarchie de paquets. LIDK a une reprsentation des mtamodles dIngenias via XML. Celle-ci dnit les concepts, les relations, les diagrammes de mtamodle, ainsi que les associations entre les concepts et les lments graphiques qui les reprsentent. les modules IDK : ce sont des outils pour la vrication et la validation des modles, ainsi que des moteurs de transformation qui visent driver le code pour la plate-forme nale. Ainsi, ces outils traitent des spcications pour produire en sortie : le code source (des templates pour chaque plate-forme cible sont spcies ainsi que des procdures dextraction dinformation des modles), des rapports (analysant les spcications pour recueillir une information statistique sur lutilisation des dirents lments), et des transformations vers dautres modles. LIDK est trs important dans le processus de dveloppement dIngenias puisquil permet le dveloppement rapide dapplications, le dcouplage des spcications de limplmentation, et la vrication de la spcication suivant les besoins dimplmentation. Le processus de dveloppement Ingenias couvre les phases danalyse, de conception, de codage et dimplmentation. Son processus de dveloppement est bas sur un cycle de dveloppement standard : le Processus Uni (Unied Process). Cependant, Ingenias rane ce processus de dveloppement en dcrivant avec plus de dtail les activits pouvant tre ralises dans la phase danalyse et de conception [Pav06]. Ces activits sont en fait, bases sur lapproche dirige par les modles (brivement prsente dans la section 5.3 du chapitre 2) qui se base elle-mme sur la spcication des mtamodles et la transformation successives des modles jusquau code source. Ingenias identie deux types principaux de rles dans le processus de dveloppement : le dveloppeur des SMA qui utilise lditeur de lIDK pour spcier les modles qui dcrivent le systme multi-agents. Ces modles peuvent tre vris et valids avec des modules dIDK. Une fois valids, les modules de gnration de code facilitent limplmentation pour la plateforme cible. lingnieur Ingenias qui connat le mtamodle Ingenias et peut travailler sur les outils de lIDK. Celui-ci va tre responsable de la production de nouveaux modules pour vrier les proprits de modles bass sur de nouveaux concepts qui viennent tendre les mtamodles dIngenias ou pour la gnration de code en une plate-forme cible sp68
CHAPITRE 3. INGNIERIE DES SYSTMES MULTI-AGENTS cique. Il est possible galement de personnaliser lditeur pour un propos spcique, par exemple, pour ladapter un langage de modlisation spcique du domaine dapplication. Ce dernier exige de modier le mtamodle et demande une connaissance plus approfondie du mtamodle Ingenias.
Analyse et conclusion La mthodologie Ingenias ore une manire trs exible pour le dveloppement des systmes multi-agents. Elle applique une technique dingnierie base sur lapproche IDM (Ingnierie Dirige par les Modles) qui permet le passage des modles vers le code. Un des grands avantages dIngenias est le fait davoir un environnement de dveloppement orant les outils ncessaires pour lapplication de la mthodologie. Cependant, nous pouvons reprocher Ingenias le manque de formalisme permettant de spcier et de vrier les proprits relatives aux SMA telles que les proprits de vivacit et sret. Ces proprits, bien quelles soient considres comme des proprits comportementales devraient tre prise en compte trs tt au niveau du cycle de vie. Leur conservation devraient tre garanties au niveau du code source gnr. De plus, lIDK nore pas de formalisme pouvant exprimer explicitement les rgles de transformation et de gnration de code, ce qui ne permet pas de conserver le savoir-faire.
5.4
La mthodologie PASSI
PASSI (Process for Agent Societies Specication and Implementation) [CGSS05] est une mthodologie se basant sur des concepts provenant de lingnierie oriente objet et de lintelligence articielle. PASSI est une mthodologie gnrique pouvant sappliquer nimporte quel domaine. PASSI a la particularit de prendre en compte la modlisation des agents mobiles. Cette modlisation respecte les spcications FIPA.
Le mtamodle Le mtamodle PASSI est dcompos en trois domaines(cf. gure 3.18) : le domaine de la solution le domaine dagence le domaine du problme 69
Fig. 3.18: Le mtamodle PASSI [CBP05] Au niveau du domaine du problme, la capture des besoins est eectue et traduite en terme de scnarios (qui dcrivent les interactions entre les acteurs et le systme) et denvironnement. Lenvironnement est dni par un ensemble dlments ontologiques : les concepts qui dnissent les direntes catgories du domaine, les actions qui regroupent les oprations pouvant tre excutes et les prdicats qui permettent dajouter des lments dans le domaine. Lenvironnement contient aussi des ressources auxquelles lagent va accder. Le "domaine dagence" reprsente les agents qui peuvent avoir connaissance des lments ontologiques, des besoins fonctionnels et non fonctionnels dnis dans la couche prcdente. Les agents accdent aux ressources. Ils ont au moins un rle qui propose des services, eectuent des tches, dnissent des communications et excutent les scnarios. Les communications sont constitues de messages dnis par des performatives qui vont spcier la smantique du contenu. Les performatives sont contenues dans les protocoles dinteraction qui structurent les communications. 70
CHAPITRE 3. INGNIERIE DES SYSTMES MULTI-AGENTS Au niveau du domaine de solution la structure de limplmentation est spcie. Selon PASSI, limplmentation doit tre compatible la plateforme FIPA. Ainsi, trois lments vont tre choisis : FIPA-Plateform Agent qui dnit la classe qui va implmenter lagent, FIPA-Platform Task qui dnit la structure dimplmentation des tches et Service Description qui va implmenter les services. Les notations PASSI rutilise fortement UML [CP01]. En se basant sur cette notation, PASSI fournit cinq modles permettant de dcrire les concepts identis au niveau du mta-mtamodle. Ces modles sont : modle de collecte des besoins : celui-ci est utilis ds les premires phases relatives la collecte des besoins. Il permet "dagentier" le systme dvelopper cest--dire de le dcrire sous forme dagents, de rles et de taches. De plus ce modle permet de dcrire le domaine dapplication. Pour cela il utilise le diagramme de cas dutilisation dUML, de paquetages strotyps, le diagramme de squences (associs aux cas dutilisation) et le diagramme dactivits, modle de socit dagents : regroupe la description de trois concepts qui sont les ontologies, les rles et les protocoles dinteraction. Ce modle est focalis sur la description des interactions sociales ainsi que les dpendances entre les agents, modle dimplmentation : permet de dnir les constituants des agents en terme de ressources internes, de connaissances (attributs) et de tches. Ce modle permet galement la dnition du comportement des agents grce des diagrammes dactivits o apparaissent les tches des agents ainsi que leurs interactions. Ce modle est ralis par les diagrammes de classes et dactivits classiques, modle de code : permet didentier les modules rutilisables dans le cas o un dveloppement pralable a t ralis. Au mme titre que le modle dimplmentation, le modle de code est ralis par les diagrammes de classes et dactivits, modle de dploiement : permet de spcier la conguration du systme. Ce modle est ralis par les diagrammes de dploiement UML. Les outils La modlisation avec PASSI est supporte par loutil PTK (PASSI Toolkit) [CCS04]. PTK est un add-in de Rational Rose. En eet, tous les diagrammes et strotypes spciques sont intgrs dans une extension au logiciel Rational Rose, an de raliser les modles danalyse et conception de manire ergonomique.
71
CHAPITRE 3. INGNIERIE DES SYSTMES MULTI-AGENTS Le processus de dveloppement Le processus de PASSI est un processus pas--pas, mais ritrable. Il est compos de cinq phases, composes dtapes, correspondant aux spcications des cinq modles prsents prcdemment.
Fig. 3.19: Le processus PASSI [CP01]
Analyse et conclusion PASSI couvre pratiquement la totalit des phases du cycle de dveloppement. Son utilisation est facile puisquelle est base sur une extension du langage UML. Son application ne ncessite donc pas une expertise particulire (bien que la connaissance des spcications FIPA soit prfrable). PASSI est compltement dissocie des plates-formes dimplmentation bien que loutil PTK soit orient vers la gnration de code en Java an dtre compatible avec JADE et FIPA-OS. Nous pouvons reprocher PASSI, le manque de formalisme qui rend dicile lexpression des proprits telles que la vivacit et la sret. Aussi, le fait dtre base sur un langage semi-formel tel que UML rend les phases de tests et de vrication peu ecaces. 72
5.5
La mthodologie Tropos
Tropos [CGSS05] est une mthodologie de dveloppement fonde sur les concepts utiliss en ingnierie des besoins [GKMP04]. Elle adopte une approche transformationnelle, dans le sens o, chaque tape, les modles vont tre rans de manire itrative par ajout ou suppression dlments ou de relations dans les modles. Le mtamodle Tropos a t conu en se basant sur une approche oriente buts. Le mtamodle [GKMP04] dni par cette mthodologie met ainsi en vidence le concept but qui est dni par une classe "Goal". Deux sous-classes manent de celle-ci : "HardGoal" et "SoftGoal". "HardGoal" dcrit les besoins fonctionnels tandis que "SoftGoal" dcrit les besoins non fonctionnels. La ralisation de ces buts est eectue par lapplication dun ou plusieurs plans.
[CBP05] Fig. 3.20: Le mtamodle Tropos Ces plans sont relis aux acteurs, cest dire les dirents participants au systme (agent, acteur humain, etc.). Les agents hritent de la classe acteur, de mme que le rle et la position. La position est en fait un ensemble de rle. Un agent peut occuper une ou plusieurs positions qui vont lui assigner plusieurs rles. Les acteurs utilisent des ressources et lancent lexcution dun plan.
73
CHAPITRE 3. INGNIERIE DES SYSTMES MULTI-AGENTS Une classe "dpendance" spcie les direntes relations de dpendances entre les agents. Elle indique quun acteur dpend dun autre an datteindre un but, excuter un plan, ou fournir une ressource. Le premier acteur source sappelle le depender, le deuxime acteur est un dependee et lobjet de leur dpendance est le dependum qui peut tre un but, une ressource ou une tche. Ce mtamodle dnit les concepts de la notation i*, qui est le langage adopt par Tropos (voir 5.5). Cependant, dautres concepts sont manipuls qui napparaissent pas dans ce mtamodle tels que les capacits (qui modlisent les capacits dun acteur dnir, choisir et excuter un plan pour remplir un but), les croyances (qui sont une reprsentation de la connaissance dun acteur sur le monde) et les contributions (qui permettent de notier si les plans contribuent de manire positive ou ngative dans la ralisation dun but). Les notations Tropos utilise principalement i* pour modliser les systmes. Ce langage se focalise sur lingnierie des besoins centre sur les caractristiques intentionnelles des agents (leurs buts) [YM94]. Ce langage manipule les dirents concepts du mtamodle. Cest un langage graphique qui est facilement comprhensible. Cependant, les diagrammes qui modlisent de relles applications complexes peuvent vite devenir illisibles. Par ailleurs, i* ne peut tre utilis que dans la phase danalyse puisquil permet uniquement dexprimer les besoins. Pour cette raison, Tropos a recours lutilisation dautres notations telles que les diagrammes dtats/transitions pour modliser les capacits et les plans. Les interactions entre agents sont spcies grce des diagrammes de protocole AUML. Une approche plus formelle, appele Formal Tropos [PPRS03], propose des descriptions textuelles et logiques des besoins. Les descriptions logiques sont bases sur la logique temporelle. Ces descriptions textuelles et logiques peuvent tre par la suite traduites automatiquement vers i*. Ceci ajoute de la prcision aux notations et langages et rend les diagrammes vriables. Ces direntes notations, sont utilises pour produire les principaux diagrammes suivants : diagramme dacteur : il dcrit les acteurs, leurs buts et leurs dpendances. Ce type de diagramme est employ pour dnir les besoins des utilisateurs du systme, pour montrer leurs intentions ainsi que les relations entre les acteurs. Ce diagramme reprsente un acteur par un noeud et les dpendances par les liens entre les nuds, diagramme de but : il montre la structure interne dun acteur (ses buts, ses plans et ses ressources) et les rapports entre eux, 74
CHAPITRE 3. INGNIERIE DES SYSTMES MULTI-AGENTS diagramme de comptence : chaque comptence (ou ensemble corrl de comptences) est modlise par un diagramme dtats/transitions. Les vnements externes dclenchent ltat du diagramme de comptence ; les plans sont dcrits par les noeuds du diagramme, les arcs des transitions modlisent les vnements et les croyances, diagramme de plan : chaque noeud de plan du diagramme de comptences peut tre encore dtaill par un diagramme dactivits UML, diagramme dinteraction dagent : pour dcrire linteraction des agents, Tropos utilise des diagrammes AUML. Les outils Plusieurs outils aident lapplication de la mthodologie Tropos. T-Tool [KPR03] est un outil utilisable durant les phases prliminaires de collecte des besoins. Il permet lanalyse et la validation des spcications dcrites durant cette phase en utilisant les notations formelles introduites par Formal Tropos. T-Tool applique pour cela la technique du model checking. T-Tool permet par ailleurs danimer certains modles an dtre valids par les dveloppeurs. GR-Tool [SPM04] est aussi fourni par la mthodologie Tropos. Cest un outil de conception graphique permettant de spcier les diagrammes de buts et excuter les algorithmes qui leur correspond. Tropos fournit aussi ST-Tool (Secure Tropos tool) [GMMZ04] qui est un diteur graphique qui permet de spcier des diagrammes de scurit. Ces diagrammes, qui viennent tendre la mthodologie Tropos, permettent de spcier les rgles de scurit. Enn, TAOM4E est une plate-forme permettant lintgration de dirents outils de manire exible. Le but tant dappliquer lapproche dirige par les modles. [BGG+ 04b]. Le processus de dveloppement Tropos couvre une grande partie du cycle de dveloppement. Elle suit une approche incrmentale par ranement itratif. La dmarche propose par Tropos se dcompose en cinq phases [GMP02] : lanalyse des besoins initiaux permet une comprhension du problme. Cette phase permet didentier les principaux acteurs et leurs buts respectifs dans le systme. A ce niveau les diagrammes dacteurs et de buts sont labors, lanalyse des besoins naux fournit une description du systme dans son environnement oprationnel et modlise le systme en tant quensemble dacteurs possdant des dpendances. Cette phase permet de raner les modles prcdents, la conception architecturale dnit larchitecture globale du systme en termes de sous-systmes interconnects par des ots de donnes et 75
CHAPITRE 3. INGNIERIE DES SYSTMES MULTI-AGENTS de contrle. Ces sous-systmes sont reprsents comme des acteurs et les interconnexions comme des dpendances entre acteurs. Plusieurs styles darchitectures (structure plate, pyramidale, etc.) sont fournis, la conception dtaille dnit chaque composant architectural en termes dentres, de sorties, de contrle, etc. Cette phase permet de dtailler la communication entre acteurs et le comportement des acteurs en diffrents niveaux. Un niveau dtaille un dialogue intra-acteur ou interacteurs. Le niveau le plus bas dcrit le traitement interne dun acteur via des diagrammes de plans, limplantation fournit une architecture dagents BDI sur la plate-forme Jack [BRHL99]. Analyse et conclusion Tropos est une mthodologie gnrique pouvant tre applique des contextes dirents. Cette mthodologie ore une manire exible pour dvelopper des systmes multi-agents assistes par plusieurs outils de dveloppement. Tropos couvre la totalit du cycle de dveloppement, et se base sur une notation formelle (Formal Tropos) qui lui permet de vrier et valider ses modles. Cependant, celles-ci ne sont applicables que durant les phases dingnierie des besoins. Dun autre cot, les activits et les dlivrables associs au sein des phases ne sont pas si clairement dnis et la lecture de nombreux articles est ncessaire. De plus, Tropos ne couvre quun ensemble limit de concepts orients agent. La dimension organisationnelle, par exemple, nest pas prise en compte de manire explicite.
5.6
Comparaison
La comparaison des mthodologies fait ressortir toute la diversit des techniques dingnierie oriente agent. Ces mthodologies se limitent parfois des aspects trs spciques des systmes multi-agents ou bien ne couvrent pas la totalit du processus de dveloppement. Gnralement, ce sont les phases danalyse et de conception qui sont les plus couvertes. Ceci ncessite parfois le passage dune mthodologie une autre an de pouvoir couvrir la conception de tout le systme. On parle alors de fragments de mthodes pour construire des mthodologies exibles [CGGS07]. Ceci serait rellement facilit si ces direntes mthodologies sont conformes un mme mtamodle gnrique. Cependant, dans ltat actuel des choses, les mthodologies ont dni leur propre mtamodle an de spcier et de dnir les concepts quelles utilisent. Ces mtamodles restent orients vers les caractristiques de chaque mthodologie et sont ainsi trs dirents les uns des autres. Un courant vers une unication des mthodologies commence apparatre. Nous dtaillons ceci dans la section suivante. 76
5.7
Unication des mtamodles
C. Bernon, M. Cossentino et M.P. Gleizes [BCG+ 04] proposent dunier les mtamodles proposs par les mthodologies ADELFE, PASSI et Gaia. Lunication des mtamodles consiste rcuprer les concepts utiliss dans chacun deux. Ainsi, pour la structure de lagent, les concepts utiliss dans ADELFE ont t mixs avec ceux de PASSI et ceux de Gaia. La mme chose a t faite pour les interactions. Les structures organisationnelles et sociales ont t dcrites quant elles selon les concepts de Gaia et PASSI. Enn limplmentation a aussi t prise en compte selon ce qui a t dni dans PASSI. La gure suivante montre le rsultat de cette unication :
Fig. 3.21: Le mtamodle uni [CBP05]
Le mtamodle gnr suite lunication dADELFE, PASSI et Gaia est plus complet et plus gnrique. Cependant, celui-ci mixe des concepts de haut niveau et des concepts lis limplmentation. Nous pensons que ceci prive le concepteur de son libre choix de la plate-forme dimplmentation. De plus, certains concepts ne sont pas pris en compte. Nous citons principalement les buts, les plans, les normes, etc. 77
Les plates-formes orientes Agent
Tout comme les mthodologies, il existe une multitude de plates-formes multi-agents ddies dirents modles dagent. Les plates-formes fournissent une couche dabstraction permettant de facilement implmenter les concepts des systmes multi-agents. Dun autre cot, elle permet aussi le dploiement de ces systmes. Ainsi, elles constituent un receptacle au sein duquel les agents peuvent sexcuter et voluer. En eet, les plates-formes sont un environnement permettant de grer le cycle de vie des agents et dans lequel les agents ont accs certains services. Comme le choix dune plate-forme dagent a une grande inuence sur la conception et la mise en uvre des agents, FIPA a produit les normes qui decrivent comment une plate-forme dagent devrait tre. Ces normes existent pour assurer une conception uniforme des agents indpendamment de la plate-forme. Dans ce qui suit, nous prsentons quelques plates-formes. Cette liste nest pas exhaustive. Elle reprsente cependant les plates-formes les plus utilises et les plus cites dans la littrature. Pour comparer les direntes platesformes, nous appliquons un cadre de comparaison qui se base sur les lments suivants : les types de systmes viss : certaines plates-formes sont conues pour dvelopper des applications dans des domaines spciques tel que la simulation, les systmes distribus, etc. les modles dagents suports : certaines plates-formes imposent un modle dagent spcique (agent BDI, agent collaboratif, etc.). les mthodologies : certaines plates-formes proposent une mthodologie de dveloppement, dautres plates-formes sont utilises par certaines mthodologies orientes agent. le langage dimplmentation appliqu : gnralement, le langage dimplmentation qui est adopt par les plates-formes est Java. Nous tudierons les classes abstraites qui sont fournies par la plate-forme, qui aident architecturer les applications.
6.1
La plate-forme ZEUS
Zeus [CNNL98] est une plate-forme ddie pour la construction rapide dapplications base dagents collaboratifs. Elle se prte bien aux systmes conomiques qui utilisent des applications de planication ou dordonnancement. Pour implmenter les agents collaboratifs, Zeus se base principalement sur les concepts agents, buts, tches (que les agents doivent raliser pour atteindre leurs buts) et faits (qui reprsentent les croyances des agents). Un 78
CHAPITRE 3. INGNIERIE DES SYSTMES MULTI-AGENTS agent dans Zeus est constitu en trois couches : la couche de dnition, qui contient les capacits de raisonnement et des algorithmes dapprentissage, la couche organisationnelle, qui contient la base de connaissances et des accointances de lagent, et la couche de coordination, qui dnit les interactions avec les autres agents. Zeus propose aussi un ensemble dagents utilitaires (serveur de nommage et facilitateur) pour faciliter la recherche dagents. Zeus fournit aussi une mthodologie qui se base sur quatre phases pour la construction dagents : lanalyse du domaine : consiste modliser des rles. A ce stade aucun outil logiciel nest fournit et le langage UML est utilis. la conception : consiste spcier des buts et des tches qui permettent de les raliser. Cette spcication se fait par le langage naturel et nest supporte par aucun outil. le dveloppement : Cette phase est ralise en quatre tapes : cration de lontologie, cration des agents, conguration de lagent utilitaire, conguration de lagent tche et implmentation des agents.Des outils supportant des notations graphiques sont fournies an daider llaboration de ces tapes. le dploiement : dans cette phase, le systme multi-agents est lanc. Un outil de visualisation permet le suivi de lexcution. Cet outil permet de visualiser lorganisation, les interactions ayant lieu dans la socit dagents, la dcomposition des tches et ltat interne des agents. Zeus fournit un environnement de dveloppement dagents grce un ensemble de bibliothques Java que les dveloppeurs peuvent rutiliser pour crer leurs agents.
6.2
La plate-forme JADE
La plate-forme JADE (Java Agent DEvelopment framework) [BPR99] est certainement celle qui est la plus utilise par la communaut des systmes multi-agents. JADE permet de dvelopper et dexcuter des applications distribues bases sur le concept dagents et dagents mobiles. Elle est compatible la plate-forme FIPA. Les agents dans JADE sont implments selon 6 proprits : Autonomie : les agents ont leurs propres thread de contrle qui leur permet de contrler leurs actions, de prendre leurs propres dcisions an de raliser leurs buts mais aussi de contrler leur cycle de vie. Ractivit : les agents peuvent percevoir les vnements de leur environnement et ragissent en fonction de ces vnements, Aspects sociaux : les agents exhibent des aspects sociaux qui leur permettent de communiquer et dinteragir entre eux. La communication 79
CHAPITRE 3. INGNIERIE DES SYSTMES MULTI-AGENTS se fait travers le passage de messages asynchrones. La communication est considre comme un type dactions et peuvent de ce fait intgrer un plan dactions. Les messages ont une smantique et une structure dnis par le standard FIPA. Dynamicit : les agents ont la possibilit de dcouvrir dynamiquement dautres agents et de communiquer avec eux. Ore de service : chaque agent ore un ensemble de services, il peut enregistrer ses services et les modier. Il a aussi la possibilit de chercher des agents qui orent les services dont il a besoin. Mobilit : les agents dans Jade ont la possibilit de se dplacer. Les agents sont implments dans des conteneurs et ils peuvent se dplacer. Cest un composant complmentaire ajout Jade pour permettre dintgrer limplmentation de larchitecture interne des agents. Jadex [PBL05] [SBPL06] prend en compte larchitecture des agents hybrides (cest--dire des agents qui sont la fois ractifs et proactifs). Pour les agents proactifs, jadex se base sur le modle BDI. Jade assure la scurit en orant aux applications des systmes dauthentication qui vrient les droits daccs des agents. Jade nore pas de mthodologie, par contre plusieurs mthodologies la prennent comme plate-forme cible lors de la gnration de code tel que Gaia et PASSI. Limplmentation de Jade est base sur Java. La plate-forme peut tre rpartie sur un ensemble de machines et congure distance. La conguration du systme peut voluer dynamiquement puisque la plate-forme supporte la mobilit des agents.
6.3
La plate-forme MADKIT
La plate-forme MadKit (Multi-Agents Developement kit) [FG00] est dveloppe lUniversit de Montpellier II. Bien quelle puisse supporter le dveloppement de divers systmes, elle semble bien adapte pour les application de simulation. La plate-forme MADKIT est base sur les concepts agent, groupe et rle (gure 3.22). Ces concepts sont appliqus de la manire suivante : lagent : quasiment aucune contrainte nest pose sur larchitecture interne ou le modle de comportement de lagent. Lagent est simplement dcrit comme une entit autonome communicante qui joue des rles au sein de dirents groupes. La faible smantique associe lagent est volontaire ; lobjectif tant de laisser le choix au concepteur pour choisir larchitecture interne approprie son domaine applicatif. le groupe : chaque agent peut tre membre dun ou plusieurs groupes. 80
Fig. 3.22: Le mtamodle AALAADIN Il sert identier la structure organisationnelle dun systme multiagents usuel. le rle : il est considr comme une reprsentation abstraite dune fonction ou dun service. Chaque agent peut avoir plusieurs rles et un mme rle peut tre tenu par plusieurs agents. Les rles sont locaux aux groupes. Cette implmentation correspond la conception ralise au niveau de la mthodologie AALAADIN. En eet, partir des concepts AGR, cette mthodologie dnit une dmarche de dveloppement axe sur la spcication du cadre organisationnel des applications multi-agents. Cette dmarche dnit lensemble des rles possibles, spcie les interactions, et dcrit les structures abstraites de groupe. MadKit fournit une API permettant la construction dagent en spcialisant une classe dagent abstraite. Les agents sont lancs par le noyau de MadKit, qui propose notamment les services de gestion des groupes et de communication. Lchange des messages se fait travers le rle que lagent est en train de jouer.
6.4
La plate-forme AgentBuilder
AgentBuilder est une suite intgre doutils permettant de construire des agents intelligents. Cette plate-forme est adapte pour tous types de systmes. Llaboration du comportement des agents se fait partir du modle BDI et du langage AGENT-0. KQML est utilis comme langage de communication entre les agents. AgentBuilder est compos dune interface graphique et dun langage orient agent permettant de dnir des croyances, des engagements et des actions. Il permet galement de dnir des ontologies et des protocoles de communications inter-agents. Les agents sont dcrits avec le langage Radl (Reticular Agent Denition Language), qui permet de dnir les rgles du comportement de lagent. Les rgles se dclenchent en fonction 81
CHAPITRE 3. INGNIERIE DES SYSTMES MULTI-AGENTS de certaines conditions et sont associes des actions. Les conditions portent sur les messages reus par lagent tandis que les actions correspondent linvocation de mthodes Java. Il est aussi possible de dcrire des protocoles dnissant les messages accepts et mis par lagent. AgentBuilder propose lutilisation de la mthode OMT durant la phase danalyse. OMT permet de spcier des objets du domaine et les oprations quils peuvent eectuer. A partir de cette spcication une ontologie du domaine est cre. Des outils graphiques sont fournis pour eectuer ces tches. Durant la phase de conception, les agents sont identis et des fonctionnalits leur sont assignes. Leurs rles et leurs caractristiques sont dnis ainsi que les protocoles dinteraction auxquels ils participent. Durant la phase de dveloppement, le comportement de lagent est dni ainsi que ses croyances, intentions et capacits. Durant le dploiement, le code de lagent est interprt par le Run-Time Agent Engine.
Analyse et conclusion
Ltude des direntes techniques dingnierie prsentes tout au long de ce chapitre, fait ressortir plusieurs constats que nous allons exposer dans ce qui suit. 1. Direntes vues du systme peuvent tre spcies Pour simplier la comprhension ainsi que le dveloppement des systmes multi-agents, il est prfrable de considrer plusieurs vues. Lors de la premire section, nous avons adopt la dcomposition Voyelles qui considre la vue Agent, Environnement, Interaction et Organisation. Nous avons remarqu quau niveau des mthodologies, dautres vues sont considres. Par exemple, dans Ingenias, six vues (cas dutilisation, agent, organisation, interaction, "tches & buts" et environnement) ont t adoptes. Au niveau des autres mthodologies, les vues nont pas t explicites. Nous pouvons cependant dduire quADELFE met plus en valeur la vue Agent et Interaction. Gaia est plus oriente vers lOrganisation. PASSI dnit une vue du domaine, une vue sur le systmes multi-agent (incluant agents, services et interaction) et une vue sur limplmentation du systme. Enn Tropos soriente plus vers les buts et les interactions. La dicult dans le dveloppement orient agent est le fait que ces direntes vues sont fortement interrelies et la dnition des concepts lis chaque vue nest pas chose aise. Ainsi, mettre en valeur une vue plutt quune autre peut dpendre entirement du domaine dapplication. 2. Dnition de dirents concepts 82
CHAPITRE 3. INGNIERIE DES SYSTMES MULTI-AGENTS Les mtamodles adopts dans chaque mthodologie, prennent en compte des concepts dirents. Ceci implique que les modles utiliss au niveau de lanalyse et de la conception sont dirents smantiquement et structurellement. Aucun problme particulier ne sera pos, si les mthodologies couvraient entirement le processus de dveloppement ainsi que les direntes vues du systme. Mais tel nest pas le cas. Comme nous avons pu le constater, les mthodologies couvrent gnralement une partie du cycle de dveloppement ou une vue partielle du systme. Prenons lexemple de la mthodologie PASSI. Celle-ci peut tre considre parmi les plus complte. Nous remarquerons cependant que les phases de validation et de maintenance ne sont pas couvertes ce qui constitue un rel problme dans le cas des systmes multi-agents qui sont considrs comme des systmes complexes et volutifs. Un dveloppement sr et cohrent est important dans ce cas. Pour cette raison, des tapes de validation doivent tre proposes chaque phase de dveloppement. De plus, une relle prise en charge de la maintenance permet de contrler lexcution du systme ainsi que son volution. 3. Cycle de dveloppement Nous remarquons aussi quun large foss spare les phases danalyse/conception des phases dimplmentation. En eet, rares sont les mthodologies qui prennent en compte la phase dimplmentation et la gnration de code vers une plate-forme spcique. Au niveau des mthodologies que nous avons exposes dans ce chapitre, loutil PTK de PASSI permet de gnrer du code vers JADE alors que Tropos gnre du code vers la plate-forme JACK. Cependant, les plates-formes ne couvrent pas tous les concepts pris en compte au niveau des modles produits par la mthodologie. Cest donc au dveloppeur que revient la charge de crer les entits correspondantes. 4. Notations orientes Agents Il est aussi important de soulever le fait que les notations orientes agent restent compltement dconnectes des mthodologies et plateformes dimplmentation (bien que AUML soit utilis dans plusieurs mthodologies). Dans ce contexte, lutilisation de ces notations devient dicile. Suite aux constats lists prcdemment, nous avons identi plusieurs besoins lis lingnierie des systmes multi-agents. Dans le cadre de cette thse, nous nous concentrons sur deux besoins particuliers : 1. Cadre de dveloppement exible Nous pouvons dclarer que lapplication des systmes multi-agents 83
CHAPITRE 3. INGNIERIE DES SYSTMES MULTI-AGENTS soure de labsence de cadre de dveloppement exible et cohrent qui couvre les direntes vues dun systme multi-agent ainsi que les direntes phases de dveloppement. Bien quil existe plusieurs propositions intressantes aussi bien au niveau des mthodologies, des langages de spcication et des plates-formes dimplmentation, ces direntes propositions manquent de cohsion. Loin de prfrer une technique sur une autre, nous soulignons que dans le contexte des systmes multi-agents, des techniques exibles sont ncessaires. Dans ce contexte, nous adhrons lapproche adopte par Ingenias qui consiste diviser le problme en plusieurs aspects qui seront modliss par des mtamodles, les modles, les notations et les outils ncessaires seront alors gnrs partir de ces mtamodles. Lenvironnement de dveloppement est ainsi construit en fonction des besoins du dveloppeur. 2. Vrication et validation des modles Nous pouvons aussi constater que la validation des modles nest pratiquement pas aborde durant les direntes phases de dveloppement. Cette situation peut tre de deux causes principales : les mthodologies sont pratiquement toutes bases sur des langages informels ou semi-formels ce qui rend la vrication et la validation des modles difciles. La deuxime raison voque le manque doutillage permettant la vrication et la validation des proprits. Gaia est une mthodologie qui intgre lutilisation de la logique temporelle lors de la conception, ce qui permet dexprimer des proprits de sret et de vivacit. Or, aucun outil de validation nest fourni au sein de cette mthodologie qui permet de vrier si la conception faite respecte les proprits spcies. Par ailleurs, Tropos permet dexprimer et vrier les proprits en utilisant Formal Tropos et les outils qui lui sont associs (tel que TTool). Cependant, cette vrication nest valable que durant les phases dingnierie des besoins. Or, la vrication et validation des proprits ne trouvent leur intert que lorsque celles-ci sont conserves jusqu la phase dimplmentation voire de dploiement et de maintenance. Ainsi, il y a un grand besoin relatif aux notations permettant dexprimer diffrentes proprits ainsi quaux outils de vrication et validation. Il est en eet ncessaire davoir une conception sr an de produire des logiciels de qualit surtout dans le contexte des systmes orients agent. Suivant les besoins que nous avons identis dans cette section, nous exposons dans le chapitre suivant, les ventuelles approches dingnierie qui peuvent nous aider rsoudre ces deux points.
84
Chapitre 4 Vers un dveloppement exible et sr
CHAPITRE 4. VERS UN DVELOPPEMENT FLEXIBLE ET SR
Introduction
Nous avons vu lors du prcdent chapitre que les principaux besoins lis lingnierie des systmes multi-agents consistent dans la spcication dun cadre de dveloppement, dont les caractristiques sont : exible pour couvrir les direntes vues dun systme multi-agent, capable de grer la cohrence des direntes vues et la prservation de leurs proprits lors de leur intgration, An de rpondre ces besoins, et proposer au nal un cadre de dveloppement sr, cohrent et formel, nous avons analys les direntes avances faites au niveau des techniques dingnierie actuelles (c.f. chapitre 2). Les problmatiques souleves dans le cadre des systmes multi-agents rencontrent celles qui sont souleves lors de lapplication dautres paradigmes de dveloppement rcents tels que les composants logiciels et les services Web. Les avances eectues au niveau du gnie logiciel pour rsoudre ces problmatiques sont diverses (cf. chapitre 2). Notre choix sest port sur deux principales approches : Lingnierie dirige par les modles : qui nous permet dappliquer les techniques de mtamodlisation an dobtenir une exibilit dans la dnition des composants lis aux systmes. Lapproche dirige par les modles conoit lintgralit du cycle de vie comme un processus de production, de ranement itratif et dintgration de modles ; ce qui rejoint notre objectif. Le dveloppement orient architecture : qui se penche sur les techniques de description des modles architecturaux ainsi que leur intgration. 86
CHAPITRE 4. VERS UN DVELOPPEMENT FLEXIBLE ET SR En sabstrayant des dtails de limplmentation, larchitecture ore une vue globale du systme qui est lisible et qui expose les proprits les plus cruciales ; ce qui permet un dveloppement ecace. De plus, comme nous allons le dcrire lors de la section 3 de ce chapitre, le dveloppement orient architecture ore des moyens de formalisation qui facilitent lexpression et la vrication des proprits. Dans ce chapitre, nous commenons par une prsentation dtaille de la problmatique, dcline en plusieurs objectifs. Par la suite, nous prsentons plus profondment chacune de ces approches avec leurs apports pour le developpement des systmes multi-agents. Nous concluons ce chapitre par une mise en relation de ces deux approches, partir de laquelle nous construisons notre proposition (cf. chapitre 5).
Problmatique et objectifs de la thse
Nous avons vu lors du prcdent chapitre que les principaux besoins lis lingnierie des systmes multi-agents consistent la spcication dun cadre de dveloppement exible et cohrent qui couvre les direntes vues dun systme multi-agent ainsi que les direntes phases de dveloppement. En eet, nous avons pass en revue dans le chapitre 3 les concepts orients agent. Ceux-ci sont nombreux et leurs smantiques peuvent avoir plusieurs dclinaisons. Par exemple, un agent peut tre cognitif, ractif ou hybride. Il peut avoir une ou plusieurs interfaces travers lesquelles il peut percevoir son environnement ou communiquer avec dautres agents. Il peut poursuivre des buts ou orir des services. Il peut tre situ dans un environnement et peut appartenir une organisation sociale etc. La smantique dagent qui va tre utilise dpend largement du domaine dapplication. Ainsi, la spcication dun systme particulier ncessite une certaine exibilit o le dveloppeur peut dnir la smantique qui convient le plus son domaine dapplication. Dautre part, an de garantir un dveloppement de qualit, le cadre de dveloppement devrait permettre lexpression et la validation des proprits au cours du cycle de dveloppement. Les systmes multi-agents sont en eet des systme complexes ncessitant un grand nombre de composants interconnects. Dans un pareil contexte, il faut sassurer que les proprits fonctionnelles et non fonctionnelles restent conserves tout au long du cycle de dveloppement. Dans cette thse, nous proposons de construire un cadre de dveloppement qui permettra aux dveloppeurs de : sadapter aux dirents types de systmes multi-agents, 87
CHAPITRE 4. VERS UN DVELOPPEMENT FLEXIBLE ET SR dnir les direntes vues ncessaires au dveloppement de leur application ainsi que leurs concepts respectifs, dnir les mcanismes de ranement et de transformation qui permettent le passage de lanalyse/conception vers limplmentation et le dploiement, dnir les proprits ainsi que les moyens de vrication et de validation de ces proprits qui devraient tre conserves tout au long du cycle de dveloppement. La exibilit dun cadre de dveloppment peut tre obtenue grce lutilisation des mtamodles. En eet, tout domaine dapplication (tlcom, commerce lectronique, etc.) possde des concepts spciques. Ces concepts ainsi que leurs relations sont dcrits au niveau du mtamodle. Celui-ci est utilis pour prciser ce quest un composant logiciel pour un domaine particulier. Etant donn quil ny a pas de dnition unique des composants multi-agents, ce point nous semble important. De plus, nous avons not quau niveau des systmes multi-agents, une multitude de mtamodles peuvent tre exprims pour des utilisations diverses. Il est important, dans ce contexte, daccorder la libert au dveloppeur de dnir le mtamodle qui convient le plus ses besoins. Par ailleurs, nous avons vu que la complexit des systmes multi-agents ncessite leur dcomposition en plusieurs vues. Chaque vue peut tre dnie dans un mtamodle propre. Par la suite, les vues vont tre intgres pour obtenir le mtamodle complet dun systme particulier. De par cette manire de dnir un mtamodle, il est possible de disposer dun support complet, adapt une application particulire et respectant la sparation des proccupations. Notons que la sparation des proccupations permettra de capturer les proprits de chaque vue de manire plus aise. Le premier objectif de cette thse consiste orir les moyens au dveloppeur de dnir les mtamodles reprsentant les vues de leur systme. Au niveau de ces mtamodles, nous pensons que les contraintes structurelles et comportementales relatives aux entits contenues dans chaque vue doivent tre explicitement dnies. Dans ce contexte, INGENIAS adopte la mme approche base sur la mtamodlisation, ce qui permet de dnir les modles ncessaires chaque vue du systme multi-agents. Ces modles vont tre instancis au niveau des phases danalyse/conception an de dcrire lapplication qui est en cours de dveloppement. Des templates sont gnrs partir de ces vues qui sont intgrs et compils an de vrier leur validit. Cependant, nous avons soulev que les proprits structurelles et comportementales ne sont pas vries 88
CHAPITRE 4. VERS UN DVELOPPEMENT FLEXIBLE ET SR dans les phases danalyse et de conception. Ceci est principalement d au manque de formalisation. En eet, INGENIAS utilise des notations semiformelles, ce qui ne facilite pas la vrication de telles proprits. Le deuxime objectif de cette thse consiste orir les moyens aux dveloppeurs dexprimer les proprits fonctionnelles et non fonctionnelles de leur systme. Ces proprits doivent tre prserves tout au long du cycle de dveloppement. Pour cette raison, les moyens dexprimer ces proprits doivent alors tre accompagns doutils de vrication et de validation. Pour atteindre cet objectif, nous utiliserons au cours de cette thse des langages formels qui garantissent lexpression des proprits, leur vrication et leur validation durant les direntes phases de dveloppement. Nous avons aussi soulev le fait que les phases danalyse/conception soient compltement dissocies des phases dimplmentation/dploiement. Pour rsoudre cette problmatique, il est ncessaire dadopter un cycle de dveloppement permettant de guider les dveloppeurs durant les direntes phases en explicitant les rgles de passage dune phase une autre. Ceci peut correspondre par exemple, la dnition de rgles permettant de gnrer les modles partir du mtamodle ou spcier des rgles permettant le passage des modles vers le code, etc. Ces rgles sont en gnral appeles rgles de transformation et rgles de ranement (nous allons approfondir ces deux notions au cours de ce chapitre). Le troisime objectif de cette thse consiste dcrire les rgles de ranement et de transformation permettant le passage dune phase de dveloppement vers une autre.
Le dveloppement dirig par les modles
Le dveloppement dirig par les modles a t brivement introduit dans la section 5.3 du chapitre 2. Cette approche vise fournir un cadre conceptuel, technologique et mthodologique dans lequel les modles sont au centre des activits de dveloppement. Dans cette section, nous allons rappeler brivement les principes de cette approche avant dintroduire les principes de son application et consiste en ltude : des niveaux dabstraction considrs, des relations entre les niveaux, des transformations de modles, des processus de dveloppement mettre en uvre 89
3.1
Principes de lapproche
IDM spcie lintgralit du cycle de vie du logiciel comme un processus de production, de ranement itratif et dintgration de modles. En ce sens, IDM fait voluer lusage des modles. En eet, une traabilit entre les lments des dirents modles est garde et ceci quel que soit leur niveau dabstraction. Lutilisation des modles permet de capitaliser les connaissances quelles soient des connaissances du domaine mtier ou du domaine technique. Par ailleurs, la traabilit (entre les direntes vues du systme) ainsi que la transformation de modles (entre les direntes phases de dveloppement) permet de capitaliser le savoir-faire. Les travaux mens sur lIDM font suite la dnition de lapproche Model Driven Architecture (MDA) par lOMG (Object Management Group) [OMG03]. MDA a recours aux dirents standards de lOMG an de dcrire les dmarches bases sur lingnierie des modles. IDM entend ne pas se limiter au jeu de standards spciques un organisme particulier, et dsire proposer autour de la notion de modle et de mtamodle une vision unicatrice. Dans ce contexte, MDA est considr comme un exemple particulier dingnierie dirige par les modles. Nanmoins, la plupart des travaux sur lIDM font rfrence MDA. Cet tat de fait provient du fait que lOMG catalyse, centralise, et synthtise bon nombre de travaux sur lIDM. Pour cette raison, nous dtaillerons dans ce qui suit plusieurs travaux proposs dans le cadre de MDA.
3.2
Les quatre niveaux de OMG
An de mieux comprendre lapproche de lIDM, il convient de prciser plus en dtail la nature des modles utiliss tout au long du cycle de vie, les divers usages de ces modles, ainsi que les possibles intentions du concepteur au moment de leur construction. MDA a propos une architecture quatre niveaux qui structure les dirents modles pouvant tre produits lors de lapplication de lapproche de lIDM. Cette architecture fait maintenant lobjet dun consensus [Sei03], [BBB+ 05], on retrouve ainsi des rfrences cette architecture dans de nombreux travaux dsirant se situer par rapport lIDM [IEV05]. Cette architecture (cf. gure 4.1) comporte quatre niveaux dabstraction que nous allons dtailler dans ce qui suit. Le niveau M0 Le niveau M0, reprsente les objets du monde du rel. Il reprsente, par exemple, un compte bancaire avec son numro et son solde actuel (cf. gure 4.1). 90
CHAPITRE 4. VERS UN DVELOPPEMENT FLEXIBLE ET SR Le niveau M1 Cest au niveau M1 que les modles sont dits. Ces modles sont conformes aux mtamodles dnis au niveau M2. Ainsi, MDA considre que si lon veut dcrire des informations appartenant au niveau M0, il faut dabord construire un modle appartenant au niveau M1. De ce fait, un modle UML (comme le diagramme de classes ou le diagramme dtat/transition) est considr comme appartenant au niveau M1. Il reprsenterait des objets manipuls dans le monde rel (dcrits au niveau M0).
Le niveau M2 Le niveau M2, est le lieu de dnition des mtamodles. Un mtamodle peut tre considr comme un langage spcialis pour un aspect du systme. Il peut aussi dcrire les aspects spciques aux dirents domaines, chaque aspect tant pris en compte dans un mtamodle spcique. Les mtamodles contenus dans le niveau M2 sont tous des instances du niveau M3 (notons quau niveau M3, il ne peut y avoir quun seul mta-mtamodle). Dans le cadre de MDA, cest le mtamodle dUML [OMG04] qui est le plus utilis, celui-ci dnit la structure interne des modles UML.
Le niveau M3 Le niveau suprieur, M3 correspond au mta-mtamodle. Il dnit les notions de base permettant lexpression des mtamodles (niveau M2), et des modles (M1). Pour viter la multiplication des niveaux dabstraction, le niveau M3 est rexif, cest--dire quil se dnit par lui-mme. Le plus souvent, cest le mta-mtamodle MOF (Meta Object Facility) qui est utilis. Celui-ci est standardis par lOMG [OMG06]. Cependant dautres mtamtamodles ont t proposs tels que eCore dnit dans le cadre du "Eclipse Modeling Framework" (EMF) [BSE+ 03] et OWL [DGS06]. Des plates-formes de modlisation gnriques implmentant MOF permettent la production de mtamodles spciques des domaines et de produire ensuite des modeleurs spciques ce domaine. Par exemple, la plate-forme de mtamodlisation GME [LBM+ 01] est compatible avec eCore dEMF [BBB+ 05]. An davoir une ide plus prcise de larchitecture quatre niveaux dOMG, nous illustrons par la gure 4.1, les modles pouvant appartenir chaque couche. 91
Fig. 4.1: Les quatre niveaux de MDA
92
3.3
Les relations entre les modles
Les relations entre les modles appartenant aux quatre niveaux ont fait lobjet de plusieurs dbats [Fav04]. Les ches que nous avons annotes est un sur la gure 4.1 mritent un approfondissement de leur smantique. Nous pouvons aller jusqu dclarer que lapproche de lIDM repose sur la smantique adopte au niveau de ces ches. Actuellement, trois relations fondamentales sont identies : "reprsentation de", "tre conforme " et "tre instance de". la relation "reprsentation de" Cette relation (note ) lie le modle au systme quil reprsente. Cette relation traduit la smantique qui existe entre un systme et un modle. En eet, il est communment admis quun modle est la simplication subjective dun systme. Dans ce contexte, le modle sert obtenir des rponses par rapport au systme quil reprsente [BG01], [Bz04]. Par exemple, une carte gographique peut jouer le rle de modle, alors que la rgion tudie jouera celui de systme modlis. De mme quune carte elle-mme peut jouer le rle du systme modlis comme le montre la gure 4.2. Dans cette gure, la carte est elle mme reprsente par un schma XML.
Fig. 4.2: La relation [BBB+ 05] Il faut spcier par ailleurs, que dans la gure prcdente, le chier modlisant la carte ne peut tre considr comme un mtamodle. En eet, il existe une nuance entre la dnition dun modle et la dnition dun mtamodle. Alors quun modle est une description dun systme ou dune partie du systme [KWB03], un mtamodle est un modle qui dnit le langage qui exprime le modle. Ainsi, la relation "reprsentation de" peut dcrire le lien entre la couche M0 et M1, mais ne dcrit pas le lien entre les couches M1, M2 et M3. la relation "tre conforme " La relation "tre conforme " (note ) est plus approprie pour la description de liens entre les couches M1, M2 et M3. Elle spcie en eet la 93
CHAPITRE 4. VERS UN DVELOPPEMENT FLEXIBLE ET SR relation existante entre les modles et leur mtamodle. Manipuler informatiquement et oprationnaliser des modles ncessitent quils soient exprims dans un langage clairement dni. Larchitecture quatre niveaux permet davoir un cadre permettant cette dnition : un modle appartenant au niveau M1 est conforme un mtamodle dni au niveau M2, qui est luimme conforme un mta-mtamodle dni au niveau M3. La relation est considre comme le point cl de lapproche de lIDM. En eet, celle-ci permet dassurer dun point de vue thorique mais aussi oprationnel quun modle est correctement construit. A partir de ce moment, il devient envisageable de lui appliquer des transformations automatises. La gure 4.3 dmontre la relation entre une carte gographique et son mtamodle qui est constitu dune notation graphique reprsentant les rgions et les dpartements.
[BBB+ 05] Fig. 4.3: La relation
la relation "InstanceDe" MDA est principalement fonde sur lapproche oriente objet. Ceci a gnr de nombreuses confusions par rapport aux relations existantes entre les direntes couches de modles. La relation "InstanceDE" est un exemple qui incarne cette confusion. Au niveau du standard MDA, il a t largement relay par lOMG quun modle serait une "instance dun" mtamodle. Or, ceci fait rfrence lhypothse implicite que modles et mtamodles sont exprims dans une technologie oriente-objet. Il nexiste aucune contrainte de cette sorte dans lIDM. Lapproche IDM se veut indpendante de toute contrainte technologique, pour cette raison, la relation InstanceDe est considre comme une incarnation particulire de la relation ConformeA dans la technologie oriente objet [BBB+ 05]. 94
3.4
La transformation de modles
Les transformations de modles 1 sont au coeur de lapproche de lingnierie dirige par les modles. Elles reprsentent lun des grands ds relever dun point de vue technique pour envisager une large diusion de lingnierie dirige par les modles. La transformation de modles intresse aussi bien les chercheurs que les industriels. En eet, leur mise en uvre augmentera considrablement la productivit et la qualit des logiciels produits. Cependant, lheure actuelle, il nexiste pas encore de consensus sur la dnition et la mise en uvre dune transformation. Une transformation est une opration qui sert produire un modle (appel modle cible) partir dun autre modle (appel modle source). Plusieurs sortes de modles cibles et sources peuvent exister. Selon la nature des modles, plusieurs types de transformation sont rpertoris [MCG05] : Transformation du modle vers le code : dans lingnierie dirige par les modles, le code source est considr comme un modle ayant un bas niveau dabstraction (modle concret). Une telle transformation consiste gnrer du code partir dune spcication. Transformation du code vers le modle : dans une transformation le code source peut aussi jouer le rle de modle source. Il sagit alors de ringnierie des systmes. Transformation endognes et exognes : la transformation endogne implique des modles sources et cibles conformes au mme mtamodle ; alors quune transformation exogne implique des modles issus de mtamodles dirents. Dans ce dernier cas, on parle de translation. La gnration de code, la ringnierie ainsi que les migrations (cf. gure 4.4) sont des exemples typiques de translation (ou transformation exogne). Les transformations endognes peuvent quant elles servir loptimisation (pour amliorer la qualit du modle), la refactorisation (pour amliorer la lisibilit du modle), la simplication ou normalisation (pour limiter la complexit syntaxique relative un modle, il sagit par exemple de rajouter du sucre syntaxique). Transformation verticale et transformation horizontale : une transformation horizontale est une transformation o le modle cible et le modle source appartiennent au mme niveau dabstraction (un exemple de cette transformation est la refactorisation). La transformation verticale sapplique sur des modles appartenant des niveaux dabstraction dirents (exemple gnration de code). MDA dnit le langage QVT (Query/View/Transformation) [OMG05] comme standard pour la spcication des rgles de transformation. Ce lanDans cette section, le terme modle est utilis dans le sens large, et non pas en faisant rfrence la couche M1.
1
95
CHAPITRE 4. VERS UN DVELOPPEMENT FLEXIBLE ET SR gage est form de trois parties : la dnition de requtes qui permet une navigation dans les modles, la spcication de vues qui permet de focaliser sur une partie des modles, la spcication de rgles de transformations de modles dont lapplication permet de gnrer un modle source dun modle cible.
Dirents langages de transformation implmentent QVT (exemples SmartQVT [SMA06], Medini QVT [HSE06], OptimalJ [JSHL07] ) ou sen rapprochent (principalement ATL [JK06]). Ces langages se comparent selon diffrents critres, dnis par Czarnecki et al. [CH03] :
les rgles de transformation : avec ce critre, nous pouvons regarder la structure de construction des rgles de tranformation. Les rgles peuvent tre paramtres, dcrites dune manire dclarative, imprative ou hybride ( la fois dclarative et imprative). la porte dapplication des rgles : les rgles de transformation peuvent avoir comme porte la totalit du modle ou une partie du modle. les relations entre modle source et modle cible : ce critre compare la nature de relations qui peut exister entre le modle cible et le modle source. Celles-ci peuvent tre de deux types ; le modle cible est un nouveau modle dirent, cr partir du modle source ou le modle cible est le mme que le modle source sur lequel des modications ont t faites. la stratgie dapplication des rgles : lapplication des rgles peut tre dterministe (cest--dire que lexcution des rgles est faite de manire prtablie ou standard comme par exemple le parcours classique dun arbre) ; ou bien indterministe (cest--dire pouvant tre eectues dans un mode interactif voire concurrent). lordonnancement des rgles : ce critre vrie si lordre dapplication des rgles peut tre explicit. Dans le cas contraire cest loutil interprtant les rgles qui dtermine lordre. Lorganisation des rgles : ce critre vrie sil est possible de rassembler et dorganiser les rgles dans des modules. Il vrie galement si elles peuvent tre rutilises par dautres rgles en utilisant le mcanisme dhritage ou de composition. La traabilit : durant la transformation de modles, les liens de traabilit entre modles peuvent tre conservs. La direction : les rgles de transformation peuvent tre appliques de manire unidirectionnelle ou bidirectionnelle (dans ce cas la traabilit entre les modles doit tre conserve). 96
Fig. 4.4: Migration de modle objet un modle relationnel
3.5
Processus de dveloppement orient modles
Le modle de cycle de dveloppement ne fait pas encore lunanimit dans lingnierie dirige par les modles. Cependant, nous avons pu distinguer deux sortes de modles de cycle de vie. Le premier a t propos dans le cadre de lapproche MDA. Le deuxime est considr plus gnraliste et est bas sur une adaptation du cycle de vie en Y. Nous allons prsenter dans ce qui suit, chacun de ces modles.
Le cycle de dveloppement de MDA Le cycle de dveloppement de MDA peut tre comparable un cycle de dveloppement classique tel que le processus en cascade. On y trouve en eet les mmes phases de dveloppement savoir lexpression des besoins, lanalyse, la conception, limplmentation, la validation et le dploiement. La dirence rside cependant dans la nature des artefacts produits dans chacune des phases. La gure 4.5 dcrit ce processus de dveloppement.
97
Fig. 4.5: Le cycle de vie de MDA Le premier modle produit appel Computer Independent Model (CIM) correspond la description en langage naturel du domaine dapplication. Dans ce modle aucune considration informatique napparat. Par exemple, dans le domaine Bancaire, il pourrait sagir dun texte o il serait indiqu que certaines compensations peuvent tre traites le soir. Un modle CIM sert de base la dnition du modle PIM (Platform Independent Model) o le mtamodle sous-jacent est cette fois-ci de type informatique mais non rattach une technologie particulire (ex : un modle objet). Le passage dun modle CIM un modle PIM est normalement manuel et ncessite plusieurs discussions entre experts du domaine et informaticiens bien que certains travaux prconisent une projection automatique [ZMZY05]. Le modle PIM est, dans une troisime tape ran an dindiquer des aspects propres au paradigme de dveloppement qui va tre utilis (ex : lobjet, le procdural, etc.). La quatrime tape consiste produire, en appliquant une transformation automatique, un modle PSM (Platform Specic Model) cest--dire un modle spcique une plate-forme. Un modle EJB (modle UML utilisant le prol EJB) est un exemple de modle de type PSM. Aprs ranement de ce type de modles, celui-ci sert gnrer automatiquement une partie du code nal qui va tre par la suite ran et test (manuellement) par le dveloppeur. Ce processus de dveloppement a cependant fait lobjet de plusieurs critiques. Bien quil semble simple de premier abord, plusieurs travaux actuels portant sur les compositions de modles ont montr la dicult de relier entre eux les dirents modles, reprsentant les dirents aspects dune application [EVI05]. Dautres dicults ont t releves quant lutilisation de UML et de MOF. Ceux-ci sont considrs comme trs gnralistes et dicilement manipulables par des non spcialistes. Microsoft par exemple a fait le choix de privilgier des langages de domaines (Domain Specic Languages ou 98
Fig. 4.6: Le cycle de vie en Y DSL) de petite taille, facilement manipulables et transformables [JSCK04]. Processus de dveloppement en Y Plusieurs travaux concernant IDM font rfrence au cycle de dveloppement en Y [BDD+ 02], [Kad05]. Initialement, ce processus de dveloppement avait pour objectif une matrise des cots et dlais grce une paralllisation des tches danalyse et de conception [Lar94] mais certains travaux lont adapt dans le cadre dIDM [BBF06]. Dans ce contexte, il sagit de mettre en parallle llaboration du PIM et la description de la plate-forme. Une jonction entre les deux branches va constituer le PSM. La gure 4.6 illustre ce processus. Selon ce processus, les phases danalyse/conception sont menes en parallle avec ltude des direntes plates-formes existantes. Durant lanalyse et la conception, les modles CIM et PIM sont produits comme le prconise le processus fourni par MDA. Notons quun premier PIM est labor dcrivant le domaine du problme. Celui-ci est ensuite ran pour produire un PIM dcrivant le domaine de la solution. Ce ranement doit cependant conserver lindpendance des modles par rapport aux dtails dimplmentation. Il sagirait de spcier lchange de ux de donnes entre les direntes entits du systme. Paralllement, les aspects techniques de chaque plate-forme 99
Fig. 4.7: Un exemple de table de mapping PDM/PIM sont tudis et le choix de la plate-forme dimplmentation est eectu. Les caractristiques techniques de celle-ci sont modliss dans le PDM (Platform Description Model). Celui-ci va dcrire par exemple, les types supports par la plate-forme (exemple : une chane de caractre en JAVA correspond un objet qui instancie la classe String). Un mapping est ensuite eectu entre les entits dcrites dans le PIM et celles qui leur correspond dans le PDM. La gure 4.7 illustre un exemple de table de mapping entre les entits du PIM et celles du PDM. Cest la suite du mapping PDM/PIM que le PSM est gnr. Celui-ci est donc le rsultat de la fusion du PDM et du PSM. Une fois le PSM eectu, le code est gnr. Ensuite il est ran, test et valid par le dveloppeur avant que le dploiement nait lieu.
3.6
Apports potentiels de lapproche oriente modles dans lingnierie des systmes multi-agents
Dans cette section, nous nous replaons dans le contexte du dveloppement orient agent. Lingnierie dirige par les modles peut tre utile divers niveaux dans ce contexte. Nous rsumons dans le tableau 3.6, tous les avantages que nous pouvons tirer de lapplication dIDM dans lingnierie des systmes multi-agents. Nous remarquons cependant que lexpression et la vrication des pro100
Problmatiques des systmes multi-agents Plusieurs mthodologies, langages de modlisation, plates-formes orientes agents sont proposs, chacun adoptant une smantique particulire des concepts.
Thories IDM Larchitecture quatre niveaux de IDM permet de structurer et dunier le cadre de dveloppement en dnissant les mtamodles et les mta-mtamodles utiliss. La transformation de modles permet de combiner les modles produits selon des mtamodles dirents. La couche mtamodle et mtamtamodle permettent de dnir la smantique des concepts utiliss. Larchitecture quatre niveaux de IDM permet une grande exibilit : la mtamodlisation permet de dnir les concepts de manire indpendante. Ainsi, les concepts orients agent seront dnis indpendemment des concepts du domaine. Lunication des deux mtamodles se fera par la suite lors de la dnition du PIM. Le PIM est un modle labor pendant les phases danalyse et de conception tandis que le PSM est labor pendant la phase dimplmentation. Des rgles de transformation doivent tre ralises pour passer du PIM vers le PSM ce qui permet de connecter ces direntes phases. Thoriquement, la transformation de modles facilitera lchange de modles entre plusieurs platesformes.
La smantique des concepts utiliss est trs ambigu. Application de lapproche dirents domaines.
Connecter les phases danalyse et de conception la phase dimplmentation.
Interoprabilit entre les platesformes.
Tab. 4.1: Les apports relatifs lapplication de lapproche IDM dans le contexte multi-agents 101
CHAPITRE 4. VERS UN DVELOPPEMENT FLEXIBLE ET SR prits sur les modles, ne sont pas rellement traites au niveau de IDM. En eet, IDM soriente vers la validation des modles par rapport au mtamodle. Ce genre de validation permet de dterminer si le modle est correctement construit mais ne peut raisonner sur les proprits comportementales telles que la sret, la vivacit ou le deadlock. Les deux modles de cycle de vie prsents prcdemment, ne prennent pas en compte ltape de vrication au niveau des phases danalyse et de conception. De plus, les formalismes utiliss sont essentiellement bass sur MOF et UML dont la syntaxe et la smantique ne sont pas formalises de manire mathmatique. Il en dcoule que des proprits structurelles et comportementales sont difcilement exprimables et vriables. Ainsi, tout en suivant les instructions dIDM, il nous parat judicieux de combiner cette approche avec lapproche centre architecture dans laquelle les phases danalyse et de conception ont t traites avec plus de rigueur. Nous prsentons cette approche dans ce qui suit.
Le dveloppement orient architecture
Le dveloppement centr architecture a aussi t abord dans la section 5.2 du chapitre 2. Dans cette section nous allons approfondir cette approche. Nous commenons dabord par rappeler les principes de bases de cette approche, avant dexpliquer sa mise en uvre et dtailler le processus de dveloppement utilis. A la n de cette section, nous rsumons les avantages que nous pouvons tirer de lutilisation de cette approche dans les systmes multi-agents.
4.1
Dnition dune architecture logicielle
Le dveloppement orient architecture est une discipline rcente focalisant sur la structure, le comportement et les proprits globales dun logiciel. Elle sadresse plus particulirement la conception de systmes logiciels de grandes tailles ou de familles de systmes logiciels. Le but du dveloppement orient architecture est de permettre aux concepteurs deectuer des analyses prliminaires sur ces systmes. Ces analyses visent dcouvrir et rsoudre les problmes de conception ds les premires tapes du dveloppement. Plusieurs dnitions ont t attribues aux architectures logicielles [PW92], [Boa95] , [BCK99]. De manire gnrale, une architecture logicielle est dnie par un ensemble de composants (ex : ltres, objets, bases de donnes, serveurs, etc.) ainsi que par la description des interactions entre ceux-ci (ex : appels de procdures, envois de messages, missions dvnements, etc.) [GS93]. Mais larchitecture logicielle ne se limite pas ces descriptions. La description architecturale dun systme informatique permet en outre de spcier : 102
sa structure : lments de traitement et leurs interactions (pas de dtail dimplmentation), son comportement : fonctionnalits et protocoles de communication, dynamisme, ses proprits globales : scurit, vivacit, etc. les rgles rgissant sa conception : il pourrait sagir de rgles de ranement, de transformation (vers le code) ou de vrication. Lvaluation dune architecture mne une meilleure comprhension des besoins, des stratgies dimplmentation, et des risques potentiels. De plus, lutilisation dune conception oriente architecture comporte des avantages pour toutes les personnes intervenant dans le cycle de vie dun projet logiciel : pour le client : larchitecture permet une estimation du budget, de la faisabilit et du temps de dveloppement. pour le chef de projet : elle fournit un support pour la traabilit des besoins, lvaluation du systme et le suivi des progrs, pour le dveloppeur : larchitecture ore une ligne de conduite et les spcications ncessaires pour limplmentation de nouveaux composants. De plus, elle ore les garanties pour linteroprabilit avec les systmes existants, pour le mainteneur : larchitecture est un guide pour faire voluer le systme. Pour avoir une ide plus claire sur larchitecture logicielle, nous allons, dans la suite de cette section exposer les dirents apports de la spcication des architectures logicielles.
4.2
Mettre en uvre lapproche oriente architecture
La mise en uvre de lapproche oriente architecture ncessite divers techniques. Malencontreusement, dans lindustrie encore aujourdhui, les descriptions architecturales sont encore bases sur des diagrammes informels (sous forme de lignes et de botes) et sont souvent ambigus, incompltes, inconsistantes, et non-analysables. En eet, de simples diagrammes comportant des annotations ne sont pas susamment expressifs pour spcier une architecture. Pour tre exploitable, une architecture doit clairement dnir : quels traitements les "botes" et leurs annotations reprsentent, quelles relations de contrle/ux de donnes sont indiques par les "lignes" ou "ches", comment le comportement global du systme est dtermin par celui de ses composants, 103
CHAPITRE 4. VERS UN DVELOPPEMENT FLEXIBLE ET SR quelles sont les proprits structurelles et comportementales qui doivent tre conserves tout au long du dveloppement. An de dnir avec rigueur larchitecture des systmes logiciels, les langages de description darchitectures - ADLs (Architecture Description Languages) - mergent comme le support de notation pour les modles darchitectures [MT01], [WH05]. Ils utilisent des notations textuelles et graphiques ayant une smantique bien dnie. Ces langages sont souvent accompagns doutils de cration, de modication, de navigation, de simulation et danalyse. Certains ADLs sont bass sur des notations formelles. Ceci comporte de multiples bnces : le fait de dcrire formellement larchitecture rend possible lutilisation (parfois automatique) des mcanismes danalyse, de rafnement, et de gnration du code correspondant. Lanalyse de larchitecture permet lvaluation des proprits dun systme au niveau architectural ; ce qui permet de prvenir les erreurs et de diminuer les cots ds celles-ci. Les types danalyses applicables dpendent de lADL utilis et de son modle smantique. En eet, certains ADL se contentent de dcrire la structure du systme, alors que dautres incluent aussi des caractristiques comportementales. Ainsi, selon la nature de lADL, il est possible dexprimer des contraintes structurelles et comportemantales. Ces contraintes constituent des proprits fonctionnelles que le systme nal doit respecter. Dans certains ADL, ils est aussi possible de pouvoir exprimer des proprits non fonctionnelles telles que la scurit, la qualit etc. Lors du ranement, les proprits de larchitecture abstraite doivent tre conserves par larchitecture concrte. Dans ce contexte, certains ADLs permettent dexprimer explicitement les rgles de ranement, en spciant lopration qui doit tre eectue lors du pas de ranement ainsi que les proprits qui doivent tre conserves. Lusage doutils adquats est indispensable dans ce cas. Le but ultime de la conception logicielle est de produire un systme excutable. Un modle architectural "lgant" et ecace a peu de valeur sil nest pas convertible en application excutable. Cela peut se faire manuellement ; cas dans lequel de nombreux problmes de consistance et de traabilit entre larchitecture et son implmentation peuvent apparatre. Il est prfrable dutiliser des outils de gnration de code qui devraient tre fournis par chaque ADL.
4.3
Processus de conception orient architecture
Au niveau du cycle de dveloppement, la spcication des architectures logicielles se situe essentiellement dans les phases de conception et dimplmentation. Le processus de dveloppement centr architecture inclut trois 104
CHAPITRE 4. VERS UN DVELOPPEMENT FLEXIBLE ET SR sortes dacteurs : larchitecte dapplication, le dveloppeur et lanalyste qui est responsable de vrication et la validation des architectures (cf. gure 4.8).
Fig. 4.8: Le processus centr architecture
Larchitecte a pour rle de dnir larchitecture qui servira de base au dveloppement du systme. Le dveloppeur rane cette architecture de faon sapprocher, petit petit, du systme nal. On parle alors du passage dune architecture abstraite vers une architecture concrte. Ce passage se fait par ranement successif ; ce qui consiste ajouter de plus en plus de dtails larchitecture abstraite jusqu ce que larchitecture soit assez dtaille pour pouvoir tre implmente sans ajouter dinformations nouvelles. A chaque tape du ranement, lanalyste doit tre en mesure de vrier que larchitecture rane est conforme larchitecture du niveau dabstraction suprieur. Ce processus permet de garantir que lapplication obtenue respecte les proprits fonctionnelles, structurelles et comportementales dnies par lanalyste en accord avec le client et les utilisateurs. Le nombre de ranements successifs peut tre trs dirent dune application lautre. En eet, il dpend de la prcision ncessaire de larchitecture pour pouvoir passer au code. Cette tape de ranement est ncessaire pour les grosses applications qui ne peuvent pas tre construites en une seule passe, mais on peut trs facilement sen passer pour des applications de plus petites tailles. Dans ce cas, lapplication pourrait directement tre implmente partir de la premire architecture si celle-ci est assez prcise. 105
4.4
La notion de style architectural
Les principes dorganisation architecturale pour les systmes logiciels sont appels styles architecturaux. Un style formalise la connaissance et lexprience dans un domaine logiciel spcique. Le but principal des styles architecturaux est de simplier la conception des logiciels et la rutilisation, en capturant et en exploitant la connaissance utilise pour concevoir un systme [MKMG97]. Un style architectural dnit une famille des systmes logiciels ayant un vocabulaire commun pour dsigner les composants, des caractristiques topologiques et comportementales communes, et un ensemble de contraintes sur les interactions parmi les composants. Un style architectural est moins contraignant et moins complet quune architecture spcique. Il spcie uniquement les contraintes les plus importantes, au niveau par exemple de la structure, du comportement, de lutilisation des ressources des composants [AA96]. Dune faon gnrale, les styles architecturaux permettent un dveloppeur de rutiliser lexprience concentre de tous les concepteurs qui ont prcdemment fait face des problmes similaires [KK99]. Un style architectural fournit typiquement [Gar95] : un vocabulaire pour spcier les types dlments de construction : Agent, Groupe, Client, Serveur, etc. des rgles de conguration, ou contraintes, qui dterminent comment les lments architecturaux peuvent tre composs. Une contrainte peut interdire deux lments de communiquer, elle peut dnir aussi des patrons spciques (une organisation hirarchique ou en toile). une interprtation smantique par laquelle les compositions des lments architecturaux ont une signication bien dnie. des analyses qui sont associes au style et qui identient des caractristiques de direntes sortes (par exemple vrier une mesure telle que le nombre dlments ou vrier la satisfaction dune proprit etc.). Les styles architecturaux ont un trs haut niveau dabstraction. Ils ont merg naturellement de lexprience du dveloppement logiciel et en particulier de la conception architecturale. Ils sont utiliss trs tt dans le processus de dveloppement dun systme logiciel, au dbut de la conception architecturale. Ceci va tre illustr dans la section suivante. Les styles architecturaux ont longtemps t dnis et utiliss comme des concepts, des guides de conception informels. Puisquun style architectural reprsente une famille entire de systmes logiciels, il est dsirable de formaliser le concept de style architectural pour la fois avoir une dnition prcise de la famille de systmes et pour tudier les proprits architectu106
Fig. 4.9: Le processus centr architecture [Ley04]
rales communes tous les systmes de la famille [BGPG02]. Les travaux mens depuis lors ont soulign lintrt de formaliser les styles [AAG95], et de nombreux langages ddis cette tche ont t dvelopps. Les ADLs devraient permettre la dnition des styles architecturaux [NR99]. De plus ils devraient fournir un mcanisme pour exploiter un style dans la dnition dune architecture. Il est aussi utile de pouvoir dnir des sous-styles. De nombreux ADLs sont spciques un domaine et un style en particulier. Par exemple, le style MetaH [Ves92], [Ves94] est un langage spcique aux architectures des systmes multiprocesseurs temps rel pour laviation.
Les styles sont prsents tout au long du cycle de dveloppement centr architecture, depuis la spcication des besoins jusqu lexcution du systme (4.9). Les styles orent un cadre et un support la conception architecturale, mais un style en particulier peut promouvoir un aspect plutt que lautre suivant sa dnition. Le schma ci-dessous montre que les styles peuvent tre utiliss pour formaliser les spcications dune famille (ou dune ligne) de produits partir dun cahier des charges, pour apporter un support la description avec des notations spciques, pour apporter un support analytique ou pour apporter un support la conception avec des styles rpondant des problmes spciques. 107
4.5
Apports potentiels de lapproche oriente architecture dans lingnierie des systmes multi-agents
Comme nous lavons mentionn dans la section 3.6 lingnierie dirige par les modles permet de mieux structurer le cycle de dveloppement. En utilisant la mtamodlisation, les concepts multi-agents seront mieux dnis, ce qui enlvera certaines ambiguts. La sparation des aspects permettra de dnir les concepts multi-agents et les concepts lis au domaine dapplication de manire indpendante. Ceci simplie le dveloppement puisque les dtails de chaque aspect seront dgags. Les modles de cycle de dveloppement de IDM suggrent de spcier les PIMs partir des mtamodles. Ces PIMs peuvent parfaitement correspondre aux architectures logicielles puisque leur rle consiste spcier en dtail les direntes vues du systme. La plupart des travaux utilisent pour cela le formalisme UML. Bien que UML soit parfois considr comme un formalisme adquat pour la description des architectures (cf. section 5.2), plusieurs dicults ont t recenses quant son ecacit produire des modles de qualit qui soient corrects, extensibles, rutilisables et oprationnels. Rappelons que dans notre problmatique, nous avons soulign labsence de phases de vrication et validation dans les diverses mthodologies orientes agent. Nous avons aussi prcis que dans le cas des systmes complexes comme ceux dvelopps avec le paradigme agent, diverses proprits doivent tre vries si nous voulons aboutir un logiciel sr. Malgr lutilisation du langage OCL, certaines proprits comportementales ne peuvent tre exprimes et vries sur les modles UML. Cest pour cela que nous pensons quutiliser les ADLs peut tre adquat la spcication des architectures logicielles au niveau du PIM. Les avantages des ADLs sont rsums dans le tableau 4.5.
Combinaison des deux approches
Lutilisation de lapproche centre architecture est tout fait envisageable au niveau de lIDM. Plusieurs similarits entre les deux approches existent. Avant de discuter les dtails techniques qui peuvent tre mis en uvre pour appliquer une telle combinaison, nous rsumons dans le tableau 5, les similarits des deux approches. 108
Problmatiques des systmes multi-agents La smantique des concepts utiliss est trs ambigu
Approche Oriente Architecture La spcication dun style architectural permet dviter toute ambigut par rapport lapplication dun concept et la dnition du composant qui limplmente puisque celui-ci permet de fournir le vocabulaire, les contraintes, linterprtation smantique et les analyses lies aux concepts Lapproche oriente architecture fournit un niveau dabstraction plus lev. Le dveloppeur rchit sur les lments composant le systme ainsi que sur leurs interactions. Lutilisation des ADLs formels rend possible la vrication et la validation des proprits structurelles et comportementales et ce lors des direntes tapes de dveloppement, grce aux rgles de ranement. Le cycle de dveloppement par ranement successif permet de limiter les carts entre les direntes phases de dveloppement.
La plupart des mthodologies sont bases sur lapproche oriente objet cependant celle-ci nest pas bien adapte puisquelle a un bas niveau dabstraction par rapport aux concepts orients agents Les mthodologies norent pas de supports consistants pour la vrication et la validation des modles lors de la phase de conception
Les phases danalyse/conception ne sont pas connects la phase dimplmentation
Tab. 4.2: Les apports relatifs lapplication de lapproche centre architecture dans le contexte multi-agents
109
Lapproche IDM Dveloppement centr sur lutilisation des modles
Lapproche Centre Architecture Lapproche IDM permet de manipuler des modles or larchitecture est un modle qui permet de dcrire la fois la structure et le comportement global du systme. Tout systme se caractrise par une architecture particulire. Ainsi, le modle architectural peut dcrire les PIMs et les PSMs introduits par lIDM. Le dveloppement centr architecture est bas sur la notion de ranement, cette notion rencontre celle des transformations de modles dIDM. Lapproche IDM met en avant la mtamodlisation qui permet de dnir la smantique des concepts. Ceci rejoint le principe des styles architecturaux qui dcrivent de manire plus abstraite une architecture particulire dun systme
Transformation de modles
La mtamodlisation
Tab. 4.3: Combinaison de lapproche IDM et lapproche centre architecture
Nous situons larchitecture logicielle au niveau du PIM et les styles architecturaux au niveau des mtamodles. Notre objectif durant cette thse est de dcrire les mcanismes qui partir des mtamodles (dcrits par des styles architecturaux) vont permettre de dnir les patrons architecturaux ncessaires la spcication de chaque vue du systme multi-agents. Ces patrons architecturaux - qui vont constituer notre PIM - devraient respecter la smantique dnie au niveau des mtamodles. Nous tudierons aussi la manire de combiner ces dirents patrons an davoir une description globale du systme. Une partie importante de notre travail sera consacre la dnition de certaines proprits structurelles et comportementales lies aux patrons architecturaux. Une autre partie correspondra la dntion des rgles de ranement permettant dobtenir ces combinaisons tout en respectant la vrication et la validation des proprits. Cette solution va tre explique avec plus de dtail dans le prochain chapitre. 110
Conclusion
Ce chapitre nous a permis de prciser la problmatique laquelle sattaque cette thse. A partir de cette problmatique, ltude des direntes techniques dingnierie existantes (exposes dans le chapitre 3) nous a amen choisir deux approches principales an de mieux structurer le dveloppement des systmes multi-agents. Le dveloppement centr architecture nous permettra de focaliser sur larchitecture logicielle des systmes multi-agents. Le but recherch lapplication de cette approche est lobtention de logiciels corrects, extensibles et rutilisables. Lingnierie dirige par les modles servira spcier le cadre de dveloppement permettant de raliser les direntes phases du cycle de dveloppement. Trois avantages majeurs ressortent de lutilisation de cette approche : la prennisation du savoir relatif lutilisation des concepts (aussi bien les concepts multi-agents que les concepts du domaine) ; la prennisation du savoir faire grce lapplication de rgles de transformation permettant de combiner divers modles ; un gain de productivit grce la spcication des rgles de transformation servant la gnration de code. Dans le prochain chapitre, nous abordons les moyens techniques relatifs la mise en uvre de notre approche.
111
112
Chapitre 5 Lapproche ArchMDE
CHAPITRE 5. LAPPROCHE ARCHMDE
Introduction
Dans ce chapitre, nous dcrivons notre dmarche de dveloppement des systmes multi-agents qui est base sur la combinaison de lapproche IDM et de lapproche centre architecture. Nous baptisons notre approche ArchMDE pour Architecture Model Driven Engineering. Dans la premire partie de ce chapitre, nous allons dtailler les principes de ArchMDE en prcisant les artefacts considrs au niveau de notre approche ainsi que les direntes manires de les utiliser. Cette premire partie reste gnrique et ne fait pas de suppositions quant lutilisation doutils techniques particuliers. La deuxime partie illustre lapplication de notre dmarche ArchMDE laide de lenvironnement ArchWare qui sera prsent dans la section 4 de ce chapitre.
Lapproche ArchMDE
ArchMDE combine lapproche IDM et lapproche centre architecture. En respectant les principes dIDM, ArchMDE est base sur la construction et la transformation des modles. Dans ArchMDE, les modles sont des constructions architecturales. Le mtamodle est reprsent par un style architectural, le PIM par une architecture particulire et le PSM par le code source. Dans cette premire section, nous commenons par prsenter les modles considrs dans ArchMDE. Par la suite, nous prcisons comment ces modles 114
CHAPITRE 5. LAPPROCHE ARCHMDE sont raliss dans le cadre dun processus de dveloppement ArchMDE.
2.1
Les modles considrs
ArchMDE repose sur larchitecture quatre niveaux de MDA (cf. section 3.2). Dans ce qui suit, nous allons rednir cette architecture dans notre contexte. Le mta-mtamodle Rappelons que le mta-mtamodle sert dnir la syntaxe et la smantique selon lesquelles les mtamodles vont tre exprims (cf. section 3.2). Un langage gnrique et rexif doit tre adopt ce niveau. Un langage rexif est un langage qui se dnit par lui-mme. Cette caractristique permet dune part dviter de multiplier les niveaux dabstraction et dautre part de rendre le langage facilement extensible ; ce qui permet de dnir de nouveaux concepts appartenant des domaines dirents. Traditionnellement, dans les approches IDM ce sont les langages bass sur le formalisme de MOF qui sont utiliss. Nous reprochons ces langages le manque de formalisation ainsi quune ambigut quant la dnition de certains concepts et leurs utilisations. Le fait que MOF soit exprim en utilisant le diagramme de classe UML brouille les frontires entre les deux niveaux dabstraction (mta-mtamodle et mtamodle). De plus, MOF est orient objet et est principalement dni en terme de classes, dassociations, de paquetages, de types de donnes, dexception, de constantes et de contraintes, ce qui peut limiter considrablement notre approche, puisque les agents comme nous lavons dmontr au chapite 2 ont un niveau dabstraction plus lev que les objets logiciels. Lutilisation des objets dans notre contexte risque dengendrer des systmes fortement coupls. Enn, MOF est trs dicile matriser : les spcications de OMG sur ce sujet restent vagues et compliques comprendre ; ce qui rend son utilisation dicile. Pour ces raisons, nous favorisons lutilisation des langages formels pour exprimer les mtamodles. Nous avons dmontr dans le chapitre prcdent, quil y avait une grande similarit entre le rle des mtamodles et des styles architecturaux (cf. tableau 5 du chapitre 4). Lutilisation dun ADL permettant la dnition des styles est donc tout fait envisageable ce niveau. Cependant, il faut prendre soin de choisir un ADL gnrique permettant la description de divers concepts appartenant des domaines dirents. Ce langage ne doit pas imposer des restrictions qui peuvent tre incohrentes ou conictuelles avec celles sous-jacentes un domaine particulier 1 .
Par exemple, C2SADEL [MRT99] ne permet pas deux interfaces (ports) dtre connectes directement un mme troisime.
1
115
Fig. 5.1: Arbres de drivation dune expression arithmtique
De plus, les langages formels permettent lexpression et la vrication des proprits. En eet, ces langages sont la fois dnis par une syntaxe mais galement par une smantique formelle associe aux direntes constructions du langage. Une syntaxe dun langage formel est souvent exprime par une grammaire EBNF (Extensible BNF). Cependant, celle-ci ne traduit que la structure sans sattaquer la smantique. Dans notre cas, la smantique est en eet dcrite par les contraintes et les analyses que le style introduit, ce qui permet de rduire les arbres de drivation qui peuvent tre gnrs lors de linterprtation dune expression du langage. Nous allons illustrer nos propos par un exemple simple, li la formulation dune expression arithmtique. Bien que cet exemple puisse tre considr de bas niveau, il illustre bien les problmes smantiques qui peuvent apparaitre lors des formalisations. Prenons donc lexemple de la syntaxe S dcrivant une opration algbrique, la soustraction (cf. gure 5.1). En appliquant cette syntaxe, nous pouvons obtenir une expression arithmtique E. Linterprtation de cette expression peut tre ralise de deux manires direntes dcrites par larbre a1, soit par larbre a2. Pour viter cette situation, le mta-mtamodle devrait donner la possibilit dexprimer des rgles smantiques relatives lutilisation des expressions syntaxiques. Dans notre exemple, ceci revient prciser deux rgles smantiques permettant de prciser le sens de lassociativit. Une premire rgle R1 qui correspond larbre a1 dcrit une associativit droite et une rgle R2 qui correspond larbre R2 dcrit une associativit gauche. Pour viter toute confusion entre les niveaux, nous prcisons que la syntaxe (S), peut tre considre comme un mta-mtamodle. Lexpression E d116
CHAPITRE 5. LAPPROCHE ARCHMDE crit un style (mtamodle) quon pourrait appeler additionTroisNombres. Ce style peut en fait tre spcialis en deux sous-styles. Le premier imposera la rgle R1 alors que le deuxime imposera la rgle R2. Lors de linstanciation du style (au niveau architecture), si lexpression respecte le style R1, elle va tre interprte par x-(x-x). Si elle respecte le style R2, elle sera interprte par (x-x)-x. Les mtamodles Dans notre contexte, le mtamodle nous permet de dnir les concepts utiliss dans un systme multi-agents. Comme nous lavons vu dans le chapitre 3, plusieurs vues regroupant des concepts orients agents peuvent tre dnies. Nous avons aussi soulign que ces vues peuvent largement dpendre des domaines dapplication. Une question nous est donc parue essentielle dans ce contexte. Comment associe-t-on les concepts du domaine dapplication aux concepts orients agent ? Dans les mthodologies orientes agent que nous avons parcourues, trs peu traitent les concepts du domaine indpendamment des concepts orients agent. Le mtamodle agent est gnralement x, et les concepts du domaine vont tre directement dcrits en utilisant les concepts orients agent. Ceci peut compliquer davantage la tche des dveloppeurs qui se retrouvent manipuler les concepts agents et les concepts du domaine en mme temps. Dans ce contexte, certaines proprits du domaine dapplication risquent dtre omises ou traites dune manire inapproprie. Un des principes de lapproche IDM est la sparation des aspects qui stipule que chaque aspect dun problme soit trait indpendemment an de pouvoir se concentrer plus ecacement sur chacun. Dans notre contexte, il nous parait indispensable de pouvoir reprsenter de manire indpendante les concepts du domaine dapplication et de spcier leurs proprits an de pouvoir les "agentier" par la suite dune manire correcte. Cette sparation des aspects est dailleurs illustre dans le mtamodle de PASSI (cf. section 5.4 du chapitre 3) qui reprsente trois couches : la couche domaine, la couche oriente agent, et la couche plate-forme dimplmentation. Ainsi, cest en sappuyant sur la dcomposition adopte par PASSI que nous avons identi trois types de mtamodles : le mtamodle du domaine : il dcrit les concepts utiliss dans le domaine dapplication. Il sagit de dnir les entits "mtier", faisant parti du domaine dapplication, leurs relations ainsi que leurs principales proprits architecturales. le mtamodle orient agent : il dcrit les concepts orients agent ainsi que leurs principales relations et proprits architecturales. Au niveau de ce mtamodle direntes vues peuvent tre intgres telles que les 117
CHAPITRE 5. LAPPROCHE ARCHMDE vues adoptes dans Ingenias (section 5.3 du chapitre 3), savoir lagent, lorganisation, linteraction, les "tches & buts" et lenvironnement. le mtamodle de la plate-forme dimplmentation : il dcrit les concepts qui sont implments par une plate-forme oriente objet ou autre plateforme "classique". Ces dirents mtamodles permettent dappliquer la sparation des proccupations. Lapplication dveloppe par le paradigme orient agent est aborde par partie, ce qui rduit la complexit de conception et de ralisation. De plus, cette sparation entre les trois mtamodles nous permet de capturer les proprits lies chaque aspect de manire indpendante. La dicult rside ensuite dans lintgration des dirents aspects an de gnrer larchitecture concrte du systme. Ce point sera discut plus loin dans ce chapitre (section 2.2). Les mtamodles adopts dans ArchMDE sont spcis en utilisant le langage de style de la couche mta-mtamodle. Notons par ailleurs que la reprsentation de ces mtamodles par des styles architecturaux permet - si le langage de style le permet - de dnir aussi bien des proprits que des contraintes 2 structurelles et comportementales lies chaque aspect.
Le PIM et le PSM Dans le cadre de ArchMDE, le PIM et le PSM (cf. section 3.5 du chapitre 4) appartiennent la couche M1. Ces deux modles sont obtenus suite au tissage des aspects appartenant aux mtamodles que nous avons dnis prcdemment. Le tissage doit conserver les proprits spcies dans chaque mtamodle. Il est ralis grce des rgles de transformation. Cest la suite de ce tissage que nous obtenons le PIM et le PSM du systme. Le PIM est obtenu par tissage des concepts du domaine avec les concepts orients agent. Nous obtenons dans ce modle, une description agentie dun domaine dapplication. A ce niveau, nous sommes pourtant loin davoir un PSM. En eet, un domaine agenti se situe dans la phase de conception et les concepts dimplmentation ne sont pas encore introduits. Ceux-ci sont en eet dcrits par le mtamodle de la plate-forme dimplmentation. Une autre transformation est ncessaire qui associe les concepts orients agents aux concepts de la plate-forme. Lapplication de ces rgles de transformation gnrera le PSM constitu par le code source de lapplication (cf. gure 5.2).
Les contraintes peuvent tre considres comme des proprits particulires devant tre absolument satisfaites
118
Fig. 5.2: La couche modle La couche systme Le dploiement du systme partir du code source gnr dans le PSM est eectu au niveau de cette couche. Le systme gnr doit conserver les proprits dcrites au niveau des mtamodles et des modles. Aprs le dploiement du systme, un aspect interessant peut tre tudi : le monitoring du systme ainsi que le contrle de son volution. Ces deux points peuvent tre considrs dun point de vue de ringnierie. Que se passe-t-il si durant lexcution, on fait voluer le systme pour intgrer de nouvelles fonctionnalits ? Ces points ne seront pas tudis dans cette thse mais feront partie des perspectives de nos travaux.
2.2
Le cycle de dveloppement ArchMDE
Le but de lapproche ArchMDE est de permettre au dveloppeur de crer son cadre de dveloppement qui soit spcique son application. Le cadre de dveloppement va contenir : les concepts et les proprits spciques au domaine dapplication, les concepts et les proprits spciques aux systmes multi-agents quil va utiliser, les rgles de transformation entre les concepts du domaine et les concepts orients agents, les concepts et les proprits sur lesquels se basent les plates-formes dimplmentation, les rgles de transformation entre les concepts orients agents et les 119
CHAPITRE 5. LAPPROCHE ARCHMDE concepts de la plate-forme dimplmentation. Lapplication de la dmarche de ArchMDE est situe deux niveaux : le premier niveau consiste dnir le cadre de dveloppement form par les mtamodles et les rgles de transformation, le deuxime niveau consiste utiliser le cadre de dveloppement en crant des modles bass sur les mtamodles dnis et en appliquant des rgles de transformation entre ces modles. Comme nous lavons dni prcdemment, nous proposons trois mtamodles. Ces mtamodles constituent la base du cycle de dveloppement. Nous avons vu prcdemment que la principale dicult de notre approche rside dans le tissage des aspects appartenant dirents mtamodles. Deux principales phases de tissage sont ncessaires dans le cadre de notre approche. La premire phase concerne le tissage entre le mtamodle orient agent et le mtamodle du domaine. Nous appelons ce processus "agentication". La deuxime phase reprsente une translation des modles "agentis" vers le PSM. Durant cette translation, il sagit de rednir larchitecture dcrite au niveau du PIM selon les concepts du mtamodle de la plate-forme dimplmentation. Nous appelons ce processus de transformation un "mapping". Ces deux processus forment en fait des jonctions qui permettent dassocier deux branches. Chaque branche reprsente une phase de dveloppement. Pour cela, nous dcrivons notre cycle de dveloppement par un double Y (cf. gure 5.3). Selon le niveau auquel la demarche ArchMDE est applique (dveloppement ou utilisation du cadre de dveloppement), les tapes du cycle de vie en double Y prennent des interpretations direntes, comme nous allons le prsenter dans la section suivante.
Application du cycle de dveloppement ArchMDE
Lapplication du cycle de dveloppement ArchMDE peut se faire de deux manires direntes. Chaque manire ncessite des acteurs dirents. Dans la premire, le processus doit tre droul par des experts de mtamodlisation dont le rle est de spcier le cadre de dveloppement pour des domaines particuliers. Ces experts vont dnir : le mtamodle selon lequel le domaine va tre spci, le mtamodle orient agent qui va tre adopt, les rgles de transformation entre ceux-ci, les rgles de gnration de code vers une plate-forme spcique.
La dmarche ArchMDE peut aussi tre utilise par des dveloppeurs. A ce niveau, le mtamodle du domaine, le mtamodle orient agent ainsi que 120
Fig. 5.3: Le processus de dveloppement ArchMDE les rgles de tissage sont dj spcis et le dveloppeur naura qu les utiliser. Ces utilisateurs auront alors la tche de dcrire leur domaine avec le mtamodle du domaine fourni. Ils utiliseront par la suite les rgles de transformation fournies pour agentier leur domaine. Enn, ceux-ci utiliseront les rgles de gnration de code pour gnrer leur application.
3.1
Construction du cadre de dveloppement par les experts de mtamodlisation
Comme nous lavons spci, le rle des experts de mtamodlisation est de spcier les mta-entits qui vont tre utilises par les dveloppeurs. Dans ce cas, la dmarche ArchMDE va tre applique an de spcier le cadre de dveloppement des applications appartenant des domaines spciques (par exemple, un domaine conomique, le domaine des systmes embarqus etc.). Nous associons la spcication des mta-entits du domaine la phase danalyse, la spcication du mtamodle dagent ainsi que des rgles de tissage la phase de conception. Enn, la phase dimplmentation concerne la mtamodlisation de la plate-forme et la spcication des rgles de tissage entre mtamodle de la plate-forme et mtamodle orient agent. Dans ce qui 121
CHAPITRE 5. LAPPROCHE ARCHMDE suit nous allons dtailler les tches eectuer durant ces direntes phases.
Lanalyse Durant cette phase, le mtamodliste va produire un mtamodle permettant au dveloppeur de facilement dcrire son domaine indpendamment de tout paradigme de dveloppement. Ce mtamodle est un niveau dabstraction intermdiaire entre le langage de style et les concepts du domaine. Plusieurs mtamodles peuvent tre fournis ce niveau, par exemple le mtamodle entit-relation [Che76], les cas dutilisation adopts par UML, les modles de ots de donnes etc. Dans le cadre de cette thse, nous avons spci un mtamodle de domaine form par les entits suivantes : dataEntity : dcrivent les donnes relatives au domaine. Ces donnes peuvent tre simples ou composes. Par exemple, un contrat de vente peut tre considr comme une dataEntity. taskEntity : elles dcrivent les tches et les fonctionnalits qui sont eectues dans le domaine. Par exemple, passer une commande peut tre considre comme une taskEntity. activeEntity : ce sont les entits qui dcrivent les acteurs du systme. Nous incluons aussi bien les acteurs humains ou logiciels. Ceux-ci sont responsables de lexcution dune ou plusieurs tches (taskEntities) selon un processus dtermin. structureEntity : ces entits peuvent tre considres comme des structures organisationnelles regroupant toutes les autres entits. Elles reprsentent les lments composites du systme o plusieurs activeEntities vont fonctionner et interagir ensemble. La dirence entre une structureEntity et une activeEntity rside dans le niveau de granularit considr. Par exemple, une structureEntity va reprsenter une entreprise fournisseur (elle contiendra un acteur charg de la vente, un acteur charg de la production et un acteur charg de la gestion des stocks). Cette structureEntity, peut elle-mme tre considre comme une activeEntity qui forme un maillon dune supply chain (travaux en cours de Jihene Tounsi [TBH07]). Le mtamodliste aura comme mission de formaliser ces mta-entits par un langage de style et de saisir les contraintes relatives chacunes delles. Par exemple, une taskEntity doit tre excute par au moins une activeEntity ou une structureEntity. Nous allons traiter ce point plus loin dans le chapitre (section 7). 122
Fig. 5.4: Dnition des rgles de transformation La conception Durant cette phase, les experts de mtamodlisation auront excuter deux types de tches : 1. dnition du mtamodle orient agent : en utilisant le langage de style, un expert de systme multi-agent peut introduire le mtamodle orient agent qui lui parait le mieux adapt sa vision. 2. dnition des rgles de transformation : quand les deux mtamodles (du domaine et orient agent) sont spcis, la deuxime tape de conception va consister dclarer les rgles de transformation entre les concepts du mtamodle du domaine et ceux du mtamodle agent. Pour raliser cette tape, le concepteur a besoin dun langage de transformation. Cette tape est dcrite par la gure 5.4. Durant notre thse, nous avons spci un mtamodle orient agent qui traduit notre vision [AHO06]. Une version simplie de ce mtamodle est illustre dans la gure 5.5. Ce mtamodle exprim avec un langage semi-formel, ne traduit que partiellement les caractristiques des entits dcrites. La formalisation grce un langage de style va permettre de saisir toutes les proprits de manire plus ne. Nous allons traiter lexemple dun agent ractif dans la section 8 de ce chapitre. 123
Fig. 5.5: Un mtamodle Orient Agent
Aprs la spcication des deux mtamodles du domaine et orient agent, des rgles de transformation gnriques seront ncessaires pour permettre la rednition dune entit du domaine vers une entit du mtamodle agent. Si nous reprenons, le mtamodle du domaine que nous avons spci dans la sous-section prcdente, plusieurs rgles de transformation peuvent exister. Nous donnons quelques exemples dans le tableau 3.1. Au cours de cette phase, un travail important doit tre men qui consiste dnir les rgles de transformation des concepts mtier vers les concepts orients agent. Cette transformation doit respecter les proprits dcrites dans les deux mtamodles an de maintenir la cohrence globale du systme.
Limplmentation Le principe de base durant cette phase, est de transformer les concepts orients agent vers les concepts implments dans une plate-forme dimplmentation quelconque. Cette phase est trs dlicate et ncessite une grande expertise de la plate-forme dimplmentation. La tche des experts de mtamodlisation ce niveau consiste identier les rgles de transformation entre les concepts orients agent et ceux implments dans la plate-forme. 124
Entits du domaine dataEntity
Entits agenties
Etat Mental dun agent Ressource dans un environnement Attribut dun agent Tche ralise par un agent Tche ralise par une ressource active dans un environnement processus dans un agent Tche inclue dans le rle de lagent Tche ralise collectivement Agent (faible granularit) Groupe dagents (grande granularit) Ressource active dans un environnement Organisation dagents
taskEntity
activeEntity
structureEntity
Tab. 5.1: Mapping entre mtamodle du domaine et mtamodle orient agent
125
CHAPITRE 5. LAPPROCHE ARCHMDE Cette phase correspond alors la spcication dun gnrateur de code pour un langage donn. Ce gnrateur de code peut tre fourni par lenvironnement de description de style.
3.2
Utilisation du cadre de dveloppement par les dveloppeurs
Suite la construction du cadre de dveloppement par les experts en mtamodlisation, les dveloppeurs peuvent lutiliser pour dcrire leurs applications spciques. Les tches raliser durant les phases de dveloppements sont alors direntes de celles des experts en mtamodlisation. Lanalyse Au niveau de la phase danalyse, lutilisation du cadre de dveloppement ArchMDE va permettre dacqurir le maximum dinformations concernant les concepts et les processus "mtier". Nous supposons que ces informations sont dcrites au niveau dun cahier des charges. Il sagit durant cette phase de dcrire les entits du domaine selon le mtamodle fourni par le cadre de dveloppement. En utilisant ce mtamodle, le dveloppeur na pas besoin de matriser les concepts orients agent. Supposons par exemple, que le domaine dapplication concerne une application de vente par Internet. Ce domaine comporte plusieurs concepts tels que : les acteurs : deux sortes dacteurs sont considrs de prime abord, le client et le fournisseur. le ux de donnes : la commande constitue un ux de donnes chang entre le client et le fournisseur. Elle peut avoir des lments descriptifs tels que le prix, le dlai de livraison, etc. le processus : il peut exister des processus de commande ou de ngociation de prix entre le fournisseur et le client. En utilisant le mtamodle fourni prcdemment, les acteurs vont tre considrs comme des activeEntities changeant des ux de donnes dont les types vont tre dcrits en tant que dataEntities. Les processus vont tre dcomposs en plusieurs taskEntities. Celles-ci vont tre ordonnances au niveau dune structureEntity. Les processus dcrivent partiellement le comportement du systme. Nous pensons cependant que ceux-ci doivent gurer au niveau du mtamodle. En eet, ils imposent des contraintes comportementales, que le systme doit correctement excuter lors de son dploiement. Le dveloppeur devrait avoir sa disposition un langage lui permettant de dcrire ces entits ainsi que leurs proprits. Les proprits deviennent des contraintes lorsquelles doivent tre absolument satisfaites par le systme. Notons par ailleurs que les proprits ont plusieurs niveaux : 126
niveau structurel : ce niveau deux types de proprits peuvent tre prises en compte, les proprits topologiques qui prcisent par exemple le nombre doccurences possibles dune entit. Dans notre systme, il devrait y avoir au moins un client et un fournisseur. Le deuxime type de proprits dsigne les proprits dattribut. Les attributs dcrivent gnralement les donnes manipules par le systme. Elles peuvent tre contraintes par leur type, lintervalle de valeurs possibles, etc. niveau comportemental : il dcrit des contraintes comportementales telles que la squence dactions qui doivent tre excutes lors dun processus, etc. niveau interne : ce niveau dcrit les contraintes dont la porte concerne une seule entit du domaine 3 ; par exemple le prix dun produit ne doit pas dpasser 5 euros, ou un processus rcursif doit tre relanc la suite de sa dernire action, niveau global : ce niveau concerne des proprits ayant une porte sur le systme global ou une partie de celui-ci (une partie dun systme contient plusieurs entits). Par exemple, un protocole dinteraction dnit une squence denvois de messages eectue par plusieurs acteurs du systme. A la n de la phase danalyse, le mtamodle dcrit sous forme de style architectural va introduire (cf. gure 5.6) : le vocabulaire li au domaine et qui spcie ses dirents concepts, les contraintes lies chaque concept, les interprtations smantiques de chaque concept. La conception La phase de conception, telle quelle est dcrite dans la gure 5.3 permet de faire la jointure entre le mtamodle du domaine et le mtamodle agent. Lutilisation du cadre de dveloppement ArchMDE durant cette phase implique deux principales tapes : 1. application des rgles de transformation : lapplication des rgles de transformation peut se faire automatiquement si le langage de transformation est fourni avec un outil permettant dinterprter les rgles de transformation. A la suite de lapplication des rgles de transformation, nous obtenons un style dcrivant le mtamodle du domaine agenti. 2. gnration de larchitecture : la dernire tape concerne la gnration de larchitecture qui va tre conforme au style du domaine agenti.
3
Nous considrons quune entit dcrit un ou plusieurs concepts relis.
127
Fig. 5.6: La phase danalyse La gnration dune architecture peut se faire soit manuellement soit laide dun outil qui permet de congurer le style en vue de linstancier (cf. gure 5.7).
Reprenons lexemple du client/fournisseur de la section prcdente. Le client est considr comme un acteur du systme. Lentit acteur du mtamodle du domaine peut tre associe lentit agent du mtamodle orient agent. Si le client se contente de recevoir un ordre dachat et de lancer une commande la suite de cet ordre, celui-ci va tre considr comme un agent ractif. Par contre, supposons que le client avant de lancer sa commande, doit tudier les prix pratiqus lors des transactions ultrieures an de xer un seuil ne pas dpasser. Cela suppose que le client est capable de garder un historique de ses actions. De ce fait, le client ne peut tre considr comme un agent ractif puisque ce dernier na ni un tat mental ni un historique. Cependant, le client peut tre conu comme un agent cognitif ou hybride. Si les proprits sont valides, lentit du domaine devient alors une spcication de lentit agent. A ce niveau, le concepteur utilise les rgles de transformation fournies paramtres avec les entits de son domaine. Lapplication de ces rgles va gnrer un nouveau style ddi au domaine agenti. Le concepteur va par la suite congurer ce style an de gnrer son architecture concrte.
128
Fig. 5.7: Application des rgles de transformation
129
CHAPITRE 5. LAPPROCHE ARCHMDE Limplmentation Durant la phase dimplmentation, le dveloppeur naura qu choisir le langage cible avec lequel il voudrait gnrer son application. Le gnrateur de code tant fourni par le cadre de dveloppement, le dveloppeur naura qu lutiliser. Dans la suite de ce chapitre nous allons explorer comment on peut mettre en uvre lapproche ArchMDE laide dun environnement de dveloppement centr architecture.
3.3
Les besoins relatifs la mise en uvre de lapproche
Pour mettre en uvre ArchMDE, il est ncessaire de disposer d"outillages" qui aideront particulirement dans la construction du cadre de dveloppement. Ces outillages seront regroups dans un environnement de modlisation. Ils sont composs de : langage constituant le mta-mtamodle (langage dexpression de style) et qui va tre utilis pour crer les dirents mtamodles. Il doit tre assez gnrique pour permettre la capture des spcicits de chaque domaine. Par ailleurs, ce langage doit tre facile manipuler et comprhensible par tous les participants au projet de dveloppement an dencourager le travail dquipe, un langage de transformation/ranement : ce langage doit faciliter la dnition des rgles de transformation/ranement et ce entre les concepts du domaine et les concepts orients agents. Les rgles de transformation doivent dnir le contexte sur lequel va sappliquer la transformation, lopration eectuer et les proprits vrier, ce qui ncessite un systme de navigation sur les dirents modles, un langage dexpression de proprits : ces proprits peuvent tre soit des contraintes structurelles ou comportementales exprimes au niveau du mtamodle (et devant tre respectes au niveau des modles) ; soit des proprits architecturales qui rgissent le comportement du systme modlis et qui doivent tre respectes lors de son dploiement, des outils dinterprtation et dapplication des rgles de transformation ainsi que des outils de vrication des proprits sont ncessaires an de raner et valider les modles (architectures) produits. Pour fournir ces dirents lments, nous adoptons lenvironnement dingnierie logicielle ArchWare, dvelopp en partie par le laboratoire LISTIC dans le cadre dun projet europen. Nous prsentons cet environnement dans la section suivante. 130
Lenvironnement ArchWare
Lenvironnement ArchWare a t dvelopp au sein du projet europen ArchWare (ArchWare European RTD Project IST-2001-32360). Lobjectif de ce projet consistait fournir un environnement dingnierie logicielle qui permet de rpondre aux problmatiques de dveloppement actuelles. Dans ce contexte, ArchWare fournit des solutions consistant en des langages, des modles de conception et des outils pour lingnierie des architectures logicielles dynamiques (cest dire dont la topologie peut changer) ayant une forte interaction entre ses composants. Ceci est le cas des systmes multiagents puisque les agents sont des entits communicantes, ayant de fortes interactions avec leur environnement ; et qui sont susceptibles de faire voluer la conguration du systme dans lequel ils oprent (thorie dmergence et dauto-adaptation - chapitre 3). Plusieurs partenaires ont particip llaboration de cet environnement : The University of Manchester (Angleterre), The University of St Andrews (Ecosse), Engineering Ingegneria Informatica S.p.A. (Italie), CPR - Consorzio Pisa Ricerche (Italie), INRIA Rhnes-Alpes (France), Thsame - Mcatronique et Management (France) et InterUnec - University of Savoie (France). Dans la mesure o nous avons activement particip ce projet, il nous parat judicieux de lutiliser dans le cadre de cette thse. Mais ceci ne constitue pas le seul argument de notre choix. En eet, lenvironnement ArchWare fournit plusieurs outils qui peuvent nous aider mettre en uvre notre approche ArchMDE. Ceci va tre discut dans la section ?? o nous montrerons que la vision dArchWare rejoint sur plusieurs point celle de ArchMDE. En eet, le but dArchWare est de fournir un environnement personnalisable dingnierie logicielle qui peut tre utilis pour crer des environnements logiciels centrs architecture. Les mcanismes cls de cette personnalisation sont les styles architecturaux qui rappelons-le forment aussi la base de notre approche ArchMDE. Dans le cadre dArchWare, un langage de style est fourni permettant de dcrire les concepts, leurs caractristiques et leurs contraintes. Ce langage permet aussi de dnir une syntaxe pour appliquer ces concepts ainsi quun mcanisme de gnration darchitecture. Ceci rejoint donc nos besoins pour la mise en uvre de ArchMDE. De plus, lenvironnement ArchWare est bas sur une approche formelle amliorant ainsi lexactitude du systme modlis et garantissant une certaine qualit de dveloppement travers une analyse rigoureuse des proprits. Le projet ArchWare fournit un environnement personnalisable centr architecture structur en deux couches distinctes, savoir un cadre conceptuel visant produire les modles architecturaux et un cadre dexcution visant 131
CHAPITRE 5. LAPPROCHE ARCHMDE excuter ces modles an de valider leurs comportements. Le cadre conceptuel dArchWare inclut notamment : un diteur textuel permettant la dnition des styles et des architectures ; un animateur graphique ; des outils de vrication de proprits (statiques et dynamiques) ; un raneur permettant linterprtation et lexcution des rgles de ranement ; un gnrateur de code permettant de gnrer le code correspondant larchitecture dans le langage souhait. Le cadre dexcution inclut un moteur dexcution darchitectures, un processus de ranement de description darchitecture (qui eectue un ranement en cours dexcution) et des mcanismes supportant linteroprabilit des outils de lenvironnement. Nous nallons pas utiliser le cadre dexcution au niveau de cette thse. Nous allons en eet, nous focaliser sur les phases danalyse et de conception ainsi que sur la production de leurs artefacts. De ce fait, ArchWare ore un environnement complet pour lapplication de notre approche ArchMDE. Avant dexpliquer lutilisation de lenvironnement ArchWare dans le cadre de ArchMDE, nous prsentons les langages fournis par cet environnement.
Les langages ArchWare
Les langages ArchWare possdent une grande souplesse dans les descriptions darchitectures dynamiques ayant une forte interaction entre ses composants. Ceci est d au fait que les langages ArchWare soient bass sur le -calcul [Mil99]. Ces langages sont : ArchWare Architecture Description Language ( -ADL) : cest un langage pour la description darchitectures ayant des caractristiques dynamiques et volutives. En eet, le langage permet de capturer les mcanismes permettant larchitecture de changer de topologie et de conguration durant lexcution, ArchWare Architecture Analysis Language (AAL) : cest un langage pour la spcication de divers proprits architecturales (structurelles et comportementales), ArchWare Style Language (ASL) : lutilisation de ce langage permet la personnalisation de lenvironnement puisquil permet la description de styles architecturaux. A travers ce langage nous pouvons introduire la description de divers concepts en leur associant des contraintes. Ce langage permet aussi lintroduction de syntaxe adapte ces concepts. 132
CHAPITRE 5. LAPPROCHE ARCHMDE Enn, ArchWare ASL permet la description de gnrateurs darchitecture (appels constructeurs), ArchWare Architecture Renement Language (ARL) : cest un langage pour la description de rgles de ranement/transformation. Nous allons dans cette section introduire brivement chacun de ces langages. Une description plus approfondie est fournie dans lannexe A. Notons aussi que ces langages sont tous dnis par une EBNF.
5.1
Le langage ArchWare ADL ( -ADL)
Le projet ArchWare propose une famille de langages de description darchitecture. Cette famille est structure en couches, partir dun langage noyau, le langage ArchWare -ADL. Les direntes couches sont construites grce un mcanisme dextension, le style architectural. Le langage -ADL [OACV02], [COB+ 02] est un langage formel conu pour supporter la spcication excutable darchitectures logicielles dynamiques et volutives. Il est fond sur le -calcul [Mil99]. -ADL est dni comme une extension du -calcul typ dordre suprieur : cest une extension bien forme pour dnir un calcul dlments architecturaux mobiles et communicants. Ce langage permet de formaliser la structure et le comportement au sein dune mme description. En -ADL, une architecture est un ensemble dlments, appels lments architecturaux, qui sont relis par des liens de communication. Ces lments sont dnis en terme de comportement (behaviour ). Le langage dnit aussi un mcanisme de rutilisation de comportements paramtrs. Ce mcanisme est appel abstraction. Le comportement est dni par un ensemble dactions ordonnances qui spcient le traitement interne de llment (actions internes) et les interactions avec son environnement (actions de communication). Un lment architectural communique avec les autres par une interface caractrise par un ensemble de connexions (connection ) qui permet de faire transiter des donnes. Un mcanisme de composition et un mcanisme de liaison, appel unication (cest une substitution au sens du -calcul) permettent la mise en relation des lments architecturaux. Ces lments peuvent interagir lorsquils sont composs et lis. Un lment architectural peut tre dni comme une composition dautres lments. En dautres termes, un comportement peut tre dni comme un ensemble dautres comportements interconnects. -ADL permet la description darchitectures dynamiques. En eet, les lments architecturaux peuvent, dune part, tre composs ou dcomposs la vole et, dautre part, des lments architecturaux peuvent tre crs et lis dynamiquement. Enn, des lments architecturaux peuvent transiter comme des donnes travers les connexions. Ce qui fournit un mcanisme adquat pour dcrire la mobilit (exemple les agents mobiles). 133
ArchWare ADL permet de dcrire la fois la structure du systme et son comportement. ArchWare ADL permet la description darchitectures dynamiques. Dabord, les lments architecturaux peuvent tre composs ou dcomposs la vole. Ensuite, des lments architecturaux et des connexions peuvent tre crs dynamiquement. Enn, des lments architecturaux et des connexions peuvent transiter comme des donnes travers les connexions. Lexemple suivant dnit une architecture dcrivant un groupe de deux agents. Ces agents communiquent entre eux : Agent1 envoie une requte travers la connexion call et Agent2 reoit la requte travers la connexion request. Le comportement de chaque agent est dcrit dans une abstraction. Ces abstractions sont ensuite appliques 4 au niveau du groupe qui est lui mme dcrit par labstraction Groupe2Agents. Au niveau de cette abstraction les connexions sont unies an que les deux agents puissent communiquer. LAgent1 eectue un appel lAgent2, puis il attend une rponse. LAgent2 est en attente de lappel de lAgent1. Lorsquil reoit cet appel celui-ci lui rpond. Groupe2Agents est alors considr comme un lment composite.
value Agent1 i s abstraction ( ) { via c a l l send ; via w a i t receive ; unobservable }; value Agent2 i s abstraction ( ) ; { via r e q u e s t receive ; unobservable ; via r e p l y send ) } ; value Group2Agents i s abstraction ( ) ; { value c a l l , wait , r e q u e s t , r e p l y i s connection ( ) ; compose { A1 i s Agent1 ( ) and A2 i s Agent2 ( ) where { A1 : : c a l l u n i f i e s A2 : : r e q u e s t and A2 : : r e p l y u n i f i e s A1 : : w a i t } } }
4
Lapplication dune abstraction gnre un comportement.
134
5.2
Le langage AAL
AAL [AGMO02] est un langage formel pour exprimer les proprits structurelles et comportementales des architectures logicielles volutives modlises en -ADL. Il est dni comme une extension du -calcul [Koz83] qui est limit lexpression de proprits comportementales. Pour exprimer les proprits structurelles, lAAL sappuie sur la logique des prdicats. En AAL, les proprits sont dnies comme des formules prdicatives. Ce langage fournit des prdicats prdnis et des mcanismes (oprateurs et quanticateurs) pour construire de nouveaux prdicats. Un support de vrication des proprits est fourni travers les outils Analyser [AO05] et model Checker [BCD+ 04]. Lexpression suivante dcrit une contrainte qui est vraie si le prdicat p est vrai pour chacun des lments dune collection.
to c o l l e c t i o n apply f o r a l l { e l e m e n t | p ( e l e m e n t ) }
5.3
Le langage ArchWare ASL
Ce langage est considr comme un mcanisme dextension qui reprsente une famille darchitectures ayant des caractristiques communes et obissant un certain nombre de contraintes. Des concepts peuvent tre introduits par un style, et formeront le vocabulaire du style. Il est ainsi possible de dnir des styles architecturaux selon une tour de mta-niveaux : en utilisant la couche -ADL de lenvironnement ArchWare, ASL permet de dnir une couche n+1, fournissant un vocabulaire li aux concepts dun domaine donn. Une architecture dnie en utilisant le langage -ADL a son correspondant dans le langage dni par ASL. Les contraintes associes aux concepts contenus dans les styles sont dcrits par des proprits AAL. Ainsi, ASL forme une couche suprieure incluant -ADL et AAL (cf. gure 5.8) Nos travaux se basent sur ce langage. ASL a t contruit en ciblant deux principaux axes. Le premier concerne lexpression des contraintes. Celles-ci permettent de dlimiter un espace de conception qui caractrise la famille darchitectures, de vrier la satisfaction dune architecture un style ou de rvler les carts au style. Le deuxime axe concerne un support la description architecturale en permettant de spcier une syntaxe spcique au systme. Celle-ci peut tre utilise comme un DSL (Domain Spcic Language), ce qui est trs utile pour les non spcialistes dArchWare qui peuvent dcrire leur architecture sans avoir connaitre les mcanismes dArchWare. 135
Fig. 5.8: Le langage ASL De plus, ASL ore des mcanismes pour la rutilisation des styles. Parmi ces mcanismes, nous citons : linstanciation : linstanciation dun style est la dnition dune architecture telle que celle-ci satisfasse ce style. ASL fournit des constructeurs qui permettent linstanciation des architectures5 , le sous-style : lorsquun style reprsente un sous-ensemble dune famille darchitectures reprsente par un style plus abstrait, on parle de sous-style. Dans le cadre de nos travaux, ASL nous permettra de dcrire des styles architecturaux fournissant : Un vocabulaire pour spcier les concepts, par exemple, Agent, Role, etc. Des rgles de conguration, ou contraintes, qui dterminent comment les lments architecturaux peuvent tre relis, Une interprtation smantique par laquelle les compositions des lments architecturaux ont une signication bien dnie, Des analyses qui peuvent tre appliques sur les systmes construits dans ce style. Dans ce contexte, le langage ASL jouera le rle de mta-mtamodle. et les styles dnis selon ce langage joueront le rle de mtamodle. Les architectures gnres partir de ces styles appartiennent la couche M1 avant dtre instancis au niveau de la couche M0. La syntaxe permettant la description dun style est la suivante. Celle-ci est explique en dtail au niveau de lannexe.
NomDuStyle i s s t y l e extending S t y l e _ p a r e n t where { types { D f i n i t i o n s de types }
Comme nous allons le voir par la suite le mcanisme de constructeur est bien plus gnerique. Il permet linstatiantion des fragments darchitecture ou des types de donnes.
5
136

s t y l e s { D f i n i t i o n s de s t y l e s } constructors { D f i n i t i o n s de c o n s t r u c t e u r s } constraints { D f i n i t i o n s de c o n t r a i n t e s } analyses { D f i n i t i o n s d analyses } }
Notons cependant que types dnit un ensemble de types manipuls au niveau des styles.Styles dnit les styles contenus dans NomDuStyle (relation dagrgation). Constructors dcrivent les mcanismes de gnration de larchitecture. Au niveau des constructeurs, une syntaxe spcique peut tre dnie qui sera interprte selon le code spci par le constructeur. Constraints et Analyses dcrivent les proprits qui doivent tre respectes par les architectures dnies selon ce style. Ces direntes notions sont dcrites de manire dtaille dans lannexe A.
5.4
Le langage ArchWare ARL
ArchWare ARL [Oqu03] est un langage formel bas sur la logique de rcriture, ddi au ranement/transformation darchitectures logicielles avec dune part, la prise en compte du ranement/transformation des donnes, des comportements, des connexions et des structures et, dautre part, la prservation des proprits architecturales lors de lexcution des rgles de ranement/transformation. Le noyau du langage est un ensemble doprations appeles actions de ranement/transformation [Meg04]. Chaque tape de ranement/transformation implique lapplication dune action qui fournit une solution architecturale correcte. Dans ARL, les actions de ranement/transformation sont exprimes par des pr-conditions, des transformations et des post-conditions. Les pr-conditions sont des conditions qui doivent tre satisfaites dans une architecture avant lapplication dune action de ranement. Les post-conditions doivent tre satisfaites suite lapplication dune action de ranement. La transformation dcrit lopration raliser. Un modle darchitecture peut tre ran/transform vers un autre modle darchitecture. Ceci tablit une relation de ranement/transformation binaire note :
a r c h e t y p e a r c h i t e c t u r eDef I d i s a r c h i t e c t u r e { types i s { t y p e D e c l a r a t i o ns } p o r t s i s { p o r t D e c l a r a t i o ns } beh a v i ou r i s { c ompo s i t i onOfCompo n e n t s } }
a r c h e t y p e a r c h i t e c t u r eRe f I d i s a r c h i t e c t u r e { types i s { t y p e D e c l a r a t i o ns } p o r t s i s { p o r t D e c l a r a t i o ns }
137
Fig. 5.9: Le langage ARL

beh a v i ou r i s { c ompo s i t i onOfCompo nents } }
o : typeDeclarations et portDeclarations sont des dclarations de types et de ports avant le ranement et typeDeclarations et portDeclarations sont des dclarations de types et de ports aprs le ranement. portDeclarations contient les connexions libres avec lesquelles les composants communiquent avec lextrieur. compositionOfComponents est le comportement composite avant le ranement et compositionOfComponents est le nouveau comportement composite aprs le ranement. Dans le cadre du projet, le langage ARL a t ddi au ranement/transformation de larchitecture (cest--dire la couche M1). Pour nos besoins spciques dans lapproche ArchMDE, nous avons tendu ce langage an quil prennent en compte le rannement des styles. Dans ce cas, ARL formera une couche suprieure incluant les trois langages ASL, -ADL et AAL (cf. gure 5.9). Nous allons claircir ce point dans la section 9.
Les outils ArchWare
Les langages ArchWare sont accompagns de plusieurs outils qui nous seront indispensables lors du droulement du processus ArchMDE. Ces outils sont : lASL Toolkit, lAnalyser, lAnimator, le Rener, 138
CHAPITRE 5. LAPPROCHE ARCHMDE le Code Synthesizer. Pour la cration des mtamodles et la gnration de larchitecture lASL Toolkit est ncessaire. Lanalyse des proprits dune architecture se fait grce loutil Analyser. Le Rener permet dexcuter les rgles de ranement au niveau architectural (niveau M1). Enn, le code Synthesizer aidera le dveloppeur implmenter larchitecture. Loutil ASL Toolkit Loutil ASL Toolkit [Ley04] permet la personnalisation dun environnement en sappuyant sur la dnition de styles architecturaux. Cet outil contient deux modules : le module "style compiler" et le module "style instantiator". Le premier module compile des dnitions de styles crites en ASL, tandis que le second gnre des instances du style. Celles-ci constituent des architectures (abstraites ou concrtes selon le niveau dabstraction du style). Ces architectures seront dcrites en -ADL. ASL Toolkit est implment en Java et en XSB Prolog. Cet outil sera utilis lors de la cration des mtamodles. Chaque mtamodle sera compil an de vrier sil est correctement construit. A la n du processus dagentication, larchitecte, pourrait utiliser le module "style instantiator" pour gnrer son architecture. Loutil Analyser Nous avons activement particip llaboration de cet outil [AO05]. Au cours du processus ArchMDE, lAnalyzer va tre utilis pour vrier que larchitecture gnre partir du style respecte bien toutes les proprits et contraintes dclares par celui-ci. Pour cela, loutil Analyzer sappuie sur les dmonstrations logiques pour raliser des vrications de proprits exprimes en AAL. Il est implment en Java et XSB Prolog. Cet outil comporte deux modules, le module reier et le module moteur danalyse. Le module reier permet de rier larchitecture dcrite en -ADL en faits Prolog, an de pouvoir raisonner sur celle-ci et vrier les proprits. Cette rication est faite suite une analyse syntaxique suivie dune analyse smantique de larchitecture dcrite en -ADL. Des faits prolog sont alors gnrs en fonction de la smantique de chaque expression. Le moteur danalyse est un module qui prend en entre un chier contenant la description architecturale en -ADL et un chier contenant les proprits dcrites en AAL. Les proprites en AAL vont tre analyses syntaxiquement et smantiquement avant dtre transformes en prdicats prolog. 139
Fig. 5.10: Le processus de vrication eectu par Analyser Les prdicats Prolog vont raisonner sur les caractristiques structurelles de larchitecture ainsi que sur les caractristiques comportementales. En eet, le comportement de larchitecture va tre traduit par des arbres relis chacun son abstraction. La vrication des proprits comportementales se fait en parcourant ces arbres. Le processus de vrication des architectures se fait donc selon deux phases (cf. gure 5.10) : processus de rication de larchitecture, processus vrication. Loutil Analyser va tre utilis par lanalyseur aprs la gnration de larchitecture et chaque pas de ranement, o loutil va tre voqu pour vrier larchitecture. Loutil Animator Loutil Animator [APVO03], [PVA+ 05] anime des descriptions darchitectures crites en -ADL, il est implment en Java et en XSB Prolog. Cet outil, contrairement lanalyseur, ne permet pas de vrication formelle. Il sagit en ralit de gnrer les traces dexcution dune architecture et de les interprter graphiquement. Ceci permet larchitecte ou lanalyste de valider le comportement de larchitecture. Dans le cadre de notre approche lanimateur peut tre utilis aprs la gnration de larchitecture pour interprter graphiquement les traces dex140
CHAPITRE 5. LAPPROCHE ARCHMDE cution de larchitecture. Loutil Rener Loutil Rener [Meg04] se base sur le langage ARL pour construire (par ranement) une architecture, il est implment sous MAUDE [CDS+ 03]. Il sappuie sur les actions de ranement pour gnrer, de faon formelle, une nouvelle architecture. Dans notre contexte, loutil Rener pourrait tre utilis par larchitecte pour ajouter de nouveaux dtails larchitecture ou pour ajuster celle-ci an quelle respecte certaines proprits. Cependant, dans le cadre dArchWare, cet outil a t conu pour tre utilis au niveau de larchitecture et nest pas adquat pour prendre en compte la transformation de style.
Loutil Code Synthesizer Loutil Code Synthesizer [BFDP05] sappuie sur des rgles de transformation pour gnrer la description dune architecture dans un langage cible (excutable). Concrtement, cet outil permet de transformer du code crit en -ADL en nimporte quel langage cible pour peu que des rgles de transformation soient crites. De par les langages et les outils quil ore, lenvironnement ArchWare est bien adapt pour lapplication de notre approche ArchMDE. Cet environnement sera utilis par les experts en mtamodlisation an de construire le cadre de dveloppement spcique un domaine. Cet environnement devrait tre transparent pour les autres dveloppeurs. Dans la suite de ce chapitre, nous expliquons comment utiliser les langages et les outils durant le processus ArchMDE.
Formalisation du mtamodle du domaine
Nous avons formalis avec le langage ASL le mtamodle du domaine fournis dans la section 3.1, ce qui nous a permis de gnrer une syntaxe relative ces concepts, simpliant ainsi leur application. Nous allons dcrire ci-dessous la formalisation de ces entits avec ArchWare ASL. An de simplier la comprhension, nous adoptons un exemple pdagogique dcrivant un client et un fournisseur excutant un processus de commande.
7.1
dataEntity
Une dataEntity na aucun comportement mais se contente de dcrire certaines donnes du systme. Les dataEntities peuvent tre simples ou compo141
Fig. 5.11: Le code ASL de dataEntity sites. Pour les dcrire, nous utilisons les types de base dArchWare ADL. Une dataEntity est dnie par son name, qui permet de la rfrencer. Elle dnit aussi les types des donnes qui la constituent(typeOfDataEntity ). Accessoirement, une dataEntity peut aussi spcier les valeurs par dfaut qui seront assignes lors de la cration/instanciation de la donne (defaultValue ). Nous donnons ci-dessous une description du constructeur relatif dataEntity exprime en ArchWare ASL. A ce constructeur est associ une syntaxe mixx, qui dnit un langage ddi que les spcialistes du domaine dapplication peuvent utiliser sans tre experts du domaine. Le style correspondant dataEntity sexprime de la manire suivante en ArchWare ASL 5.11 Quand il va dcrire une dataEntity particulire, le dveloppeur va la syntaxe introduite par le mixx. Celle-ci permet dintroduire trois paramtres : le nom attribu celle-ci (variable $_name), le type qui permet de la dcrire (variable $_typeOfDataEntity) et optionnellement la valeur par dfaut quelle prend lors de linstanciation (variable $_typeOfDataEntity). Par exemple, dans le systme que nous traitons, le fournisseur manipule lattribut stock dans lequel est dnie la valeur du stock. A linitiation, celui-ci contient 100 lments. Ceci est dcrit de la manire suivante, en utilisant la notation mixx fournie par le constructeur :
s t o c k i s d a t a E n t i t y with { t y p e E n t i t y : d e f a u l t value i s 1 0 0 } ; integer ;
Comme nous le constatons, les mcanismes fournis par ASL sont faciles utiliser. Le constructeur permettra de crer un nouveau type dont le nom est _name contenant son type et sa valeur de base. La notation mixx facilite lapplication de ce type. En eet, lutilisateur nal naura pas connatre la syntaxe de base de ASL. Il utilisera directement la syntaxe dnie par le mixx. Contraintes et Analyse
142
CHAPITRE 5. LAPPROCHE ARCHMDE Nous avons identi plusieurs proprits relatives aux dataEntity : proprits sur les valeurs : cette classe de proprits impose des contraintes sur les valeurs assignes aux instances de dataEntity. Par exemple, la valeur stock ne doit jamais dpasser la capacit maximale dun dpt. Ceci peut sexprimer en AAL de la manire suivante :
to s t o c k . I n s t a n c e s apply { s t o c k . I n s t a n c e s . value <= depot . I n s t a n c e s . c a p a c i t y }
Lexpression de cette contrainte suppose bien sr quun style dpt soit dni et que celui-ci contienne une valeur capacit. proprits sur la visibilit : cette classe de proprits permet de denir le degr de visibilit de la dataEntity partir dune activeEntity/taskEntity ou une structureEntity. Ces proprits portent ainsi sur le lien entre la dataEntity et les autres entits. En eet, une dataEntity peut tre visible (et donc accessible) certaines entits et compltement invisible dautres. Au niveau de AAL, nous avons cr un prdicat isInvisible(dataEntity, Entity) qui permet de notier quune instance de dataEntity est invisible lautre. Un exemple dutilisation de ce prdicat est fourni dans la proprit suivante qui stipule quun fournisseur na nullement accs au stock dun client :
to c l i e n t . I n s t a n c e s apply { i s I n v i s i b l e ( stock . instances , fournisseur . Instances ) }
proprits sur la cardinalit : cette classe de proprits permet de contraindre le nombre dinstances cres pour une dataEntity. Par exemple, la proprit suivante exprime quil peut y avoir entre une et cinq instances de clients dans une structureEntity appele "clientsFournisseur".
to c l i e n t s F o u r n i s s e u r . I n s t a n c e s . e l e m e n t s apply { exists ( [ 1 . . 5 ] x | x in s t y l e Client )
7.2
taskEntity
Le concept taskEntity dcrit les actions atomiques de base qui doivent tre ralises au niveau du domaine. Celles-ci vont tre par la suite regroupes selon un certain ordonnancement pour dcrire le comportement dune entit active (activeEntity ). Une taskEntity dcrit donc une partie du comportement. Cette dcomposition nous permettra de faciliter lintgration de ces fragments du comportement au sein dun processus. Par ailleurs, ceci facilitera lidentication des tches assigner aux agents lors de la phase "dagentication".
143
CHAPITRE 5. LAPPROCHE ARCHMDE Une taskEntity peut recevoir des paramtres en entre (_inputParametersOfTaskEntity ) et produire des rsultats en sortie(_outputOfTaskEntity ) suite une opration eectue (_operationOfTaskEntity ). Les rsultats en sortie seront communiqus par des connexions libres. En eet, ArchWare ADL ne permet pas de modliser des fonctions qui vont directement communiquer leur rsultat. Cette entit est formalise en ASL de la manire suivante :
taskEntity is constructor ( _name : A l i a s ; _inputParametersOfTaskEntity : set [ A t t r i b u t e s ] ; _operationOfTaskEntity : E x p r e s s i o n [ Behavior ] ; _outputOfTaskEntity : set [ Connection ] ) ; { type t a s k E n t i t y i s view [ name : _name ; p a r a m e t e r s O fT a s kE nti ty : _parametersOfTaskEntity ; b e h a v i o u r O f T a s k E n t i t y : _operationOfTaskEntity ; outputOfTaskEntity : _outputOfTaskEntity ] } } as $_name i s t a s k with { [ input : { $ _parametersOfTaskEntity ; } ] o p e r a t i o n : {$ _operationOfTaskEntity ; } [ output : { $ _outputOfTaskEntity } ] }
Nous pouvons observer que le constructeur prend quatres paramtres : le nom, la liste des paramtres en entre, lopration et la liste des paramtres en sortie de la taskEntity. Ce constructeur sera dans notre cas utilis en utilisant la notation mixx qui lui est associe. Lexemple suivant de lutilisation du constructeur taskEntity reprsente un comportement qui consiste crer un bon de commande et lenvoyer. Ceci va sexprimer de la manire suivante :
passerCommande i s t a s k with { input : { _numCommande : String _nomClient : String ; _ r e f P r o d u i t : Integer ; _quantit : Integer ; _dateDeLivraison : String } operation : { value operationPasserCommande i s behaviour { value Commande i s view ( numCommande i s _numCommande ; nomClient i s _nomClient ; refProduit is _refProduit ;
144

q u a n t i t i s _quantit ; d a t e D e L i v r a i s o n i s _dateDeLivraison ) )} value passerCommande_connection i s f r e e connection (Commande ) ; via passerCommande_connection send Commande ; output : { passerCommande_connection : connection (Commande) } }}
La liste de paramtres dentre de cette taskEntity contient un numro de commande (_numCommande ), le nom du client(_nomClient ), la rfrence du produit (_refProduit ), la quantit (_quantit ) et une date de livraison (_dateDeLivraison ). Le comportement li cette opration consiste crer une instance dune commande sous forme dune vue en fonction des paramtres qui ont t passs. Par la suite, cette commande est envoye au fournisseur via la connexion passerCommande_Connection. Cette connexion est donne dans liste de paramtres de sortie. Contraintes et Analyse Les contraintes relatives taskEntity sont aussi varies. Nous prsentons quelques unes : la relation inclusion : cette relation est tablie entre deux taskEntity 6 et signie que tout comportement reprsentant linstanciation de taskEntity2 inclut un comportement reprsentant linstanciation de taskEntity1. Cette proprit peut sexprimer comme suit :
include is analysis { kind AAL input { taskEntity1 : taskEntity , taskEntity2 : taskEntity } output { Boolean } body { to t a s k E n t i t y 2 . I n s t a n c e s apply { e x i s t s { t 1 : t a s k E n t i t y 1 . i n s t a n c e | t r u e . t 1 . t r u e } } }}
Nous avons modlis cette proprit par une analyse. En eet, il est utile de vrier cette proprit au niveau architectural pour savoir si larchitecture analyse rpond bien aux exigences du style.
Ici par taskEntity nous faisons rfrence au style taskEntity. Une instance de ce style peut etre construite en utilisant le constructeur qui porte le mme nom et pour lequel nous avons donne une dnition ASL auparavant.
6
145
CHAPITRE 5. LAPPROCHE ARCHMDE succession directe : cette contrainte existe aussi entre deux taskEntity et signie quun comportement reprsentant linstantitation de taskEntity1 est immdiatement suivi par un autre comportement reprsentant linstanciation de taskEntity 2.
successionDirecte is analysis { kind AAL input { taskEntity1 : taskEntity , taskEntity2 : taskEntity } output { Boolean } body { to s t y l e . I n s t a n c e s apply { f o r a l l { t1 : taskEntity1 . I n s t a n c e s | exists { t2 : taskEntity2 . I n s t a n c e s | t r u e . t 1 . t 2 . t r u e } } } }
succession indirecte : cette contrainte signie quun comportement reprsentant linstanciation de taskEntity1 est indirectement suivi par un autre comportement reprsentant linstanciation de taskEntity2.
successionIndirecte is analysis { kind AAL input { taskEntity1 : taskEntity , taskEntity2 : taskEntity } output { Boolean } body { to s t y l e . I n s t a n c e s apply { f o r a l l { t1 : taskEntity1 . I n s t a n c e s | exists { t2 : taskEntity2 . I n s t a n c e s | t r u e . t 1 . t r u e . t 2 . t r u e } } }
choix conditionnel : cette contrainte peut tre applique pour vrier que deux taskEntities sont mutuellement exclusives selon une condition C. Ceci sexprime comme suit :
choixConditionnel is analysis { kind AAL input { taskEntity1 : taskEntity , taskEntity2 : taskEntity } output { Boolean } body {
146

to s t y l e . I n s t a n c e s apply { f o r a l l { t1 : taskEntity1 . I n s t a n c e s | exists { t2 : taskEntity2 . I n s t a n c e s | e x i s t s { c : boolean | t r u e . ( ( c== t r u e ) . t 1 ) or ( ( c==f a l s e ) . t 2 ) . t r u e } } } } } }
choix indterministe : cette contrainte vrie que deux taskEntity sont mutuellement exclusives sans quune condition ne soit xe. Ceci est exprim comme suit :
choixIndterministe is analysis { kind AAL input { taskEntity1 : taskEntity , taskEntity2 : taskEntity } output { Boolean } body { to s t y l e . i n s t a n c e apply { f o r a l l { t1 : taskEntity1 . I n s t a n c e s | t 1 . { not ( e x i s t s { t 2 : t a s k E n t i t y 2 . I n s t a n c e s | true . t2 })} or f o r a l l { t2 : taskEntity2 . I n s t a n c e s | t 2 . { not ( e x i s t s { t 1 : t a s k E n t i t y 1 . I n s t a n c e s | true . t1 })} } }}
paralllisme : cette contrainte vrie si deux taskEntity sont mises en parallle. Elle sexprime de la manire suivante :
paralllisme is analysis { kind AAL input { taskEntity1 : taskEntity , taskEntity2 : taskEntity } output { Boolean } body { to s t y l e . i n s t a n c e apply { f o r a l l { t1 : taskEntity1 . I n s t a n c e s | exists { t2 : taskEntity2 . I n s t a n c e s | t r u e . compose { ( true . t1 . true )
147

and ( true . t2 . true ) }}}} }}
7.3
activeEntity
Les activeEntities dcrivent les acteurs du systme responsables de lexcution dune ou plusieurs tches selon un processus bien dni. Ce processus contient au moins une ou plusieurs taskEntities. Les activesEntities peuvent aussi contenir quelques attributs permettant par exemple, de passer les paramtres aux taskEntities quils vont activer. Ainsi, les activeEntities sont formalises de la manire suivante :
activeEntity is constructor ( _name : A l i a s ; _ a t t r i b u t e s : set [ A t t r i b u t e s ] _p roc ess : E x p r e s s i o n [ t a s k E n t i t y ] ) ; { type a c t i v e E n t i t y i s view [ name : _name ; attributesOfActiveEntity : _attributes ; p r o c e s s O f A c t i v e E n t i t y : _process ] } } as $_name i s a c t i v e E n t i t y with { attributes : { $ _attributes ;} p r o c e s s : {$ _ pr o c es s ; } }
Nous continuons notre exemple du client qui va passer une commande un fournisseur. A la suite de cette commande, le client attend la rponse du fournisseur qui va accepter ou pas de traiter la commande. Cette entit active va avoir un processus squentiel qui consiste passer une commande au fournisseur, celui-ci va ensuite attendre la rponse du fournisseur. Si la rponse est positive, le client va recevoir la livraison de la commande et procder par la suite au paiement. Si la rponse est ngative, nous supposons que le processus va sarrter. Le processus dcrit donc lordre dinstanciation des taskEntities. Pour traduire cette relation entre les taskEntities et les activeEntities, nous utiliserons loprateur new propos dans le langage ASL [Ley04]. La structure syntaxique de cet oprateur est la suivante :
new nom_meta e n t i t [ named nom_entite ] [ i n i t i a l i s e d with { p a r a m e t e r s } ]
148
CHAPITRE 5. LAPPROCHE ARCHMDE Notons que nom_entite est optionnel. Voici maintenant la description du client en ASL :
C l i e n t i s a c t i v e E n t i t y with { attributes : { numCommande i s String d e f a u l t value i s "num0001" ; nomClient i s String d e f a u l t value i s " C l i e n t 1 " ; r e f P r o d u i t i s String d e f a u l t value i s " r e f 0 0 1 " ; q u a n t i t i s I n t e r g e r d e f a u l t value i s 1 0 0 ; d a t e D e L i v r a i s o n i s String d e f a u l t value i s " 11 dec2007 " ; } process : { new passerCommande with { p a r a m e t e r s : set (numCommande ; nomClient ; r e f P r o d u i t ; quantit ; dateDeLivraison ) } ; new a t t e n d r e R e p o n s e ; choose { done or behavior is { new r e c e v o i r L i v r a i s o n ; new payementFacture ; done } } } }
Contraintes et Analyse Une activeEntity va en premier lieu respecter les contraintes dcrites par les taskEntity et les dataEntity. Dautres contraintes peuvent tre dcrites ce niveau : communicationForbidden : cette contrainte impose que deux activeEntities ne doivent pas directement communiquer ensemble. Ceci veut dire que les activeEntities en question nont aucune unication de connexions. communicationPrescribed : cette contrainte impose que deux ou plusieurs activeEntities doivent communiquer ensemble. Au contraire de communicationForbidden, ces activeEntities doivent unier leurs connexions.
7.4
structureEntity
La structureEntity peut tre considre comme llment composite auquel appartient direntes activeEntities, taskEntities et dataEntities. Dans notre exemple, il sagit du systme regroupant les deux entits client-fournisseur. 149
CHAPITRE 5. LAPPROCHE ARCHMDE Ce systme va reprsenter un maillon dune supply chain. Cette structure est responsable de linstanciation des deux entits actives. Au sein de cette structure, les entits actives tournent en parallle. Lentit structurelle est responsable de la synchronisation des entits actives si celles-ci doivent communiquer. Rappelons que les langages ArchWare synchronisent les processus en uniant les connexions sur lesquelles elles sont senses communiquer. Ainsi, structureEntity contient deux lments : lensemble des entits actives lui appartenant ; leur conguration qui consiste lunication de leurs connexions libres. La formalisation de structureEntity est dcrite ci-dessous :
structureEntity is constructor (_name : A l i a s ; _ a c t i v e E n t i e s : set [ A c t i v e E n t i t y ] _ c o n f i g u r a t i o n : set [ view [ c1 : connection [ Any ] , c2 : connection [ Any ] ] ) ; { type s t r u c t u r e E n t i t y i s abstraction [ ] ; { value _Name i s abstraction ( ) { project _ a c t i v e E n t i e s as n and s e t A c t i v e E n t i t y ; i t e r a t e sequence ( 1 . . n ) by i : Natural ; from value composingElements i s behaviour ( ) accumulate { compose s e t A c t i v e E n t i t y : : i and composingElements } where { _ c o n f i g u r a t i o n : : c1 : : i u n i f i e s _ c o n f i g u r a t i o n : : c2 : : i ; } } as $_name i s s t r u c t u r e E n t i t y with { a c t i v e E n t i t i e s : { $ _activeEnties } c o n f i g u r a t i o n : {$ _ c o n f i g u r a t i o n } }
En utilisant notre systme de client fournisseur sera modlis comme suit :

c l i e n t F o u r n i s s e u r i s s t r u c t u r e E n t i t y with { a c t i v e E n t i t i e s : {new c l i e n t ; new f o u r n i s s e u r } c o n f i g u r a t i o n : { set ( view ( c l i e n t : : passerCommande_connection ; f o u r n i s s e u r : : recevoirCommande_connection ) ; view ( c l i e n t : : r e c e v o i r N o t i f i c a t i o n _ c o n n e c t i o n ; f o u r n i s s e u r : : notifierCommande_connection ) ;
150

... } )}
Contraintes et Analyse A ce niveau, les contraintes dcrites au niveau des dataEntities, taskEntities et activeEntities doivent toutes tre respectes. Il faut aussi vrier que la vivacit et la suret du systme sont garanties. Il est ncessaire aussi que ce systme ne contient pas dinterblocage. Labsence d interblocage peut tre vrie de la manire suivante : toutes les connexions sont unies (cest--dire que chaque entit communiquante a un interlocuteur), les connexions unies transportent le mme type de donnes, une action denvoi correspond une action de rcption.
Le mtamodle orient agent
Ce mtamodle introduit les dirents mcanismes appliqus au niveau des systmes multi-agents indpendemment des domaines quils sont en train de traiter. Nous avons vu au cours du chapitre 3 que plusieurs mtamodles sont proposs par les mthodologies et que plusieurs smantiques peuvent correspondre ces concepts. Nous ne pouvons ce jour, armer quun tel mtamodle est meilleur quun autre. Dailleurs, ceci ne constitue pas lobjet de nos travaux. Ainsi, il est important de donner une certaine exibilit dans la construction du mtamodle orient agent [AHO06]. Cette exibilit implique quun expert de systme multi-agents peut proposer une bibliothque de styles dcrivant dirents concepts orients agent, que larchitecte peut utiliser sa guise lors du processus dagentication. La description des concepts ainsi que leurs relations se fait aussi en utilisant le langage ArchWare ASL qui permet de dnir les constituants dun concept, ses mcanismes de fonctionnement, sa manire de le construire (cest--dire la manire de crer une architecture partir dun style), ses contraintes ainsi que ses analyses qui reprsentent les proprits quune architecture doit respecter. Par ailleurs, nous avons vu que le style nous permettra de dnir une syntaxe spcique au domaine multi-agent qui peut facilement tre utilisable par un non spcialiste ArchWare. Il nous serait impossible dnumrer tous les concepts orients agent et de les formaliser avec le langage ArchWare ASL. Nous avons donn un exemple de mtamodle orient agent dans la section 3.1. Au cours de cette section, nous allons formaliser une partie de ce mtamodle illustrant un agent ractif. Nous avons choisi ce type dagent pour des raisons pdagogiques, tant donn que cest le type dagent le plus simple mettre en uvre. Une vue 151
Fig. 5.12: Mtamodle dAgent Ractif plus dtaille sur lagent ractif est dcrite dans la gure 5.12. Un agent ractif est compos de capteurs et deecteurs. Les capteurs contiennent des actions de perception permettant de percevoir les vnements survenus dans lenvironnement (et plus particulirement sur les ressources de lenvironnement). Les eecteurs contiennent des actions proactives permettant de changer ltat de lenvironnement. Les capteurs et les eecteurs sont lis au moteur interne de lagent qui permet dassocier une action de perception une action proactive. A la suite de cette section, nous allons prsenter comment le style dun agent ractif est formalis. Par la suite, nous prsenterons la manire dassocier une syntaxe un style architectural.
8.1
Formalisation du style agent ractif
Pour reprsenter le style de lagent ractif tel quil est dcrit dans la gure 5.12, nous protons des mcanismes daggrgation fournis par le langage ASL qui nous permet de facilement dcrire la structure dun agent ractif :
agentReactif is style { capteur is s t y l e { . . . } moteur i s s t y l e { . . . } effecteur is style { . . . } }
Ce style peut dcrire direntes sortes darchitectures dagent ractif. Ainsi, une architecture peut limiter le nombre de capteurs utiliss un seul capteur percevant un seul vnement ou au contraire plusieurs capteurs percevant plusieurs sortes dvnements. De mme un eecteur peut agir sur une ou plusieurs ressources de lenvironnement. Dans ASL, un style peut dnir des constructeurs. Le constructeur introduit les mcanismes de fonc152
CHAPITRE 5. LAPPROCHE ARCHMDE tionnement dun concept. Concrtement, il dnit le comportement qui sera gnr au niveau de larchitecture. Par exemple, le constructeur suivant va prendre en paramtres les capteurs, moteurs, eecteurs et conguration. Il va composer (cest--dire mettre en parallle) ces dirents lments, ensuite congurer leurs liens en appliquant bindings. Un constructeur dun agent ractif contenant un capteur, un moteur et un eecteur va tre dcrit de la manire suivante :
reactiveAgent is constructor ( _ID : A l i a s , captor : captor . Instance engine : engine . Instance e f f e c t o r : e f f e c t o r . Instance b i n d i n g : set [ tuple [ E x p r e s s i o n [ Connection ] , E x p r e s s i o n [ Connection ] ] ] ) { abstraction ( ) ; { compose { captor () and engine () and effector () } where { i t e r a t e b i n d i n g s by i : Natural do project b i n d i n g s : : i as c1 , c2 do c1 u n i f i e s c2 ; } } }}
A lapplication de ce style (en utilisant loutil ASL TOOLKIT), une abstraction va tre gnre dont le comportement consiste mettre en parallle le capteur, le moteur et leecteur. Ces dirents lments sont eux-mmes dcrits par des styles ayant des constructeurs permettant ainsi de dcrire le comportement de chaque entit.
8.2
Dnition dune syntaxe
An de faciliter la tche de larchitecte durant le processus dagentication, le styliste peut fournir une syntaxe lie un constructeur. Cette syntaxe va faciliter lutilisation du style par un utilisateur lambda. Voici un exemple de syntaxe pour un agent ractif :
$_ID i s r e a c t i v e A g e n t with { c a p t o r s {$ c a p t o r s }
153

e n g i n e {$ e n g i n e } e f f e c t o r s {$ e f f e c t o r } b i n d i n g s {$ b i n d i n g } }
Quand il va utiliser cette syntaxe, larchitecte dclare un agent ractif en dnissant son identiant, sa liste de capteurs, sa liste deecteurs, son moteur et sa conguration que nous avons nomme ici bindings. Cette conguration permet de dcrire le lien qui existe entre les actions de perception et les actions proactives. Au niveau de ASL, ce lien va tre dcrit par une synchronisation des connexions internes partages dune part entre les actions de perception contenues dans les capteurs et le moteur interne de lagent et dautre part entre le moteur et les actions proactives contenues dans les eecteurs. Rappelons que la synchronisation dans ArchWare ADL se fait en uniant les connexions sur lesquelles la communication entre deux entits va seectuer. Bindings est donc un ensemble qui contient des tuples7 de connexions allant tre unies.
8.3
Proprits dun agent ractif
Nous pouvons dnir plusieurs proprits au niveau de lagent ractif. Ces proprits peuvent concerner la conguration de lagent. Ainsi, lagent ractif doit possder au moins un capteur et un eecteur. Ceci est dcrit comme suit :
Captor_and_effector_instances i s c o n s t r a i n t { to r e a c t i v e A g e n t . I n s t a n c e s apply { exists {c | c is captor . Instances } and exists {e | e is e f f e c t o r . Instances } }
Les seules connexions libres dun agent ractif doivent appartenir soit un capteur soit un eecteur mais jamais au moteur de lagent, tant donn que celui-ci ne peut communiquer avec lextrieur qu travers son capteur ou son eecteur. Cette proprit va tre exprime comme suit :
Reactive_agent_connections i s c o n s t r a i n t { to r e a c t i v e A g e n t . I n s t a n c e apply { f o r a l l { c : f r e e connection [ Any ] | ( c i s I n captor . Instances ) or ( c i s I n e f f e c t o r . I n s t a n c e s )} } }}
un tuple est un type compos fourni par archWare ADL et qui permet de regrouper plusieurs valeurs (voir annexe A)
7
154
CHAPITRE 5. LAPPROCHE ARCHMDE Aprs la spcication des styles du domaine et du style orient agent, il sagit maintenant de spcier les rgles de transformation qui vont nous permettre dagentier le domaine. Ceci est dcrit dans la section suivante.
Le processus dagentication
Au cours de ce processus, les styles dnis dans le mtamodle du domaine et ceux dnis dans le mtamodle orient agent vont tre combins an dobtenir un style du domaine agenti. Ce style va permettre de dnir la syntaxe relative la conception dun domaine agenti. Cest en utilisant ce style que le concepteur va gnrer larchitecture de son systme. Le rsultat de cette combinaison doit conserver les proprits des deux prcdents mtamodles. Pour expliquer notre dmarche, nous nous appuyons sur les deux mtamodles dnis dans les sections 7 et 8. Nous avons spci dans le tableau 3.1 de ce chapitre quelques exemples de tissage entre les entits du mtamodle du domaine et les entits du mtamodle agent. Au cours de cette section, nous allons formaliser quelques rgles de tissage en employant le langage ArchWare ARL. Cependant, avant dutiliser ce langage des extensions sont ncessaires dans la mesure o ce langage permet uniquement le ranement des expressions architecturales au niveau M1. De plus, celui-ci est bas sur un style composant/connecteur.
9.1
Extension du langage ARL
An davoir la possibilit dutiliser le langage ARL dans notre contexte, deux possibits sorent nous dans ce cas : utiliser le langage tel quil est, ce qui nous obligera exprimer nos entits avec le style composant/connecteur, tendre le langage ARL an de prendre en compte la syntaxe exprime au niveau du mtamodle du domaine et du mtamodle orient agent. Nous pensons que la premire mthode alourdira le processus dagentication, dans la mesure o cela obligera larchitecte bien connatre le fonctionnement du style composant/connecteur. Nous avons ainsi opt pour la deuxime solution qui consiste tendre le langage ARL pour prendre en compte les nouvelles syntaxes. Cette solution est tout fait faisable dans la mesure o les rgles de transformation sont bases sur des oprateurs gnriques qui peuvent sappliquer toutes les entits structurelles. Ces oprateurs sont : becomes : pour modier une entit includes : pour introduire une nouvelle entit (exprime avec une syntaxe spcique excludes : pour supprimer un lment 155
CHAPITRE 5. LAPPROCHE ARCHMDE Sur la base de ces lments nous modions la BNF du langage comme suit :
a r c h e t y p e D e f i n i t i on : : = a r c h e t y p e i d e n t i f i e r i s { ... [ s t y l e E x p r e s s i on ] } r e f A c t i on : : = . . . | S t y l e A c t i on S t y l e A c t i on : : = includes s t y l e E x p r e s s i on | excludes s t y l e E x p r e s s i on | bec omes s t y l e E x p r e s s i on
Dans ce qui suit, nous allons utiliser cette extension du langage pour tisser les styles du domaine et les styles orients agent.
9.2
Le tissage des mtamodles
Le choix du concept orient agent qui va reprsenter lentit du systme se fait en fonction des proprits qui ont t dnies sur celles-ci. Par exemple, une dataEntity va tre considre comme une ressource de lenvironnement de lagent si elle est accessible par plusieurs activeEntity alors quelle va tre considre comme un tat mental ou un attribut dagent si elle est utilise par une seule activeEntity. Ainsi pour transformer une dataEntity en ressource de lenvironnement, la prcondition suivante doit tre vrie :
to data : d a t a E n t i t y . I n s t a n c e s apply { forall { a : activeEntity | i t e r a t e a by i : Natural do { i f i s V i s i b l e ( data , a : : i ) do a : : i includes a c t i v e E n t i t y S e t } and activeEntitySet . size > 1 }
Cette proprit parcourt les entits actives du systme. Si celles-ci accdent la donne considre, elles sont incluses dans lensemble activeEntitySet. Si la taille de cet ensemble est strictement suprieure 1, dataEntity peut tre transforme en une ressource dans lenvironnement grce lopration suivante :
doma inMet amo d e l : : da t a includes a gentifiedMM : : Envi r o nment
Une taskEntity peut tre excute par une seule entit active. Si lentit active est reprsente par un agent, celui-ci va intgrer lentit active au 156
Fig. 5.13: Agentication dune activeEntity en agentReactif niveau de ses actions. Par ailleurs si la taskEntity est excute par plusieurs entits actives, celle-ci va intgrer une entit rle. Combinaison des syntaxes Un mtamodle dun domaine agenti permettra de gnrer une syntaxe (qui pourrait tre utilise comme un DSL(Domain specic Language)) qui aidera concevoir un domaine dapplication selon les concepts agent. En utilisant ArchWare, cela reviendrait combiner les notations mixx spcies au niveau des styles contenus dans les deux mtamodles. Une combinaison de la syntaxe peut se faire en utilisant le langage ARL. La gure 5.13 illustre lagentication dune entit active. Ainsi, daprs ce patron de transformation, le ux dentre dune entit active devient un ux d vnements que les capteurs dun agent ractif va intercepter. Le comportement de lentitActive qui permet dinterprter ces vnements sera inclue dans le moteur de lagent. Enn, les ux en sortie seront envoys par les eecteurs.
157
CHAPITRE 5. LAPPROCHE ARCHMDE La rgle de ranement de cette gure fournit un patron dagentication qui pourrait tre utilis par larchitecte. Un nouveau style dcrivant lentit formalise sera gnr la suite de cette action. Le nouveau style conservera les proprits dnies dans le mtamodle du domaine mais aussi dans le mtamodle orient agent. Cependant, pour le moment cette opration bien que formalise, sera eectue manuellement par larchitecte. En eet, les outils implments dans le cadre du projet ArchWare (en particulier loutil Rener) ne permettent pas de prendre en compte le ranement des styles. Nous soulverons ce point dans les perspectives de cette thse. Par ailleurs, notons que la formalisation de cette rgle "dagentication", permet de conserver le savoir-faire.
10
Gnration de larchitecture
Les outils fournis par ArchWare peuvent assister les utilisateurs lors de lapplication de la dmarche ArchMDE. Nous supposons partir de ce point que les experts de mtamodlisation ont fourni les mtamodles du domaine, et le mtamodle orient agent. Le concepteur suite au processus dagentication veut gnrer son architecture. Cette tche se fait en utilisant ASL TOOLKIT (c.f. section 6). Cet outil prend en entre une expression en ASL et gnre larchitecture en ADL selon le processus dcrit dans la gure 5.14. Pour illustrer la gnration de larchitecture, reprenons lexemple de lagent ractif reprsentant un service dapprovisionnement. Celui-ci reoit un besoin et lance une commande. Le capteur de cet agent va recevoir un vnement indiquant quil y a besoin de se rapprovisionner. Dans la gure 5.15 nous nous concentrons sur le style du capteur. La premire case contient la syntaxe qui va tre utilise par le concepteur. Cette syntaxe est produite suite au processus dagentication. Selon le mcanisme du langage ASL, cette syntaxe renvoie un constructeur de style, lequel dcrit la manire dont larchitecture doit tre dcrite. Le compilateur de ASL Toolkit va interprster le constructeur et gnrer larchitecture ADL correspondante.
11
Validation des proprits
La validation des proprits est eectue suite la gnration de larchitecture. En eet, il nexiste pas encore doutil supportant la validation des proprits au niveau du style architectural. Les proprits qui sont exprimes au niveau du style du domaine agenti, sont regroupes dans un chier ".aal". Loutil Analyzer prend en entre ce chier avec celui qui est gnr par loutil ASL TOOLKIT et lance le processus de vrication des proprits (c.f. gure 5.16).
158
Fig. 5.14: Processus de gnration darchitecture
159
Fig. 5.15: Gnration dun capteur dans un agent ractif chier.adl correspond au chier contenant la description architecturale gnre par loutil ASL TOOLKIT. Ce chier va dabord tre compil ensuite analys smantiquement. Suite cette analyse, larchitecture est rie sous forme darbre smantique reprsent par des prdicats Prolog. Cet arbre va tre par la suite parcouru pour vrier les proprits fournies dans chierProp.aal. Celles-ci vont tre aussi compiles an de vrier quelles respectent la syntaxe du langage AAL. Par la suite, les prdicats Prolog correspondant vont tre activs an de parcourir larbre de larchitecture. La gure 5.17 montre une capture dcran de lAnalyseur. Dans cet exemple, nous vrions que larchitecture du capteur dcrit un comportement cyclique, ce qui revient vrier que dans cette architecture labstraction est rcursive. Nous donnons un autre exemple o nous vrions cette fois-ci, si cette architecture contient un interblocage. Pour vrier linterblocage, plusieurs conditions doivent tre valides : toutes les connexions dclares et utilises dans larchitecture doivent tre unies, chaque action denvoi correspond une action de rception, les connexions unies transportent le mme type de donnes.
160
Fig. 5.16: Vrication des proprits
161
Fig. 5.17: Vrication de linterblocage Si nous prenons le capteur comme lment part, cette proprits ne va pas tre respecte comme lindique la gure 5.17. En eet, les connexions utilises dans le capteur, ne sont pas encore unies. Cette situation va tre rpare quand le capteur sera intgr dans lagent (o sa connexion interne sera unie avec le moteur de lagent) et que lagent sera intgr dans le groupe dagent correspondant (o la connexion externe de lagent sera unie avec llment qui va envoyer lvnement lagent).
12
Gnration du code
Cet outil permet de gnrer un chier XML interprtable partir duquel des rgles de gnration du code peuvent tre appliques. Pour ce faire, le gnrateur de code sappuie sur des rgles de transformation Langage ArchWare ADL - Langage cible pour gnrer le chier XML. Nous navons pu tester cet outil, tant donn quil tait implant par notre partenaire (University of St Andrews) et quil ntait pas en notre possession. Nous fournissons cepedant dans le tableau 12 les rgles de mapping qui ont t utilises pour gnrer du code Java partir dune spcication en -ADL [BFDP05].
13
Conclusion
Dans ce chapitre, nous avons prsent notre approche ArchMDE qui est base sur un processus de dveloppement en double Y. Lutilisation de lapproche ArchMDE se situe deux niveaux. Le premier niveau concerne la 162
ADL le_identier.adl value identier is abstraction(...) ;
JAVA le_identier.java public class le_identier extends ProcessCreator public static void main(String[] args) new le_identier() ; public void createProcess() throws Exception setProcessName("le_identier") ; setAutoInstanciated() ; ... WfVertexDef identier = setActivity( null, "identier", outcome+"identier.x true, null, prell+"identier.xml", false, 0, null ) ; WfVertexDef identier = setActivity( null, "identier", outcome+"identier.xsd", true, null, prell+"identier.xml", false, 0, null ) ;
value identier is free connection( ... ) ; via identier send ... ;
value identier is free connection( ... ) ; via identier send ... ; via identier receive ... ;
Tab. 5.2: Mapping entre architecture en -ADL et code Java
163
CHAPITRE 5. LAPPROCHE ARCHMDE construction du cadre de dveloppement qui va tre utilis par les dveloppeurs des applications multi-agents. Ce niveau est ralis par des experts en mtamodlisation. A ce niveau, durant la phase danalyse, les mta-entits permettant de dcrire le domaine doivent tre formalises et leurs proprits exprimes indpendemment des concepts orients agent. Durant la phase de conception, le mtamodle orient agent est formalis et les direntes proprits auxquelles obissent les concepts orients agent exprimes. Par la suite, les rgles de transformation sont exprimes an de tisser les concepts du domaine aux concepts orients agent. Le deuxime niveau dutilisation de ArchMDE concerne les dveloppeurs des applications qui ne sont pas experts en mtamodlisation. Ceux-ci vont utiliser le mtamodle du domaine pour spcier le domaine dapplication. Par la suite ils utilisent les rgles de transformation fournies par le cadre de dveloppement an dagentier leur domaine. A la n du processus dagentication, nous obtenons une architecture abstraite du systme que lutilisateur va pouvoir congurer pour gnrer son architecture concrte. Larchitecture du systme doit respecter aussi bien les proprits du domaine que les proprits des concepts orients agent. La phase dimplmentation traite le mapping entre les plates-formes dimplmentation et larchitecture du systme. Il sagit durant cette phase dnumrer les entits de la plate-forme et dtudier leurs proprits. Par la suite, des rgles de mapping doivent tre explicites an de gnrer automatiquement le code. An de construire la cadre de dveloppement bas sur lapproche ArchMDE, nous avons choisi dutiliser lenvironnement ArchWare. En utilisant le langage de style de ArchWare nous avons introduit un mtamodle de domaine bas sur quatre entits : dataEntity : qui reprsente les donnes taskEntity : qui reprsente des comportements atomiques devant tre raliss dans le systme activeEntity : qui reprsente les entits actives du systme structureEntity : qui reprsente les entit structurelles regroupant diffrentes donnes et direntes entits actives du systme Le langage de style ASL ore un mcanisme de mixx qui permet de dnir des DSL pouvant tre utiliss par des personnes non spcialistes des langages ArchWare. Lors du processus dagentication ces syntaxes vont tre mixes avec celles qui ont t spcies pour les concepts orients agent. Les rgles de transformation du processus dagentication sont exprimes en utilisant le langage ARL qui a t tendu an de permettre le tissage des styles. A partir de la syntaxe reprsentant le mix des deux syntaxes larchitec164
CHAPITRE 5. LAPPROCHE ARCHMDE ture concrte va tre gnre en utilisant loutil ASL TOOLKIT. Aprs la gnration de larchitecture, les proprits peuvent tre vries en utilisant loutil Analyser. Dans le prochain chapitre, nous validons lapplication de notre approche ArchMDE dans le cadre dune agentication dun systme de production.
165
166
Chapitre 6 Validation de lapproche ArchMDE Agentication dun systme de production
CHAPITRE 6. VALIDATION DE LAPPROCHE ARCHMDE AGENTIFICATION DUN SYSTME DE PRODUCTION
Prsentation du projet
Nous avons appliqu notre approche dans le cadre dun projet BQR regroupant dirents membres du laboratoire LISTIC travaillant sur des thmatiques direntes [HHP+ 07]. Ce projet concerne ltude dune nouvelle approche pour la modlisation, la simulation et le pilotage des systmes de production (nots SdP). Nous avons appliqu dans ce projet lapproche oriente agent an de procurer plus de exibilit aux plates-formes de simulation actuelles [Bak96], [Ber00], [Hab01]. En eet, pour faire face aux changements brusques de leurs environnements et de la demande des clients, les entreprises manufacturires doivent piloter avec beaucoup dagilit leur outil de production. Or, les SdPs tels quils sont simuls actuellement se concentrent au niveau du ux physique en prcisant le processus de fabrication et les spcicits des machines utilises pour la ralisation des oprations. Cela a pour consquence de rendre dicile la simulation car il est ncessaire pour lutilisateur de trouver aprs plusieurs essais les bons rglages pour obtenir un rsultat acceptable (nombre des machines, caractristiques des machines, taille des lots, capacit des stocks, etc.). Il apparat clairement que la simulation des SdPs manque dautomatisation et quil serait prfrable de laisser le systme voluer de lui-mme pour aboutir une solution par mergence. Dans ce contexte, lutilisation de lapproche oriente agent est bien approprie. En eet, lutilisation des systmes multi-agents permettra au simulateur de faire voluer la conguration du systme de production en prenant en compte les changements survenus dans son environnement. Au cours de ce projet, nous nous sommes bass sur des concepts utiliss 168
CHAPITRE 6. VALIDATION DE LAPPROCHE ARCHMDE AGENTIFICATION DUN SYSTME DE PRODUCTION par lquipe Simulation avec laquelle nous avons collabor. Il a t question dans ce projet de concevoir ces concepts selon lapproche oriente agent an dapporter plus de exibilit dans leur utilisation. Le but tant de crer un simulateur qui satisfasse des besoins de plusieurs ordres : crer un cadre logiciel modulaire et volutif : le simulateur est conu de manire pouvoir tre utilis dans de nombreux cas, tout en ne ncessitant que des modications mineures. crer un outil puissant pour le thoricien en lui facilitant la comprhension des phnomnes complexes. En eet, le programme permet par une simple modication, via une interface graphique, de tester de nombreuses hypothses et, ainsi, de comprendre les inuences des paramtres. permettre une analyse complte et dtaille : des chiers comprenant les informations sur ltat des agents, les changes raliss, etc. Ces informations sont gnres par le simulateur an de permettre une tude ultrieure. Pour dvelopper ce simulateur, nous avons appliqu notre dmarche base sur lapproche ArchMDE. Dans ce contexte, nous avons utilis le mtamodle du domaine que nous avons fourni dans le chapitre prcdent (cf. section 7). Par la suite, nous avons appliqu des rgles dagentication an de gnrer un style de systmes de production agentis. Nous voulons focaliser sur ce point au cours de ce chapitre. Ainsi, dans la section 2 de ce chapitre, nous dcrivons de manire plus dtaille les systmes de production. Par la suite, nous prsentons les concepts du domaine que nous formalisons en utilisant lenvironnement ArchWare (section 3). Nous expliquons ensuite lagentication des concepts SdP (section 4).
Les systmes de production
Un SdP peut tre dni comme tant une association dynamique de trois parties : la premire partie constitue par un ux de matires ou dentits transformer ou assembler et qui reprsentent gnralement matires premires, composants, produits en cours, pices de rechange et produits nis. Le ux form par ces lments peut se trouver sous direntes formes : des pices unitaires, des groupements temporaires, des produits assembls, des lots, des sries, etc. la deuxime partie physique qui reprsente lensemble des moyens ncessaires la ralisation des oprations sur le ux de matire. Elle 169
Fig. 6.1: Modle de Systme de Production
comprend les machines, les espaces de stockage, les moyens de transfert, les robots, les manipulateurs, etc. la partie contrle ou pilotage qui reprsente la partie intelligente du systme cest--dire les systmes de commande, les systmes de supervision, les acteurs humains (oprateurs, responsables, gestionnaires, etc.). La partie pilotage associe des points dacquisition et de collecte de linformation, des processus dcisionnels (analyse, traitement de linformation et valuation pour gnrer des dcisions) et des actions (points de transfert des ordres ou des actions de la partie pilotage la partie physique).
Ces trois parties sont illustres dans la gure 6.1. Dans cette gure la partie physique reoit des donnes partir de la partie ux. La partie pilotage agit aussi bien sur la partie physique que la partie ux qui lui transmettent les informations ncessaires. A partir de ce modle gnrique, plusieurs concepts ont t identis. Nous dcrivons ces concepts dans la section suivante. 170
Mtamodlisation dun SdP
Une analyse plus approfondie des trois parties constituant un SdP a permis de constater que les lments du systme peuvent tre diviss en trois types structurellement et fonctionnellement dirents. Il sagit de : lEntit Circulante (EC), le Systme de Transformation du Produit (STP), le Centre de Pilotage (CP). Pour chacune de ces entits, nous dcrivons leurs rles dans le systme ainsi que la manire dont elles ont t formalises en utilisant lenvironnement ArchWare.
3.1
LEntit Circulante (EC)
Le Rle de lEC LEC est un concept gnrique modlisant le ux du produit. Il possde une trajectoire dnie a priori, il est passif vis--vis de lui-mme mais il active les STPs et les CPs son passage et dclenche leurs comportements. Formalisation du mtamodle de lEC Nous considrons lEC comme une dataEntity. En eet, bien que ce concept reprsente le fait que ce soit une entit qui "circule" dans le SdP, elle na pour autant pas dactions excuter. Ce sont les lments du SdP chargs de sa transformation qui auront un rle actif sur celle-ci. LEC sert donc regrouper les informations concernant le ux de production. Les informations principales qui sont contenues dans lEC sont les suivantes : un identiant unique, le processus : qui est un ensemble doprations devant tre eectues sur lEC. Les oprations sont dcrites par lidentiant du poste qui va les excuter et le temps opratoire. En se basant sur ces informations, nous formalisons lentit EC de la manire suivante :
EC i s d a t a E n t i t y with { type i s { view [ ID : A l i a s ; p r o c e s s u s : set [ view [ numPoste : A l i a s ; t p s O p e r a t o i r e : Real ] ] } }
171
Fig. 6.2: Les trois fonctions fondamentales dun STP
3.2
Le Systme de Transformation du Produit (STP)
Le Rle du STP Le STP est un concept gnrique possdant toutes les caractristiques structurelles et fonctionnelles dune ressource de production. Le STP excute trois oprations (cf. gure 6.2) : rception : obtention dune ou plusieurs ECs transformer, transformation : occupation du STP et blocage de lEC pendant le temps de transformation, fourniture : libration du STP et fourniture de lEC transforme un autre STP conscutif. Le STP est une structure rcursive qui est principalement utilis pour dcrire une ressource de production ajoutant de la valeur au produit en cours de fabrication. Toutefois, le concept de STP peut aussi reprsenter dautres ressources de production telles que : les stocks et les moyens de transfert. En eet, ceux-ci sont interprts comme des STPs particuliers qui neectuent pas doprations de transformation, mais qui rceptionnent et fournissent les ECs aprs un temps dattente souvent ncessaire pour rguler le ux. Parfois, il est ncessaire de reprsenter un groupe de machines fonctionnellement identiques par des STPs dirents (dirence entre les performances, les dfaillances, les rglages, etc.). Dans, ce cas nous utilisons le concept de Centre de Charge (CC) qui est un groupement de plusieurs STPs dirents mais ralisant la mme fonction ou opration. Formalisation du mtamodle du STP LEC est manipule par les STPs que nous considrons comme des activeEntities. Celles-ci ralisent direntes oprations que nous considrons comme des taskEntities et qui sont la rception des EC, la mise jour de leurs donnes, la mise jour des indicateurs et la fourniture des ECs transformes. Nous avons choisi de direncier, dans notre mtamodle entre le STP-Machine qui va raliser des transformations sur lEC et le STP-Stock qui va recevoir puis fournir les ECs sans oprer de changements sur les don172
CHAPITRE 6. VALIDATION DE LAPPROCHE ARCHMDE AGENTIFICATION DUN SYSTME DE PRODUCTION nes quelles contiennent. En eet, en modlisant le comportement de ces deux entits, nous avons relev plusieurs disparits, ce qui nous a pouss distinguer les deux types en modlisant chacun par un style particulier. Ainsi, le STP-Stock est reprsent comme suit :
STPStock i s a c t i v e E n t i t y with { a t t r i b u t e s { ID : A l i a s ; c a p a c i t : Integer ; n i v e a u S t o c k : Integer ; ECStocks : set [EC. I n s t a n c e ] } process { recursive P r o c e s s { compose { new STPStockRecevoitEC and new stockerEC and new STPStockFournitEC } where { STPStockRecevoitEC : : t r a n s m e t t r e E C r e c u e u n i f i e s stockerEC : : s t o c k e r E C r e c u and stockerEC : : sendECstoquee u n i f i e s STPStockFournitEC : : pre par e r ECa Fournir } }} analysis { constraints { c o n t r a i n t e 1 to STPStock . I n s t a n c e s apply { not (STPStock . c a p a c i t < STPStock . n i v e a u S t o c k ) } and c o n t r a i n t e 2 to STPStock . I n s t a n c e s apply { ( s u c c e s s i o n D i r e c t e ( stockerEC , f o u r n i r E C ) or ( s u c c e s s i o n I n d i r e c t e ( stockerEC , f o u r n i r E C ) } c o n t r a i n t e 3 to STPStock . I n s t a n c e s apply { h a s C y c l e (STPStock ) } ... }
Les trois taskEntities STPStockRecevoitEC, stoquerEC et STPStockfournitEC qui sont composes par lentit active STP-Stock sont des instanciations de style de type taskEntity. Lentit active STP-Stock permet alors 173
CHAPITRE 6. VALIDATION DE LAPPROCHE ARCHMDE AGENTIFICATION DUN SYSTME DE PRODUCTION de spcier comment ces tches sont excutes son niveau et comment elles sont relies travers des connexions partages qui ont t unies au niveau de STP-Stock. Ces taskEntities agissent alors comme des modules internes de STP-Stock qui sont indpendants mais qui partagent les attributs dclars au niveau de activeEntity. Dans ce mtamodle formalis par un style, nous avons fournis quelques exemples de contraintes que la STP-Stock doit satisfaire. Ainsi, la contrainte 1 stipule que le niveauStock ne doit jamais dpasser la capacit. La contrainte 2 veut que le stockage dun EC peut tre directement suivi par sa fourniture (cas dun ux tendu) ou que son stokage peut tre suivi par la rception dautres instances dEC. Enn, la contrainte 3 veut que le comportement du STP-Stock soit rcursif. Dans ce qui suit, nous focalisons sur la mtamodlisation des taskEntities qui ont t utilises au niveau du style STP-Stock. Une description dtaille des trois oprations STPStockRecevoitEC, stoquerEC et STPStockfournitEC est fournie. Le comportement de chacune de ces oprations est spcie au niveau de leur constructeur.
STPStockRecevoitEC i s t a s k E n t i t y { input : { r e a d C a p a c i t : connection [ c a p a c i t ] ; r e a d N i v e a u S t o c k : connection [ n i v e a u S t o c k ] } operation : { recursive behaviour { value r e a d C a p a c i t i s connection ( c a p a c i t . I n s t a n c e ) ; value r e a d N i v e a u S t o c k i s connection ( n i v e a u S t o c k ) ; r c u p r e r l e s a t t r i b u t s c a p a c i t e t n i v e a u S t o c k via r e a d C a p a c i t receive c : c a p a c i t ; via r e a d N i v e a u S t o c k receive n : n i v e a u S t o c k ; i f c a p a c i t < n i v e a u S t o c k then l a c a p a c i t du s t o c k n e s t pas a t t e i n t e STPS t o c k r e o i t l EC via r e c e v o i r E C receive EC : EC. I n s t a n c e s ; via t r a n s m e t t r e E C r e c u e send EC; new STPStockRecevoitEC l a c a p a c i t du s t o c k n e s t pas a t t e i n t e STPS t o c k r e f u s e l EC else via r e f u s R e c e p t i o n send ;
174

new STPStockRecevoitEC } output : {} }
stoquerEC i s t a s k E n t i t y { input : { lockECS to ck s : connection [ ECStocks ] ; l o c k N i v e a u S t o c k : connection [ n i v e a u S t o c k ] } operation : { value lo ck ECS toc k s i s connection ( ECStocks ) ; value l o c k N i v e a u S t o c k i s connection ( n i v e a u S t o c k ) ; behavior { Le module STPStockRecevoitEC n o t i f i e l a r r i v e d une EC via s t o c k e r E C r e c u receive EC : EC. I n s t a n c e s ;
Accs l a t t r i b u t ECStocks ( f o r m a l i s e l a l i s t e ) d e s ECs c o n t e n u e s dans l e s t o c k v r o u i l l e r ECStocks via loc kE CSt oc ks receive ECS : ECStocks ; m o d i f i e r ECStocks en a j o u t a n t l EC r e u e ECS includes EC; d v r o u i l l e r ECStocks via unlockECStocks send ECS : ECStocks ; Accs l a t t r i b u t n i v e a u S t o c k v r o u i l l e r n i v e a u S t o c k via l o c k N i v e a u S t o c k receive n i v e a u S t o c k ; m o d i f i e r n i v e a u S t o c k en l i n c r m e n t a n t n i v e a u S t o c k := n i v e a u S t o c k +1; d v r o u i l l e r n i v e a u S t o c k via u n l o c k N i v e a u S t o c k receive n i v e a u S t o c k ; new stoquerEC } new stoquerEC } } output : { unlockECStocks : connection [ ECStocks ] u n l o c k N i v e a u S t o c k : connection [ NiveauStock ] }
175

}
STPStockfournitEC i s t a s k E n t i t y { input : { lo ckE CS toc ks : connection [ ECStocks ] ; r e c e v o i r P a r am N i v e au receive n : n i v e a u S t o c k } operation :{ f o u r n i r E C i s recursive behaviour { value loc kECSt ocks i s connection ( ECStocks ) ; value l o c k N i v e a u S t o c k i s connection ( n i v e a u S t o c k ) ; v r o u i l l e r l e s a t t r i b u t s ECStocks e t N i v e a u S t o c k via loc kE CSt oc ks receive ECS : ECStocks ; via l o c k N i v e a u S t o c k receive n : NiveauStock ; choose { envoyerEC i s behaviour { Envoyer l EC s t o q u e ( s i l e STP s u i v a n t e s t p r t r e c e v o i r ) via sendECaFournir send ECStocks : : 1 ; ECStocks e x c l u d e s ECStocks : : 1 ; n i v e a u S t o c k := n i v e a u S t o c k 1 ; via unlockECStocks send ECS ; via u n l o c k N i v e a u S t o c k send n ; } or d b l o q u e r a t t r i b u t s ( s i l e STP s u i v a n t e s t p r t r e c e v o i r ) via unlockECStocks send ECS ; via u n l o c k N i v e a u S t o c k send n ; } STPStockfournitEC ; or fournirEC } } output { unlockECStocks : connection [ ECStocks ] u n l o c k N i v e a u S t o c k : connection [ NiveauStock ] } }
Ces trois oprations bien quelles tournent en parallle au niveau du STPStock communiquent entre elles : quand le module rception peroit larrive de lEC, il vrie que le niveau du stock actuel nest pas atteint. Si cest le cas, il accepte lEC et la transmet au module de stockage ( travers la connexion transmettreECrecue ). Si la capacit est atteinte, il envoie un refus de rception. 176
Lopration stockerEC reoit lEC et linclue dans la liste des ECs reus. Suite cette opration, le niveau courant du stock est incrment. Le module fournirEC prpare lEC qui va tre envoye. Si le STP suivant est prt la recevoir, celui-ci la lui fournit et remet jour la liste des EC stockes sinon il relache les valeurs vrouilles et reboucle sur lui-mme. Nous remarquons que ces trois modules ont un accs concurrent aux dirents attributs fournis par lentit active. Pour garantir la cohrence de ces attributs, nous avons spci des sentinelles sur ces attributs. Ainsi quand lun des modules essaie daccder une ressource pour la modier, il lacquiert dabord en utilisant la connexion lockNomAttribut, une fois la ressource modie, le module la relache en utilisant la connexion unlockNomAttribut. Avant que lopration via unlockNomAttribut send ne soit eectue, lattribut devient inaccessible. Cependant, notons que les oprations de lecture peuvent tre eectues en parallle en employant la connexion readNomAttribut. STP-Machine est formalis selon le mme principe. Cependant plusieurs dirences existent avec le comportement STP-Stock. Le STP-Machine est responsable doprer des changements sur lEC. Ainsi, STP-Stock et STPMachine se direncient au niveau des taskEntity quils vont inclure : stockerEC et transformerEC. Bien que les oprations de rception et de fourniture dEC peuvent paratre identiques, celles-ci exhibent un comportement interne dirent. Tandis que STP-Stock va vrier si sa capacit est atteinte ou pas (ce qui lui permet ou pas de recevoir lEC), STP-Machine va vrier son tat. En eet, divers tats indiquent si la machine est disponible, en panne, en maintenance, prvue pour un changement de srie etc. Les changements dtats peuvent tre programms en avance au niveau du STPMachine. Par exemple, nimporte quel moment une panne peut survenir. Si une panne intervient alors quEC est en train dtre transforme, celle-ci sera dtruite et comptabilise comme un rebus. Enn, le STP-machine dire du STP-Stock par les indicateurs quil manipule. Ces indicateurs peuvent tre par exemple les taux de rebus, les taux de pannes etc. Suivant ces caractristiques, STP-Machine est reprsent comme suit :
STPMachine i s a c t i v e E n t i t y with { attributes { ID : A l i a s ; E t a t s : union [ panne , changementDeSrie , d i p o n i b l e , maintenance ] ; EtatCourant : quote [ E t a t s ] ; i n d i c a t e u r s : set [ I n d i c a t e u r ] }
177

process { recursive behaviour { compose { new stpMachineRecoitEC and new transformerEC and new d e t r u i r e E C and new c h a n g e r E t a t and new st pM ac hinefourni tEC } ... }
Les styles modliss au niveau des taskEntities de STP-Machine respectent le mme principe que ceux modliss au niveau du STP-Stock.
3.3
Le Centre de Pilotage
Le Rle du CP Le CP a t dni par [Ber00] comme suit : " une structure organise et autonome, dpendante de la stratgie de lentreprise, ayant un pouvoir dcisionnel, associe une entit piloter et disposant dun ensemble de moyens ncessaires la mise en place dactions pour atteindre un ou plusieurs objectifs dnis dans le cadre global de lentreprise ". Le CP peut intervenir dirents niveaux de dcision dans latelier de production : de celui qui dirige un STP jusquau CP ayant un pouvoir dcisionnel et stratgique vis--vis du dveloppement de lentreprise. Les activits de supervision et de pilotage de lagent-CP sont de trois natures : loptimisation : dabord, lagent-CP a une activit doptimisation o le pilotage dni a priori. Ds linstant initial, avant excution de la simulation, lagent-CP doit tre capable de construire dune part ses propres objectifs ainsi que le domaine datteignabilit de ces objectifs, et dautre part, les plans daction excuter en cas de drive du systme, la prvention : pendant la simulation, lagent-CP doit avoir une capacit de raisonnement lui permettant denclencher des activits de prvention proactives. En eet, il doit tre capable dagir sur le systme, si ncessaire, avant mme quune drive puisse avoir lieu sur un lment du systme, 178
Fig. 6.3: Modle du CP la correction : enn, en cas de drive dun lment du systme, lagentCP doit enclencher le plan dactions ncessaire pour rtablir ltat du systme. Les principales tapes du processus de pilotage du CP sont les suivantes : acquisition de linformation dun STP ou dun CP, traitement et valuation de linformation, prise de dcision, choix dun plan daction adapt et transfert de ce dernier aux ressources concernes.
Le schma de la gure 6.3 prsente de manire simplie les 4 tapes du processus de pilotage du CP. Ces tapes concernent : la mesure, lvaluation, la dcision et lapplication du plan. Le processus de dcision se fait au niveau des tapes 2 et 3 (valuation et dcision). Il prend en compte : les informations intrinsques (endognes) qui sont propres au CP telles que les rfrents, les objectifs locaux et les rgles de conduite du CP, les informations extrinsques (exognes) qui sont les informations externes au CP et qui sont lies lenvironnement, la structure et aux autres CPs, les mesures lies au systme piloter et qui sont traduites sous forme dindicateurs de performance. 179
CHAPITRE 6. VALIDATION DE LAPPROCHE ARCHMDE AGENTIFICATION DUN SYSTME DE PRODUCTION La mtamodlisation du CP Pour mtamodliser le CP, nous nous sommes bass sur la gure 6.4. Cette gure dcrit de manire dtaille les oprations eectuer au niveau du CP. Ainsi, le processus de pilotage du CP comporte les 7 tapes suivantes : prise de mesure : lors de cette tape, il sagit dacqurir la mesure qui peut tre soit vnementielle soit priodique. La mesure est fournie par un STP, une EC ou un CP de niveau infrieur. Cette mesure concerne lindicateur principal et les indicateurs secondaires associs aux inducteurs quun CP doit suivre. valuation de la performance du systme pilot : lvaluation de la performance du systme pilot se fait en deux tapes : dabord, le calcul de la performance (comparaison de la mesure avec lobjectif), et ensuite lvaluation de cette performance (analyse de cette comparaison pour dduire un tat de drive ou de non drive du systme). Dans le cas dune drive, le processus de pilotage est poursuivi pour identier linducteur interne responsable. Dans le cas de non drive, le comportement du systme tant celui qui est attendu, le processus de pilotage est stopp. identication de linducteur interne : lidentication de linducteur est essentielle pour construire un systme de pilotage. Il sagit de dterminer les ressources critiques dans le systme pilot et les principaux facteurs qui agissent sur la performance de ces ressources (leurs inducteurs). valuation de linducteur interne : cette tape consiste mettre en vidence, parmi la liste des inducteurs, ceux qui sont responsables de la drive de lindicateur principal suivi du CP. Les inducteurs sont valus grce aux indicateurs de performance secondaires. identication du plan daction : une fois que linducteur interne est identi et valu, le CP cherchera identier la liste des actions correspondant cet inducteur et pouvant amliorer la situation. simulation du plan daction : lobjectif de cette tape est de tester les actions laide dun historique des actions mises en place dans le pass et de leur inuence sur le systme. application du plan daction : si laction value a permis dans le pass de rtablir la situation de non drive, elle sera applique sur le systme pilot. Sur la base de ces informations, nous formalisons le CP de la manire suivante :
CP i s a c t i v e E n t i t y with { attributes {
180
Fig. 6.4: Le comportement du CP
181

ID : A l i a s ; e n t i t s P i l o t s : set [ tuple [ EC, STPStock , STPMachine ] ] i n d i c a t e u r s D e P e r f o r m a n c e : set [ I n d i c a t e u r ] ; i n d u c t e u r s I n t e r n e s : set [ I n d u c t e u r ] ; p l a n A c t i o n s : set [ ProcessusCP ] ; h i s t o r i q u e : set [ view [ a c t i o n P a s s e s : set [ Action ] , r s u l t a t O b t e n u : Any ] ] o b j e c t i f s : set [ Any ] } process { recursive behaviour { compose { new Mesure and new EvaluationDePerformance and new MesureDerive and new I n t e r r o g a t i o n I n d u c t e u r s E x t e r n e s and new i d e n t i f i c a t i o n P l a n A c t i o n and new s i m u l a t i o n P l a n A c t i o n and new a p p l i c a t i o n P l a n A c t i o n }} } }
Ces oprations sont mises en parallle. Cest avec le mcanisme dunication que les squences daction vont stablir (mme principe quavec les taskEntities de STP-Stock et STP-Machine)
Agentication du systme de production
Dans cette section nous prsentons la manire dagentier les concepts prsents dans la section prcdente. Nous considrons que le concept EC peut tre considr comme une ressource de lenvironnement. Les concepts STP-Stock et STP-Machine vont tre considrs comme des agents hybrides tant donn que ceux-ci contiennent des attributs internes qui vont tre considrs comme des tats mentaux. Le CP doit avoir des capacits cognitives dvaluation, de planication qui lui permettent de piloter le systme en fonction des connaissances et des objectifs qui lui sont assigns. Il a t donc modlis par un agent cognitif. Dans cette section, nous allons dcrire lagentication de chacun de ces concepts. 182
4.1
La ressource EC
La ressource EC a t reprsente au niveau du mtamodle du domaine par une dataEntity nayant aucune action. Au niveau de la modlisation multi-agents du concept dEC, notre choix sest port sur une reprsentation de lEC par une ressource passive dans lenvironnement. A ce niveau, nous appliquons la rgle de transformation dataEntityEnvironmentRessource qui vrie dans les prconditions que la dataEntity est visible par divers ressources dans le domaine. Cette rgle est formalise en ARL de la manire suivante :
on AgentifiedMM a c t i on da t a E n t i t y A g e n t i f i c a t i on i s r e f i n e m e n t (SdPMM: metamo d e l , AgentMM : metamo d e l ) { p r e s t y l e i s {SdPMM : : EC AgentMM : : Pa s s i v eRe s s ou r c e } v r i f i e r que EC e s t v i s i b l e p ar p l u s qu une a c t i v e E n t i t y da ns l e s y s t m e p r e { t o EC a pply { f o r a l l { a : SdPMM: : a c t i v e E n t i t y | i t e r a t e a by i : Na tu r a l do { i f i s V i s i b l e (EC , a : : i ) do a : : i includes a c t i v e E n t i t y S e t } and a c t i v e E n t i t y S e t . s i z e > 1} }} po s t s t y l e i s {ECPa s s i v eRe s s ou r c e wi t h {EC wi t h { . . . } }} t r a n s f o rma t i on i s {ECPa s s i v eRe s s ou r c e includes AgentifiedMM } }a ssuming {AgentMM : : Pa s s i v eRe s s ou r c e : : c o n s t r a i n t s }
Au niveau de post-style, nous introduisons la nouvelle syntaxe correspondant lentit EC modlise en tant que ressource dans lenvironnement. La transformation correspondant cette action consiste dans lintgration du ECPassiveRessource dans le mtamodle agenti AgentiedMM. Le style correspondant cette entit combinera le style dune ressource passive de lenvironnement et de la ressouce passive PassiveRessource. Au niveau de assuming, nous pouvons intgrer les contraintes qui doivent tre respectes lors de lapplication du nouveau style. Ces proprits peuvent correspondre celles dj dclares au niveau de la dataEntity EC. Par exemple, nous incluons ce niveau la proprit stipulant quun niveau de stock ne doit jamais dpasser sa capacit. 183
4.2
Les agents hybrides STP-Stock et STP-Machine
Nous avons modlis prcdemment les fonctionnements internes des STP-Stocks et STP-Machines. Ces entits ont des attributs quelles grent en interne. Ces attributs seront considrs comme des tats mentaux des agents. De plus, nous savons que ces entits sont communiquantes puisque cest travers la communication quelles russissent changer les ECs (cf. gure fournie par lquipe Simulation 6.5). Nous considrons ces entits comme des agents hybrides. Pour raliser cette transformation plusieurs tapes sont ncessaires. Nous dcrivons le processus tape par tape dans ce qui suit.
Etape 1 : attributs tats mentaux La premire rgle est AttributToMentalState. Cette rgle permet de transformer les attributs en tats mentaux internes de lagent hybride. Pour que cette rgle puisse tre excute, la prcondition suivante doit tre vrie. Elle stipule que les attributs internes ne soient pas visibles de lextrieur. Ce qui est le cas de ces entits actives. Nous exprimons ci-dessous la rgle correspondant la transformation des attributs du STP-Stock :
on AgentifiedMM a c t i on Att r i b u t ToMenta l S t a t e is r efinement (SdPMM: metamo d e l , AgentMM : metamo d e l ) {
p r e s t y l e { t o a : SdPMM : : STPSto ck : : a t t r i b u t e s . i n s t a nce a pply { f o r a l l {a c t i v e E n t i t yRe f : SdPMM: : a c t i v e E n t i t y | no t ( i s V i s i b l e ( a , a c t i v e E n t i t yRe f ) and a c t i v e E n t i t yRe f <> STPSto ck ) } } po s t s t y l e i s {Menta l S t a t e STPSto ck wi t h {SdPMM : : STPSto ck : : a t t r i b u t e s }} t r a n s f o rma t i on i s {Menta l S t a t e STPSto ck includes AgentifiedMM } }a ssuming {AgentMM : : c o n s t r a i n t s }
Cette premire tape doit tre suivie par un autre ranement au niveau du nouveau style. An de garantir la cohrence de ces tats mentaux, nous avons mentionn au pralable que des sentinelles sont ncessaires. Il serait judicieux ce niveau dinclure ces tats mentaux dans un module interne qui va implmenter ces sentinelles. Nous utilisons pour cela un concept introduit par Ingenias [PGS03] et qui consiste en un gestionnaire dtat mentaux. Nous dcrivons ceci dans ltape 2. 184
CHAPITRE 6. VALIDATION DE LAPPROCHE ARCHMDE AGENTIFICATION DUN SYSTME DE PRODUCTION Etape 2 : Intgration du gestionnaire dtats mentaux Lintgration du gestionnaire dtats mentaux est formalise par la rgle de transformation suivante :
on AgentifiedMM a c t i on I ncludeMent a l S t ateMana ge r i s r e f i n e m e n t { p r e s t y l e i s { AgentMM : : Menta l S t a t e wi t h {} }
po s t s t y l e i s { St ockMenta l S t ateMana ge r wi t h { Menta l S t a t e s i s {AgentMM : : Menta l S t a t e } LockP r o c e s s i s { c ompo s e s e n t i n e l l e E C S t o c k s i s r ecu r s i v e beh a v i ou r { va l u e l ockECSto c k s i s c o n n e c t i on ( Menta l S t a t e s : : ECSto c k s ) ; ch oo s e { v i a l ockECSto c k s send Menta l S t a t e s : : ECSto c k s ; v i a u n l ockECSto c k s r e c e i v e Menta l S t a t e s : : ECSto c k s ; sentinelleECSt o cks } or v i a r e adECSto c k s send Menta l S t a t e s : : ECSto c k s ; sentinelleECSt o cks } and beh a v i ou r { . . . } } t r a n s f o rma t i on i s { St ockMenta l S t ateMana ge r includes AgentifiedMM ; Menta l S t a t e STPSto ck excludes AgentifiedMM } }a ssuming { p ro p1 t o us l e s t a t menta ux o n t l e u r s e n t i n e l l e p ro p 2 c o h r ence de f o n c t i onnement d e s s e n t i n e l l e s no t ( v i a l ockECSto c k s send Menta l S t a t e s : : ECSto c k s ; v i a r e adECSto c k s send Menta l S t a t e s : : ECSto c k s ; ) and ... }
Ainsi, les dirents tats mentaux gnrs par ltape prcdente sont inclus au niveau du gestionnaire des tats mentaux (MentalStates ). Dans lockProcess, toutes les sentinelles ncessaires sont spcies sous forme de comportement qui sil reoit un vnement sur la connexion lock bloque la ressource et ne permet de la librer que lorsque unlock est eectu. Sinon, 185
CHAPITRE 6. VALIDATION DE LAPPROCHE ARCHMDE AGENTIFICATION DUN SYSTME DE PRODUCTION la lecture peut tre lue de manire concurrentielle. Au niveau de assuming, nous avons spci une proprit qui vrie quil est impossible de lire une valeur si celle-ci est vrouille en criture. Dans cet exemple, nous nous somme contents de dcrire la sentinelle correspondant ltat les ECStocks. Le procd est le mme pour les autres tats mentaux. Notons par ailleurs que pour garder la cohrence du mtamodle agenti, nous avons supprim le style des tats mentaux MentalStateSdPStock. Celuici est dsormais inclu dans le style StockMentalStateManager et il serait dsormais impossible dinclure cet tat mental dans un agent sans dclarer son gestionnaire qui spcie les sentinelles. Etape 3 : taskEntity actions internes de lagent A ce niveau, nous sommes en mesure de faire la correspondance entre les taskEntities dnies au niveau de lactiveEntity STP-Stock. Pour quune taskEntity soit considre comme une action interne, il faut quelle manipule des attributs dans ltat mental et quelle nait pas de connexion externe. Bien que les actions de rception et denvoi dEC ncessite la communication avec lextrieur, on na pas spci de connexions libres au niveau de ces deux taskEntities. Ceci a t fait parce que nous tions conscients quau niveau des agents, les interfaces de communication (rle) externe doivent tre spares des modules internes. Mais si lutilisateur a spci des connexions libres au niveau des tches de rception et denvoi dEC, une action supplmentaire devient ncessaire qui permet de transformer les connexions libres en connexions internes avant dexcuter cette tape. Dans notre cas, tant donn que les trois actions que nous avons spcies valident les prconditions nous appliquons directement laction activeEntityProcessToInternAction suivante :
on AgentifiedMM a c t i on a c t i v e E n t i t y P r o c e s s ToI n t e r nActi on is r efinement (SdPMM: metamo d e l , AgentMM : metamo d e l ) { p r e { t o SdPMM : : STPSt o ck a pply { f ora l l { t : t a skEntity . I nst a nces | l e p ro c e s s u s ne c o n t i e n t pa s d a c t i o ns a y a n t d e s c o n n e x i o ns l i b r e s no t ( e x i t s { c : c o n n e c t i on [ Any ] | f r eeCo n n e c t i on ( c ) } ) and l e s a c t i o ns ma n i p u l e n t l e s a t t r i b u t s
186

e x i t s { c1 : c o n n e c t i on [ Any ] | e x i s t s { a: a tt r ibut | c1 . va l u e = a}} }} } po s t s t y l e i s { I n t e rnPr o c e s s STPSto ck wi t h {STPSt o ck : : Pr o c e s s }} t r a n s f o rma t i on i s { I n t e rnPr o c e s s STPSto ck includes AgentifiedMM } }a ssuming {AgentMM : : I n t e rnPr o c e s s : : c o n s t r a i n t s }
Pour vrier que les actions manipulent des tats mentaux, il sut de vrier quau niveau de ce processus il existe au moins une connexion qui tranfert un attribut. Rappelons que pour manipuler un attribut la tache doit accder lattribut travers une connexion (lock). Le rsultat de cette action de transformation est la cration du style InternProcessSTPStock, qui contient le processus interne dcrit au niveau de lentit active STP-Stock. Etape 4 : activeEntity Agent hybride A ce niveau du processus, nous pouvons agentier lentit active STPStock. Les attributs de lagent ont t rednis et inclus dans StockMentalStateManager et son processus en InternProcessSTPStock. Ces deux composants vont tre intgrs au niveau de lagent hybride hybridAgentSTP-Stock. Ceci est possible puisque le style agent hybride ninterdit pas davoir de tels composants. Si ce niveau, le dveloppeur se trompe et intgre ces composants dans un agent ractif, les proprits seront violes puisque lagent ractif na pas dtats mentaux. Laction correspondant lagentication du STP-Stock est la suivante :
on AgentifiedMM a c t i on a c t i v e E n t i t yToHyb r idAgent is r efinement (SdPMM: metamo d e l , AgentMM : metamo d e l ) { p r e s t y l e i s {AgentMM: : H yb r idAgent } pr e { } po s t s t y l e i s {Hyb r idAgentSTPSt o ck wi t h { Menta l S t a t e s i s { St ockMenta l S t ateMana ge r } I n t e rnPr o c e s s i s { I n t e rnPr o c e s s STPSto ck } b i n d i n g s { u n i f i c a t i on d e s c o n n e x i o ns }}
187

t r a n s f o rma t i on i s {Hyb r idAgentSTPSt o ck includes AgentifiedMM } }a ssuming { au n i v e au de b i n d i n g s t o u t e s l e s c o n n e c t i o ns i n t e r nes s o n t u n i f i e s }
Ainsi, dans cette action, une nouvelle syntaxe est introduite qui dcrit exclusivement un agent hybride pour un STP-Stock. Etape 5 :intgration des rles Au niveau de cette tape, le style dni dans ltape 5 va tre redni pour intgrer laspect communicatif de ces agents. Ceci va tre ralis par le concept de rle. En eet, les entit STP-Stock et STP-Machine sont des entits communiquantes qui participent des protocoles dinteraction. Lquipe avec laquelle nous avons travaill, nous a transmis un exemple de protocole dni dans la gure 6.5
Fig. 6.5: Communication entre STP Pour intgrer la communication externe, nous avons dcid dintgrer un module communicationAction dans notre style dagents hybrides. Cette transformation pourrait scrire comme suit :
on AgentifiedMM : : H yb r idAgentSTPSt o ck a c t i on r e f i n e S t y l e is r efinement { p r e s t y l e i s {AgentMM: : H yb r idAgent }
188

t r a n s f o rma t i on i s {Hyb r idAgentSTPSt o ck bec omes Hyb r idAgentSTPSt o ck wi t h { Menta l S t a t e s i s { St ockMenta l S t ateMana ge r } I n t e rnPr o c e s s i s { I n t e rnPr o c e s s STPSto ck } r o l e s {} b i n d i n g s { u n i f i c a t i on d e s c o n n e x i o ns } } }
Le processus dagentication continue avec plusieurs autres tapes qui vont raner les rles jous par lagent pour communiquer. Nous avons ici, montr une partie dun processus qui va tre appliqu pour agentier le STPStock. Le mme principe va tre appliqu aux autres entits du systme. Lagent cognitif CP Lagentication du CP nest pas encore acheve. Mais nous commenons analyser la manire dont on va procder. Le Centre de Pilotage (CP) joue la fois le rle de pilote et de superviseur. Il doit tre capable de prendre des dcisions pour permettre au systme de production datteindre ses objectifs. Pour cette raison, nous nous sommes naturellement tourns vers un agent cognitif pour modliser le CP, plus prcisment un agent BDI ayant : La facult de mmoriser lhistorique dvolution du systme et des actions quil a ralises sur ce dernier, La facult dapprendre de son pass pour viter les erreurs quil a pu commettre mais aussi de minimiser son temps de rponse, La facult de choisir la bonne action entreprendre en se rattachant des critres (cots, impact sur lensemble du systme, etc.), Lautonomie dans le comportement. An de mieux expliciter lagentication de lAgent-CP, nous proposons dans le tableau 4.2 une correspondance entre les concepts BDI et les composantes du CP. Dans ce tableau, nous avons dni la base de connaissances de lagentCP travers : les dsirs, les croyances et les intentions. Nous avons ainsi pu dterminer ce quon peut mettre derrire chaque module partir de lanalyse du centre de pilotage.
4.3
Agentication des autres lments du SdP
Dautres concepts appartiennent aux systmes de production. Nous avons abord par exemple le concept de centre de charge (CC). Celui-ci a t agenti par un groupe dagents constitu dagents hybrides Stock et agents hy189
Architecture BDI Perceptions (P)
Croyances (B)
Dsirs (D)
Intentions (I)
Agentication de lAgent-CP Architecture interne CP Explication Mesures + informations des Ce sont les informations perautres CPs ues au niveau des lments du systme (STPs, ECs, etc.) rattachs ou des CPs de niveau infrieur. Valeurs des indicateurs et in- Cest la base de connaisducteurs + ressources + rgles sances de lagent contenant les de gestion informations ncessaires sur son environnement et sur luimme. Objectifs et sous-objectifs du Ce sont les objectifs que CP + Seuil dalerte lagent voudrait voir se raliser. Ils seront en liaison avec les croyances pour dterminer sil y a drive ou non sur lune des perceptions un instant donn. Les plans daction mis en Les intentions sont relies place par le CP en cas de d- une bibliothque de plans o rive dun inducteur. on trouve des plans daction prdnis et stocks partir des situations passes.
Tab. 6.1: Agentication de lAgent-CP
190
CHAPITRE 6. VALIDATION DE LAPPROCHE ARCHMDE AGENTIFICATION DUN SYSTME DE PRODUCTION brides Machine. Les concepts de "lot", "commande", "processus", "opration" (un processus est compos doprations), "calendrier douverture" et "atelier" ne jouent aucun rle actif : ces lments nont pas daction mener. Au mme titre que lEC, ces direntes entits sont reprsentes par des ressources passives de lenvironnement.
Conclusion
Dans ce chapitre, nous avons expos un travail que nous avons men en parallle avec nos recherches. A travers ce travail, nous validons notre approche sur un cas rel fourni par nos collgues de lquipe Simulation. Au cours de ce chapitre nous avons focalis sur les aspects mtamodlisation du domaine et droulement dun processus dagentication en employant lenvironnement ArchWare. Nous avons employ dans ce contexte le mtamodle du domaine fourni dans le chapitre 5. Nous avons aussi utilis des rgles de transformation que nous avons formalises en ArchWare ARL. Ce travail nous a prouv quil tait tout fait envisageable de construire un processus dagentication en dnissant des rgles de transformation qui vont gnrer le style agenti pas pas.
191
192
Chapitre 7 Conclusions et Perspectives
CHAPITRE 7. CONCLUSIONS ET PERSPECTIVES
Rappel de la problmatique
Au cours de cette thse, nous nous sommes intresss lingnierie des systmes multi-agents. Le point de dpart de nos travaux a t de parcourir ltat de lart relatif aux techniques dingnierie des systmes multi-agents. Nous avons class ces travaux en trois grandes familles : langages spciques au paradigme agent qui facilitent la spcication des systmes multi-agents, mthodologies orientes agent qui guident les dveloppeurs durant les phases de dveloppement, plates-formes multi-agents qui facilitent limplmentation et le dploiement des systmes multi-agents. Ltude de ces travaux nous a rvl de grandes disparits relatives lapplication des thories orientes agent. Ainsi, nous avons constat que : dirents concepts ont t dnis et utiliss au niveau des mthodologies, langages de modlisation et plates-formes dimplmentation. La smantique de ces concepts est souvent aborde de manire informelle, ce qui a suscit direntes interprtations au niveau des direntes techniques dingnierie, direntes vues ont t spcies pour dnir les systmes multi-agents : ces vues regroupent plusieurs concepts et sont fortement interrelies (exemple vue Agent, vue Organisation, etc.). Nous avons relev que la mise en valeur dune vue plutt quune autre peut dpendre entire194
CHAPITRE 7. CONCLUSIONS ET PERSPECTIVES ment du domaine dapplication, le cycle de dveloppement est souvent incomplet : un large foss spare les phases danalyse/conception des phases dimplmentation. En eet, rares sont les mthodologies qui prennent en compte la phase dimplmentation et la gnration de code vers une plate-forme spcique. De plus, les plates-formes ne couvrent pas tous les concepts pris en compte au niveau des modles produits par la mthodologie. Cest donc au dveloppeur que revient la charge de crer les entits correspondantes.
Dans ce contexte, notre problmatique sest concentre sur deux aspects :
proposition dun cadre de dveloppement exible : qui devrait permettre aux dveloppeurs de choisir au cours de la conception les concepts et vues orientes agent qui saccordent le mieux leurs domaines dapplication. Ce cadre de dveloppement devrait permettre par ailleurs de xer (trs tt dans le processus de dveloppement) la smantique des concepts multi-agents qui vont tre utiliss dans le cadre de lapplication. intgration de phases de vrication et validation des modles : les concepts orients agent ainsi que les modles qui les appliquent sont gnralement abords de manire informelle ce qui ne favorise pas la vrication et la validation des modles durant le cycle de dveloppement. Cependant, dans le contexte du dveloppement orient agent, il est ncessaire davoir une conception sre an de produire des logiciels de qualit. En eet, les systmes orients agent sont composs dentits jouissant dune grande autonomie, qui sexcutent en parallle tout en partageant plusieurs ressources dans leur environnement. Dans ce contexte, il est ncessaire de sassurer que les modles garantissent certaines proprits dans lapplication future telles que la vivacit, labsence dinterblocage, laccs scuris aux ressources, etc.
Pour garantir la exibilit du cadre de dveloppement, nous avons adhr lapproche adopte par Ingenias qui consiste diviser le problme en plusieurs aspects qui seront modliss par des mtamodles, les modles et notations ncessaires seront alors gnrs partir de ces mtamodles. Le cadre de dveloppement est ainsi construit en fonction des besoins du dveloppeur. A cette approche, nous ajoutons lutilisation de modles bass sur des notations formelles qui permettent lexpression et la validation des proprits. Pour proposer un tel cadre de dveloppement nous avons combin lapproche dirige par les modles et lapproche centre architecture. 195
Contributions
Notre principale contribution consiste en la proposition dune dmarche de dveloppement qui aidera les dveloppeurs construire leur cadre de dveloppement. Cette dmarche est base sur la combinaison de lapproche IDM et de lapproche centre architecture. Dans cette section, nous rcapitulons dabord les apports de chacune de ces approches, ensuite ceux de notre approche ArchMDE.
2.1
Apports de lapproche IDM
Lingnierie dirige par les modles nous a permis didentier les niveaux dabstraction ainsi que les modles qui sont dnis dans chaque niveau. En se basant sur larchitecture quatre niveaux propose par lOMG [OMG03], nous adoptons les niveaux dabstraction constitus du mta-mtamodle, mtamodle, modle et systme. Lapplication de cette architecture procure une grande exibilit dans la construction des cadres de dveloppement. En eet, la couche mtamodle permet de dnir de manire explicite les concepts qui sont utiliss pour reprsenter les direntes vues dun systme multi-agents. Au cours de cette thse, nous nous sommes principalement bass sur le mtamodle du domaine, le mtamodle des concepts orients agent et le mtamodle de la plate-forme dimplmentation. Au niveau de la couche modle, nous avons identi les deux modles PIM et PSM qui sont gnrs par composition des concepts associs aux dirents mtamodles. IDM conoit lintgralit du cycle de vie comme un processus de production, de ranement itratif et dintgration de modles ; ce qui rejoint notre objectif. Rappelons quun des points auxquels nous nous sommes interesss au niveau de notre problmatique est labsence dun processus de dveloppment cohrent qui couvre les dirents aspects du systme ainsi que les direntes phases du cycle de vie. Nous avons vu que dans la plupart des travaux que nous avons tudis, plusieurs aspects au niveau des systmes multi-agents devraient tre traits de manire ad hoc par les dveloppeurs. Lapproche IDM permet dviter cette situation en exploitant les modles de manire productive. Ceci veut dire quils sont assembls, modis ou transforms en excutant des rgles de transformation explicitement exprimes. Les modles produits chaque niveau dabstraction deviennent alors des artefacts pouvant tre pleinement exploits au niveau du cycle de dveloppement, perdant ainsi leur caractristique contemplative dans laquelle ils taient cantonns dans les approches de dveloppement classiques (o les modles permettaient uniquement de documenter les applications en cours de dveloppement). 196
2.2
Apports de lapproche centre architecture
Le dveloppement orient architecture se penche sur les techniques de description des modles architecturaux ainsi que leur intgration. Nous avons choisi de considrer les modles appartenant chaque couche dabstraction comme des constructions architecturales. Ce choix est motiv par le fait que les constructions architecturales permettent de dnir des vues du systme de manire lisible et qui expose les proprits les plus cruciales. De plus, cette approche datant dune dizaine dannes commence orir aux dveloppeurs des environnements de dveloppement exploitables. Parmi ces environnements, certains se basent sur des langages formels que nous pouvons utiliser an de rendre possible lexpression et la validation de diverses proprits structurelles et comportementales. En se basant sur cette approche, nous avons choisi de reprsenter les dirents mtamodles par des styles architecturaux. Les styles orent des mcanismes puissants permettant de dnir : un vocabulaire pour spcier les concepts utiliss (exemple : Agent, Groupe, Client, Serveur, etc.) des rgles de conguration, ou contraintes, qui dterminent comment les concepts peuvent tre apppliqus. une interprtation smantique par laquelle les compositions des lments architecturaux ont une signication bien dnie. des analyses qui sont associes au style et qui identient des caractristiques de direntes sortes (par exemple vrier une mesure telle que le nombre dlments ou vrier la satisfaction dune proprit, etc.). Ces analyses forment des proprits que les architectures gnres partir du style devraient satisfaire. Ainsi, le PIM appartenant la couche modle va tre considr comme une architecture globale du systme obtenue par intgration darchitectures reprsentant dirents aspects (ou vues) du systme. Cette intgration darchitecture est ralise grce lapplication de rgles de transformation. Cellesci sont exprimes par des langages de ranement que certains environnements centrs architecture orent. Dans les environnements centrs architecture bass sur des langages formels, les rgles de transformation sont exprimes en terme de pr-conditions et post-conditions, ce qui permet de garantir la cohrence de larchitecture.
2.3
Apports de la dmarche ArchMDE
Notre dmarche que nous avons baptis ArchMDE (Architecture Model Driven Engineering) applique la combinaison des approches IDM et approche 197
CHAPITRE 7. CONCLUSIONS ET PERSPECTIVES centre architecture. Elle permet de construire un cadre de dveloppement exible et sr bas sur les besoins du domaine tudi. En eet, au niveau de notre approche, nous avons adopt un cycle de dveloppement modlis par un double Y. Ce cycle de dveloppment se base sur le mtamodle du domaine, le mtamodle des concepts orients agent et le mtamodle de la plate-forme dimplmentation. Deux principaux processus de transformation sont dnis : le processus dagentication et le processus dimplmentation que nous avons appel mapping. Nous avons identi deux principales manires complmentaires dutiliser lapproche Arch-MDE, chacune ralise par des acteurs dirents. Ainsi nous distinguons : 1. les spcialistes en mtamodlisation : ceux-ci sont responsables de la construction du cadre de dveloppement qui va tre utilis par les dveloppeurs des applications multi-agents. Les spcialistes de mtamodlisation fournissent les mta-entits (dcrites sous forme de style architectural) permettant de dcrire le domaine. Chaque mta-entit dnit les proprits qui lui correpondent et qui doivent tre respectes tout au long du cycle de dveloppement. Selon notre approche, les concepts du domaine sont formaliss indpendemment des concepts orients agent. Paralllement, les spcialistes de mtamodlisation fournissent aussi les mtamodles contenant le mtamodle orient agent. Par la suite, les rgles de transformation entre le mtamodle du domaine et le mtamodle orient agent sont exprimes. Elles expriment les pr-conditions quune entit du domaine doit valider an quelle soit considre comme une entit agent, ressource, rle, etc. 2. les dveloppeurs dapplications orientes agents : ceux-ci utilisent le cadre de dveloppement fourni par les spcialistes de mtamodlisation. Leur rle consiste spcier le domaine dapplication en instanciant les mta-entits dnies dans le mtamodle du domaine. Par la suite, ils utilisent les rgles de transformation fournies par le cadre de dveloppement an dagentier leur domaine. A la n du processus dagentication, nous obtenons une architecture abstraite du systme que lutilisateur va pouvoir congurer pour gnrer son architecture concrte. Enn, larchitecture du systme doit respecter aussi bien les proprits du domaine que les proprits des concepts orients agent. Dans le cadre de cette thse, nous avons utilis lenvironnement ArchWare, qui est un environnement formel bas sur le langage -calcul pour construire lenvironnement de dveloppement. Grce aux langages ArchWare, nous avons fourni les mtamodles ncessaires lapplication de ArchMDE. 198
CHAPITRE 7. CONCLUSIONS ET PERSPECTIVES Nous avons identi dans chaque mtamodle les proprits correspondantes qui sont utilises au niveau des rgles de transformation lors du processus dagentication. Les outils dArchWare nous ont aid lapplication de ce processus. Ces outils sont principalement composs de : lASL TOOLKIT qui permet de compiler le style du domaine agenti. Cet outil comprend aussi un module de conguration permettant la gnration de larchitecture de lapplication, lAnalyser : la suite de la gnration de larchitecture, les proprits dclares au niveau du style peuvent tre vries. Dautres outils existent dans cet environnement qui peuvent tre exploits tel que lanimateur, le rener (tendu pour prendre en compte la transformation de styles) et le synthtiseur (pour la gnration de code). Ces travaux ont t appliqus avec succs au niveau du projet BQR dont lobjet tait dagentier une plate-forme de simulation des systme de production an de lui procurer plus de exibilit et de faciliter lapplication des rgles de pilotage.
2.4
Bilan
Lapproche ArchMDE traite les deux points que nous avons identi au niveau de la problmatique. La mtamodlisation permet dobtenir un cadre de dveloppement exible et personnalisable et lutilisation des langages formels permet de mettre en valeur les proprits de chaque vue du systme. Cependant, notre approche prsente plusieurs dicults et ce pour les deux types dutilisateur. Ainsi, pour les experts de mtamodlisation, les dicults se situent au niveau de : lidentication des mta-entits ncessaires ainsi que leurs relations pour la reprsentation dun domaine dapplication quelconque, lidentication des rgles de transformation gnriques ainsi que les proprits sur lesquelles elles se basent (pr et post conditions). Pour les dveloppeurs dapplications orientes agents, les dicults se situent dans lapplication des rgles de transformation. Tout dabord notre dmarche modie considrablement la manire de dvelopper des systmes. Dans ce contexte, les dveloppeurs devraient acqurir de nouvelles habitudes de dveloppement bases sur la construction de processus de transformation (dans notre cas ce sont les processus dagentication et de mapping). Par ailleurs, les dveloppeurs doivent identier le bon ordre dexcution de ces rgles. La transformation se fait pas pas, et chaque pas les modles doivent tre valids. 199
Cependant, malgr ces dicults nous pensons que notre approche prsente des avantages majeurs. Si les dveloppeurs se familiarisent avec lutilisation des rgles de transformation, cette dmarche permettra daugmenter la productivit et la qualit des systmes produits. Lapplication des rgles de transformation pour agentier le systmes devient alors un moyen de prototypage rapide alors que les rgles de transformations vers le code vitera la fastidieuse tche de codage. La validation des proprits chaque application des rgles de transformation assurera la qualit de lapplication nale. De plus, durant notre exprience, il nous a paru plus facile didentier les proprits relatives au systme un niveau lev dabstraction. Par ailleurs, les mtamodles ainsi que la spcication des rgles de transformation permettront de conserver le savoir-faire. En terme de rutilisabilit, lexprience est prescrite sous forme de mtamodles et de rgles de transformation.
Perspectives
Plusieurs perspectives ont t identies nous permettant denvisager la suite de nos travaux. Nous numrons ces perspectives dans cette section : 1. Adaptation de loutil rener : comme nous lavons mentionn dans la section 9.2 du chapitre 5, loutil Rener a t conu dans le cadre dArchWare pour supporter le ranement des architectures exprimes selon un style bien particulier qui est les composants/connecteurs. Nous avons voulu au niveau de notre approche viter la transformation du domaine vers ce style an de lagentier. En eet, nous pensons que cela risque dalourdir lapproche. Ainsi, nous avons dcid dtendre ARL an de prendre en compte la transformation du style. De ce fait il faudrait aussi faire voluer loutil Rener an de prendre en compte lextension du langage. Ceci nous permettra davoir un outil assistant les dveloppeurs dans lapplication des rgles de transformation. 2. Dnition dun langage graphique : celui-ci doit tre bas sur la smantique dArchWare. En eet, lutilisation de notre approche dans le cadre du projet BQR, nous a rvl les dicults que peuvent avoir les non informaticiens dans la pratique des langages textuels. Nous nous sommes alors xs lobjectif de dnir une syntaxe graphique base sur la smantique des langages ArchWare. Un prol UML appliqu avec beaucoup de rigueur peut tre utilis ce niveau. Ces travaux sont en cours actuellement. Nous prconisons par exemple, lutilisation des diagrammes pour dnir des scnarios qui seront considrs comme des structureEntity contenant des acteurs activeEntities eectuant des tches taskEntities. Chaque tche peut tre exprime par un 200
CHAPITRE 7. CONCLUSIONS ET PERSPECTIVES diagramme dtat/transition dont les transitions entrantes modlisent des actions receive et les transactions sortantes, des actions send. Les noeuds peuvent modliser les actions internes (par exemple aectation dune nouvelle valeur un attribut). 3. Mtamodlisation des plates-formes dimplmentation : la partie implmentation a t aborde de manire supercielle au cours de cette thse. A moyen terme nous prconisons de mtamodliser les concepts appliqus au niveau des plates-formes dimplmentation. Cette tche risque dtre dlicate. Il faudrait trouver le moyen dexprimer clairement ces mtamodles ainsi que les rgles de transformation permettant le passage du style du domaine agenti vers le code. Nous explorerons ce niveau deux approches. La premire consiste exprimer le style du domaine agenti par un langage exploitable au niveau dun langage QVT. La deuxime est de faciliter la production de gnrateur de code partir de lenvironnement ArchWare. 4. Phases de test et maintenance : nous pouvons envisager dtendre le processus de ArchMDE pour intgrer les phases de test et de maintenance. Pour la phase de test, nous pouvons envisager que les proprits exprimes au niveau des styles soient transformes en scnarios de test. Pour la phase de maintenance, nous pouvons utiliser un cadre dexcution fourni par lenvironnement de dveloppement centr architecture tel que celui propos par ArchWare (chapitre 4). Ce cadre dexcution est compos dune machine virtuelle qui pourrait excuter larchitecture modlise. Celle-ci peut tre connecte la plate-forme dexcution relle et agir comme un systme de monitoring. Au niveau de ce cadre dexcution, un langage (lArchWare Hyper-code ADL) est conu pour supporter lvolution dune architecture en cours dexcution en sappuyant sur la notion de "rexion structurelle". Cette notion est dnie comme la capacit dune spcication en cours dexcution gnrer de nouveaux fragments de spcication et les intgrer au sein de sa propre excution. 5. Systme daide la dcision : long terme, nous pouvons envisager de proposer un systme daide la dcision, qui partir de lanalyse des proprits exprimes au niveau du mtamodle du domaine et du mtamodle agent puisse suggrer des rgles de transformation que les dveloppeurs puissent utiliser lors du processus dagentication. Ceci implique que des proprits telles que lintelligence ou lautonomie des agents puissent tre explicitement exprimes. En eet, ce jour ces proprits sont encore considres de manire vague. Cette perspective pourrait encore plus faciliter lapplication des systmes multi-agents 201
CHAPITRE 7. CONCLUSIONS ET PERSPECTIVES et la rendre plus accessible des non-informaticiens. Ceux-ci nauront qu dcrire leur domaine. A partir des proprits de ce domaine, le systme pourra identier les rgles de transformation appliquer au niveau du processus dagentication. Le mme processus pourrait tre envisag pour eectuer le processus de mapping.
202
Chapitre A Description des langages ArchWare
ANNEXE A. DESCRIPTION DES LANGAGES ARCHWARE
An de simplier la comprhension de ce manuscrit de thse, nous fournissons dans cette annexe une description dtaille des langage ArchWare. Rappelons que lenvironnement ArchWare fournit un ensemble de langages qui sont : ArchWare Architecture Description Language ( -ADL) : cest un langage pour la description darchitectures ayant des caractristiques dynamiques et volutives. En eet, le langage permet de capturer les mcanismes permettant larchitecture de changer de topologie et de conguration durant lexcution, ArchWare Architecture Analysis Language (AAL) : cest un langage pour la spcication de divers proprits architecturales, ArchWare Architecture Renement Language (ARL) : cest un langage pour la description de ranements darchitectures. ArchWare Architecture Style Language (ASL) : cest un langage pour la description de styles architecturaux.
Le langage ArchWare ADL
En -ADL, une architecture est un ensemble dlments, appels lments architecturaux, qui sont relis par des liens de communication. Ces lments sont dnis en terme de comportement (behaviour, abstraction ). Ce dernier est dni par un ensemble dactions ordonnances qui spcient le traitement interne de llment (actions internes) et les interactions avec son environnement (actions de communication). Un lment architectural communique avec les autres par une interface caractrise par un ensemble de connexions (connections ) qui permet de faire transiter des donnes. Un 204
ANNEXE A. DESCRIPTION DES LANGAGES ARCHWARE mcanisme de composition et un mcanisme de liaison, appel unication (cest une substitution au sens du -calcul) permettent la mise en relation des lments architecturaux. Ces lments peuvent interagir lorsquils sont composs et lis. Un lment architectural peut tre dni comme une composition dautres lments (composite). En dautres termes, un comportement peut tre dni comme un ensemble dautres comportements interconnects. -ADL permet la description darchitectures dynamiques. En eet, les lments architecturaux peuvent, dune part, tre composs ou dcomposs la vole et, dautre part, des lments architecturaux peuvent tre crs et lis dynamiquement. Enn, des lments architecturaux peuvent transiter comme des donnes travers les connexions. Ce qui fournit un mcanisme adquat pour dcrire des architectures dynamiques dont la topologie peut changer au cours du temps. Dans les paragraphes suivants, nous donnons plus de dtails sur la description des comportements et des structures dune architecture. Nous exposerons les types de donnes pouvant tre dnis ainsi que leurs mcanismes de manipulation.
1.1
Comportement
Tout comportement est construit autour dactions et doprateurs spciques. Ces actions et ces oprateurs sont similaires ceux du -calcul. Dailleurs, un comportement est lquivalent dun processus en -calcul. Il existe dirents types dactions possibles qui sont dcrites ci-dessous. Le texte qui est en caractre gras correspond aux mots cl du langage -ADL : laction denvoi : qui permet un lment architectural denvoyer une donne (ou dautres lments architecturaux en cas darchitecture dynamique). Cette action est dcrite de la manire suivante :
via nomConnexion send donnes ;
laction de rception : celle-ci dcrit la rception dun message par un lment architectural. Elle est dcrite de la manire suivante :
via nomConnexion receive donnes : DfinitionDuType ;
laction inobservable : reprsente une action interne qui ne participe pas une communication ; elle est inobservable depuis lenvironnement du comportement.
205
unobservable
linaction : celle-ci correspond laction nil du -calcul. Elle peut tre utilis pour marquer la terminaison dun processus en excution. Linaction est dcrite par le mot cl done.
done
Un comportement dans sa globalit, inclut un ensemble ordonn dactions. Plusieurs oprateurs sont utiliss pour ordonnancer les actions, ce sont les oprateurs de succession, de condition, de choix, de composition et de rplication. Nous prsentons dans ce qui suit chacun des oprateurs. Loprateur de succession Loprateur de succession : il est not par un point virgule. Laction prcdent la virgule doit sexcuter avant laction qui suit la virgule. Lexpression suivante est la spcication dun comportement nomm b qui correspond lenvoi du message "Hello". A la suite de cet envoi, le processus sarrte (action done ).
value b i s behaviour { via a send " H e l l o " ; done }
Laction done peut tre omise lorsquelle est prxe. Lexpression prcdente devient quivalente :
value b i s behaviour { via a send " H e l l o "}
Loprateur de condition Loprateur de condition est not par if( condition ) then comportement1 else comportement2 dnit un comportement qui se comporte comme comportement1 si la condition est vrie et comme comportement2 sinon. Lexpression -ADL suivante est la dnition dun comportement qui dnit la rception de deux chanes de caractres. Si celles-ci sont quivalentes, il renvoie la premire, sinon il renvoie un message derreur.
206
behaviour { value x , y , z i s connection ( String ) ; via x receive c1 : String ; via x receive c2 : String ; i f c1 == c2 then via z send y ; e l s e via z send " E r r o r " ; }
Loprateur de choix Loprateur de choix correspond lexpression choice { comportement1 or ... or comportementn } : Il traduit un choix indterministe qui doit tre fait entre des comportements possibles, le choix correspond un OU exclusif, si lune des actions est choisie, lautre est abandonne. Ceci peut tre trs utile dans la description des architectures distribues, qui peuvent tre confrontes des troubles lis au rseau. Le comportement dun lment architectural peut tre bloqu sil na pas de correspondant immdiat. Dans ce cas, une autre action peut tre eectue. Lexpression -ADL suivante est un comportement qui peut se comporter de deux manires direntes : soit recevoir un message via une connexion x, soit envoyer un "timeout" via la connexion z.
behaviour { value x i s f r e e connection ( String ) ; value z i s f r e e connection ( String ) ; choose { { via x receive y : String ; unobservable } or { via z send " t i m e o u t " ; unobservable } }}
Loprateur de composition Loprateur de composition est dni par lexpression suivante compose { comportement1 and ... and comportementn } : elle traduit la mise en composition parallle de plusieurs comportements cest-dire que ceux-ci vont sexcuter en parallle et vont tre concurrents. La synchronisation de ces comportements permet deux lments mis en parallle de communiquer. Celle-ci se fait par lunication des connexions libres (qui sont prxes par le mot cl free ). Aprs unication les connexions deviennent partages. 207
ANNEXE A. DESCRIPTION DES LANGAGES ARCHWARE Lexpression lie lunication des connections se fait est la suivante :
nomComportement : : nomConnection unifies nomComportement : : nomConnection
Lexemple suivant prsente la composition de deux comportements, p et q. Ces deux comportements possdent des connexions libres (free) qui sont unies de telle sorte que p puisse envoyer un message sous forme de String q.
compose { p i s behaviour { value y i s f r e e connection ( String ) ; value message i s " H e l l o " ; via y send message } and q i s behaviour { value z i s f r e e connection ( String ) ; via z receive message : String ; unobservable } where {p : : y u n i f i e s q : : z } }
Loprateur de rplication
loprateur de rplication replicate{ comportement } est quivalent une composition innie du mme comportement. Nous pouvons lassimiler un oprateur de clonage dun mme comportement plusieurs fois. Lexpression suivante est un comportement qui peut tre dclench une innit de fois par la rception dune requte par la connexion requestConnection.
behaviour { replicate { value r e q u e s t C o n n e c t i o n i s connection ( String ) ; via r e q u e s t C o n n e c t i o n receive y : String ; unobservable ; } }
La notion dabstraction
208
ANNEXE A. DESCRIPTION DES LANGAGES ARCHWARE An de rutiliser des dnitions de comportement, ArchWare ADL fournit un mcanisme de rutilisation appel abstraction. Labstraction permet dencapsuler des dnitions paramtrables de comportement. Nous pouvons comparer une abstraction une procdure. On obtient un comportement dune abstraction par lapplication de cette dernire, en fournissant ventuellement une liste de paramtres. Lexemple suivant dnit labstraction dune architecture dcrivant un groupe de deux agents. Ces agents communiquent entre eux : lun envoie une requte et lautre y rpond. Le comportement de chaque agent est dcrit dans une abstraction. Ces abstractions sont ensuite appliques au niveau du groupe qui est lui mme dcrit par labstraction Groupe2Agents. Au niveau de cette abstraction les connexions sont unies an que les deux agents puissent communiquer. LAgent1 eectue un appel lAgent2, puis il attend une rponse. LAgent2 est en attente de lappel de lAgent1. Lorsquil reoit cet appel celui-ci lui rpond. Groupe2Agents est alors considr comme un lment composite.
value Agent1 i s abstraction ( ) { value c a l l , w a i t i s connection ( ) ; via c a l l send ; via w a i t receive ; unobservable }; value Agent2 i s abstraction ( ) { value r e q u e s t , r e p l y i s connection ( ) ; via r e q u e s t receive ; unobservable ; via r e p l y send }; value 2 AgentGroup i s abstraction ( ) { compose { A1 i s Agent1 ( ) and A2 i s Agent2 ( ) } where { A1 : : c a l l u n i f i e s A1 : : r e q u e s t and A2 : : r e p l y u n i f i e s A2 : : w a i t } }
La notion de rcursivit
209
ANNEXE A. DESCRIPTION DES LANGAGES ARCHWARE En plus de permettre la rutilisation, les abstractions permettent de dnir des comportements rcursifs, cest--dire des comportements qui retournent leur tat initial aprs un certain nombre dtapes. Nous reprenons lexemple prcdent de deux agents communiquant dans un groupe. Aprs avoir reu une rponse, lAgent1 peut renvoyer une requte alors que lAgent2 peut se remettre en attente dune requte. Pour dcrire un tel comportement rcursif,le mot cl recursive est ncessaire. Ceci va tre dcrit comme suit :
recursive value Agent1 i s abstraction ( ) { via c a l l send ; via w a i t receive ; unobservable ; Agent1 ( ) }; recursive value Agent2 i s abstraction ( ) { via r e q u e s t receive ; unobservable ; via r e p l y send ; Agent2 ( ) };
Nous avons vu que les comportements communiquent par des envois de donnes, nous tudions les aspects concernant ces donnes dans ce qui suit.
1.2
Les valeurs et les types
ArchWare ADL est un langage fortement typ. Il fournit un systme de types de donnes complet et des oprateurs pour manipuler les donnes. Nous prsentons ici ces types et ces oprateurs. ArchWare ADL fournit des types qui sont classs en types de base, types darchitectures, types construits et types collections : Les types de base sont Natural, Integer, Real, Boolean, et String. Les types darchitectures sont les suivants : connection[Type de donne], Behaviour, abstraction[Types des paramtres]. Ils reprsentent les valeurs architecturales prsentes dans les sections prcdentes. Les types construits reprsentent des valeurs composites. Ces types sont les suivants : tuple[Liste de types], view[Liste de types tiquets], union[Liste de types], variant[Liste de types tiquets], Les types collections reprsentent des valeurs composes de plusieurs autres valeurs de mme type. Ces types sont bag[Type], set[Type] et sequence[Type]. Prenons comme exemple, le type vue, qui reprsente une structure de valeurs de types dirents. Au niveau dune vue, ces valeurs sont tiquetes. Dans lexemple suivant, une valeur v de type view est dnie. Elle est com210
ANNEXE A. DESCRIPTION DES LANGAGES ARCHWARE pose dune valeur true tiquete b, et dune valeur "Chane de caractre" tiquete s.
value v i s view ( b i s t r u e , s i s " Chane de c a r a c t r e " )
Cette valeur a comme type, MaVue sui est dni de la manire suivante :
type MaVue i s view [ b : Boolean , s : String ]
Comme nous lavons mentionn prcdemment, des mcanismes sont fournis pour pouvoir manipuler les valeurs construites. Projection Des mcanismes de projection permettent daccder aux composantes dune valeur compose (vue, tuple, variant ou union). La ligne suivante exprime que les composantes de v sont associes aux identiants b et s qui sont utiliss par la suite (si b vaut true alors on envoie s par la connexion c).
project v as b , s ; i f b do via c send s
Le mcanisme de projection peut tre dcrit en utilisant du sucre syntaxique not " : :".
i f v : : b do via c send v : : s
iterate Ce mcanisme permet de manipuler les valeurs ayant un type collection, en permettant de parcourir une collection. Lexemple suivant permet de compter le nombre dlments contenus dans un ensemble de type set. Ceci est ralis par un mcanisme ditration : pour tout lment i de lensemble, la valeur somme (initialise 0) est incrmente de la valeur de llment i ; le rsultat nal est stock dans la valeur resultat.
value ensemble i s set ( 1 , 2 , 3 ) ; i t e r a t e ensemble by i : Integer ; from value somme i s location ( 0 ) accumulate {somme:=somme + i } as r e s u l t a t ;
211
ANNEXE A. DESCRIPTION DES LANGAGES ARCHWARE Pour accder aux lments des collections, le mcanisme de projection est utilis. Dans lexemple suivant, le deuxime lment est rcupr et stock dans la valeur resultat1 .
value s e q i s sequence ( 2 , 4 , 1 ) ; project s e q a t 2 as r e s u l t a t 1 ;
Includes et Excludes Dautres mcanismes permettent dajouter ou de retirer des lments dun ensemble. Dans lexemple suivant, la valeur 2 est ajoute ensemble. Ensuite une valeur 3 est retire.
value ensemble i s set ( 1 , 2 , 3 ) ; ensemble includes 2 ; ensemble excludes 3 ;
Le langage ArchWare AAL
En AAL, les proprits sont dnies comme des formules prdicatives. Ce langage fournit des prdicats prdnis et des mcanismes (oprateurs et quanticateurs) pour construire de nouveaux prdicats. Un support de vrication des proprits est fourni travers les outils Analyser [AO05] et Model Checker [BCD+ 04].
2.1
Les oprateurs et les quantieurs
ArchWare AAL fournit des oprateurs boolens ainsi que des quanticateurs. Ceux-ci permettent de construire de nouveaux prdicats partir de prdicats dnis. Le vocabulaire utilis pour les oprateurs boolens est le suivant : not, or, and, xor, implies, equivalent. Les quanticateurs sont le quanticateur existentiel, exists, et le quanticateur universel forall. Un prdicat peut tre appliqu une collection via loprateur to ... apply.
to c o l l e c t i o n apply p r d i c a t
Ce dernier est gnralement utilis avec les quanticateurs exist et forall pour appliquer un prdicat tous les lments dune collection. Lexpression 212
ANNEXE A. DESCRIPTION DES LANGAGES ARCHWARE suivante est vraie si le prdicat p est vrai pour chacun des lments de la collection.
to c o l l e c t i o n apply f o r a l l { e l e m e n t | p ( e l e m e n t ) }
2.2
Prdicats et fonctions sur les donnes
AAL fournit un ventail de prdicats et de fonctions prdnis concernant les donnes en gnral. Nous prsentons ci-dessous un sous-ensemble des prdicats prdnis. isValue(name, type ) est vrai si la valeur name est de type type. isType(alias, type ) est vrai si lidentiant alias rfre le type type. isAbstraction(name ) est vrai si la valeur name est une abstraction. isInstance(name, abstractionName ) est vrai si le comportement name est une instance de labstraction abstractionName. isConnection(name, type ) est vrai si isValue(name, connection[type] ) est vrai. Concernant les fonctions prdnies, nous prsentons galement un sousensemble. parameters(name ) - cette fonction sapplique une abstraction et retourne lensemble de ses paramtres. name(data) - cette fonction retourne le nom dune donne, elle existe pour tout type de donne ainsi que pour les paramtres. value(name) - cette fonction retourne la valeur dune donne.
2.3
Prdicats sur les comportements
ArchWare AAL permet de dcrire des patrons comportementaux. Ce sont des prdicats qui sont vrais si lordonnancement des actions dun comportement vrie certaines rgles quon exprime. Ces rgles expriment lagencement possible entre des actions de communication. Elles sont dcrites laide doprateurs spciques : la concatnation, ., le choix, |, la fermeture transitive rexive, : elle correspond la concatnation de zro ou plusieurs actions. la fermeture transitive, + : elle correspond la concatnation dune ou plusieurs actions. 213
ANNEXE A. DESCRIPTION DES LANGAGES ARCHWARE Lexpression suivante dnote un patron pour lequel une rception via la connexion c2 ne peut tre prcde directement dune ou plusieurs missions via la connexion c1.
( not ( via c1 send any ) ) . ( via c2 receive any )
De plus, AAL fournit deux autres oprateurs en se basant sur les oprateurs modaux de ncessit et de possibilit du -calcul. Le premier permet de spcier que toute squence dactions vriant un patron comportemental donn doit aboutir un tat donn. Le second permet de spcier quil doit exister au moins une squence dactions vriant un patron comportemental donn et aboutissant un tat donn. La proprit suivante exprime quil ne peut y avoir denvoi par la connexion c2 que sil y a eu rception par la connexion c1 juste avant. Dit autrement, chaque squence dans laquelle un envoi par la connexion c2 nest pas prcd par une rception par la connexion c1 conduit vers un tat faux.
every sequence { not via c1 receive any . via c2 send any } leads to state { f a l s e }
La proprit suivante exprime quil doit exister au moins une squence dans laquelle une action de rception par la connexion c1 prcde un envoi par la connexion c2.
some sequence { via c1 receive any } leads to state { via c2 send any }
Enn, AAL fournit deux derniers oprateurs se basant sur les quanticateurs de points xes maximaux et minimaux du -calcul : nite tree Y (x :T) given by s (Y) ( v ) innite tree Y (x :T) given by s (Y) ( v ) Le premier oprateur est bas sur les points xes minimaux. Cet oprateur spcie quen partant dun tat satisfaisant Y, on arrive aprs un nombre ni de pas (un "pas" = un dpliage rcursif de la formule s) un tat satisfaisant s (false). Lintuition est que les points xes minimaux se comportent comme des fonctions rcursives en langage de programmation, sauf quils sont interprts sur des systmes de transitions. En dautres termes, un patron dactions peut tre rpt un nombre ni de fois avant que le systme atteigne un tat donn.
214
ANNEXE A. DESCRIPTION DES LANGAGES ARCHWARE Par exemple, la formule suivante exprime lexistence dune succession nie dactions via x receive any.
f i n i t e tree Y given by {some sequence { via x receive any } leads to state { t r u e } or Y}
Aprs un nombre ni de pas (transitions franchies en dpliant le corps "{ some sequence { via x receive any } leads to state { true } or Y" de la formule), on doit arriver un tat qui satisfait {some sequence { via x receive any } leads to state { true } or { some sequence { via x receive any } leads to state { true }. Le second oprateur est bas sur les points xes maximaux. Par exemple, la formule suivante signie lexistence dune squence innie de rception par la connexion x.
i n f i n i t e tree Y given by {some sequence { via x receive any } leads to {Y}}
Le langage ArchWare ARL
Le noyau du langage est un ensemble doprations appeles actions de ranement qui supportent le ranement dune architecture abstraite vers une architecture concrte en vue de son implmentation [Meg04]. Dans ARL, les actions de ranement sont exprimes par des pr-conditions, des transformations et des post-conditions. Les pr-conditions sont des conditions qui doivent tre satisfaites dans une architecture avant lapplication dune action de ranement. Les post-conditions doivent tre satisfaites suite lapplication dune action de ranement. La transformation dcrit lopration raliser. Une tape de ranement seectue par lapplication dune action de ranement que lon peut exprimer en utilisant la syntaxe suivante :
on a r c h i t e c t u r eDef I d a c t i on r e f i n e m e n t A c t i on I d i s r e f i n e m e n t ( a c t i onPa r a mete r s ) { p r e i s { a c t i onPr e c o n d i t i o ns } po s t i s { a c t i onPo s t c o n d i t i o ns } t r a n s f o rma t i on i s { r e f i n e m e n t A c t i o ns } } a ssuming { p r o pe r t i e s } a s { m i x f i x }
o :
215
ANNEXE A. DESCRIPTION DES LANGAGES ARCHWARE actionPreconditions sont les conditions ncessaires satisfaire avant dappliquer laction de ranement, actionPostconditions sont les conditions satisfaire aprs lapplication de laction de ranement, renementActions sont les actions de ranement appliquer pour excuter une transformation depuis larchitectureDefId vers une nouvelle architecture rane, properties sont les conditions que lon suppose vraies et qui doivent tre vries (des obligations de preuve) an dappliquer les actions de ranement, mixx dnit la notation dune action dans une forme mixx. Notons que actionPreconditions, actionPostconditions et properties sont des expressions logiques. Direntes actions de ranement peuvent tre envisage au niveau des architectures. Nous les rsumons ci-dessous. Les oprations de ranement similaires sur tous les lments architecturaux Elles consistent principalement lajout, suppression et la modication des lments architecturaux ou au remplacement dun lment architctural par un autre. Elles sont exprimes par les expressions suivantes : Includes : ajoute un lment ou un sous-ensemble dlment un ensemble, Exludes : supprime un lment ou un sous-ensemble dlments dun ensemble, Replaces : remplace un lment par un lment, Becomes : remplace un comportement par un autre comportement. Voici un exemple de rgle de ranement permettant de supprimer plusieurs comportements dans une architecture.
Ar chtype No u v e l l e A r c h i t e c t u r e r e f i n e s AncienneA r c h i t e c t u r e using { beh a v i ou r excludes { beh1 , . . . , behN} }
Les oprations de ranement spciques aux connections Celles-ci permettent de raner les relations entre les dirents lments architecturaux. Elles sont exprimes comme suit : Unies : unie des connections Separates : spare des connections 216
ANNEXE A. DESCRIPTION DES LANGAGES ARCHWARE Lexemple suivant permet de sparer deux connections.
Ar chtype No u v e l l e A r c h i t e c t u r e r e f i n e s AncienneA r c h i t e c t u r e using ( Ancienne_Co n n e c t i o ns : t u p l e [ c o n n e c t i on ] ) { sep ara t e s Element1 : : p o r t 1 : : c o n n e c t i on1 wi t h Element2 : : p o r t 2 : : c o n n e c t i on2 }
Le langage ArchWare ASL
Le langage ASL a t construit comme une couche supplmentaire sur les langages ADL et AAL. Nous prsentons dans ce qui suit les mcanismes quil ore pour la formalisation de nouveaux styles.
4.1
description gnrale dun style
En ASL, un style est formalis selon trois entits : les constructeurs (qui fournissent un support la description architecturale), les contraintes, les analyses. La structure gnrale de la description dun style est la suivante :
Nom_du_style i s s t y l e extending S t y l e _ p a r e n t where { types { D f i n i t i o n s de types } s t y l e s { D f i n i t i o n s de s t y l e s } constructors { D f i n i t i o n s de c o n s t r u c t e u r s } constraints { D f i n i t i o n s de c o n t r a i n t e s } analyses { D f i n i t i o n s d analyses } }
Nom du style Un style est nomm. Son nom est lunique rfrence vers ce style. Il est ncessaire de faire rfrence un style plusieurs occasions : lors de son instanciation, lors de la vrication de la satisfaction dune architecture par rapport ce style, lors de lhritage par un autre style. Style parent Comme nous lavons mentionn prcdemment, ASL fournit un mcanisme de spcialisation : lhritage. Celui-ci permet de construite un nouveau style S sur la dnition dun autre style S. Le style S est alors appel style parent du style S et le style S un sous-style de S. Les lments dnis au 217
ANNEXE A. DESCRIPTION DES LANGAGES ARCHWARE niveau du style S (les constructeurs, les contraintes et les analyses) sont des acquis pour le style S. On spcie quun style en spcialise un autre par le mot cl extending. Dans lexemple ci-dessous, le style Style hrite du style StyleParent.
S t y l e i s s t y l e extending S t y l e P a r e n t where { . . . }
4.2
Types
La dnition dun style peut englober la dnition dun ensemble de types. Les types sont construits par rapport aux types prdnis dans ADL. Trois sortes de types gnriques sont cependant rajout : Type : c est un type dont les valeurs associes sont des types, Expression[T] : permet de capturer des dnitions de valeurs de type T. Par exemple, un paramtre de type Expression[ Behaviour ] est la dnition dun comportement et non pas une instance de comportement qui sexcute, Alias : cest un type dni pour pouvoir passer un alias en paramtre (et non linstance quil rfrence), Ces types sont utilisables pour paramtrer les constructeurs. Nous clarions cette notion ci-dessus.
4.3
Styles
Styles permet de structurer un style en terme dautres styles dits agrgats. Les styles agrgats encapsulent des constructeurs, de contraintes et des analyses qui alimentent le style contenant. La structure dun style en termes dagrgats peut tre construite paralllement celle des architectures quil reprsente. Reprenons lexemple des deux agents interagissant au sein dun groupe. Cette architecture peut tre reprsente par un style qui sera structur avec un style Agent1 et un style Agent2. Un style agrgat Groupe2Agents donne un support pour des sous-parties des architectures.
Groupe2Agents i s s t y l e { styles { Agent1 i s s t y l e where { . . . } Agent2 i s s t y l e where { . . . } } ... }
218
4.4
Les constructeurs
Les constructeurs fournissent le support la description architecturale. Ils permettent en eet de fournir des patrons architecturaux, respectant un style particulier. La valeur dnie par un constructeur peut reprsenter aussi bien une architecture, quun lment architectural, quun comportement, quune donne ou une connexion. Ainsi, dirents niveau de granularit peuvent tre traits, allant dune simple donne une architecture complexe. Un constructeur est un mcanisme de rutilisation. Lensemble des constructeurs dun style constitue une bibliothque de patrons architecturaux rutilisables. Un constructeur est dni avec un nom (nomDuConstructeur), un ensemble de paramtres typs (p1, p2, ..., pn), un corps (corpsDuConstructeur) et une notation mixx (notationMixx). La structure syntaxique correspondant une style est la suivante :
nomDuConstructeur i s c o n s t r u c t o r ( p1 : TypeP1 , . . . , pn : TypePn ) ; { corps_du _c o nstr u ct eu r } as { n o t a t i o n M i x f i x }
Le corps dun constructeur contient la description dune valeur construite relativement aux paramtres fournis au niveau du constructeur. Pour dcrire ces valeurs, le langage ArchWare ADL ( -ADL) est utilis. La notation mixx permet de crer une syntaxe adquate aux concepts dnis par le style. Cette syntaxe sera utilise lors de llaboration des architectures au niveau de la couche M1. Cette notation permet dabstraire les concepts basiques de ASL et de ADL et facilite ainsi lutilisation de lenvironnement par des non spcialistes dArchWare. Pour illustrer lutilisation du constructeur, nous reprenons notre exemple. Nous crons ici un constructeur pour lAgent1, dun constructeur de valeurs de type abstraction. Ces abstractions reprsentent des agents qui envoient des requtes aux autres agents.
Agent1 i s c o n s t r u c t o r (nom : String , r e q u e t e : String ) { abstraction ( ) { value r e q u e t e i s tuple (nom , r e q u e t e ) via c a l l send r e q u e t e ; via w a i t receive r e p o n s e : String ; unobservable } } as { a g e n t named $nom s e n d s $ r e q u e t e }
219
4.5
Les contraintes
Les contraintes de style caractrisent une famille darchitecture qui prsentent des qualits spciques en termes de structure ou de comportement. On sassure quune architecture prsente lensemble des qualits entranes par un style lorsquelle satisfait ses contraintes. Pour cette raison, il est important de formaliser les contraintes pour pouvoir par la suite vrier automatiquement quune architecture satisfait un style. Plusieurs types de contraintes peuvent tre direncies : les contraintes structurelles : par exemple, une architecture ne contient pas de cycles ; les contraintes comportementales : par exemple, la vivacit, labscence dinterblocage, les contraintes dattributs : par exemple, la valeur dun attribut ne doit pas excder 100. La structure syntaxique dune description de contrainte est la suivante :
nom_de_la_contrainte i s c o n s t r a i n t { corps_de_la_contrainte }
Une contrainte peut aussi tre dnie par rfrence une contrainte dun autre style.
constraints { contrainte is autre_style@contrainte1 }
o, autre_style@contrainte1 dsigne la contrainte nomme contrainte1 dans autre_style. Le corps de la contrainte est exprim par des proprits en AAL. La contrainte concerne linstance dun style. Gnralement, il sagit dune architecture reprsente sous forme dabstraction, mais il peut sagir de nimporte quel autre type de donne. Au sein de la description cette instance est reprsente par le mot-cl styleInstance. Nous illustrons la dnition des contraintes par lexemple suivant qui dcrit une formalisation de la contrainte deadLockFreedom. Cette contrainte vrie que pour toute squence dactions on peut trouver une action prochaine telle que celle-ci dbouche elle-mme sur une action. Ainsi, cette proprit signie quune action peut toujours tre eectue, donc que le systme ne peut pas bloquer. 220
deadLockFreedom i s c o n s t r a i n t { to s t y l e I n s t a n c e . behaviour apply { every sequence { t r u e } leads to state {some sequence { t r u e } leads to state { t r u e }} } }
4.6
Les analyses
An dautomatiser ltude dune architecture suivant un style particulier, il est ncessaire de dnir des outils danalyse spciques ce style. Les caractristiques identies peuvent tre de direntes sortes. Il peut sagir dune vrication ou dune mesure. Une analyse peut vrier la satisfaction dune proprit par larchitecture ; par exemple, une analyse permet de vrier que la structure de larchitecture est cyclique. Une analyse peut retourner une mesure ; par exemple, lanalyse retourne le nombre dlments dune architecture. La performance dun systme svalue diremment selon la nature de son architecture. Par exemple, sil sagit dune architecture dcrivant un agent ractif, on valuera son temps de rponse. Un agent cognitif sera plus valu sur le nombre de cas quil pourrait rsoudre. La structure syntaxique permettant de crer une analyse est la suivante :
nom_de_l_analyse i s analysis { kind type_d_analyse input { parametres_d_entre } output { type_de_la_valeur_retourne } body { corps_ de_l_analyse } }
Ainsi, une analyse est dnie avec : un nom : il est utilis pour rfrencer lanalyse ; le type danalyse : celui-ci rfrence loutil danalyse capable de traiter la description contenue au niveau du corps. des paramtres dentre (input ) : ils sont constitus par un ensemble didentiants typs. Les valeurs qui sont passes en paramtre reprsentent la fois des lments sur lesquels lanalyse porte et des lments pour congurer (rgler) lanalyse. Ils sont utiliss dans la description du corps de lanalyse comme sil sagissait de valeurs dnies. un type de la valeur retourne (output ) : ici sont spcis les types de donnes quune analyse va retourner. un corps : il contient la description de lanalyse dans un langage associ au type de lanalyse. 221
Bibliographie
[AA96] A. Abd-Allah. Composing Heterogeneous Software Architecture. PhD thesis, Center for Software Engineering, University of Southern California, 1996. G. Abowd, R. Allen, and D. Garlan. Formalizing style to understand descriptions of software architecture. ACM transaction on Software Engineering and Methodology, pages 319364, 1995. J.R. Abrial. The B Method for Large Software Specication, Design and Coding. S. Prehn and W.J. Toetenel. Eds. VDM91 : Formal Software Development Methods, 1991.
[AAG95]
[Abr91]
[AGMO02] I. Alloui, H. Garavel, R. Mateescue, and F. Oquendo. The ArchWare Architecture Analysis Language. ArchWare Europeen RTD Project IST-2001-32360. Delivrable D 3.1b, 2002. [AHO06] S. Azaiez, M.P. Huget, and F. Oquendo. Approach for MultiAgent Metamodelling. Multi-Agent and Grid Systems, Special Issue on Agent-Oriented Software Development Methodology, 2006. Robert Allen. A Formal Approach to Software Architecture. PhD thesis, Carnegie Mellon University, USA, 1997. S. Azaiez and F. Oquendo. Final ArchWare Architecture Analysis Tool by Theorem Proving. ARCHWARE European RTD Project IST-2001-32360. Deliverable D1.2b, 2005. S. Azaiez, F. Pourraz, H. Verjus, and F. Oquendo. Final ArchWare Architecture Animator - Release 1. ArchWare European RTD Project IST-2001-32360, Deliverable D2.2b, 2003. J.L. Austin. How to do Things with Words. Oxford University Press, 1962. M. Bakalem. Modlisation et simulation orientes objet des systmes manufacturiers. PhD thesis, Thse de Doctorat en Electronique - Electrotechnique - Automatique, Universit de Savoie, 1996. M. Le Bars, J.-M. Attonaty, and S. Pinson. An agent-based simulation for water sharing between dierent users. In Interna-
[All97] [AO05]
[APVO03]
[Aus62] [Bak96]
[BAP02]
224
Bibliographie tional Joint Conference on Autonomous Agents and Multi Agent Systems : Bringing people and agents together, pages 211213, Bologne, 2002. ACM. J. Bzivin, M. Blay, M. Bouzhegoub, J. Estublier, J.M. Favre, S. Grard, and J.M. Jezequel. Rapport de Synthse de lAS CNRS sur le MDA (Model Driven Architecture). Rapport CNRS, janvier 2005. A. Belangour, J. Bzivin, and M. Fredj. Towards a new software development process for MDA. In Proceedings of the European Workshop on Milestones, Models and Mappings for ModelDriven Architecture, Bilbao, Spain, 2006. D. Bergamini, D. Champelovier, N. Descoubes, H. Garavel, R. Mateescu, and W. Serwe. ArchWare Architecture Analysis Tool by Model-Checking. ARCHWARE European RTD Project IST-2001-32360. Deliverable D3.6b, 2004. C. Bernon, M. Cossentino, M.P. Gleizes, P. Turci, and F. Zambonelli. A study of some Multi-Agent Meta-Models. In Proceedings of the fourth international workshop on software engineering for large-scale multi-agent systems, 2004. L. Bass, P. Clements, and R. Kazman. Software architecture in practice. Addison Wesley, ISBN 0-201-19930-0, 1999. C. Bernon, M. Cossentino, and J. Pavon. An Overview of Current Trends in European AOSE Research. Informatica (Slovenia), pages 379390, 2005. O. Boissier and Y. Demazeau. ASIC : An Architecture for Social and Individual Control and its Application to Computer Vision. MAAMAW, pages 135149, 1994. P. Boulet, J.-L. Dekeyser, C. Dumoulin, Ph. Kajfasz, Ph. Marquet, and D. Ragot. Sophocles : Cyber-Enterprise for SystemOn-Chip Distributed Simulation. LIFL02, June 2002. C. Berchet. Modlisation pour la simulation dun systme daide au pilotage industriel. PhD thesis, Thse de Doctorat en Gnie Industriel, INP de Grenoble, 2000. D. Balasubramaniam, P. Fabriani, R. Dindeleux, and F. Pourraz. Archware code synthesiser. ARCHWARE European RTD Project IST-2001-32360.Project Deliverable D6.4b, June 2005. J. Bzivin and O. Gerb. Towards a precise denition of the omg/mda framework. In ASE01, Novembre 2001. O. Boissier, S. Gitton, and P. Glize. Caractristiques des systmes et des applications. Observatoire Franais des Techniques Avances, Rapport de synthse du Groupe Systmes MultiAgents, Fvrier 2004. 224
[BBB+ 05]
[BBF06]
[BCD+ 04]
[BCG+ 04]
[BCK99] [BCP05]
[BD94]
[BDD+ 02]
[Ber00]
[BFDP05]
[BG01] [BGG04a]
Bibliographie
225
[BGG+ 04b] P. Bresciani, P. Giorgini, F. Giunchiglia, J. Mylopoulos, and A. Perini. Tropos : An Agent-Oriented Software Development Methodology. . Journal of Autonomous Agent and Multi-Agent Systems, 2004. [BGPG02] C. BERNON, M.-P. GLEIZES, G. PICARD, and P. GLIZE. The ADELFE Methodology For an Intranet System Design. In Fourth International Bi-Conference Workshop on AgentOriented Information Systems (AOIS-2002), volume 57, Toronto, Canada, 2002. CEUR Workshop Proceedings. M.E. Bratman, D.J. Israel, and Martha E. Pollack. Plans and resource-bounded practical reasoning. Computational Intelligence, 4(4) :349355, 1988. F. M. T. Brazier, B. Dunin Keplicz, N. Jennings, and J. Treur. DESIRE : Modelling multi-agent systems in a compositional formal framework. Int. J. Coop. Inform. Syst. 9(1), 1997.
[BIP88]
[BKJT97]
[BKPPT00] P. Bottoni, M. Koch, F. Parisi-Presicce, and G. Taentzer. Consistency checking and visualization of OCL constraints. In The Unied Modeling Language Advancing the strandard, third international conference, pages 294308, 2000. [BMO01] B. Bauer, J.P. Muller, and J. Odell. Agent UML : A Formalism for Specifying Multiagent Software Systems. The International Journal of Software Engineering and Knowledge Engineering, 2001. M. Boasson. The Artistry of Software Architecture. Guest editors introduction,IEEE Software, 1995. B. W. Boehm. Software Engineering. IEEE Transaction Computers, 1976. B. W. Boehm. A spiral model of software development and enhancement. IEEE Computer, 1988. G. Booch. Conception oriente objets et applications. AddisonWesley, 1992. F. Bellifemmine, A. Poggi, and G. Rimassa. JADE - A FIPA compliant agent framework. In 4th International Conference and Exhibition on the Practical Application of Intelligent Agents and Multi-Agents, 1999. D. Bertolini, A. Perini, A. Susi, and H. Mouratidis. The Tropos visual modeling language. A MOF 1.4 compliant meta-model. Contribution for the AOSE TFG meeting, 2005. M. E. BRATMAN. 1987. Intention, Plans, and Practical Reason.
[Boa95] [Boe76] [Boe88] [Boo92] [BPR99]
[BPSM05]
[BRA87]
225
226 [BRHL99]
Bibliographie P. Busetta, R. Ronnquist, A. Hodgson, and A. Lucas. Jack intelligent agents - components for intelligent agents in java. AgentLink News Letter, 1999. G. Booch, J. Rumbaugh, and I. Jacobson. Le guide de lutilisateur UML. 2000. R. A. Brooks. A robust layered control system for a mobile robot. IEEE Journal of Robotics and Automation, 1986. F. Budinsky, D. Steinberg, R. Ellersick, E. Merkes, S.A. Brodsky, and T.J. Grose. Eclipse Modeling Framework. Addison Wesley, 2003. J. Bzivin. In Search of a Basic Principle for Model-Driven Engineering. Novatica Journal. Special Issue., 2004. Valrie Camps. Une valuation de la mthode de la relaxation restreinte pour lauto-organisation dans les systmes multiagents. Masters thesis, IRIT -Toulouse, 1994. M. Cossentino, C. Bernon, and J. Pavn. Modelling and Metamodelling Issues in Agent Oriented Software Engineering : The AgentLink AOSE TFG Approach. Report of the AOSE TFG Ljubljana meeting, 2005. A. Chella, M. Cossentino, and L. Sabatucci. Tools and patterns in designing multiagent systems with PASSI. In 6th WSEAS International Conference on Telecommunications and Informatics, Cancun, Mexico, 2004. L. Cernuzzi, M. Cossentino, and F. Zambonelli. Process Models for Agent-based Development. Journal of Engineering Applications of Articial Intelligence, 18, 2005. M. Clavel, F. Duran, S.Eker, P. Lincoln, N.Marti-Oliet, Jos Meseguer, and C.Talcott. The Maude 2.0 System. In In Proc. Rewriting Techniques and Applications, 2003, Springer-Verlag LNCS 2706, pages 7687, June 2003. M. Cossentino, S. Gaglio, A. Garro, and V. Seidita. Method fragments for agent design methodologies : from standardization to research. International Journal on Agent Oriented Software Engineering (IJAOSE), 2007. M. Cossentino, S. Gaglio, L. Sabatucci, and V. Seidita. The PASSI and Agile PASSI MAS Meta-Models Compared with a Unifying Proposal. In Proceeding of the CEEMAS 05 Conference, pages 183192., Budapest, Hungary, sept 2005. K. Czarnecki and S. Helsen. Classication of model transformation approaches. In OOPSLA03 Workshop on Generative Techniques in the Context of Model-Driven Architecture, 2003. 226
[BRJ00] [Bro86] [BSE+ 03]
[Bz04] [Cam94]
[CBP05]
[CCS04]
[CCZ05]
[CDS+ 03]
[CGGS07]
[CGSS05]
[CH03]
Bibliographie [Che76]
227
P. Chen. The entity relationship model - towards a unied view of data. ACM Transactions on Database Systems, pages 936, 1976. P. Ciancarini. Coordination models and languages as software integrators. ACM Computing Surveys, 1996. G. Caire, F. Leal, P. Chainho, R. Evans, F. Garijo, J. Gomez, J. Pavon, P. Kearney, J. Stark, and P. Massonet. Agent-oriented analysis using message/uml, 2001. J. C. Collis, D. T. Ndumu, H. S. Nwana, and L.C. Lee. The ZEUS agent building toolkit. BT Technology Journal, 16(3), 1998. S. Cimpan, F. Oquendo, D. Balasubramaniam, G. Kirby, and R. Morrison. The ArchWare ADL : Denition of the Textual Concrete Syntax. ArchWare European RTD Project IST-200132360, Deliverable D1.2b, 2002. M. Cossentino and C. Potts. PASSI : a process for specifying and implementing Multi-Agent Systems Using UML, 2001. L.R. Coutinho, J.S. Sichman, and O. Boissier. Modeling Organization in MAS : A comparison of Models. 2005. R. Cervenka and I. Trencansky. Agent Modeling Language : Language Specication. Technical report, Version 0.9. Technical report, Whitestein Technologies, 2004. R. Cervenka, I. Trencansky, M. Calisti, and D. Greenwood. AML : Agent Modeling Language. Toward Industry-Grade Agent-Based Modeling. In In Odell, J., Giorgini, P., Muller, J., eds. : Agent-Oriented Software Engineering V : 5th International Workshop, AOSE 2004, Springer-Verlag, 2005. L. Cernuzzi and F. Zambonelli. Experiencing AUML with the Gaia Methodology. In 6th International Conference on Enterprise Information Systems, Porto, April 2004. A. Drogoul, B. Corbara., and D. Fresneau. Manta : New experimental results on the emergence of (articial) ant societies. Articial Societies : the computer simulation of social life, N. Gilbert and R. Conte, eds., UCL Press, 1995. Y. Demazeau. Voyelles. Mmoire dhabilitation diriger des recherches, INP Grenoble, 2001. P. Desfray. UML Proles Versus Metamodel Extensions : An Ongoing Debate. In OMGs UMLWorkshops : UML in the .com Enterprise : Modeling CORBA, Components, XML/XMI and Metadata Workshop, 2000. 227
[Cia96] [CLC+ 01]
[CNNL98]
[COB+ 02]
[CP01] [CSB05] [CT04]
[CTCG05]
[CZ04]
[DCF95]
[Dem01] [Des00]
228 [DGS06]
Bibliographie T.-L.-A. Dinh, O. Gerb, and H. Sahraoui. Un mtamtamodle pour la gestion de modles. In IDM 06 Actes des 2mes Journes sur lIngnierie Dirige par les Modles, Lille, France, 2006. F. DeRemer and H. Kron. Programming-in-the large versus programming-in-the-small. In ACM Press, editor, In Proceeding of the International Conference on Reliable software, pages 114 121, New York, NY, USA, 1975. M. dInverno, D. Kinny, M. Luck, and M. Wooldridge. A formal specication of dMARS. In Agent Theories, Architectures, and Languages, pages 155176, 1997. J.-C. Derniame, B. A. Kaba, and D.G. Wastell, editors. Software Process : Principles, Methodology, Technology, volume 1500 of Lecture Notes in Computer Science. Springer, 1999. A. Drogoul. De la simulation multi-agents la rsolution collective de problmes. Une tude de l mergence de structures dorganisation dans les systmes multi-agents. PhD thesis, University of Pierre et Marie Curie (Paris VI), 1993. K.H. Dam and M. Winiko. Comparing agent-oriented methodologies. In AAMAS03, editor, Fifth International BiConference Workshop on Agent-Oriented Information Systems (AOIS-2003), volume 3030, pages 7893, Melbourne, Australia, 2003. Springer-Verlag. B. Esfandiari and D. Quinqueton. An interface agent for network supervision. In Proceedings of ECAI, Budapest, 1996. J. Estublier, G. Vega, and A. Ionita. Composing DomainSpecic Languages for Wide-scope Software Engineering Applications. In MODELS, 2005. Jean-Marie Favre. Towards a Basic Theory to Model Driven Engineering. In Workshop on Software Model Engineering, WISME, 2004. Jacques Ferber. Les systmes multi-agents : vers une intelligence collective. Informatique, Intelligence Articielle. Interditions, 1995. J. Ferber and O. Gutknecht. A meta-model for the analysis and design of organizations in multi-agent systems. In In Proceedings of the third international conference on multi-agent systems., 1998. J. Ferber and O. Gutknecht. Madkit : A generic multi-agent platform. In 4 th International Conference on Autonomous Agents., 2000. 228
[DK75]
[dKLW97]
[DKW99]
[Dro93]
[DW03]
[EQ96] [EVI05]
[Fav04]
[Fer95]
[FG98]
[FG00]
Bibliographie [FGM03]
229
J. Ferber, O. Gutknecht, and F. Michel. From agents to organizations : An organizational view of multi-agent systems. In AOSE, pages 214230, 2003. [FGSP04] R. Fuentes, J. Gmez-Sanz, and J. Pavn. Towards requirements elicitation in multi-agent systems. In Proc. Of the 17th European Meeting on Cybernetics and Systems Research, 2004. [FIP99] FIPA. FIPA Specication. rapport, 1999, FIPA Association, 1999. [FLM95] T. Finin, Y. Labrou, and J. Mayeld. KQML as an agent communication language. Je Bradshaw (Ed.), "Software Agents", MIT Press,Cambridge, 1995. [Fox81] M. Fox. An organizational view of distributed systems. In IEEE Transactions on Systems, 11 :7080, 1981. [Gar89] Hubert Garavel. Compilation et vrication de programmes LOTOS. PhD thesis, Universit Joseph Fourier (Grenoble), 1989. [Gar95] D. Garlan. What is style ? In Proceedings of Dagshtul Workshop on Software Architecture, 1995. [GGG05] J-P. Georg, M-P. Gleizes, and P. Glize. Basic approach to emergent programming - feasibility study for engineering adaptive systems using self-organizing instruction-agents. In LNCS 3910 Springer Verlag, editor, The Third International Workshop on Engineering Self-Organising Applications (ESOA05) at the Fourth International Joint Conference on Autonomous Agents & Multi-Agent Systems (AAMAS05), pages 1630, Utrecht, Netherlands, July 2005. [GHB00] M. Greaves, H. Holmback, and J. Bradshaw. What is a conversation policy ? Issues in Agent Communication, F. Dignum, M. Greaves editors, LNAI 1916, Springer Verlag, pages 118131, 2000. [GJM03] C. Ghezzi, M. Jazayeri, and D. Mandrioli. Fundamentals of Software Engineering. Second Edition, ISBN 0-13-305699-6, 2003. [GKMP04] P. Giorgini, M. Kolp, J. Mylopoulos, and M. Pistore. The Tropos Methodology : An Overview. In Methodologies and Software Engineering for Agent Systems, Kluwer, 2004. [GL87] M. P. George and A. L. Lansky. Reactive reasoning and planning. In Proceedings of the Sixth National Conference on Articial Intelligence (AAAI-87), pages 677682, Seattle, 1987. [GMMZ04] P. Giorgini, F. Massacci, J. Mylopoulos, and N. Zannone. Filling the gap between Requirements Engineering and Public Key/Trust Management Infrastructures. In Proceedings of the 1st European PKI Workshop : Research and Applications (1st EuroPKI), LNCS 3093, 2004. 229
230 [GMP02]
Bibliographie F. Giunchiglia, J. Mylopoulos, and A. Perini. The tropos software development methodology : Processes, models and diagrams. In AOSE 02, pages 162173, 2002. M.-P. Gleizes, T. Millan, and G. Picard. ADELFE : Using SPEM Notation to Unify Agent Engineering Processes and Methodology. Rapport interne IRIT/2003-10-R, Institut de Recherche en Informatique de Toulouse (IRIT), 2003. D. Garlan, R.T. Monroe, and D. Wile. Acme : Architectural description of component-based systems. In Gary T. Leavens and Murali Sitaraman, editors, Foundations of Component-Based Systems, Cambridge University Press, pages 4768, 2000. IEEE Architecture Working Group. Recommended practice for architectural description of software-intensive systems. Technical report, IEEE, 2000. Object Management Group. OMG : Software Process Engineering Metamodel Specication Version 1.0. Rapport technique Version 1.0, formal/02-11-14, 2002. D. Garlan and M. Shaw. Introduction to software architecture. In World Scientic Publishing Company, editor, Advances in Software Engineering and Knowledge Engineering, 1993. J. Habermas. The Idea of the Theory of Knowledge as Social Theory. Knowledge & Human Interest, 1968. G. Habchi. Conceptualisation et modlisation pour la simulation des systmes de production. HDR, ESIA, Universit de Savoie., 2001. G. Habchi, M.-P. Huget, M. Pralus, S. Azaiez, J. Tounsi, and K. Tamani. Modlisation systme multi-agents (sma) du processus de pilotage dun systme de fusion dinformations appliqu un systme de production. Technical report, laboratoire LISTIC, 2007. M.-P. Huget, J. Odell, and B. Bauer. The AUML Approach. volume 11, chapter 1. Kluwer, 2004. J.F Hbner, J.S Sichman, and O. Boissier. Spcication structurelle, fonctionnelle et dontique dorganisations dans les systmes multi-agents. JFIADSMA 02, 2002. J. Hbler, M. Soden, and H. Eichler. Coevolution of Models, Metamodels and Transformations. http ://www.ikv.de/index.php, 2006. M.-P. Huget. Agent Communication. In Intelligent Decision Support Systems in Agent-Mediated Environments. Frontiers in Articial Intelligence and Applications. Gloria Phillips-Wren and Lakhmi Jain (eds.), IOS Press, 115, 2005. 230
[GMP03]
[GMW00]
[Gro00]
[Gro02]
[GS93]
[Hab68] [Hab01]
[HHP+ 07]
[HOB04] [HSB02]
[HSE06]
[Hug05]
Bibliographie [IEV05]
231
A. D. Ionita, J. Estublier, and G. Vega. Domaines rutilisables dirigs par les modles. In Proc. Of Ingnierie dirige par les modles, IDM05, Paris, 2005. C.A. Iglesias, M. Garijo, and J.C. Gonzalez. A survey of agentoriented methodologies. In Proceeding of the Fifth International Workshop on Agent Theories Architectures, and Languages, "Budapest, Hungary", sept 1999. I. Jacobson. Object-Oriented Software Engineering - a Use Case Driven Approach. TOOLS, 1993. N. R. Jennings, P. Faratin, A.R. Lomuscio, S. Parsons, C. Sierra, and M. Wooldridge. Automated negotiation : prospects, methods and challenge. International Journal of Group Decision and Negotiation (GDN), 10 :99215, 2001. J.-M. Jzquel, S. Grard, and B. Baudry. Le gnie logiciel et lidm : une approche unicatrice par les modles. Lingnierie dirige par les modles, Lavoisier, Hermes-science, 2006. F. Jouault and I. Kurtev. On the architectural alignment of atl and qvt. In Proceedings of ACM Symposium on Applied Computing (SAC 06), Model Transformation Track, Dijon (Bourgogne, FRA), April 2006. N. R. Jennings, S. Parsons, C. Sierra, and P. Faratin. Automated negotiation. In 5th International Conference on The Practical Application of Intelligent Agent and Multi-Agent Systems(PAAM-2000), Manchester, UK, 2000. G. Jack, K. Short, S. Cook, and S. Kent. Software Factories : Assembling Applications with Patterns, Models, Frameworks, and Tools. West Sussex, England : John Wiley & Sons, Ltd., 2004. H. Jonkers, M. Steen, L. Heerink, and D. Van Leeuwen. From Business Process Design to Code : Model-Driven Development of Enterprise Applications. https ://doc.freeband.nl/dsweb/Get/Document-77839/, 2007. N. R. Jennings, K. Sycara, and M. Wooldridge. A Roadmap of Agent Research and Development. Journal of Autonomous Agents and Multi-Agent Systems, 1998. H. Kadima. MDA - conception oriente objet guide par les modles. NFE114, 2005. M. Klein and R. Kazman. Attribute-based architectural styles. Technical report, CMU/SEI-99-TR-022. ESC-TR-99-022, 1999. D. Kozen. Results on the propositional -calculus. Theoretical Computer Science, 1983. 231
[IGG99]
[Jac93] [JFL+ 01]
[JGB06]
[JK06]
[JPSF00]
[JSCK04]
[JSHL07]
[JSW98]
[Kad05] [KK99] [Koz83]
232 [KPR03] [Kru95] [KWB03]
Bibliographie R. Kazhamiakin, M. Pistore, and M. Roveri. T-tool tutorial. Technical report, University of Trento, 2003. P. Kruchten. The 4+1 view model of architecture. IEEE Softw, 1995. A. Kleppe, J. Wagner, and W. Bast. MDA Explained : The Model Driven Architecture : Practise and Promise. AddisonWesley., 2003. P. Larvet. Analyse des systmes : de lapproche fonctionnelle lfapproche objet. InterEditions., 1994. A. Ledeczi, A. Bakay, M. Maroti, P. Volgyesi, G. Nordstrom, and J. Sprinkle. Composing domain-specic design environments. Computer Networks and ISDN Systems, pages 4451, 2001. F. Leymonerie. ASL : un langage et des outils pour les styles architecturaux. Contribution la description darchitectures dynamiques. PhD thesis, LISTIC, Universit de Savoie, Annecy, 2004. M. Ljunberg and A. Lucas. The OASIS air trac management system. In In Proceedings of the Second Pacic Rim International Conference on AI (PRICAI-92), Seoul, Korea, 1992. S. E. Lander and R. Lesser. Understanding the role of negotiation in distributed search among heterogeneous agents. In International Joint Conference on Articial Intelligence (IJCAI-93), 1993. D.B. Lange and M. Oshima. Programming and Deploying Java Mobile Agents with Aglets. Addison Wesley, 1998. T. Malone. Modeling coordination in organizations and markets. In Management science, 33, 1987.
[Lar94] [LBM+ 01]
[Ley04]
[LL92]
[LL93]
[LO98] [Mal87]
[MBWH03] P. Marrow, E. Bonsma, F. Wang, and C. Hoile. DIET - A Scalable, Robust and Adaptable Multi-Agent Platform for Information Management. BT Technology Journal, 21(4) :130137, 2003. [MC97] P. Marcenac and S. Calderoni. Self-organisation in agent-based simulation. In Proceedings of MAAMW 97, Ronnedy, Sweden, 1997. T. Mens, K. Czarnecki, and P. Van Gorp. A taxonomy of model transformations. In Dagstuhl Seminar Proceedings 04101, 2005.
[MCG05]
[MDEK95] J. Magee, N. Dulay, S. Eisenbach, and J. Kramer. Specifying distributed software architectures. 1995. [Meg04] K. Megzari. REFINER : environnement logiciel pour le ranement darchitectures logicielles fond sur une logique de rcriture. Thse de Doctorat de lUniversit de Savoie, 2004. 232
Bibliographie [Mil99]
233
R. Milner. Communicating and mobile systems : The -calculus. Cambridge University Press., 1999. [MKMG97] R.T. Monroe, A. Kompanek, R. Melton, and D. Garlan. Architectural styles, design patterns, and objects. In Proceedings of the IEEE Transactions on Software Enginering, 1997. [Ml02] J.P. Mller. Des systmes autonomes aux systmes multiagents : Interaction, mergence et systmes complexes. PhD thesis, Universit Montpellier II, 2002. [MP05] P. Mathieu and S. Picault. Towards an interaction-based design of behaviors. In The Third European Workshop on Multi-Agent Systems, 2005. [MPS02] P. Moraitis, E. Petraki, and N.I. Spanoudakis. Engineering jade agents with gaia methodology. In Agent Technologies, Infrastructures, Tools, and Applications for E-Services, pages 7792, 2002. [MRRR02] Nenad Medvidovic, David S. Rosenblum, David F. Redmiles, and Jason E. Robbins. Modeling software architectures in the unied modeling language. In ACM Transactions On Software Engineering and Methodology, 2002. [MRT99] N. Medvidovic, D.S Rosemblum, and R. Taylor. A language and environment for architecture-based software development and evolution. In Proceedings of the 21st International Conference on Software Engineering (ICSE99), Los Angeles, Mai 1999. [MT00] N. Medvidovic and N R. Taylor. A classication and comparison framework for software architecture description languages. IEEE Transactions on Software Engineering, pages 7093, 2000. [MT01] N. Medvidovic and R. N. Taylor. A classication and comparison framework for software architecture description languages. IEEE Transactions on Software Engineering, 2001. [NR99] E. Di Nitto and D. Rosenblum. Exploiting ADLs to Specify Architectural Styles Induced by Middleware Infrastructures. Proceedings of the 21st International Conference on Software Engineering (ICSE99), 1999. [OACV02] F. Oquendo, I. Alloui, S. Cmpan, and H. Verjus. The ArchWare ADL : Denition of the Abstract Syntax and Formal Semantics. ARCHWARE European RTD Project IST-2001-32360. Deliverable D1.1b, dcembre 2002. [OBDK01] M. Occello, C. Baeijs, Y. Demazeau, and J.L. Koning. Mask : An aeio toolbox to develop multi-agent systems. Knowledge Engineering and Agent Technology, Cuena, Demazeau, Garcia, Treur eds, IOS Series on Frontiers in Articiel Intelligence and Applications, 2001. 233
234 [Ode02] [OJ96] [OMG03] [OMG04] [OMG05] [OMG06] [Oqu03]
Bibliographie J. Odell. Objects and Agents Compared. Journal of Object Technology, 2002. G. M. P. OHare and N. R. Jennings. Foundations of Distributed Articial Intelligence. Wiley-Interscience, 1996. OMG. MDA GUIDE Version 1.0.1. omg/2003-06-01., 2003. document number
OMG. Uml 2 metamodel. ptc/04-10-05 (UML 2.0 Superstructure FTF Rose model containing the UML 2 metamodel), 2004. OMG. MOF QVT Final Adopted Specication. OMG document, november 2005. OMG. Meta Object Facility Core Specication version 2.0. OMG Document, january 2006. F. Oquendo. The ArchWare Renement Language. Deliverable D6.1b. ArchWare European RTD Project. IST-200132360, 2003. Juan Pavn. Ingenias : Dveloppement dirig par modles des systmes multi-agents. HDR Universit Paris 6, 2006. A. Pokahr, L. Braubach, and W. Lamersdorf. Jadex : A bdi reasoning engine, chapter of multi-agent programming. Kluwer Book, Editors : R. Bordini, M. Dastani, J. Dix and A. Seghrouchni, 2005. J. Pavon and J. Gomez-Sanz. Agent-oriented Software Engineering with INGENIAS. In 3rd Central and Eastern European Conference on Multi-Agent Systems (CEEMAS03), Prague, Czech Republic., 2003. G. Picard. Mthodologie de dveloppement de systmes multiagents adaptatifs et conception de logiciels fonctionnalit mergente. Institut de Recherche en Informatique de Toulouse(IRIT), dcembre 2004. A. Perini, M. Pistore, M. Roveri, and A. Susi. Agent-oriented modeling by interleaving formal and informal specication. Agent Oriented Software Engineering - AOSE, 2003. F. Pourraz, H. Verjus, S. Azaiez, F. Oquendo, and C. Zavattari. Extended ArchWare Architecture Animator - Release 2.1. ARCHWARE European RTD Project IST-2001-32360. Deliverable D2.2d, avril 2005. Dewayne E. Perry and Alexander L. Wolf. Foundations for the study of software architecture. SIGSOFT Software Engineering Notes, 17(4) :4052, 1992. 234
[Pav06] [PBL05]
[PGS03]
[Pic04]
[PPRS03]
[PVA+ 05]
[PW92]
Bibliographie [RB98]
235
[RBE+ 95]
[RM01]
[Rod94]
[SBPL06]
[SDS03]
[Sea69] [Sei03] [SMA06] [Smi88]
[Spi92] [SPM04]
[SRB06]
[SS03]
J. Rouchier and F. Bousquet. Non-merchant economy and multi-agent system : an analysis of structuring exchanges. Number 11112. Springer Verlag, 1998. J. Rumbaugh, M. Blaha, F. Eddy, W. Premerlani, and W. Lorensen. OMT. Modlisation et conception orientes objet. Masson Paris and Prentice Hall London, 1995. J.-C. Routier and P. Mathieu. Magique : Agents, comptences et hirarchies. Revue de Technique et Science Informatiques (TSI), 2001. M. Rodriguez. Modlisation dun agent autonome : Approche constructiviste de larchitecture de contrle et de la reprsentation de connaissances. PhD thesis, Universit de Neufchtel., 1994. J. Sudeikat, L. Braubach, A. Pokahr, and W. Lamersdorf. Validation of BDI Agents. In The Fifth International Workshop on Programming Multiagent Systems (PROMAS-2006), 2006. A. Sturm, D. Dori, and O. Shehory. Single-model method for specifying multi-agent systems. In Proceedings of AAMAS03, 2003. J.R. Searle. Speech acts. Cambridge University Press, UK, 1969. E. Seidewitz. What models mean. IEEE Software, 2003. http ://smartqvt.elibel.tm.fr/, 2006. R.G. Smith. The contract net protocol : High-level communication and control in a distributed problem solver. Readings in Distributed Articial Intelligence, Bond A. H. and Gasser L.(Eds.), pages 357366, 1988. J. M. Spivey. The Z Notation : A Reference Manual. Prentice Hall International Series in Computer Science., 1992. R. Sebastiani, P.Giorgini, and J. Mylopoulos. Simple and minimum-cost satisabilityfor goal models. In Proceedings of the 16th Conference On AdvancedInformation Systems Engineering (CAiSE 04), LNCS Springer, 2004. D.R. Dos Santos, M. Blois Ribeiro, and R. Melo Bastos. A comparative study of multi-agent systems development methodologies. In Second Workshop on Software Engineering for AgentOriented Systems, pages 3748, Florianopolis, 2006. A. Sturm and O. Shehory. A framework for evaluating agentoriented methodologies. In Fifth International Bi-Conference Workshop on Agent-Oriented Information Systems (AOIS2003), volume 3030, pages 94109, Melbourne, Australia, 2003. Springer-Verlag. 235
236 [Str95]
Bibliographie E. Le Strugeon. Une mthodologie dauto-adaptation dun systme multi-agents cognitifs. Thse de doctorat, Universit de Valanciennes, 1995. J. Tounsi, J. Boissire, and G. Habchi. Modlisation pour la simulation des fonctions de management de la chaine logistique globale dans un environnement de production PME Mcatronique. PhD thesis, Universit de Savoie - thse en cours, 2007. S. Vestal. Metah reference manual. Technical report, Honeywell Technology Center Minneapolis MN, 1992. S. Vestal. Mode changes in real-time architecture description language. In Proceedings of the Second International Workshop on Congurable Distributed Systems, 1994. J. Vazquez-Salceda, V. Dignum, , and F. Dignum. Organizing multiagent systems. Technical Report UU-CS-2004-015, Institute of Information and Computing Sciences, Utrecht University, 2004. E. Woods and R. Hilliard. Architecture Description Languages in Practice Session Report. Software Architecture, 2005. WICSA 2005. 5th Working IEEE/IFIP Conference, pages 243 246, 2005. M. J. Wooldridge, N.R. Jennings, and D. Kinny. The Gaia Methodology for Agent-Oriented Analysis and Design. In Autonomous Agents and Multi-Agent systems, volume volume 3, pages 285312, "The Netherlands", 2000. G. Wagner and F. Tulba. Agent-Oriented Modeling and Agent-Based Simulation. In Proceedings of 5th Int. Workshop on Agent-Oriented Information Systems (AOIS-2003), ER2003 Workshops, Springer-Verlag, LNCS. In P. Giorgini and B. Henderson-Sellers (Eds.), 2003. E. Yu and J. Mylopoulos. Towards Modelling Strategic Actor Relationships for Information Systems Development - With Examples from Business Process Reengineering. In Proceedings of the 4th Workshop on Information Technologies and Systems, pages 2128, 1994. F. Zambonelli, N. Jennings, and M. Wooldridge. Developing multiagent systems : The Gaia methodology. ACM Trans. Software Eng. Meth. 12(3), pages 417 470, 2003. W. Zhang, H. Meiand, H. Zhao, and J. Yang. Transformation from CIM to PIM : A Feature-Oriented Component-Based Approach. In Model Driven Engineering Languages and Systems, 8th Intenational Conference MoDELS, Montego Bay, Jamaica, 2005. 236
[TBH07]
[Ves92] [Ves94]
[VSDD04]
[WH05]
[WJK00]
[WT03]
[YM94]
[ZJW03]
[ZMZY05]
Rsum Les systmes multi-agents sattaquent aux nombreuses problmatiques poses actuellement dans le monde informatique telles que la distribution, lvolution, ladaptabilit et linteroprabilit des systmes. Les solutions proposes par ces systmes sont prometteuses et permettent dobtenir des systmes exibles et volutifs. Cependant, leur mise en oeuvre reste dicile. Ceci est d au manque de techniques dingnierie adaptes ce genre de systme et qui permettent un dveloppement able et cohrent. Bien quil existe plusieurs propositions intressantes au niveau des mthodologies, des langages de spcication et des plates-formes dimplmentation orients agent, celles-ci manquent de cohsion et font ressortir plusieurs dirences aussi bien au niveau de la smantique des concepts utiliss mais aussi au niveau des dmarches de dveloppement. Notre but durant cette thse a t de proposer une approche exible et cohrente supportant le dveloppement des systmes multiagents. Cette approche que nous baptisons ArchMDE se base sur une combinaison de lapproche centre architecture et de lapproche dirige par les modles. Lapproche centre architecture nous permet de raisonner sur les lments qui structurent le systme multi-agents ainsi que leurs interactions. Elle permet didentier les patrons architecturaux ncessaires au dveloppement des systmes multi-agents en prenant en compte les direntes vues du systme (vue organisationnelle, vue environnementale, etc.). Lapproche oriente modles nous permet dexprimer de faon explicite la manire de combiner ces patrons architecturaux an davoir une reprsentation globale du systme multi-agents. Dautre part, IDM permet de couvrir les direntes phases du cycle de dveloppement en adoptant une dmarche base sur la transformation de modles. Cette dmarche permet de garantir la cohrence du systme durant les direntes phases du cycle de vie. Par ailleurs, celle-ci ore lavantage de prserver le savoir-faire des dveloppeurs en exprimant explicitement les oprations dintgration (entre les patrons architecturaux) et de mapping (entre les modles de conception et les modles dimplmentation). Pour implanter ArchMDE, nous utilisons le cadre de dveloppement ArchWare qui est bas sur le -calcul typ, polyadique et dordre suprieur, ce qui permet de supporter les aspects communicatifs et volutifs des systmes multi-agents. Le choix dun cadre formel vise rduire lambigut lie aux concepts multi-agents mais aussi garantir une conception sre. En eet, lutilisation dun langage formel donne la possibilit dexprimer explicitement direntes proprits structurelles et comportementales. Le cadre de dveloppement ArchWare ore divers langages accompagns de dirents outils qui nous seront utiles pour mettre en oeuvre notre approche.

Thèse Doctorat - Approche Dirigée Par Les Modèles

Enviado por

Dados do documento

Título original

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

Thèse Doctorat - Approche Dirigée Par Les Modèles

Enviado por

Direitos autorais:

Formatos disponíveis

THSE DE lUNIVERSIT DE SAVOIE

DOCTEUR DE LUNIVERSIT DE SAVOIE

Approche dirige par les modles pour le dveloppement de systmes multi-agents

A mon cher pre, il aurait t si er

Table des matires

Table des gures

Liste des tableaux

Chapitre 1 Introduction gnrale

CHAPITRE 1. INTRODUCTION GNRALE

Une dmarche de dveloppement exible et sre

CHAPITRE 1. INTRODUCTION GNRALE

CHAPITRE 1. INTRODUCTION GNRALE

Chapitre 2 Etude du domaine

CHAPITRE 2. ETUDE DU DOMAINE

Paradigmes de dveloppement vs Ingnierie des systmes logiciels

Les paradigmes de dveloppement

CHAPITRE 2. ETUDE DU DOMAINE programmation tel que Pascal, FORTRAN, C, etc.

Les techniques dingnierie

Lvolution des paradigmes de dveloppement

Le paradigme orient objet

Le paradigme orient composant

CHAPITRE 2. ETUDE DU DOMAINE

Le paradigme orient service

Positionnement du paradigme orient agent

Les problmatiques traites par le paradigme orient agent

Les freins lutilisation des systmes multi-agents

Lvolution des techniques dingnierie

Les techniques dingnieries classiques

Lingnierie des systmes bass sur le paradigme orient composant

CHAPITRE 2. ETUDE DU DOMAINE

CHAPITRE 2. ETUDE DU DOMAINE

Lingnierie dirige par les modles

Conclusions relatives lvolution des techniques dingnierie

CHAPITRE 2. ETUDE DU DOMAINE

Introduction la problmatiques de la thse

CHAPITRE 2. ETUDE DU DOMAINE

Chapitre 3 Ingnierie des Systmes Multi-agents

CHAPITRE 3. INGNIERIE DES SYSTMES MULTI-AGENTS

Les thories orientes agent

CHAPITRE 3. INGNIERIE DES SYSTMES MULTI-AGENTS

CHAPITRE 3. INGNIERIE DES SYSTMES MULTI-AGENTS

Fig. 3.2: Larchitecture MANTA [DCF95]

CHAPITRE 3. INGNIERIE DES SYSTMES MULTI-AGENTS

CHAPITRE 3. INGNIERIE DES SYSTMES MULTI-AGENTS

Ingnierie des systmes informatiques selon le paradigme orient agent

Les langages de spcication

Les mthodologies de dveloppement

Les plates-formes dimplmentation

Les langages de spcication orients agent

Les langages bass sur une extension dUML

CHAPITRE 3. INGNIERIE DES SYSTMES MULTI-AGENTS

Les langages raliss par cration de prol UML

Les notations graphiques

Interaction entre agents Interaction entre objets et agents

Les mthodologies orientes Agent

CHAPITRE 3. INGNIERIE DES SYSTMES MULTI-AGENTS

Organisation Socit Rle Protocole Faits Buts Services Rgles

Tab. 3.3: Les concepts manipuls par OPM/MAS

CHAPITRE 3. INGNIERIE DES SYSTMES MULTI-AGENTS

Fig. 3.10: Le mtamodle dADELFE

CHAPITRE 3. INGNIERIE DES SYSTMES MULTI-AGENTS

CHAPITRE 3. INGNIERIE DES SYSTMES MULTI-AGENTS

Fig. 3.12: Le mtamodle Gaia