République Algérienne Démocratique et Populaire Ministère de L’enseignement Supérieur et de la Recherche Scientifique Université Constantine 2 Mahri Abdelhamid
Faculté des nouvelles technologies de l'information et de la communication Département des Technologies des Logiciels et des Systèmes d’Information
Thèse
Pour obtenir le diplôme de Doctorat en Sciences
Approche basée Agents Mobiles et Composants pour développer des applications ouvertes et adaptables Par Abderrahim Siam Soutenue le : 02/02/2015
Devant le Jury : Pr Belala Faiza Pr Maamri Ramdane Pr Rahmoun Abdellatif Pr Chikhi Salim Pr Kazar Okba Pr Sahnoun Zaidi
Professeur à l’universitéMehri abdelhamid Constantine Professeur à l’universitéMehri abdelhamid Constantine Professeur à l’université université Djillali Liabes Sidi Bel abbes Professeur à l’universitéMehri abdelhamid Constantine Professeur à l’universitéMohamed Khider de Biskra Professeur à l'universitéMehri abdelhamid Constantine
Président Rapporteur Examinateur Examinateur Examinateur Invité
République Algérienne Démocratique et Populaire Ministère de L’enseignement Supérieur et de la Recherche Scientifique Université Constantine 2 Mahri Abdelhamid
Faculté des nouvelles technologies de l'information et de la communication Département des Technologies des Logiciels et des Systèmes d’Information
Thèse
Pour obtenir le diplôme de Doctorat en Sciences
Approche basée Agents Mobiles et Composants pour développer des applications ouvertes et adaptables Par Abderrahim Siam
Remerciements
Je tiens tout d’abord à remercier Professeur Ramdane MAAMRI et Professeur Zaidi SAHNOUN qui m’ont fait l’honneur d’être les rapporteurs de cette thèse. Mes sincères remerciements vont aux membres du jury qui m’ont fait l’honneur d’évaluer les travaux ici présentés. Je remercie Professeur Belala F, qui a présidé le jury. Je remercie Pr Maamri Ramdane et Pr Sahnoun zaidi qui ont accepté de rapporter cette thèse. Je remercie aussi Pr Rahmouni A et Pr Chikhi Salim qui ont pris part au jury. Je les remercie tous pour leur évaluation qui donne toute sa valeur à cette thèse ainsi que pour leurs remarques et questions.. Je tiens à remercier tout un ensemble de personnes grâce à qui, directement ou indirectement, j’ai pu mener ce travail à bien : Tous les membres du laboratoire LIRE, particulièrement les membres de l’équipe GL&IA ; Toute ma famille : mes parents, ma femme, mes frères et ma sœur,... Mes amis, particulièrement : Benaboud Rouhellah, Badis Abdelhafid et le gentleman Ramoul Hichem. Je n’oublie pas les étudiants que j’ai eu le plaisir d’encadrer pour les richesses qu’ils m’ont apportés tant sur le plan scientifique que sur le plan humain. Je n’oublie pas de penser aux enseignants que j’ai eus par le passé depuis l’école primaire.
Abstract
This research focuses on the development of, distributed, open and adaptive applications in which software components and agents (mobile and not mobile) are involved. Software components and agents present two technologies that have a great impact on the software development. The proprieties of distribution, openness and adaptability are imposed as essential characteristics in several systems by the wide spread of Internet and Web technologies as well as the presence of means of data processing in the majority of equipment around us. The development of distributed, open and adaptive applications needs special means, and which could provide solid solutions that meet all the characteristics related to distribution, openness and adaptability. In this thesis, the development of such applications is addressed from the way of the development of organizational multi agent systems. We proposed a combination between components and agents to define a flexible organizational model of MAS based on three concepts: roles, self-adaptive agents based on components and fuzzy groups. Roles are played by agents in fuzzy groups. A fuzzy group is a fuzzy set of agents characterized by a membership function reflecting the notion of partial membership and expressing the membership degree of each agent to the group. The membership degree expresses the degree of capacity of each agent to play a role. We proposed a fuzzy measure of the capacity of agents to play roles. We proposed a model of auto adaptive agents constructed and adapted by automatic assembly (reassembly) of software components that implement required capabilities to play roles. The proposed model and introduced concepts have been tested using the Madkit platform.
Keywords: software components, self adaptive agents, adaptive applications, distributed and open applications, organization, fuzzy sets.
Résumé
Ce travail de recherche porte sur le développement d’applications distribuées, ouvertes et adaptables en faisant intervenir les composants logiciels et les agents (mobiles et non mobiles) qui présentent deux technologies ayant un grand impact sur le développement d’applications informatiques. L’ouverture, la distribution et l’adaptabilité s’imposent de plus en plus comme caractéristiques importantes et essentielles dans plusieurs systèmes informatiques vu la popularisation de l’internet et des technologies Web ainsi que la présence des moyens de traitement de l’information dans plupart des dispositifs qui nous entourent. Le développement d’applications distribuées, ouvertes, et adaptables nécessite des moyens qui peuvent fournir des solutions solides et qui sont en mesure de répondre aux exigences ainsi qu’aux caractères spécifiques imposés sur les applications par les propriétés d’ouverture, de distribution et d’adaptation. Dans cette thèse, on a adressé le développement de telles applications sous l’angle du développement de systèmes multi agents organisationnels. On a proposé une combinaison entre les composants logiciels et les agents pour définir un modèle d’organisation flexible basé sur les concepts de rôles, d’agents auto adaptatifs à base de composants et les groupes flous d’agents. Les rôles sont joués par les agents dans des groupes flous. Un groupe flou est un ensemble flou d’agents caractérisé par une fonction d’appartenance reflétant la notion d’appartenance partielle et exprimant le degré d’appartenance de chaque agent au groupe. Le degré d’appartenance d’un agent à un groupe exprime le degré de sa capacité pour jouer le rôle joué dans le groupe. On a proposé une mesure floue pour la mesure des capacités des agents pour jouer les rôles et un modèle d’agents auto adaptatifs construits et adaptés par assemblage automatique de composants qui implémentent les compétences requises pour jouer les rôles. Les modèles et les concepts proposés ont été testés à travers le développement d’une application multi agents sous la plateforme MadKit.
Mots clé : composants logiciels, agents auto adaptables, applications adaptables, applications ouvertes et distribuées, organisation, ensembles flous.
ﻣﻠﺨﺺ
ھذا اﻟﺑﺣث ﯾﺗﻧﺎول ﺑﺎﻟدراﺳﺔ ﺗطوﯾر اﻟﺑراﻣﺞ و اﻟﺗطﺑﯾﻘﺎت اﻟﺗﻲ ﺗﺗﺻف ﺑﻛوﻧﮭﺎ ﻣوزﻋﺔ ,ﻣﻔﺗوﺣﺔ واﻟﻘﺎﺑﻠﺔ ﻟﻠﺗﺄﻗﻠم ﻣن ﺧﻼل اﺳﺗﻐﻼل ﺗﻛﻧوﻟوﺟﯾﺔ اﻟﺑرﻣﺟﯾﺎت اﻟﺟزﺋﯾﺔ و ﺗﻛﻧوﻟوﺟﯾﺔ اﻟوﻛﻼء) ﻣﺗﻧﻘﻠﺔ وﻏﯾر ﻣﺗﻧﻘﻠﺔ( واﻟﺗﻲ ﻟﮭﻣﺎ ﺗﺄﺛﯾر ھﺎم ﻋﻠﻰ ﺻﻌﯾد ﺗطوﯾر وھﻧدﺳﺔ اﻟﺑراﻣﺞ .إن اﻻﻧﺗﺷﺎر اﻟﻛﺑﯾر ﻟﻼﻧﺗرﻧت و ﺗﻛﻧوﻟوﺟﯾﺎﺗﮭﺎ ﻋﻠﻰ ﻏرار اﻧﺗﺷﺎر وﺳﺎﺋل ﻣﻌﺎﻟﺟﺔ اﻟﺑﯾﺎﻧﺎت ﻓﻲ اﻏﻠب اﻷﺟﮭزة اﻟﻣﺣﯾطﺔ ﺑﻧﺎ ﯾﺣﺗم ﯾوﻣﺎ ﺑﻌد اﻵﺧر ﻋﻠﻰ اﻟﺗطﺑﯾﻘﺎت أن ﺗﻛون ﻣوزﻋﺔ ,ﻣﻔﺗوﺣﺔ وﻗﺎﺑﻠﺔ ﻟﻠﺗﺄﻗﻠم .إن ﺗطوﯾر ﺗطﺑﯾﻘﺎت ﺑﮭذه اﻟﻣواﺻﻔﺎت ﯾﺗطﻠب وﺳﺎﺋل ﻣن ﺷﺄﻧﮭﺎ أن ﺗﻘدم ﺣﻠوﻻ ﻧﺎﺟﻌﺔ و اﻟﺗﻲ ﺗﺗﻣﺎﺷﻰ ﻣﻊ ﻣﺎ ﺗﻔرﺿﮫ ﺧﺻﺎﺋص اﻟﺗوزﯾﻊ ,اﻻﻧﻔﺗﺎح و ﻗﺎﺑﻠﯾﺔ اﻟﺗﺄﻗﻠم ﻣن ﻣﻣﯾزات .ﻓﻲ ھذه اﻷطروﺣﺔ ﻧﻘﺗرح ﺗطوﯾر اﻟﺑراﻣﺞ و اﻟﺗطﺑﯾﻘﺎت اﻟﻣوزﻋﺔ ,اﻟﻣﻔﺗوﺣﺔ واﻟﻘﺎﺑﻠﺔ ﻟﻠﺗﺄﻗﻠم ﻣن ﺧﻼل ﺗطوﯾر ﻧظم ﻣﻧظﻣﺔ ﻣﺗﻌددة اﻟوﻛﻼء أﯾن ﻧﻘﺗرح ﺻﯾﻐﺔ ﻧﺳﺗﺧدم ﻓﯾﮭﺎ اﻟﺑرﻣﺟﯾﺎت اﻟﺟزﺋﯾﺔ و اﻟوﻛﻼء ﺟﻧﺑﺎ إﻟﻰ ﺟﻧب. اﻻﻗﺗراح اﻟﻣﻘدم ﯾﺗﻣﺛل ﻓﻲ اﻗﺗراح ﻧﻣوذج ﺗﻧظﯾم ﯾﺳﺗﻧد ﻋﻠﻰ اﻟﻣﻔﺎھﯾم اﻟﺗﺎﻟﯾﺔ :اﻷدوار ,وﻛﻼء ذاﺗﯾﺔ اﻟﺗﺄﻗﻠم ﯾﺗم ﺑﻧﺎؤھﺎ ﻋﺑر ﺗﺟﻣﯾﻊ اﻟﺑرﻣﺟﯾﺎت اﻟﺟزﺋﯾﺔ و أﺧﯾرا ﺗﺟﻣﻌﺎت ﻣﺑﮭﻣﺔ ﻟﻠوﻛﻼء .ھذه اﻟﺗﺟﻣﻌﺎت ھﻲ ﻋﺑﺎرة ﻋن ﻣﺟﻣوﻋﺎت ﻣﺑﮭﻣﺔ ﯾﺗم ﺑداﺧﻠﮭﺎ ﻟﻌب اﻷدوار ﻣن طرف اﻟوﻛﻼء .ﻛل ﺗﺟﻣﻊ ﯾﺗﻣﯾز ﺑداﻟﺔ اﻧﺗﻣﺎء ﺗﻌﻛس ﻣﻔﮭوم اﻻﻧﺗﻣﺎء اﻟﺟزﺋﻲ إﻟﻰ ﻣﺟﻣوﻋﺔ وﺗﻌﺑر ﻋن ﻣدى اﻧﺗﻣﺎء ﻛل وﻛﯾل إﻟﻰ اﻟﺗﺟﻣﻊ .ھذا اﻟﻣﻘدار ﯾﻌﺑر ﺑدوره ﻋن ﻣدى ﻗدرة اﻟوﻛﯾل ﻋﻠﻰ ﻟﻌب اﻟدور اﻟﻣﺗﻌﻠق ﺑﺎﻟﺗﺟﻣﻊ اﻟذي ﯾﻧﺗﻣﻲ إﻟﯾﮫ اﻟوﻛﯾل .ﻣن أﺟل اﺳﺗﻛﻣﺎل ھذا اﻟﻧﻣوذج ﻗﻣﻧﺎ ﺑﺎﻗﺗراح ﻗﯾﺎس ﻣﺑﮭم ﻟﺗﻘﯾﯾم ﻣدى ﻗدرة اﻟوﻛﻼء ﻋﻠﻰ إﺗﻣﺎم اﻧﺟﺎز اﻷدوار .ﻓﻲ اﻟوﻗت ذاﺗﮫ ,ﺗم اﻗﺗراح ﻧﻣوذج وﻛﻼء ﺗﺑﻧﻰ و ﺗﺗﺄﻗﻠم ﻣن ﺧﻼل ﺗﺟﻣﯾﻊ و إﻋﺎدة ﺗﺟﻣﯾﻊ اﻟﺑرﻣﺟﯾﺎت اﻟﺟزﺋﯾﺔ اﻟداﺧﻠﺔ ﻓﻲ ﺗﺷﻛﯾل اﻟوﻛﯾل و اﻟﺗﻲ ﺗﺿم اﻟﻛﻔﺎءات اﻟﺗﻲ ﺗﻠزم اﻟوﻛﻼء ﺣﺗﻰ ﯾﺗﺳﻧﻰ ﻟﮭم ﻟﻌب اﻷدوار داﺧل اﻟﺗﻧظﯾم .اﻟﻧﻣﺎذج و اﻟﻣﻔﺎھﯾم اﻟﻣﻘﺗرﺣﺔ ﺗم ﺗﺟرﯾﺑﮭﺎ ﻣن ﺧﻼل ﺗطﺑﯾق ﺗم اﻧﺟﺎزه ﻋﻠﻰ أرﺿﯾﺔ ﺗطوﯾر اﻟﻧظم ﻣﺗﻌددة اﻟوﻛﻼء ﻣﺎد ﻛﯾت.
ﻛﻠﻣﺎت ﻣﻔﺗﺎﺣﯾﺔ :اﻟﺑرﻣﺟﯾﺎت اﻟﺟزﺋﯾﺔ ,اﻟوﻛﻼء ذاﺗﯾﺔ اﻟﺗﺄﻗﻠم ,اﻟﺗطﺑﯾﻘﺎت اﻟﻘﺎﺑﻠﺔ ﻟﻠﺗﺄﻗﻠم ,اﻟﺗطﺑﯾﻘﺎت اﻟﻣﻔﺗوﺣﺔ و اﻟﻣوزﻋﺔ, اﻟﺗﻧظﯾﻣﺎت ,اﻟﻣﺟﻣوﻋﺎت اﻟﻣﺑﮭﻣﺔ.
Tables des matières Introduction générale
Chapitre I : Applications distribuées, ouvertes et adaptables 1.1 Introduction 1.2 Développement d’applications distribuées 1.2.1 Problèmes liés au développement des applications distribuées 1.3 Ouverture et applications ouvertes 1.3.1 Environnement d’un système informatique 1.3.2 Ouverture d’un système informatique 1.3.3 Propriétés des applications ouvertes
1.3.3.1 Interopérabilités 1.3.3.2 Ajout et suppression d’éléments dans un système informatique ouvert 1.3.3.3 Contrôles d’accès dans un système informatique ouvert
1.4 Adaptabilité et applications adaptables 1.4.1 Première dimension : Dans quels buts adapte-t-on une application ? 1.4.2 Deuxième dimension : Sur quoi porte une adaptation ? 1.4.3 Troisième dimension : À quels moments peut-on adapter une application ? 1.4.4 Quatrième dimension : Qui décide l’adaptation d’une application ? 1.4.5 Cinquième dimension : comment mettre en œuvre l’adaptation d’une application ? 1.5 Synthèse sur le contexte du travail 1.6 Conclusion
5 6 6 8 8 9 9 9 10 11 12 13 14 14 15 15 17 19
Chapitre II : Composants logiciels et applications à base de composants 2.1 Introduction 2.2 Composants logiciels & génie logiciel basé composant 2.2.1 Différentes définitions du composant 2.2.2 Interfaces de composant 2.2.3 Contrats 2.2.4 Patterns 2.2.5 Framework 2.2.6 Récapitulation 2.3 Spécifications des composants logiciels 2.3.1 Spécifications fonctionnelles de composants 2.3.1.1 Spécifications syntaxiques 2.3.1.2 Spécification des aspects sémantiques 2.3.2 Spécifications des propriétés extra-fonctionnelles des composants 2.4 Catégorisation des composants logiciels 2.5 Modèles et technologies de composants logiciels 2.5.1 Le modèle de composant COM 2.5.2 Le modèle CCM 2.5.3 Le modèle Java Beans 2.5.4 Le modèle .Net 2.5.5 Le modèle Fractal 2.6 Adaptabilité des applications à base de composants 2.6.1 L’adaptation dans quelques modèles de composants
21 22 22 24 24 25 26 27 27 28 28 29 32 32 35 36 36 37 37 38 39 43
2.7 Synthèse 2.8 Conclusion
45 48
Chapitre III : Agents & Composants : Concepts, analyse comparative et apports mutuels 3.1 Introduction 3.2 Agents, agents mobiles et SMAs 3.2.1 Définitions d’un agent 3.2.2 Caractéristiques d’un agent 3.2.3 Typologie des agents 3.2.4 Les Systèmes Multi Agents (SMAs) 3.2.4.1 Types de systèmes multi agents 3.2.4.2 La négociation dans les systèmes multi agents 3.2.4.3 Organisation des systèmes multi-agent 3.2.4.4 La réorganisation des systèmes multi-agents 3.2.5 Les agents mobiles 3.2.5.1 Attributs d’un agent mobile 3.2.5.2 Caractéristiques d’un agent mobile 3.2.5.3 Types d’agents mobiles 3.2.5.4 Avantages des agents mobiles 3.2.5.5 Limites et inconvénients des agents mobiles 3.3 Analyse comparative des approches basées agent et celles basées composant 3.3.1 Agents vs composants par rapport au niveau d’abstraction 3.3.2 Agents vs composants par rapport au couplage entre entités 3.3.3 Composants et systèmes multi agents pour construire des systèmes ouverts 3.4 Apports mutuels entre approches basées agent et approches basées composant 3.4.1 Apports des agents et des SMA aux applications à base de composants 3.4.1.1 Agents et SMA pour assister pour la sélection des composants 3.4.1.2 Agents et SMA pour assister la mise en correspondance et l’assemblage de composants 3.4.1.3 Agents et SMA pour assister la reconfiguration dynamique de l’architecture d’une application à base de composants 3.4.1.4 Agentification des composants 3.4.2 Apports des composants aux agents et aux systèmes multi agents 3.4.2.1 L’environnement de développement de systèmes multi agents MAST 3.4.2.2 Le modèle d’agent MALEVA 3.4.2.3 Le modèle d’agent JavAct δ 3.4.2.4 Le modèle d’agent MaDcAr-AGENT 3.4.2.5 Le système M&M, la construction d’agents mobiles à base de composants 3.5 Synthèse sur les possibilités de combinaisons des composants, des agents et des agents mobiles 3.6 Conclusion
50 51 51 51 52 53 54 54 54 55 56 56 57 58 58 59 60 61 63 67 69 70 71 71 72 73 74 76 78 80 82 85 86 91
Chapitre IV : Développer des applications distribuées ouvertes et adaptables en combinant : composants logiciels, agents et agents mobiles
4.1 Introduction 4.2 En quoi les agents et les composants peuvent servir ? 4.3 Approche proposée : Construire des MASs sous l’angle d’organisations flexibles en utilisant des agents adaptatifs à base de composants 4.3.1 Organisations, Rôles et réorganisation
93 94 97 97
4.3.2 Vue d’ensemble 4.3.3 Éléments de base 4.3.3.1 Agent 4.3.3.1.1 Enveloppe logicielle 4.3.3.1.2 Architecture de l’agent 4.3.3.2 Rôles 4.3.3.2.1 Description comportementale des rôles 4.3.3.2.1.1 Protocoles et Types de sessions 4.3.3.2.1.2 Calcul de similarité comportementale entre rôles et agents 4.3.3.3 Groupes flous 4.3.3.3.1 Matrice de paramètres 4.3.3.3.2 Gestion des F-groupes 4.3.4 Gestion de l’adaptation 4.3.4.1 Adaptation au niveau organisation 4.3.4.2 Adaptation aux niveaux des agents 4.3.4.2.1 Sélection de composants 4.3.4.2.1.1 Aperçu sur les méthodes de sélection de composants 4.3.4.2.1.2 Solution proposée pour la sélection de composants 4.3.4.2.2 Réalisation des réassemblages de composants 4.4 Conclusion
101 103 103 104 105 107 108 109 110 114 117 118 124 125 126 126 127 128 134 136
Chapitre V : Une mesure floue multidimensionnelle des capacités des agents pour jouer des rôles. 5.1 Introduction 5.2 Ensembles flous 5.2.1 Sous ensembles flous 5.2.2 Caractéristiques d’un sous-ensemble flou 5.2.2.1 Fonction d’appartenance 5.2.2.2 Noyau 5.2.2.3 Cardinalité 5.2.2.4 Support et Hauteur 5.2.2.5 –coupe 5.2.3 Opérations sur les sous-ensembles flous 5.2.3.1 Egalité 5.2.3.2 Complément 5.2.3.3 Inclusion 5.2.3.4 La différence 5.2.3.5 Union 5.2.3.6 Intersection 5.3 Une Mesure floue des capacités des agents pour jouer les rôles 5.3.1 Construction des fonctions d’appartenance aux ensembles flous 5.3.2 Fonctions d’appartenance aux F-groupes d’agents 5.4 Choix et définitions des indicateurs de capacités pour les rôles 5.5 Conclusion
139 140 141 142 142 143 143 143 143 144 144 144 144 144 144 145 145 146 150 156 157
Chapitre VI : Etudes de cas : Applications et évaluation 6.1 Introduction 6.2 Premier exemple : Mesure de qualité de service dans un réseau
160 160
6.2.1 La qualité dans les réseaux informatiques
161
6.2.2 Conception d’un système simplifié pour la mesure de la qualité de service
161
6.3 Deuxième exemple : Un système de ventes aux enchères
163
6.3.1 Présentation et modélisation
163
6.3.2 Implémentation et expérimentations
167
6.3.2.1 La plate forme multi agents MadKit
168
6.3.2.1.1 Groupes et Rôles Sous MadKit
169
6.3.2.1.2 Agent sous MadKit
170
6.3.2.2 Aspects d’implémentations
171
6.4 Bilan
174
6.5 Conclusion
176
Conclusion générale Bibliographie
179 182
Table des figures Figure 1.1 : Machines distantes communiquant via des réseaux
6
Figure 2.1 : Composant logiciel
22
Figure 2.2 : Relations entre composant, interface, contrat, patterns et Framework
27
Figure 2.3 : Exemple de spécification d’un composant COM
29
Figure 2.4 : Mécanismes pour réaliser la substitution d’un composant par un autre
42
Figure 3.1 : Evolution du niveau d’abstraction en programmation
61
Figure 3 .2 : Agent vs composant par rapport aux liaisons et les sélections d’actions
66
Figure 3.3 : Architecture d’un agent MAST
77
Figure 3.4 : Architecture d’un agent MALEVA
79
Figure 3.5 : Le modèle d’agent JavAct δ
81
Figure 4.1 : Une schématisation simplifiée d’un système où 3 rôles sont joués
83
Figure 4.2 : Enveloppe logicielle
106
Figure 4.3 : Architecture proposée des agents
107
Figure 4.4 : Formalises, la grammaire engendrant le langage des types et les relations de sous typage
113
Figure 4.5 : Contenu d’un fichier de description du rôle auctionneer
115
Figure 4.6 : Une schématisation simplifiée de deux F-groupes
118
Figure 4.7 : Diagramme schématisant le processus d’obtention d’une autorisation pour jouer un rôle
121
Figure 4.8 : Contenu d’un fichier de description du rôle superviseurs d’un F-groupe d’agents auctionneers
122
Figure 4.9 : Vue d’ensemble d’un système où 3 rôles sont joués
129
Figure 4. 1O : Exemple de spécification de sonde
131
Figure 4.11 Macro algorithme explicitant l’activité de sélection de composants
132
Figure 4.12 : Contenu d’un fichier de description de composant
133
Figure 4.13 : Schématisation du moteur d’assemblage
134
Figure 4.14 : Assemblage de composants dans une enveloppe logicielle
136
Figure 5.1 : ensemble classique et ensemble flou
142
Figure 5.2 : Courbe à seuil
148
Figure 5.3 : Probabilité d’erreur sur le choix de l’élément frontière dans la courbe à seuil
148
Figure 5.4 : Fonction d’appartenance résultant de la méthode de Hisdal
149
Figure 5.5 : Exemple de fonction d’appartenance
149
Figure 6. 1: Vue d’ensemble d’un système de ventes aux enchères.
165
Figure 6.2 : Contenu de la description DCSUP1 du rôle superviseur du groupe Auctionneers
166
Figure 6.3 : Contenu de la description DC1 du rôle Auctionneer
167
Figure 6.4 : Utilisation de Madkit
171
Figure 6.5 : Une capture écran du système de ventes aux enchères
173
Introduction générale
Introduction générale
Depuis quelques années la conception et le déploiement d’applications ouvertes, distribuées et adaptables présentent de grands enjeux pour les chercheurs dans plusieurs branche de l’informatique. L’ouverture, la distribution et l’adaptabilité s’imposent de plus en plus comme caractéristiques importantes et essentielles dans plusieurs systèmes informatiques vu la popularisation de l’internet et des technologies Web ainsi qu’avec la progression de l’informatique ubiquiste du fait que la plupart des dispositifs qui nous entourent comme les téléphones mobiles sont équipés de moyens de traitement de l’information et de plus en plus dotés d’équipements de communication. Dans cette thèse nous abordons le développement d’applications ouvertes, distribuées et adaptables particulièrement en exploitants les technologies de composants logiciels, d’agents et d’agents mobiles. Nous allons exposer ci-dessous le contexte et les motivations nous ayant poussé à aborder cette problématique. Ensuite, nous détaillerons les objectifs ainsi que la démarche suivie et nous terminerons par la présentation de la structure du manuscrit. Le développement d’applications distribuées, ouvertes, et adaptables nécessite des moyens qui peuvent fournir des solutions solides et qui sont en mesure de répondre aux exigences ainsi qu’aux caractères spécifiques imposés sur les applications par les propriétés d’ouverture, de distribution et d’adaptation. La propriété de distribution impose qu’une application soit implémentée sous forme d’un ensemble d’entités logicielles et qui s’exécutent sur des machines distantes avec une distribution des computations et une décentralisation des ressources et des connaissances. Derrière cette distribution, se cachent plusieurs problèmes de taille à gérer. La propriété d’ouverture impose de son côté que les applications doivent obéir à des règles d’interopérabilité, de pouvoir changer de frontières par l’ajout (intégration) de nouvelles entités ou par la suppression (retrait) de quelques unes parmi celles qui la composent tout en assurant un contrôle sur les échanges entre les applications et leurs environnements. Quant à l’adaptation, cette propriété impose que les applications soient capables de réagir en s’adaptant en réponse à des besoins applicatifs ou pour être plus conformes avec les environnements d’exécution qui ne cessent de changer constamment. Les propriétés de distribution, d’ouverture et de d’adaptation ne sont pas totalement indépendantes les unes des autres. Par contre, les aspects couverts par chacune des propriétés sont fortement liés les uns aux autres. Le développement des applications informatiques s’inscrivant dans ce contexte mobilise différentes technologies. Parmi celles-ci, nous pouvons notamment citer la technologie des composants logiciels et celles des systèmes multi-agents. Ces deux technologies définissent le cadre de nos travaux. Les composants logiciels et les systèmes multi agents présentent 1
Introduction générale
actuellement deux approches de développement de logiciels très importantes et qui sont toutes les deux bien équipées de moyens et d’outils leurs permettant de contribuer considérablement dans le développement d’applications distribuées, ouvertes et adaptables. Les approches de développement à base de composants ainsi que celles basées agents proposent des abstractions pour organiser le logiciel sujet de développement en un ensemble d’entités logicielles dans le but de réduire la complexité, d’assurer une meilleure structuration du logiciel ainsi que pour mieux gérer son évolution. Dans le contexte décrit ci-dessus, nous sommes confrontés à des problèmes qui nous poussent à utiliser conjointement les composants et les d’agents (mobiles et non mobiles) à deux niveaux d’abstraction différents, programmation et conception. Malgré que les systèmes multi agents présentent des avancées technologiques par rapport aux composants, ces derniers préservent toujours quelques atouts incontournables. Particulièrement leurs capacités de structuration et de reconfiguration dynamique ainsi que la grande mise en valeur de la réutilisation. Deux questions fondamentales aiguillent nos travaux dans cette thèse : quelles sont les meilleures formes de combinaisons des composants logiciels, des agents et des agents mobiles pour développer des applications qui sont distribuées, ouvertes et adaptables ? Quelles sont les combinaisons qui permettent de tirer profit au maximum des avantages des deux paradigmes à savoir la structuration et la réutilisation du côté des composants et de tous les avantages découlant de l’utilisation des agents et des agents mobiles ? La communauté des chercheurs travaillant sur des problématiques liées au développement d’applications et des systèmes informatiques ou des problématiques du génie logiciel en général proposent des solutions dans lesquelles ils combinent souvent plusieurs éléments. Ces éléments peuvent être des techniques, des méthodes, des approches, des modèles et des paradigmes de conception et de programmation différents dans le but de tirer profit de plusieurs points forts caractérisant chacun de ces éléments d’un coté, et d’un autre côté faire compenser les limites et les faiblesses d’un élément par les caractéristiques avantageuses des autres éléments. Dans cette même tendance de combinaison s’inscrivent nos travaux de thèse. Ces travaux entreprennent l’étude et l’analyse des différentes possibilités de combinaison et du potentiel de fertilisation croisé entre les composants et les agents entant que deux approches de conception et de développement de logiciel ayant actuellement un grand impact. Ces deux approches proposent des abstractions pour organiser le logiciel comme une combinaison d’éléments logiciels, avec pour objectifs communs : réduire la complexité ; assurer une meilleure structuration du logiciel ; et de faciliter son évolution. Les systèmes multi-agents à l’aide de leurs capacités d’auto-organisation et d’utilisation de connaissances repoussent encore plus loin le niveau d’abstraction. Dans ce travail, nous défendons la thèse qu’un élément de solution intéressant pour aborder le développement d’applications distribuées, ouvertes, et adaptables, consiste à fournir une infrastructure à composants pour la construction et l’adaptation d’agents par 2
Introduction générale
assemblage de composants. Les agents ainsi construits font parties d’une société d’agents structurée selon une organisation flexible dans laquelle les agents appartiennent à des ensembles flous d’agents dans lesquels sont autorisés à opérer des tâches selon une mesure de leurs capacités effectives pour l’achèvement de ces tâches. La mesure des capacités des agents est une mesure floue multidimensionnelle, qui à partir des descriptions des composants constituant un agent, la mesure produit un indice de capacité de l’agent à l’ égard d’une tâche donnée exprimant au même temps le degré d’appartenance de l’agent à l’ensemble flou auquel il appartient. Les ensembles flous sont utilisés comme moyen de partitionnement de l’organisation que nous avons appelé groupes flous ou F-groupes permettant d’exploiter la notion d’appartenance partielle à un ensemble pour exprimer un passage graduel entre la situation de non capacité d’un agent à l’égard d’une tâche à la situation d’une capacité totale. Ces idées sont développées le long des chapitres IV et V dans lesquels nous présentons l’approche proposée pour développer des applications distribuées, ouvertes et adaptables dans la quelle nous combinons les composants logiciels et agents (mobiles et non mobiles). Mais bien avant ces deux chapitres, les trois premiers chapitres de ce manuscrit constituent un état de l’art selon la manière suivante : le premier chapitre est consacré pour présenter et définir les propriétés de distribution, d’ouverture et d’adaptabilité des applications en mettant l’accent sur les contraintes imposées et les difficultés à surmonter lors du développement d’applications caractérisées par de telles propriétés. Le deuxième chapitre fait l’objet d’une présentation de l’approche de développement par composants component-based development (CBD) et le génie logiciel à base de composants Component-based software engineering (CBSE) ainsi que la majorité des concepts en relation avec cette approche. Une attention particulière est prêtée pour l’adaptation et les possibilités de reconfiguration dynamique des applications à base de composants. Dans le chapitre trois, après avoir présenté d’une manière sommaire le paradigme agent, une analyse comparative entre les approches orientées composant et celles orientées agent est présentée. Ce chapitre dresse un état de l’art des approches dans les quelles les paradigmes composant et agent sont combinés tout en discutant les apports mutuels des composants et des agents. Pour la mise en valeur est l’évaluation de notre approche, deux études de cas ont été conduites et présentées dans le chapitre VI dans lequel nous présentons vers sa fin un bilan dans lequel nous évaluons l’approche proposée. Nous terminons ce manuscrit avec une conclusion dans laquelle nous résumons les contributions de cette thèse ainsi que ses limites et ses perspectives.
3
Chapitre I : Applications distribuées, ouvertes et adaptables
Applications distribuées, ouvertes et adaptables
Chapitre I : Applications distribuées, ouvertes et adaptables
1.1 Introduction Pour plusieurs raisons, comme la grande propagation de l’internet et des technologies Web ainsi que la présence de processeurs et de moyens de traitement de l’informations dans la majorité des équipements qui nous entourent, l’ouverture, la distribution et l’adaptation s’imposent comme caractéristiques ayants d’extrêmes importances dans les applications informatiques de nos jours. Noun nous intéressons au développement d’applications distribuées, ouvertes et capables de s’adapter en réponse à des besoins applicatifs ou pour être plus conformes avec les environnements d’exécution qui ne cessent de changer constamment. Dans ce premier chapitre nous présentons les caractéristiques liées à la distribution, l’ouverture et l’adaptation des applications d’une manière générale. Cette présentation servira de cadre pour étudier et situer plus particulièrement dans les deux chapitres qui suivent les apports dans le développement de telles applications des composants logiciels [164] et des agents [52], notamment mobiles [18], en tant que deux approches de développement ayant leurs impacts importants sur le développent de logiciels. Nous présentons en premier lieu un aperçu sur le développement d’applications distribuées; en deuxième lieu nous traitons la propriété d’ouverture ainsi que la manière dont elle est supportée dans différentes applications ; et en troisième position nous présentons l’adaptation des applications d’une manière générale et nous reviendrons sur l’adaptation des applications à base composants logiciels et à base d’agents dans le deuxième et le troisième chapitres en faisant une projection 5
Applications distribuées, ouvertes et adaptables
des concepts liés à l’adaptation présentés dans ce chapitre sur les applications à base de composants, celles basées agents et les applications dans lesquelles les deux approches sont combinées, tout en insistant également sur les caractéristiques de distribution et d’ouvertures. 1.2 Développement d’applications distribuées Le développement d’applications distribuées [159] partage beaucoup de points en commun avec le développement de n’importe quelles autres applications informatiques. La particularité à prendre en compte lors du développement de telles applications c’est que les composantes de ces dernières sont à exécuter sur des machines distantes les une des autres et qui communiquent via des réseaux (figure 1.1). Cette particularité fait des applications distribuées des applications plus complexes que les applications centralisée ; par conséquence, elles sont plus difficiles à concevoir, à implémenter et à tester. En outre, il est très difficile de maitriser les propriétés émergeantes de la distribution d’une application ou d’un système à cause de la complexité des interactions entre les composants et l’infrastructure du système. Malgré les difficultés liées à la distribution, cette propriété a ses impacts positifs sur les applications informatiques en mettant en avant des propriétés importantes tel que le partage de ressources, la concurrence, l’ouverture, l’extensibilité et la tolérance aux pannes.
Figure 1.1 : Machines distantes communiquant via des réseaux
1.2.1
Problèmes liés au développement des applications distribuées.
Les applications et les systèmes distribués sont caractérisés par leurs grandes complexités et par le caractère inhérent du non prédictibilité des services qu’ils fournissent. Cette complexité est due à l’impossibilité de la mise en œuvre de contrôles Top-Down du fait que les nœuds qui fournissent les services sont des systèmes indépendants qui n’obéissent pas à une seule autorité ainsi que les réseaux qui assurent les connexions entre les nœuds présentent eux même des systèmes indépendants gérés séparément des nœuds du système. Le développement des applications distribuées et plus particulièrement leurs conceptions s’articulent sur: la transparence, l’ouverture, l’extensibilité, la sécurité, les qualités de service et la gestion des pannes. La propriété de transparence est en relation avec la visibilité d’un système par ses utilisateurs. Un système distribué est dit transparent que s’il est vu par ses utilisateurs 6
Applications distribuées, ouvertes et adaptables
comme étant un seul système dont le comportement n’est pas affecté par la manière dont il est distribué. Cette propriété est très importante et fortement recommandée pour les applications distribuées. Mais, en pratique et pour plusieurs raisons il est impossible d’avoir des systèmes distribués complètement transparents. La principale raison consiste en l’impossibilité de la mise en œuvre d’un contrôle centralisé pour un système distribué et donc les différentes entités peuvent se comporter de manières différentes à différents moments. En outre, les contraintes liées aux réseaux d’interconnexion tel que les délais d’attentes et les localisations de certaines ressources sont inévitables et même par fois incontournables. Vu la difficulté, voire l’impossibilité, de développer des systèmes qualifiées de totalement transparents, il est utile de mettre les utilisateurs au courant de quelques aspects de distribution du système sur lequel ils travaillent pour qu’ils puissent comprendre quelques conséquences de la distribution comme les délais d’attentes et la perte de nœuds. Le développement d’applications et de systèmes distribués prend en charge généralement comme l’une des préoccupations essentielles la possibilité d’intégrer et de permettre l’interopérabilité de différentes entités ou composantes arrivants de différentes sources. Les aspects qui tournent au tour de cette préoccupation sont couverts par la propriété d’ouverture que nous présentons avec plus de détails dans la section 1.3. Concernant l’extensibilité, [121] cette propriété souvent liée à la distribution désigne les capacités d’une application pour ajouter plus de ressources suivant le nombre croissants des utilisateurs ; les capacités d’une application de répartir géographiquement ses composantes sans que cette répartition ait des influences négatives sur ses performances ; et finalement, les capacités d’une application de pouvoir gérer son extensibilité. La sécurité présente l’une des plus importantes problématiques liées au développement des applications distribuées où il est extrêmement difficile d’établir des politiques de sécurité sérieusement applicables à toutes les composantes d’une application vu que ces dernières peuvent faire parties de différentes organisations où des politiques et des mécanismes de sécurité non compatibles les uns avec les autres sont utilisés. Par rapport aux applications centralisées, les applications distribuées peuvent être attaquées par un nombre plus important de points et avec plusieurs manières. Les principaux types d’attaques que les applications distribuées peuvent être victimes sont [159] : l’interception des communications entre différentes composantes d’une application provoquant une perte de confidentialité ; le bombardement d’un nœud par des fausses requêtes empêchant ce dernier de traiter les requêtes valides et fournir les services attendus ; le changement des données et des services d’une application ; et finalement, les attaques par la génération de fausses informations utilisables pour atteindre quelques privilèges comme la génération de mots de passe permettant l’accès à des données, des services et des ressources inaccessible sans avoir d’autorisations. La qualité des services fournis par une application distribuée reflète sa capacité de fournir d’une manière fiable et dans des délais de réponse acceptables ses services [159]. Lors du développement d’une application distribuée les besoins en termes de qualités de services 7
Applications distribuées, ouvertes et adaptables
doivent être spécifiés avant sa conception pour que cette dernière soit conçue de sorte à prendre en compte les qualités quelle doit assurer quand elle offre ses services. Un point plus important à prendre en compte lors du développement d’une application distribuée c’est que les dégradations et les pannes sont inévitables et que l’application doit résister dans les situations pareilles. En pratique, on ne peut pas assurer une bonne qualité de service à tout moment, il y a des situations où le nombre de requêtes atteint un pic et pour assurer une bonne qualité de service l’application nécessite plus de ressources dont elle n’exploite pas la plupart du temps. Dans ce cas, on accepte une dégradation de la qualité de service que d’investir dans des ressources qui seront sous exploitées. La qualité de service devient critique dans le cas où l’application à développer traite des données de type vidéo ou audio ou toutes autres données critiques. Dans ces circonstances, l’application doit préserver une qualité de service haut delà du seuil toléré sinon, les vidéos ou les sons seront dégradés. 1.3 Ouverture et applications ouvertes La propriété d’ouverture dans les systèmes informatiques acquit de plus en plus d’importance en présentant une problématique fortement abordée dans plusieurs travaux de recherches. La notion d’ouverture dépend étroitement de la nature de la relation d’un système informatique avec son environnement. Les systèmes informatiques regroupent un ensemble de moyens humains (concepteurs, programmeurs, utilisateurs, ...) et un ensemble de moyens techniques qui regroupent des ressources matérielles (serveur, routeur, ...) et des logiciels (système d’exploitation, SGBD,…). Ces éléments sont en interactions permanentes, et leurs principales fonctionnalités sont de traiter, stocker, acheminer ou présenter de l’information. L’environnement d’un système informatique est constitué d’autres systèmes qui l’entourent et qui regroupent à leurs tours des éléments de types matériels, logiciels et humains. 1.3.1
Environnement d’un système informatique
D’une manière générale, un environnement peut être vu comme étant ce qui entoure quelque chose. L’environnement d’un système informatique est définit par Van Gigch [168] comme tout autre système sur lequel les mécanismes de décision du système n’ont pas de contrôle. Selon cette définition, nous pouvons traiter un environnement d’un système comme étant tout ce qui est en dehors de celui-ci et n’est pas sous son contrôle. Les échanges entre un système informatique et son environnement sont principalement les transmissions d’informations à traiter ou traitées. Les influences réciproques entre un système et son environnement sont répertoriées en deux classes [172]. La première concerne les données échangées alors que la seconde concerne les modifications des frontières du système. Les données échangées entre un système et son environnement regroupent les données introduites dans le système par les éléments de l’environnement et celles que le système génère à destination de son environnement. Les modifications des frontières du système peuvent être
8
Applications distribuées, ouvertes et adaptables
des extensions de frontières suite à l’intégration de certains éléments de son environnement, ou des restrictions de frontière par abandon de certains de ses éléments.
1.3.2
Systèmes informatiques ouverts
La définition de l’ouverture d’un système repose sur la notion de l’environnement. A l’opposé d’un système ouvert, un système fermé n’a pas d’environnement. Par conséquence, il n’a pas d’échanges avec des systèmes extérieurs et son état n’est influencé que par ses propriétés et ses conditions initiales [172]. L’étude de l’ouverture dans les systèmes consiste donc à définir les moyens d’établir et gérer les échanges que peut avoir un système avec les autres systèmes de son environnement. Il s’agit de définir la nature des échanges : échanges de messages (communication), les données échangées, les supports et flux d’échanges ainsi que les impacts des échanges (stabilité, adaptation, fiabilité). De cet effet, un système ouvert peut être défini comme un système situé dans un environnement et qui interagit, communique et faisant des échanges aves d’autres systèmes de son environnement. En d’autres termes, un système ouvert est un système qui fournit des avantages en interopérabilité, portabilité, et standards ouverts de logiciels ; ou configuré pour permettre des accès non restreints par des personnes et/ou des ordinateurs [93]. L’interopérabilité définit la capacité d’échange des données et services entre systèmes ; La portabilité concerne la capacité et la facilité d’intégration d’un système informatique dans un autre, ce qui est rapporté à la problématique d’extension d’un système par l’intégration d’autres systèmes de son environnement ; par l’utilisation de standards ouverts il est visé de faciliter la modification des logiciels utilisés de façon à ce qu’ils puissent mieux répondre aux besoins d’un système ; Les accès non restreints de personnes et/ou d’ordinateurs dépendent des applications et/ou des systèmes. 1.3.3
Propriétés des applications ouvertes
En analysant et faisant correspondance entre toutes les définitions de l’environnement et d’ouverture de systèmes présentées dans les deux sections précédentes, nous pouvons constater que les propriétés suivantes caractérisent un système informatique ouvert : l’interopérabilité, l’ajout / la suppression d’éléments, et le contrôle d’accès. 1.3.3.1 Interopérabilité La propriété d’interopérabilité résume et traduit le besoin de faciliter les interactions entre un système et d’autres systèmes de son environnement. Ces interactions sont des accès aux fonctionnalités d’autres systèmes ainsi que des d’échanges d’informations. Un autre point qui est concerné par l’interopérabilité consiste à faciliter et pouvoir utiliser les informations échangées [37]. Pour arriver à répondre à ces besoins il est nécessaire d’avoir des structures
9
Applications distribuées, ouvertes et adaptables
et des interfaces précises pour la représentation et l’échange de données. A cet égard, on distingue dans la littérature trois niveaux d’interopérabilité [42] : un niveau syntaxique qui concerne le format de représentation des données et des connaissances, un niveau structurel qui fait référence à l’organisation de l’information ; et un niveau sémantique qui prend en charge l’interprétation des représentations relativement à un domaine. Pour garantir l’interopérabilité entre différents systèmes développés par des firmes et des développeurs différents, les développeurs répondent à des consortiums de standardisation et de normalisation tel que ISO ou ANSI pour développer les interfaces de leurs systèmes ainsi que pour structurer les données échangées. Une norme est une règle fixant les conditions de la réalisation d’une opération, de l’exécution d’un objet ou de l’élaboration d’un produit dont on veut unifier l’emploi ou assurer l’interchangeabilité [93]. Les normes n’imposent pas la façon dont les fonctionnalités d’un système sont conçues et développées dans son architecture interne, elles ne définissent que les objectifs des fonctionnalités, leurs données respectives d’entrée et de sortie et les interfaces d’interopérabilités. L’interopérabilité peut être mieux illustrée à travers Internet. Dans ce réseau géant les informations transitent d’un réseau à un autre via des routeurs fabriqués généralement par des constructeurs différents. L’utilisation des protocoles standards de transport et de transmission de données tel que TCP/IP permet à tout routeur quelque soit son constructeur et indépendamment de ses mécanismes de fonctionnement de pouvoir envoyer et recevoir des données provenant de tout autres routeurs. L’interopérabilité est garantie par des normes qui couvrent toutes les étapes du processus d’échange d’informations entre systèmes comme les normes de codage de caractères tel que UTF-8, les normes de représentation structurée des données tel que XML et RDFS et Les normes de transport internet et de transmission des données tel que TCP/IP et HTTPS. En pratique, il n’existe pas de normes pour toutes les applications existantes, et qui sont sensées de régir toutes leurs interactions avec tous les systèmes avec lesquels elles sont susceptibles d’interagir. Ainsi, dans le cas d’absence de normes ou dans le cas de l’impossibilité de leurs utilisations, les constructeurs et développeurs de systèmes décrivent eux-mêmes et mettent à la disposition de leurs environnements les représentations des données échangeables ainsi que les interfaces d’interaction de leurs produits matériels et logiciels. Malgré son importance, l’interopérabilité ne peut suffire à elle seule pour répondre à tous les besoins de la problématique de l’ouverture. Spécifiquement, les besoins relatifs à l’intégration de nouveaux éléments dans un système ou la suppression d’une ou de plusieurs composantes d’un système.
1.3.3.2 Ajout et suppression d’éléments dans un système informatique ouvert
10
Applications distribuées, ouvertes et adaptables
L’ajout et la suppression d’éléments dans un système informatique ouvert présentent les propriétés prépondérantes de l’ouverture. L’ajout d’une nouvelle entité dans un système informatique implique que ce dernier dispose de mécanismes d’entrée et d’intégration. L’intégration d’une entité dans un système référence l’aptitude des fonctionnalités de cette dernière d’être explicitement identifiables et que cette nouvelle entité peut interagir avec les autres entités du système. La suppression d’une entité dans un système informatique suppose que celui-ci dispose de mécanismes pour gérer la sortie d’entités. Le fait d’ajouter ou de retirer des entités d’un système peut remettre en cause son bon fonctionnement. Généralement les entités d’un système ont des fonctionnalités complémentaires, le retrait d’une entité peut provoquer une instabilité dans le fonctionnement d’autres entités et par conséquence dans tout le système. De même, l’arrivé d’une nouvelle entité dans un système nécessite une certaine coordination avec celles déjà existantes pour maintenir le bon fonctionnement de ce dernier. La propriété d’ajout et de suppression d’éléments est présente dans plusieurs applications réelles comme ApacheFelix [10] qui présente une implémentation de la spécification OSGI [132 ]. ApacheFelix dispose d’une architecture modulaire de composants appelés bundles et qui sont des classes Java qui implémentent des services ; qui peuvent être ajoutés ou supprimés avant ou pendant l’exécution. Le registry d’une implémentation OSGI détecte automatiquement l’ajout de nouveaux bundles et donc de leurs services ainsi que la suppression de services suite à la suppression de(s) bundle(s) correspondants. La propriété d’ouverture des systèmes et des applications présente un support naturel pour gérer l’adaptation de ses derniers, l’ajout et la suppression d’entités d’un système met en avant les possibilités d’extension de ce dernier et qui présente un volet important pour la distribution des applications déjà présentée ainsi que pour les possibilités d’adaptation et d’enrichissement des fonctionnalités d’un système. Nous reviendrons en détails sur l’adaptation dans une prochaine section de ce chapitre. Similairement à la propriété d’interopérabilité, les mécanismes liés aux ajouts et aux suppressions d’entités ont besoin de standardisation, sinon les systèmes se trouvent devant l’obligation de fournir explicitement aux systèmes de leurs environnements les types et les représentations des donnés ainsi que les interfaces qui permettent d’un côté d’ajouter et d’intégrer de nouvelles entités et d’un autre côté de supprimer et retirer des entités du système. L’interopérabilité ainsi que les ajouts et suppressions d’entités dans des systèmes informatiques ouverts nécessite encore l’intégration de mécanismes pour assurer la stabilité et la robustesse des systèmes que nous présentons dans la section suivante.
1.3.3.3 Contrôles d’accès dans un système informatique ouvert 11
Applications distribuées, ouvertes et adaptables
Le contrôle présente le troisième volet couvert par la propriété d’ouverture. Ce volet présente une sorte de régulation pour s’assurer du bon déroulement d’échanges entre un système et son environnement. Le contrôle peut être étendu sur le fonctionnement du système pour s’assurer que tous les éléments constituant ce dernier accomplissent correctement leurs rôles, c'est-à-dire s’assurer que les ressources matérielles, les entités logicielles et les intervenants humains agissent correctement en réalisant les traitements, les stockages, l’acheminement et la présentation de l’information. Ce contrôle est très important vu que les interactions ainsi que l’ajout d’entités peuvent avoir des influences malveillantes aux systèmes ainsi qu’aux leurs environnements. Ces influences justifient pour quoi souvent ce point est abordé d’un point de vu sécurité où l’accent est mis sur l’intégrité et la fiabilité des informations échangées entre le système et son environnement ainsi que sur l’accessibilité ou la confidentialité des informations et des ressources. La mise en œuvre de mécanismes permettant d’atteindre ses finalités vont de la gestion des droits d’accès au cryptage des donnés en passant par la surveillance du système et tout autres moyens pouvant intervenir à cet égard. Dans un système ouvert il est préférable d’avoir une gestion décentralisée du contrôle, c'est-à-dire, plusieurs entités de contrôle interviennent dans cette gestion. En effet, comme toutes solutions centralisées, une gestion de contrôle centralisée dans une seule entité met en cause la robustesse et la fiabilité du système particulièrement dans les cas de défaillance de l’entité de contrôle ou dans les cas de surcharge de cette dernière. La gestion de l’ouverture dans les systèmes informatiques prend des formes différentes et varie selon les approches et les paradigmes de conception et de développement utilisés. Chacun des aspects de l’ouverture constitue un domaine de recherche dont nous ne pouvons pas faire une étude exhaustive dans cette thèse. Nous nous intéressons aux approches de développement à base de composants logiciels et à celles basées agents et agents mobiles. Nous reviendrons sur l’ouverture dans les approches à base de composants et les systèmes multi agents dans les deux prochains chapitres. 1.4 Adaptabilité et applications adaptables La problématique de l’adaptation des applications et des systèmes informatiques n’est pas nouvelle, depuis très longtemps cette problématique est abordée et faisait jusqu'à nos jours sujets de plusieurs travaux de recherches. La propriété d’adaptation est aperçue sous plusieurs différents angles et traitées avec une grande diversité de manières et de méthodes qui se sont déployées autour de l’auto-organisation, les systèmes intégrant des facultés d’apprentissage, les systèmes dynamiques, la reconfiguration logicielle, les mécanismes et techniques bioinspirées, les métaphores des organisations collectives, …etc. cette diversité rend la comparaison entre les différents travaux sur l’adaptation une tache très difficile et ardue. Le 12
Applications distribuées, ouvertes et adaptables
besoin d’adaptation des logiciels s’impose d’un côté du fait qu’il est très souvent qu’un logiciel ne corresponde pas totalement à ses spécifications ou les spécifications initiales d’un logiciel ne soient plus pertinentes après plusieurs mois d’utilisation, ou même pendant sa réalisation. D’un autre côté, les environnements dans lesquels les applications sont exécutées présentent, une hétérogénéité importante, une grande variabilité et de nombreuses possibilités d'évolution aussi bien au niveau des moyens d'exécution que des moyens de communication. Cette adaptation d’une application est vue comme l’aptitude de cette dernière de se conformer à des conditions nouvelles ou différentes. L’adaptation correspond au processus de modification d’un système, nécessaire pour permettre un fonctionnement adéquat de ce dernier dans un contexte donné [98]. Le terme adéquat signifie que le système correspond parfaitement à ce que l'on attend dans un contexte précis. Devant ce changement de conditions on distingue deux situations différentes, la première situation présente le cas où les changements sont déjà prévus alors une étape de reconfiguration du logiciel peut répondre aux besoins d’adaptation. Le deuxième cas où le changement des conditions n’a pas été prévu, alors il faut adapter le logiciel en modifiant une partie ou même sa totalité. L’intégration de la problématique de l’adaptation dans le cycle de vie du logiciel semble très utile [147] spécialement pour diminuer les couts de modifications à porter sur le logiciel pour l’adapter. L'adaptabilité d’une application repose essentiellement sur le fait que cette dernière soit constituée d’entités séparables, c'est-à-dire l’application doit être décomposable et composable. Un système monolithique ne peut être modifié qu'en le remplaçant intégralement ; dans un système construit sous forme d’entités logicielles interconnectées, il est possible de modifier ou de remplacer certaines parties d’une application tout en minimisant les interférences avec le reste des parties. La décomposabilté reflète une mesure de la séparation des éléments qui constituent une application, alors que la composabilité reflète la mesure des capacités d'assemblage entre ces éléments. La granularité de la composition peut être plus ou moins fine et le couplage entre les différentes entités logicielles plus ou moins faible. Les entités constitutives d’une application peuvent prendre différentes formes selon le contexte technique de la réalisation de l’application et peuvent être des modules, des classes, des composants, des aspects, des services ainsi que plusieurs autres formes possibles. L’adaptabilité repose aussi sur une autre caractéristique très importante, il s’agit de la capacité d'une application à s'observer et donc à répondre à des questions sur son état. Cette propriété que l’on appelle introspection est essentielle particulièrement pour l'adaptation de systèmes complexes. L’adaptabilité des applications concerne différentes dimensions, plusieurs études comme [67] et [152] ont permis d’identifier les axes autour de lesquels tourne cette notion d’adaptation qui ce déroule généralement en trois phases : le déclenchement, la décision et la réalisation. Chaque axe représente une réponse pour l’une des questions suivantes : Dans quels buts adapte-t-on une application ? Sur quels éléments de l’application peut porter une adaptation ? À quels moments peut-on adapter une application ? Qui décide d’adapter une application ? Comment réaliser l’adaptation d’une application ? Toutes ces dimensions 13
Applications distribuées, ouvertes et adaptables
peuvent servir de critères pour mesurer le degré d’adaptabilité d’une application et par la suite donner un certain pouvoir pour comparer l’adaptabilité de différents systèmes. 1.4.1
Première dimension : Dans quels buts adapte-t-on une application ?
À partir de plusieurs travaux comme [89] et [67] nous pouvons définir et extraire les raisons pour les quelles une application est amenée à subir à des adaptations. Généralement la communauté des chercheurs dans ce domaine semble d’accord sur la définition de quatre types d’adaptations qui se distinguent par des motivations différentes tout en notant que ces différents types ne sont que des points de vue et qu’ils ne sont pas exclusifs : l’adaptation corrective, l’adaptation adaptative, l’adaptation évolutive et l’adaptation perfective. Adaptation corrective : le but de l’adaptation est de corriger les erreurs de fonctionnement d’une entité au sein de l’application. Adaptation adaptative : le but de l’adaptation est de faire évoluer l’application en fonction d’un changement de contexte (nouveau système d’exploitation par exemple). Adaptation évolutive : ajouter des fonctionnalités à cause de l’évolution des besoins du client. Adaptation perfective : L’objectif est d’optimiser les performances de l’application. Pour ce faire, on peut améliorer le comportement de certaines parties de l’application pour résoudre une tâche plus efficacement. 1.4.2
Deuxième dimension : Sur quoi porte une adaptation ?
On peut apercevoir un système logiciel comme une architecture composée d’un ensemble d’éléments reliés entre eux. Une adaptation peut donc porter sur un élément, sur une liaison entre deux éléments ou bien sur l’architecture entière. L’adaptation d’un élément peut aller d’un simple paramétrage à une transformation complète. Par un élément on désigne une partie d’un système qui peut s’agir d’une fonction, d’une classe, d’un composant, ou toutes autres entités logicielles. Pour une liaison, l’adaptation consiste à modifier la nature de la liaison ou de l’appliquer sur d’autres couples d’éléments, par exemple, remplacer un lien d’héritage par un lien de délégation. Au niveau de l’architecture, l’adaptation consiste à ajouter, supprimer ou remplacer un élément ou une liaison ; comme il peut s’agir d’un redéploiement qui consiste à modifier la répartition d’un système logiciel sur un environnement d’exécution matériel composé d’un ou de plusieurs sites de déploiement. 1.4.3
Troisième dimension : À quels moments peut-on adapter une application ?
L’adaptation d’une application peut être effectuée à des moments différents et qui recouvrent toutes les étapes de son cycle de vie. L’adaptation peut être une adaptation statique et qui concerne dans ce cas que les étapes d’analyse, de conception et 14
Applications distribuées, ouvertes et adaptables
d’implantation. Par exemple, Les modifications des spécifications d’un élément qui est en cours de développement engendrent une adaptation statique de son implantation. Nous parlons d’une Adaptation semi-dynamique pour désigner l’adaptation qui peut apparaître à l’étape de déploiement de l’application. Dans ce cas, on s’intéresse au processus d’installation de l’application. Des opérations d’adaptation peuvent avoir lieu pendant que le processus d’installation de l’application est en cours. En effet, lorsque le contexte de déploiement d’une application n’est pas totalement connu à l’avance, il doit être découvert dynamiquement au moment du déploiement [152]. En dernier, l’adaptation est dite Adaptation dynamique : puisque elle intervient lors de la phase d’exécution de l’application. Les modifications dynamiques permettent de satisfaire les besoins les plus tardifs. Par exemple, lors d’un changement de contexte d’exécution comme dans le cas d’une faible quantité de batterie sur un dispositif mobile, il est souhaitable d’économiser de l’énergie par arrêter certains services facultatifs, l’adaptation consiste alors à réorganiser l’architecture logique de l’application pour minimiser les aspects gourmands en ressources. Les opérations d’adaptation dynamique doivent être optimisées. Ainsi, l’effort à faire pour optimiser les opérations d’adaptation peut être de plus en plus grand lorsqu’on se place dans des systèmes à fortes contraintes comme les applications temps-réel. Il est important de noter qu’il existe des applications critiques qui doivent s’exécuter de manière continue car elles doivent être disponibles à tout moment. Dans ces cas, il faut envisager d’adapter dynamiquement ces applications. Il existe encore d’autres cas où les adaptations doivent être faites sans arrêter l’application concernée par les adaptations. Par exemple, dans les cas d’applications dont les environnements d’exécution changent constamment, il est inadapté d’arrêter les applications à chaque modification ; de même pour les applications dont l’arrêt est coûteux pour les entreprises. 1.4.4
Quatrième dimension : Qui décide l’adaptation d’une application ?
L’adaptation d’applications est un processus qui se déroule en plusieurs étapes. Chacune de ses étapes fait intervenir des acteurs particuliers. Plusieurs acteurs humains ou logiciels peuvent intervenir pour déclencher le processus de l’adaptation. Si le concepteur de l’application a anticipé l’adaptation, l’application peut initier sa propre adaptation automatiquement sans intervention humaine. Dans ce cas des entités logicielles par exemple des composants ou des capteurs physiques peuvent jouer ce rôle d’initiateur d’adaptation, ceci devient possible si les critères de déclenchement de l’adaptation sont clairement identifiés et donc facilement automatisables. Ce genre d’adaptation déclenchée automatiquement figure bien dans applications dites autonomiques ou auto-adaptatives [120] et les applications sensibles au contexte où par exemple en fonction d’une position géographique un capteur physique peut déclencher le processus d’adaptation. Dans l’autre côté, le déclenchement d’une adaptation est initié par un acteur humain qui peut être l’un des principaux acteurs du cycle de vie d’un logiciel, c'est-à-dire, le concepteur, le développeur et l’administrateur. 15
Applications distribuées, ouvertes et adaptables
1.4.5
Cinquième dimension : comment mettre en œuvre application ?
l’adaptation d’une
Il existe plusieurs approches pour réaliser l’adaptation d’une application, les comparaisons entre ces approches peuvent s’effectuées selon plusieurs critères : selon les étapes du processus d’adaptation ; par rapport aux techniques utilisées ; et selon la qualité du processus d’adaptation en mettant l’accent sur les garanties à obtenir en contrôlant le processus d’adaptation. Les techniques d’adaptation peuvent être basiques comme un simple re-paramètrage ou une reconfiguration à condition que l’adaptation soit anticipée. Dans ce cas, le système à adapter est construit selon un ensemble de paramètres prédéfinis dont les valeurs peuvent être spécifiées après la construction du système. Toujours dans le cas d’adaptation anticipée, celle-ci peut être réalisée par la transformation de code portant sur le code source ou sur du « bytecode » comme il est fait dans les travaux de Hnetynka [77]. Dans l’autre direction où les adaptations sont non anticipées, il existe plusieurs approches qui permettent l’adaptation à un haut niveau. Parmi ces approches on note l’existence d’approche qui se base sur La capacité d'un système à s'observer et donc à répondre à des questions sur son état. Cette propriété est considérée comme essentielle pour l'adaptation de systèmes complexes. La réflexion [143] peut servir d’exemple pour ce genre d’adaptation, il s’agit d’une technique permettant à un logiciel de s’auto-représenter et de s’auto-manipuler. Ce mécanisme est utilisé pour programmer de manière générique en manipulant le code de base d’une application. La programmation par aspects (AOP) [54] présente une autre alternative pour faire des adaptations de haut niveau, c’est un mécanisme permettant de réaliser des opérations transversales sur le code métier d’une application ou sur son code technique. Cette technique a pour objectif la réalisation d’adaptation évolutive de logiciels [102], elle également utilisée pour l’adaptation d’applications à base de composants. Les techniques utilisées pour mettre en œuvre l’adaptation aux niveaux d’applications informatiques peuvent aussi être catégorisées par d’autres critères autres que le bas et le haut niveau. Une classification peut se faire selon l’élément sur lequel agit le processus d’adaptation. Selon cette vision, on a des techniques qui agissent sur les liaisons reliant les différent éléments d’une application, et d’autres techniques qui se contentent d’agir sur les éléments ou les composantes de l’application ainsi que d’autres techniques qui agissent sur l’architecture logicielle d’une application. Les techniques de mise en œuvre de l’adaptation qui situent les modifications au niveau des liaisons sont répertoriées en deux classes, celles où l’adaptation consiste à modifier la nature de la liaison et les techniques où l’adaptation consiste à appliquer la liaison sur d’autres couples d’éléments. Parmi les techniques de la première classe on peut citer l’interposition. Il s’agit d’une technique utilisée dans le cas des liaisons dites Blanches signifiant des liaisons sur lesquelles on peut effectuer des modifications. Par exemple le 16
Applications distribuées, ouvertes et adaptables
concept de fabrique de liaisons proposé dans [49] permet d'adapter les liaisons. Une autre bonne raison pour s’intéresser aux liaisons blanches c’est le pouvoir de contourner le problème d'adaptation des boîtes noires, c'est-à-dire, les éléments intégrés dans une application dont on n’a pas les détails d’implémentation. Pour la deuxième classe on peut citer comme exemple des travaux basés sur la technique de délégation [2] où le travail d'une entité est délégué vers une autre. La mise en place d'une délégation revient à générer une autre liaison, mais celle-ci peut être perçue comme une extension et donc une adaptation de la liaison initiale. Pour les techniques d’adaptation qui agissent sur les éléments ou les entités du système sans toucher aux liaisons, l’adaptation consiste à modifier l’état d’une entité ou son code. Le changement d'interface sans changement du code est considéré comme du changement de liaisons. Les techniques de transformation de code déjà citées appartiennent à cette catégorie de travaux. Ces techniques consistent à modifier directement le code d’une entité. La modification de cette dernière est seulement possible quand celle-ci est blanche. La transformation peut être faite manuellement ou réalisée par des technologies comme le tissage d'aspects [92] dans la programmation dite par aspects et qui vise à permettre une séparation des différentes préoccupations des programmeurs face à la réalisation d'un programme. Dans ce paradigme de programmation, il est possible d'implémenter des comportements s'entrelaçant avec le reste du système d'une manière modulaire. La programmation par aspects s'attache tout particulièrement à permettre d’un côté l'expression séparée des parties techniques et des parties fonctionnelles des applications. D’un autre côté, plusieurs récents travaux se sont intéressés à décomposer également les parties fonctionnelles. L'entrelacement entre les aspects, aussi nommé tissage (weaving), qui s’appuis sur la manipulation des points de jonctions est aux cœurs de plusieurs approches qui présentent la particularité de permettre la manipulation (ajout, retrait ou re-ordonnancement) des aspects de façon dynamique, autorisant ainsi une adaptation en fonction de l'environnement. Les travaux qui s'intéressent à l'adaptation de l'architecture complète, sont basés sur des procédures de configuration et de reconfiguration. Cette activité consiste en une composition et recomposition d’éléments ou composantes à l'intérieur de l'architecture. Cela peut donc être réalisé soit par retrait, remplacement, paramétrage de certaines entités et/ou liaisons, soit par ajout de nouvelles entités. 1.5 Synthèse sur le contexte du travail Noun nous somme intéressés dans nos travaux au développement d’applications distribuées, ouvertes et capables de s’adapter en réponse à des besoins applicatifs ou pour être plus conformes avec les environnements d’exécution qui ne cessent de changer constamment. Le développement de telles applications nécessite des moyens qui peuvent fournir de réelles solutions en vue de répondre aux caractères spéciaux imposés sur les applications par les 17
Applications distribuées, ouvertes et adaptables
propriétés de distribution, d’ouverture et d’adaptation. Par le terme moyens nous désignons techniques, approches, méthodes, langages de programmation et tout autres supports qui peuvent servir pour produire des éléments de solutions pour le développement d’applications distribuées, ouvertes et adaptables. Les propriétés de distribution, d’ouverture et d’adaptation chacune de son côté, imposent des caractères et des contraintes spécifiques sur les applications sujets de développement. La distribution impose que les applications soient implémentées sous formes d’entités ou de composantes qui s’exécutent sur des machines distantes les unes des autres avec une distribution de computation et une décentralisation des ressources et des connaissances. Le développement d’applications distribuées et plus particulièrement leurs conceptions s’articulent sur: la transparence, l’extensibilité, la sécurité, les qualités de service et la gestion des pannes pour maitriser leurs complexité ainsi que les phénomènes émergeants du à la distribution. L’ouverture de son côté impose sur une application d’être situées dans un environnement où elle interagit, communique et faisant des échanges aves d’autres systèmes de son environnement ; d’obéir à des règles d’interopérabilité et d’avoir l’aptitude de changer les frontières par l’intégration de nouvelles composantes ou par retirer des composantes parmi celles qui la constituent. La prise en compte de l’adaptabilité des applications comme une préoccupation essentielle influence fortement leurs développements, particulièrement, si la problématique de l’adaptation est intégrée dans le cycle de vie du logiciel. Cela permet de diminuer les coûts de modifications à porter sur le logiciel pour l’adapter. L’adaptation correspond au processus de modification nécessaire pour permettre un fonctionnement adéquat d’une application dans un contexte donné. Les modifications à porter sur une application en vue de son adaptation peuvent être situées dans un espace définit par les cinq repères suivants : Dans quels buts adapte-t-on une application ? Sur quels éléments de l’application peut porter une adaptation ? À quels moments peut-on adapter une application ? Qui décide d’adapter une application ? Comment réaliser l’adaptation d’une application ? Devant le changement de contexte on distingue deux situations différentes, la première situation présente le cas où les changements sont déjà prévus alors une étape de reconfiguration du logiciel peut répondre aux besoins d’adaptation. La seconde situation présente le cas où le changement des conditions n’a pas été prévu, alors il faut adapter l’application en modifiant une partie ou même sa totalité. Les propriétés de distribution, d’ouverture et d’adaptation ont été abordées soit séparément les unes des autres soit abordées toutes ensembles par les chercheurs en génie logiciel, en systèmes distribués et même en intelligence artificielle selon plusieurs différentes manières et sous différents angles de visions où à chaque fois l’accent est mis sur un aspect particulier de la distribution, de l’ouverture ou de l’adaptabilité. Le développement d’applications distribuées, ouvertes et adaptables est abordé dans plusieurs approches appartenant à des paradigmes de développement différents tel que les architectures logicielles [103], les services [112], les composants [164], les agents [52], les agents mobiles [18], les systèmes multi-agents [52], les approches connexionnistes basées sur l’émergence [90] ou
18
Applications distribuées, ouvertes et adaptables
plusieurs autres paradigmes, ainsi que dans les approches dans lesquelles plusieurs de ces paradigmes sont combinés. Chacun des paradigmes de développement propose des supports qui peuvent être exploités pour développer des éléments de solutions pour un ou plusieurs problèmes relatifs à la distribution, l’ouverture ou l’adaptation. Comme exemples, les composants logiciels [164] et les systèmes multi-agents [52] proposent la structuration du logiciel sous forme de combinaisons de plusieurs entités logicielles ; cette structuration présente un support naturel pour la distribution des applications. Les mécanismes de reconfiguration dynamique d’architectures logicielles qu’on trouve dans plusieurs approches centrées sur l’architecture logicielles peuvent servir de support pour mettre en œuvre des applications adaptables. L’interopérabilité qui présente l’un des volets de l’ouverture trouve des supports dans les interactions agents – agents qui sont abordées avec le développement de langages de communication comme KQML [55] et ACL [56] et qui permettent aux agents de pouvoir échanger des messages tout en conservant leurs propres architectures. Les exemples de supports offerts par les différentes approches et paradigmes sont encore nombreux. Nous nous sommes intéressé dans nos travaux aux supports offerts par les approches de développement à base de composants logiciels [164] et ceux offerts par les approches à base d’agents, particulièrement mobiles. Nous envisageons trouver une bonne combinaison entre ces deux paradigmes pour qu’on puisse proposer de bonnes solutions pour la majorité des points sur lesquels s’articule le développement d’applications distribuées, ouvertes et adaptables. 1.6 Conclusion Dans ce chapitre, nous avons tenté de faire un aperçu sur les applications distribuées, ouvertes et adaptables ainsi que les difficultés à rencontrer lors du développement de telles applications. Dans cet aperçu ont été identifiés tous les éléments autour desquels s’articule le développement d’applications distribuées, ouvertes et adaptables ainsi que toutes les particularités imposées par les propriétés de distribution, d’ouverture et d’adaptation. Les composants logiciels, les agents, les agents mobiles et les systèmes multi agents se présentent comme solutions et contribuent chacun de son côté dans le développement d’applications distribuées, ouvertes et adaptables. Dans les deux chapitres qui suivent nous présenterons l’approche de développement à base de composants et le développement basé agents en étudiant les possibilités offertes par chacune de ces approches de développement et faisant une analyse comparative entre ces deux paradigmes importants pour arriver en fin à chercher les fertilités croisées et les possibilités de combinaisons des deux approches pour proposer des solutions pour le développement d’applications distribuées, ouvertes et adaptables dans les quelles nous pouvons tirer profit des importants points forts de chacune des deux approches.
19
Chapitre II Composants logiciels et applications à base de composants
Composants logiciels et applications à base de composants
Chapitre II Composants logiciels et applications à base de composants
2.1 Introduction Depuis des années le monde à connu une énorme utilisation des logiciels dans tous les domaines tel que l’industrie, l’enseignement, l’administration et même dans plusieurs aspects de la vie quotidienne. Cela se traduit en une augmentation des exigences sur la production du logiciel, on demande de plus en plus des logiciels fiables, flexibles, robustes, adaptables, mieux exploitables et que l’on peut facilement installer et déployer. Cette demande grandissante du logiciel ainsi que l’augmentation sur le plan des exigences de qualités ont provoqué une grande complexité à la fois au niveau des logiciels mêmes qu’aux niveaux des processus de développement de ces derniers. Comment vaincre cette complexité ou au minimum la réduire ? Comment adapter rapidement des logiciels face aux changements ? Et finalement, comment prendre en compte l’évolution du logiciel dés son développement ? Ces points présentent des défis très importants pour les développeurs de logiciels et de systèmes informatiques de manière générale. La réutilisation présente une clé de solutions pour ces problèmes. L’idée de réutiliser des logiciels en tous ou en partie est très ancienne. Malgré quelques succès, la réutilisation n’est pas devenue une force motrice pour le développement du logiciel. Dans plusieurs approches la réutilisation n’est pas unie avec le processus de développement tout en constatant l’absence de définitions exactes de ce qui est réutilisable d’un côté et l’absence de formalisations du comment introduire des changements aux éléments réutilisables d’un autre. L’approche de développement par composants (component-based development (CBD)) rétablie l’idée de réutilisation en introduisant de nouveaux éléments. Dans cette approche le logiciel est construit par assemblage de composants développés auparavant et préparés pour être intégrés. Cela influence très considérablement sur la gestion de la complexité, l’augmentation de la productivité et l’amélioration des qualités des logiciels. Les développeurs du logiciel ainsi que leurs clients ont attendu beaucoup du CBD, mais les expériences ont montré que le développement à base de composant exige une approche systématique pour se concentrer sur les aspects du composant pendant le développement de 21
Composants logiciels et applications à base de composants
logiciels [44]. Les techniques du génie logiciel traditionnel doivent être ajustées à la nouvelle approche et de nouvelles procédures doivent être développées. Le génie logiciel à base de composants (Component-based software engineering (CBSE)) est reconnu comme nouvelle sous-discipline du génie logiciel où principalement on s’intéresse à fournir des supports pour le développement de composants autant qu’entités réutilisables, des supports pour l’assemblage de composants ainsi que des supports pour la maintenance et la mise à niveau des applications à base de composants par remplacements où personnalisations de composants [44]. Le présent chapitre fait l’objet d’étude et de présentation de l’approche de développement à base de composants logiciels ainsi que la majorité des notions et des concepts en relation avec le concept “composant”.
2.2 Composants logiciels & génie logiciel basé composant Il est très importants de clarifier les concepts liés au CBSE afin d’enlever les ambigüités causées par les différentes définitions des concepts proposées par les auteurs et qui représentent leurs différentes compréhensions dans différentes situations. À la première vue, le développement de logiciel à base de composants paru comme une extension du développement orienté objet, alors que plusieurs arguments comme la granularité, la composition et le déploiement ainsi que le processus de développement permettent de distinguer clairement les composants des objets. Dans cette section nous présentons les concepts de composant, interface, contrat, patterns, et les Framework qui présentent des concepts très importants liés au CBSE. 2.2.1 Différentes définitions du composant D’une manière simple nous pouvons considérer un composant schématisé dans la figure 2.1 comme une unité réutilisable pour la composition et le déploiement. Dans la littérature plusieurs définitions ont été attribuées à ce concept qui est au cœur du CBSE. Nous présentons quelques définitions qui nous semblent pouvoir couvrir toutes les manières selon les quelles ce concept peut être aperçu.
Figure 2.1 : Composant logiciel
22
Composants logiciels et applications à base de composants
Szyperski dans [164] définit un composant comme « Une unité de composition avec des interfaces spécifiées contractuellement et seulement des dépendances explicites vis à vis de son contexte. Un composant logiciel doit pouvoir être déployé indépendamment et fait l’objet de composition par des tiers. » En analysant cette définition, on peut constater les points suivants: le composant communique avec son environnement à travers des interfaces, par conséquent celles-ci doivent être spécifiées clairement tout en encapsulant l’implémentation à l’intérieur du composant. Cette séparation entre spécification et implémentation n’est pas similaire à celle que nous pouvons voir dans certains langages de programmation tel que ADA où les déclarations sont séparées des implémentations, ou dans des langages de programmation orientés objet où les définitions des classes sont séparées de leurs implémentations, la différence réside dans les besoins d’intégration du composant dans une application, l’intégration du composant doit être indépendante de son cycle vie. En d’autres termes, il n’est pas nécessaire de recompiler une application quand on ajoute un nouveau composant. Pour que le composant peut être déployé indépendamment, il est nécessaire de faire une distinction claire entre le composant et son environnement ainsi que entre le composant et les autres composants. Une autre définition selon laquelle il est possible d’utiliser le concept de composant dans des niveaux d’abstractions autres que le niveau d’implantation a été proposée dans [82] où le composant est défini comme « Une unité de conception (de n’importe quel niveau d’abstraction) identifiée par un nom, avec une structure définie et des directives de conception sous la forme de documentation pour supporter sa réutilisation ». Cette définition est proche de celle proposée dans [44] «Un composant logiciel fusionne deux perspectives distinctes : entant qu’implémentation un composant peut être déployé et assemblé dans un système ou un sous système ; d’un point de vue architectural le composant exprime les règles de conception imposées par un modèle standard de coordination entre les composants… » Dans cette définition on a deux aspects physiques différents à apparaître : le composant d'implémentation qui est un programme ou une partie de programme, et le composant de conception qui est un modèle.
Selon D’Souza et Wills [47] «un composant est une partie réutilisable d’une application, il est développé indépendamment et peut être combiné avec d’autres composants pour construire des unités plus grandes. Un composant peut être adapté mais il ne peut pas subir à des modifications ». La spécificité de cette définition réside dans le fait qu’il est noté en clair qu’un composant ne peut pas être modifié. Brown [29] propose la définition suivante : « Un composant logiciel est un élément logiciel conforme à un modèle de composants et peut être indépendamment déployé et composé sans modification selon un standard de composition.» en plus des aspects qui apparaissent des les autres définitions, dans cette définition il mentionné qu’un composant 23
Composants logiciels et applications à base de composants
doit être conforme à un modèle de composant (voir les modèles de composant dans la section 2.4). Cette définition est très proche de la vision de l’industrie qui est différente de la manière avec laquelle les composants sont vus dans les milieux académiques. Pour conclure, nous revenons au point de départ. Il existe plusieurs définitions pour le concept composant, dans chacune l’accent est mis sur un ou plusieurs aspects. Tous le monde est d’accord sur quelques points, le composant est une unité de composition, il doit être spécifié pour être composé avec d’autres composants ou intégré dans des applications ; les composants sont réutilisables, la réutilisation dans le génie logiciel à base de composant est différente de celle que nous pouvons trouver dans la technologie orienté objet ou d’autre technologies liées au génie logiciel traditionnel. Cette différence réside dans le fait qu’un composant peut être utilisé au moment de l’exécution « run time » sans le besoin de recompilation, le deuxième argument de cette différence apparait parce que le composant détache ses interfaces de son implémentation ce qui permet la composition sans être obligé de savoir aucun détail sur l’implémentation du composant. 2.2.2 Interfaces de composant Une interface d’un composant est définie comme la spécification de ses points d’accès [164]. Ces points sont utilisés par les clients du composant pour accéder aux services fournis par ce dernier. Une interface ne fourni aucun détail d’implémentation de ses opérations. Au lieu de cela, dans une interface on se contente de nommer une collection d’opérations et fournir des descriptions et des protocoles pour ces opérations. Ce mécanisme augmente l’adaptabilité du composant ainsi que ses performances dans le sens où nous pouvons ajouter de nouvelles interfaces et implémentations sans modifier les implémentations existantes ou même remplacer la partie implémentation sans reconstruire le système. Les interfaces servent aussi pour permettre la personnalisation d’un composant. Les interfaces définies dans des technologies standardisées peuvent exprimer des propriétés fonctionnelles dans lesquelles sont inclues : les signatures des opérations ainsi que les comportements des composants. La majorité des techniques pour la description des interfaces comme les langages de définition d’interfaces (IDL) [68] ne mettent l’accent que sur la partie signature (que les aspects syntaxiques). Ces techniques soufrent aussi de certaines incapacités pour décrire les propriétés non fonctionnelles tel que l’exactitude, la précision, la disponibilité, la sécurité, et la latence. Les interfaces d’un composant sont partitionnés en : les interfaces fournies qui décrivent les services fournis par le composant et les interfaces requises qui spécifient les services requis par le composant. 2.2.3
Contrats
Les contrats [113] trouvent leurs raisons d’exister par le besoin de décrire le comportement global d’un composant et par la limitation de la majorité des techniques de descriptions d’interfaces comme les IDL [68] qui ne traitent que les signatures selon une
24
Composants logiciels et applications à base de composants
vision purement syntaxique. Les contrats [113] permettent d’avoir des spécifications plus précises pour les comportements des composants. Bertrand Meyer est parmi les premiers qui ont introduit les contrats dans le développement des systèmes, il mentionne dans [113] qu’un contrat précise les contraintes globales (invariantes) qu’un composant doit maintenir. Pour chaque opération le contrat précise les pré-conditions que les clients doivent satisfaire ainsi que les post-conditions promises en retour par le composant. L’ensemble des pré-conditions, post-conditions et les invariants à maintenir constituent la spécification du comportement d’un composant. En plus de leurs utilisations pour spécifier les comportements des composants individuellement, les contrats sont utilisés aussi pour spécifier les interactions entre un ensemble de composants. Cette spécification concerne : l’ensemble de composants ; les rôles de chaque composant à travers un ensemble d’obligations ainsi que leurs types ; et un ensemble d’invariants à maintenir par les composants. L’utilisation des contrats dans ce cas favorise la réalisation ainsi que le raffinement d’unités logicielles à base de composant de grande granularité, cela est du aux facteurs suivants : Les contrats permettent aux développeurs du logiciel d’isoler et de spécifier explicitement avec un niveau élevé d’abstractions les rôles de tous les composants dans des contextes particuliers. La présence de plusieurs contrats permet de modifier indépendamment les rôles de chaque composant, ou de faire des extensions des rôles. De nouveaux contrats peuvent être obtenus par l’association de différents participants avec différents rôles. Puisque un composant peut participer dans plusieurs contrats son comportement global peut être assez complexe. Plus encore, les contrats spécifient les conditions selon lesquelles les composants interagissent avec d’autres composants en termes de pré et post conditions. 2.2.4 Patterns Le concept de patterns [4] a été introduit à la fin des années 70. Un pattern défini une solution récurrente pour un problème récurrent. Dans un pattern en capture les solutions d’un problème, les solutions fournies ne sont pas des théories ou des abstractions de principes et de stratégies. Les patterns décrivent en détail les relations entre les structures du système et les mécanismes. On peut se poser la question composant. On peut dire d’un côté conception et la documentation d’un les unités réutilisables doivent être qu’entités réutilisables peuvent être
sur la relation entre les deux concepts, patterns et que les design patterns peuvent être utilisés pour la composant, spécialement les composants dans lesquels identifiées. D’un autre côté les composants en tant considérés comme des implémentations de quelques 25
Composants logiciels et applications à base de composants
design patterns. Les designs patterns peuvent servir comme moyen pour décrire les détails d’implémentation de bas niveau d’un composant à la fois pour son comportement et sa structure. Les patterns peuvent aussi décrire les relations entre des composants dans le contexte d’un langage particulier de programmation. Les design patterns peuvent aussi être utilisés pour la description de composition, c à d décrire des assemblages qui associent plusieurs composants. 2.2.5 Framework Dans cette section, nous essayons de mettre en clair la relation entre les Framework et le génie logiciel à base de composant (CBSE) et répondre à la question comment utiliser les Framework dans le CBSE ? Les Framework peuvent être définies selon plusieurs points de vue à différents niveaux d’abstractions. Les Framework peuvent être considérés comme de réutilisables conceptions dans lesquelles la conception consiste à représenter le système à concevoir en classes abstraites et en interactions entre leurs instances. Les Framework peuvent aussi être définis comme des squelettes d’applications qui peuvent être personnalisés par les développeurs [87]. D’un point de vue architectural, un Framework représente une microarchitecture qui fournit un modèle (Template) incomplet pour un système dans un domaine donné [87]. L’idée principale autour de laquelle le concept de Framework tourne c’est que l’on peut extraire des résultats abstraits de l’effort de conception d’un système. Ces résultats peuvent être utilisés dans d’autres situations. Les Framework font la description de ce que peut être utilisé avec quelques modifications dans des situations similaires dans le même domaine ou dans le même espace de problème.
Le CBSE propose de développer des logiciels par « assembler des pièces ». Dans de telles situations il est essentiel d’avoir un contexte dans lequel les pièces peuvent être utilisées. Les Framework peuvent jouer le rôle de ce contexte. Les Framework peuvent jouer le rôle d’une carte mère avec des slots vides auxquels des composants peuvent être insérés dynamiquement pour créer une instance fonctionnelle. La contribution principale des Framework réside dans le fait que ces derniers forcent les composants à achever leurs tâches à travers des mécanismes contrôlés par les Framework. Le visuel studio de Microsoft [117] est un bon exemple où les formes sont construites par ajouter des composants (contrôles) sur une
forme initialement vide ; le développeur ajoute des comportements aux contrôles à travers une interface de messages et d’évènements échangés entre les composants.
26
Composants logiciels et applications à base de composants
2.2.6 Récapitulation
Figure 2.2 : Relations entre composant, interface, contrat, patterns et Framework [2.2]
Les relations entre les concepts de composant, interface, contrat, patterns, et les Framework sont schématisées dans la figure 2.2 tirée de [44].Un composant (1) est une implémentation logicielle réalisant un ensemble de services décrits par une ou plusieurs interfaces (2). Des contrats (3) décrivent des conditions et des obligations que les composants doivent respecter. Les contrats assurent que des composants développés indépendamment obéissent à des règles d'interaction, et peuvent être déployés dans un environnement de compilation et d'exécution standard (4). Les composants ont des types(5). Un ensemble de types de composants et leurs interfaces ainsi que des patterns de conception décrivant les interactions entre les différents types de composants forment un modèle de composant (6). Un Framework d'applications (7) fournit un ensemble de critères de déploiement et d'exécution (8) comme support pour les modèles de composants.
27
Composants logiciels et applications à base de composants
2.3 Spécifications des composants logiciels
Les composants logiciels sont accessibles qu’à travers leurs interfaces. Celles-ci doivent fournir toutes les informations nécessaires pour leurs utilisations et leurs déploiements dans différents contextes tout en cachant tous les détails des opérations que les composants implémentent. La spécification d’un composant revient en la spécification de ces interfaces, cette spécification regroupe la définition des opérations du composant ainsi que les dépendances aux contextes, ce que veut dire les aspects fonctionnels du composant ainsi que ses propriétés non fonctionnelles. Toutes ces informations sont utiles aussi pour les développeurs des composants dans le sens où la spécification du composant peut servir comme cadre pour la définition abstraite de sa structure interne. 2.3.1
Spécifications fonctionnelles des composants
Les spécifications des composants concernent les aspects fonctionnels ainsi que les aspects extra fonctionnels du composant. Puisque un composant est visible qu’à travers ses interfaces la spécification de ce dernier revient en une spécification de ses interfaces, cette spécification doit définir d’une manière précise et complète toutes les opérations ainsi que toutes dépendances aux contextes. Les techniques de spécifications utilisées pour décrire les aspects fonctionnels se devisent en deux classes. Des techniques limitées en ce que est appelées spécifications syntaxiques et des techniques qui permettent de décrire des aspects concernant la sémantique de ce que fait le composant.
2.3.1.1 Spécifications syntaxiques Les composants logiciels implémentent et fournissent un ensemble d’interfaces ou de types. Chaque interface regroupe un ensemble d’opérations où chaque opération porte un nom et a un ensemble de paramètres en entrée et \ou en sortie. Les techniques de spécification syntaxiques associent des types pour tous ces éléments. Certaines techniques permettent de spécifier si le composant a besoin d’interfaces qui sont implémentées par d’autres composants. Les technologies tel que COM [114], ou CORBA (Object Management Group’s Common Object Request Broker Architecture) [125] et les JAVABeans de Sun [161] permettent de développer et de déployer des composants réutilisables où les spécifications sont principalement syntaxiques. Pour les deux premières technologies des langages de définition d’interfaces IDL [68] sont utilisés alors pour les JAVABeans les interfaces sont décrites en JAVA. La figure 2.3 illustre un exemple [44] de contenu d’un fichier de spécification d’un composant COM [114]. Deux interfaces sont spécifiées contenant trois opérations qui
28
Composants logiciels et applications à base de composants
constituent les fonctionnalités d’un composant vérificateur orthographique simple. Les deux interfaces héritent de l’interface COM standard IUNKOWN. Toutes les opérations retournent une valeur de type HRESULT pour indiquer un échec ou un succès de l’exécution de l’opération. Dans cette spécification on a une seule instance du composant associée à deux instances d’interfaces. La première interface est associée à une seule opération, cette dernière à son tour est associée à une seule instance de paramètre d’entrée et deux instances de paramètres de sortie. Nous pouvons constater que cette spécification peut fournir l’information sur les points suivants : quelles sont les opérations fournies, quel est le nombre de paramètres et quels sont leurs types ; mais aucune information sur l’effet de l’invocation d’une opération n’est fournie. Les spécifications syntaxiques présentent des insuffisances pour traiter la substitution et l’évolution de composants. La substitution consiste en la possibilité de remplacer un composant par un autre, d’un point de vue syntaxique cette substitution n’est possible que si le nouveau composant implémente les mêmes interfaces que le composant à remplacer ou les interfaces du nouveau composant sont des sous-types des interfaces du composant à remplacer. L’évolution d’un composant est vue comme un cas spécial de la substitution.
Figure 2.3 : Exemple de spécification d’un composant COM [2.2]
29
Composants logiciels et applications à base de composants
2.3.1.2 Spécification des aspects sémantiques Pour utiliser effectivement les composants, les spécifications syntaxiques ne suffisent pas seules. Il est clair que l’on a besoin d’informations sémantiques sur les composants tel que les codes d’erreurs possibles pour chaque opération, les contraintes sur l’ordre d’invocations des opérations et les combinaisons de valeurs et paramètres que les opérations acceptent. Depuis que l’idée de développer des logiciels à partir de bibliothèques de composants logiciels produits en masse est annoncée, plusieurs méthodes pour concevoir des composants ont été proposées, la majorité des méthodes ont la tendance d’inclure des informations sémantiques dans la spécification des composants. Par exemple la méthode Design By Contrat [113] ainsi que plusieurs autres méthodes proches associent pour chaque opération des préconditions et des post-conditions qui représentent des assertions qui doivent être satisfaites avant l’invocation de l’opération et les assertions que le composant garantie après son invocation respectivement. En plus des pré-conditions et des post-conditions, le contrat liste les contraintes globales que le composant doit maintenir (invariants). Un contrat peut se décomposer en quatre niveaux différents [20] : un niveau syntaxique où le contrat n'est assuré que par les signatures des opérations ; le deuxième niveau : contrat par contraintes, où il est décrit pour chaque service offert les conditions d'utilisation et le résultat attendu ; le troisième niveau : contrat par synchronisation, garantit la bonne marche du système en cas d'utilisation concurrente des interfaces ; et finalement le quatrième niveau qui représente le contrat de qualité de service. Ce type de contrat décrit les conditions d'utilisation de l'interface permettant de garantir la QoS de l'interface. L’utilisation de telles assertions dépond d’un état du composant que ce dernier doit maintenir. Pour cela, pour chaque interface du composant sont ajoutées des informations qui présentent une partie de l’état du composant qui affecte et qui est affectée par l’invocation des opérations de l’interface. Sous le titre « UML components » J.Cheesman et J.Daniels ont publié un ouvrage pour proposer la méthode UML component [36] dans laquelle ils utilisent UML et OCL [174] (Object Constraint Language) pour écrire des spécifications de composants. Les auteurs utilisent la notation UML pour définir le concept du contrat d’assemblage que chaque composant doit remplir pour être intégré facilement dans un système à base des composants existant. La méthode a enrichi la notation d’UML avec des stéréotypes pour désigner la spécification des composants. Par exemples, les stéréotypes suivants ont été proposés: Component specification, Subcomponent, Date Type, Interface Type et Information Type. D’un autre côté, OCL est utilisé pour vérifier et contrôler les pré-conditions et les postconditions des opérations qui caractérisent le comportement de chaque composant. La méthode propose également six workflows (Capture de besoin, spécification, approvisionnement, assemblage, test et le déploiement). Chacun de ces éléments contient d’autres sous workflows, par exemple le workflow ‘spécification’ contient trois activités : identification des composants, interaction entre les composants et la spécification des 30
Composants logiciels et applications à base de composants
composants. Cette méthode est limitée au niveau de conception, aucune explication n’est fournie à-propos de la manière comment interpréter la spécification du composant dans l’implémentation, ou comment vérifier les spécifications du contact au niveau de la compilation. Une autre méthode dont UML component est inspirée a été proposée par D’Souza et A. Wills. La méthode est appelée Catalysis [47]. Dans Catalysis un composant est défini comme un package logiciel cohérant, qu’on peut développer pour la construction ou l’extension d’un système plus large. Les composants de la méthode sont abstraits, et définis comme un ‘Type’. chaque ‘Type’ est une classe stéréotypée. Un type présente un comportement dans un domaine. Le comportement externe de chaque ‘Type’ est défini par ses interfaces. La méthode Component Unified Process [144] et qui présente une adaptation du Processus Unifié [81] orienté vers les systèmes à base de composants a été aussi une source d’inspiration pour les auteurs de UML component. La méthode utilise la notation UML pour exprimer le concept de composant durant le cycle de vie de développement des logiciels. L’accent est mis sur l’obligation de l’omniprésence du composant dans tout le cycle de conception du système, car dans la notation classique d’UML on trouve les composants que dans la phase de déploiement. Cette méthode opte pour le développement dans le contexte des architectures dirigées par les modèles [22] en proposant un méta-modèle indépendant d’une plate-forme technologique (PIM). Par la suite, une projection est effectuée vers des plates-formes spécifiques (PSM). Plusieurs autres méthodes peuvent également servir d’exemples où la spécification des composants et leurs interfaces incluent des informations sémantiques. Nous pouvons citer quelques méthodes comme la méthode Business Component Factory [75] proposée par Herzum et Sims, la méthode KobrA [12][13],la méthode Rational’s Unified Process [94]proposée par Jacobson, Booch, et Rumbaug, et finalement la méthode de sélection de perspectives[5] (Select Perspective method). La notion de substitution de composants dans le cas des spécifications prenant en compte la sémantique n’est pas similaire à la substitution dans les approches qui se contentent des spécifications syntaxiques des composants [44]. La différence réside dans le fait que la condition disant que le nouveau composant doit implémenter les mêmes interfaces que le composant à remplacer n’est plus nécessaire. Pour que la substitution soit possible et d’une manière sûre le nouveau composant doit implémenter les mêmes opérations avec les mêmes signatures que le composant à remplacer implémente tout en assurant les pré-conditions et les post-conditions précitées. En d’autres termes les interfaces du nouveau composant doivent avoir des pré-conditions plus légères et des post-conditions plus fortes que le composant à remplacer. Il faut bien noter que cette vision n’est valide que pour les systèmes séquentiels
31
Composants logiciels et applications à base de composants
contrairement aux systèmes qualifiés de concurrent où la notion de substitution sûre est discutée autrement. Il est important de noter que l’on constate un manque de représentations formelles pour les différents éléments formants le composant, ce manque empêche l’évaluation de certaines propriétés du composant comme la substitution. Ce manque cause aussi plusieurs autres conséquences comme la difficulté pour sélectionner et choisir des composants sans avoir de représentations riches de ces derniers. 2.3.2
Spécifications des propriétés extra-fonctionnelles des composants
Pour réussir une bonne utilisation des composants on a besoin d’informations supplémentaires autres que les spécifications fonctionnelles. Ces informations peuvent être qualifiées de propriétés non fonctionnelles ou extra fonctionnelles. Par propriétés extra fonctionnelles nous désignons les propriétés des composants qui déterminent leurs comportements, mais ces propriétés ne sont pas décrites sous forme de fonctions et par la suite elles ne sont pas invocables. Ces propriétés regroupent des contraintes temporelles comme le temps d’exécution et la latence ainsi que des contraintes liées à la fiabilité, la performance, l’efficacité, la synchronisation et la sécurité [44]. Au niveau système, d’autres propriétés peuvent être considérées, ces propriétés sont en relation avec la maintenance, l’adaptabilité et l’utilisation du système. Quand on traite les propriétés extra fonctionnelles, l’un des problèmes les plus importants qui se pose est la détermination des relations entres les propriétés des composants et celles du système. Ainsi que la détermination des propriétés à considérer lors de l’évaluation des composants et lors de leurs compositions. Depuis longtemps le besoin d’enrichir les spécifications des composants par des propriétés extra fonctionnelles a été reconnu. Plusieurs propositions ont vu le jour présentant des résultats de recherches menées par la communauté des chercheurs en génie logiciel. Nous pouvons citer comme exemple le concept de FURPS scheme incorporé dans Rational Unified Process framework [94], UML QoS [103] et Fault Tolerence Profile [103]. Parmi les concepts proposés pour décrire les propriétés non fonctionnelles figure le concept Credential [28] qui est un triplet (Attribut, valeur, crédibilité) où l’attribut représente la propriété, la valeur représente une mesure sur la propriété et la crédibilité indique la manière selon laquelle la mesure est obtenue ; ce concept a été incorporé dans l’approche de construction de système à partir de composant préexistants ensemble [171]. Nous citons encore les travaux sur les formalismes des propriétés extra fonctionnelles comme la formulation systématique des propriétés non fonctionnelles proposée par Xavier Franch [178] et l’approche proposée dans [62] pour l’intégration de Qos dans le développement du logiciel. Les travaux portant sur les besoins non fonctionnel en génie logiciel ainsi que les descripteurs de propriétés non fonctionnelles peuvent également servir d’exemples. 2.4 Catégorisation des composants logiciels 32
Composants logiciels et applications à base de composants
Les composants peuvent être vus de différentes manières, leurs classifications dépendent de plusieurs points de vue comme le niveau de transparence, le niveau d’abstraction, la spécialisation, et tout autres points de vue permettant une catégorisation des composants. L’utilité des classifications des composants réside dans la possibilité de mieux entourer leurs utilisations. Selon le degré de transparence signifiant un degré de visibilité et de détails apparents les composants sont répartis en composants boites noires, composants boites blanches et composants boites grises. - Composants boites noires : des composants dont le code binaire est vendu avec un mode d’emploi et des spécifications. la réutilisation d’un composant boîte noire est une sorte de réutilisation d’une mise en œuvre sans tenir compte sur autres choses que son interface et ses spécifications. - Composants boites blanches : Totalement opposé aux composants boites noires, la solution dans le cas des composants boîte blanche est de fournir tout le code des composants. Dans ce cas, on constate une perte au niveau de possibilités de réutilisation dans le sens où il devient très peu probable que les composants peuvent être remplacés par de nouvelles versions car ceux-ci peuvent dépendre de certains détails d'implémentation qui peuvent être sujet de changement dans les nouvelles versions. - Composants boites grises : il s’agit d’une solution intermédiaire entre les composants boites noires et les composants boites blanches. Les composants de cette catégorie dévoilent une partie contrôlée de leurs mises en œuvre dans le cadre de la spécification. Selon la spécialisation des composants, trois types principaux de composants peuvent être distingués [91] : les composants conceptuels, les composants logiciels et les composants métiers. Les composants conceptuels : Un composant conceptuel est une solution à un problème conceptuel sous la forme d’un modèle (ou une partie d’un modèle) destinée à être réutilisée [91]. Cette solution peut être spécifiée avec un langage de modélisation comme UML. Les composants conceptuels peuvent être des composants produits ou des composants processus. Un composant produit est une partie cohérente d’un modèle qui peut être réutilisée avec d'autres composants produits pour assembler un modèle complet. Un produit correspond au but à atteindre lorsqu’on utilise la solution offerte par le composant produit. Par exemple, le patron « composite » de Gamma [60] peut être considéré comme un composant conceptuel produit. Un composant processus est une partie cohérente d’un processus qui peut être réutilisé avec d'autres composants processus pour assembler un processus complet. Un processus correspond au chemin à parcourir pour atteindre la solution offerte par le 33
Composants logiciels et applications à base de composants
composant processus. Par exemple, le patron « revue technique » [6] est un composant conceptuel processus. Les composants logiciels : Nous pouvons prendre la définition de D’Souza [47] où un composant logiciel est défini comme un paquetage cohérent d’implantations logicielles et qui peut être indépendamment développé et délivré. Il possède des interfaces explicites spécifiant les services offerts et les services requis par le composant. Il peut être composé avec d’autres composants et être éventuellement paramétrable sans modifier son implantation. Il existe d’autres définitions qui s’intéressent à des aspects spécifiques des composants logiciels, certaines insistent sur la séparation du processus de production et de la réutilisation du composant. Cette propriété permet l’industrialisation du processus de production des systèmes divisé en deux sous-processus : le processus de développement pour la réutilisation dans lequel les composants sont développés avec une optique de réutilisation et le processus de développement par réutilisation de composants dans lequel les systèmes sont construits en utilisant des assemblages de composants. D’autres définitions comme celle de Heineman [74] introduit la standardisation des composants conformément à des modèles de composants. Ainsi, les modèles de composants permettent l’outillage des approches de développement à composants en fournissant des environnements de développement. Les modèles de composant présentés dans la section suivante servent d’exemples pour cette catégorie de composant. Les composants métiers: Le concept de composant métier résulte de celui d’objet métier défini par l'OMG (Object Management Group) comme suit : « Business Objects are representations of the nature and behaviour of real world things or concepts in terms that are meaningful to the enterprise. Customers, products, orders, employees, trades, financial instruments, shipping containers and vehicles are all examples of real-world concepts or things that could be represented by Business Objects »[126]. Ce que peut être traduit en: les objets métiers sont des représentations de la nature et des comportements des objets du monde réel ou des concepts en termes significatifs pour l’entreprise. Les clients, produits, ordres, employés, affaires, instruments financiers, conteneurs de transport et véhicules sont des exemples de concepts ou d’objets du monde réel représentables par les objets métiers.
Un composant métier peut être vu comme un composant logiciel qui fourni des fonctions dans un domaine métier. Certains spécialistes définissent un composant métier comme une unité de réutilisation de connaissances de domaines d’un point de vue uniquement conceptuel. Par exemple, Casanave propose la définition suivante: « Un composant métier est vu comme une représentation de la nature et du comportement d'entités du monde réel dans des termes issus du vocabulaire d’une entreprise » [34]. Parmi les modèles de composants métiers existants nous pouvons citer à titre d’exemple le modèle de composant métier Symphony [73].Symphony a pour but de spécifier les différentes phases d’un projet, de définir les tâches de chacun des intervenants et de contrôler les coûts, les délais et la qualité de l’application logicielle produite. Symphony se présente
34
Composants logiciels et applications à base de composants
sous forme d’un guide méthodologique offrant une solution basée sur l’utilisation de composants. Cette démarche s’appuie sur le langage unifié UML et elle est construite autour d’un certain nombre de pratiques. Elle est itérative, incrémentale, orientée utilisateur, orientée composants, pilotée par les cas d’utilisation et adopte un modèle de cycle de vie en Y [9]. 2 .5 Modèles et technologies de composants logiciels
Un modèle de composants regroupe un ensemble de conventions à respecter lors de la construction et l’utilisation des composants. Ces conventions permettent de définir et de gérer d’une manière uniforme les composants. Elles couvrent toutes les phases du cycle de vie d’un logiciel à base de composants : la conception, l’implantation, l’assemblage, le déploiement et l’exécution. Le concept de modèle de composant présente un appui essentiel pour le développement, la composition, la communication, le déploiement et l’évolution des composants. Le modèle de composant est un facteur important pour traiter les aspects de l'interopérabilité, l'évolutivité, la maintenabilité, ainsi que de nombreux autres attributs de qualité. Contrairement aux ADLs (langages de description d’architecture) qui traitent principalement les activités de conception [110], les modèles et les technologies de composants académiques ou industriels comme COM [115] et Java Beans[161] mettent l’accent sur les dernières phases de développement à savoir l’implémentation, le déploiement et l’exécution. Il est tout à fait clair que les ADLs et les technologies de composants adressent des problèmes différents à des niveaux d’abstraction différents. Alors que les ADLs s’intéressent aux problèmes liés à la réalisation et le développement proprement dit, les modèles et les technologies de composants traitent les problèmes liés à la capacité d’analyser le fonctionnement des systèmes ainsi qu’aux supports d’exécution en mettant l’accent sur les aspects pragmatiques. La majorité les modèles de composants existants offrent des possibilités d’ajouter de nouveaux services ou de nouvelles fonctionnalités aux systèmes logiciels d’une manière transparente. Cela est dû aux possibilités offertes par la majorité de modèles de composants entre autres le pouvoir de définir explicitement les composants et les connexions entre ces derniers ; le pouvoir de définir explicitement les implémentations de composants à partir de codes natifs ; et finalement définir explicitement les propriétés extra fonctionnelles des composants. La majorité des modèles de composants industriels visent certains objectifs communs comme l’augmentation de l’indépendance des codes ; augmenter la transparence des services ; la mise en œuvre de la distribution et la généralisation de service. Il existe plusieurs modèles et de technologies de composants logiciels comme COM [115], CCM [107], JAVA BEANS[161], .NET [116], FRACTAL[30],et OSGI[128]. Ces modèles de composants se diffèrent les uns des autres principalement dans les points suivant : les concepts clés de chaque modèle ; la manière d’implémenter les composants ; la manière 35
Composants logiciels et applications à base de composants
dont sont réalisés les assemblages et finalement le cycle de vie du composant ainsi que celui de l’application à base de composants. Dans ce qui suit nous présentons en se basant sur ces points quelques modèles de composants logiciels ayant connu des succès importants et de larges utilisations, il s’agit de COM, CCM, JAVA BEANS, .NET et FRACTAL. 2.5.1
Le modèle de composant COM
Les technologies COM (Component Object Model) [115], DCOM [50], MTS [139], et COM+ [139], proposées par Microsoft présentent de réelles tentatives pour augmenter l’indépendance autre les programmes d’un côté et pour vaincre l’hétérogénéité entre les langages de programmation d’un autre. La technologie COM se base sur les interfaces et sur des conventions d’interopérabilité, DCOM est une extension de COM qui traite la distribution, la technologie MTS présente une extension de DCOM qui offre des services de transaction ainsi qu’une certaine persistance, COM+ regroupe les trois technologies en un seul modèle. Dans la technologie COM une interface est vue comme une classe virtuelle c++ et prend la forme d’un ensemble de fonctions et de données sans codes associés. Un objet COM est un code binaire dont la source est écrite dans n’importe quel langage de programmation. Ce code binaire peut être sous la forme d’un exécutable ou d’une DLL (dynamic libraries) qui contient un minimum d’information nécessaire pour la liaison dynamique et l’identification de l’objet COM. La composition des COM est supportée par deux techniques, il s’agit de l’agrégation et la contenance qui signifie qu’un objet COM contient d’autres objets COM. Dans le cas de la contenance l’objet contenant déclare certaines interfaces des objets contenus, l’implémentation de ces dernières se fait par délégation aux objets contenus. L’agrégation est un peu plus complexe, l’objet COM composé expose les interfaces des objets qui le composent comme si l’objet composé implémente réellement ces interfaces. Il est à noter que COM et COM+ sont des modèles de composant basés sur le moment d’exécution uniquement. C’est à dire, ces modèles ne proposent pas des supports pour le cycle de vie entier d’un composant ou d’une application à base de composants. 2.5.2
Le modèle CCM
Le modèle de composant industriel CCM [107] (Corba Component Model) développé par OMG est basé sur des expériences d’utilisation des servies CORBA, les JAVA BEANS et les EJB. Dans CCM l’accent n’est pas mis uniquement sur l’assemblage de composants pour construire une application mais l’accent est mis également sur la conception et le déploiement des composants. CCM présente une solution pour le problème de complexité dans les services CORBA, cette complexité vient de la flexibilité offerte par CORBA aux développeurs et qui impose toujours un nombre important de choix. CCM est le résultat des travaux menés pour définir un modèle de composant dans lequel les standards d’EJB sont généralisés et le nombre de détails à spécifier est réduit ainsi que les risques d’inconsistance. La vue externe d’un composant CCM est une extension du langage IDL de CORBA (langage de définition 36
Composants logiciels et applications à base de composants
d’interfaces de CORBA) où chaque interface est constituée de cinq éléments : facettes, points de connexion décrivant l’aptitude d’utiliser des références fournies par des acteurs externes (receptacles), points de connexion émetteurs d’événements, points de connexion pour les quels quelques événements seront transférés, et des attributs pour la configuration du composant. Concernant l’assemblage des CCM, la connexion entre les composants est définie comme la référence d’objets, les composants sont connectés par la liaison des facettes aux receptacles et les points de connexion émetteurs d’événements aux points de connexion receveurs. Les connexions sont décrites explicitement dans un fichier XML appelé descripteur d’assemblage d’une manière similaire à celle utilisée dans l’ADL Rapide [103]. Les connexions sont établies par le Framework CCM à l’initialisation. Dans CCM l’implémentation d’un composant consiste en un ensemble de segments présentant chacun un code exécutable implémentant au minimum un port. CCM propose un langage de définition d’implémentation de composant (CIDL) pour décrire les segments, les exécuteurs associés, les types de stockage et les classes de conteneurs. CCM donne de l’importance à la possibilité d’obtenir plusieurs services sans être obligé de faire des modifications au niveau du code tout comme MTS et EJB. Cette approche augmente la réutilisabilité et améliore la maintenabilité d’un côté, et affaiblit la complexité d’un autre côté. Tout comme EJB et CORBA, les composants CCM utilisent des conteneurs pour implémenter les accès aux services en utilisant des patrons de conception collectionnés à travers des expériences dans la construction d’applications basées sur la technologie de l’objet. 2.5.3
Le modèle Java Beans
Le modèle Java Beans(1997) [161] présente une première tentative d’intégrer la notion de composant dans le langage Java. Le modèle met l’accent sur la réutilisation et l’augmentation des capacités de composition statique et dynamique. L’objectif principal de Java Beans est de définir un modèle de composant pour java, ce modèle est utilisé pour créer des composants que l’on peut déplacer et composer ensemble dans une application. L’assemblage peut être réalisé visuellement avec un outil d’assemblage appelé ‘’builder Tools’’. Aucune solution spécifique pour l’assemblage propre à ce modèle n’est proposée, Java beans est conçu pour supporter plusieurs manières d’assemblage de composants. Un java bean est décrit à travers quatre types de port, méthodes, propriétés, sources d’événements, et les ports d’écoute d’événements. Ces ports présentent l’interface d’un composant java bean qui est implémenté généralement par un simple objet java, cette implémentation peut être vue comme une encapsulation de l’objet dans un composant. Parfois, des implémentations plus sophistiquées (collection d’objets ou envelopper un objet) sont nécessaires. Un autre volet bien couvert par java Beans concerne le paquetage des composants, ces derniers peuvent être paquetés dans des archives que l’on ouvert par un ’builder tool’ pour obtenir tous les composants archivés.
37
Composants logiciels et applications à base de composants
2.5.4
Le modèle .Net
Le modèle .Net de Microsoft [116] ne présente pas une continuité des modèles COM, DCOM et COM+. Ce modèle est caractérisé par la limitation des interopérabilités binaires. .Net est basé sur un langage d’interopérabilité et d’introspection dénommé MSIL pour designer un langage interne de Microsoft. Ce langage est similaire au Byte code de java. MSIL est interprété par CLR (Common Language Runtime) similaire à la machine virtuelle java. A l’opposé de la vision adoptée par OMG où les informations relatives aux relations entre composants sont séparées de ces derniers dans .Net les choses passent comme en langages de programmation. C'est-à-dire, les programmes contiennent les informations relatives aux relations entre composants. Un composant est décrit dans un descripteur (manifest) qui regroupe les informations : les méthodes importées et exportées, les événements, le code, les métadonnées, et les ressources. .Net est basé sur une liaison dynamique pour réaliser les connexions entre les composants pendant l’exécution. En ce qui concerne l’implémentation des composants, ces derniers consistent en modules qui sont des codes exécutables ou des DLLs (dynamic libraries). La liste des modules qui composent le composant est donnée au compilateur pendant la compilation du module principale. A la fin de la compilation le manifest est généré dans le même fichier avec le module exécutable principal. Les modules ne peuvent pas être assemblés de modules à leurs tours et ils sont chargés qu’aux moments où ces derniers sont requis. 2.5.5
Le modèle Fractal
Fractal [30] est un framework de composition qui définit un modèle à composants modulaire extensible et générique. Ce framework peut être utilisé avec différents langages de programmation pour concevoir, implanter, déployer et reconfigurer les systèmes informatiques de toute sorte. Ce modèle de composants adopte le principe de séparation des préoccupations dans la conception des composants et des systèmes d’information à base de composants. Le principe de séparation des préoccupations préconise la séparation des aspects et des préoccupations d’un système d’information en plusieurs entités distinctes. Par exemple, implanter les services fonctionnels fournis par le système d’information dans une entité différente des entités qui assurent les aspects non fonctionnels comme la configuration, la sécurité, et la disponibilité, etc. En particulier, le modèle de composants Fractal propose trois niveaux de séparation des préoccupations : Séparation des interfaces et des implémentations où le découplage entre les interfaces et leurs implémentations est assuré par le patron de conception Pont [60]. Ainsi, les interfaces et les implémentations peuvent évoluer séparément, ce qui augmente l’adaptabilité et l’évolutivité des composants et des systèmes d’information à base de composants ; la programmation orientée composants, ce deuxième niveau correspond à la décomposition des préoccupations d’implémentation en plusieurs sous 38
Composants logiciels et applications à base de composants
préoccupations de plus petites tailles et composables. Ces sous-préoccupations sont implantées dans des entités séparées appelées composants. Et finalement le niveau d’inversion du contrôle où la configuration et le déploiement d’un composant Fractal sont délégués à une entité extérieure au composant de manière que les composants ne se préoccupent plus de trouver et de paramétrer les composants et les ressources dont ils ont besoin.
2.6 Adaptabilité des applications à base de composants Nous nous somme intéressé dans nos travaux d’une manière particulière à la problématique d’adaptation logicielle, dans le premier chapitre une vue globale de cette problématique est présentée. Nous essayons dans cette section de projeter les différentes dimensions de l’adaptation explicitées dans le premier chapitre sur le cas d’applications à base de composants.
Première dimension : Dans quels buts adapte-t-on une application à base de composants ? Les principales raisons pour adapter une application à base de composant sont pratiquement les mêmes pour l’adaptation d’applications en général : l’adaptation corrective, l’adaptation adaptative, l’adaptation évolutive et l’adaptation perfective. Néanmoins, il existe d’autres raisons liées beaucoup plus à l’amélioration de la qualité de l’application. Une application à base de composant peut être adaptée pour des besoins l’interopérabilité [28] dans le but de rendre un ou plusieurs composants compatibles avec un grand nombre de contextes. Une autre raison pour laquelle on adapte des composants est de les rendre plus réutilisables [19] et donc plus découplés de leurs contextes. Deuxième dimension : Sur quoi porte l’adaptation composants ?
d’une application à base de
Une application à base de composants regroupe naturellement un ensemble de composants et se caractérise par une architecture physique ou logique. Il est donc clair que l’adaptation d’une application à base de composants consiste à porter des modifications ou des changements soit au niveau des composants (les entités qui forment l’application) soit au niveau de l’architecture. Le tableau 2.1 résume la situation en mettant en clair pour chaque sujet d’adaptation les actions de modification qui correspondent.
39
Composants logiciels et applications à base de composants
Sujet d’adaptation
Actions de modification
Architecture
L’adaptation de l’architecture physique
Migrer des composants vers d’autres sites d’exécution
(un
redéploiement
de
l’application). L’adaptation de l’architecture logique
Reconfiguration du composant
Composant
Réimplantation du composant primitif
Réimplantation composite
d’un
ajouter, supprimer ou remplacer des composants. Modifier les connexions entre composants existants (réassemblage de l’application). Reparamétrer les propriétés configurables d’un composant. Réimplantation interne du composant : changer par exemple une structure de données dans le code, ou le changement d’algorithme d’une méthode ; Réimplantation de la structure externe du composant : par exemple fusionner des interfaces ou les éclater en plusieurs interfaces ;
composant Réimplantation interne du composant ; Réimplantation de la structure externe du composant ; Réorganisation interne du composite.
Tableau 2.1 : Sujets d’adaptation d’une application à base de composants.
Troisième dimension : À quels moments peut-on adapter une application à base de composants ? On peut adapter une application à base de composants à plusieurs moments de son cycle de vie. Cette adaptation peut être statique, comme elle peut être effectuée au moment du déploiement, on parle dans ce cas d’une adaptation semi-dynamique et l’adaptation peut être effectuée en cours d’exécution, il s’agit d’une adaptation dynamique.
Quatrième dimension : Qui décide l’adaptation d’une application à base de composants ? Dans le cas d’une adaptation manuelle les opérations d’adaptation sont initiées par des acteurs humains. En fonction du moment dans lequel l’adaptation est recommandée ou nécessaire différents acteurs peuvent intervenir. On distingue le concepteur d’application à base de composants, le développeur et l’administrateur. 40
Composants logiciels et applications à base de composants
Pour une adaptation automatique l’initiateur des opérations d’adaptations peut être aussi un acteur humain ou une entité logicielle interne qui peut être un composant particulier chargé de gérer l’adaptation comme il est présenté dans [78], ces composants chargés de l’adaptation peuvent être conçus selon des design patterns spécifiques comme il est fait dans l’approche présentée dans [32]. L’adaptation peut être déclenchée également par une entité logicielle externe. Cinquième dimension : comment mettre en œuvre l’adaptation d’une application à base de composants ?
La mise en œuvre de l’adaptation d’une application à base de composants dépend étroitement de l’élément sujet de modifications. Dans le cas où la modification concerne le niveau composant primitif l’adaptation est similaire à l’adaptation d’applications d’une manière générale comme il est expliqué dans la section 1.3.5 du premier chapitre. L’adaptation des composants composites est similaire à l’adaptation d’une application à base de composants du fait qu’un composant composite peut être vu d’une certaine manière comme une application à base de composants. Le dernier cas concerne les modifications qui ont un impact sur l’architecture physique ou logique d’une application. L’adaptation de l’architecture physique consiste à effectuer un redéploiement de composants d’une application ce qui pose des problèmes spécifiques liés à la distribution et dépend de l’infrastructure de déploiement utilisée. L’adaptation de l’architecture logique sur laquelle nous mettons l’accent se résume en l’ajout, la suppression et le remplacement d’un composant ainsi que la reconfiguration des liaisons entre composants. L’adaptation de l’architecture logique est réalisée à travers un enchainement d’exécutions d’opérations d’ajouts de composants, de suppressions de composants, de substitutions de composants et de reconfigurations de liaisons pour modifier la façon dont les composants de l’application sont assemblés en gardant les mêmes composants. Ces opérations reposent sur certains mécanismes que nous pouvons résumer en : i) le mécanisme d’activation et de désactivation de composant qui consiste à autoriser et interdire respectivement les opérations d’un composant ; ii) le chargement d’un composant qui regroupe les actions permettant d’intégrer dans une application un composant extérieur à celle-ci de sorte qu’il devienne un élément de l’application. À l’opposé, le déchargement d’un composant consiste à supprimer toutes ses occurrences ; iii) les mécanismes de connexion et de déconnexion des composants qui dirigent les dépendances entre les composants ; iv) le mécanisme de configuration de composant qui consiste à modifier les valeurs configurables d’un composant à travers des interfaces de contrôle ; v) le mécanisme de sauvegarde et de restauration d’état des composants pour les utiliser lors des substitutions. Dans la figure 2.4 nous explicitons l’utilisation de ces mécanismes pour réaliser la substitution d’un composant par un autre. 41
Composants logiciels et applications à base de composants
Figure 2.4 : Mécanismes pour réaliser la substitution d’un composant par un autre.
Les d’opérations d’ajouts de composants, de suppressions de composants, de substitutions de composants et de reconfigurations de liaisons peuvent être combinées pour donner naissance à d’autres opérations plus complexes [26]. Ces opérations semblent d’une grande utilité dans des cas par exemple où nous voulons remplacer un composant par un assemblage d’autres composants ou l’inverse. La majorité des approches visant le développement d’applications adaptables dynamiquement comme l’approche CommUnity [176] proposent l’utilisation d’opérations d’adaptation complexes et qui sont composées d’opérations simples. Plusieurs travaux ont été proposés pour traiter la problématique de l’adaptation dynamique au niveau des applications à base de composants. La manière avec laquelle la problématique est traitée diffère d’une approche à une autre. Par exemple dans le domaine des ADLs (Architecture Description Language)[110] l’adaptation apparait sous forme de dynamicité des architectures. Certains ADLs comme Darwin [109] et Rapide [103] permettent d’exprimer des reconfigurations dynamiques des connexions entres les composantes d’une architecture et même d’ajouter, supprimer ou remplacer des composants 42
Composants logiciels et applications à base de composants
et des connexions. Dans les ADLs, l’architecture d’un système est décrite principalement en termes de composants traités en tant que des unités de calcul ou de stockage qui sont dotées d’interfaces fournies et requises, de connecteurs représentants les interconnexions ainsi que les règles d’interaction entre composants et des règles de configurations qui peuvent être décrites sous fourme de graphe de composants interconnectés à travers des connecteurs. En plus des ADLs, il existe des langages pour modifier des architectures abrégés généralement AMLs (Architecture Modification Language)[131] qui représentent des environnements de configuration dynamique des architectures comme [17]. Dans une autre catégorie de travaux la problématique d’adaptations d’applications à base de composant est traitée en tant qu’une problématique de spécifications d’adaptations. Dans cette tendance s’inscrit le modèle proposé dans [111] où les auteurs utilisent des règles exprimées en XML sous la forme d’un contrat qui associe une certaine configuration du contexte d’exécution aux comportements que doit adopter l’application. Dans ce genre de travaux, il s’agit d’exprimer les cas d’adaptation où un comportement est appliqué dès que certaines contraintes de déclenchement de l’adaptation sont satisfaites. Cependant, les travaux basés sur cette idée de règles indépendantes ne peuvent pas apporter quelque chose d’intéressant dans les cas complexes, ces travaux restent applicables que pour des cas simples. 2.6.1 L’adaptation dans quelques modèles de composants Il existe de nombreux travaux qui traitent l’adaptation d’applications à base de composants en utilisent des modèles de composants particuliers qui peuvent êtres industriels comme EJB ou non industriels où les auteurs proposent leurs propres modèles de composant. L’adaptation d’applications est prise en charge en fournissant une infrastructure d’adaptation particulière. Les adaptations basées sur les modèles de composant SAFRAN [137], Sofa [32], DUCS [23], K-Component [46],OpenRec [175] et CASA [118] peuvent servir de bons exemples . Le modèle de composant SAFRAN [137] présente une extension du modèle de composant Fractal [30] visant à supporter le développement des composants auto adaptables. Ce modèle de composant est basé sur l’introduction d’une extension réflexive permettant de modifier de manière transparente le comportement d’un composant en fonction de son contexte d’exécution. L’adaptation est traitée en tant qu’aspect dynamiquement dans les applications en utilisant la programmation par aspects sous forme de politique réactive réalisée grâce à un langage dédié (FScript). Dans SAFRAN, d’adaptation consiste à exécuter des actions permettent de réassembler une application, dans le sens qu’un composant composite basé sur le modèle ECA (évènement-Condition-Action). Le déclenchement automatique de ces actions consiste à tester les évènements issus du contexte. En faisant une évaluation de SAFRAN on conclue que l’infrastructure d’adaptation utilisée dans SAFRAN est assez sophistiquée car elle inclut non seulement un modèle de politiques d’adaptation mais aussi un gestionnaire générique de contexte et un langage de reconfiguration. Ainsi, un
43
Composants logiciels et applications à base de composants
concepteur d’applications dispose de tous les outils nécessaires pour définir facilement une application auto-adaptable [67].
DUCS [23] est un modèle à composant supportant la mise à jour des composants de manière dynamique. Le but de DUCS est de fournir une infrastructure pour créer des applications réparties où les composants peuvent évoluer sans arrêter l’application. L’infrastructure de DUCS est composée de quatre entités. Le plus bas niveau représente les nœuds. Les nœuds sont apparentés à une machine virtuelle (Java). Au dessus de ces nœuds se trouve la base de l’infrastructure fournissant l’environnement d’exécution des composants de l’application. La communication entre les composants utilise cette infrastructure. Au sein de cette infrastructure se trouve le gestionnaire de configuration gérant l’évolution sur les nœuds. Ce gestionnaire de configuration fournit une interface afin de faire évoluer les composants du noeud. Cette évolution est commandée par une « requête de mise à jour ». La dernière entité formant le canevas de DUCS est le gestionnaire d’architecture. Ce gestionnaire gère l’ajout, la suppression et la mise à jour de composants sur tous les nœuds formant l’application. Lors d’une mise à jour DUC propose un support de transfert d’état. À l’aide de fonctions de transfert, l’état d’un composant est réinjecté dans le composant le remplaçant. K-Component [46] est un modèle à composant au dessus de CORBA ayant pour but de créer des applications auto-adaptables. Ce modèle tend à séparer l’implémentation des composants (en CORBA) de la gestion du dynamisme. Une autre particularité de ce modèle à composant est que les adaptations sont directement effectuées sur l’architecture et reproduites sur l’application. Plus particulièrement, l’application est composée d’un ensemble d’instances de composant et de connecteurs. Elle est directement supervisée par un gestionnaire de configuration. Ce gestionnaire maintient en permanence le graphe des instances de composants et des connecteurs qui composent l’application. La communication entre le gestionnaire de configuration et l’application se fait via des événements d’adaptations émis par l’application ou émis par le gestionnaire de configuration afin de « commander » les reconfigurations. Les reconfigurations sont décrites dans des contrats d’adaptation. Ces contrats sont exprimés avec un ensemble de règles conditionnelles permettant à la fois de reconfigurer l’architecture de l’application en fonction des événements émis par l’application et de définir des contraintes architecturales. La reconfiguration de l’architecture se fait en utilisant des opérations de reconfiguration fournies par le gestionnaire de configuration. KComponent propose donc un modèle à composant intéressant pour créer des applications dynamiques. En effet, il est capable de gérer toutes les sources de dynamisme. De plus, le fait de reconfigurer directement l’architecture de l’application permet d’exprimer les reconfigurations à l’aide de primitives de plus haut niveau. OpenRec [175] est un modèle à composant où l’adaptation est réalisée par des supports pour la reconfiguration dynamique. OpenRec permet la création d’applications dynamiques ouvertes sans définir un algorithme de reconfiguration au départ mais permet de définir des algorithmes et de les substituer à l’exécution. L’infrastructure d’OpenRec est divisée en trois 44
Composants logiciels et applications à base de composants
couches qui sont elles-mêmes implémentées en utilisant OpenRec. La première couche représente le pilote de reconfiguration qui reçoit les politiques d’adaptation et détermine quand et comment doit être adaptée l’application. Lorsqu’une adaptation est nécessaire, il notifie le gestionnaire de reconfiguration qui en fonction de l’algorithme de reconfiguration utilisé restructure l’application. L’application est donc supervisée par le pilote et le gestionnaire de reconfiguration. La couche application contient des composants et des connecteurs OpenRec, mais également des plug-ins de supervision. Selon qu’il existe plusieurs modèles et approches à base de composant où chacune propose des mécanismes et des concepts pour supporter l’adaptation des applications à base de composants, il faut mettre en place une certaine mesure de la qualité du processus d’adaptation. Des critères d’évaluation du processus d’adaptation sont proposés dans [67], que nous pouvons résumer en : -
-
-
la cohérence qui fait référence à la capacité d’empêcher l’introduction d’erreurs de fonctionnement à cause du processus d’adaptation et des problèmes qu’il peut engendrer ; La performance qui fait référence à la quantité de ressources matérielles utilisées par le processus d’adaptation ; la disponibilité : qui fait référence à la capacité de garantir que certaines fonctionnalités prioritaires pourront être utilisées durant le processus d’adaptation ; La simultanéité qui fait référence à la capacité de coordonner des adaptations qui sont déclenchées ou réalisées simultanément ; et finalement l’ouverture qui fait référence à la possibilité de configurer/adapter le processus d’adaptation avec des stratégies plus ou moins élaborées.
2.7 Synthèse A travers l’étude de l’approche de développement à base de composants et l’étude de quelques modèles de composant nous constatons qu’il est d’intérêt de conserver la notion de composant logiciel et d’architecture logicielle dans le développement des applications. Les composants logiciels apportent de la structuration du code de l’application, de la réutilisation et du support pour le déploiement. Le concept de connecteurs utilisés pour inter relier les composants apportent de leurs côté un support permettant de séparer les aspects liés à la mise en œuvre de la communication des aspects métiers de l’application. Les capacités qu’offrent certains modèles de composant en termes de pouvoir de reconfigurer dynamiquement une application présentent de réelles solutions pour la construction d’applications plus adaptables et plus flexibles. La reconfiguration d’une application recouvre les modifications portant sur les éléments constitutifs de l’application ainsi que celles qui portent sur les interactions entre ceux-ci. 45
Composants logiciels et applications à base de composants
Un autre constat que nous avons fait en étudiant quelques approches de développement à base de composants consiste en la redéfinition de langages de description d’architecture pour chaque approche bien qu’il est facilement observable qu’il existe de nombreuses similitudes entre ces langages. Afin de mettre en avant l’interopérabilité entre les approches de construction d’applications à base de composants nous pensons qu’il est intéressant de disposer d’un modèle suffisamment abstrait pour la description d’architecture et commun entre la majorité des modèles de composants et plus particulièrement les modèles académiques. Il semble aujourd’hui que la majorité des approches de développement à base de composant ainsi que la majorité des modèles de composants se rencontrent bien sur les grandes lignes de la structure du composant avec principalement l’utilisation des notions de ports et d’interfaces. Cet accord sur le plan structure est escorté par une grande variation dans la sémantique des composants ainsi qu’une grande diversité dans les caractéristiques et les objectifs de chaque approche. Devant le nombre important d’approches et de modèles de composants révélant une grande diversité de points de vue, d’objectifs et de caractéristiques, il est important, voire obligatoire, de fixer les axes qui définissent un repère dans lequel nous pouvons situer les approches et les modèles de composants les uns par apport aux autres. Les axes de ce repère représentent les critères selon les quels les approches et les modèles de composants sont évalués. De nombreux critères d’évaluation des approches et des modèles de composants peuvent être définis où un critère peut à son tour définir d’autres sous critères. Les critères qui nous semblent importants et qui se coïncident avec nos objectifs sont : La prise en compte de la dynamique et de l’adaptation de l’application ; La distance importante reflétant l’abstraction par apport aux plateformes d’exécution ; La précision dans la description d’assemblages de composants et de leurs interfaces. Il est d’une importance extrême de prendre en compte l’évolution de l’architecture logicielle en réponse à la dynamique de l’application. Cette prise en compte ne se résume pas en quelques mécanismes de reconfiguration dynamique même avancés que nous trouvons dans quelques modèles de composants comme FRACTAL [30] ou SAFRAN [137], mais la prise en compte de la dynamique doit aller jusqu’à la spécification de l’évolution elle-même loin de s’appuyer sur des descriptions qui présentent le système sous forme d’images instantanées. Cela ne veut pas dire que la description doit contenir l’ensemble de toutes les configurations possibles, il est clair que ce mécanisme est inefficace si le système doit s’adapter fréquemment. Darwin [109] fait partie des approches qui proposent la description de la dynamique du système. Cela apparait sous forme de mécanismes explicites d’instanciation des composants du système. UML 2.0 [127] à son tour propose par l’intermédiaire des diagrammes de séquences la description explicitement de la création 46
Composants logiciels et applications à base de composants
d’instances de composant ainsi qu’un ensemble d’invariants du système au niveau de la description de l’assemblage. Globalement, la dynamique de l’architecture logicielle est prise en compte que par peu d’approches, même dans celle-ci, l’évolution n’est pas spécifiée et encadrée totalement. Sur le plan abstraction vis-à-vis de la plate-forme d’exécution, les techniques de description et notamment les ADLs doivent réagir positivement à cet égard. Les ADLs en particulier doivent proposer des mécanismes permettant de profiter de la description d’architecture du système dans la production de l’application et de la génération de code vers différentes plates-formes composants. Cependant, dans certains ADLs l’objectif des spécifications se limite à l’analyse du système à réaliser. De ce fait, ils ne proposent pas de mécanismes de projection de code vers des plates-formes d’exécution. D’autres approches comme celles suivies dans Darwin [109] et SOFA [32] se limitent à proposer une unique plate-forme d’exécution pour leur modèle de composant malgré que les modèles de composant qu’elles proposent et plus particulièrement celui de SOFA sont suffisamment abstraits pour qu’on puisse faire des projections vers d’autres plates-formes à composants. Les techniques qui ne séparent pas la description de l’architecture de l’implantation des services fournis et requis par ses composants mènent à des situations compliquées et très difficiles à gérer si les développeurs veulent par besoins générer du code vers une autre plate-forme à composant. L’approche suivi dans Fractal [30] définit un modèle de composant abstrait avec l’existence de plusieurs implantations permettant de choisir une plate-forme cible en fonction du contexte du système à réaliser. Par exemple, une implantation en C appelée think [51] permet de construire des applications embarquées à base de composants. Alors que pour la construction de système d’information d’entreprise plusieurs implantations en Java comme Julia [31] ou en c++ comme PLASMA [97] sont disponibles, ce que fait de Fractal un bon modèle d’abstraction vis-à-vis de la plate-forme d’exécution. En ce que concerne le critère de la précision dans la description d’assemblages de composants et de leurs interfaces, ces propriétés permettent d’analyser l’assemblage de composants et de statuer par la suite sur le niveau de qualité de service de l’application. Comme les activités d’analyse d’une description d’architecture s’appuient principalement sur la description des interfaces de ses composants, beaucoup d’approches et d’ADLs ont fourni une définition étendue des interfaces de composant pour disposer d’un maximum d’information sur le composant lors de l’analyse de l’assemblage. Parmi ces définitions étendues des interfaces de composants, des approches comme SOFA proposent au niveau des interfaces des composants et des rôles des connecteurs, une description des messages entrants et sortants de ces composants ou de ces connecteurs. D’autres approches se caractérisent par leurs focalisations sur les contrats [113]. Ces derniers se diffèrent des IDL [68] qui ne traitent que les signatures d’interfaces selon une vision purement syntaxique. Les contrats contiennent des informations réparties sur quatre niveaux différents [20] : un niveau syntaxique dans lequel Le contrat n'est assuré que par les signatures des opérations ; le deuxième niveau 47
Composants logiciels et applications à base de composants
concerne les contraintes, où il est décrit pour chaque service offert les conditions d'utilisation et le résultat attendu ; le troisième niveau traite la synchronisation pour garantir la bonne marche du système en cas d'utilisation concurrente de l'interface ; et finalement le quatrième niveau qui représente le contrat de qualité de service. Ce dernier niveau du contrat décrit les conditions d'utilisation de l'interface permettant de garantir la QoS de l'interface. Les approches qui ne proposent pas d’abstraction du comportement du composant proposent l’utilisation de quelques mécanismes d’extension comme les annexes et les propriétés qui permettent d’ajouter de l’information pour caractériser le composant. Grâce à ces mécanismes les différents niveaux de contrats peuvent être décrits. Cependant, pour le moment ces mécanismes sont principalement utilisés pour des propriétés de qualité de service. Des méthodes comme UML component [36] dans laquelle les auteurs utilisent UML et OCL [174] proposent de nombreux mécanismes au niveau du langage pour enrichir la définition de l’interface d’un composant. Si OCL est maintenant convenablement adopté et intégré dans le modèle de composant, la définition d’information relative au comportement à tous les niveaux du composant et le manque de cohérence entre ces informations gênent l’analyse d’un assemblage de composants. Pour finir, pour réussir une bonne utilisation des composants on a besoin d’informations supplémentaires autres que les spécifications fonctionnelles. On a besoin de propriétés extra fonctionnelles qui déterminent les comportements des composants en regroupant des contraintes temporelles comme le temps d’exécution et la latence ainsi que des contraintes liées à la fiabilité, la performance, l’efficacité, la synchronisation et la sécurité. 2.8 Conclusion Dans ce deuxième chapitre, nous avons essayé de donner un aperçu plus ou moins détaillé sur le développement d’applications à base de composant et plus généralement sur la sous discipline du génie logiciel orienté composant. Ce type de développement et qui présente une approche ayant un grand impact sur le développement de logiciel cible comme objectif principal la recherche d’un développement efficace, c'est-à-dire la recherche de méthodes qui permettent un développement qui se fait en peu de temps et produit des applications de qualité. Dans cet aperçu on a présenté les définitions relatives à la majorité des concepts et des notions en relation avec la sous discipline du génie logiciel orienté composant, l’accent est mis sur les définitions faisant le maximum d’accords dans la communauté composant. Egalement on a présenté quelques modèles et approches à composants ayant connu des réussites notamment sur le plan industriel. Nous nous somme intéressé particulièrement aux capacités d’adaptation automatiques des applications à base de composants. Le présent chapitre inclut une étude de quelques mécanismes de reconfiguration automatique d’applications à base de composants qui ont été proposés dans quelques modèles et approches à composants. Nous discutons dans le chapitre suivant la combinaison d’une telle importante approche de développement avec un autre paradigme de développement assez riche et puissant sur plusieurs plans. Il s’agit du paradigme agent et agent mobiles. Nous discutons les apports mutuels et les différentes possibilités de combinaison des deux technologies pour le développement d’applications qualifiées de : ouvertes, distribuées et adaptables. 48
Chapitre III Agents & Composants : Concepts, analyse comparative et apports mutuels
Agents & Composants : Concepts, analyse comparative et apports mutuels
Chapitre III Agents & Composants : Concepts, analyse comparative et apports mutuels
3.1 Introduction La communauté des chercheurs travaillant sur des problématiques liées au développement d’applications et des systèmes informatiques ou des problématiques du génie logiciel en général proposent des solutions dans lesquelles ils combinent souvent plusieurs éléments. Ces éléments peuvent être des techniques, des méthodes, des approches, des modèles et des paradigmes différents dans le but de tirer profit de plusieurs points forts caractérisant chacun de ces éléments d’un coté, et d’un autre côté faire compenser les limites et les faiblesses d’un élément par les caractéristiques avantageuses des autres éléments. Dans cette tendance de combinaison ce chapitre fait l’objet d’étude et d’analyse des différentes possibilités de combinaison de deux approches de conception et de développement de logiciel ayant actuellement un grand impact. Il s’agit de l’approche agent [52] et les systèmes multi agents abrégés SMA [52] d’un côté et de l’autre côté l’approche composant que nous avons présentée dans le deuxième chapitre. Ces deux approches proposent des abstractions pour organiser le logiciel comme une combinaison d’éléments logiciels, avec pour objectifs communs : réduire la complexité ; assurer une meilleure structuration du logiciel ; et de faciliter son évolution. Les systèmes multi-agents à l’aide de leurs capacités d’auto-organisation et d’utilisation de connaissances repoussent encore plus loin le niveau d’abstraction. Le présent chapitre commence par une brève présentation des concepts d’agent, d’agent mobile et SMA. En deuxième lieu nous présentons une comparaison entre les concepts et les approches basées agent et celles basées composant. Comme troisième préoccupation nous essayons de fournir les éléments de réponse pour les questions du comment peut on combiner ces deux approches et d’envisager des apports mutuels entre les concepts d’agent et de composant.
50
Agents & Composants : Concepts, analyse comparative et apports mutuels
3.2 Agents, agents mobiles et SMAs La technologie des agents fait partie du domaine de l’intelligence artificielle distribuée dans laquelle l’intelligence et l’expertise sont distribuées sur un ensemble d’entités logicielles ou physiques autonomes, en interactions, qui travaillent en collaboration pour résoudre un problème ou attendre certains objectifs. Cette technologie a tiré profits d’autres disciplines comme la sociologie, la psychologie sociale et les sciences cognitives. Aujourd’hui la technologie d’agent est largement utilisée et les agents sont impliqués dans plusieurs applications informatiques et plus particulièrement celles caractérisées par la recherche d’atteindre certains buts, puisqu’un agent est une entité qui agit à la demande de quelqu’un pour accomplir quelque chose. 3.2.1. Définitions d’un agent Le concept d’agent comme plusieurs autres concepts est définit de plusieurs manières différentes, quoi que toutes les définitions de l’agent ont quelques points en commun. La communauté scientifique a accepté des définitions parmi lesquelles nous citons la définition de Ferber considérée l’une des premières définitions où « Un agent est une entité autonome, réelle ou abstraite, qui est capable d’agir sur elle‐même et sur son environnement, qui, dans un univers multi‐agents, peut communiquer avec d’autres agents, et dont le comportement est la conséquence de ses observations, de ses connaissances et des interactions avec les autres agents » [52]. Jennings propose la définition suivante : « Un agent est un système informatique qui est situé dans un certain environnement et qui est capable d’effectuer de manière autonome une action afin de répondre aux objectifs pour lesquels il a été conçu » [84].
En synthétisant toutes les définitions proposées pour le concept d’agent, il en résulte qu’un agent est une entité physique ou virtuelle ayant les qualités suivantes: l’agent est capable d’agir dans un environnement ; il peut communiquer directement avec d’autres agents ; son comportement est contraint par des objectifs individuels ; Il possède des ressources propres ; Il est capable de percevoir son environnement et dispose d’une représentation partielle de cet environnement ; l’agent possède des compétences et offre des services ; Il a la capacité de se reproduire ; le comportement d’un agent tend à satisfaire ses objectifs, en tenant compte des ressources et des compétences dont il dispose, et en fonction de sa perception, de ses représentations de l’environnement ainsi que les communications qu’il effectue avec les autres entités. 3.2.2. Caractéristiques d’un agent
Les caractéristiques principales qu’un agent possède et qui sont pratiquement objet de consensus par toute la communauté agent sont définis par Jennings [84]:
51
Agents & Composants : Concepts, analyse comparative et apports mutuels
Situation : l’agent est une entité située, capable d’agir sur son environnement à partir des entrées sensorielles qu’il reçoit de ce même environnement ; Autonomie : l’agent est capable d’agir sans l’intervention d’un tiers (humain ou agent) et contrôle ses propres actions ainsi que son état interne ; Apprentissage : un agent est capable d’apprendre et d’évoluer en fonction de cet apprentissage, il est aussi capable de changer le comportement en fonction des expériences passées ; Mobilité : la capacité d’un agent de se déplacer à travers un réseau d’une machine à une autre ; Flexibilité : cette caractéristique résume les propriétés suivantes : Réactivité : un agent est capable de modifier son comportement lorsque les conditions environnementales changent et de percevoir son environnement et d’élaborer une réponse dans les temps requis ; Pro‐activité : les agents n’agissent pas seulement en réponse à leur environnement mais ils sont également capables d’avoir un comportement guidé par un but en ayant la possibilité de prendre l’initiative ; Sociabilité : l’agent doit être capable d’interagir avec les autres agents (logiciels ou humains) et peut se trouver engagé dans des transactions sociales ; Activité : un agent est toujours actif ; il s’exécute dans un thread ou un processus indépendant ; Communication : c’est la possibilité d’échange de messages entre agents, selon l’un des schémas de communication : Now‐type messaging : dans lequel l’émetteur du message bloque son exécution jusqu’à ce que le récepteur ait téléchargé le message et envoyé sa réponse ; Future‐type messaging où l’émetteur ne bloque pas son exécution mais l’expéditeur retient une variable qui peut être utilisée pour obtenir le résultat et finalement le schéma One‐way messaging qui représente un type de messagerie asynchrone qui ne bloque pas l’exécution courante. L’expéditeur ne retient pas une variable pour ce message et le récepteur ne va jamais répondre. Ce type est utile quand deux agents engagent une conversation où l’agent expéditeur n’a pas besoin de la réponse de l’agent récepteur. 3.2.3 Typologie des agents Principalement les agents peuvent être répertoriés en deux types reflétant chacun une école de pensée dans la communauté des agents: l’école cognitive et l’école réactive. Avec l’existence d’autres types d’agents, qualifiés d’hybrides, et qui utilisent ces deux types de comportements. Les agents réactifs sont de plus bas niveau, ils ne disposent que d’un protocole et d’un langage de communication réduits, ils n’ont pas une représentation globale de leurs environnement et ne sont pas capables de tenir compte de leur actions passées, leurs capacités répondent uniquement à la loi stimulus/ action. Quant aux agents cognitifs, ces 52
Agents & Composants : Concepts, analyse comparative et apports mutuels
derniers possèdent une représentation explicite de leur environnement et des autres agents ; Ils tiennent compte de leurs passés et disposent d’un but explicite; ils possèdent une base de connaissances qui contient toutes les connaissances concernant leurs fonctionnements et leurs environnements. Les agents cognitifs sont dotés de capacités de raisonnement sur leurs bases de connaissances et ils peuvent avoir un monde social d’organisation. Les agents cognitifs se trouvent en petit nombre, ainsi la granularité dans les systèmes composés de ces derniers est faible. Les agents BDI (Belief, Desire, Intension) sont un bon représentant de ce type d’agents qui peuvent être des agents intelligents, des agents collaborant, des agents interfaces …etc. Il en résulte de la combinaison des deux manières de pensée des architectures d’agents composées d’un ensemble de modules organisés dans une hiérarchie, chaque module étant soit une composante cognitive, soit une composante réactive. De cette manière, le comportement proactif de l’agent, dirigé par les buts, est combiné avec un comportement réactif afin d’obtenir les avantages des architectures cognitives et réactives, tout en éliminant leurs limitations [52]. Les architectures hybrides souvent formées en couches dont trois suffisent généralement, la couche de plus bas niveau est une couche réactive qui prend des décisions en se basant sur des données brutes en provenance des senseurs, la couche intermédiaire qui fait abstraction des données brutes et fonctionne selon une vision qui se situe au niveau des connaissances de l’environnement et enfin, la couche supérieure qui se charge des aspects sociaux de l’environnement en tenant compte des autres agents.
3.2.4 Les Systèmes Multi Agents (SMAs)
La mise en œuvre d’un ensemble d’agents mettant en commun leurs compétences et connaissances s’avère plus intéressante que la manipulation d’agents en tant qu’entités individuelles formant ainsi ce qui est appelé un système multi agents. [52] Un système multiagents est un système distribué composé d’un ensemble d’agents. Contrairement aux systèmes d’IA, qui simulent dans une certaine mesure les capacités du raisonnement humain, les SMA sont conçus et implantés idéalement comme un ensemble d’agents interagissant, le plus souvent, selon des modes de coopération, de concurrence ou de coexistence. Les systèmes multi agents sont généralement caractérisés par : la possession limitée des informations ou des capacités de résolution de problèmes de chaque agent ; ainsi que chaque agent a un point de vue partiel; il n’y a aucun contrôle global du système multi-agents; les donnés sont décentralisées; et finalement le calcul est asynchrone. Les agents autonomes et les systèmes multi-agents représentent une approche pour l’analyse, la conception et l’implantation des systèmes informatiques complexes. La vision basée sur l’entité agent offre un puissant répertoire d’outils, de techniques, et de métaphores qui y ont le potentiel d’améliorer considérablement les systèmes logiciels. Les systèmes multi-agents sont présentés comme solution privilégiée pour analyser concevoir et construire 53
Agents & Composants : Concepts, analyse comparative et apports mutuels
les systèmes logiciels complexes [84] puisque en partitionnant le système en N agents réduit sa complexité et la configuration résultante se trouve plus facile à développer, à tester et à maintenir. Les SMAs s’adaptent bien à la réalité dans la mesure où de nombreux problèmes sont de nature distribuée. L’utilisation de nombreux agents résous le problème de façons différentes et produit généralement des solutions de meilleures qualités en termes de compétence, complétude et de précision. 3.2.4.1 Types de systèmes multi agents Les SMAs peuvent être catégorisés selon : le nombre d’agents, la nature et la complexité de ces agents, en : SMAs ouverts : les agents y entrent et en sortent librement. SMAs fermés : où l’ensemble d’agents restent le même. SMA homogène : dont tous les agents sont construits sur le même modèle. SMA hétérogène : dont les agents sont construits sur des modèles différents. 3.2.4.2 La négociation dans les systèmes multi agents
La négociation est le processus d’interaction permettant aux agents de converger vers une décision commune en verbalisant leurs conflits et puis cherchant un accord. Il existe plusieurs types de négociation, comme la négociation heuristique [85], la négociation par argumentation [85] et la négociation pour l’allocation de tâches faisant appel par exemple au protocole Contract Net [158] qui présente un mécanisme de négociation entre deux types d’agents, un contractant et un gestionnaire. Ce dernier commence par décomposer la tache en sous taches puis les annoncer aux autres agents. Les agents peuvent faire leurs propositions en harmonie avec leurs capacités à remplir ces taches. Le gestionnaire rassemble ensuite ses propositions et alloue la tache à l’agent ayant fait la meilleure proposition. 3.2.4.3 Organisation des systèmes multi-agent
Les systèmes multi-agents sont composés d’un ensemble d’agents autonomes en interaction permanente, leurs comportements sont des émergences des comportements des agents qui les composent. Pour contraindre les agents à se comporter de sorte à satisfaire les objectifs globaux d’un système multi agents, les organisations [104] présentent un bon moyen. Les recherches dans les SMA et les inspirations des organisations sociales dans les communautés d’individus dans les contextes sociologiques tout en respectant les contraintes d’opérationnalisation et de mise en œuvre ont permet d’avoir plusieurs modèles organisationnels pour les SMAs. L’étude de l’organisation opérationnalisable [69] est à la 54
Agents & Composants : Concepts, analyse comparative et apports mutuels
fois l’étude du modèle décrivant les échanges potentiels entre agents, et également le schéma explicatif applicable sur le système. L’organisation d’un SMA [104] est un modèle permettant aux agents de coordonner leurs actions pour accomplir une ou plusieurs tâches, elle définit d’une part une structure exprimée en un ensemble de rôles à jouer par les agents ainsi que les communications entre rôles c’est à dire entre les agents jouant tel ou tel rôle. D’autre part l’organisation définit un aspect fonctionnel du SMA en termes de processus de coordination qui déterminent l’allocation des tâches aux agents ainsi que leurs décompositions en sous tâchent. La situation de la connaissance organisationnelle présente un point crucial dans la spécification d’une organisation [79] ; l’organisation peut exister que dans la connaissance des agents, nous parlons alors du point de vue centré agent, où la spécification de l’organisation revient à la spécification des agents eux-mêmes. Le point de vue centré organisation considère l’organisation comme une entité manipulable entant que telle, la spécification dans ce cas est indépendante des agents et de leurs architectures ou leurs choix d’implémentations. Dans ce type d’organisations, les modèles organisationnels – l’organisation est l’implémentation d’un modèle organisationnel - sont nombreux et on trouve les modèles Moïse [71], Moïse+ [ 79 ], le modèle MOCA [ 7 ], le modèle YAMAM [150] …etc. ces modèles organisationnels explicites sont répertoriés en des modèles qui s’appuient sur les plans globaux et ceux qui se focalisent sur les rôles comme Moise [ 70 ], le modèle proposé par Odel [124], AGR [ 53 ],et AGRS[ 105]. Dans les modèles de la seconde classe la spécification de la structure est faite à travers la structuration des rôles dans des formes connues, une structuration en groupe par exemple [69] ainsi que les relations entre les rôles ; la première classe s’intéresse aux aspects plus fonctionnels et dynamiques du système en mettant l’accent sur les plans globaux, les tâches, les ressources et leurs allocations. On note l’existence de modèles comme le modèle Moïse+ [79] qui présentent des tentatives d’union des deux aspects au sein de la même spécification. 3.2.4.4 La réorganisation des systèmes multi-agents
Les systèmes multi-agents s’appliquent particulièrement aux domaines ayant de très fortes dynamiques, il devient très difficile (voire impossible) de prévoir toutes les situations possibles dès la conception. Une situation imprévue peut donc remettre en cause tous le système. Il est donc nécessaire de trouver les moyens pour que les agents parviennent à gérer la dynamique de l’environnement de manière autonome. D’autre part, est il possible établir une organisation idéale pour un problème ou un environnement donné ? C’est peu probable : l’environnement, le contexte des agents n’est jamais complètement maîtrisé, et l’adaptation du système est obligatoire.
55
Agents & Composants : Concepts, analyse comparative et apports mutuels
La réorganisation est l’un des moyens pour qu’un SMA s’adapte aux changements de l’environnement, elle consiste [14] à passer d’une organisation à une autre. Dans le cas où l’organisation s’avère n’est pas la plus appropriée le système procède à une réorganisation et passe à une nouvelle organisation plus adéquate qui améliorera la situation. Ce passage est réalisé par le SMA d’une manière autonome sans intervention externe (auto-organisation). La réorganisation peut être statique est spécifiée par le concepteur qui peut pour des situations spécifiques où l’organisation de départ n’est pas la plus appropriée spécifier d’autres organisations. Une fois ces situations détectées, le système se réorganise selon la nouvelle organisation définie à priori par le concepteur. La réorganisation peut être dynamique, les agents eux-mêmes décident quand et comment se réorganiser, aucune spécification n’est définie à priori, l’avantage de cette dernière par rapport à la réorganisation statique réside dans le fait qu’il est impossible de déterminer toutes les situations possibles et leur vérifier l’adéquaté de l’organisation de départ et en spécifier de nouvelles par la suite.
3.2.5 Les agents mobiles
La mobilité des agents est considérée par quelque chercheurs en tant qu’une des caractéristiques des agents, il s’agit en fait d’une caractéristique supplémentaire permettant à un agent, généralement un agent information, de parcourir un réseau à la recherche d’informations. Plusieurs définitions ont été proposées pour déterminer les éléments entrant dans la formulation du concept d’agent mobile. Les agents mobiles sont définis comme étant : « Des entités logicielles autonomes qui peuvent suspendre leurs exécutions sur une machine et migrer avec leurs codes, variables et états vers une autre machine où ils reprennent leurs exécutions » [16]. Dans [18] une autre définition est proposée : « Un agent mobile peut se déplacer à travers un réseau hétérogène sous son propre contrôle, migrant d’un site à un autre et durant sa migration, l’agent mobile peut interagir avec d’autres agents ou d’autres ressources et revient généralement sur son site initial une fois sa tâche accomplie ». 3.2.5.1 Attributs d’un agent mobile Cinq composants constituent les éléments ou les attributs qui composent un agent mobile: un état, une implémentation (code), une interface, un identifiant et une autorité [16], ces attributs sont transportés par l’agent en se déplaçant à travers le réseau. L’état : l’état d’un agent lui permet de reprendre son exécution quand il arrive à destination après déplacement. L’état d’un agent peut être considéré comme une image instantanée de son exécution. L’implémentation : Comme tout programme, l’agent mobile a besoin d’un code pour pouvoir s’exécuter. Quand il se déplace à travers le réseau, l’agent peut soit emporter son code soit qu’il se déplace à destination puis voir le code qui est 56
Agents & Composants : Concepts, analyse comparative et apports mutuels
disponible sur la machine distante et récupère le code manquant à partir du réseau. L’implémentation d’un agent doit être à la fois exécutable et sans risque pour l’hôte de destination. Les langages interprétés offrent une indépendance par rapport aux plates formes et aux environnements d’exécution contrôlés qui limitent l’accès aux ressources privées des hôtes. L’interface : Un agent fournit une interface qui permet aux autres agents et aux autres systèmes d’interagir avec lui. Cette interface peut être un ensemble de méthodes qui permettent aux autres agents et aux applications d’accéder aux méthodes de l’agent par un système de messagerie. L’identifiant : Chaque agent possède un identifiant unique durant son cycle de vie, cette information permet aux agents d’être identifiés et localisés. Puisque l’identifiant est unique, il peut être utilisé comme clé dans les opérations qui exigent un moyen pour référencer une instance particulière d’agents. L’autorité : Une autorité est une entité dont l’identité peut être authentifiée par n’importe quel système auquel elle essaye d’accéder. Une autorité peut être soit une personne privée, soit une organisation. L’identité est constituée d’un nom et d’autres attributs. Pour les agents, il existe principalement deux types d’autorité : Le fabriquant (manufacturer) qui est le fournisseur du code d’implémentation de l’agent, et le propriétaire (owner) qui a la responsabilité du comportement de l’agent. 3.2.5.2 Caractéristiques d’un agent mobile
Les principales caractéristiques d’un agent mobile [83] sont :
La mobilité : c’est le mécanisme utilisé pour transporter l’agent entre les différents sites. Le déplacement d’un agent est contrôlé par la fonction de migration faible (transfert du code et de données) ou forte (transfert du code, de données et de l’état de l’exécution). La communication : les agents mobiles peuvent communiquer localement sur le même site ou sur des sites différents (communication à distance). La gestion des ressources : Les agents mobiles contrôlent leurs propres ressources afin d’optimiser leurs performances et répondre aux exigences des hôtes. La tolérance aux pannes : comme un agent mobile s’exécute sur un site distant, il est de forte probabilités qu’il aura lieu des pannes (déconnexion, défaillance…).Ainsi, il faut définir des mécanismes de récupération pour relancer l’agent à nouveau, une certaine redondance est nécessaire. La sécurité : l’agent mobile doit s’assurer que ni son code ni ses données ne seront modifiés par le système qui contrôle l’hôte dans lequel l’agent est présent. 57
Agents & Composants : Concepts, analyse comparative et apports mutuels
Sérialisation/Désérialisation : l’agent mobile est composé de code, données et d’un état d’exécution. Avant d’être migré à une autre machine, ceux‐ci doivent être codés sous la forme d’une chaîne de caractères ; on dit que l’agent est sérialisé (processus de sérialisation). La désérialisation est le processus inverse. Il est à noter que la conversion d’un format de codage d’agent à un autre format est trop complexe. Quand les formats de sérialisation des codes d’agents sont similaires, il est possible de construire des ponts entre différents types de systèmes d’agents. 3.2.5.3 Types d’agents mobiles Les agents mobiles sont répertoriés en modèles d’agents selon la nature de la tâche qu’ils sont en mesure d’accomplir. Il s’agit de : Agent statique : il s’agit d’un agent qui fait qu’une seule migration depuis la station de départ vers un nœud défini au lancement. A l’arrivée sur ce nœud de destination, l’agent ne migre plus et se contente d’exécuter la tâche prédéfinie. Agent visiteur : C’est un agent qui visite successivement les différents nœuds de la plateforme afin d’y appliquer la même fonction d’administration du réseau, par exemple, récupérer les versions des systèmes d’exploitation installés sur les nœuds du réseau. Agent collecteur : Les agents collecteurs se déplacent d’un serveur à un autre pour collecter l’information recherchée. Les données collectées ne doivent pas dépasser un seuil de capacité pour ne pas surcharger l’agent mobile. Agent fusion : Les agents fusion se chargent de la fusion des différentes données collectées afin de construire les réponses espérées. Agent ordonnanceur : Le rôle de l’agent ordonnanceur consiste en l’affectation des tâches aux serveurs en minimisant le coût et en respectant la date de fin au plus tard d’une même requête. En effet, plusieurs serveurs peuvent proposer un même service, à des prix différents et avec des durées d’exécution différentes. Agent identificateur : Ces agents décomposent les requêtes reçues en sous‐requêtes composées chacune de tâches élémentaires et indépendantes. 3.2.5.4 Avantages des agents mobiles Les agents mobiles prouvent de nombreux avantages et de points forts vis‐à‐vis des approches classiques. En effet, les agents mobiles permettent : De rapprocher les clients et les serveurs et réduisent ainsi le nombre et le volume des interactions distantes, ce qui permet de réduire le trafic sur le réseau et avoir comme
58
Agents & Composants : Concepts, analyse comparative et apports mutuels
effets la diminution de la consommation de bande passante, la diminution de temps de latence, avoir de brèves périodes de communication, et l’optimisation des traitements. De redéployer des applications de sorte que les sites défaillants et en disfonctionnement peuvent être évités ce qui améliore la tolérance aux pannes. D’obtenir des informations de façon plus précise dans le sens que l’information reflète l’état le plus récent étant donné que le délai est minimal lorsque l’information est accédée localement. D’accéder à certaines données difficiles à atteindre à distance ou via des protocoles peu flexibles. Unifier les différents paradigmes d’interactions (client/serveur, communication par messages, code mobile). S’adapter aux modifications des réseaux et à leur hétérogénéité. En se déplaçant avec leurs codes et données propres, les agents mobiles peuvent s’adapter facilement aux erreurs systèmes. Ces erreurs peuvent être d’ordre purement physique, comme la disparition d’un nœud, ou d’ordre plus fonctionnel, comme l’arrêt d’un service par exemple. Si un service s’arrête, l’agent pourra alors choisir de se déplacer vers un autre site contenant la fonctionnalité désirée. Un agent mobile réside à un moment donné sur un seul site, contrairement aux serveurs multiples statiques demandant une duplication de fonctionnalités sur toutes les localisations; l’agent mobile porte lui‐même ses fonctionnalités et donc aucune duplication n’est requise.
3.2.5.5 Limites et inconvénients des agents mobiles Malgré les apports importants du concept d’agent mobile dans le développement de systèmes et des applications informatiques, les systèmes à base d’agents mobiles soufrent de certaines incommodités que nous pouvons résumer en :
Il est nécessaire de garder le code de l’agent mobile le plus petit possible à fin que la migration des agents n’apporte pas plus de trafic que les applications centralisées. Cette contrainte est difficile à respecter, plus l’agent est intelligent, plus que son code est grand; et plus l’agent accumule de l’information en se déplaçant, plus ce code augmente. Les agents peuvent engendrer un temps de réponse plus long vis‐à‐vis des approches centralisées. Les agents mobiles ne sont pas recevables dans tous les équipements du réseau, certains équipements ne sont pas conçus pour pouvoir recevoir des agents mobiles.
59
Agents & Composants : Concepts, analyse comparative et apports mutuels
Un problème de sécurité sérieux s’impose avec les agents mobiles. Divers hôtes peuvent modifier le code d’un agent mobile, altérer ses données ou même lire des informations qui ne sont pas destinées à ces hôtes. Les agents mobiles sont difficiles à intégrés dans les réseaux du fait que ces derniers sont décrits comme des entités pouvant agir sans l’intervention de l’utilisateur, cette automatisation peut comporter toujours des risques d’augmenter encore les difficultés. La communication entre les agents mobiles demeure complexe ; les systèmes actuels se limitent souvent à un seul agent ou plusieurs agents ayant peu d’interactions entre eux, voire aucune. Les agents mobiles sont difficiles à développer car le code doit être implémenté d’une façon à ce qu’il puisse, par la suite, s’exécuter dans différents environnements. Les agents mobiles sont difficiles à tester et à débuguer car la distribution et la mobilité ne sont pas dans un ordre prédéfini. Les agents mobiles sont difficiles à authentifier et à contrôler. La sécurité des agents mobiles présente un problème délicat qui n’est pas encore intégralement résolu, ce problème est considéré comme le principal argument avancé pour expliquer la faible utilisation de ce paradigme. En effet, les agents mobiles représentent une voie intéressante pour le domaine de recherche en sécurité, d’une part dans la protection des sites vis‐à‐vis des agents malveillants et d’autre part dans la protection des agents vis‐à‐vis des sites malveillants. Trois types de problèmes de sécurité [148] ont été identifiés pour les environnements d’exécution d’agents mobiles : sécurité site‐agent où l’on s’intéresse à protéger les agents des sites malveillants et inversement ; sécurité inter‐agent où l’on s’intéresse à protéger un agent des agents malveillants ; et finalement la sécurité inter‐site où on s’intéresse à empêcher un site malveillant de modifier d’autres sites. Les plates formes supportant les agents mobiles bien que de plus en plus basées sur Java, restent incompatibles entre elles. Plus exactement un agent d’une plate‐forme ne peut pas s’exécuter sur une autre. Si cela ne pose pas de problème dans un univers « fermé », il est tout fait le contraire dans le cas d’Internet. Un tel réseau est un environnement ouvert, peuplé d’applications fort hétérogènes, de services divers, mais surtout de plates formes d’exécution d’agent incompatibles. 3.3 Analyse comparative des approches basées agent et celles basées composant. Pour comparer les concepts d’agent, agent mobile et système multi agent avec le concept composant logiciel nous choisissons un cadre d’analyse à deux dimensions. Ce cadre est un repère dont la première dimension représente le niveau d’abstraction alors que la seconde 60
Agents & Composants : Concepts, analyse comparative et apports mutuels
représente le couplage entre différentes entités. La projection sur la dimension du niveau d’abstraction reflète le besoin progressif d’abstraction qui n’a pas cessé d’augmenter. Ce besoin est témoigné par l’évolution de la programmation et du développement du logiciel allant des procédures et des structures de données, passant par les objets, les acteurs, les composants, les services, les modèles, les ontologies, les agents, les connaissances jusqu’à l’arrivée aux organisations et aux sociétés artificielles. La deuxième dimension représente les aspects liés aux liaisons entre différentes entités logicielles mises en jeu. Cette dimension reflète le besoin croissant en matière de description des liaisons et des relations indépendamment des entités qu’elles relient. Cette dimension exprime également la flexibilité des couplages signifiant la capacité de mettre des relations entre différentes entités logicielles. Le troisième aspect exprimé à travers cette dimension est le besoin de repousser le plus tard possible la décision de choisir l’action à exécuter et qu’elle est l’entité responsable de son exécution. 3.3.1 Agents vs composants par rapport au niveau d’abstraction Sur le plan de l’abstraction trois éléments semblent essentiels pour définir l’espace dans lequel nous pouvons comparer les concepts et les technologies ayant un apport dans la programmation et le développement de logiciel d’une manière générale. Le premier élément représente les possibilités offertes pour identifier des abstractions de plus en plus de haut niveau ; le deuxième élément de définition résume l’évolution dans la représentation et l’explicitation des données et de connaissances manipulées ; le troisième élément concerne l’évolution en termes de représentations et d’explicitations des données et des connaissances échangées et communiquées. Les composants, les agents et les systèmes multi agents s’inscrivent dans le courant d’approches de développement de logiciel qui ciblent d’avoir de plus en plus des niveaux d’abstraction élevés. En particulier les agents et les systèmes multi agents représentent des avancées par rapport aux composants dans le sens d’avoir plus de manipulations et d’explicitations des connaissances plutôt que de données.
Instructions
Procédures
Bas niveau d’abstraction
Type abstrait de données
Objets Composants (messages)
Services
SMA Agent (connaissances) (organisation) (intention …) Haut niveau d’abstraction
Figure 3.1 : Evolution du niveau d’abstraction en programmation
61
Agents & Composants : Concepts, analyse comparative et apports mutuels
La figure 3.1 illustre les positions des composants, des agents et des systèmes multi agents dans un axe présentant l’évolution du niveau d’abstraction en programmation. D’une manière générale la programmation est passée de la manipulation des données à la manipulation des concepts. Les objets représente plus que des structures de données, ils représentent des objets du monde réel, les composants se distinguent d’une granularité plus importante et par la composition. Les agents repoussent encore plus loin le niveau d’abstraction. Les agents et les systèmes multi agents représentent des avancées technologiques par rapport aux composants, les agents et les systèmes multi agents prolongent l’évolution de l’abstraction à travers l’explicitation des connaissances et l’introduction des notions de croyance, but,…, et d’état mental dans les agents cognitifs [52]. En plus que ces notions et ces concepts sont représentés explicitement généralement d’une manière symbolique, ils sont aussi communiqués et échangés entre les agents à fin que ces derniers puissent apprendre ou se coordonner entre eux.
Les langages de communication d’agents comme KQML [55] et ACL [56] apportent encore plus d’explicité et d’abstraction du fait que les informations comme la logique de coordination et qui sont implicites dans les approches à base de composants deviennent explicites. Ces langages peuvent être utilisés pour spécifier le contenu des messages échangés entre les agents. À titre d’exemple une communication ACL peut spécifier une désignation symbolique de l’intention de la communication; le langage de description du contenu utilisé pour décrire le contenu où il peut s’agir d’un langage de programmation comme Java ou un langage de représentation de connaissances adapté comme SL de FIPA [57] ; et l’ontologie des concepts du message, par exemple une ontologie standard pour décrire les concepts entrant en jeu dans la conception de cartes électroniques.
La conception des systèmes multi agents selon un point de vue social repousse encore plus loin l’abstraction. Cette conception guidée par l’organisation fait éloigner et rend plus tardives les questions de mise en œuvre. Généralement des concepts de très haut niveau d’abstraction tel que les rôles [124], les groupes d’agents [53], les mécanismes de réorganisation [14] et l’auto organisation sont proposés et manipulés dans l’organisation des SMAs. Selon [104] L’organisation d’un SMA est un modèle permettant aux agents de coordonner leurs actions pour accomplir une ou plusieurs tâches, elle définit d’une part une structure exprimée en un ensemble de rôles à jouer aux agents ainsi que les communications entre les rôles, c’est à dire entre les agents jouant tel ou tel rôle, d’autre part l’organisation définit un aspect fonctionnel du SMA en terme de processus de coordination qui déterminent l’allocations des tâches aux agents ainsi que leurs décompositions en sous tâches. Les méthodes de conception des systèmes multi agents focalisant sur l’organisation et les modèles organisationnels sont nombreux, nous pouvons citer à titre d’exemples les modèles Moïse [71], Moïse+ [79], le modèle MOCA [7], le modèle YAMAM [150] et le modèle AGRS [105] …etc. 62
Agents & Composants : Concepts, analyse comparative et apports mutuels
3.3.2 Agents vs composants par rapport au couplage entre entités
La mesure de la flexibilité du couplage résumée dans la figure 3.2 peut être faite selon deux volets. Un volet dans lequel la mesure concerne l’aspect de sélection de l’action à exécuter. Et un autre volet qui traite les liaisons entre les différentes entités logicielles. Les technologies de composants et d’agents ont des apports concernant ces deux volets. Si nous voyons les deux technologies dans un cadre de l’évolution de la programmation nous pouvons distinguer l’apport de chacune des deux technologies.
La programmation au début de son histoire était simple. Les différentes instructions sont identifiées par l’intermédiaire de leurs numéros de lignes, ce que signifie que la sélection de l’action à exécuter est exprimée globalement d’une manière statique. La situation est améliorée légèrement avec la programmation structurée où la modularité et l’encapsulation du code ont un impact sur la sélection de l’action à exécuter dans le sens où l’action à exécuter est exprimée via un nom symbolique et non par un numéro de ligne. Les langages de programmation orientés objet apportent une innovation importante avec la réunion des données et des procédures appelées méthodes. La liaison tardive était une avancée déterminante, c'est-à-dire, la méthode à invoquer sera déterminée en fonction de la classe de l’objet effectivement invoqué et non pas en fonction de la déclaration. Nous pouvons remarquer que la sélection de l’action à exécuter est repoussée à l’exécution et non résolue statiquement. Les composants ont apporté les notions du prêt à porter, prêt à déployer et prêt à utiliser. Et là les composants se distinguent des objets qui nécessitent les codes écrits dans leurs classes et leurs superclasses. Les composants contiennent tous leurs codes et toutes leurs documentations. Quant aux agents, la sélection de l’action à exécuter prend tous son sens. L’apport de ces derniers résident dans l’autonomie interne de la prise de décision, ce que signifie que la sélection de l’action à exécuter ne dépend pas totalement de l’entité externe qui à envoyer la requête à l’agent. La sélection de l’action à exécuter dépend de l’état interne de l’agent, de ses connaissances, et de ses objectifs. Les agents à travers l’introduction d’un ensemble de concepts avancés repoussent encore vers l’avant la sélection de l’action à exécuter. A titre d’exemple, la notion d’action persistante structurée [61] dans laquelle l’agent tente d’une manière persistante d’accomplir une mission indépendamment de la manière selon laquelle l’agent est programmé. Dans ce mécanisme d’action le concepteur fournit une description de l’objectif sans programmer explicitement les tentatives. Il à noter que l’action persistante structurée n’est pas l’unique concept influant sur la sélection de l’action à exécuter, la négociation, la réorganisation et d’autres concepts avancés ont un impact certain sur la sélection de l’action à exécuter. L’aspect couvert par le deuxième volet de la flexibilité du couplage concerne les concepts architecturaux de mise en relation structurelle entre entités et les modes de communication entre celle-ci. Les modes de communication sont caractérisés par les modes 63
Agents & Composants : Concepts, analyse comparative et apports mutuels
de désignation du receveur, les modes de transfert de données et les modes de couplage temporel.
Les composants logiciels apportent une amélioration pour le couplage structurel par l’externalisation des références et par leurs descriptions explicites sous la forme d’interfaces fournies (de sortie) et d’interfaces requises (d’entrée). La manipulation du couplage devient ainsi explicite et externe aux entités logicielles. Le couplage est explicité par des connecteurs, qui vont relier les interfaces des composants. Les identifiants de ces interfaces sont appelés des « ports », d’entrées ou de sorties. Dans les technologies précédentes les références n’étaient pas externe, dans le paradigme objet par exemple un objet référence un autre par avoir un attribut dont la valeur est l’identifiant de l’objet référencé ce que implique des modifications à l’intérieur de l’objet en cas de besoin de modification de liaisons. Pour les composants la reconfiguration souhaitée s’opère par un simple ajout de connecteur. Un composant peut posséder plusieurs interfaces d’entrée, et de même pour les interfaces de sortie. C’est une différence importante avec un objet qui n’a lui qu’un identifiant et qu’un point d’entrée. Une conséquence intéressante est que les composants sont compositionnels, c’est-à-dire qu’une composition de plusieurs composants est équivalente à un composant qui posséderait la même union d’ensembles d’interfaces d’entrée et d’interfaces de sorties. Les objets eux ne sont pas directement compositionnels : une composition de plusieurs objets n’est pas immédiatement équivalente à un objet, car elle a plusieurs points d’entrée.
La vision architecturale explicite apportée par les composants est encore un gain en terme d’abstraction de couplage puisque l’accent est mis sur la logique du couplage entre les composants indépendamment de leur implantation interne en se servant des langages de description d’architecture [110] dédiés à la spécification de l’architecture d’une application. Les informations de typage des interfaces des composants sont utilisées pour vérifier la correction de l’assemblage, c’est-à-dire la conformité entre les interfaces mises en relation. Il existe plusieurs types de connecteurs où chaque type s’adapte avec un ou plusieurs styles architecturaux ainsi que les protocoles de communication associés. Les approches à base de composant ne se limitent pas à exprimer des indications sur les types de données (typage) mais également sur les comportements des composants à travers les contrats [113] qui peuvent contenir des indications : syntaxiques, comportementales, de synchronisation, et de qualité de service. Suivant les cas, ils peuvent être garantis, vérifiés ou négociés.
L’organisation du couplage et la coopération entre différentes entités logicielles sont poussées encore plus loin avec les systèmes multi-agents grâce à des mécanismes de coordination, décomposition, négociation et autres mécanismes permettant la collaboration entre plusieurs entités, et à l’aide aussi de la manipulation des connaissances comme 64
Agents & Composants : Concepts, analyse comparative et apports mutuels
l’organisation, les tâches et les plans. Le plus apporté par les systèmes multi-agents réside dans le fait qu’ils proposent un couplage sémantique guidé par les connaissances et par une organisation sociale du travail contrairement aux composants où le couplage est principalement syntaxique (discipline des types) entre les composants. Le concept d’organisation [104] est plus axé connaissances que le concept d’architecture logicielle. Le plus souvent et dans plusieurs modèles organisationnels l’organisation est décrite sous la forme d’un ensemble de rôles [53], [79], [105] et un ensemble de liens entre ces rôles. Les rôles sont joués par les agents. La manière selon laquelle les rôles sont attribués aux agents diffère d’un modèle à un autre. Cette abstraction de l’agent vers le rôle permet une description plus générique de l’architecture de l’application ainsi que les rapports et les interactions entre les agents. En jouant un rôle l’agent référence d’une manière indirecte et implicite l’ensemble des agents remplissant au moment de l’interaction ce rôle. De cette manière, le couplage structurel est externe au même titre que pour les composants, mais avec un degré d’implicite de plus par rapport aux connexions explicites entre composants. Les systèmes multi-agents se distinguent aussi des composants par l’utilisation de divers mécanismes de mise en relation dynamiques et indirects, par exemple, par l’intermédiaire de la consultation d’agents intermédiaires ou d’agents annuaires. La sélection et la contractualisation de partenaires dans l’objectif d’effectuer et de traiter des tâches peut s’effectuer par des mécanismes d’appels d’offre dont le protocole contract net [158] est un bon exemple. Nous concluions par dire que les relations entre les agents sont très dynamiques et gérées en partie par les agents mêmes ou via les organisations. Cela aura pour effet d’apporter en plus de la dynamicité, les capacités d’autonomie ou d’auto réorganisation de l’organisation, qui peuvent évoluer en fonction des besoins soient guidées par un niveau plus haut, soit à l’initiative des agents eux-mêmes. Cela représente des avancées importantes par rapport aux approches basées composants malgré que la communauté des architectures logicielles et des composants aborde également ces enjeux de dynamicité et des capacités de reconfiguration automatique de l’architecture que l’on a discuté dans le deuxième chapitre. Les SMAs répondent mieux aux besoins croissants de flexibilité et donc de délégation de l’initiative, ce qui augmente d’un autre coté les besoins pour l’assurance de certaines garanties sur le fonctionnement du système car l’approche multi-agent malgré quelle est plus ambitieuse, elle reste plus difficile à vérifier.
En termes de communication, les deux technologies d’agent et de composant ont leurs apports. Les composants introduisent une communication multipoints, du fait qu’une sortie d’un composant peut être connectée à plus d’un composant. Cela représentait une avancée par rapport aux objets où le mode de communication entre les objets n’était fondamentalement que point à point avec la désignation explicite du receveur du message. Plusieurs variantes de connecteurs entre composants comme [155] et [65] ont été proposées offrant chacune de 65
Agents & Composants : Concepts, analyse comparative et apports mutuels
nouvelles possibilités pour la gestion indirecte et dynamique des connexions entre composants en introduisant des mécanismes de désignation de receveurs totalement implicites. De l’autre coté, les systèmes multi-agents généralisent le mécanisme de désignation indirecte et dynamique par l’intermédiaire de la consultation d’agents intermédiaires ou annuaires. Un agent peut sélectionner dynamiquement lui-même son interlocuteur d’une manière qui peut être aussi automatique et implicite. Le mécanisme de facilitators [88], les modèles SMA organisationnels basés sur la notion de rôle et les travaux visant à promouvoir l’environnement d’un système multi-agent comme une abstraction privilégiée [177] peuvent servir d’exemples. Dans le mécanisme facilitators la sélection est guidée par le contenu du message. Pour les modèles organisationnels à base de rôle, un agent peut s’adresser à un rôle, par conséquence à l’ensemble des agents remplissant ce rôle à l’ instant de la communication. Le troisième exemple représente les systèmes multi-agents dans lesquels l’environnement est modélisé explicitement, les agents peuvent communiquer via l’environnement, en laissant des données spécifiques.
Dynamicité
Sélection plus tardive de l’action
Autonomie de la décision a propos de l’action à exécuter
Auto organisation et réorganisation
Reconfiguration automatique de l’architecture
-Liaisons explicites et externes - Vision architecturale
Auto contenance du code et de documentations
Agent
Composant
-Rôles et organisations -agents intermédiaires -annuaires -communication via l’environnement -sélection du partenaire
Liaisons implicites et indirectes
Figure 3 .2 : Agent vs composant par rapport aux liaisons et les sélections d’actions.
Concernant les modes de transfert de données, les modèles de composants, tel par exemple le CORBA component model (CCM) [107], proposent souvent deux types de transferts : bidirectionnel par appel de procédure (via des interfaces d’entrée et de sortie, 66
Agents & Composants : Concepts, analyse comparative et apports mutuels
appelées par CCM facettes et réceptacles), et unidirectionnel par diffusion d’événements (via des puits et sources d’événements). Les agents reprennent en général le mode unidirectionnel (et asynchrone) des acteurs [2], c'est-à-dire le transfert souhaité ne s’effectue que de l’émetteur vers le receveur. Si le receveur veut renvoyer une valeur, il doit le faire explicitement par un autre envoi de message. Le mode de transfère de données unidirectionnel et asynchrone entre agent est accompli par le biais de langages de communication d’agents très élaborés qui peuvent aussi spécifier de manière très fine les informations communiquées. La communication entre agents suit en général l’envoi de message asynchrone et unidirectionnel des acteurs [2]. Des langages de communication d’agents permettent de spécifier un protocole associé à une communication. Le protocole systématise la spécification des échanges de messages valides et la synchronisation entre les agents. La spécification du couplage temporel est ainsi beaucoup plus générale et concerne un nombre arbitraire de messages et d’agents. Il existe diverses familles de protocoles d’interaction, de coordination, de négociation, et d’enchères. La communication via un environnement par ajout, enlèvement, ou consommation de données représente à son tour un mode indirect de transfert de données entre les agents.
La mobilité des agents signifiant la capacité d’un agent de se déplacer à travers un réseau pour accéder à des ressources distantes ou pour rencontrer d’autres agents n’apporte pas de nouveau ni en termes de sélection d’action à exécuter ni en termes de modes de transfert de données mais elle a des influences sur la qualité du fonctionnement par rapprocher les clients et les serveurs et donc réduire le nombre et le volume des interactions distantes (en les remplaçants par des interactions locales) ce que permet de réduire le trafic sur le réseau.
3.3.3 Composants et systèmes multi agents pour construire des systèmes ouverts
Les propriétés d’ouverture mentionnées en premier chapitre se trouvent en accord avec les caractéristiques des systèmes multi-agents plus qu’avec les propriétés des composants logiciels, notamment l’hétérogénéité des agents, leurs capacités cognitives et leurs autonomies. Ainsi, l’interopérabilité, les entrées et les sorties des agents et leurs contrôles sont partiellement formalisées et abordées respectivement par des problématiques de langages de communication entre agents, services de pages jaunes et systèmes normatifs. Le défi de l’ouverture dans les systèmes multi agent concernant la propriété d’interopérabilité est comment permettre à des agents ayant des architectures différentes et/ou des langages de programmation différents de pouvoir interagir entre eux et avec les ressources de leurs environnements. Ce volet de l’ouverture couvre deux types d’interactions : interactions agentressource et interaction agent-agent. Pour le premier type d’interactions, nous constatons 67
Agents & Composants : Concepts, analyse comparative et apports mutuels
l’absence de normes prescrivant une description fonctionnelle des ressources ainsi que leurs utilisations. Généralement les programmeurs d’agents implémentent directement dans le code des agents des primitives que ces derniers utiliseront pour interagir avec les ressources qu’ils veulent utiliser. Une telle manière de traitement des interactions de type agent- ressource pose un problème de la découverte dynamique de nouvelles ressources dans un système multi agents ainsi qu’un problème correspondant à la capacité d’interagir avec celles-ci. Il est à noter qu’il existe des travaux comme [104] et [117] où les auteurs proposent quelques notions pour la conception et l’implémentation des ressources dans les systèmes multi agents. Par exemple dans [117] une notion artefact est proposée, le principe est de définir chaque ressource avec la spécification d’un artefact auquel est associé un manuel d’utilisation où l’interface d’utilisation de l’artefact est décrite. Ainsi, les agents peuvent apprendre euxmêmes comment interagir avec les artefacts représentant les ressources de leurs environnements. Les interactions agents – agents sont abordées avec le développement de langages de communication comme KQML [55] et ACL [56] qui permettent aux agents de pouvoir échanger des messages tout en conservant leurs propres architectures. Avec la standardisation FIPA de l’ACL (Agent Communication Language), ce langage devient un standard qui est implémenté dans la plupart des plateformes de programmation d’agents. La spécification standard des communications entre agents permet de faciliter l’interprétation syntaxique des messages échangés entre les agents. En outre, grâce aux protocoles de communication les agents arrivent à se comprendre indépendamment de leurs architectures internes et de leurs langages de programmation. Par ailleurs, la sémantique des messages échangés dépend des applications, d’où il est à la charge des développeurs de préciser quelle est l’ontologie utilisée pour une application donnée pour l’interprétation sémantique des messages échangés. L’interopérabilité sémantique dans les systèmes multi agents présente toujours une problématique ouverte malgré les travaux menés pour la spécification d’ontologie pour les agents [99], et pour impliquer des approches de services web comme [151]et [112] à ce propos. La deuxième caractéristique de l’ouverture concernant l’ajout et la suppression d’entité dans un système informatique trouve une correspondance directe dans les approches à base de composants dans lesquelles des mécanismes pour ajouter et retirer des composants sont proposés. La correspondance est plus directe d'ailleurs dans les systèmes multi agents. Cette correspondance est directe du fait que l’une des préoccupations essentielles dans la conception d’un SMA est celle de définir les moyens permettant aux agents d’entrer, de s’intégrer et de sortir. Il existe plusieurs approches pour la gestion d’arrivées et de départs d’agents dans un SMA. A titre d’exemple, nous pouvons citer l’approche par broker [36], Un broker est un service de courtage qui assure les fonctions de pages jaunes et de routeurs entre les agents d’un SMA. Ainsi, tout agent qui entre dans un SMA s’enregistre auprès d’un broker en précisant ses caractéristiques et ses compétences. Lorsqu’un agent quitte le SMA, le broker dans lequel il est enregistré le supprime de sa liste d’agents. De plus, le broker 68
Agents & Composants : Concepts, analyse comparative et apports mutuels
fournit une liste d’agents qui peuvent réaliser un service sollicité par un agent dont il n’a pas les compétences. Le broker assure les fonctions de routeur lorsqu’il sert d’intermédiaire pour des interactions entre agents [36]. La présence d’un broker n’exclut pas les interactions directes agent – agent. En effet, suite à des interactions entre les agents via le broker, les agents peuvent conserver les références (adresse, compétences, ...) d’autres agents et peuvent par la suite leurs faire appel sans faire intervenir le broker comme intermédiaire. Par ailleurs, cette approche souffre de la centralisation des données relatives aux agents auprès d’un seul composant. Raison pour laquelle des approches de décentralisation des services d’enregistrement et d’intégration ont été proposées en vue d’une gestion collective et coopérative des entrées et de l’intégration d’agents dans un SMA. Parmi ces approches s’inscrit l’utilisation d’agents accueillants [169]. Concernant le contrôle et qui présente la troisième caractéristique de l’ouverture ; Les SMA ont leurs particularités par rapport aux autres systèmes informatiques à travers la distribution et l’autonomie des agents. La distribution permet de répartir la résolution d’un problème sur plusieurs agents, l’autonomie consiste à considérer que l’agent peut prendre individuellement ses décisions sans l’intervention d’aucune entité de contrôle extérieure. Du fait que le comportement d’un agent n’est pas toujours bienveillant vis-à-vis le système, celuici doit imposer un certain contrôle sur l’activité des agents, ce qui est en opposition avec le principe d’autonomie. Dans cette direction de contrôle, les travaux en SMA ont de plus en plus évolué dans le développement des systèmes qualifiés de sociaux en se basant sur les organisations qui régissent les comportements des agents dans une société d’agents. Plusieurs travaux témoignent la grande utilité et l’apport important des organisations non seulement pour mettre œuvre des mécanismes de contrôle de l’ouverture dans les systèmes multi agents mais pour supporter aussi toutes les caractéristiques de l’ouverture concernant l’interopérabilité et la gestion des arrivées et des suppressions d’entités constituant un système. 3.4 Apports mutuels entre approches basées agent et approches basées composant
Les composants logiciels et les systèmes multi agents ont leurs impacts certains sur le monde du développement et de production de logiciels. L’analyse comparative présentée dans la section précédente nous a permis de mettre en clair les empruntes de chacun des deux paradigmes sur le développement de logiciels. Malgré que les systèmes multi agents présentent des avancées technologiques par rapport aux composants, ces derniers préservent toujours quelques atouts incontournables. Particulièrement leurs capacités de structuration et la grande mise en valeur de la réutilisation. Nous pouvons légitimement poser la question sur les apports potentiels des deux paradigmes l’un pour l’autre, en d’autres termes, sur le potentiel de fertilisation croisée entre composants et systèmes multi-agents. 69
Agents & Composants : Concepts, analyse comparative et apports mutuels
Les apports mutuels des deux approches consistent en trois éléments. L’apport potentiel des agents aux composants pour concevoir des applications à base de composants plus autonomes et flexibles, en se servant des techniques de mise en correspondance et de négociations pour une assistance à l’assemblage par exemple ; L’apport potentiel des composants vers les systèmes multi agents apparaît sous forme d’aides à l’intégration, au packaging et au déploiement des systèmes multi-agents ; Et finalement le troisième élément concernant l’apport des composants au niveau d’un seul agent où le composant est utilisé comme moyen pour la structuration et la construction d’agent ou comme une aide à la réutilisation de l’implémentation de son architecture.
3.4.1 Apports des agents et des SMA aux applications à base de composants
Les approches de développement d’applications à base de composants et le CBSE Component based software engineering d’une manière générale soufrent encore de certaines difficultés où des technologies avancées comme celle des systèmes multi agents peuvent intervenir pour résoudre définitivement quelques problèmes ou au minimum améliorer certaines situations.
D’une vision simplifiée le développement d’applications à base de composants logiciels revient à identifier les composants adéquats, souvent à partir de bibliothèques internes ou externes, et les assembler en fonction des objectifs souhaités. Les agents peuvent intervenir en premier lieu pour aider à sélectionner les composants à assembler à partir d’informations sur ce que font ces derniers sous la contrainte d’optimisation de certaines fonctions objectives de caractère fonctionnel ou non fonctionnel. Par exemple, pour minimiser le coût des composants. En deuxième lieu les agents à travers leurs capacités de négociation peuvent fournir des services d’assistance pour la mise en correspondance entre les composants ainsi que l’assistance pour l’assemblage effectif de ces derniers. Les agents et les systèmes multi agents peuvent également être utilisés pour implémenter des mécanismes de reconfiguration dynamique des applications à base de composants. Les agents mobiles aussi à travers leurs capacités de déplacement peuvent être utilisés pour adapter l’architecture physique d’une application à base de composants en les utilisant pour faire déplacer des composants vers d’autres sites d’exécution pour effectuer des redéploiements de l’application. Dans certains travaux de cherche une manière un peu spéciale d’utilisation des agents est proposée. Il s’agit d’une sorte d’utilisations dans lesquels la vision agent est utilisée pour faire une sorte d’agentification des composants dans le but de rendre ces derniers comme étant des entités plus actives tout en préservant les caractéristiques principales des composants, particulièrement l’externalisation des interfaces requises et fournies. 70
Agents & Composants : Concepts, analyse comparative et apports mutuels
3.4.1.1 Agents et SMA pour assister pour la sélection des composants
La classification et la sélection rapide des composants réutilisables présentent une véritable clé de réussite pour le développement d’applications à base de composant du fait qu’elles touchent et actionnent le cœur même du paradigme composant dont la réutilisation est l’un des piliers ayants la plus grande importance. Cette mission de recherche et de sélection de composant peut être déléguée aux agents vu que ces derniers sont bien équipés d’outils pour accomplir cette mission particulièrement à travers leurs capacités de négociation et de mobilité. Cette tendance apparaît dans plusieurs travaux comme celui présenté dans [8] où les auteurs proposent un modèle d’agent mobile appelé C-Agent conçu d’une manière compositionnelle. Les auteurs utilisent l’agent mobile C-Agent pour la recherche et la sélection de composants. Ces derniers doivent fournir une documentation standardisée pour que les agents puissent les trouver. Les agents C-Agent conçu pour tourner sur la plateforme d’agents mobiles MultiTEL2 [8], celle-ci permet la réutilisation des composants arrivants de différentes sources mais conformes avec le Framework de MultiTEL2 par les situés dans des DCR (Distributed Component Repository). Les agents mobiles C-Agent recherchent et récupèrent les composants depuis les DCR selon les besoins du logiciel à développé. Les composants sélectionnés sont inclus dans un outil de conception visuel nommé Visual Design Tool (VDT) pour être utilisés dans la phase de conception. Le besoin de la recherche d’un composant peut apparaitre pendant ou après la phase de conception c’est à dire pendant la conception ou en cours d’exécution de l’application. Nous reviendrons sur d’autres exemples d’utilisation d’agents pour la sélection de composants dans le chapitre IV.
3.4.1.2 Agents et SMA pour assister la mise en correspondance et l’assemblage de composants.
Les agents et les systèmes multi agents particulièrement à travers leurs capacités de négociation peuvent être utilisés pour assister l’assemblage de composants et plus particulièrement pour la mise en correspondance et la vérification de compatibilités entre les composants. L’utilisation des agents et des systèmes multi agents poussent plus loin la mise en correspondance et la vérification de compatibilités pour dépasser le stade de vérification résultant du typage des interfaces et des contrats qui offrent certaines possibilités de vérification de la compatibilité des compositions. Mais les types de données restant souvent de bas niveau, une compatibilité des types ne garantit pas pour autant la compatibilité. Les 71
Agents & Composants : Concepts, analyse comparative et apports mutuels
contrats comportementaux sont d’un niveau plus sémantique, mais restent plus focalisés sur les hypothèses de fonctionnement correct que sur une véritable description des services offerts ou requis par un composant.
Le modèle d’agent LARKS [163] est un exemple d’utilisation d’agent pour la mise en correspondance (matchmaking).le modèle est relativement élaboré et est fondé sur différents niveaux de descriptions (signatures, types, comportementaux, contraintes, ontologiques, …etc), différents types de mesures de similarité, et différents types de politiques de mise en correspondance (exact, inclusion, relâché). L’approche suivie dans LARKS est en fait plus générale et peut s’appliquer à des composants Logiciels, des services ou encore à des agents.
Un autre exemple dans lequel les agents sont utilisés pour assister l’assemblage de composants dans le but d’adapter dynamiquement les services fournis par une application à base de composants est présenté dans [96]. Le travail consiste à étendre le modèle de composant Ugatze [153], adapté à la réutilisation de composants logiciels autonomes, hétérogènes et distribués et qui s’inscrit dans le domaine de l’Ingénierie Dirigée par les Modèles (IDM). L’extension proposée est dirigée vers l’adaptation de composants logiciels en intégrant le principe de variabilité. Le principe de variabilité conduit à distinguer dans la spécification d’un composant une partie fixe et une partie variable. Ces deux parties sont visibles dans la spécification du composant ; elles introduisent le caractère générique du composant. Au moment de la réutilisation, c’est en fixant la partie variable que l’on choisit une réalisation particulière et que l’on adapte le composant en fonction des spécificités du système en cours de développement. Les auteurs proposent d’ajouter une autre catégorie d’interfaces aux composants, ils proposent des «points d’ajustements » dans l’objectif d’avoir un modèle de composant gérant l’adaptation, en plus de l’intégration. Un point d’ajustement est associé à chaque service fournie ou requis, permettant d’adapter le composant à des besoins spécifiques. Les auteurs proposent de faire intervenir des agents pour :(i) exprimer les besoins (interfaces requises), en s’appuyant sur une description sous forme de métainformations ; (ii) Parcourir les cas de réutilisation existants : recherche de cas de réutilisation correspondant aux interfaces requises exprimées par d’autres composants ; et (iii) pour négocier l’adaptation d’un composant d’origine. Lorsque le système nécessite l’adaptation d’un composant, les agents permettent de sélectionner les points d’ajustements adéquats. Bien que l’aspect d’assistance à l’assemblage soit clair dans ce travail, nous pouvons le situer aussi dans la catégorie des travaux d’assistance des agents pour la reconfiguration dynamique de l’architecture d’une application à base de composants.
72
Agents & Composants : Concepts, analyse comparative et apports mutuels
3.4.1.3 Agents et SMA pour assister la reconfiguration dynamique de l’architecture d’une application à base de composants.
Les applications dynamiques et ouvertes particulièrement celles à base de composants engendrent des besoins d’adaptation et de reconfiguration dynamiques au niveau de l’architecture, comme au niveau d’un composant. (L’adaptation des applications à base de composants est détaillée dans la section 2.5 du deuxième chapitre). Ces besoins en termes d’adaptation amènent à une évolution sur le plan des mécanismes d’adaptation, au départ essentiellement réactifs à partir d’évènements, vers des mécanismes de plus haut niveau, à partir de contraintes et de politiques, voire de buts et de plans. Autrement dit, selon une approche multi-agent. L’adaptation des applications à base de composant est devant des besoins insistants pour coordonner des adaptations possibles à différentes entités et à différents niveaux d’une architecture tout en maintenant la cohérence. Ces besoins poussent à la recherche et le développement de mécanismes de reconfiguration de plus en plus cognitifs (planification) et coopératifs (coordination). Cette vue multi agents apparaît dans des travaux sur le réassemblage automatique de composants sans que les agents soient utilisés d’une manière explicite comme l’approche proposée dans [135]. Dans cette approche l’assemblage et le réassemblage automatique de composants sont effectués à travers une analyse et une vérification des propriétés au niveau de l’architecture logicielle, en suite par une génération du code d’assemblage. En cas de changement dynamique d’un composant le contrôle de l’adaptation suspend l’activité de ce composant pendant son remplacement et effectue un transfert d’état du composant vers le nouveau composant.
L’approche présentée dans [86] peut également servir d’exemple. Dans cette approche une notion de composant déplaçable est introduite. Ces composant ne sont pas mobiles au sens agents mobiles et n’ont pas en main ni la décision ni la gestion du déplacement. Ils sont tout simplement des composants logiciels aptes à être déplacés par d’autres entités. La mission de déplacement des composants est à la charge d’un ensemble d’agents mobiles. Les auteurs ont défini une notion de distance logique entre composants. La distance logique entre deux composants exprime le coût d’interaction entre ces derniers. Un système d’agents mobiles est mis en place pour recueillir des informations sur les différents sites dans un réseau où se trouvent les différents composants, ainsi que des informations sur les interactions composant-composant et les interactions composant-ressource. Ces informations servent comme éléments de calcul des différentes distances logiques entre les composants. Dans cette approche orientée structure, les agents mobiles agissent ensemble pour effectuer des déplacements de certains composants en positionnant les composants ayants plus interactions entre eux proches les un des autres dans l’objectif d’avoir un total de distances logiques le plus minimum possible.
73
Agents & Composants : Concepts, analyse comparative et apports mutuels
3.4.1.4 Agentification des composants
Une tendance d’agentification de composant est apparue à travers plusieurs propositions comme l’une des pistes possibles pour combiner les paradigmes de composant et celui d’agent. Cette agentification des composants consiste en une consolidation des composants logiciels par des propriétés des agents tel que l’autonomie ou la mobilité. Une notion de composant mobile a été proposée par [133] en vue de répondre à des besoins propres aux composants en termes de souplesse de déploiement et d’adaptation dans un contexte dynamique. Cette approche s’appuie sur une plate-forme à agents mobiles coopérants qui jouent le rôle de conteneurs. La mobilité des composants est ainsi prise en charge par la mobilité des agents. Cette proposition consiste à étendre une plate-forme à agents mobiles coopérants par une couche de service de composants mobiles. Une telle approche consiste à faire jouer aux agents mobiles coopérants le rôle de conteneurs de composants. Les agents ont pour tâches d’intercepter les appels inter composants. Lorsqu’un composant appelle un composant encapsulé dans un autre conteneur, l’agent conteneur appelant doit alors identifier le composant cible, le localiser et se déplacer vers un(le) site sur lequel il existe un agent conteneur du composant appelé afin de coopérer localement. Une telle approche apporte des propriétés intéressantes comme le : Contrôle de l’accès à un composant dans le sens où le composant n’est accessible que sur les sites qu’il visite ; l’Adaptabilité des composants qui doivent pouvoir être adapté dynamiquement pour répondre à diverses contraintes de caractère non fonctionnel (sécurité, qualité de service) mais aussi aux besoins de ses usagers ; La mobilité des composants facilite et enrichit les possibilités de déploiement et de reconfiguration ; et la Coopération des agents conteneurs qui présente un aspect intéressant dans cette approche, les agents conteneurs, en gérant les composants qu’ils contiennent, peuvent coopérer. On peut envisager que deux agents conteneurs échangent leurs composants pour permettre, par exemple, la migration plus rapide de l’un des deux agents. Cependant cette approche est trop limitée sur le plan pratique vue la difficulté pour gérer l’hétérogénéité des composants, et des environnements de composants et d’agents mobiles. Les composants en réalité sont traités comme des objets java ce que limite autant cette approche. Jadex Active components [140] est aussi un exemple d’agentification de composants. Jadex Active components sont des composants dans le sens où ses derniers représentent des entités logicielles à gérer et qui fournissent en clair des interfaces requises et fournies. Jadex Active components s’exécutent sur la plateforme Jadex [141] et partagent avec les agents la propriété d’autonomie et communiquent via des envois de messages d’une manière similaire à celle utilisée entre les agents. Le comportement d’un composant actif est déterminé par son architecture interne composée d’une manière hiérarchique de sous composants. Cette structure permet d’un côté d’avoir plusieurs types de composants s’adaptant chacun avec des besoins et
74
Agents & Composants : Concepts, analyse comparative et apports mutuels
des domaines précis. D’un autre coté, cette hiérarchisation permet d’assurer des propriétés non fonctionnelles importantes tout comme les composants. 3.4.2 Apports des composants aux agents et aux systèmes multi agents Dans cette direction les travaux sont plus importants en quantité et en qualité par rapports aux travaux appartenant à la catégorie présentée dans la section précédente où les agents sont utilisés pour aider le développement, la mise en œuvre ou l’adaptation des applications à base de composant. Malgré que les agents et les SMA soient de vraies avancées technologiques par rapport aux composants, la maturité des composants les place en position de candidat important pour la structuration et la construction d’agents et de systèmes multi agents. Les travaux entrant dans cette catégories sont nombreux nous pouvons citer les travaux suivants comme exemples :JavAct[101], MadCar-AGENT[67], MALEVA [27], MAST [170], DESIRE [59], MASK [123], VOLCANO [145] et AgentComponent [95]. Nous nous intéressons particulièrement à une sous catégorie de ces travaux. Nous mettons l’accent sur les travaux dans lesquels les composants logiciels sont utilisés pour construire des agents capables de s’auto-adapter. Le développement par composants est en effet intéressant pour ce type de d’application car les agents présentent souvent des capacités proches d’une application à une autre (communication, perception, planification, . . .). La construction d’un agent revient à assembler des composants préexistants qui implémente chacun une partie bien spécifique de l’architecture et du comportement de l’agent. En quelque sorte, un agent est une entité logicielle contenant un assemblage de composants qui matérialise son comportement. Le fait d’utiliser les composants pour construire des agents offre plusieurs intérêts [67] résumés en :
Permettre aux concepteurs de décrire et de gérer de manière unifiée la structure et le comportement des agents.
Favoriser la réutilisation ce qui permettre un développement plus rapide dans lequel les erreurs d’implémentation sont limitées. Les composants permettent de réutiliser des capacités récurrentes chez les agents (communication, perception, planification, . . .). Construire des agents à base de composants consiste principalement à récupérer un ensemble approprié de composants et de les assembler entre eux. Donc, l’utilisation des composants tend à faciliter la construction d’agents. Le fait de réutiliser des composants plusieurs fois augmente la confiance dans ces derniers ce que limite les risques d’erreurs causées à une mauvaise implantation.
Faciliter l’adaptation des agents. Il est assez facile d’ajouter, de supprimer ou de modifier les compétences d’un agent, puisque les applications à base de composants ont l’avantage de pouvoir être réassemblées. Le fait de réassembler un agent à base de composant permet d’adapter à la fois sa structure et son comportement.
75
Agents & Composants : Concepts, analyse comparative et apports mutuels
Néanmoins, le développement d’agent à base de composants n’est pas sans difficultés, généralement cette difficulté est due au haut niveau d’abstraction inhérent à la majorité des modèles de composants. Généralement, les caractéristiques des composants ne sont pas explicites et les interactions entre composants ne le sont pas aussi. Le choix de cette sous catégorie est justifiée par l’harmonie existante entre ces travaux et la vision selon laquelle nous apercevons la solution pour le développement d’applications distribuées ouvertes et adaptables. Dans ce qui suit, nous présentons quelques modèles d’agent capables de s’autoadapter et construit comme étant un assemblage de composants. 3.4.2.1 L’environnement de développement de systèmes multi agents MAST Nous commençons par l’environnement de développement et de déploiement d’applications multi-agents MAST [170]. Dans cet environnement, un SMA est construit comme un assemblage de composants à deux niveaux comme il est illustré dans la figure 3.3. Un niveau composant et un niveau système. Le modèle de composant proposé tient compte de ces deux niveaux, il en résulte de ce fait deux types de composants. Au niveau système, un SMA est composé d’agents considérés comme des composants et de certaines entités fonctionnelles nommées composants orientés système (COS). Au niveau agent, un agent est conçu comme un assemblage de composants, dits composants orientés agent (COA). Pour construire un agent MAST, il suffit de lui ajouter un composant dit noyau et un ensemble de composants fonctionnels (COA). L’environnement MAST permet de connecter automatiquement et de manière flexible les composants qui forment un agent. Le composant noyau est chargé de capturer les événements émis par les différents composants de l’agent. En se basant sur la description sémantique de chaque composant, le noyau transmit chaque événement reçu aux composants capables de le traiter selon un ordre de priorité entre ces derniers. L’intéressant dans MAST c’est les connexions implicites entre les COAs. Les connexions sont automatiquement déduites en fonction des interfaces des composants. Ainsi, l’adaptation des agents qui consiste à lui ajouter ou supprimer des composants est réalisée automatiquement. Le tableau 3.1 résume les dimensions définissant l’adaptation conformément au cadre d’adaptation présenté dans la section 2.6 du chapitre précédant. Malgré la flexibilité introduite par les connexions implicites entre les composants, MAST souffre de plusieurs inconvénients. Principalement, nous pouvons constater facilement l’absence totale de toute sorte de contrôle sur l’assemblage des composants. Ainsi, le risque d’introduire des erreurs dans le comportement de l’agent est important. En outre, le comportement de l’agent après une adaptation ne peut pas être prévu. Les agents MAST ne sont pas totalement auto adaptables malgré que l’adaptation soit réalisée d’une manière automatique puisque c’est le développeur de l’agent qui déclenche les adaptations. L’adaptation ne peut pas être déclenchée qu’en ajoutant ou en supprimant manuellement des composants.
76
Agents & Composants : Concepts, analyse comparative et apports mutuels
Composants orientés agent (perception, communication,… )
COA
COA Noyau d’agent
COA
COA
Nom du composant -Priorité de traitement des événements -Evénements emissibles . - événements traitables.
COA
Exemple d’assemblage Communication -3 -receive
-send
-
Communication Noyau d’agent Perception
Send
Interprétation
Décision
receive
Action
Accès environnement -1 -act
Accès -preceived
Décision -2 -act, send
Act
-preceived, receive
Figure 3.3 : Architecture d’un agent MAST
Initiateur Moment
Le développeur de l’agent qui déclenche les adaptations Le développeur de l’agent déclenche dynamiquement les adaptations par l’ajout ou la suppression de composants.
Sujet d’adaptation L’adaptation de l’architecture physique
Actions de modification et Mise en œuvre Aucune
Composant
Architecture
« Non » L’adaptation de l’architecture logique de l’agent. «Oui»
Ajouter, supprimer ou remplacer des composants. La réalisation des adaptations s’appuie sur un mécanisme de bus logiciel chargé de la distribution d’événements en se fondant sur le « matching » entre interfaces de communication des composants.
Reconfiguration du composant
Aucune
Réimplantation du composant primitif
Aucune
Réimplantation d’un composant composite
Aucune
Tableau 3.1 : L’adaptation dans le modèle d’agent MAST
77
Agents & Composants : Concepts, analyse comparative et apports mutuels
3.4.2.2 Le modèle d’agent MALEVA
Le modèle MALEVA [27] illustré dans la figure 3.4 est un modèle d’agent à base de composants proposé dans une tendance de construire des agents logiciels dont le comportement et la structure peuvent être adaptés. Dans MALEVA les interactions entre composants sont partagées en flot de données et flot de contrôle. Le principal avantage d’avoir un flot de contrôle explicite dans un assemblage de composant est de faciliter l’identification de problème de concurrence. Le concepteur d’agents dispose d’une bibliothèque de composants représentant des comportements élémentaires. Il peut assembler plusieurs composants existants dans un composant composite de manière à constituer des comportements complexes réutilisables dans différents contextes ou différents types d’agents. Concevoir un agent revient à composer, de manière structurelle et fonctionnelle, différents composants comportementaux au sein de l’agent en utilisant un patron de conception permettant d’instancier un comportement complexe abstrait et apte à être spécialisé grâce à l’existence d’un pré câblage entre des composants fixes et des composants à insérer. Un comportement est défini en connectant plusieurs composants dont l’un est un composant de contrôle appelé Switch qui permet de réifier la conditionnelle perception/non perception. La gestion du contrôle revient à définir et ajouter des composants spécifiques chargés de traiter les compositions associées aux données et celles associées aux contrôles.
Les adaptations d’un agent MALEVA sont déclenchées par l’agent lui même une fois qu’un de ses composants de comportement émette une requête dans ce sens. Cette requête est transmise à un composant spécifique appelé « méta composant », qui se comporte comme un fournisseur de profils comportementaux préalablement définis par le concepteur de l’agent. Ces profils prédéfinis décrivent des assemblages spécifiques de composants. Les assemblages non prédéfinis sont contrôlables par le concepteur en se référant aux assemblages prédéfinis. Le tableau 3.2 résume les dimensions définissant l’adaptation des agents MALEVA conformément au cadre d’adaptation présenté dans la section 2.5 du chapitre précédant.
78
Agents & Composants : Concepts, analyse comparative et apports mutuels
Agent MALEVA Méta composant (Profils comportementaux)
Notification Eèèèènnn nbnbnb
Niveau de base
Comportement2
Comportement4
Comportement 3
4
Actionneurs
Capteurs
Comportement1
modification
Comportements (vue simplifiée)
Composant primitif
Flot de données
Composant composite
Flot de contrôle
Figure 3.4 : Architecture d’un agent MALEVA
L’adaptation d’agents MALEVA est faite d’une manière ad hoc. L’évolution d’un agent (ajout/retrait de composants ou de profils comportementaux) nécessite de réimplanter systématiquement la partie de l’agent qui est en charge de l’adaptation (le méta composant). La façon dont sont définis les profils comportementaux des agents n’est pas explicitée, ce qui conduit au fait que les réassemblages de composants doivent être implanté pour chaque profil. Il n’existe pas de mécanisme capable d’adapter un agent selon n’importe quel profil, ce qui a rendu nécessaire d’implanter plusieurs opérations de réassemblage dans un méta composant. L’infrastructure d’adaptation c'est-à-dire le méta-composant n’est pas facilement reconfigurable car le choix des adaptations est spécifié dans le code du méta-composant.
79
Agents & Composants : Concepts, analyse comparative et apports mutuels
Initiateur
l’agent (par ses composants comportementaux)
Moment
déclenchement d’adaptation dynamique à n’importe quel moment, en fonction de l’état et des messages entrants de chaque composant comportement.
Sujet d’adaptation
Actions de modification et Mise en œuvre
Architecture
L’adaptation de l’architecture physique « Non » Ajouter,
supprimer
ou
remplacer
des
L’adaptation de l’architecture logique de composants. l’agent. un méta-composant reçoit les demandes « Oui»
Composant
Aucune
d’adaptation (flot méta) et adapte l’agent selon un des profils comportementaux préalablement définis par le concepteur de l’agent.
Reconfiguration du composant
Aucune
Réimplantation du composant primitif
Aucune
Réimplantation d’un composant composite
Réimplantation de la structure externe du composant ; Réorganisation interne du composite.
Tableau 3.2 : L’adaptation dans le modèle d’agent MALEVA
3.4.2.3 Le modèle d’agent JavAct δ JavAct δ [101] est un modèle d’agents proposé pour la programmation d’applications concurrentes, réparties et mobiles. Il s’agit d’une dérivée du modèle JavAct [11] et de l’architecture réflexive présentée dans [106]. Le modèle repose sur l’idée de permettre aux concepteurs de vérifier l’architecture d’un agent à partir d’une description d’assemblage de composants dans l’objectif de générer des agents flexibles et toujours corrects. Le modèle de composants utilisé est proche d’EJB [162] où un composant est caractérisé par son interface, une ou plusieurs réalisations et un moyen d’exécution. Chaque agent possède un niveau de base contenant du code fonctionnel et un niveau méta décrivant les services non fonctionnels appelés mécanismes opératoires comme la mobilité, la gestion de la boîte aux lettres et la gestion du cycle de vie de l’agent. Chaque mécanisme opératoire est représenté par un composant de granularité fine (ou microcomposant) qui offre un unique service non fonctionnel. Les agents ont une architecture en étoile, ces derniers se composent d’un composant nommé Contrôleur autour duquel sont connectés des microcomposants. Le contrôleur fonctionne comme un bus logiciel et permet d’implémenter le principe de délégation pour faciliter l’évolution de l’architecture. Par ailleurs, le niveau méta de l’agent 80
Agents & Composants : Concepts, analyse comparative et apports mutuels
correspond à un type d’agent défini selon un style d’architecture. JavAct δ permet de concevoir des agents réactifs, des agents BDI, des agents mobiles ou autres types d’agents. Les adaptations possibles dans ce modèle se divisent en adaptations de niveau de base et les adaptations au niveau méta. Une adaptation au niveau de base consiste à remplacer le composant de comportement courant par un autre grâce à une primitive spécifique. Une adaptation au niveau méta consiste à remplacer un microcomposant par un autre. Les adaptations sont dynamiques et pour éviter les problèmes d’incohérence, l’adaptation n’est immédiate que si l’agent est en position observable, comme l’attente d’un message par exemple. Sinon, elle est différée après la fin de l’exécution du comportement courant. Selon les dimensions définis dans la section 2.5 du second chapitre le tableau 3.3 offre une vue résumée sur l’adaptation dans ce modèle.
Micro composant non remplaçable offrant un service non fonctionnel comme envoi de message ou autres services
Niveau méta ReceiveCT
Contrôleur
Micro composant remplaçable mais obligatoire offrant un service non fonctionnel
Analyser
Configuration
Surveillance
Niveau de base Un composant de comportement
Figure 3.5 : Le modèle d’agent JavAct
δ
L’objectif principal de ce modèle et de doter les agents d’une capacité d’adaptation de leurs fonctionnements, en particulier pour leur permettre de s’adapter à leurs environnements d’exécution. Cette approche se distingue des autres approches par l’utilisation du méta niveau de micros composants qui offrent un service non fonctionnel unique. Cela permet d’avoir un niveau méta qui soit configurable, une possibilité de vérifier la correction des modifications 81
Agents & Composants : Concepts, analyse comparative et apports mutuels
de l’architecture – au niveau méta - grâce à un ADL ad hoc. Néanmoins, un agent n’est pas complètement réflexif dans la mesure où certains microcomposants du niveau méta peuvent être non remplaçables : le composant pour la réception de messages, le composant qui implémente la politique d’adaptation et le composant qui implémente les primitives offertes au niveau de base. Le niveau méta de l’agent est reconfigurable mais uniquement de manière statique.
Initiateur
l’agent depuis son niveau de base ou à la demande du concepteur donc depuis le niveau méta
Moment
déclenchement à n’importe quel moment, en fonction du contexte d’exécution et de la politique d’adaptation implémentée dans un composant spécifique Analyser.
Sujet d’adaptation
Actions de modification et Mise en œuvre
Architecture
L’adaptation de l’architecture physique « Non » Ajouter,
supprimer
ou
remplacer
des
L’adaptation de l’architecture logique de composants. l’agent. le niveau méta de l’agent est dynamiquement «Oui»
Composant
Aucune
adaptable grâce à l’utilisation de la réflexion, tandis que le niveau de base de l’agent est dynamiquement adaptable grâce au modèle d’acteur.
Reconfiguration du composant
Aucune
Réimplantation du composant primitif
Aucune
Réimplantation d’un composant composite
Aucune
Tableau 3.3 : L’adaptation dans le modèle JavAct
δ
3.4.2.4 Le modèle d’agent MaDcAr-AGENT MaDcAr-Agent [67] est un modèle abstrait d’agent à base de composants dans le quel les auteurs proposent la description de la structure d’une architecture d’agent auto-adaptable qui s’appuie sur le moteur de réassemblage MaDcAr [67]. MaDcAr est un modèle de moteurs dédiés à l’adaptation dynamique et automatique d’applications à base de composants. Ce modèle fournit une solution basée sur un solveur de contraintes utilisé pour la construction d’applications par assemblage automatique et pour la reconfiguration dynamique de ces applications. MaDcAr établit une séparation entre les spécifications d’applications et leurs implémentations, ce qui permet de spécifier des applications à base de composants sans connaître le modèle concret qui sera utilisé pour les composants. Un moteur d’assemblage MaDcAr permet de construire ou d’adapter une application à partir de quatre entrées : un ensemble de composants à assembler, une description de l’application qui représente la spécification des assemblages valides en termes de propriétés fonctionnelles et extrafonctionnelles, une politique d’assemblage qui dirige les décisions d’adaptation et un contexte 82
Agents & Composants : Concepts, analyse comparative et apports mutuels
qui reflète les informations sur les ressources matérielles et l’état de l’application. Les composants, la description de l’application et le moteur d’assemblage peuvent être réutilisés pour construire des applications différentes. L’architecture de MaDcAr-Agent (figure 3.6) permet d’assembler automatiquement et dynamiquement les composants internes d’un agent. Reposant sur le modèle MaDcAr pour les configurations, MaDcAr-Agent est indépendant de tout modèle spécifique de composant logiciel. L’architecture générale du modèle MaDcArAgent définit trois niveaux principaux dans un agent. Le niveau infrastructure présentant l’interface entre l’agent et son infrastructure de déploiement, c’est-à-dire une infrastructure matérielle et logicielle qui fournit pour l’agent des fonctionnalités pour percevoir et agir sur des entités extérieures. Le niveau de base présentant la partie opérationnelle de l’agent, c’est-à-dire l’ensemble des composants implémentant les comportements de l’agent, ces connaissances ou ces compétences permettant de réaliser des tâches spécifiques. Le niveau méta est celui qui est en charge des adaptations. Il encapsule un moteur MaDcAr qui est connecté au niveau infrastructure et au niveau de base pour percevoir respectivement le contexte externe et le contexte interne de l’agent.
Niveau Infrastructure Communication
Capteurs
Gestionnaire de communication
effecteurs
Assemblage de composants Gestionnaire de contexte
Gestionnaire de contenu
Moteur d’assemblage Politique de gestion du contenu
Desciption du niveau de base
Composants non utilisés
Politique d’assemblage
Niveau Infrastructure
Niveau de base
Contexte interne
Flot de données
Contexte interne
Lien de modification
Composant
Lien avec l’assemblage de composants
Figure 3.6 : L’architecture du MadCar-Agent
83
Agents & Composants : Concepts, analyse comparative et apports mutuels
L’adaptation de l’agent depuis son déclenchement, décision et son exécution est à la charge du niveau méta. En plus du moteur d’assemblage le niveau méta comporte un gestionnaire de contexte de l’agent, une description du niveau de base, la politique d’assemblage, un gestionnaire de communication, un gestionnaire de contenu et la politique de gestion de contenu. Les adaptations peuvent être déclenchées par l’agent de manière régulière, lorsqu’il existe un meilleur assemblage de composants internes que l’assemblage courant. L’utilisation d’un solveur de contraintes dans le processus de décision mis en œuvre dans le moteur d’assemblage permet d’éliminer rapidement les configurations non acceptables ou peu pertinentes, et de choisir une configuration et des composants qui sont les meilleurs par rapport à la fonction de sélection issue de la politique d’assemblage et du temps réservé pour les opérations d’adaptation. En plus, l’agent peut transmettre aux autres agents des composants qu’il n’utilise pas ou les supprimer si nécessaire et ne garder que les composants les plus utiles avec la faveur d’obtenir des composants en faisant des échanges avec d’autres agents. Le tableau 3.4 offre un aperçu rapide sur L’adaptation des agents MaDcAr-AGENT. l’agent par son moteur d’assemblage.
Initiateur Moment
déclenchement d’adaptation dynamique à n’importe quel moment, en fonction de la politique d’assemblage et du contexte d’exécution qui est obtenu d’après le gestionnaire de contexte.
Sujet d’adaptation
Architecture
L’adaptation de l’architecture physique
Actions de modification et Mise en œuvre Aucune
« Non » Le moteur d’assemblage révise les composants
L’adaptation de l’architecture logique de et leurs connexions puis procède à ajouter, l’agent. supprimer ou remplacer des composants.
Composant
« Oui» Reconfiguration du composant
Aucune
Réimplantation du composant primitif
Aucune
Réimplantation d’un composant composite
Aucune
Tableau 3.4 : L’adaptation dans le modèle d’agent MadCar-Agent
Ce modèle d’agent se caractérise par l’utilisation d’un niveau méta qui est configurable à travers deux politiques d’adaptation : l’une centrée sur le réassemblage des composants et l’autre centrée sur les ajouts et suppressions de composants. L’infrastructure d’adaptation est reconfigurable en modifiant la politique d’assemblage et la politique de gestion du contenu de l’agent. Les adaptations prennent en compte l’état des ressources de l’agent. La réutilisation est favorisée dans ce modèle du fait que les éléments définissant ce modèle sont suffisamment abstraits pour être réutilisés dans plusieurs agents composés de différents composants 84
Agents & Composants : Concepts, analyse comparative et apports mutuels
instances de différents modèles de composant. Néanmoins en compte aucun aspect social des agents.
ce modèle d’agent ne prend pas
3.4.2.5 Le système M&M, la construction d’agents mobiles à base de composants
Les travaux de Paulo Marques et Luis Silva concernant le système d’agents mobiles M&M publiés dans [134] peuvent servir d’exemple pour l’utilisation des composants comme unités de construction d’agents mobiles. Dans l’approche suivie dans M&M, les auteurs cherchent à bâtir une architecture d’agent mobile en mettant l’accent principalement sur les aspects et les possibilités de réutilisations. Contrairement aux modèles déjà présentés, cette approche ne traite pas l’adaptation de l’agent comme étant une préoccupation essentielle. L’objectif du projet M&M est de faciliter le développement et l’intégration des agents mobiles dans des applications ordinaires. Par applications ordinaires les auteurs désignent des applications multi agents qui ne nécessitent pas forcement des plateformes agents pour quelles puissent être exécutées. Dans M&M la notion de plateforme comme étant une extension du système d’exploitation est éliminée, on n’utilise pas une plateforme agent comme une couche au dessus des systèmes d’exploitation pour fournir des fonctionnalités que les agents utilisent. Après avoir développé la plateforme JAMES [157], et après plusieurs expériences de développement de systèmes multi agents sous JAMES, les auteurs ont constaté que l’utilisation d’une plateforme comme un intergiciel (middleware) limite considérablement l’acceptation des agents mobiles comme étant un paradigme de programmation et de structuration d’application. Ainsi dans le système M&M il n’existe pas de plateforme pour exécuter les agents. Ces derniers arrivent à l’application et partent directement. Les fonctionnalités que les plateformes offrent sont remplacées par l’incorporation d’un ensemble de composants logiciels dans l’application même. Ces composants fournissent aux agents les capacités particulières pour l’envoi, la réception et l’interaction avec d’autres agents. Les agents deviennent mobiles à travers l’utilisation des composants offrants les services de mobilité. M&M propose une palette contenant des composants de différents types. Le développement d’une application consiste en sélectionner des composants et les reliés par les différentes glues possibles. Les types de composants sont : les composants sur étagères qui représentent une catégorie de composants commercialisés et qui sont utilisés sont être réimplémentés, actuellement il existe plusieurs composants pour différents besoins, pour construire des interfaces utilisateurs graphiques, pour accéder à des bases de données et pour plusieurs autres besoins ; les composants spécifiques à des domaines précis, il s’agit des composants qui implémentent des besoins liés au contexte dans le quel l’application est développée ; et finalement des composants de mobilité d’agents qui fournissent aux agents mobiles les besoins que les plateformes d’agent fournissent d’une manière générale. L’adaptation n’est pas prise en compte comme une préoccupation essentielle dans les travaux de Paulo Marques et Luis Silva concernant le système d’agents mobiles M&M. Mais 85
Agents & Composants : Concepts, analyse comparative et apports mutuels
l’adaptation est implicitement traitée car le fait d’utiliser les composants offre des possibilités d’adaptations puisque ces derniers peuvent être supprimés ou remplacés. D’un autre côté la mobilité des agents peut être vue comme une forme de redéploiement et de reconfiguration de l’architecture physique de l’application. Néanmoins cette approche en réalité ne fait que contourner les plateformes vu que les composants qui la remplacent doivent être présents sur tous les sites sinon ils doivent êtres déplaçables avec les agents mobiles ce qui augmente considérablement les coûts des déplacements des agents. l’agent ou l’administrateur.
Initiateur
N’est pas traité
Moment
Architecture
Sujet d’adaptation
Actions de modification et Mise en œuvre
L’adaptation de l’architecture physique
Déplacement des composants par les
« possible »
agents en se déplaçant ajouter,
supprimer
L’adaptation de l’architecture logique de composants. l’agent.
ou
remplacer
des
Composant
«Oui» Reconfiguration du composant
Aucune
Réimplantation du composant primitif
Aucune
Réimplantation d’un composant composite
Aucune
Tableau 3.5 : L’adaptation dans le système M&M
3.5 Synthèse sur les possibilités de combinaisons des composants, des agents et des agents mobiles Du fait des besoins croissants en termes de dynamicité, de répartition et d’ouverture des applications, les composants d’un côté et les agents, les systèmes multi agents et les agents mobiles d’un autre, proposent des éléments de solutions très importants basés sur la combinaison de plusieurs entités logicielles pour développer ces applications. Les composants arrivant en une phase de maturité industrielle poussent progressivement le niveau d’abstraction et les capacités d’adaptation des applications par l’auto reconfiguration des composants et des architectures. Les agents d’une manière générale, les agents mobiles et les systèmes multi agents se trouvent dans un stade avancé grâce à une armada de méthodes, de méthodologies, d’outils et de plateformes. Il est très naturel de voir les communautés composant et agent cherchent à prospecter les possibilités, les manières et les niveaux de fertilisation croisées des deux approches.
86
Agents & Composants : Concepts, analyse comparative et apports mutuels
Il est extrêmement difficile de faire des comparaisons objectives et complètes entres les différents travaux dans les quels les concepts liés aux composants et ceux liés aux agents sont combinés. Cette difficulté provient du fait que ces travaux visent des objectifs différents et combinent les éléments de plusieurs manières très différentes. Dans un premier sens, il existe des approches dans lesquelles les composants sont utilisés pour construire et \ou déployer des agents et des systèmes multi agents. Cette utilisation peut aller de l’utilisation d’une simple vision compositionnelle jusqu'à l’utilisation effective des composants et des modèles de composants, tout en visant des objectifs allant d’une aide pour spécifier les comportements des agents jusqu'à la construction d’agents à base de composants et le développement de systèmes multi agents dynamiques et auto-adaptables. Dans l’autre sens, les agents et les systèmes multi agents sont utilisés pour développer ou au moins aider pour développer des applications à base de composants logiciels. Cette utilisation des agents prend diverses formes et vise différents objectifs. Les travaux présentés dans la section 3.3.1 ainsi que l’approche que nous avons proposée dans [156] peuvent servir d’exemples. Les agents et les systèmes multi agents présentent deux approches parmi plusieurs approches et techniques qui ont été proposées et utilisées pour développer des applications de plus en plus ouvertes, distribuées et adaptables. Selon plusieurs expériences les systèmes multi agents présentent une solution privilégiée pour développer ce genre d’applications. Le caractère d’adaptation d’une application est un atout crucial dans les applications d’aujourd’hui vu que ces dernières sont soumises à des contraintes liées à des environnements caractérisés par de forte dynamicité. Dans les systèmes multi agents adaptables, les compétences et les comportements d’adaptation sont situées, soit au niveau des agents, soit à un niveau supérieur par rapport à ces derniers où l’adaptation peut apparaitre par exemple sous forme de mécanismes d’organisation et de réorganisation décrits et manipulés explicitement indépendamment des agents. Dans les approches centrées agent, c'est-à-dire les approches où les compétences relatives à l’adaptation sont situées au niveau de l’agent, nous pouvons distinguer des approches dans les quelles les concepteurs s’appuient sur la notion de composant pour concevoir et développer les agents, et d’autres approches où l’architecture des agents est définie sans faire intervenir les concepts de composant et de composition. A travers l’étude de quelques modèles d’agents nous pouvons déterminer l’impact de l’architecture de l’agent sur les possibilités d’adaptation de ce dernier ainsi que les possibilités d’adaptation des applications à base d’agents. Dans les architectures d’agents qui ne s’appuient pas sur les composants comme InterRRap [119] ou autres architectures proposées, il est toujours possible de mettre en œuvre des mécanismes d’adaptation. Cette adaptation est centrée sur les comportements des agents et non pas sur leurs structures internes. Ces architectures généralement en couche, ne permettent pas aux agents de modifier leurs structures internes dans l’objectif d’ajouter ou supprimer des fonctionnalités. En outre, une couche faisant partie d’une architecture est difficilement réutilisable pour concevoir une autre architecture d’un autre agent, cela est du au fait qu’une couche dépend en général étroitement des autres couches faisant partie de la même architecture. Par contre à ces approches, pour les 87
Agents & Composants : Concepts, analyse comparative et apports mutuels
architectures d’agent basées sur le concept de composant il est possible d’adapter la structure interne d’un agent et par conséquence son comportement. Cette aptitude permet aux agents d’ajouter ou de supprimer des fonctionnalités en ajoutant, remplaçant ou supprimant des composants. Les modèles d’agent à base de composants se diffèrent les uns des autres, certains sont théoriques, d’autres sont implémentables dont certains ont des environnements dédiés. Ces modèles d’agent présentent généralement des tentatives pour définir des architectures d’agent hautement configurables en se basant sur le concept de composant. Chacun de ces modèles d’agent possède certaines caractéristiques qui reflètent la mise en avant de quelques propriétés des agents tel que l’autonomie, la mobilité,…etc. L’étude de quelques modèles d’agent à base de composant nous a montré des possibilités intéressantes sur le plan de développement d’agents auto-adaptables qui peuvent être modifiés dynamiquement. Un agent construit par un assemblage de composant peut être traité comme étant une application à base de composants, son adaptation est considérablement proche à celle des applications à base de composants présentée dans la section 2.5 du deuxième chapitre. Ainsi, il devient possible de modifier profondément à la fois la structure et le comportement d’un agent par ajouter, remplacer ou supprimer des composants ou par la reconfiguration des liens entres les composants sans être obligé de modifier les composants eux-mêmes. Sinon, il est possible de faire intervenir toutes ces actions ensembles pour modifier l’agent. Cette aptitude est particulièrement appréciable pour développer des applications ouvertes, c'est-à-dire des applications aux quelles il est possible d’ajouter ou de retirer des fonctionnalités d’une manière dynamique. Depuis son émergence, la communauté agent avait l’objectif de développer des agents capables de déclencher et de réaliser des adaptations voulues d’une manière purement automatique et sous le contrôle entier des effets de ces adaptations. Dans le contexte de contrôle des effets de l’adaptation il est préférable de pouvoir définir les adaptations autorisées. Il est fortement recommandé d’avoir des moyens pour qu’on puisse s’assurer que les adaptations des agents réalisées automatiquement finissent par avoir des agents dont les comportements sont cohérents. Les profils comportementaux de Maleva et les mécanismes de vérification a posteriori des adaptations de JavaAct que nous avons présentés s’inscrivent dans ce contexte. Dans MadCar le déclenchement et l’exécution d’une adaptation ne nécessite aucune intervention humaine, tout est achevé automatiquement, MadCar propose aussi des techniques intéressantes pour contrôler les modifications effectuées lors d’une adaptation. Pour atteindre l’objectif de développer des agents capables de déclencher et de réaliser des adaptations d’une manière purement automatique et sous le contrôle entier des effets des adaptations, il nous semble très important d’utiliser des concepts de haut niveau pour décrire les capacités d’adaptation des agents. Ces concepts de haut niveau comme les politiques et les configurations sont utilisés au niveau des modèles d’agents puisque ils peuvent pousser en avant la séparation des préoccupations et la réutilisation. Par exemple les politiques d’assemblage et le gestionnaire de contexte de MadCar ont leurs impacts à cet égard. L’utilisation des composants permet de mettre en œuvre ces concepts que nous qualifions de 88
Agents & Composants : Concepts, analyse comparative et apports mutuels
haut niveau, elle permet aussi la mise en évidence des éléments essentiels de l’adaptation en explicitant les stratégies de déclenchement et de contrôle des adaptations à la manière des composants de contrôle de Maleva. Dans un environnement ouvert, pour qu’une application à base d’agents soit adaptable, les agents doivent pouvoir s’adapter selon une fréquence plus ou moins élevée et de manière conduisant au maximum d’autonomie possible. Pour que cette autonomie des agents soit garantie, l’infrastructure de l’adaptation doit faire partie intégrante du modèle d’agent, ce dernier contrôle lui-même son état interne. De cette manière on s’assure que les adaptations ne soient pas intrusives. D’autres propriétés sont aussi souhaitables dans l’infrastructure de l’adaptation de l’agent, particulièrement la simplicité d’utilisation et la richesse en expressivité. L’emploi des composants pour développer des architectures d’agents permet à certaines mesures d’avoir des architectures avec toutes ces propriétés. En plus de ces propriétés, les architectures d’agents gagnent considérablement en matière de réutilisation. Cela ne veut en aucun cas dire que la problématique de réutilisation est réglée définitivement. Le concepteur des composants doit de son côté doter ces derniers d’interfaces les plus génériques possibles pour que les composants soient en mesure d’être utilisés dans différents agents encapsulant différentes structures. D’un autre côté, le concepteur de composants doit intégrer les aspects extra fonctionnels dans les composants pour que les développeurs d’agents puissent les utilisés dans différents agents sous différentes contraintes liées aux environnements d’exécution. La réutilisation ne se limite pas en une réutilisation des composants eux-mêmes dans différents agents mais elle concerne aussi la réutilisation des comportements complexes des agents, c'est-à-dire la réutilisation d’assemblage de composants pour reproduire des comportements prouvés. La réutilisation des comportements complexes est un problème qui est mal traité, peu de travaux se sont intéressés à la prise de comportements éprouvés dans un contexte données et les réutilisés dans d’autres contextes. L’adaptation des agents peut répondre à des besoins propres aux agents eux-mêmes, les agents peuvent s’adapter aussi pour répondre à des besoins liés au niveau application ou SMA dans une perspective d’équilibration de charge par exemple. Cette séparation n’apparait pas – à notre connaissances – dans la majorité des travaux ciblant de fournir des solutions pour adapter dynamiquement des agents à base de composants. Nous pensons qu’il serait intéressant si les approches de développement d’agent à base de composant fournissent les moyens pour décrire explicitement et séparément les adaptations qui répondent à des besoins propres aux agents et celles qui répondent à des besoins propres à l’application. Cette séparation permet de catégoriser les composants en deux classes dont les éléments de chacune sont utilisés selon le besoin d’adaptation. L’utilisation des composants en respectant la vision de séparation décrite dans le paragraphe précédent permet d’exploiter la dimension sociale des systèmes multi agents. L’organisation des systèmes multi agents qui présente une clé de conception importante et une avancée très importante en termes d’abstractions et de références indirecte et implicite 89
Agents & Composants : Concepts, analyse comparative et apports mutuels
d’agents (dans les organisations basées sur le concept de rôle, en jouant un rôle l’agent référence d’une manière indirecte et implicite l’ensemble des agents remplissant au moment de l’interaction ce rôle). Malgré les avancés apporter par l’organisation des SMA , elle n’est pas exploitée pour principalement contraindre les agents à base de composants pour se comporter de certaines manières lors de l’exécution des tâches de caractère applicatif et pour s’adapter à fin d’être mieux conformes avec l’organisation ou même pour réaliser de nouvelles organisation (réorganisation). Nous pensons que le fait de prendre un point de vue social comme clé de conception des systèmes multi agents dont les agents sont à base de composants pousse vers le haut la barre des limites, et offre plus de possibilités d’adaptation. La réorganisation en tant qu’un moyen d’adaptation et en tant qu’un cadre d’analyse nous conduit à faire une séparation entre les modifications de l’architecture de l’agent pour des raisons comportementales et les modifications pour des raisons extra fonctionnelles tel que la variabilité des ressources physiques par exemple. La mobilité des agents présente une caractéristique très intéressante. Depuis leurs apparitions comme étant un paradigme de développement, les agents mobiles n’ont pas cessé de contribuer dans l’amélioration de la qualité du développement ainsi que la qualité d’applications développées notamment en termes de répartition et d’adaptabilité. La mobilité des agents apporte par nature une certaine adaptabilité aux applications développées à base de ces derniers. Un agent qui se déplace pour accéder par exemple à une ressource dont l’accès à distance est compliqué, difficile ou coûteux, cet agent est entrain de répondre en quelques sortes à des besoins d’adaptations exigeant un redéploiement physique de certaines entités de l’application. Malgré les problèmes accompagnant la mobilité des agents, spécialement les problèmes de sécurité et malgré que la forme d’adaptation provenant de la mobilité ne concerne pas l’aspect fonctionnel des applications en se limitant à des aspects uniquement opérationnels et extra fonctionnels, la mobilité des agents reste intéressante pour le développement d’applications distribuées, ouvertes et adaptables vu les avantages des agents mobiles que nous avons présenté dans la section 3.1.5.4 du présent chapitre, plus particulièrement sur un plan du génie logiciel où les agents mobiles présentent des unités de structuration des applications ; ils unifient en un modèle unique plusieurs paradigmes d’interaction entre entités réparties (client-serveur, communication par messages, code mobile). Dans plusieurs travaux les agents mobiles sont combinés avec les composants pour développer des applications ouvertes, distribuées et adaptables. Dans certains de ces travaux, la mobilité apparaît comme une simple propriété tout comme l’autonomie ou toutes autres propriétés des agents. Dans d’autres, l’accent est mis sur la mobilité et les propositions reposent sur le fait que les agents sont mobiles. Plusieurs formes de combinaisons des deux paradigmes ont été proposées. On distingue dans [86] que les agents mobiles sont engagés pour effectuer un redéploiement physique d’une application à base d’une variante de composants déplaçables. Les agents en se déplaçant dans le réseau, procèdent à collecter des informations relatives aux états des sites du réseau. En travaillant ensemble les agents agissent 90
Agents & Composants : Concepts, analyse comparative et apports mutuels
collectivement à placer les composants par les déplacer vers les meilleurs sites tout en réduisant au maximum les coûts des communications entre les composants. Les coûts de communication entre les composants sont exprimés à travers la définition d’une notion de distance logique entre les composants. Dans [133] une autre forme de combinaison des composants et des agents mobiles est proposée, les agents mobiles sont utilisés cette fois comme étant des conteneurs pour les composants. Par leurs pouvoirs de mobilité les agents font des composants qu’ils contiennent des entités mobiles. Dans [100] l’auteur propose une architecture d’agent mobile à base de microcomposants. Dans cette approche, il est ciblé comme objectif le développement d’agent mobile auto adaptatif. L’approche proposée s’avère très limitée en termes d’adaptation puisque l’accent est mis sur l’adaptation du fonctionnement des agents, c’est-à-dire sur leurs activités non-fonctionnelles, en particulier pour leurs permettre de s’adapter à leurs environnement d’exécution. En plus, certains microcomposant sont non remplaçables ce que limite encore l’adaptation de l’agent. Finalement, La question que nous pouvons poser légitimement est : quelles sont les meilleures formes de combinaisons des composants logiciels, des agents et des agents mobiles qui permettent de tirer profit au maximum des avantages des deux paradigmes à savoir la structuration et la réutilisation du côté des composants et de tous les avantages provenant de l’utilisation des agents et des agents mobiles ?
3.6 Conclusion Ce chapitre avait comme objectif de fournir une plateforme sur laquelle devient possible l’exploration et la recherche des différentes manières possibles pour combiner les concepts et les enjeux parvenant de deux communautés ayant un grand impact sur le monde de développent de logiciels et plus particulièrement les applications distribuées, ouvertes et adaptable. Pour atteindre cet objectif, après une brève présentation des agents, agents mobiles et systèmes multi agents, on a procéder à faire une analyse comparative entre les concepts de composant et d’agent selon une vision basée sur l’évolution de la programmation. Cette analyse nous a permet de mesurer la grandeur de l’impact de chacune des deux approches sur le développement de logiciel par rapport aux critères d’abstractions et de couplage entre différentes entités dans une perspective de l’évolution de la programmation. Après cette analyse comparative, on a présenté des études qu’on a fait sur plusieurs propositions dans les quelles les agents et les composants sont combinés, ces études nous ont permet de faire une classification des apports mutuels des deux approches ainsi qu’une synthèse définissant les principaux repères où peut on situer les différentes possibilités de combinaisons des composants d’un côte et les agents, agents mobiles et systèmes multi agents de l’autre. Ce chapitre étant le dernier de cette première partie de l’état de l’art contenant en plus de ce chapitre, un chapitre centré sur le développement à base de composants où une attention particulière est prêtée aux possibilités d’adaptation et un autre chapitre introductif dans le
91
Agents & Composants : Concepts, analyse comparative et apports mutuels
quel on a présenté les concepts et les enjeux du développement d’applications distribuées ouvertes et adaptables.
92
Développer des applications distribuées ouvertes et adaptables en combinant : composants logiciels, agents et agents mobiles
Chapitre IV Développer des applications distribuées ouvertes et adaptables en combinant : composants logiciels, agents et agents mobiles
4.1 Introduction L’ouverture, la distribution et l’adaptation s’imposent comme caractéristiques ayants d’extrêmes importances dans les applications informatiques de nos jours comme nous l’avons mentionné dans le premier chapitre. Le développement d’applications distribuées, ouvertes, et adaptables nécessite des moyens qui peuvent fournir des solutions qui sont en mesure de répondre aux exigences ainsi qu’aux caractères spécifiques imposés sur les applications par les propriétés d’ouverture, de distribution et d’adaptation. La propriété de distribution impose qu’une application soit implémentée sous forme d’un ensemble d’entités logicielles et qui s’exécutent sur des machines distantes avec une distribution des computations et une décentralisation des ressources et des connaissances. La propriété d’ouverture impose de son côté que les applications doivent obéir à des règles d’interopérabilité, de pouvoir changer de frontières par l’ajout (intégration) de nouvelles entités ou par la suppression (retrait) de quelques unes parmi celles qui la composent tout en assurant un contrôle sur les échanges entre les applications et leurs environnements. Quant à l’adaptation, cette propriété impose que les applications soient capables de réagir en s’adaptant en réponse à des besoins applicatifs ou pour être plus conformes avec les environnements d’exécution qui ne cessent de changer constamment. Les propriétés de distribution, d’ouverture et de d’adaptation ne sont pas totalement indépendantes les unes des autres. Par contre, les aspects couverts par chacune des propriétés sont fortement liés les uns aux autres. Par exemple, l’ajout ou l’intégration de nouvelles entités dans une application et qui présente un volet important de la propriété de l’ouverture peut un considéré comme un support pour l’adaptation en réponse à des besoins applicatifs pour acquérir de nouvelles fonctionnalités.
93
Développer des applications distribuées ouvertes et adaptables en combinant : composants logiciels, agents et agents mobiles
Dans ce chapitre on présente l’approche que nous proposons pour développer des applications distribuées, ouvertes et adaptables et qui consiste à combiner les composants logiciels et les agents mobiles de manière à satisfaire la majorité des exigences et des contraintes imposées par les propriétés d’ouverture, de distribution et d’adaptation que nous avons présenté dans le premier chapitre. Réellement, l’approche proposée ne se limite pas aux agents mobiles, l’approche est plus générale et nous utilisons le concept d’agent d’une manière générale en traitant la mobilité de ce dernier comme toutes autres propriétés des agents telles que l’autonomie et la flexibilité.
4.2 En quoi les agents et les composants peuvent servir ?
Les composants logiciels et les systèmes multi agents présentent actuellement deux approches de développement de logiciels très importantes et qui sont toutes les deux bien équipées de moyens et d’outils leurs permettant de contribuer considérablement dans le développement d’applications distribuées, ouvertes et adaptables. Les approches de développement à base de composants ainsi que celles basées agents proposent des abstractions pour organiser le logiciel sujet de développement en un ensemble d’entité logicielles dans le but de réduire la complexité, d’assurer une meilleure structuration du logiciel ainsi que pour mieux gérer son évolution. Nous avons étudié d’une manière détaillées les apports importants de chacun des deux paradigmes composant et agent à travers l’analyse comparative présentée dans le troisième chapitre. Nous pouvons résumer ces apports dans les points suivants : Le paradigme des composants logiciels et celui des agents d’une manière générale (qu’ils soient mobiles ou non) assurent chacun de son côté des niveaux d’abstraction élevés ainsi qu’une grande flexibilité du couplage entre les différentes entités logicielles qui constituent un système. Les composants se distinguent des technologies antérieures par une granularité plus importante et par la composition. Les agents de leurs côté favorisent la manipulation ainsi que l’explicitation des connaissances et des concepts de très haut niveau comme les buts, les plans, les croyances et les états mentaux des agents. En plus de la manipulation des ces concepts de très haut niveau, ces derniers sont communiqués et échangés entre les agents. La considération d’un point de vue social pour la conception des systèmes multi agents pousse encore très loin le niveau d’abstraction. Cette conception dirigée par l’organisation rend tardives les questions d’implémentation et fait introduire des concepts de niveaux d’abstraction plus élevés encore comme les rôles, les groupes d’agents et les mécanismes de réorganisation. Concernant la flexibilité du couplage entre différentes entités constituantes d’une application, les composants logiciels permettent d’améliorer le couplage structurel par 94
Développer des applications distribuées ouvertes et adaptables en combinant : composants logiciels, agents et agents mobiles
l’externalisation des interfaces des composants et leurs descriptions explicites sous formes d’interfaces requises et d’interfaces fournies. Cette externalisation des interfaces a permis de manipuler explicitement le couplage entre les composants indépendamment de ces derniers. Ce n’était pas le cas dans les technologies antérieures où la manipulation du coulage ne peut pas se faire sans affecter les entités participantes dans le couplage. Par exemple, pour le développement à base d’objet, un objet référence un autre objet par avoir un attribut dont la valeur est l’identifiant de l’objet référencé. Cela implique que la modification du lien entre les objets provoque une modification au niveau des objets. La vision architecturale explicite apportée par les composants représente une avancée pour l’abstraction du couplage entre différentes entités constituant une application du fait que l’accent est mis sur la logique du couplage entre les composants sans se soucier de leurs implémentations internes. Les systèmes multi agents poussent encore plus loin les questions de couplage par les mécanismes de coordination, de décomposition, de négociation et par des mécanismes permettant la collaboration entre les agents ainsi que par des mécanismes pour la manipulation des connaissances comme l’organisation, les tâches et les plans. Les systèmes multi agents se distinguent des composants qui se limitent à des couplages syntaxiques par un couplage sémantique guidé par les connaissances et l’organisation sociale. Dans les systèmes multi agents conçus selon des modèles organisationnels basés sur le concept de rôle [124], l’abstraction des agents vers des rôles permet une description générique de l’architecture de l’application à développer ainsi qu’une description générique des relations et des interactions entre les agents. En jouant un rôle, les agents référencent tous les autres agents jouant le même rôle au moment de l’interaction. De cette manière, le couplage structurel est externe tout comme pour les composant mais avec un degré supplémentaire d’implicite par rapport aux connections entre les composants. En plus de cette abstraction, les systèmes multi agents proposent des mécanismes d’interaction indirecte entre les agents comme la consultation d’agents intermédiaires ou des agents annuaires. Cette propriété qui permet à une entité (agent) de sélectionner sont interlocuteur de manière indirecte et implicite est particulièrement intéressante pour le développement d’applications ouvertes où des entités peuvent à tout moment rejoindre ou quitter l’application. La communauté composants logiciels introduit une communication multipoints et propose plusieurs variantes de connecteurs entre composants permettant ainsi une gestion dynamique des connexions entre les composants. Les agents de leurs coté permettent aussi une gestion dynamique des connexions aussi que la gestion des connections indirectes entre les agents. Un agent peut dynamiquement choisir son interlocuteur d’une manière automatique et implicite dans les systèmes multi agents organisationnels basés sur les rôles, les systèmes multi agents qui s’articulent sur les agents intermédiaires et annuaires ou les systèmes multi agents où les agents communiquent via l’environnement en laissant des données spécifiques. 95
Développer des applications distribuées ouvertes et adaptables en combinant : composants logiciels, agents et agents mobiles
La mobilité des agents influence la qualité de fonctionnement des applications distribuées par réduire le nombre et le volume d’interactions distantes entre les agents ainsi que par l’amélioration de la tolérance aux pannes en permettant aux applications de continuer à fonctionner en déplaçant leurs entités depuis des sites défaillants vers d’autres qui sont mieux fonctionnels. La mobilité des agents peut être considérée en quelque sorte comme un support pour mettre en œuvre des mécanismes d’adaptation pour les applications distribuées. Cette forme d’adaptation permet aux applications de réagir et mieux se conformer avec les changements dans les environnements d’exécution. Par exemple, un agent qui s’exécute sur un équipement dont la source d’alimentation électrique est une batterie sur le point d’être totalement déchargée, peut quitter cet équipement et continuer à fonctionner sur d’autres sites. Aussi, pour des raisons d’équilibration de charge les agents peuvent changer de localités. Les systèmes multi agents ainsi que les approches de développement à base de composants supportent naturellement la distribution des applications qui consiste à l’implémentation de celles-ci sous formes d’entités logicielles s’exécutant sur des machines distantes. Dans le cas des systèmes multi agents ces entités correspondent aux agents, pour les approches de développement à base de composants les entités constituant l’application sont des composants qui peuvent être simples ou composites. Par rapport aux caractéristiques liées à la propriété d’ouverture, les systèmes multi agents sont bien outillés. Particulièrement l’hétérogénéité des agents, leurs capacités cognitives et leurs autonomies. L’interopérabilité et le contrôle des agents sont partiellement aborder dans les problèmes de langages et de protocoles de communication entre les agents. En outre, l’une des préoccupations essentielles lors de la conception des systèmes multi agents est la définition de moyens avec lesquels les agents peuvent entrer, s’intégrer et quitter le système. Ce dernier point concernant l’ajout et la suppression d’entités dans un système trouve une correspondance directe dans les approches de développement à base de composants logiciels qui proposent des mécanismes pour ajouter et pour retirer des composants. Concernant la propriété d’adaptation, les mécanismes de reconfiguration dynamique d’applications à base de composants qu’offrent certaines approches de développement par composant présentent de réelles solutions pour construire des applications flexibles et adaptables. De leurs côté, les approches orientées agent et plus particulièrement celles focalisées sur l’organisation et la réorganisation offrent plusieurs solutions très intéressantes pour les problèmes en relation avec l’adaptation. Maintenant, les empruntes de chacun des deux paradigmes sur le développement de logiciels sont bien claires. Et nous pouvons constater que malgré que les systèmes multi agents présentent des avancées technologiques par rapport aux composants, ces derniers préservent toujours quelques atouts incontournables. Particulièrement leurs capacités de structuration et de reconfiguration dynamique ainsi que la grande mise en valeur de la réutilisation. Il est temps pour se poser la question : quelles sont les meilleures formes de combinaisons des composants logiciels, des agents et des agents mobiles qui permettent de 96
Développer des applications distribuées ouvertes et adaptables en combinant : composants logiciels, agents et agents mobiles
tirer profit au maximum des avantages des deux paradigmes à savoir la structuration et la réutilisation du côté des composants et de tous les avantages provenant de l’utilisation des agents et des agents mobiles ? Nous présentons dans les sections qui suivent l’approche que nous proposons pour le développement d’applications distribuées, ouvertes, et adaptables. Dans cette approche nous avons cherché une combinaison entre les composants logiciels et les agents en considérant la mobilité de ces derniers comme étant une simple propriété tout comme l’autonomie et les autres propriétés des agents. 4.3 Approche proposée : Construire des MASs sous l’angle d’organisations flexibles en utilisant des agents adaptatifs à base de composants. Nous avons exposé dans la section 3.4 du troisième chapitre les déférentes manières selon lesquelles les composants logiciels et les agents sont combinés. Nous pouvons résumer ces formes de combinaison possibles en : l’utilisation des agents pour concevoir des applications à base de composants plus autonomes et flexibles, en se servant des techniques de mise en correspondance et de négociations pour une assistance à l’assemblage ou pour la gestion d’une reconfiguration dynamique d’une application à base de composants ; l’utilisation des composants logiciels qui apparaît sous forme d’aides à l’intégration, au packaging et au déploiement des systèmes multi-agents ; l’utilisation des composants au niveau d’un seul agent où le composant est utilisé comme moyen pour la structuration et la construction d’agent. En outre, les composants sont d’une utilité pour aider à la réutilisation de l’implémentation de l’architecture de l’agent. Les approches existantes que nous avons étudiées et présentées dans le chapitre précédant et dans lesquelles les composants et les agents étaient combinés n’ont pas exploité toute la puissance des deux paradigmes ensemble. Plus particulièrement, la dimension sociale (l’organisation) [104] des systèmes multi agents malgré son importance n’a pas été mise en valeur dans toutes les approches proposées. L’approche que nous proposons est centrée sur une organisation flexible basée sur le concept de rôles [124] joués par des agents auto adaptatifs construits par assemblages automatiques de composants logiciels. Avant de présenter l’approche proposée, nous présentons d’abord les apports potentiels des organisations et du concept de rôles qui nous ont poussé à s’appuyer sur ces deux concepts pour développer des applications distribuées, ouvertes et adaptables. 4.3.1 Organisations, Rôles et réorganisation Les systèmes multi agents représentent une solution privilégiée pour développer des applications distribuées [84]. Cela est dû à la nature de leurs compositions, les SMAs étant composés d’un ensemble d’agents (entités logicielles ou matérielles) interagissant, le plus 97
Développer des applications distribuées ouvertes et adaptables en combinant : composants logiciels, agents et agents mobiles
souvent, selon des modes de coopération, de concurrence ou de coexistence. Les SMAs offrent une abstraction naturelle et de très haut niveau très souhaitable pour le développement d’applications distribuées. Les organisations dans les systèmes multi agents permettent d’obtenir des degrés supplémentaires en termes d’abstractions. Selon une vision organisationnelle, un système multi agents est analysé comme étant une organisation computationnelle en utilisant des concepts sociaux comme les rôles [124] et les normes [165]. Il existe plusieurs différentes définitions pour l’organisation dont on a déjà présenté quelques unes dans le troisième chapitre ; nous pouvons dire en peu de termes, qu’une organisation multi-agent est un ensemble d’agents qui interagissent suivant une structure, des schémas de coopération et des normes prédéfinis pour atteindre des objectifs définis. L’organisation permet aux agents de savoir quels sont leurs partenaires et quels rôles ils jouent de façon à répondre à un objectif donné. C’est un arrangement des agents et de leurs comportements conditionné par les contraintes imposées par l’environnement. Parmi les intérêts de l’organisation lors du développement d’un système multi agents est que la conception de ce dernier guidée par l’organisation fait éloigner et rend plus tardives les questions de mise en œuvre et qu’elle permet d’introduire et de manipuler des concepts de très haut niveau d’abstraction tel que les rôles [124], les groupes d’agents [53], les mécanismes de réorganisation et d’auto organisation. L’organisation peut être un cadre idéal pour gérer l’ouverture d’un système [93]. L’évolution de l’utilisation des technologies des systèmes multi agents vers des applications plus ouvertes a encouragé les recherches pour développer des langages de communication pour permettre à des agents hétérogènes d’interagir. Ce pas vers l’ouverture a été suivi par plusieurs autres et les systèmes multi agents ont passé du stade de la communication simple à la recherche d’agents ayant les compétences ou services qui correspondent le mieux aux besoins d’un système ou d’un autre agent. Dans cette tendance se sont développés par exemple des travaux sur les systèmes pages jaunes qui référencent les agents selon les rôles auxquels ils sont enregistrés. D’un autre coté, Les standardisations d’un langage de communication FIPA ACL [56] et d’une architecture de SMA avec un service de pages jaunes par la FIPA [58] ont contribué à produire des bases pour l’ouverture. Les organisations apportent aux SMA des outils de structuration des agents, de représentation de leurs répartitions de tâches ainsi que des règles qui régissent leurs comportements et les régulations qui en découlent [93]. La modélisation permet ainsi de réduire la complexité des problèmes traités ainsi que de faciliter les modifications et les adaptations des aspects logiciels par : la structuration des SMA et qui est généralement définie dans les modèles organisationnels avec des concepts sociaux tel qu’équipe, groupe, et rôle ; La répartition des tâches qui résulte d’une décomposition des objectifs de l’organisation en sous-objectifs et sous tâches à réaliser par les agents auxquels auront été attribuées ; Les règles de régulation définies par des normes qui établissent les permissions, obligations, interdictions des rôles et des agents au sein d’une organisation. Les travaux sur l’organisation et les modèles organisationnels que l’on trouve dans la littérature couvre chacun de sa part un ou plusieurs aspects de l’ouverture et qui entrent sous 98
Développer des applications distribuées ouvertes et adaptables en combinant : composants logiciels, agents et agents mobiles
l’angle de l’interopérabilité, l’entrée/sortie des entités ou le contrôle des échanges avec l’extérieur. Les organisations sont décrites par des langages de modélisation d’organisation qui permettent la réalisation des spécifications organisationnelles qui concernent différentes dimensions : structurelle, dialogique, fonctionnelle, contextuelle et normative. Les organisations spécifiées avec un langage de modélisation d’organisations sont gérées par une plate-forme appelée infrastructure de gestion d’organisation qui implémente les mécanismes de gestion relatifs au langage de modélisation. La plate-forme permet de gérer les différents services relatifs au fonctionnement d’instances d’organisations. Les plateformes gèrent principalement les échanges avec les agents extérieurs qui concernent principalement la gestion de procédures d’entrée d’agents et les activités des agents après leurs entrées au sein d’une organisation. Cette gestion prend à sa charge la coordination, la régulation des comportements et la gestion des sorties. Le concept de rôle a permis l’augmentation du degré d’abstraction. L’abstraction de l’agent vers le rôle permet une description plus générique de l’architecture de l’application ainsi que les rapports et les interactions entre les agents. En jouant un rôle l’agent référence d’une manière indirecte et implicite l’ensemble des agents remplissant au moment de l’interaction ce rôle. De cette manière, le couplage structurel est externe et implicite. Pour cette raison nous constatons que dans la littérature plusieurs modèles organisationnels utilisent la notion de rôle comme moyen d’entrée dans une organisation. Le concept de rôle est utilisé de plusieurs manières différentes dans les approches et les modèles organisationnels des SMA. Le concept de rôle peut prendre des sens variés selon les modèles et les contextes, certaines approches comme ROMAS [179] et AGR [53] se focalisent sur les aspects conceptuels. De telles approches, exploitent le rôle au niveau de modélisation et même au niveau d’implémentation. Le concept de rôle est abordé dans d’autres approches d’un point de vue structuration organisationnelle où l’accent est mis sur les liaisons entre agents et rôles. Par exemple, dans certains travaux, l’agent est utilisé comme entité à laquelle des rôles sont attachées. Nous pouvons citer à titre d’exemples quelques façons d’exploitation des rôles dans quelques modèles organisationnels. Dans le modèle organisationnel AGR [53] basé sur les concepts agent, groupe et rôle, le rôle est une abstraction d’une fonction ou une position sociale occupée par un agent dans un groupe. Dans le modèle proposé par Colman [40] le rôle est vu comme l’exécution d’une fonction dans l’organisation ; les rôles sont indépendants des agents ; ces derniers sont attachés aux rôles dès qu’ils possèdent les capacités nécessaires pour exécuter les fonctions liées aux rôles. Dans le modèle organisationnel ROMAS [179] le rôle est utilisé pour exprimer d’un point de vue conceptuel une contrainte qui détermine les interactions et l’évolution de l’agent, d’un point de vue implémentation le rôle encapsule des attributs et des comportements de l’agent. Les rôles et les relations entre eux sont figés, aucune modification peut être effectuée ni au niveau du rôle ni au niveau des relations entre les rôles. L’organisation dans ce modèle n’existe que dans les relations entre les rôles. Cette manière d’utilisation des rôles est mal adaptée aux systèmes ouverts où une structuration des agents en groupes est préférable. Dans YAMAM 99
Développer des applications distribuées ouvertes et adaptables en combinant : composants logiciels, agents et agents mobiles
[150] le rôle est utilisé avec les notions de compétences, tâches et agent. Un rôle peut être un
service, une fonction ou une position identifiant l'agent. Jouer un rôle revient à exécuter une ou plusieurs tâches qui nécessitent des compétences. Le concept de groupe n'a pas de modélisation concrète dans le modèle, mais relativement remplacé par une notion de réseaux d’accointances qui n’existent qu’aux niveaux des agents. Cela constitue d’un côté une perte d'un moyen de structuration important pour les systèmes ouverts. D’un autre, il semble que le mécanisme de réseaux d’accointance est irréalisable dans un système ouvert car le contrôle de la structure devient très difficile. Une autre manière d’utiliser les rôles peut être identifiée dans Moise+ [79]. Il s’agit d’un modèle organisationnel basé sur les notions de groupe et de rôle tout comme son prédécesseur Moise [71]. Dans les deux modèles le rôle est utilisé pour la restriction de l’activité individuelle de l’agent. Le rôle dans ce modèle est un ensemble de missions qui spécifient un comportement attendu d'un agent défini par des combinaisons d’obligations et d’autorisations sur les buts et les actions. Les interactions et les échanges entre agents sont structurés par les liens organisationnels entre les rôles. La non prise en compte des événements imprévus peut mettre les agents dans une situation où ils n'ont aucun moyen leurs permettant de résoudre les conflits possibles, ce qui rend ce modèle difficilement utilisable dans un environnement ouvert. Le modèle est orienté vers les agents BDI, cette dépendance entre modèle organisationnel et architecture d'agents limite le modèle à des types d'agents particuliers. Nous pouvons citer encore pour finir le modèle organisationnel AGRS [105] successeur du modèle AGR où la notion de rôle est redéfinie. Le modèle est fondé sur la notion de service, qui permet aux agents d’exprimer leurs besoins et compétences au travers de descriptions de rôles. Le rôle décrit les services qu’il fournit. Ces services sont exécutés par les agents joueurs du rôle et utilisés par ses agents utilisateurs. Les services fournis par un rôle sont publiés dans le cadre de la description de son groupe. Le rôle est vu comme une frontière entre agents exécutant des services, et les agents utilisateurs des services. Pour jouer ou utiliser un rôle l’agent doit entrer dans le groupe qui le contient. L’agent joue un rôle dans une entité appelée AgentInRole, encapsulant les variables qui concernent le cycle de l’exécution du rôle. Contrairement aux modèles déjà présentés, dans AGRS les groupes sont dynamiques, l’utilisation de la notion de publication et de recherche de service ainsi que la manière d’exploitation de la relation entre le rôle et l’agent permettent de qualifier ce modèle d’être adapté aux systèmes multi-agents déployés à grande échelle, ouverts et très dynamiques. Néanmoins, comme pour la plupart des modèles organisationnels, dans AGRS la conformité de l’agent avec les rôles n’est pas traitée. L’étude des différentes approches organisationnelles dont lesquelles la notion de rôle est utilisée ainsi que nos objectifs pour développer des applications distribuées, ouvertes et adaptables nous ont permet de dégager les points suivants : Baser une organisation d’un SMA sur le concept de rôle permet de séparer les agents des systèmes dans le sens qu’une abstraction est faite sur l’architecture interne des agents et aussi sur la structure organisationnelle et le raisonnement. Pour les
100
Développer des applications distribuées ouvertes et adaptables en combinant : composants logiciels, agents et agents mobiles
systèmes ouverts ce point semble d’une grande utilité car on peut avoir des agents de types différents qui arrivent et sortent du système en tout moment. Un point très important et difficile à traiter surtout dans le cas des systèmes ouverts et dynamiques est la définition des critères pour associer les agents aux rôles. La difficulté résulte du fait que les frontières et les objectifs du système peuvent être changés dans le temps. le rôle peut être utilisé pour la restriction de l’activité individuelle de l’agent dans le sens contraindre le comportement de ce dernier pour bien se rencontrer avec les objectifs globaux du système. Le fait de figer les relations entre les agents, les groupes et les rôles supprime toute dynamique du système. Les agents doivent pouvoir appartenir ou quitter les groupes selon certains objectifs ou critères d’une manière dynamique. Les critères et conditions pour jouer un rôle doivent être situés au niveau des rôles. Le filtrage des agents pour jouer un rôle doit être souple et loin de la vision dichotomique qu’un agent est soit capable ou non capable pour jouer le rôle. L’ajout, la modification et la suppression des rôles doivent être possibles. Une description comportementale explicite associée au rôle est souhaitable. Dans cette description le comportement attendu de l’agent joueur de rôle est décrit d’une manière explicite. Cela permet de mieux mesurer la capacité des agents pour jouer le rôle.
Le dernier point qui nous intéresse concernant l’organisation, c’est que cette dernière permet d’offrir un support très puissant et très important pour l’adaptation à travers les possibilités d’évolution des organisations ou en d’autres termes à travers l’auto-organisation. L’auto-organisation est une faculté très importante dans l’adaptation des systèmes multiagents. L’auto-organisation peut s’effectuer par : la modification des connaissances des agents (apprentissage des expériences passées, évolution des compétences, révision de croyances, buts…) ; la distribution de cette connaissance dans le système ; par la modification de la structure organisationnelle par changement de rôles ; spécialisation ; suppression et ajout d’agents, ou par délégation. La manière selon laquelle une auto organisation est effectuée dépend essentiellement du fait que l’organisation est manipulable explicitement entant que telle ou elle n’existe que dans les connaissances des agents. Il est à noter que dans les SMA deux grandes communautés abordent la problématique des organisations multi-agents. La communauté SASO (Self-Adaptive ans Self-Organising systems) dont les approches sont centrées agents [99], ces approches s’intéressent principalement au développement de comportements locaux de chaque agent ainsi qu’aux d’interactions pair-à-pair adéquates dont le résultat émergeant constitue une organisation [136]. Il est clair que le fonctionnement des organisations réalisées selon cette vision peut conduire à des phénomènes imprévisibles et a priori non vérifiables formellement. Dans la communauté COIN (Coordination, Organizations, Institutions, and Norms in Multi-Agent Systems) les approches de développement d’organisation sont centrées sur les organisations. 101
Développer des applications distribuées ouvertes et adaptables en combinant : composants logiciels, agents et agents mobiles
En effet, les organisations sont préalablement spécifiées ainsi que les mécanismes de coordination des comportements des agents. Concrètement, contrairement aux approches utilisées dans la communauté SASO, les approches utilisées dans la communauté COIN visent à assurer certains invariants comportementaux des agents [136]. 4.3.2 Vue d’ensemble Notre objectif principal consiste à proposer une approche pour développer des applications distribuées, ouvertes et adaptables. Nous pensons que Les Systèmes multi agents SMA et plus précisément les systèmes multi agents organisationnels peuvent être considérés comme solution privilégiée pour concevoir et mettre en œuvre de telles applications. Cela est dû aux arguments que nous avons déjà présentés dans des sections précédentes ainsi qu’à la nature de la composition des SMAs. Les SMAs étant composés d’agents autonomes mobiles ou non mobiles en interactions permanentes où le comportement global du système émerge des comportements des agents qui le composent. L’adaptabilité de l’application à développer est retardée pour apparaitre comme une adaptabilité au niveau du SMA, ce que signifie pour nous, que le développement d’une application adaptable revient en un développement d’un système multi agents adaptable. Parmi plusieurs moyens possibles, nous choisissons de prendre un point de vue social – Organisationnel -comme clé pour concevoir les systèmes multi agents. Ainsi, L’adaptabilité du SMA est assurée par une flexibilité et une auto adaptabilité de l’organisation. Cela signifie que nous proposons un model d’organisation flexible des systèmes multi agents pour développer des SMAs adaptables. Comme plusieurs autres modèles organisationnels tel que Moïse+ [79], le modèle MOCA [7], le modèle YAMAM [150] et le modèle AGRS [105], le modèle que nous proposons et détaillons au long de ce chapitre se focalise sur le concept de rôle. Ce choix est justifié par les apports importants de ce concept que nous avons discutés dans la section précédente. L’espace fonctionnel du SMA est structuré en rôles joués par des agents auto adaptatifs à base de composants dans ce que nous appelons F-groupes. Un F-groupe est un ensemble flou [181] d’agents qui peuvent jouer le rôle associé au F-groupe. Selon leurs capacités de jouer un rôle donné, un degré d’appartenance au F-groupe est associé à chaque agent voulant jouer le rôle. Il s’agit de partitionner les agents en deux classes : capables et non capables de jouer un rôle. Or, il n’ya pas de moyen pour fixer un seuil pour cette capacité. La théorie des ensembles flous apparait comme un outil bien adapté pour modéliser un concept vague tel que la capacité des agents pour jouer des rôles. Nous définissons une fonction d’appartenance pour chaque rôle. Cette fonction associe pour chaque agent un degré d’appartenance au F-groupe du rôle ; ce degré exprime a quel point un agent est capable de jouer un rôle. Pour qu’on puisse mesurer une telle capacité, nous proposons un modèle d’agents construits à base de composants logiciels tirant profit ainsi des avantages du développement à base de composants comme la structuration, réutilisation et les possibilités de reconfiguration dynamiques des compositions de composants. D’un autre 102
Développer des applications distribuées ouvertes et adaptables en combinant : composants logiciels, agents et agents mobiles
coté, nous pensons que les composants logiciels peuvent aider à la formulation du problème de conformité d’un agent à un rôle. Ce problème reste encore peu abordé, mais il nous semble un enjeu réel. Le problème consiste à comment garantir ou au moins estimer qu’un agent qui va être amené à jouer un rôle sera effectivement en mesure de l’accomplir. Ce problème a été identifié dans [69] comme le problème de l’admission d’un agent dans un groupe, où les auteurs proposent comme piste la sanction d’agent s’il ne remplissait pas ses engagements. Dans notre point de vue, l’utilisation des composants pour implémenter les capacités que les rôles demandent et pour construire les agents est un possible point de départ. Les agents utilisés sont construits par assemblage et/ou réassemblage automatique des composants. En fonction de leurs compositions (composants et connexions) on peut calculer les degrés d’appartenance des agents aux F-groupe. Nous proposons par la suite un mécanisme de reconfiguration et de réassemblage pour améliorer l’appartenance d’un agent un Fgroupe pour répondre aux besoins d’adaptation. La solution que nous proposons repose essentiellement sur les systèmes multi agents organisationnels et sur le concept de composant logiciel comme unité de base pour la construction d’agent. Nous somme convaincu que les agents à base de composants sont plus flexibles que les agents standards et que l’emploi de composants logiciels permet d’adapter simplement le comportement et la structure des agents. Le modèle organisationnel proposé dont une schématisation figure dans la figure 4.1 repose sur les trois concepts principaux suivants : Agents auto adaptatifs construits à base de composants logiciels, rôles décrivant les services fournis par les agents joueurs des rôles et les groupes flous d’agents dans lesquels les rôles sont joués. La figure 4.1 présente une schématisation d’un système où trois rôles sont joués par des agents construits par assemblage de composants dans trois groupes flous. 4.3.3 Éléments de base L’approche proposée pour le développement d’applications distribuées, ouvertes et adaptables est une approche organisationnelle dont les éléments essentiels sont : des Agents auto adaptatifs qui peuvent être mobiles ou non mobiles construits à base de composants logiciels, rôles, et groupes flous d’agents comme la principale structure sociale pour les agents. 4.3.3.1 Agent Pour être en harmonie avec la vision organisationnelle de l’approche proposée, les agents doivent être conçus de sorte à permettre la mesure des capacités de ces derniers pour jouer les différents rôles dans l’organisation. Les agents doivent aussi être en mesure d’acquérir de nouvelles qualités et compétences pour améliorer leurs capacités pour jouer les différents rôles. Pour cela, nous proposons un modèle d’agent auto adaptatif à base de composants. Chaque agent est composé d’un ensemble de composants logiciels assemblés automatiquement et d’une manière dynamique dans des enveloppes logicielles que nous présenterons dans la section qui suit. Les composants implémentent des compétences et les différents savoirs faire que les rôles spécifiés dans l’organisation nécessitent. Les agents 103
Développer des applications distribuées ouvertes et adaptables en combinant : composants logiciels, agents et agents mobiles
acquirent les compétences par l’intégration des composants. plusieurs avantages :
Cette composition offre
Possibilité de définir des agents à granularité variable. Possibilité de définir des agents à structure adaptative. Chaque agent peut dynamiquement changer ses composants ainsi que les relations entre ses différents composants. Possibilités d’intégrer différents modèles d’agents. Possibilité de définir des bibliothèques de composants réutilisables. L’assemblage de composants est effectué par un moteur d’assemblage qui présente une composante essentielle dans l’architecture de l’agent illustrée dans la figure 4.3 où nous proposons l’utilisation d’un concept que nous appelons enveloppe logicielle .
Figure 4.1 : Une schématisation simplifiée d’un système où 3 rôles sont joués
4.3.3.1.1 Enveloppe logicielle
Nous introduisons la notion d’enveloppe logicielle que nous définissons comme un récipient de composants à l’intérieur duquel l’assemblage de composants est effectué. L’enveloppe interagit avec les autres éléments de l’architecture via un ensemble de port virtuels. Chaque port virtuel peut être activé ou désactivé individuellement et indépendamment des autres ports. Une fois l’assemblage de composants réalisé à l’intérieur de l’enveloppe, les interfaces fournies et requises de la composition obtenue seront reliées aux
104
Développer des applications distribuées ouvertes et adaptables en combinant : composants logiciels, agents et agents mobiles
ports virtuels de l’enveloppe. Les ports qui ne sont pas reliés à aucune interface seront désactivés. En plus des ports virtuels, l’enveloppe est composée de plusieurs ‘’enveloppecomposant’’ reliées par un ‘’bus logiciel ‘’ à l’intérieur de l’enveloppe. (Les enveloppes logicielles et les enveloppes-composants ne sont pas équivalents, l’enveloppe logicielle regroupe plusieurs enveloppes-composants). Une enveloppe-composant sert à accueillir un composant logiciel. Cet accueil peut être réel ou d’une manière virtuelle ; dans le premier cas le composant est intégré et exécuté à l’intérieur de l’enveloppe-composant. Dans le second cas, l’enveloppe-composant contient une sorte d’image sur le composant, le composant fonctionne dans une localité hors l’enveloppe et toutes les sollicitations de ses interfaces sont transférées au composant là où il est opérationnel. L’enveloppe-composant est équipée de plusieurs ports où les interfaces du composant qu’elle contient seront reliées. Les ports de toutes les enveloppes-composant sont reliés par un bus logiciel qui véhicule toute invocation d’interfaces des composants ainsi que les données échangées entre les composants à l’intérieur de l’enveloppe. Le bus logiciel relie aussi les ports des enveloppes-composant auxquels sont reliés des interfaces exportables (interfaces de la composition résultante) aux ports virtuels de l’enveloppe. Pour illustrer la situation soit l’assemblage présenté dans la figure 4.2 où trois composants C1, C2 et C3 sont utilisés. C1 fournit les interfaces f1et f2 et requit l’interface f3 que C2 fournit, C2 à son tour requit l’interface f4 que C3 fournit avec f5. La composition résultante fournit ainsi les interfaces f1, f2 et f5 qui sont reliées aux ports de l’enveloppe. Comme il est déjà noté, l’accueil de composants peut être virtuel. Par exemple dans la première enveloppe une image sur le composant C2 est accueillie et non le composant C2 qui opère dans une autre localité. Cela donne l’avantage d’avoir des compositions légères très utiles dans le cas où l’agent est mobile mais de cette manière l’autonomie de l’agent est diminuée du fait que ce dernier perd le contrôle total sur son état interne. . 4.3.3.1.2 Architecture de l’agent
Dans cette section nous présentons l’architecture interne de l’agent. Comme il est illustré dans la figure 4.3 l’agent se compose de six éléments : un module de contrôle, un moteur d’assemblage de composants, et de quatre enveloppes logicielles (Service, communication, navigation et perception de l’environnement) dans lesquelles les différentes capacités de l’agent sont implémentées à base de composants.
Le Module de contrôle : la partie de l’agent où sont situés les codes nécessaires pour que l’agent contrôle ses actions et son état interne. les actions principales de l’agent gérées dans ce module sont : la prise de décisions d’engagements pour jouer les différents rôles, la mesure de la capacité pour jouer un rôle, rendre les services liés aux rôles joués, prendre la décision d’effectuer les assemblages (et/ou) les 105
Développer des applications distribuées ouvertes et adaptables en combinant : composants logiciels, agents et agents mobiles
réassemblages de composants dans les différentes enveloppes logicielles et la prise de décision pour se déplacer d’une localité à une autre. Un moteur d’assemblage : qui permet de construire ou d’adapter une enveloppe logicielle à partir d’un ensemble de composants à assembler et une spécification d’assemblage fournie par le module de contrôle, lors de la construction ou de l’adaptation d’une enveloppe le moteur d’assemblage vérifie la compatibilité entre les interfaces des différents composants. Enveloppe service : une enveloppe logicielle dans laquelle est implémenté le comportement métier attendu de l’agent en jouant un rôle. Ce comportement applicatif fonctionnel de l’agent pour rendre certains services est construit par assemblage de composants logiciels. L’avantage d’une telle approche est la capacité de mesurer que l’agent est bien capable de jouer un rôle et d’avoir la possibilité d’augmenter la capacité d’un agent envers un rôle donné par un réassemblage convenable de composants.
C3
f5 f4
f3
f4
C2
X X X
f 1
f2
f5 f4
C3
C1
f1 f2 f3
C1
f 3
X
X
f3
f4
C2
Enveloppe de composant Port virtuel d’une enveloppe de composant
Port utilisé d’une enveloppe logicielle
X
Port non utilisé d’une enveloppe logicielle
Enveloppe de composant avec un port virtuel
Bus logiciel reliant les enveloppes de composant
Enveloppe de composant non utilisée
Un composant avec une interface requise et deux interfaces fournies
Figure 4.2 : Enveloppe Logicielle
Enveloppe de communication : une enveloppe logicielle dans laquelle on implémente les capacités de l’agent en termes de communications. De même pour l’aspect applicatif, les capacités de communication sont réalisées à base de composants logiciels. L’intérêt d’une 106
Développer des applications distribuées ouvertes et adaptables en combinant : composants logiciels, agents et agents mobiles
telle réalisation s’exprime en une capacité d’auto adaptation de l’agent en termes de moyens, techniques, protocoles, modes et langages de communication. Par exemple pour jouer un rôle donné, l’agent est amené à intégrer un langage de communication tel que KQML ou FIPA-ACL, cette intégration est bien facilement réalisable si on implémente ces langages dans des composants logiciels réutilisables. Enveloppe de perception de l’environnement : une enveloppe logicielle dans laquelle on implémente à base de composants logiciels les capacités sensorielles de l’agent pour apercevoir son environnement, cela donne une capacité d’auto adaptation de l’agent pour changer la manière d’apercevoir l’environnement pour répondre aux changements dans l’environnement, dans le cas d’un agent mobile qui change d’environnement en se déplaçant, ou pour répondre à des besoins décrit par un rôle que l’agent désire jouer. Enveloppe de navigation : une enveloppe logicielle dans laquelle sont implémentés les capacités et les mécanismes relatifs à la mobilité de l’agent. Tous comme les autres enveloppes, cette enveloppe est à base de composants offrant ainsi une flexibilité pour changer de techniques et de stratégie de la mobilité de l’agent.
Enveloppe: perception de l’environnement
Enveloppe de communication
PV1
Enveloppe de navigation
PV2 PV3
Moteur d’assemblage de composants
Ports Virtuels PV n
Enveloppe de service
Module de contrôle
Enveloppe composant Port virtuel d’une enveloppe composant
Bus logiciel reliant le module de contrôle avec les enveloppes, (service, communication, perception et navigation). Bus logiciel reliant les enveloppes composants
Enveloppe composant avec un port virtuel
Bus logiciel reliant le moteur d’assemblage et les enveloppes
Figure 4.3 : Architecture proposée des agents
107
Développer des applications distribuées ouvertes et adaptables en combinant : composants logiciels, agents et agents mobiles
4.3.3.2 Rôles Un rôle décrit les services que tous les agents acceptés pour jouer ce rôle, sont capables à un certain degré de fournir. Un service peut être vu comme un ensemble de fonctionnalités que doit réaliser l’agent, et doit être vu comme un concept faisant partie d'une ontologie de services d'un domaine donné. Ainsi le rôle est une représentation abstraite d’un ou de plusieurs services. L’ensemble des agents capables même partiellement de jouer un rôle R forment un F-Groupe du rôle (voir la section 4.3.3.3) .Un agent qui joue un rôle donné peut demander des services fournis par des agents joueurs d’un ou de plusieurs autres rôles ; les conditions pour pouvoir jouer un rôle sont décrits au niveau du F-Groupe du rôle. Nous proposons de définir un rôle comme un triplet (Id , Dc, Sn,) où : Id : représente un identifiant ou le nom du rôle. Dc : une Description comportementale décrivant l’ensemble de services à réaliser par les agents qui jouent le rôle ainsi que l’ensemble de fonctionnalités qu’un agent joueur du rôle doit implémenter pour qu’il puisse fournir les services du rôle ; la description Dc inclut des descriptions comportementales abstraites qui décrivent le comportement attendu de la part des agents pour fournir les services du rôle. Ces descriptions servent comme l’un des moyens pour la mesure de la capacité des agents à jouer un rôle. Sn : Ensemble de couples (Rôle, service), signifiant les services requis par l’agent en jouant le rôle, ainsi que les rôles où ces services sont décrits. 4.3.3.2.1 Description comportementale des rôles Pour chaque rôle spécifié dans l’organisation, le concepteur doit fournir une description comportementale qui servira de guide pour mesurer les capacités des différents agents pour jouer le rôle. Cette description consiste en deux parties : une première partie qui sert pour décrire les services à fournir en jouant un rôle et une seconde qui est utilisée pour faire une certaine mesure de similarité entre le comportement décrit au niveau du rôle et celui qu’un agent est capable de reproduire. Dans la première partie le concepteur défini les services que les agents doivent fournir en jouant un rôle. Pour chaque service à fournir on défini le savoir faire nécessaire ; c'est-à-dire l’ensemble de fonctions que l’agent qui veut jouer le rôle doit avoir dans son enveloppe de service. En d’autres termes, l’agent doit avoir parmi les composants qui forment son enveloppe de service ceux qui implémentent les fonctions spécifiées pour le rôle. Par exemple dans une modélisation d’un magasin, nous pouvons spécifier le rôle caissier. Les agents qui jouent ce rôle sont sensés fournir les services « encaisser » et « comptabiliser ». Pour fournir le service « encaisser », l’agent amené à jouer le rôle caissier doit savoir ouvrir une caisse et il doit savoir calculer aussi. Pour fournir le service « comptabiliser » les agents doivent avoir les connaissances en comptabilité nécessaires pour effectuer les comptes du jour. Nous utilisons la possession du savoir faire pour réaliser les services décrits pour un rôle comme un indicateur parmi les indicateurs de capacité que nous utilisons pour faire la mesure floue que 108
Développer des applications distribuées ouvertes et adaptables en combinant : composants logiciels, agents et agents mobiles
nous avons proposée pour mesurer la capacité des agents pour jouer le rôle. La mesure floue de la capacité des agents pour jouer les rôles sera présentée brièvement dans la section 4.3.3.3.1 et fera l’objet du cinquième chapitre où nous présentons tous les détails relatifs à cette mesure. Cette partie de la description peut être facilement exprimée en XML comme il est fait dans plusieurs modèles organisationnels tel que le modèle organisationnel Rolex [33]. Le contenu de la deuxième partie sert pour analyser les comportements des agents désirant jouer un rôle. Nous voulons mesurer à quel point en fonction des assemblages des composants dans ses enveloppes, un agent est capable de reproduire un comportement similaire à celui décrit pour le rôle à jouer. Pour que cette mesure soit possible, on a besoin d’une description de rôles et des composants qui ne soit pas limitée à une simple description syntaxiques de leurs interfaces fournies et requises. Plusieurs notations tel que les réseaux de pétri, les pré et post conditions, ainsi que d’autres notations que nous avons présenté dans le deuxième chapitre peuvent être d’une certaine utilité pour ajouter des informations sémantiques aux interfaces de composants. Le problème avec ces techniques est qu’elles sont caractérisées par des coûts computationnels considérables [138] ainsi que leurs indécidabilités. Dans ces dernières années les protocoles [138] ont été proposés comme un bon moyen pour décrire les propriétés du comportement dynamique des composants. Nous utilisons les protocoles [138] et les types de sessions [45] pour exprimer le contenu de la deuxième partie de la description du rôle. Dans les deux sections qui suivent nous présentons brièvement les concepts de protocoles et de types de sessions puis nous présentons la mesure proposée pour analyser la similarité comportementale entre le comportement de l’agent et celui décrit dans la deuxième partie de la description du rôle. Cette mesure se base essentiellement sur un typage des comportements des agents et des comportements attendus par les rôles en utilisant les types de sessions. 4.3.3.2.1.1 Protocoles et Types de sessions Les protocoles [138] sont des techniques pour décrire le comportement dynamique des composants. Ils décrivent les comportements des composants sous forme de séquences d’appels acceptés et de séquences d’appels requis. A mi-distance entre les signatures purement syntaxiques et les approches sémantiques, se trouvent les protocoles. L’idée est que la description mis l’accent sur l’interaction d’un composant avec les autres composants. Les sessions sont des protocoles utilisées pour garantir un échange de données sûr, privé et structuré lors d’une communication entre deux partenaires. Plus particulièrement, les sessions sont des spécifications partielles de protocole, pour décrire le comportement dynamique des composants. Les sessions ont été initialement formulées pour les langages basés sur le calcul de processus. Depuis, l'idée a été appliquée aux langages fonctionnels [64], aux systèmes d'objets et aux systèmes à base de composants [166],[167]. L’idée principale est née du besoin
109
Développer des applications distribuées ouvertes et adaptables en combinant : composants logiciels, agents et agents mobiles
de s’assurer que le déroulement de la communication entre deux processus ne soit pas interrompu pour échanger en toute sécurité des messages. Pour cela, les processus doivent s’accorder sur un protocole à adopter lors de l'interaction. Plusieurs auteurs ont adapté les sessions en les combinant avec un autre principe de résolution de la compatibilité entre systèmes de type [167]. La résolution de la compatibilité entre systèmes de type s’appuie essentiellement sur le principe de sous-typage [167]. Cette combinaison a donné naissance à ce qui est appelé : types de sessions. L'utilisation des types de sessions permet de réduire la complexité lorsqu'on vérifie la compatibilité de communication en raison du fait que chaque élément de la paire contient la définition du comportement inverse (duale) de l’autre. Dans la théorie des types de sessions la spécification du protocole est un type associé au canal de communication, qui décrit la séquence et la direction des données échangées [66]. Prenons l’exemple de Giachino [66] qui traite un service qui vérifie si deux nombres entiers sont égaux ou non. La description du comportement de communication de ce service est de la façon suivante:
"Le service (EGALITE) prévoit deux entiers et retourne un booléen.". Ainsi, un client approprié pour interagir avec le service ci-dessus est celui qui est capable de donner les deux nombres et attendre une réponse booléenne. "Un client du service (EGALITE) doit fournir deux entiers et obtiendra un booléen". Le service et le client savent que, s'ils se comportent comme spécifie par la description ci-dessus, c'est-à-dire, ils suivent le protocole d'interaction, leur communication sera couronnée de succès. Nous disons que le client dispose d'un protocole dual au regard du protocole du service. Ainsi, tout client avec un comportement similaire peut interagir avec n'importe quel service avec le comportement dual. Les types de session spécifient exactement ce genre d'information comme un type associé au canal sur lequel le service/client est à l'écoute. Il enregistre le type des données échangées et leur direction, précise si les données doivent être envoyées ou reçues. Par exemple, un canal de type (!Int) précise que le processus enverra un entier sur ce canal. Dualement, un canal de type ?Int précise que le processus s'attend à recevoir un nombre entier sur ce canal.
4.3.3.2.1.2 Calcul de similarité comportementale entre rôles et agents
On veut décrire le comportement exigé par un rôle ρ sur les agents concernés par jouer ce rôle. En quelque sorte, décrire le comportement d’un agent abstrait qui joue le rôle ρ, dénote cette description. D’un autre côté nous cherchons à décrire de comportement de chacun des composants ∁ utilisé dans l’enveloppe service d’un agent désirant jouer le rôle ρ. ∁ dénote la description comportementale du composant∁ . La notation à utiliser
110
Développer des applications distribuées ouvertes et adaptables en combinant : composants logiciels, agents et agents mobiles
pour la description comportementale doit être facilement compréhensible et doit permettent un raisonnement formel sur les comportements spécifié. Selon une certaine manière de voir la chose, le rôle ρ peut être traité comme étant un composant ∁ dont la description comportementale est
(la description comportementale d’un agent abstrait qui joue le rôle
ρ). Les interfaces fournies du composant ∁ sont les différents services fournies par les agents
qui jouent le rôle ρ ; les interfaces requises du composant ∁ sont les services requis par les agents qui jouent le rôle ρ. L’enveloppe service de l’agent
désirant jouer le rôle ρ est aussi
vue comme un composant composite ∁ composé des composants∁ . Ainsi, nous cherchons à construire une fonction
,
comportementale d’un rôle ρ notée
∁
,
∁
,…,
∁
→ [0,1]et qui à partir de la description
et les descriptions des composants ∁ qui composent ∁
(le composant composite équivalent à l’enveloppe service de l’agent désirant jouer le rôle ρ) retourne une valeur entre 0 et 1 pour exprimer le degré de substitution entre les deux
composants ∁ et ∁ qui reflète à quel degré le composant ∁ peut remplacer le composant ∁ . Ce qui revient à dire à quel degré l’agent
désirant jouer le rôle ρ est en mesure de produire
un comportement similaire à celui exigé par le rôle ρ. Nous utilisons ce degré de substitution parmi les indicateurs de capacité pour faire la mesure floue des capacités des agents pour jouer les rôles. Pour construire la fonction décrite ci-dessus, nous proposons d’utiliser le concept de types de sessions pour décrire les comportements dynamiques des différents composants ainsi que pour décrire les comportements demandés par les rôles. Les sessions sont des spécifications partielles des protocoles pour la spécification des comportements des composants en mettant l’accent uniquement sur les comportements des interfaces des composants. Les types de session sont des types. Alors, ils sont naturellement supportés par une discipline de type [167]. Ce que permet généralement de définir des relations de sous typage permettant à leurs tours d’étudier les propriétés de compatibilité et de substitution. La notion de typabilité d'un programme développée par Vallecillo et al [166]permet la définition de contrôle de substituabilité des composants basé sur le concept de sous-typage de session, qui est un simple calcul dans la plupart des cas, à la différence des tests exponentielles connus comme problème NP-complets qui résultent de l'utilisation des traces ou des algèbres de processus dans la description du protocole. Ainsi, le test de substitution entre de composants revient à vérifier que le type de comportement de l‘un des composants est un sous type du type du comportement de l’autre composant. En utilisant le typage et les relations de sous typage nous pouvons vérifier que le composant composite ∁ (enveloppe service de l’agent ) peut remplacer le composant ∁ , en d’autres termes, vérifier que
l’agent est capable de produire le comportement spécifié pour le rôle ρ. Nous utilisons les relations de sous typage définies sur les types de sessions par Gay et Hole [66] pour vérifier la substituabilité entre deux composants. La vérification de la substituabilité revient à vérifier un sous typage. Et donc, nous pouvons vérifier qu’un agent est capable de reproduire un comportement similaire à celui spécifié pour le rôle dont il veut 111
Développer des applications distribuées ouvertes et adaptables en combinant : composants logiciels, agents et agents mobiles
jouer par vérifier l’existence d’un sous typage entre le comportement du composant représentant l’enveloppe service de l’agent et le type du comportement du composant qui représente le rôle. La décidabilité de la substitution et le sous typage en utilisant les types de session est prouvée dans [167]. Nous utilisons le même formalise pour exprimer les sessions ainsi que le langage de type proposé par Vallecillo et al dans [167]. Le formalisme, la grammaire qui génère le langage des types ainsi que les relations de sous type que nous utilisons sont résumés et présenté sommairement dans la figure 4.4 qui illustre aussi un exemple de description d’un système distribué de vente aux enchères où trois rôles (Auctioneer, Seller et Bidder ) sont joués. Nous reviendrons sur cet exemple plus loin dans cette section et celle qui suit. Les détails du formalisme et du langage de type ainsi que tous autres détails peuvent être trouvés dans [167]. Selon les règles de sous typage définies dans [167], est un sous type de , noté ≤ , si peut être utilisé dans n’importe quel contexte où est utilisé. doit avoir un nombre de sélection (+) supérieur ou égal au nombre de sélections de et un nombre de branchements (&) inferieur ou égal à celui de . Les règles algorithmiques du sous typage sont de la forme ∑ ⊢ ≤ [167] où ∑ représente un ensemble fini d’inégalité ≤ signifiant que est un sous type de . Par exploiter cette idée de comptage de sélections et de branchements, nous introduisons une notion de distance de sous typage. Cette distance reflète les différentes situations possibles entre le comportement décrit pour un rôle et celui qu’un agent désirant jouer ce rôle est capable de produire. En faisant un typage pour les deux comportements, le comportement décrit au niveau du rôle est de type , et celui de l’agent est de type . Maintenant, il est possible de vérifier si est un sous type de et donc déduire que le comportement produit par l’agent peut remplacer celui décrit au niveau du rôle. Par la suite il est possible de juger que : l’agent en question est capable de jouer le rôle selon un point de vue purement fonctionnel. La capacité globale de l’agent pour jouer un rôle ne se résume pas dans un point de vue fonctionnel, elle est en fonction de plusieurs autres paramètres opérationnels et non fonctionnels. En se basant sur le nombre de sélections et celui de branchement nous pouvons attribuer des valeurs pour la distance de sous typage. On peut distinguer les situations suivantes : si la condition de sous typage entre (le nombre de sélections (+) de est supérieur ou égal au nombre de sélection de et le nombre de branchements (&) de inferieur ou égal à celui de ) n’est pas vérifier, alors n’est pas un sous type de et la distance de sous typage prend la valeur 0, expriment la non capacité du point de vue fonctionnel de l’agent. Dans les cas où la condition de sous typage entre est vérifiée, plus le nombre de sélections (+) du type diminue et celui des branchements (&) augmente ℎ (à condition que la condition de sous typage soit toujours vérifiée). On peut donc attribuer des valeurs dans l’intervalle ]0,1] pour la distance de sous typage entre exprimant à quel point ℎ . Quand la valeur de la distance de sous typage vaut 1, alors sont les mêmes (même type). Plus la valeur de la distance de sous typage entre s’approche de 1 ℎ . C’est-à-dire, n’a pas 112
Développer des applications distribuées ouvertes et adaptables en combinant : composants logiciels, agents et agents mobiles
beaucoup de spécificités qui le distinguent de . Si nous traduisons ça en termes d’agents et de rôles, une distance de sous typage proche de 1 exprime que l’agent est capable de produire un comportement similaire à celui décrit pour un rôle sans que l’agent soit capable de faire beaucoup d’autres choses supplémentaires.
≤ ∑⊢
Protocol ::=protocol X { Session} Session ::= session X= T …session X=T T ::= &{ m1 : T1 |. . . mn : Tn} |+ { m1 : T1 |. . . mn : Tn} | ); | ! [ ]; ?( ); ! [ ]; ? ( Sort ::= string | float| boolean
| |
.
∑ ⊢ end ≤ end
| end
∑ ⊢? (
Une grammaire pour décrire les comportements Protocol Auctionneer{ Session withSeller= +{ selling :![ string, float]; & { sold:? (float); end |notSold; end } } Session withABidder= +{register: &{ wannaBid: ?(string, float); ![boolean]; Bidding}} Bidding = &{wannaBid: ?(string, float); ![boolean]; Bidding || |itemSold: ?(string); Unregistering | youGotIt: ?(string, float); Unregistering } Unregistering = +{ unregister : end} } un exemple de description d’un système distribué de vente aux enchères où trois rôles (Auctioneer, Seller et Bidder ) sont joués.
∈∑ ≤
∑⊢ ≤ ); ≤? (
);
….. ….. …..
∑,
≤
. ⊢ ≤ ∑⊢ ≤
.
(
. )
Quelques relations du système de sous typage, la liste de toutes les relations peut être trouvée dans [167].
Figure 4.4 : Formalises, la grammaire engendrant le langage des types et les relations de sous typage.
L’importance de la distance de sous typage réside dans le fait qu’elle favorise pour jouer un rôle la sélection d’agents qui produisent des comportements très proches de celui décrit pour le rôle sans que ces derniers sachent faires autres choses. Cela est très important dans les cas où les agents doivent accomplir en urgences les tâches relatives aux rôles joués ou dans les cas où les rôles joués exigent des agents mobiles. Il est clair que plus la taille de l’agent est réduite plus sa mobilité est facile et moins coûteuse. Pour que les agents soient de tailles réduites, ils doivent se contenter de savoir faire juste le minimum du savoir demandé sans plus. Nous utilisons la distance de sous typage pour construire la fonction
,
décrite précédemment et que nous utilisons comme l’un des ) → [0,1] indicateurs pour la mesure de la capacité des agents pour jouer des rôles. ∁
,
∁
,…,
∁
113
Développer des applications distribuées ouvertes et adaptables en combinant : composants logiciels, agents et agents mobiles
Prenons comme exemple la conception d’un système distribué de vente aux enchères. Trois rôles sont joués dans un tel système :
le rôle "Auctioneer" signifiant le rôle d’un commissaire-priseur joué par des agents qui mettent des objets à vendre ;
le rôle "Seller" ou vendeur joué par les agents qui vendent les objets pour le compte des agents qui jouent le rôle Auctioneer ;
et finalement, le rôle "Bidder" ou soumissionnaire joué par des agents qui font des soumissions pour acheter les objets mis à la vente aux enchères.
La spécification des rôles peut être écrite sous la forme suivante : Roles= {(auctioneer,DC1,(seller, best_offer)), (Seller, DC2, - ), (Bidder, DC3, -)}
Cette spécification dénote que trois rôles sont à jouer. Un rôle auctioneer dont DC1 présente la description comportementale. Les agents qui jouent ce rôle requirent le service best_offer offert par les agents qui jouent le rôle seller. Deux autres rôles sont définis, le rôle seller et le rôle Bidder dont les descriptions sont respectivement DC2 et DC3. Les agents qui jouent ces deux rôles n’ont pas besoin de services offerts par d’autres agents. Les descriptions DC1, DC2 et DC3 décrivent les services à fournir, les fonctions à réaliser ainsi que les comportements attendus de la part des agents qui jouent les rôles Auctioneer, Seller et Bidder respectivement. Le contenu de la description DC1 est proche du listing illustré dans la figure 4.5. 4.3.3.3 Groupes flous
Le troisième élément sur lequel s’appuie l’organisation que nous proposons c’est les groupes. Dans sa définition la plus basique, un groupe est un ensemble d’agents. Cette notion de création de groupes ou d’alliances d’agents apparait sous différentes manières dans des modèles organisationnels des systèmes multi agents comme AGR [53], MOISE+[ 79], AGRS [105] ainsi que dans plusieurs autres modèles. L’élément commun entre tous les modèles organisationnels qui utilisent les groupes y compris le notre est que les groupes sont utilisés comme un moyen de partition de l’organisation.
114
Développer des applications distribuées ouvertes et adaptables en combinant : composants logiciels, agents et agents mobiles
Part 1
Auctioneer Sell_object contact_sellers client.setCourtier Selction_best_sellers_offer client.activate select the best offer among offers of different sellers contrat client.handleMessage validate the sale with the selected bidder
Part 2 :Dynamic behavior Protocol Auctionneer{ Session withSeller= +{ selling :![ string, float]; & { sold:? (float); end |notSold; end } } Session withABidder= +{register: &{ wannaBid: ?(string, float); ![boolean]; Bidding}} Bidding = &{wannaBid: ?(string, float); ![boolean]; Bidding || |itemSold: ?(string); Unregistering | youGotIt: ?(string, float); Unregistering } Unregistering = +{ unregister : end} }
Figure 4.5 : Contenu d’un fichier de description du rôle auctionneer.
Les groupes d’agents que nous utilisons sont des groupes flous que nous appelons «FGroupes » dont la figure 4.6 illustre une schématisation simplifiée. Un F-group d’un rôle ρ est un ensemble flou d’agents concernés par jouer le rôle ρ. Contrairement à la notion d’appartenance classique aux groupes où un agent appartient ou non un groupe, dans les Fgroupés proposés les agents appartiennent à un F-groupe d’un rôle ρ partiellement en fonctions de leurs capacités pour jouer le rôle ρ. En d’autres termes, un F-group d’un rôle ρ est un ensemble flou d’agents capables totalement ou partiellement de jouer le rôle ρ. Il s’agit donc de partitionner les agents en deux classes, ceux qui sont capables de jouer un rôle donné 115
Développer des applications distribuées ouvertes et adaptables en combinant : composants logiciels, agents et agents mobiles
et ceux qui ne le sont pas. Par ailleurs ; cette restitution dichotomique entre capable et non capable de jouer un rôle paraît abrupte. Il est donc question d’assouplir cette vision de capacité de jouer un rôle par un agent et faire le passage d’une situation de non capacité à une situation de capacité d’une manière graduelle. On peut recourir à la théorie des ensembles flous introduite en 1965 par L.A. Zadeh [181][48] pour résoudre le problème de la restitution dichotomique entre capable et non capable de jouer un rôle. La théorie des ensembles flous reflète l’admission de l’existence de situations intermédiaires entre le tout et le rien à partir de l’idée d’appartenance partielle à une classe ou aux catégories aux limites mal définies et de gradualité dans le passage d’une situation à une autre. La théorie des ensembles flous apparaît comme un outil bien adapté pour modéliser un concept vague tel que la capacité d’un agent pour jouer un rôle donné ou pour accomplir une tâche précise. Ainsi, comme pour les ensembles flous, il s’agit d’établir une fonction d’appartenance des agents à un groupe qui, à ses extrémités, inclut l’agent au groupe ou l’en exclut de façon certaine, mais qui, entre les valeurs extrêmes, varie à proportion de la proximité au groupe. La fonction d’appartenance d’un F-groupe d’un rôle ρ permet de déterminer pour chaque agent son degré d’appartenance au F-groupe. Ce degré exprime la capacité de l’agent pour jouer le rôle ρ. La mesure floue multidimensionnelle des capacités des agents pour jouer les rôles fait l’objet du cinquième chapitre où tous les détails sur l’établissement des fonctions d’appartenances et les mesures des capacités des agents sont présentés. Avec cette mesure des capacités des agents pour jouer un rôle, un ordre de préférence entre les agents peut être créé en fonction de leurs degrés d’appartenances. Et donc, seuls les agents ayants les meilleures capacités seront autorisés pour jouer le rôle. A l’intérieur de chaque F-Groupe deux rôles sont joués : un rôle service et un rôle superviseur. Le rôle service décrit le ou les services fournis par les agents qui appartiennent même partiellement au F-Groupe. Le rôle superviseur est joué par un ou plusieurs agents chargés de la gestion du F-groupe. La gestion du F-groupe peut être résumée en :
Evaluer la fonction d’appartenance et autoriser ou non les agents désirant jouer le rôle service du f-groupe ;
Mettre à jour les paramètres du F-groupe (ces paramètres affectent l’évaluation de la fonction d’appartenance ainsi que les modes d’accomplissement des tâches relatives aux rôles) ; Un F-Groupe est défini comme : F-Group= (ID, Rôle Service, Rôle superviseur, ,ƒm , Matrice paramètres_superviseur, Links, Mode, Card_nimmax Superviseurs) où :
paramètres_Service,
,
Matrice
ID : identifiant du F-Groupe ; Rôle Service : le rôle service joué par les agents membres du F_Groupe. Rôle superviseur : le rôle joué par les agents qui gèrent le F-groupe. La description de ce rôle se fait de la même manière que les rôles services, la description consiste en les fonctions à assurer et les comportements que les agents doivent produire dans les 116
Développer des applications distribuées ouvertes et adaptables en combinant : composants logiciels, agents et agents mobiles
activités de gestion du F-groupe. Les agents qui jouent ce rôle de superviseur doivent avoir les capacités qu’il faut pour le faire. Le même modèle d’agent est utilisé pour les agents qui jouent les rôles services et ceux qui jouent les rôles de supervision. Comme l’unité de construction de l’agent est le composant, on préserve les avantages pour les agents superviseurs tel que la mesure de la conformité des agents avec le rôle superviseur de groupe et la possibilité d’augmentation du degré de cette conformité par des réassemblages convenables. En plus de ces avantages, il est possible de faire engager des agents comme superviseur à n’importe quel moment dans le cas où le FGroupe nécessite plus de superviseurs ou dans le cas de perte d’agents superviseurs pour différentes raisons, par exemple la localité où un agent superviseur opère n’est plus connectée. ƒm : une fonction d’appartenance du F-Groupe similaire aux fonctions d’appartenance aux ensembles flous. Cette fonction permet de calculer le degré d’appartenance de chaque agent au F-groupe exprimant la capacité de ce dernier pour jouer le rôle service du F-groupe. La construction des fonctions d’appartenance aux F-groupes et la mesure multidimensionnelle des capacités des agents pour jouer les rôles font l’objet du chapitre suivant. Matrice paramètres_service : une collection de données regroupant un ensemble de paramètres fonctionnels, non fonctionnels, et opérationnels utilisés pour évaluer la fonction d’appartenance au F-Groupe. En d’autres termes, cette matrice contient les indicateurs selon lesquels la mesure des capacités des agents est effectuée. Matrice paramètres_superviseur : une collection de données regroupant un ensemble de paramètres fonctionnels, non fonctionnels, et opérationnels utilisés pour la mesure des capacités des agents pour jouer le rôle superviseur du F-groupe. Links : dans cet élément de la spécification, le concepteur définit les rôles autorisés à communiquer avec le rôle service du F-groupe. C'est-à-dire, les agents membres du Fgroupe sont autorisés à communiquer avec les agents qui jouent ces rôles. Cette restriction présente une structuration sociale du système multi agents pour contraindre les comportements des agents vers la satisfaction des objectifs tracés. Mode : présente une contrainte par apport au temps selon laquelle les services du rôle seront réalisés. On distingue trois modes différents : mode urgence, mode normal et mode déféré. Dans le premier cas, l’agent doit achever le plus rapidement possible le service demandé ; dans le second, une priorité normale est accordée pour le service ; alors que pour le troisième mode une priorité faible est accordée pour le service. Card_nimmax Superviseurs : précise le nombre minimum et maximum d’agents autorisés pour jouer le rôle superviseur du F-groupe.
4.3.3.3 1 Matrice de paramètres La matrice de paramètres est une collection de données dans laquelle le concepteur définit pour le rôle service (superviseur) joué dans le F-Group l’ensemble de critères utilisés comme indicateurs de capacité. Dans le modèle proposé, les agents d’un F-groupe sont autorisés à jouer le rôle service associé au F-groupe en fonction de leurs capacités pour jouer le rôle. La mesure de la capacité des agents que nous avons proposée est une mesure floue 117
Développer des applications distribuées ouvertes et adaptables en combinant : composants logiciels, agents et agents mobiles
multidimensionnelle basée sur des indicateurs de capacité jugés pertinents pour chaque rôle. Chaque indicateur de capacité traduit un aspect particulier de la capacité fonctionnelle, opérationnelle ou extra-fonctionnelle. Les indicateurs de capacité qui couvrent le volet fonctionnel sont les indicateurs reliés au savoir faire des agents dans le sens métier. Par exemple, pour le rôle caissier dans un magasin « savoir ouvrir une caisse » est un indicateur de capacité de nature fonctionnelle. Les indicateurs de capacités opérationnelles couvrent les capacités de communication et de mobilité ainsi que les capacités en termes de perception de l’environnement. Les indicateurs de capacité qui couvrent le volet extra-fonctionnel sont des indicateurs qui sont en relation avec les facteurs qui influencent le fonctionnement des agents en jouant les rôles comme la quantité de mémoire disponible sur un site ou la quantité de l’énergie dans une batterie qui alimente un nœud d’exécution. Pour que la mesure de la capacité d’un agent pour jouer un rôle soit profondément significative, les indicateurs de capacité choisis pour un rôle doivent couvrir le maximum possible d’aspects de capacité ainsi qu’ils doivent être bien pondérés en accordance avec leurs importances dans la mesure de la capacité des agents pour jouer le rôle associé au F-groupe. En plus des indicateurs de capacité, dans la matrice de paramètres le concepteur doit spécifier leurs degrés d’importance ainsi que les différentes modalités pour les indicateurs à valeurs discrètes et les intervalles de valeurs pour les indicateurs à valeurs continues. Le tableau 4.1 présente une matrice de paramètre pour un F-groupe au quel est associé un rôle service ρ quelconque.
Figure 4.6 : Une schématisation simplifiée de deux F-groupes
4.3.3.3 2 Gestion des F-groupes
La gestion des groupes flous est assurée par un ensemble d’agents qui jouent un rôle de superviseur du groupe. Les agents qui jouent le rôle de superviseur n’ont rien de particulier par rapport à ceux qui jouent le rôle service dans un F-groupe. En termes d’architecture, les 118
Développer des applications distribuées ouvertes et adaptables en combinant : composants logiciels, agents et agents mobiles
agents service et les agents superviseurs sont identiques. C'est-à-dire, les agents qui jouent le rôle de supervision d’un F-groupe sont aussi construits par assemblages de composants dans les enveloppes logicielles de service, communication, navigation et de perception de l’environnement conformément avec l’architecture illustrée dans la figure 4.3. Les composants qui constituent les différentes enveloppes de l’agent implémentent le savoir faire nécessaire ainsi que tout ce que qualifie l’agent pout jouer un rôle de supervision tel que les mécanismes de communication et de mobilité. Pour rejoindre l’ensemble des superviseurs et devenir superviseur d’un F-groupe, l’agent concerné doit être accepté par les agents superviseurs du F-groupe. Pour que l’agent soit accepté, ce dernier doit montrer les capacités permettant aux superviseurs de le qualifier capable de jouer le rôle superviseur. De la même manière que les rôles service, une fonction d’appartenance est établie permettant la mesure de la capacité des agents pour jouer le rôle superviseur d’un F-groupe. La description du rôle superviseur d’un F-groupe s’appui sur le même formalisme utilisé pour la description des rôles services. Elle consiste aussi en deux parties, dans la première on définit les services que les agents doivent fournir en jouant le rôle superviseur tout en définissant pour chaque service le savoir faire nécessaire. La deuxième partie de la description sert pour vérifier à quel degré un agent est capable de produire un comportement similaire au comportement d’un superviseur type. Les activités des agents superviseurs apparaissent dans la description du rôle superviseur. Une description de rôle superviseur est illustrée dans la figure 4.8 .La mission principale des agents superviseurs est de veiller à ne pas autoriser que les meilleurs agents en termes de capacités pour jouer le rôle service dans un F-groupe. Après une interaction entre un agent superviseur et un agent demandeur pour jouer le rôle service d’un F-Groupe, les agents superviseurs décident d’autoriser ou non l’agent demandeur pour jouer le rôle service en fonction de son degré d’appartenance au F-groupe et les demandes des autres agents pour leurs attribuer le rôle service. La figure 4.7 présente un diagramme qui résume le déroulement du processus d’autorisation d’un agent pour jouer le rôle service d’un F-groupe. Si les agents superviseurs d’un F-groupe n’ont pas autorisé un agent pour jouer le rôle service du F-groupe, ce dernier peut procéder à une adaptation dans ses enveloppes logicielles en réalisant un ou plusieurs réassemblages de composants dans le but d’améliorer son degré d’appartenance au F-groupe et formuler de nouveau une autre demande pour jouer le rôle service du F-groupe. Dans le cas où les agents superviseurs autorisent un agent pour jouer le rôle service du F-groupe, l’agent aura une autorisation valide pendant une période T. La durée de validité d’une autorisation est limitée puisque à fur et à mesure que le système progresse d’autres agents qui n’ont pas été autorisés à jouer le rôle service, par des réassemblages de composants adéquats dans leurs enveloppes logicielles peuvent devenir mieux positionnés pour jouer le rôle par rapport à ceux déjà autorisés.
119
Développer des applications distribuées ouvertes et adaptables en combinant : composants logiciels, agents et agents mobiles
Signification Indicateur : mobilité ; Poids :
Modalités & valeurs
; nature : Discontinue. Cet indicateur exprime à quel point la mobilité Modalités= {1, 3, 6} de l’agent est nécessaire ou souhaitée pour Dans le cas où l’agent est non mobile la valeur 1 est attribuée pour cet jouer le rôle ρ. indicateur, le cas d’une mobilité faible l’indicateur prend la valeur 3. Pour les agents caractérisés par une mobilité forte l’indicateur prend la valeur 6. Selon cet indicateur de capacité les agents mobiles sont favorisés pour jouer le rôle ρ, et plus particulièrement ceux caractérisés par une mobilité f orte. Indicateur : énergie ; Poids : ; nature : Continue . Cet indicateur non fonctionnel dépend de la Intervalle de valeurs= [0,1] nature de l’alimentation électrique de la machine sur laquelle l’agent s’exécute. Sa valeur dépend du fait que la machine est L’indicateur prend la valeur 1 dans le cas où la source alimentée par une source d’alimentation d’alimentation électrique est permanant. Dans le cas d’une permanant ou par une batterie qui contient alimentation par une batterie l’indicateur prend une valeur dans une quantité donnée d’énergie au moment de [0,1] reflétant le taux de remplissage de la batterie. l’évaluation de la valeur de l’indicateur. La quantité d’énergie peut affecter le fonctionnement de l’agent en jouant le rôle ρ
Indicateur : Ressource X ; Poids :
; nature : Continue . Cet indicateur exprime la possession ou la Intervalle de valeurs= [0,1] privation d’un certain nombre d’unités d’une L’indicateur prend la valeur 0 dans le cas d’une privation totale de la ressource ressource X. Par exemples, des droits d’accès à X. il prend une valeur dans Intervalle de valeurs= [0,1] exprimant la proportion une base de données. du nombre d’unité possédées de la ressource X par rapport au nombre totale d’unité nécessaires.
Indicateur : Outils pour la communication ; Poids : ; nature : Continue . Cet indicateur exprime que pour jouer le rôle ρ, Modalités :{Oui, Non}
l’agent dispose de certains moyens pour communiquer avec les autres agents. c à d, l’agent doit avoir dans son enveloppe de communication des composants qui concrétisent ces moyens de communication. Par exemple, implémenter un langage de communication dans un ou plusieurs composants que l’agent doit avoir dans son enveloppe de communication. Indicateur : Possession d’un savoir faire X ; Poids : ; nature : Continue . Cet indicateur exprime à quel point l’agent Intervalle de valeurs= [0,1] possède un savoir faire X. C à d, à quel point les L’indicateur prend la valeur 0 dans le cas d’une privation totale du savoir faire X. composants de son enveloppe service il prend une valeur dans Intervalle de valeurs= [0,1] exprimant la proportion du implémentent de fonctionnalités constituant nombre de fonctions implémentés par les composants de l’enveloppe service le savoir faire X. de par rapport au nombre totale de fonctions demandées. il se peut qu’un agent doit avoir plusieurs savoirs faire différents, on les sépare dans des indicateurs indépendants pour leurs attribuer des poids différents en accordance avec leurs importances et leurs impacts sur la capacité.
Indicateur : similarité du comportement ; Poids : Cet indicateur exprime à quel point un agent qui est amené à jouer le rôle ρ est capable de reproduire un comportement similaire à celui décrit au niveau du rôle. la mesure de cette capacité est possible à travers l’exploitation de la distance de sous typage que nous avons introduit.
; nature : Continue . Intervalle de valeurs= [0,1]
L’indicateur prend la valeur qui résulte de l’évaluation de la fonction : ( , 1, … ) → [0,1]
Tableau 4.1 : Matrice des paramètres contenant les indicateurs de capacité pour un rôle ρ.
120
Développer des applications distribuées ouvertes et adaptables en combinant : composants logiciels, agents et agents mobiles
La durée de la période T est déterminée dynamiquement par les agents superviseurs en dépendance avec le degré de concurrence entre les agents pour jouer le rôle service. La durée T doit être suffisamment grande pour ne pas encombrer le système par le calcul et l’évaluation des degrés d’appartenance selon une fréquence élevée et doit être suffisamment petite pour qu’à tout moment le rôle service soit attribué aux agents ayant les meilleures capacités.
Agent
Agent superviseur
Un agent veut jouer le rôle ρ
Vérifier si l’agent avait une autorisation pour jouer le rôle ρ et que cette autorisation est toujours valide (période de validité non expirée) et que l’agent demandeur n’a pas procédé à des réassemblages de ses composants dans les différentes enveloppes.
L’agent envoi sa demande à l’un des agents superviseurs du F-groupe du rôle ρ
Autorisation valide
Non autorisé Initier une session pour jouer le rôle.
Exécution
Mesurer la capacité de l’agent pour jouer le rôle
Extraire les informations à partir du descripteur du rôle et les descripteurs des composants de l’agent. Calculer les indicateurs de capacité.
Evaluer la fonction d’appartenance du F-groupe.
Si l’agent désire toujours jouer le rôle, il doit améliorer sa capacité en procédant à des réassemblages adéquats de composants dans ses différentes enveloppes.
Délibération avec les autres superviseurs du F-groupe. Degré d’appartenance faible Degré d’appartenance jugé bon
Établir une autorisation avec une durée de validité limitée
Figure 4.7 : Diagramme schématisant le processus d’obtention d’une autorisation pour jouer un rôle.
121
Développer des applications distribuées ouvertes et adaptables en combinant : composants logiciels, agents et agents mobiles
Part 1
Supervisor_of_Auctioneer_Group Administer_Joining_of_agents_to_Auctioneer_Group invite_agent invite agents to play the role Auctioneer and joining the f-groupe of Auctioneers update_list_of_acquaintance list.update update the list of agents that can play the role Auctioneer evaluate_membership_function agent.calculsIndicator In interaction with agents that wish to play the role Auctioneer,calculate the degree of membership Administer_Joining_of_agents_to_supervise_Auctioneer_Group invite_agent invite agents to play the role of supervisor of f-groupe of Auctioneer and joining supervisors FunctionDescriptor> measurement_of_capacity measure the capacity of an agent to play the role of supervisor of the f-group of auctionneer Part 2 :Dynamic behavior Protocol AuctionneerSupervisor{ Session with Auctionneer= +{ authorizing :![ float]; & { best_capable:? (float); end |notbest_capable; end } } Session with agents_wanting_to_play_the_role= +{ inviting :![ string, float]; & { capable:? (float); end |notcabale; end } } Session agents_wanting_or_invited_to_become_supervisor= +{register: &{ suprvise: ?(string, float); ![boolean]; supervising}} supervising = &{supervise: ?(string, float); ![boolean]; supervising || |capable: ?(string); Unregistering | youGotIt: ?( float); Unregistering } Unregistering = +{ unregister : end} }
Figure 4.8 : Contenu d’un fichier de description du rôle superviseur du F-groupe d’agents auctionneers.
122
Développer des applications distribuées ouvertes et adaptables en combinant : composants logiciels, agents et agents mobiles
La seconde mission des agents superviseurs consiste à inviter d’autres agents pour les rejoindre à la supervision du groupe flou dans le cas où le nombre d’agents superviseurs n’est pas suffisant pour assurer une bonne gestion des entrées et des sorties des agents au F-groupe. Cette insuffisance peut être due à un nombre important d’agents qui désirent entrer dans le groupe et jouer le rôle service du groupe ou en cas de perte de quelques agents superviseurs pour diverses raisons, par exemple le cas où une localité où s’exécutent des agents superviseurs n’est plus accessible parce qu’elle est en panne ou la liaison qui assure sa connexion au système n’est pas fonctionnelle. Pour qu’un agent invité pour rejoindre les superviseurs soit accepté, ce dernier doit montrer les capacités permettant aux superviseurs de le qualifier capable de jouer le rôle superviseur. La mesure de la capacité d’un agent pour jouer le rôle superviseur d’un groupe flou est effectuée de la même façon selon laquelle la mesure de la capacité d’un agent pour jouer un rôle service est effectuée. C'est-à-dire, en utilisant la mesure floue multidimensionnelle détaillée dans le prochain chapitre et qui est basée sur des indicateurs de capacité jugés pertinents pour le rôle superviseur. L’ensemble des capacités requises pour jouer un rôle de supervision d’un F-groupe n’est pas totalement indépendant de l’ensemble des capacités requises pour jouer un rôle service du F-groupe. Les agents qui jouent ces deux rôles doivent avoir quelques capacités en commun, notamment en termes d’outils et de moyens de communication puisque ces agents sont amenés à communiquer les uns avec les autres. Considérant le même exemple du système distribué de vente aux enchères présenté dans la section 4.3.2.1.2 où trois rôles sont joués : un rôle "Auctioneer" signifiant le rôle d’un commissaire-priseur, joué par des agents qui mettent des objets à vendre ; le rôle "Seller" ou vendeur jouer, par les agents qui vendent les objets pour le compte des agents qui jouent le rôle Auctioneer ; et finalement, le rôle "Bidder" ou soumissionnaire, joué par des agents qui font des soumissions pour acheter les objets mis à la vente aux enchères. Les rôles joués dans le système distribué de vente aux enchères sont spécifiés comme: Roles= {(auctioneer,DC1,(seller, best_offer)), (Seller, DC2, - ), (Bidder, DC3, -)}
Les rôles Auctioneer, seller et Bidder sont joués à l’intérieur des groupes flous dont la spécification peut se faire de la manière suivante:
F-G1= (F-G1, Auctioneer , Auctioneer supervisor, ,ƒm , MP1 , MPSUP1, { Seller }, normal,(1,5)). F-G2= (F-G2, seller, seller supervisor, ,ƒm , MP2 , MPSUP2, { Auctioneer , Bidder }, urgency,(2,10)). F-G3= (F-G3, Bidder, Bidder supervisor, ,ƒm , MP3 , MPSUP3, { seller}, normal,(2,10)).
123
Développer des applications distribuées ouvertes et adaptables en combinant : composants logiciels, agents et agents mobiles
Cette spécification dénote qu’il existe trois groupes flous F-G1, F-G2 et F-G3 à l’intérieurs desquels trois rôles de service sont joués. Dans F-G1 le rôle Auctioneer est joué ; dans F-G2 le rôle seller est joué et dans F-G3 le rôle Bidder est joué. Les rôles Auctioneer supervisor , seller supervisor, Bidder supervisor présentent les rôles de supervision des groupes flous FG1, F-G2 et F-G3 respectivement. La même fonction d’appartenance ƒm est définie pour les trois groupes, elle sert pour mesurer les capacités des agents pour jouer les différents rôles services et même les rôles superviseurs. MP1, MP2, MP3 sont les matrices paramètres dans lesquelles sont définis les indicateurs de capacités à utiliser pour la mesure des capacités des agents pour jouer les rôles services des F-groupes F-G1, F-G2 et F-G3 respectivement. MPSUP1, MPSUP2, MPSUP3, sont les matrices paramètres dans lesquelles sont définis les indicateurs de capacités à utiliser pour la mesure des capacités des agents pour jouer les rôles de supervision des F-groupes F-G1, F-G2 et F-G3 respectivement. Les agents qui jouent le rôle Auctioneer sont autorisés à communiquer avec les agents qui jouent le rôle seller . Les agents qui jouent le rôle seller sont autorisés à communiquer avec ceux qui jouent les rôles Auctioneer et Bidder. Les agents qui jouent le rôle Bidder sont autorisés à communiquer avec les agents qui jouent le rôle seller. Une priorité normale est attribuée aux rôles Auctioneer et seller. Les agents qui jouent le rôle Bidder doivent achever les activités relatives au rôle en urgence. (1,5), (2,10) et (2,10) présentent les cardinalités (nombre) minimum et maximum d’agents superviseurs autorisés pour les groupes flous F-G1, F-G2 et F-G3 respectivement. 4.3.4 Gestion de l’adaptation La propriété d’adaptation présente l’une de nos préoccupations essentielles dans les travaux de la présente thèse. Dans le premier chapitre de ce manuscrit, on a introduit et présenté les arguments à cause desquels l’adaptation s’impose comme propriété indispensable dans la majorité des applications et des systèmes informatiques modernes. Comme nous l’avons déjà étudié dans les trois premiers chapitres, la propriété d’adaptation est un spectre composé de plusieurs couleurs où chacune d’entre elles couvre plusieurs niveaux de dégradations. Par le terme couleur, nous voulons désigner une dimension de l’adaptation et qui peut être : le but de l’adaptation, le moment de l’adaptation, sur quoi porte l’adaptation, l’initiateur de l’adaptation et finalement comment effectuer l’adaptation. Par niveaux de dégradations de couleurs, nous voulons exprimer l’existence de plusieurs facettes et manière de voir et de traiter chacune des dimensions. Dans l’approche que nous proposons, la propriété d’adaptation est à caractères évolutif, perfectif et même adaptatif. C'est-à-dire, Une adaptation qui permet d’ajouter des fonctionnalités à cause de l’évolution des besoins et qui vise en même temps comme objectif d’optimiser les performances de l’application par l’amélioration des comportements de certaines parties de l’application pour résoudre une tâche plus efficacement. Comme cette adaptation peut avoir l’objectif de faire évoluer l’application en fonction d’un changement de contexte. Cette adaptation est réalisée à deux niveaux : au niveau système, l’adaptation est supportée par la flexibilité d’une organisation 124
Développer des applications distribuées ouvertes et adaptables en combinant : composants logiciels, agents et agents mobiles
dans laquelle des rôles sont attribués aux agents dynamiquement selon une mesure floue des capacités de ces derniers. Au niveau des agents, ces derniers s’adaptent en changeant leurs structures et leurs comportements pour occuper des positions dans l’organisation en effectuant des assemblages et des réassemblages adéquats de composants leurs permettant d’améliorer leurs capacités suite à l’intégration de composants obtenus selon des sélections intelligentes de composants. 4.3.4.1 Adaptation au niveau organisation Depuis leurs émergences, les systèmes multi agents (SMA) sont considérés comme des sociétés d’agents. C’est-à-dire, un SMA est vu comme étant un ensemble d’agent en interactions pour coordonner leurs comportements et coopérer pour atteindre des objectifs collectifs. Selon cette vision, les recherches dans le domaine des SMAs portent d’un côté sur les agents et sur les sociétés d’agents d’un autre côté. Dans cette dernière alternative, les organisations dans les systèmes multi agents sont proposées comme étant des techniques pour contraindre les comportements des agents vers la satisfaction de certains objectifs globaux. Les organisations présentent par nature un support efficace pour l’adaptation. C'est-à-dire, les systèmes multi agents conçus selon un point de vue social organisationnel sont facilement adaptables à travers l’évolution des organisations et les mécanismes intégrés d’auto organisation et de réorganisation signifiant le passage d’une organisation à une autre plus adaptée pour une situation ou un contexte donné. L’utilisation du concept de groupes flous (ensemble flous d’agents) avec la notion d’appartenance partielle des agents aux différents groupes comme moyen de partitionnement de l’organisation offre une grande dynamique à l’organisation proposée. Les agents n’appartiennent pas définitivement aux groupes. Ce que signifie que les rôles ne sont pas attribués statiquement et définitivement aux agents. À fur et à mesure que le système progresse dans l’exécution, les paramètres des F-groupes ou des rôles joués dans les Fgroupes seront changés par les agents superviseurs ou un administrateur du système affectant ainsi la mesure de capacité des agents pour jouer les rôles et donc leurs degrés d’appartenance aux F-groupes seront changés. Par conséquence, certains agents qui appartenaient partiellement à un F-groupe se trouvent exclus du groupe, d’autres appartiennent toujours au F-groupe mais avec des degrés d’appartenance plus élevés ou diminués par rapport aux degrés avec lesquels ils appartenaient au F-groupe avant les changements de paramètres. L’utilisation du concept de rôle comme l’un des éléments de base du modèle organisationnel proposé a son impact certain sur l’adaptabilité des applications dont la conception s’appuie sur le modèle que nous avons proposé. Un rôle représente une description abstraite d’un comportement d’un agent. Les rôles permettent de décrire les compétences que les agents doivent avoir et les comportements que les agents doivent être capables de reproduire pour être acceptés à les jouer. De ce fait, il est possible d’adapter les conditions d’attributions des rôles aux agents et le système peut à tout moment alléger ou rendre plus sévère les conditions d’attribution des rôles aux agents. La structuration de l’espace 125
Développer des applications distribuées ouvertes et adaptables en combinant : composants logiciels, agents et agents mobiles
fonctionnel d’un système sous formes de rôles rend très facile l’ajout de nouvelles fonctionnalités ou services (adaptation évolutive)à travers l’ajout de nouveaux rôles sans être obligé d’arrêter le système. L’ajout d’un rôle revient à l’insertion de fichiers de description ainsi que l’insertion de nouveaux composants implémentant les compétences requises par le rôle dans les différents dépôts ou bibliothèques de composants. La possibilité d’ajouter des composants présente un support pour une adaptation perfective même sans ajouter de nouveaux rôles. C'est-à-dire, les performances du système peuvent être améliorées en ajoutant des composants qui réimplémentent plus efficacement des compétences existantes. D’un autre côté, Les rôles peuvent être utilisés pour la restriction de l’activité individuelle des agents. Et donc, contraindre leurs comportements pour bien se rencontrer avec les objectifs globaux du système. Par conséquence, il est possible d’adapter les comportements des agents en modifiant les descriptions des rôles qu’ils jouent. 4.3.4.2 Adaptation aux niveaux des agents Les agents de l’organisation (agents qui jouent les rôles services ou les rôles de supervision des F-groupes) sont conçus pour être auto adaptatifs. Ces agents sont construits selon l’architecture présentée dans la section 4.3.3.1.2 et illustrée dans la figure 4.3 par assemblages automatiques de composants et adaptés dynamiquement par réassemblages automatiques des composants à l’intérieur des enveloppes logicielles des agents. L’adaptation est le processus par lequel un agent est modifié afin de prendre en compte un changement que ce soit au niveau de l’environnement ou du système auquel l’agent fait partie. Il s’agit d’un processus en trois temps. Il faut détecter les situations nécessitant une adaptation, décider de la réaction la plus appropriée à la situation détectée, et enfin réaliser les traitements décidés. L’adaptation d’un agent est dirigée par l’organisation. C'est-à-dire, selon le rôle que l’agent désire jouer ou le F-groupe auquel appartient l’agent. Dans le cas où un agent A de l’organisation n’est pas autorisé pour jouer un rôle service ou un rôle de supervision par les agents superviseurs du F-groupe auquel appartient l’agent à cause de manque en capacités requises pour jouer le rôle ou parce qu’il existe un nombre suffisant d’agents mieux équipés en capacités pour jouer le rôle en question. L’agent A procède à une adaptation pour améliorer ces capacités à l’égard du rôle qu’il veut jouer. L’adaptation consiste à acquérir de nouvelles compétences en intégrant de nouveaux composants dans les différentes enveloppes logicielles de l’agent. Cette acquisition de compétence se fait en deux phases : sélectionner les meilleurs composants dans lesquels les compétences requises sont implémentées, puis effectuer le ou les réassemblages de ces composants dans les différentes enveloppes logicielles de l’agent. 4.3.4.2.1 Sélection de composants L’utilisation des composants pour construire des agents offre les mêmes avantages que l’utilisation des composants pour développer tout système logiciel d’une manière générale. 126
Développer des applications distribuées ouvertes et adaptables en combinant : composants logiciels, agents et agents mobiles
Particulièrement la structuration, la grande mise en valeur d’une réutilisation effective ainsi que les importantes possibilités d’adaptation de la structure et du comportement des agents à travers les possibilités d’assemblages et de reconfigurations dynamiques des composants. La réutilisation des composants lors du développement des agents porte deux avantages majeurs. En premier, la réutilisation a des impacts positifs sur la réduction des coûts de développement des agents. En second, à force de réutiliser des composants, ces derniers seront testés plusieurs fois dans plusieurs contextes, ce que augmente très probablement la qualité des composants et donc par conséquence augmenter la qualité des agents construits à base de ces composants. Le succès du développement des agents à base de composants en valorisant les avantages résultant de l’utilisation des composants dépend étroitement de la manière avec laquelle les composants à utiliser sont sélectionnés. La sélection des composants est une tâche fastidieuse dans le processus de développement à base de composants vu l’existence de plusieurs considérations techniques et autres que techniques à prendre en compte. Dans l’approche de l’organisation floue que nous proposons, les composants sont sélectionnés pour être intégré dans des agents en fonction des rôles qu’ils jouent dans l’organisation. D’une manière générale, des composants qui implémentent des compétences nécessaires aux agents pour qu’ils puissent jouer des rôles seront sélectionnés parmi plusieurs composants candidats selon plusieurs critères de sélections qui peuvent être en conflit les uns avec les autres. Ce problème peut être abordé par les approches proposées pour adresser les problèmes dits MCDM (Multi Criteria decision making). 4.3.4.2.1.1 Aperçu sur les méthodes de sélection de composants
Dans la littérature, il existe plusieurs travaux dans lesquels la sélection des composants est abordée. Certaines approches proposées sont manuelles et qui reposent généralement sur les techniques basées sur des calculs de scores pondérés où il est question de choisir parmi n candidats selon m critères de sélection un ou plusieurs composants. Par exemple, l’approche proposée par Collier et al [41] appartient à cette catégorie de méthodes. Dans d’autres travaux comme [1] et [82], les auteurs proposent des méthodes automatiques pour la sélection des composants. Entre les deux alternatives, il existe des approches qualifiées de semi automatiques comme l’approche proposée par Maxville et al [108] où les auteurs adressent la sélection de composants comme étant un problème de classification dans lequel chaque composant est affecté à une classe en fonction de son acceptabilité calculée pour le projet sujet de développement. Le processus de sélection proposé dans [108] prend en considération les dépendances entre les attributs des composants ainsi que les conflits qui résultent de ces dépendances. Le processus de sélection proposé par Maxville utilise deux techniques de l’intelligence artificielle pour réduire le temps et l’effort nécessaires pour la sélection des composants. Il s’agit de l’utilisation de la technique de classification supervisée C4.5 [149] et 127
Développer des applications distribuées ouvertes et adaptables en combinant : composants logiciels, agents et agents mobiles
les réseaux de neurones artificiels [90] pour générer les classeurs qui agissent à partir d’une spécification idéal écrite en XML du composant ciblé. Il est clair que les méthodes manuelles et même celles qualifiées de semi- automatique ne peuvent être d’aucune utilité pour l’approche organisationnelle que nous proposons. L’assemblage des composants est dynamique et donc leurs sélections sont dynamiques et effectuer en cours d’exécution sans faire arrêter les agents ou le système. Parmi les approches automatiques proposées pour sélectionner des composants nous pouvons citer l’approche proposée par Abraham et Aguilar [1] ainsi que celle proposée par JADHAV et AL [82]. Dans les travaux d’Abraham et Aguilar [1], une sélection intelligente des composants était proposée on faisant intervenir des concepts de l’intelligence collective [90]. Le processus de la sélection choisie le meilleur composant qui convient parmi plusieurs composants en fonction d’une spécification initiale idéale pour le composant cherché. Cette spécification initiale est exprimée en XML. La spécification du composant cible et les spécifications des composants candidats sont séparées en caractéristiques dynamiques et en caractéristiques statiques. Les caractéristiques dynamiques sont des caractéristiques qui peuvent changer dans le temps comme les performances des composants. Les caractéristiques statiques ne changent pas dans le temps comme le nom du composant. L’approche proposée étant émergente, utilise de la phéromone pour trouver le meilleur composant. Selon les besoins ciblés, à chaque fois l’ajout ou l’évaporation de la phéromone exprime les performances des composants dans un domaine particulier. Les valeurs de la phéromone sont stockées dans les profiles des composants. Les auteurs proposent un algorithme qui sélectionne la meilleure alternative en prenant en considération les feedbacks positifs et négatifs des composants. Les composants ayant les plus grandes valeurs de la phéromone sont sélectionnés. L’avantage principal d’une telle approche réside dans la possibilité de sa réplication sur la sélection d’autres types d’entités logicielles comme les services et les ressources. L’approche proposée par JADHAV [82] présente une technique pour sélectionner des composants en combinant le raisonnement à base de règles (RBR) et le raisonnement par cas (CBR). Le raisonnement à base de règles assiste l’utilisateur pour déterminer les critères d’évaluation et pour capturer les besoins ciblés. Le raisonnement par cas permet de comparer les besoins ciblés avec les composants candidats. Les candidats sont stockés sous forme de cas dans la base des cas du système. Le système produit comme résultat une liste de composants ordonnés selon un degré de similarité qui exprime à quel point chaque composant candidat rencontre les besoins ciblés. 4.3.4.2.1.2 Solution proposée pour la sélection de composants
Chacune des méthodes de sélection de composants est caractérisée par ses points forts et ses limitations. Aucune méthode n’est parfaite et meilleure dans toutes les situations. Néanmoins, nous pouvons constater que les méthodes automatiques et totalement automatisables sont certainement meilleures que les méthodes manuelles ou semi automatiques parce qu’elles permettent d’obtenir de bons degrés d’exactitude lors de la sélection des composants. Dans le contexte où nous envisageons faire intervenir la sélection des composants, cette dernière ne peut être qu’une sélection automatique. Pour s’adapter 128
Développer des applications distribuées ouvertes et adaptables en combinant : composants logiciels, agents et agents mobiles
dynamiquement sans interventions externes, les agents doivent trouver les composants qui implémentent les compétences dont les agents ont besoin et les faire intégrés dans leurs enveloppes de service, de communication, de navigation et de perception de l’environnement. Par conséquence, Pour s’adapter dynamiquement sans interventions externes, les agents doivent utiliser une méthode totalement automatique pour sélectionner les composants ciblés. Quelque soit la méthode à utiliser pour chercher et sélectionner des composants, deux alternatives sont possibles. La première consiste à mettre la recherche et la sélection des composants à la charge des agents eux-mêmes. C'est-à-dire, que les agents qui désirent jouer le rôle service ou le rôle superviseur dans un F-groupe doivent eux-mêmes chercher les composants qui implémentent les compétences qui leurs faut pour jouer le rôle service ou le rôle superviseur du F-groupe. La deuxième alternative consiste à mettre la recherche et la sélection des composants à la charge d’autres entités, des agents spécialisés par exemple, qui seront sollicités par les agents de l’organisation (les agents qui jouent les rôles service ou les rôles de supervision) pour leurs chercher et sélectionner des composants. Nous adoptons la deuxième alternative puisque elle permet d’assurer plus d’efficacité pour trouver les composants ciblés et pour ne pas encombrer les agents de l’organisation et rendre leurs implémentations plus compliquées et lourdes surtout pour le cas où les agents qui sont amenés à jouer un rôle donné sont mobiles.
Figure 4.9 : Vue d’ensemble d’un système où 3 rôles sont joués
129
Développer des applications distribuées ouvertes et adaptables en combinant : composants logiciels, agents et agents mobiles
La solution que nous utilisons pour implémenter un système qui sélectionne les composants pour l’intérêt des agents de l’organisation est inspirée et proche de l’approche proposée par Abraham et Aguilar [1] présentée ci-dessus. Les composants peuvent être répartis physiquement dans plusieurs localités ou dépôts. La sélection est réalisée par des agents appelés Sélecteurs en utilisant des fichiers XML associés aux composants. Pour chaque composant un fichier XML est associé contenant ses propriétés fonctionnelles et non fonctionnelles pertinentes. Ainsi, La vue d’ensemble illustrée dans la figure 4.1 est à remplacer par la vue illustrée dans la figure 4.9. Chaque fichier XML contient un où plusieurs champs spécifiques appelés scores. Ces champs contiennent des valeurs exprimant les performances du composant au quel le fichier est associé vis-à-vis chaque rôle joué dans l’organisation. Les scores sont similaires à la phéromone qui présente l’un des concepts de la théorie de l’intelligence artificielle collective [90]. Dans le cas où un agent Ai de l’organisation, par manque de capacité n’est pas autorisé pour jouer un rôle service ρ par les agents superviseurs du F-groupe dans lequel le rôle ρ est joué, l’agent Ai procède à une adaptation pour améliorer ces capacités à l’égard du rôle ρ. L’adaptation consiste à acquérir de nouvelles compétences en intégrant de nouveaux composants dans les différentes enveloppes logicielles de l’agent. Pour y arriver, l’agent Ai prépare une spécification des compétences qui lui manque pour jouer le rôle ρ en consultant le fichier XML dans lequel le rôle ρ est décrit. L’agent Ai vérifie sa possession de chacune des fonctionnalités requises pour jouer le rôle ρ. c'est-à-dire, l’agent Ai vérifie que les composants intégrés dans ces différentes enveloppe implémentent ou non les fonctionnalités requises. Une fois la spécification des compétences demandées établie, l’agent Ai sollicite le service de l’un des agents sélecteurs en lui envoyant la spécification des compétences cherchées avec une image sur le contexte d’exécution prévu. Le contexte d’exécution est un élément déterminant pour la phase de sélection des composants et même pour celle de réassemblage effectif de composants. C'est-à-dire, ce contexte influence à la fois la sélection et l’assemblage de composants. La définition d’un contexte d’exécution est assurée par le module de contrôle en se basant sur un ensemble de sondes logicielles implémentées à base de composants dans l’enveloppe logicielle de perception de l’environnement. La définition d’un contexte d’exécution peut être le fruit d’interactions avec les autres agents dont l’agent est autorisé à communiquer avec. C'est-àdire, un agent peut récupérer une ou plusieurs images de contextes d’exécutions établies par d’autres agents. Cette faculté est très intéressante dans le cas où l’agent est mobile et ce dernier a décidé de se déplacer vers une autre localité ; l’agent récupère une image du contexte établie par l’un des agents qui opère dans la localité cible. Et donc, le réassemblage sera orienté par le contexte d’exécution de la localité cible. En fait, « Le Contexte n’est pas simplement l’état d’un environnement prédéfini avec un ensemble fixe de ressources d’interaction. Il fait partie d’un processus d’interaction avec un environnement en perpétuel changement composé de ressources reconfigurables, migrables, distribuées et multiéchelles » [43]. 130
Développer des applications distribuées ouvertes et adaptables en combinant : composants logiciels, agents et agents mobiles
Le contexte d’exécution regroupe des informations sur les ressources matérielles (par exemple, CPU, mémoire et et l’énergie (pour une batterie) disponible sur l’infrastructure où sont déployés les agents ou certains composants ….), les réseaux disponibles (par exemple, bande passante courante et bande passante maximale) et des données géophysiques (par exemple, localisation et température). Le module de contrôle de chaque agent en fonction de sa position dans l’organisation décide quelles sont les sondes de l’environnement nécessaires, il définit la fréquence à laquelle les données contextuelles sont mises à jour et la taille de l’historique des valeurs mesurées par chaque sonde. A titre d’illustration, la figure 4.10 montre la spécification d’une sonde qui teste périodiquement si le réseau Ethernet est disponible en évaluant une fonction #isAvailable. Etant donné que la partie de l’agent responsable de la perception de l’environnement est une enveloppe logicielle à base de composants, l’agent peut adapter ces compétences à cet égard par des réassemblages adéquats de composant dans l’enveloppe logicielle de perception de l’environnement de la même façon de l’acquisition de compétences en matières de communication, métier et mobilité. En recevant la spécification des compétences requises envoyée par un agent de l’organisation, l’agent sélecteur en consultant les fichiers XML associés aux composants établit une liste des composants dans lesquels les fonctionnalités requises sont implémentées en tenant compte des informations contenues dans l’image du contexte d’exécution. Un composant peut implémenter tout ou une partie des fonctionnalités requises. Par exemple, soient , , , les compétences ciblées par l’agent Ai . Soient les composants ∁ ,∁ ,∁ , ∁ , ∁ , ∁ , ∁ les composants candidats où ∁ implémente toutes les fonctionnalités
,
,
,
; ∁
implémente les fonctionnalités
,
;
∁ implémente aussi toute les fonctionnalités ; ∁ implémente les fonctionnalités ;∁ n’implémente aucune des fonctionnalités ciblées ; ∁ implémente et finalement on a ∁ qui implémente la fonctionnalité seule. L’agent sélecteur chargé de sélectionner les composants pour l’agent Ai détermine les alternatives suivantes : ∁ , ∁ , {∁ , ∁ },{∁ ∁ , ∁ }. networkAvailabilitySensor := Sensor new. networkAvailabilitySensor resource : ’external/hardware/network/ethernet’. networkAvailabilitySensor operation : #isAvailable updatePeriod : 1000.
Figure 4. 10 : Exemple de spécification de sonde
131
Développer des applications distribuées ouvertes et adaptables en combinant : composants logiciels, agents et agents mobiles
Un agent superviseur
Un agent qui désire jouer un rôle service
Un agent sélecteur
Envoyer une demande d’autorisation pour jouer le rôle Réponse
Oui Jouer le rôle
Autorisé ? Non Établir
Evaluer les performances des composants par rapport au rôle joué.
Une Spécification des compétences à acquérir + une image sur le contexte d’exécution
Envoyer une requête pour la sélection des composants implémentant les compétences requises Chercher les composants qui implémentent les compétences requises en consultant les fichiers associés aux composants.
Une présélection des composants
- Sélectionner le ou les meilleurs composants parmi la présélection en fonction des traces d’utilisation (la plus grande valeur de phéromone). - Effectuer une évaporation de la phéromone pour les composants non choisis.
Liste des Composants sélectionnés
Réponse à la requête (Liste des composants sélectionnés) Effectuer un réassemblage de composants en intégrant les composants sélectionnés Non
Réassemblage réussi ?
Oui Envoyer les résultats d’évaluation des performances des composants Mettre à jour les scores (phéromone) des composants évalués
Figure 4.11 : Macro algorithme explicitant l’activité de sélection de composants
132
Développer des applications distribuées ouvertes et adaptables en combinant : composants logiciels, agents et agents mobiles
Parmi les alternatives déterminés comme une présélection, l’agent sélecteur choisit le meilleur composant en se basant sur le score (phéromone) du composant relatif au rôle ρ. A chaque fois qu’un composant est utilisé par un agent pendant qu’il joue un rôle donné, la performance du composant par rapport à ce rôle est testée. Le teste de la performance se traduit en un ajout de phéromone dans le cas où le composant fait preuve de bonne performance ou une évaporation de la phéromone dans le cas contraire. Si un composant qui apparait dans la présélection n’est pas sélectionné pour être utilisé, une évaporation de la phéromone est effectuée selon un certain coefficient d’évaporation α. Un même composant n’a pas forcement les mêmes performances à l’égard de tous les rôles. C’est pour cette raison que le fichier associé au composant incorpore plusieurs scores exprimant chacun une performance par rapport à un rôle (figure 4.12). La mesure de la performance d’un composant est fonction de plusieurs facteurs comme le temps d’exécution, la quantité de mémoire nécessaire et le nombre de dépendances que le composant a besoin. Le diagramme figurant dans la figure 4.11 présente un macro-algorithme du processus de sélection de composants.
PRU0707 Report Manager gpl www.location.con/sublocation Component1–Component2-………-Package1-…… …………… Interfaces_avec_signatures Fonctionnalités_implémentées …………… idRole1 0.1 … …………… 0.01 idRole2 0.5 0.1 … …………… 0.07 ……… ………
Figure 4.12 : Contenu d’un fichier de description de composant.
133
Développer des applications distribuées ouvertes et adaptables en combinant : composants logiciels, agents et agents mobiles
4.3.4.2.2 Réalisation des réassemblages de composants Le réassemblage de composants ou la reconfiguration d’un assemblage de composants est la dernière phase de l’adaptation de l’agent. Cette reconfiguration consiste à ajouter des composants déjà sélectionnés, supprimer des composants ou remplacer des composants par d’autres composants sélectionnés dans la phase précédente. Le réassemblage de composants est effectué dans les différentes enveloppes logicielles de l’agent suivant la catégorie de compétences ciblée par l’adaptation. Si l’adaptation cible une amélioration des compétences dans le sens métier, seule l’enveloppe service est concernée par l’opération de réassemblage. Dans le cas où des compétences en termes de communication sont à acquérir, l’enveloppe communication de l’agent est concernée par le réassemblage envisagé. L’opération de réassemblage de composant est assurée par une constituante de l’agent appelé moteur d’assemblage de composants. Ce concept qui présente une infrastructure d’adaptation dynamique des applications à base de composants est proposé par Grondin [67] à partir des définitions des problèmes d’assemblage automatique de composants [160], [80]. Ce moteur d’assemblage qui est un élément essentiel dans l’architecture de l’agent illustrée dans la figure 4.3 est nécessaire pour l’automatisation de la tâche d’assemblage de composants nécessaire à son tour pour la mise en œuvre de mécanismes pour l’adaptation dynamique des agents. Composants Contexte d’exécution
Module de contrôle
Description du rôle à jouer.
Moteur d’assemblage
Spécification des compétences à acquérir. Enveloppe Logicielle Entrée Sortie Assemblage
Figure 4.13 : Schématisation du moteur d’assemblage.
134
Développer des applications distribuées ouvertes et adaptables en combinant : composants logiciels, agents et agents mobiles
Le moteur d’assemblage dont une schématisation simplifiée est l’objet de la figure 4.13, permet d’assembler un ensemble de composants préalablement sélectionnés ou qui existent déjà dans les enveloppes logicielles d’un agent pour construire ou adapter les différentes enveloppes logicielles de ce dernier, de façon à satisfait la description fournie par le module de contrôle de l’agent et celle décrivant le rôle que l’agent procède à l’adaptation pour le jouer tout en tenant compte des informations contenu dans le contexte d’exécution.
Le moteur d’assemblage récupère les composants à assembler depuis les sources où ils sont situés. Chaque composant récupéré est intégré dans une enveloppe de composant à l’intérieur de l’enveloppe logicielle cible de réassemblage. Chacune des interfaces du composant est liée à un port de l’enveloppe de composant par le moteur d’assemblage qui instancie le type du port en accordance avec le type de l’interface. Les connexions entre les composants sont assurées par un bus logiciel à l’intérieur de l’enveloppe logicielle auquel sont reliés tous les ports de toutes les enveloppes de composants figure (4.14). Le bus logiciel interne d’une enveloppe logicielle véhicule les invocations des interfaces des composants ainsi que les données échangées entre les composants. Une fois l’assemblage de composants réalisé à l’intérieur de l’enveloppe, les interfaces fournies et requises de la composition obtenue seront reliées aux ports virtuels de l’enveloppe. Lors de l’intégration des composants dans les enveloppes de composants, le moteur d’assemblage procède à une vérification de la compatibilité entre les interfaces de composants en dépendance. La vérification de la compatibilité est principalement syntaxique où en se contente d’un contrôle de compatibilité de types. Si des incompatibilités sont détectées lors de la vérification, le moteur d’assemblage demande au module de contrôle de relancer une nouvelle session de sélections de composants compte tenu des incompatibilités détectées.
Une fois l’assemblage des composants effectué avec succès, l’agent reprend une nouvelle session d’interaction avec l’un des agents superviseurs pour relancer à nouveau son vouloir de jouer le rôle pour le quel l’agent s’est adapté.
135
Développer des applications distribuées ouvertes et adaptables en combinant : composants logiciels, agents et agents mobiles
Enveloppe de composant N
Enveloppe de composant 2
Enveloppe de composant 1
Bus Logiciel interne
Enveloppe logicielle
Port de l’enveloppe logicielle
Composant
Interface du Composant
Port de l’enveloppe composant Insertion d’un composant dans une enveloppe composant Liaison entre interface de composant port d’enveloppe composant
Moteur d’assemblage
Liaison entre le moteur d’assemblage et enveloppe composant
Figure 4.14 : Assemblage de composants dans une enveloppe logicielle
4.4 Conclusion
Dans ce quatrième chapitre du manuscrit, nous avons présenté en fournissant une description détaillée, l’approche que nous avons proposée pour le développement des applications qui sont distribuées, ouvertes et équipées de pouvoirs d’adaptation. Dans cette approche, deux paradigmes importants ayant leurs impacts certains sur le monde du développement de logiciels sont combinés. Il s’agit des composants logiciels d’un côté et des agents qui peuvent être mobiles ou non de l’autre. Les agents et les composants logiciels sont utilisés les uns à côté des autres dans une perspective de recherche d’une combinaison entre les deux paradigmes dans laquelle nous pouvons tirer profit de tous les points forts de chacun des paradigmes en exploitant toutes les puissances des deux paradigmes en termes de structuration, réutilisations, possibilités d’adaptation, supports pour la gestion de l’ouverture, supports pour la distribution, les hauts niveaux d’abstraction et la flexibilité du couplage qu’offre chacun des paradigmes. Durant la présentation de l’approche proposée, on a met en claire les arguments qui nous ont dirigé vers la vision selon laquelle l’approche est développée. L’approche consiste à développer les applications distribuées, ouvertes et adaptables sous forme de systèmes multi agents dont les constituants sont des agents construits à base de composants en s’appuyant 136
Développer des applications distribuées ouvertes et adaptables en combinant : composants logiciels, agents et agents mobiles
sur un point de vue social comme cadre d’analyse et de conception. L’organisation proposée est basée essentiellement sur le concept de rôle. Cette organisation est flexible et sert comme base pour doter le système à développer de pouvoirs d’adaptation à travers une attribution dynamique des rôles aux agents, une attribution qui repose sur la théorie des ensembles flous comme théorie derrière. Les rôles sont joués par les agents dans des groupes d’agents appelés F-groupes qui sont des ensembles flous d’agents où le degré d’appartenance de chaque agent à un F-groupe exprime sa capacité de jouer le rôle du F-groupe. La capacité d’un agent pour jouer un rôle est calculée à travers une mesure floue multi dimensionnelle (détaillée dans le prochain chapitre) en fonction de la composition de l’agent. C’est-à-dire, en dépendance avec les composants utilisés pour la construction de l’agent. En fonction de leurs positions dans l’organisation, les agents sont construits et adaptés par assemblages et/ou réassemblage de composants sélectionnés d’une manière intelligente par des agents spécialisés qu’on a appelés agents sélecteurs. Ainsi, les comportements et les structures des agents seront adaptés sous la contrainte de l’organisation d’où la convergence vers une attribution optimale des rôles aux agents. C’est-à-dire, à fur et à mesure que le système progresse dans son exécution, les rôles seront joués par les meilleurs agents en termes de capacités. Il est à mentionner, le présent chapitre ne fournit aucune évaluation ni mesure de l’importance et des performances de l’approche proposée. La mesure du poids de cette approche est retardée pour apparaitre sous la forme d’un bilan à la fin du 6ème chapitre dans lequel on présentera l’utilité et la faisabilité de l’approche proposée à travers la conception de deux exemples de systèmes différents avec une implémentation et des expérimentations sur l’implémentation de l’un des deux exemples.
137
Chapitre V Une mesure floue multidimensionnelle des capacités des agents pour jouer des rôles.
Une mesure floue multidimensionnelle des capacités des agents pour jouer des rôles.
Chapitre V Une mesure floue multidimensionnelle des capacités des agents pour jouer des rôles.
5.1 Introduction Dans un système ouvert où des agents de nature différentes arrivent et quittent le système, il est d’extrême importance de garantir ou au moins estimer qu’un agent qui va être amené à jouer un rôle sera effectivement en mesure de l’accomplir. En outre, si le système doit faire une sélection de quelques agents parmi plusieurs autres pour jouer un rôle, comment peut on créer un ordre de préférence entre plusieurs agents selon leurs capacités de jouer le rôle en question ? Ce problème de conformité d’agents aux rôles reste encore peu abordé, malgré qu’il nous semble un enjeu réel. Ce problème a été identifié dans [69] comme le problème de l’admission d’un agent dans un groupe, où les auteurs proposaient comme piste de solution la sanction d’agents s’ils ne remplissaient pas leurs engagements. Nous pensons que si le système peut faire des mesures sur les capacités des agents pour jouer un rôle, le problème de conformité d’agents aux rôles sera définitivement réglé. La capacité d’un agent pour jouer un rôle ou pour accomplir une mission peut se définir par référence à un seuil. Si un système composé d’agents se trouve devant une situation où il doit autoriser des agents à jouer un rôle ou pour accomplir une mission et interdire d’autres agents pour le faire, il s’agit de partitionner les agents en deux classes : capables et non capables de jouer le rôle en question. Or, cette restitution dichotomique des agents entre capables et non capables paraît abrupte car elle se présente comme une formulation du type « tout » ou « rien ». Il est donc question d’assouplir cette division abrupte et chercher un passage d’un état de privation de capacités à une situation de non privation qui se fait de manière graduelle. Pour se faire, on peut recourir à la théorie des ensembles flous introduite en 1965 par L.A. Zadeh [181][48], reflétant l’admission de l’existences de situations intermédiaires entre le tout et le rien à 139
Une mesure floue multidimensionnelle des capacités des agents pour jouer des rôles.
partir de l’idée d’appartenance partielle à une classe, de catégorie aux limites mal définies et de gradualité dans le passage d’une situation à une autre. La théorie des ensembles flous apparaît comme un outil bien adapté pour modéliser un concept vague tel que la capacité d’un agent ou de toutes entités logicielles pour jouer un rôle donné ou pour accomplir une tâche précise. En fait, il s’agit d’établir une fonction d’appartenance des agents à un ensemble d’agents (groupe) amenés à jouer un rôle qui, à ses extrémités, inclut les agents ou l’en exclut de façon certaine, mais qui, entre les valeurs extrêmes, varie à proportion de la proximité au groupe. L’avantage de cette théorie, c’est qu’elle offre la possibilité de combiner différents aspects de capacités des agents tel que la mobilité, le savoir faire, la possession de ressources,…etc. Dans ce chapitre, nous présentons dans une première partie de façon sommaire la théorie des sous-ensembles flous ; dans une deuxième partie, nous passons à la formulation proposée pour adapter cette théorie à la mesure de la capacité d’un agent pour jouer un rôle dans une organisation dont le modèle sous-jacent est le modèle organisationnel présenté dans le chapitre précédent. Enfin, dans la troisième partie, on présente une analyse multidimensionnelle de la capacité d’un agent pour jouer un rôle en recourant à une mesure floue de cette dernière.
5.2 Ensembles flous
La théorie des ensembles flous introduite par Zadeh [181] s’inscrit dans une tendance vers un rapprochement entre la précision des mathématiques classiques et l’imprécision délicate du monde réel. Ce rapprochement peut être situé dans la direction des travaux de recherches qui ciblent comme objectif de comprendre et de reproduire les capacités de l’homme de raisonner sur des données et des connaissances imprécises. Cette théorie a pour objet d’étude, la représentation des connaissances imprécises et le raisonnement approché, elle peut être située à côté des méthodes heuristiques de résolutions de problèmes, des systèmes experts, de l’apprentissage, de l’intelligence artificielle distribuée. La logique floue et la théorie des ensembles flous sont impliquées et utilisées dans plusieurs domaines tel que l’informatique, la médecine, l’économie, les processus de production industriels et plusieurs autres domaines d’application. Les exemples témoignant cette utilisation sont variés et nombreux et nous pouvons citer juste à titre d’exemples : en économie le caractère flou des préférences des agents fut traité ; Dans le domaine d'automatisme, la logique foule est beaucoup utilisée pour de nombreuses applications comme le pilotage d'avions et de trains automatiques. De nombreuses disciplines informatiques utilisent également la logique foule où nous pouvons citer notamment l'intelligence artificielle (représentation des connaissances), les bases de données (manipulation des informations incomplètes et imprécises), la recherche d'information et la programmation floue ou à orientation linguistique. 140
Une mesure floue multidimensionnelle des capacités des agents pour jouer des rôles.
Dans ce qui suit, nous présentons brièvement les concepts de base et les principes de l’arithmétique de la théorie des ensembles flous. Pour avoir plus de détails ainsi qu’une vue approfondie sur cette théorie on peut se référer aux ouvrages de bases comme [24] ou [48]. 5.2.1
Sous ensembles flous
Contrairement à la théorie des ensembles classiques où il en existe que deux situations acceptables pour un élément, appartenir ou ne pas appartenir à un sous-ensemble. La théorie des ensembles flous sort de cette logique booléenne en introduisant la notion d’appartenance pondérée pour permettre d’exprimer des graduations dans l’appartenance d’un élément à un sous-ensemble, c'est-à-dire d’autoriser un élément à appartenir plus moins fortement à ce sous-ensemble (figure 5.1). Soit un ensemble de référence et soit un élément quelconque de ensemble flou de est défini comme l’ensemble des couples : =
,
( ) ,
∈
Avec
. Un sous-
( ) → [0,1] ...........(i)
Un sous-ensemble flou de est caractérisé par une fonction d’appartenance ( ) qui associe, à chaque élément de un réel dans l’intervalle [0,1]; la fonction ( ) représente le degré d’appartenance de à . Et donc, nous pouvons distinguer les possibilités suivantes : ( ) = 0; 0 < ( ) < 1; ............(ii) ( )=1 C’est cas reflètent les différentes situations d’appartenance possibles. ( ) = 0 dans le cas où n’appartient pas ; 0 < ( ) < 1 si appartient partiellement à ; et ( ) = 1 si x appartient entièrement à . La fonction d’appartenance ( ) inclut ou exclut donc à ses extrémités d’une manière ferme, tout élément au sous-ensemble , mais entre les valeurs extrêmes le degré d’appartenance varie à proportion de la proximité à l’ensemble . Dans le cas d’un sous-ensemble classique, la fonction d’appartenance qui lui est associée ne peut prendre que les valeurs extrêmes 0 et 1. Par exemple, Si est l'ensemble des villes algériennes, nous pouvons définir le sousensemble flou des villes proches de Constantine. Ce sous-ensemble peut être décrit par la ( , ) fonction d'appartenance suivante : ( ) = max(0,1 − 100) où ( , )représente la distance entre la ville
et Constantine.
141
Une mesure floue multidimensionnelle des capacités des agents pour jouer des rôles.
Figure 5.1 : Ensemble classique et ensemble flou.
5.2.2 Caractéristiques d’un sous-ensemble flou La fonction d’appartenance d’un sous-ensemble flou suffit pour définir complètement ce dernier. Une telle fonction permet d’étudier certaines caractéristiques du sous-ensemble flou [21] que nous présentons dans ce qui suit d’une manière brève. 5.2.2.1 Fonctions d’appartenances Il n’existe pas de règles qui permettent la définition des fonctions d’appartenance d’une manière parfaite. La forme mathématique de la fonction et ses paramètres dépendent de la contribution des experts du domaine concerné par l’étude. La qualité d’une fonction d’appartenance peut être mesurée selon les cohérences des degrés d’appartenance quelle permet de calculer, si l’on procède par comparaison, la conclusion fondée sur les ensembles flous demeure significative. Par exemple, si pour un concept quelconque trois sous ensembles flous sont déterminés, « élevé », « moyen », et «faible » le degré d’appartenance d’un élément à l’ensemble flou « élevé » ne devrait pas être inférieur à celui de son appartenance à l’ensemble « moyen ». Les fonctions d’appartenance aux ensembles flous sont habituellement simples. Elles sont fréquemment linéaires et elles prennent souvent la forme d’un triangle trapézoïde, L ou r. Elles peuvent également être gaussiennes ou de type gamma. Différentes fonctions d’appartenance peuvent être définies pour un ensemble flou en raison de niveaux de connaissances ou d’expérience des personnes qui définissent ces dernières. De façon générale, elles peuvent désigner des choses semblables lorsqu’elles font référence à un ensemble flou qui permet de mettre au point un système en langage courant fondé sur les méthodes de raisonnement habituelles chez l’homme.
142
Une mesure floue multidimensionnelle des capacités des agents pour jouer des rôles.
La fonction d’appartenance d’un sous-ensemble flou définit complètement les caractéristiques de ce dernier comme le noyau, la cardinalité, la hauteur et le support ainsi que le α –coupe. 5.2.2.2 Noyau ( ) , est l’ensemble de tous les Le noyau d’un sous-ensemble flou de , noté éléments qui lui appartiennent totalement. Ce qui peut être exprimé formellement comme : 5.2.2.3 Cardinalité
( )={ ∈
|
( ) = 1}
La cardinalité d’un sous-ensemble flou de , noté | | , est le nombre d’éléments qui appartiennent à pondéré par leur degré d’appartenance. Pour fini, la cardinalité est exprimée comme :
5.2.2.4 Support et Hauteur
| |=
∈
( )
Les caractéristiques Support et Hauteur montrent dans quelle mesure un sous-ensemble flou de diffère d’un sous-ensemble classique de . Le support d’un sous-ensemble flou de , noté ( ) , est l’ensemble de tous les éléments qui lui appartiennent au moins un petit peu. Ce qui peut être exprimé formellement comme : ( )={ ∈
( )>0}
La hauteur du sous-ensemble flou de , notée ℎ (A), est le plus fort degré avec lequel un élément de appartient à . Ce qui est exprimé formellement comme:
5.2.2.5
-coupe
ℎ( )=
∈
( )
Le sous-ensemble ordinaire de associé à pour le seuil est l’ensemble des éléments qui appartiennent à avec un degré supérieur ou égal à . On dit que est l’ coupe de qu’on peut exprimer formellement comme suit : ={ ∈
|
( ) >= }
143
Une mesure floue multidimensionnelle des capacités des agents pour jouer des rôles.
5.2.3 Opérations sur les sous-ensembles flous Comme en théorie classique des ensembles, les ensembles flous ont leurs propres opérations, notamment l’union, l’intersection et le complément. Ces opérations diffèrent des opérations relatives aux ensembles classiques et reposent sur les fonctions d’appartenance. 5.2.3.1 Egalité Deux sous-ensembles flous et de sont égaux, si pour chaque élément de leurs fonctions d’appartenance prennent la même valeur. Formellement = si et seulement si : ∀ ∈ X, ( ) = ( ) 5.2.3.2 Complément
Le complémentaire d’un sous-ensemble flou de X noté ̅ est défini par : ∀ ∈ X, ̅ ( ) = 1 − ( )
Les propriétés de non contradiction ( ∩ ̅ ≠ ∅) et celle du tiers exclus ( ∪ ̅ ≠ ) ne sont pas satisfaite pour les ensembles flous contrairement aux ensembles classiques. Par contre, les autres propriétés sont conservées ̿ = ; ∅ = ; = ∅ ; | ̅| + | | = | | si est fini. 5.2.3.3 Inclusion Soit et deux sous-ensembles flous de . Si pour n’importe quel élément appartient toujours moins à qu’à , alors on dit que est inclus dans Formellement, ⊆ si et seulement si : ∀ ∈ X, ( ) ≤ ( )
de , ( ⊆ ).
5.2.3.4 La différence
La différence entre deux sous-ensembles flous et de est le sous-ensemble flou constitué des éléments de affectés du plus petit des degrés avec lesquels ils appartiennent à et . Formellement, − est donné par : ( ) = min ( ( ), 1 − ( )) 5.2.3.5 Union
L’union de deux sous-ensembles flous et de est le sous-ensemble flou constitué des éléments de affectés du plus grand des degrés avec lesquels ils appartiennent à et . Formellement, ∪ est exprimé par :
144
Une mesure floue multidimensionnelle des capacités des agents pour jouer des rôles.
∪
5.2.3.6 Intersection
( ) = max (
( ),
( ))
L’intersection de deux sous-ensembles flous et de est le sous-ensemble flou constitué des éléments de affectés du plus petit des degrés avec lesquels ils appartiennent à et . Formellement, ∩ est exprimé par : ( )) ∩ ( ) = min ( ( ), Les propriétés de treillis distributif et les relations de Morgan ainsi que l’idempotence restent valables pour les opérations d’union et d’intersection appliquées aux ensembles flous tout Comme pour les ensembles classiques.
Commutativité : on a ∩ = ∩ ainsi que ∪ = ∪ Associativité: on a ∩ ( ∩ ) = ( ∩ ) ∩ et ∪ ( ∪ ) = ( ∪ ) ∪ Idempotence : on a ∩ = ainsi que ∪ = Distributivité: ∪ ( ∩ ) = ( ∪ ) ∩ ( ∪ ) et ∩ ( ∪ ) = ( ∩ ) ∪ ( ∩ ) Les relations de Morgan : on a ∩ = ̅ ∪ et ∪ = ̅ ∩ Les lois d’absorption : on a ∪ ( ∩ ) = ∩ ( ∪ ) = Identité : on a ∪ ∅ = et ∩ = Cardinalité : on a | | + | | = | ∩ | + | ∪ | Formule d’équivalence : ( ̅ ∪ ) ∩ ( ∪ ) = ( ̅ ∩ ) ∪ ( ∩ ) Formule de la différence symétrique : ( ̅ ∩ ) ∪ ( ∩ ) = ( ̅ ∪ ) ∩ ( ∪ )
5.3 Une Mesure floue des capacités des agents pour jouer les rôles
Il est à rappeler que le modèle organisationnel de système multi agents proposé et présenté dans le chapitre précédant repose sur le concept de rôles joués par les agents dans une alliance appelée F-groupe. Un F-groupe d’un rôle ρ est un ensemble d’agents concernés par jouer le rôle ρ. Parmi les agents qui appartiennent à un F-groupe d’un rôle ρ, seuls les meilleurs agents en termes de capacités seront autorisés pour jouer ce rôle. Donc il est question de mesurer la capacité des agents pour jouer les rôles. On a admis qu’une vision dichotomique de la capacité d’un agent pour jouer un rôle (capable et non capable) représente une simplification trop exagérée de la réalité et ne permet pas la création d’un ordre de préférence entre les agents pour décider qu’un agent A est mieux positionné qu’un autre agent B pour jouer un rôle donné. Pour parvenir à mieux gérer cette situation, le concept ensembliste d’appartenance graduelle d’un élément à un ensemble apparaît comme un cadre idéal pour modéliser la capacité des agents pour jouer des rôles. On peut définir un sousensemble flou des agents capables de jouer un rôle donné en se référant aux expressions (i) et (ii) où la fonction d’appartenance au F-groupe exprime à quel degré chaque agent est en mesure d’accomplir le rôle joué au sein du F-groupe. 145
Une mesure floue multidimensionnelle des capacités des agents pour jouer des rôles.
Pour un rôle donné ρ, Considérons le F-groupe
( = 1,2,3, … , ) souhaitant jouer le rôle ρ. Le sous-ensemble flou
n agents
capables de jouer le rôle ρ parmi les agents ρ
Où,
présentant un ensemble composé de
ρ
=
,
ρ
( ) ,
ρ
des agents
est défini comme l’ensemble des couples :
∈
Avec
ρ
( ) → [0,1]
( ) représente le degré d’appartenance de chaque agent
au sous-ensemble flou
des agents capables de jouer le rôle ρ reflétant la capacité de l’agent D’où trois situations sont distinguables :
pour jouer le rôle ρ.
( ) = 0; 0 < ρ ( ) < 1; ………(iii) ( ) = 1. ρ ρ
Où, 0<
ρ
l’agent
ρ
( ) = 0 si l’agent
( ) < 1 si l’agent
n’est pas capable de jouer le rôle ρ de façon sûre ;
est partiellement capable de jouer le rôle ρ; et
est totalement capable de jouer le rôle ρ.
ρ
( ) = 1 si
Il est question maintenant de définir comment construire la fonction d’appartenance
ρ
qui va permettre d’exprimer en une valeur dans l’intervalle [0,1] la capacité de chaque agent pour jouer les différents rôles. Nous commençons par exposer les différentes manières possibles pour construire une fonction d’appartenance à un ensemble flou puis nous finissons par présenter comment nous proposons la mesure floue des capacités des agents à jouer les rôles dans la section qui suit. 5.3.1 Construction des fonctions d’appartenance aux ensembles flous Dans la littérature, on se réfère le plus souvent à l’utilisation de fonctions d’appartenance sans fournir beaucoup d’explications sur les manières de leurs obtentions [3]. Nous allons présenter dans cette section les différentes méthodes de construction de fonctions d’appartenance catégorisées selon Aladenise et Bouchon-Meunier en quatre classes [3].
La première classe regroupe les méthodes automatiques qui manipulent des données numériques. Dans ces méthodes, l’obtention des fonctions d’appartenances se déroule en deux phases : la première phase consiste en la création d’une fonction primaire mal ajustée, alors que la deuxième concerne l’ajustement de cette dernière. Les méthodes automatiques de construction de fonction d’appartenance se basent sur différentes technique comme les réseaux de neurones, la classification, les stratégies d’évolution et les algorithmes génétiques. Par exemple, En génétique, une population initiale d’individus, décrits par des chromosomes, est soumise à des transformations tel que des mutations ou des croisements, les individus résultants étant les plus adapté à la survie. Par analogie, dans la méthode des algorithmes génétiques, on se donne une population de vecteurs ou d’éléments d’information 146
Une mesure floue multidimensionnelle des capacités des agents pour jouer des rôles.
appelés chromosomes qui correspondent à une solution au problème posé. C'est-à-dire, à la recherche d’une fonction d’appartenance. Chaque chromosome représente donc, sous forme codée, les paramètres permettant de définir une fonction d’appartenance. Cette population de départ est souvent aléatoire. On définit ensuite des transformations qui s’appliquent à la population de vecteurs. Les applications successives des trois opérations génétiques vont discriminer ou promouvoir certains chromosomes. La mutation de gènes favorise l’apparition de nouvelles propriétés ; l’élimination d’éléments les moins pertinents est effectués par la sélection ; la prédominance de certaines caractéristiques par rapport à d’autres est mise en valeur par recombinaisons successives. Le résultat de l’application de ces opérations est la mise en évidence de la meilleure solution possible au problème posé, donc de la fonction d’appartenance la plus pertinente. De la même famille que les algorithmes génétiques, les stratégies d’évolution [15] ont un fonctionnement analogue, à la différence près que le chromosome des algorithmes génétiques contient ses informations sous forme binaire, alors le vecteur d’information des stratégies d’évolution contient des réels. Le principal défaut de ces méthodes est que les fonctions de calcul ne sont n’est intuitives ni explicites via à vis de l’utilisateur. Par contre elles ont l’avantage d’être automatiques. Et également l’avantage de fonctionner à partir d’exemples qui ne sont pas nécessairement fournis par des experts. Elles ont aussi l’intérêt de manipuler directement des nombres alors que tout le problème de la construction des fonctions d’appartenance est la numérisation de concepts linguistiques. La deuxième classe des méthodes pour la construction de fonctions d’appartenance aux ensembles flous regroupe les méthodes qui ont un fondement statistique et qui partent du principe que, plus une représentation est approuvées par un grand nombre d’individus, plus elle est satisfaisante. Cette classe regroupe aussi les méthodes basées sur les observations de situations avec approche fréquentielle, ainsi que les méthodes qui se basent sur l’utilisation de densités de probabilité [3]. A titre d’exemple, nous citons la méthode statistique (oui-non). Un principe simple pour obtenir le degré d’appartenance d’un élément d’un ensemble de référence à un terme linguistique (modélisé par un ensemble flou) est la méthode appelée (oui-non). Elle consiste à interroger chaque membre d’une population avec une question qui n’autorise qu’une réponse binaire : oui ou non. Par exemple, lorsque l’ensemble de référence est celui des tailles, pour savoir si un homme de 1,72 m est (grand), la question pourra être formulée ainsi : (Est-il vrai qu’un homme d’ 1,72 m soit grand ?). Le degré d’appartenance de (1,72 m) à l’ensemble flou (grand) sera égal à la proportion de réponses (Oui) dans l’ensemble des réponses. Un autre exemple de méthode appartenant à cette classe est la méthode d’Ellen Hisdal [76]. Dans cette méthode, une première étape consiste à demander à l’expert, comme dans la méthode Oui-Non, de répondre par (Oui) ou (Non) à la question « Cet élément x de X appartient-il à A (sous-ensemble de X) ? ». On lui soumet différents éléments de X jusqu’à ce que l’on puisse obtenir une courbe non floue à seuil similaire à celle illustrée dans la figure 5.2. L’idée de Hisdal est qu’il probable que l’on se soit trompé sur le choix de l’élément frontière (1,70 m sur l’exemple), mais que plus on s‘ éloigne de cet élément frontière, plus la
147
Une mesure floue multidimensionnelle des capacités des agents pour jouer des rôles.
probabilité que l’on se soit trompé est faible. Cette probabilité de l’erreur est matérialisée par une courbe d’erreur E ( u), qui est une distribution de probabilité gaussienne figure 5.3.
μ(x)
1
X Valeur seuil
Figure 5.2 : Courbe à seuil.
Figure 5.3 : Probabilité d’erreur sur le choix de l’élément frontière dans la courbe à seuil.
Finalement, μ (x) est la fonction à seuil (arrondie) par la fonction d’erreur ; plus précisément, c’est la résultante de la convolution de la courbe à seuil avec la courbe de l’erreur estimée, ce qui donne la courbe indiquée dans la figure 5.4.
148
Une mesure floue multidimensionnelle des capacités des agents pour jouer des rôles.
Le choix de la forme gaussienne pour la fonction d’erreur n’est pas justifié. Le taux d’erreur pourrait tout aussi bien décroître linéairement au fur et à mesure que l’on s’éloigne de l’élément frontière, ce qui nous donnerait une fonction d’erreur triangulaire, et donc une fonction d’appartenance à pente linéaire. Il est à noter qu’il existe plusieurs autres méthodes appartenant à cette classe tel que la méthode statistique d’estimation d’ensemble [173], la méthode d’histogramme de fréquences normalisé [35] et la méthode des fonctions de densité de probabilités [39]. μ(x)
1
X Valeur seuil
Figure 5.4 : Fonction d’appartenance résultant de la méthode de Hisdal.
La troisième classe des méthodes regroupe les méthodes dites Méthode de psychométrie. Dans cette classe de méthodes, ce sont les différentes façons d’interroger directement un expert qui sont étudiées. Il s’agit de lui faire numériser un concept linguistique vague. La méthode la plus élémentaire consiste à interroger un expert de manière à lui faire définir le noyau (éléments de X pour lesquels l’appartenance à A est certaine) et le support (X privé des éléments dont la non appartenance à A est certaine) de la fonction d’appartenance de A. il suffit pour cela, de faire produire quatre paramètres à l’expert (p1 ,p2,p3 et p4). A l’aide de ces données, il est possible de construire une fonction de maximum 1 atteint sur [p2,p3] et de minimum 0 à l’extérieur de [p1, p4], la forme (linéaire, à base d’arcs de paraboles, … )de cette fonction étant choisie arbitrairement sur l’ensemble Supp(A)-Noy(A), non décroissante entre p1 et p2 , non croissante entre p3 et p4, (figure 5.5). Plusieurs méthodes appartenant à cette classe ont été proposées, et nous citons à titre d’exemples, la méthode de quantification structurelle [180], la méthode de Norwich et Turksen [122], la méthode de grille répertoire [25][72] et la méthode Alpha-sets [142] .
149
Une mesure floue multidimensionnelle des capacités des agents pour jouer des rôles.
P1
P2
P3
P4
Figure 5.5 : Exemple de fonction d’appartenance.
La dernière classe des méthodes pour la construction des fonctions d’appartenance aux ensembles flous regroupe les méthodes de construction par interpolation. Pour construire une fonction d’appartenance sur un ensemble de définition X continu, il est nécessaire de connaître un nombre raisonnable de points appartenant à cette fonction. Lorsque le nombre de points connus est petit, il est possible de construire une fonction par interpolation à partir de ces points, vérifiant néanmoins certaines contraintes pour que la courbe obtenue corresponde à une fonction d’appartenance correcte. Ces contraintes sont formalisées par Chen et Otto dans [38], où ils proposent une méthode de construction des fonctions d’appartenance les vérifiant. En faisant l’hypothèse qu’il existe au moins un point appartenant totalement au sous-ensemble flou et au moins un point n’y appartenant pas du tout, et que l’on est capable de les identifier. Les propriétés mathématiques auxquelles les fonctions d’appartenance : → [0,1]répondent sont : ( ) [0,1] ∀ ; est différentiable et finalement ( ) = pour un ensemble fini de couples {( , ), … , ( , )}. Cette méthode permet de construire une fonction d’appartenance à partir de quelques points seulement. La fonction construite est une fonction continue, convexe et avec une forme régulière. Les méthodes présentées dans cette section pour obtenir des fonctions d’appartenance aux ensembles flous sont relativement générales. Il existe bien d’autres méthodes pour construire des fonctions d’appartenance propres aux systèmes auxquels les fonctions appartiennent ou pour les domaines pour lesquels elles ont été conçues. C’est le cas de la méthode que nous proposons et présentons dans la section suivante pour établir une fonction d’appartenance des agents aux groupes flous d’agents de l’organisation proposée. 5.3.2 Fonctions d’appartenance aux F-groupes d’agents La mesure que nous proposons pour les capacités des agents pour jouer les rôles exprimées avec une fonction d’appartenance aux F- groups se fait à partir des indicateurs de capacité jugés pertinents spécifiés pour chaque rôle, traduisant chacun, un aspect particulier 150
Une mesure floue multidimensionnelle des capacités des agents pour jouer des rôles.
de la capacité. L’ensemble des indicateurs spécifiés pour un rôle doivent couvrir les volets fonctionnel, opérationnel et extra-fonctionnel. Les indicateurs de capacité qui couvrent le volet fonctionnel sont les indicateurs liés aux savoirs faire des agents dans le sens métier, les indicateurs de capacités opérationnelles couvrent les capacités de communication et de mobilité ainsi que les capacités en termes de perception de l’environnement ; les indicateurs de capacité qui couvrent le volet extra-fonctionnel sont des indicateurs qui sont en relation avec les facteurs qui peuvent influencer le fonctionnement des agents en jouant les rôles comme la quantité de mémoire disponible ou la quantité de l’énergie dans une batterie qui alimente un nœud d’exécution. À partir de ces indicateurs, il s’agit d’évaluer des degrés d’appartenance des agents aux F-Groups. Le problème est alors de choisir parmi les fonctions d’appartenance possibles [3] celle la plus indiquée pour chacun des indicateurs.
Comme il est précisé dans le chapitre précédant, pour chaque F-Group on associe une matrice de paramètres. C’est une collection de données dans laquelle le concepteur définit pour le rôle joué dans le F-Group l’ensemble de critères utilisés comme indicateurs de capacité, leurs degrés d’importance et les différentes modalités pour les indicateurs à valeurs discrètes, pour les indicateurs à valeurs continues on précise l’intervalle des valeurs admissibles. Pour un rôle donné ρ, Considérons le F-groupe de n agents
qui présente un ensemble composé
( = 1,2,3, … , ) souhaitant jouer le rôle ρ. Le sous-ensemble flou
agents capables de jouer le rôle ρ parmi les agents couples : ρ
Où,
ρ
=
,
ρ
( ) ,
∈
Avec
ρ
des
est défini comme l’ensemble des
ρ
( ) → [0,1]
( ) représente le degré d’appartenance de chaque agent
au sous-ensemble
flou des agents capables de jouer le rôle ρ.
Pour la détermination d’une fonction d’appartenance nous pouvons définir des fonctions qui dépendent des types des indicateurs de capacité que nous pouvons classer en indicateurs qualitatifs dichotomiques, indicateurs qualitatifs polytomiques et indicateurs quantitatifs continus. Les indicateurs qualitatifs dichotomiques sont les indicateurs à deux modalités seulement que nous pouvons qualifier aussi d’indicateurs binaires. Par exemple, si nous prenons la mobilité des agents comme indicateur de capacités, un agent peut être mobile ou ( = 1,2, … , ) et soient indicateurs non mobile. Considérons un ensemble de n d’agents de capacité dichotomiques avec ( = 1,2, … , ). La valeur dichotomique traduisant le statut de possession de capacité de l’agent par rapport à l’indicateur prend une valeur nulle quand l’agent ne possède pas la capacité exprimé par l’indicateur et une valeur égale à 1 dans le cas contraire. Dans ce cas, la fonction ρ ( ) exprimant le degré d’appartenance de
151
Une mesure floue multidimensionnelle des capacités des agents pour jouer des rôles.
au sous ensemble flou des agents capable de jouer le rôle ρ par rapport à
chaque agent l’indicateur
peut être exprimée comme: ρ
0
( )=
=0
1
=1
……….. (iv).
Nous pouvons remarquer que cette fonction est similaire aux fonctions d’appartenance aux ensembles classiques. Les indicateurs de capacité qualitatifs polytomiques sont représentables par des variables qualitatives a plus de deux modalités où chacune d’entre elles correspondant à un certain degré de possession de capacité. Par exemple si nous prenons la mobilité des agents comme indicateur de capacités avec la considération que la mobilité soit faible ou forte, cet indicateur peut prendre les modalités : non mobile, mobile avec mobilité faible et mobile avec mobilité forte. Pour définir la fonction d’appartenance, on peut ordonner les modalités selon un ordre croissant par rapport à la possession de capacités relatives au rôle ρ. Considérons le sous-ensemble
des agents se trouvant dans une situation de possession de capacité par
rapport à l’indicateur capacité ( )
=
pour ( )
,
( )
, Notons
chaque ,…,
( )
les
la variable polytomique permettant d’évaluer le degré de
agent
de
avec
=
(
modalités possibles pour la variable
,
,…
( )
aux différentes modalités ordonnées
<
soit préservée et que les différentes modalités
<
<⋯<
manière égale. Soient les deux scores
,
Notons
ordonnées de sorte à
exprimer un renforcement en termes de capacité par rapport à l’indicateur associer des scores
).
. Nous pouvons
de sorte que la relation sont espacées de
associés aux deux modalités où la
première repère une extrémité au dessous de laquelle il n y a aucune capacité ; la deuxième repère clairement une situation de capacité. Par la suite, une fonction d’appartenance peut être définie comme :
( ) =
⎧
0
⎨ ⎩1
− −
≤ ≥
<
<
……..( )
Nous pouvons remarquer qu’avec cette fonction on peut avoir des degrés d’appartenance au sous ensemble flou des agents capables de jouer le rôle ρ qui croissent à proportion de la proximité de la capacité. Pour les indicateurs de capacités à valeurs quantitatives continues, des difficultés supplémentaires sont à gérer. Il s’agit de la détermination d’un seuil de capacité selon lequel les agents peuvent être jugés. Il existe toujours une incertitude concernant ce seuil. Pour contourner cette incertitude nous pouvons retenir deux seuils : le premier noté ∁ 152
Une mesure floue multidimensionnelle des capacités des agents pour jouer des rôles.
correspond à la valeur en dessous de laquelle un agent peut être classé sans ambigüité non capable de jouer le rôle en question. Le deuxième seuil noté ∁ correspond à la valeur au dessus de laquelle un agent est considéré capable de jouer le rôle d’une manière sure. Entre les deux valeurs ∁ et ∁ la fonction d’appartenance produit des valeurs entre 0 et 1. Il est à noter que la plus grande difficulté réside dans la détermination des valeurs ∁ et ∁ d’une manière pertinente. Considérons le sous-ensemble des agents en situation de capacité
favorable par rapport à l’indicateur
et la variable continue
permettant
d’exprimer la possession de capacités par les agents. On peut formuler la fonction d’appartenance en supposant que la capacité d’un agent varie de façon linéaire entre ∁ et ∁ comme : 0
( ) =
0 ≤
1
≤
∁
≥ ∁
∁
≤
≤
∁
………….(vi)
Les fonctions d’appartenance (iv),(v) et (vi) proposées jusqu’ici, malgré qu’elles permettent d’exprimer des degrés d’appartenance aux sous ensembles flous reflétant les capacités des agents pour jouer différents rôles ; elles souffrent de deux inconvénients majeurs : le premier porte sur le caractère arbitraire dans l’établissement des seuils de capacité, le deuxième concerne l’appui sur l’hypothèse discutable de l’équidistance entre les modalités des différents indicateurs. Nous pouvons améliorer les fonctions d’appartenance par chercher des fonctions qui ne se basent pas sur la spécification des seuils de capacité et qui permettent de produire des degrés d’appartenance aux différents groupes d’agents qui dépendent des emplacements des capacités de ces derniers dans la distribution de chacun des indicateurs Soit
=
,
,…..,
la variable traduisant l’état de possession de capacités de n
agents en regard de l’indicateur , avec = 1,2, … . . . , . On peut définir une fonction d’appartenance selon que la possession de capacité augmente comme la fonction suivante : ρ
Où
( )=
(
)
représente la fonction de répartition de la variable
. Dans le cas où l’indicateur
est à valeurs discrètes, nous pouvons utiliser une version normalisée de la fonction Soient
( )
, avec
= 1, … ,
les différentes modalités de la variable , classée par
ordre croissant par rapport à la possession d’une capacité de sorte que minimum de capacité et
( )
.
( )
constitue le degré
le degré maximum de capacité associé à l’indicateur de
possession j. on peut définir la fonction d’appartenance comme suit :
153
Une mesure floue multidimensionnelle des capacités des agents pour jouer des rôles.
ρ
Où
( )=
ρ
β
ρ
(
)
(
β
)
0
( )
+
(
)
( )
β =β
( )
β =β
( )
,
>1
…… (vii)
Représente le degré d’appartenance d’un agent dont la variable β
prend la modalité (m-1). Les modalités de la variable β sont ordonnées selon un ordre croissant par rapport aux capacités des agents à l’égard de l’indicateur . La valeur retournée par
ρ
( ) exprime la capacité de l’agent
à l’égard d’un
indicateur . Or, la capacité de pour jouer le rôle doit être calculée par rapport à tous les indicateurs spécifiés pour le rôle. La capacité globale de l’agent est une accumulation de ses capacités par rapport à chacun des indicateurs. L’obtention de la capacité de l’agent pour jouer le rôle revient à réduire en une seule dimension les degrés d’appartenance obtenus selon les différents indicateurs. Il est possible de faire une agrégation par une fonction ℎ: [0,1] pour ≥ 2, tel que : ρ
( ) = ℎ(
ρ
( ),
ρ
( ), … ,
ρ
( ))
Où les Gj représentent les j sous-ensembles flous déterminés sur les j indicateurs de capacité spécifiés pour le rôle . Il existe plusieurs possibilités pour déterminer la fonction ℎ. Si nous prenons par exemple l’union des j sous ensembles flous, donc ℎ est définie comme la fonction maximum : ( ρ ( ), ρ ( ), … , ρ ( )). Dans ce cas un agent est
qualifié totalement capable pour jour le rôle dès qu’il manifeste une possession totale à l’égard d’au moins un indicateur de possession de capacité. Si nous prenons l’intersection des j sous ensemble flous ℎ sera définie comme la fonction minimum : ( ρ ( ), ρ ( ), … , ρ ( )). Dans ce cas un agent est considéré comme complètement capable de jouer un rôle que s’il est en position de possession absolue par rapport à tous les indicateurs. Il est clair que ces deux possibilités sont extrémistes et présentent des inconvénients. Par exemple, dans le cas de l’union, on juge de la même manière deux agents avec, pour l’un une possession de capacités par rapport un seul indicateur et pour l’autre, une possession par rapport à un ensemble d’indicateurs.
La capacité globale d’un agent pour jouer un rôle est considérée comme un cumul de possessions de capacités selon les indicateurs de capacités précisés pour le rôle à jouer. De ce fait, il faut chercher une formule permettant à la fonction ℎ de prendre des valeurs intermédiaires entre le minimum et le maximum. On peut utiliser la formule d’une moyenne généralisée des degrés d’appartenance :
154
Une mesure floue multidimensionnelle des capacités des agents pour jouer des rôles.
ρ
( )=ℎ
ρ
( ),
ρ
( ), … ,
ρ
( ) = ∑
(
ρ
( ))
, ≠ 0 ……(viii)
La possibilité d’utiliser une telle formule est justifiée par l’association de la fonction h à une structure axiomatique minimale vérifiant Les axiomes de monotonicité, de continuité et de symétrie. Le paramètre permet de déterminer le type de la moyenne. On obtient une moyenne géométrique dans le cas où =0, une moyenne harmonique lorsque =-1, et on obtient une moyenne arithmétique dans le cas où = 1. Les représentent les poids spécifiant l’importance relative à accorder pour chaque indicateur de capacité. Nous pouvons utiliser un =
système de pondération de la forme :
∑
ρ(
)
où
ρ(
)
ρ
( ) = 1−
ρ
( )
exprime
le degré de privation de capacité par rapport à l’indicateur . Le degré d’appartenance au sous-ensemble flou des agents capables de jouer un rôle est d’autant plus élevé que les capacités s’ajoutent les uns aux autres. Dès lors, le poids associé à deux indicateurs de capacités tel que la mobilité et utiliser KQML pour communiquer est supérieur au poids affecté à l’indicateur de mobilité seul. Le logarithme est utilisé dans le système de pondération des pour accorder un peu plus d’importance aux indicateurs de capacité traduisant des aspects de capacité moins fréquents. La fonction d’appartenance formulée dans (viii) permet d’exprimer les capacités des agents pour jouer le rôle à travers des calculs de cumuls de capacités par rapport à plusieurs indicateurs. Il faut noter qu’une telle manière de mesure pose un problème de la multicolinéarité des indicateurs ainsi que le risque de sur représentation d’une dimension particulière d’où un rééquilibrage de la pondération des indicateurs est nécessaire pour réduire les poids des indicateurs redondants. Considérons un F-groupe FGρ de n agents
; soit j indicateurs de capacité définis pour
le rôle ρ joué dans le F-groupe FGρ. Notons par
le degré d’appartenance au sous-ensemble
flou des agents capables de jouer ρ de l’agent i selon l’indicateur de capacité j . Si l’on prend en compte tous les aspects de la capacité, un agent i est caractérisé par un vecteur de j degrés d’appartenance , Les degrés d’appartenance au sous-ensemble flou des agents capables de jouer ρ de tous les agents selon chaque indicateur de capacité forment une matrice de la forme suivante : =
⋮
⋯ ⋱ ⋯
⋮
Considérons la proportion des agents ayant autant ou plus de capacité que l’agent sur chacun des indicateurs considérés pour un rôle donné. Pour construire la fonction d’appartenance au sous-ensemble flou des agents capable de jouer le rôle en question, il faut 155
Une mesure floue multidimensionnelle des capacités des agents pour jouer des rôles.
calculer une mesure d’appartenance intermédiaire au groupe des agents capables de jouer le rôle notée . Que nous pouvons calculer comme : =
(ln(1
1
))
0
0<
≤1
=0
Il suffit ensuite de centrer et de normer la mesure d’appartenance intermédiaire pour obtenir une fonction d’appartenance plus adaptée de la forme :
ρ
( )=
0
(
)
(
)
(
)
= 0.
> 0;
…….(ix).
5.4 Choix et définitions des indicateurs de capacités pour les rôles. Le choix des indicateurs de capacité à utiliser pour mesurer et analyser les capacités des différents agents pour jouer différents rôles est d’extrême importance. Les indicateurs de capacités choisis pour un rôle donné déterminent la qualité de la mesure des capacités des agents pour jouer ce rôle, comme ils influencent directement l’analyse des raisons de non capacité et par la suite ils ont des influences sur le processus d’adaptation des agents qui visent à améliorer leurs capacités pour jouer le rôle en question. Les indicateurs de capacité spécifiés pour un rôle donné ρ doivent couvrir tous, sinon, la majorité des aspects de capacités. Chaque indicateur représente un aspect particulier de capacité. Les différents indicateurs de capacité peuvent être regroupés en trois catégories : des indicateurs de capacité fonctionnels, des indicateurs de capacité opérationnels et des indicateurs de capacité de nature non fonctionnelle ou extra fonctionnelle. La première catégorie des indicateurs regroupe les aspects de capacité liés aux compétences fonctionnelles, c’est à dire, le savoir faire métier que les agents doivent avoir parmi leurs compétences pour qu’ils puissent jouer le rôle ρ. Par exemple, traitons le rôle ‘caissier ‘ dans un magasin. Imaginons que la caisse s’ouvre avec un code d’accès, pour qu’un agent puisse jouer le rôle caissier, ce dernier doit avoir des connaissances en comptabilité pour effectuer les comptes de la journée ; en d’autres termes il doit savoir ouvrir une caisse, encaisser, comptabiliser et calculer. Chacun de ces savoirs faire peut être utilisé comme indicateurs fonctionnels de capacité. Le concepteur doit définir pour chaque indicateur quelles sont les différentes modalités possibles ou les intervalles de valeurs dans le cas où l’indicateur est de nature numérique continue. Le concepteur doit aussi spécifier la manière selon laquelle le système calcule ou effectue la mesure de la valeur de l’indicateur pour un agent donné suivant sa position dans l’organisation. Finalement, le concepteur doit attribuer 156
Une mesure floue multidimensionnelle des capacités des agents pour jouer des rôles.
des degrés d’importance aux indicateurs d’une manière raisonnable et équilibrée puisque dans le cas d’accorder des degrés d’importances trop élevés pour certains indicateurs, ça peut se traduire pour certains agents en un cumul important de privations de capacités, ce que minimise leurs chances pour jouer certains rôles sans justifications acceptables. La table 4.1 présentée dans le chapitre précédent et la table 5.1 incluent un bon nombre d’exemples d’indicateurs de capacités qu’un concepteur peut spécifier pour un rôle donné. Signification Indicateur : mobilité ; Poids :
Modalités & valeurs
; nature : Discontinue. Cet indicateur exprime à quel point la mobilité Modalités= {1, 3, 6} de l’agent est nécessaire ou souhaitée pour Dans le cas où l’agent est non mobile la valeur 1 est attribuée pour cet jouer le rôle ρ. indicateur, le cas d’une mobilité faible l’indicateur prend la valeur 3. Pour les agents caractérisés par une mobilité forte l’indicateur prend la valeur 6. Selon cet indicateur de capacité les agents mobiles sont favorisés pour jouer le rôle ρ, et plus particulièrement ceux caractérisés par une mobilité f orte. Indicateur : Autonomie ; Poids : ; nature : Continue . Cet indicateur exprime à quel point Intervalle de valeurs= [0,1] l’autonomie de l’agent est nécessaire ou La valeur de cet indicateur est calculée comme la proportion du souhaitée pour jouer le rôle ρ. Cet indicateur est influencé par la manière de nombre de composants réellement contenus dans les contenir les composants dans les enveloppes- enveloppes composant par rapport au nombre total de composant (réelle ou virtuelle) est donc composants qui composent l’agent. l’agent a le contrôle entier sur son état interne.
Indicateur : CPU … Indicateur : Ressource X ; Poids :
; nature : Continue . Cet indicateur exprime la possession ou la Intervalle de valeurs= [0,1] privation d’un certain nombre d’unités d’une L’indicateur prend la valeur 0 dans le cas d’une privation totale de la ressource ressource X. Par exemples, des droits d’accès à X. il prend une valeur dans Intervalle de valeurs= [0,1] exprimant la proportion une base de données. du nombre d’unité possédées de la ressource X par rapport au nombre totale d’unité nécessaires.
…… …... Indicateur : Outils pour la communication ; Poids : ; nature : Continue . Cet indicateur exprime que pour jouer le rôle ρ, Modalités :{Oui, Non}
l’agent dispose de certains moyens pour communiquer avec les autres agents. c à d, l’agent doit avoir dans son enveloppe de communication des composants qui concrétisent ces moyens de communication. Par exemple, implémenter un langage de communication dans un ou plusieurs composants que l’agent doit avoir dans son enveloppe de communication. Indicateur : Possession d’un savoir faire X ; Poids : ; nature : Continue . Cet indicateur exprime à quel point l’agent Intervalle de valeurs= [0,1] possède un savoir faire X. C à d, à quel point les L’indicateur prend la valeur 0 dans le cas d’une privation totale du savoir faire composants de son enveloppe service X. il prend une valeur dans Intervalle de valeurs= [0,1] exprimant la proportion implémentent de fonctionnalités constituant du nombre de fonctions implémentés par les composants de l’enveloppe le savoir faire X. service de par rapport au nombre totale de fonctions demandées. Pour jouer un rôle donné, il se peut qu’un agent doit avoir plusieurs savoirs faire différents, on les sépare dans des indicateurs indépendants pour leurs attribuer des poids différents en accordance avec leurs
157
Une mesure floue multidimensionnelle des capacités des agents pour jouer des rôles.
importances et leurs impacts sur la capacité des agents.
Table 5.1 : Exemples d’indicateurs de capacités
5.5 Conclusion L’objectif de ce chapitre est de présenter comment mesurer les capacités des agents pour jouer les différents rôles dans l’organisation SMA proposée. Suite à une telle mesure, les agents de l’organisation seront autorisés ou non pour jouer les rôles. La mesure développée et détaillée le long de ce chapitre est une mesure floue multi dimensionnelle faisant référence à la théorie des ensembles flous. Le chapitre commence par présenter la théorie des ensembles flous dans l’optique de l’appliquer pour mesurer la capacité des agents constituant un SMA organisationnel pour jouer les rôles de l’organisation. La théorie des ensembles flous tel que exposée brièvement nous a permis de réaliser une mesure multi dimensionnelle de la capacité des agents dans laquelle sont combinées les compétences métier d’un agent (Savoir faire métier), ses compétences opérationnelles (communication, mobilité,…), les exigences de l’organisation (description des rôles) ainsi que les conditions générales dans les quelles fonctionnent les agents. La capacité d’un agent qui est traduite en un degré d’appartenance à un ensemble flou d’agents est une mesure décomposable faite selon des indicateurs de capacités. Cette décomposition de la mesure permet d’analyser les causes d’incapacités des agents et donc peut servir comme cadre pour diriger le processus d’adaptation des agents abordé dans le chapitre précédent. Ce chapitre avec celui qui précède, présentent et fournissent des descriptions suffisamment détaillées sur tout les éléments et concepts entrant dans la constitution et la formalisation de l’approche proposée dans laquelle on a combiner les composants logiciels avec les agents que ce soit mobiles ou non pour développer des applications distribuées, ouvertes et adaptables. Dans le chapitre qui suit, nous éprouverons la faisabilité et l’utilité de l’approche proposée à travers son application sur deux exemples de systèmes différents.
158
Chapitre VI Etudes de cas : Applications et évaluation
Etudes de cas : Applications et évaluation
Chapitre VI Etudes de cas : Applications et évaluation
6.1 Introduction Ce chapitre étant le dernier de ce manuscrit, il est consacré à l’évaluation de l’approche proposée dont les éléments et les arguments principaux sont présentés dans les chapitre IV et V. L’approche est évaluée à travers l’étude et la conception de deux applications différentes : une première application pour la mesure de qualité de service dans les réseaux informatiques et une deuxième application qui consiste en un système distribué de vente aux enchères et qui a fait l’objet d’une implémentation dans la plateforme multi agents MADKIT [53] sur laquelle on a effectué des expérimentations dont on a analysé les résultats. Ce chapitre est organisé en trois parties, une première pour la présentation, l’analyse et la modélisation d’une application pour la mesure de qualité de service dans les réseaux informatiques en appliquant l’approche proposée dans cette thèse. Dans la deuxième partie, nous présentons en plus de l’analyse et la modalisation, les aspects d’implémentation et les expérimentations opérées sur l’implémentation d’un système distribué de vente aux enchères. La troisième partie du chapitre est consacrée pour un bilan global résultant de l’analyse et la réflexion sur l’approche proposée en se basant sur les arguments et les motivations qui nous ont guidé lors du développement de l’approche, aussi, sur nos objectifs visés et en tenant compte des résultats expérimentaux obtenus à travers les expérimentations réalisées. 6.2 Premier exemple : Mesure de qualité de service dans un réseau Le développement d’une application pour la mesure de qualité de service dans un réseau informatique semble un exemple parfait pour mesurer les puissances et l’aptitude de toutes approches proposées pour le développement d’applications distribuées, ouvertes et adaptables. 160
Etudes de cas : Applications et évaluation
Particulièrement pour les réseaux caractérisés par : applications réparties à grande échelle, mobilité, autorités administratives multiples, évolutivité, variation de la qualité de services, besoins de robustesse et de personnalisation et d’auto adaptation à l’environnement d’exécution. Nous présentons dans ce que suit, un aperçu sur une modélisation selon l’approche proposée dans les chapitres IV et V d’une application pour la mesure de la qualité de service dans un réseau informatique. Une telle application est considérablement compliquée sur le plan conception qu’implémentation. Nous faisons abstraction à tous les détails relatifs aux mécanismes existants pour la mesure des qualités dans les réseaux informatiques et nous nous concentrons que sur les grandes lignes et d’une vue globale sur l’applicabilité de l’approche proposée pour concevoir une telle application. Avant de présenter la modélisation de l’application, il est question de faire une brève présentation de la qualité de service dans les réseaux informatiques et des techniques pour la mesure de cette dernière. 6.2.1 La qualité dans les réseaux informatiques L’utilisation des réseaux informatiques et surtout l’Internet a connu un développement géant. Dans les dernières années les applications étaient de types accès à distance, transfert de fichiers, courriers électroniques et autres types d’applications. Dans nos jours, De nouvelles applications, comme la visioconférence, le commerce électronique ou la téléphonie IP se développent à une grande vitesse. Nous pouvons constater que l’Internet est destiné à devenir l’infrastructure de communication globale universelle avec une tendance multiservices où il est intégré le transport de la voix, de la vidéo et des données sur la même infrastructure. Le dictionnaire Hachette définit la qualité d’une manière générale comme étant une « propriété suscitant un jugement favorable ou défavorable de quelque chose, ce qui détermine sa nature, ce qui le rend propre à tel ou tel usage ». Mais elle peut aussi être «un critère permettant de donner une échelle des valeurs dans une même gamme de produits ». Nous pouvons dire que la qualité regroupe quelques aspects de quelque chose qui font qu'elle correspond à ce que l'on attend. La qualité de service dans un réseau est le sujet de plusieurs définitions différentes. D’une manière générale, elle correspond à tous les mécanismes d’un réseau qui permettent de partager équitablement et selon les besoins requis des applications, toutes les ressources offertes, de manière à offrir, autant que possible, à chaque utilisateur la qualité dont il a besoin. Généralement, cette qualité est axée sur le débit, le délai et la perte des paquets. par exemples, la téléphonie par Internet a pour but de pouvoir converser en temps réel (facteur du délai) sans entre-coupures engendrées par des délais supplémentaires; télécharger une application volumineuse ne demande pas plus que de disposer d’une assez large bande passante pour récupérer le fichier le plus vite possible (facteur du débit) ; les deux applications demandent la réception de l’intégralité des paquets (facteur de pertes). La garantie de transmission est accentuée par la ‘mesurabilité’ qui consiste à pouvoir disposer de moyens permettant le contrôle des performances du réseau. La performance d’un 161
Etudes de cas : Applications et évaluation
réseau est évaluée selon le débit et délai de transmission, la largeur et la disponibilité de la bande passante offerte, le taux de pertes des paquets, etc.… Bien qu’il existe plusieurs paramètres qui entrent dans la mesure des performances des réseaux, on se contente pour des raisons de simplification que des trois paramètres : le débit, le délai et la perte des paquets. Pour réaliser la mesure des performances ou de la qualité d’un réseau, nous prenons une mesure active comme approche. Cette mesure implique l’utilisation d’un système de test pour la génération de trafic artificiel avec des propriétés contrôlées par rapport à la taille des paquets, à l’espacement entre paquets et au débit. Ce trafic est introduit dans les éléments réseaux sous test et, après sa réception au niveau du système de test, les paramètres débit, délai et la perte des paquets sont mesurés. Ces paramètres sont dans une relation à deux degrés de liberté, si l’un d’eux est fixé, une dépendance est créée entre les deux autres. 6.2.2 Conception d’un système simplifié pour la mesure de la qualité de service Lors de la conception d’un tel système, la première chose à faire est d’identifier les rôles à jouer, c'est-à-dire découper l’espace fonctionnel de l’application en termes de rôles à jouer par les agents. En se basant sur la définition de la qualité de service présentée ci-dessus on peut identifier quatre rôles à jouer : Le rôle Contrôle-Débit : joué par des agents qui se chargent de la mesure des débits point à point. La notion de bande passante d’un réseau intervient à ce niveau : un minimum de bande passante est requis pour assurer des garanties de qualité de service point à point, demandées à intervalles différents. La capacité d’un réseau doit être suffisamment importante pour pouvoir laisser passer de l’information sans pour autant qu’il y ait de retard d’acheminement. Pour la mesure de la bande passante, plusieurs mécanismes sont utilisables et le rôle peut être décrit de façon à contraindre le comportement des agents vers la mise en œuvre de ces mécanismes. Le rôle Contrôle-Délai : joué par des agents qui se chargent de la mesure des délais. Cette mesure englobe en réalité trois aspects temporels différents : Le délai de propagation déterminé par la distance physique qui sépare la source de la destination ; Le délai de transmission dépendant de la taille des flots qui est aussi étroitement lié à l’utilisation du réseau et au partage de la bande passante disponible ; et enfin, le délai d’attente et de traitement des paquets à l’intérieur des files d’attente déterminé par la charge du réseau, ainsi que les politiques de traitement de l’information dans les routeurs pour obtenir une fluidité maximale de l’écoulement de l’information. L’information qui circule à l’intérieur d’un réseau est hétérogène, tant sur l’aspect de son flux, de sa nature ou de sa fréquence. En effet, les utilisateurs du réseau manipulent aussi bien 162
Etudes de cas : Applications et évaluation
des applications de transfert de fichiers que des applications multimédia. Contrairement à une opération simple du type de transfert de fichier, le domaine du multimédia requiert beaucoup plus de garanties en matière de qualité de service temporelle. Plus particulièrement, ces dernières applications sont sensibles au délai et à la gigue (variation du délai), mais aussi aux pertes d’information. Ainsi, la téléphonie par Internet, la vidéoconférence, le multimédia interactif, etc.… requièrent de strictes garanties en délai, en gigue et en taux de pertes. Citons à titre d’exemple le cas des jeux interactifs multimédia : les paquets de ces applications, qui subiront un délai de transit significatif ne seront plus correctement utilisés et détérioreront l’efficacité et la synchronisation de l’application. Plusieurs mécanismes sont à la disposition pour effectuer des mesures sur les délais et le rôle peut être décrit de façon à contraindre le comportement des agents vers la mise en œuvre de ces mécanismes. Le rôle Contrôle-Perte-Paquets : joué par les agents qui se chargent de mesurer le taux d’erreur en termes d’arrivées de paquets à destination. Des taux d’erreurs affectent une bonne qualité de service en matière de disponibilité du réseau. On associe souvent le taux d’erreurs au paramètre temporel. Les erreurs affectant directement le transfert des flots, et retardant/bloquant ainsi leurs arrivées à destination. Les délais et les pertes sont les deux facteurs les plus connus qui nuisent aux garanties temporelles et qui engendrent l’amoindrissement des possibilités d’une application, voire rendent celle-ci totalement inefficace et inopérante. Le rôle Contrôle-Global : les agents qui jouent ce rôle sont chargés de synthétiser les informations leurs arrivants des agents qui jouent les trois rôles Contrôle-Débit, Contrôle-Délai, Contrôle-Perte-Paquets. Ainsi, une spécification des rôles à jouer dans une telle application pour la mesure de la qualité d’un réseau est de la forme : Roles= {( Contrôle-Débit ,DCcd, -), (Contrôle-Délai , DCcl, - ), (Contrôle-Perte-Paquets , DCcpp, -), (Contrôle-Global , DCcg, ((Contrôle-Débit, mesurer_débit ) ,( Contrôle-Délai, mesurer_délai ),( Contrôle-Perte-Paquets, calculer_taux_pertes )))}. Cette spécification dénote que quatre rôles sont à jouer dans l’application. Un rôle Contrôle-Débit dont DCcd présente la description comportementale. Les agents qui jouent ce rôle ne requirent aucun service fourni par les agents qui jouent les autres rôles ; Un rôle Contrôle-Délai et Un rôle Contrôle-Perte-Paquets dont les descriptions comportementales sont DCcl et DCcpp respectivement. Les agents qui sont amenés à jouer ces deux rôles n’ont pas besoin d’aucun service offert par d’autres agents ; et finalement, un rôle ContrôleGlobal dont DCcg est la description comportementale. Les agents qui jouent ce rôle requirent 163
Etudes de cas : Applications et évaluation
les services mesurer_débit, mesurer_délai et calculer_taux_pertes assurés par les agents qui jouent les rôles Contrôle-Débit, Contrôle-Délai et Contrôle-Perte-Paquets respectivement.
Conformément au modèle organisationnel proposé, ces rôles sont à jouer par les agents dans quatre groupes flous (F-Gcd, F-Gcl, F-Gcpp, F-Gcg ) caractérisés chacun par une matrice de paramètres et une fonction d’appartenance permettant la mesure des capacités des agents pour accomplir et rendre les services décrits aux niveaux des rôles. L’expression de la fonction d’appartenance se base sur la formule (IX) développée dans le chapitre V. Les agents mis en jeu pour jouer les rôles sont construits selon l’architecture présentée dans la section 4.3.3.1.2 à base de composants implémentant les compétences requises à la mise en œuvre des mécanismes utilisés pour l’effectuation des différentes mesures. L’intéressant dans cette approche, c’est que les agents qui jouent un même rôle n’ont pas forcement la même structure. C'est-à-dire ils incluent des composants différents qui implémentent différents mécanismes ou qui implémentent les mêmes mécanismes différemment. Cela permet l’utilisation simultanée de plusieurs mécanismes et techniques de mesure. La spécification des groupes flous est la suivante : F-Gcd= (F-Gcd, Contrôle-Débit , Contrôle-Débit Global }, normal,(2,10)). F-Gcl= (F-Gcl, Contrôle-Délai , Contrôle-Délai Global }, urgency,(2,10)).
supervisor,
,ƒm , MPcd , MPSUPcd, { Contrôle-
supervisor,
,ƒm , MPcl , MPSUPcl, { Contrôle-
F-Gcpp= (F-Gcpp, Contrôle-Perte-Paquets, Contrôle-Perte-Paquets supervisor, ,ƒm , MPcpp , MPSUPcpp, { Contrôle-Global, Contrôle-Délai, Contrôle-Perte-Paquets }, normal,(2,10)). F-Gcg= (F-Gcg, Contrôle-Global , Contrôle-Global Débit, }, normal,(2,10)).
supervisor,
,ƒm , MPcg , MPSUPcg, { Contrôle-
Les groupes flous qui constituent l’organisation à l’intérieur desquels les quatre rôles de service sont à jouer sont : F-Gcd, F-Gcl, F-Gcpp et F-Gcg. Dans F-Gcd le rôle ContrôleDébit est joué ; dans F-Gcl le rôle Contrôle-Délai est joué ; dans F-Gcpp le rôle ContrôlePerte-Paquets est joué et dans F-Gcg le rôle Contrôle-Global est joué. Les rôles ContrôleDébit supervisor , Contrôle-Délai supervisor , Contrôle-Perte-Paquets supervisor et le Contrôle-Global supervisor présentent les rôles de supervision des groupes flous F-Gcd, F-Gcl, F-Gcpp et F-Gcg respectivement. La même fonction d’appartenance ƒm est définie pour tous les groupes, elle sert pour mesurer les capacités des agents pour jouer les différents rôles services et même les rôles superviseurs. L’expression de la fonction ƒ m est identique à la formule (IX) développée dans le chapitre V. MPcd, MPcl, MPcpp et MPcg sont les matrices paramètres dans lesquelles sont définis les indicateurs de capacités utilisés pour la mesure des capacités des agents pour jouer les rôles services des F-groupes F-Gcd, F-Gcl, F-Gcpp et FGcg respectivement. MPSUPcd, MPSUPcl, MPSUPcpp et MPSUPcg sont les matrices paramètres dans lesquelles sont définis les indicateurs de capacités utilisés pour la mesure des 164
Etudes de cas : Applications et évaluation
capacités des agents pour jouer les rôles de supervision des F-groupes F-Gcd, F-Gcl, F-Gcpp et F-Gcg respectivement. Les agents qui jouent le rôle Contrôle-Débit sont autorisés à communiquer avec les agents qui jouent le rôle Contrôle-Global. Les agents qui jouent le rôle Contrôle-Délai sont autorisés à communiquer avec ceux qui jouent le rôle ContrôleGlobal. Les agents qui jouent le rôle Contrôle-Perte-Paquets sont autorisés à communiquer avec les agents qui jouent le rôle Contrôle-Global. Et inversement, les agents qui jouent le rôle Contrôle-Global sont autorisés à communiquer avec les agents qui jouent le rôle Contrôle-Débit, ceux qui jouent le rôle Contrôle-Délai et ceux qui jouent le rôle ContrôlePerte-Paquets. Une priorité normale est attribuée aux rôles Contrôle-Débit, Contrôle-PertePaquets et le rôle Contrôle-Global. Les agents qui jouent le rôle Contrôle-Débit doivent achever les activités relatives au rôle en urgence pour ne pas affecter les délais mesurés par des délais supplémentaires. Les paires de valeurs (2,10), (2,10), (2,10) et (2,10) présentent les cardinalités minimum et maximum (nombre) d’agents superviseurs pour les groupes flous F-Gcd, F-Gcl, F-Gcpp et F-Gcg respectivement. Plusieurs descriptions comportementales sont possibles pour décrire chacun des rôles Contrôle-Débit, Contrôle-Délai et Contrôle-Perte-Paquets. La description de chaque rôle est en fonction des mécanismes choisis ou proposés pour faire les mesures sur le débit, les délais et les taux de perte de paquets. Par exemple, pour les mesures relatives aux délais, nous distinguons deux types de délais : délai unidirectionnel et délai bidirectionnel. Le délai unidirectionnel est référé au temps d’aller-retour à cause de l’asymétrie qui peut exister dans les caractéristiques des routes aux niveaux de l’ordonnancement, de la fourniture de ressources et de la réservation. Il peut être défini comme la différence entre le temps de réception du dernier bit d’un paquet et le temps de transmission de son premier bit. Dans cette manière de mesure nous devons préciser depuis quelle limite supérieure de temps le paquet est considéré comme perdu. Le délai unidirectionnel peut être mesuré par l’intermédiaire des timbres-à-date (estampilles). Un délai moyen peut être calculé par les agents qui jouent le rôle Contrôle-Global en se basant sur les paramètres statistiques comme les centiles, la médiane, le minimum et le centile inverse. Ce délai moyen donne une indication sur le comportement du système. Le délai bidirectionnel peut être considéré comme l’écart entre le temps d’apparition du premier bit d’un paquet « requête » au transmetteur et le temps de réception du dernier bit du paquet « réponse » au transmetteur. Pour les mesures relatives aux pertes de paquets, La perte des paquets unidirectionnelle peut être définie comme nulle quand un paquet est reçu dans un délai unidirectionnel fini. Nous devons faire une distinction entre un paquet perdu et un délai large mais fini en choisissant un seuil raisonnable pour le délai unidirectionnel. Les paquets corrompus, même s’ils sont reçus, ou les paquets fragmentés pour lesquels l’assemblage n’a pas eu lieu sont considérés comme perdus. Cet exemple bien qu’il permet de démontrer la faisabilité, les performances et l’applicabilité de l’approche proposée dans des domaines et des applications de grande complexité ; la mise en œuvre effective d’une telle application est d’extrême difficulté vu les 165
Etudes de cas : Applications et évaluation
fortes contraintes imposées par les environnements d’exécution et les réseaux. En outre, la conception d’une telle application nécessite beaucoup d’analyses et d’études des mécanismes de mesures des qualités de services dans les réseaux. Pour cela, nous proposons dans la suite de ce chapitre, une deuxième étude de cas dont l’opérationnalisation est moins compliquée. 6.3 Deuxième exemple : Un système de ventes aux enchères Cet exemple a été déjà introduit dans le chapitre IV. De façon sommaire, un système de vente aux enchères impliques trois types d’acteurs : Des commissaires de ventes (Auctioneers) qui mettent des objets à vendre aux enchères ; des vendeurs (Sellers ) qui vendent les objets mis au enchères pour le compte des commissaires de ventes et finalement, des soumissionnaires (Bidders) qui font des soumissions pour acheter les objets mis à la vente aux enchères.
6.3.1 Présentation et modélisation Dans un tel système de vente aux enchères, trois rôles sont à jouer : le rôle Auctioneer joué par des agents qui mettent des objets à vendre ; le rôle Seller joué par les agents qui vendent les objets pour le compte des agents qui jouent le rôle Auctioneer ; et le rôle Bidder joué par des agents qui font des soumissions pour acheter les objets mis à la vente aux enchères. La spécification des rôles est la suivante : Roles= {(auctioneer,DC1,(seller, best_offer)), (Seller, DC2, - ), (Bidder, DC3, -)} Cette spécification dénote que trois rôles sont à jouer. Un rôle auctioneer dont DC1 présente la description comportementale. Les agents qui jouent ce rôle requirent le service best_offer fourni par les agents qui jouent le rôle seller ; Un rôle seller et Un rôle Bidder dont les descriptions sont DC2 et DC3 respectivement. Les agents qui jouent ces deux rôles n’ont pas besoin d’aucun service offert par d’autres agents. Conformément à l’approche proposée, les trois rôles sont à jouer par les agents dans les groupes flous F-G1, F-G2 et F-G3 schématisés dans la figure 6.1 et dont la spécification est de la forme :
F-G1= (F-G1, Auctioneer , Auctioneer supervisor, ,ƒm , MP1 , MPSUP1, { Seller }, normal,(1,5)). F-G2= (F-G2, seller, seller supervisor, ,ƒm , MP2 , MPSUP2, { Auctioneer , Bidder }, urgency,(2,10)). F-G3= (F-G3, Bidder, Bidder supervisor, ,ƒm , MP3 , MPSUP3, { seller}, normal,(2,10)).
Les groupes flous à l’intérieur desquels les trois rôles de service sont à jouer sont F-G1, F-G2 et F-G3. Dans F-G1 le rôle Auctioneer est joué ; dans F-G2 le rôle seller est joué et 166
Etudes de cas : Applications et évaluation
dans F-G3 le rôle Bidder est joué. Les rôles Auctioneer supervisor , seller supervisor et Bidder présentent les rôles de supervision des groupes flous F-G1, F-G2 et F-G3 supervisor respectivement. La même fonction d’appartenance ƒm est définie pour les trois groupes, elle sert pour mesurer les capacités des agents pour jouer les différents rôles services et même les rôles superviseurs. L’expression de la fonction ƒm est identique à la formule (IX) développée dans le chapitre V. MP1, MP2 et MP3 sont les matrices paramètres dans lesquelles sont définis les indicateurs de capacités utilisés pour la mesure des capacités des agents pour jouer les rôles services des F-groupes F-G1, F-G2 et F-G3 respectivement (on utilise la matrice représentée par la tables 4.1 figurant dans le chapitre IV pour les trois rôles sauf pour les indicateurs de savoirs faire ). MPSUP1, MPSUP2 et MPSUP3, sont les matrices paramètres dans lesquelles sont définis les indicateurs de capacités utilisés pour la mesure des capacités des agents pour jouer les rôles de supervision des F-groupes F-G1, F-G2 et F-G3 respectivement. Les agents qui jouent le rôle Auctioneer sont autorisés à communiquer avec les agents qui jouent le rôle seller. Les agents qui jouent le rôle seller sont autorisés à communiquer avec ceux qui jouent les rôles Auctioneer et Bidder. Les agents qui jouent le rôle Bidder sont autorisés à communiquer avec les agents qui jouent le rôle seller. Une priorité normale est attribuée aux rôles Auctioneer et seller. Les agents qui jouent le rôle Bidder doivent achever les activités relatives au rôle en urgence. (1,5), (2,10) et (2,10) présentent les cardinalités minimum et maximum (nombre) d’agents superviseurs pour les groupes flous F-G1, F-G2 et F-G3 respectivement.
Les rôles de supervision des groupes flous sont spécifiés de la même manière que les rôles services de l’organisation. Nous ne définissons pas un seul rôle de supervision pour les trois groupes, puisque il est possible que le concepteur propose des manières différentes pour la supervision de chaque groupe. D’où la spécification des rôles de supervision est la suivante :
Roles= {( Auctioneer supervisor,, DCSUP1,( Auctioneer, evaluate_indicator)), (seller supervisor,, DCSUP2, (seller, evaluate_indicator)), (Bidder supervisor, DCSUP3, (Bidder, evaluate_indicator))}
167
Etudes de cas : Applications et évaluation
Figure 6. 1: Vue d’ensemble d’un système de ventes aux enchères.
La spécification des rôles de supervision dénote la définition de trois rôles de supervisions à jouer. Le rôle Auctioneer supervisor dont DCSUP1 est la description. Les agents amenés à jouer ce rôle utilisent le service evaluate_indicator fourni par les agents qui jouent le rôle Auctioneer dont ils sont autorisés à communiquer avec. Le rôle seller supervisor dont DCSUP2 est la description. Les agents amenés à jouer ce rôle utilisent le service evaluate_indicator fourni par les agents qui jouent le rôle seller dont ils sont autorisés à communiquer avec. Le rôle Bidder supervisor dont DCSUP3 est la description. les agents amenés à jouer le rôle Bidder supervisor utilisent le service evaluate_indicator fourni par les agents qui jouent le rôle Bidder dont ils sont autorisés à communiquer avec.
La figure 6.3 illustre le contenu de la description DC1. Concernant les descriptions des rôles de supervision, les descriptions sont pratiquement les mêmes pour les trois rôles, la figure 6.2 illustre le contenu de la description DCSUP1.
168
Etudes de cas : Applications et évaluation
Part 1
Supervisor_of_Auctioneer_Group Administer_Joining_of_agents_to_Auctioneer_Group invite_agent invite agents to play the role Auctioneer and joining the f-groupe of Auctioneers update_list_of_acquaintance list.update update the list of agents that can play the role Auctioneer evaluate_membership_function agent.calculsIndicator In interaction with agents that wish to play the role Auctioneer,calculate the degree of membership Administer_Joining_of_agents_to_supervise_Auctioneer_Group invite_agent invite agents to play the role of supervisor of f-groupe of Auctioneer and joining supervisors FunctionDescriptor> measurement_of_capacity measure the capacity of an agent to play the role of supervisor of the f-group of auctionneer Part 2 :Dynamic behavior Protocol AuctionneerSupervisor{ Session with Auctionneer= +{ authorizing :![ float]; & { best_capable:? (float); end |notbest_capable; end } } Session with agents_wanting_to_play_the_role= +{ inviting :![ string, float]; & { capable:? (float); end |notcabale; end } } Session agents_wanting_or_invited_to_become_supervisor= +{register: &{ suprvise: ?(string, float); ![boolean]; supervising}} supervising = &{supervise: ?(string, float); ![boolean]; supervising || |capable: ?(string); Unregistering | youGotIt: ?( float); Unregistering } Unregistering = +{ unregister : end} }
Figure 6.2 : Contenu de la description DCSUP1 du rôle superviseur du groupe auctionneers
169
Etudes de cas : Applications et évaluation
Part 1
Auctioneer Sell_object contact_sellers client.setCourtier Selction_best_sellers_offer client.activate select the best offer among offers of different sellers contrat client.handleMessage validate the sale with the selected bidder
Part 2 :Dynamic behavior Protocol Auctionneer{ Session withSeller= +{ selling :![ string, float]; & { sold:? (float); end |notSold; end } } Session withABidder= +{register: &{ wannaBid: ?(string, float); ![boolean]; Bidding}} Bidding = &{wannaBid: ?(string, float); ![boolean]; Bidding || |itemSold: ?(string); Unregistering | youGotIt: ?(string, float); Unregistering } Unregistering = +{ unregister : end} }
Figure 6.3 : contenu de la description DC1 du rôle Auctionneer
6.3.2 Implémentation et expérimentations Le meilleur moyen pour construire un système multi-agent est d’utiliser une plate-forme multi-agents qui consiste en un ensemble d’outils nécessaire à la construction et à la mise en service d’agents au sein d’un environnement spécifique. Une plate forme SMA peut servir 170
Etudes de cas : Applications et évaluation
également à l’analyse et aux tests des systèmes ainsi créés. L’ensemble d’outils offerts par une plate forme peuvent être sous la forme d’environnement de programmation (API) et d’applications permettant d’aider et d’assister le développeur. Bien qu’il existe actuellement plusieurs plates-formes pour le développement des systèmes multi-agents, tel que JADE, ZEUS, Swarme ou Madkit. Il n’existe pas de plates formes qui supportent soit directement soit d’une manière indirecte les agents et les composants à la fois les uns avec les autres. Pour arriver à mettre en œuvre le système de ventes aux enchères décrit précédemment, nous somme dans l’obligation de choisir une plate forme multi agents et de simuler l’existence et la manipulation des composants. Le chois de la plate forme multi agents n’est pas arbitraire. Le chois d’une plate forme est piloté par deux critère principaux : il faut choisir une plate forme qui supporte et facilite la manipulation des concepts organisationnels de rôle et de groupe d’agents. En deuxième lieu, la plate forme ne doit pas exiger que l’utilisation des modèles d’agents prédéfinis de la plate forme, la plateforme doit permettre la définition et l’utilisation de nouveaux modèles d’agents. Ces deux critères nous ont conduits vers l’utilisation de la plate forme MadKit pour réaliser une implémentation adaptée du système de ventes aux enchères où les composants sont simulés et remplacés par des fichiers contenant leurs descriptions. Chaque composant est remplacé par un fichier de description dont le contenu est similaire au contenu illustré dans la figure 4.12. 6.3.2.1 La plate forme multi agents MadKit La plate forme MadKit [53](abréviation de Multi-Agents Développement Kit) a été conçue par Jacques Ferber, Olivier Gutknecht et Fabien Michel au laboratoire d’Informatique, de Robotique et de Microélectronique de Montpellier. C’est un ensemble de packages écrits en Java, qui implémentent le micro noyau agent. La plate forme MadKit est développée pour exploiter les avantages de la programmation Multi-Agents. Elle forme une plate forme générique de conception et d’exécution des Systèmes Multi-Agents qui se basent sur le modèle organisationnel Aalaadin plus connu sous le nom AGR[53] fondé Sur les concepts Agent-groupe-rôle. Dans le modèle organisationnel Aalaadin sous-jacent de MadKit, les agents d’un système sont regroupés au sein de groupes. Selon l’application à développer, un système Multi-agents peut inclure différents groupes et chaque agent peut appartenir au plus à un groupe et jouer différents rôles. Un rôle est une représentation abstraite d’une fonction, d’un service ou d’une identification d’un agent au sein d’un groupe donné. Un agent peut avoir plusieurs rôles au sein des différents groupes. Un rôle peut être tenu par plusieurs agents. MadKit n’est pas associée à quelques modèles spécifiques d’agents uniquement. Dans le cas où les modèles d’agents disponibles ne sont pas appropriés pour l’application à développer, il est toujours possible de créer et d’implémenter de nouveaux modèles d’agents en JAVA. Cette propriété fait de MadKit un outil très utile pour mettre en œuvre notre modèle spécifique d’agent. En outre, le modèle organisationnel sous-jacent à MadKit est basé sur les 171
Etudes de cas : Applications et évaluation
concepts organisationnels groupes et rôles. Particulièrement pour les rôles, MadKit supporte bien ces derniers d’une façon qui se rencontre bien avec notre vision pour le concept de rôles. Concernant les groupes d’agents, malgré que les groupes gérés dans MadKit ne sont pas flous, on a pu injecter cet aspect flous des groupes dans les spécifications des rôles superviseurs de groupes via la fonctionnalité d’évaluation des fonctions d’appartenance. D’autres raisons nous ont orientés vers le choix de la plateforme Madkit, On reconnait à MadKit les qualités suivantes [53]: Simplicité de mise en œuvre et de prise en main ; Intégration très facile de la distribution au sein d’un réseau ;
L’aspect pratique et efficace des concepts organisationnels pour créer différents types d’applications ; Hétérogénéité des applications et des types d’agents utilisables : on peut faire tourner sur MadKit aussi bien des applications utilisant des agents réactifs simples de type fourmis, que des applications disposant d’agents cognitifs sophistiqués. Le micro noyau de MadKit est un environnement d’exécution d’agents de tailles réduites, il assure la gestion de cycle de vie des agents dans laquelle le noyau Madkit gère le lancement et l’arrêt des agents en maintenant des tables de référence de tous les agents lancés, il s’agit d’assigner une adresse globale pour chaque agent, cette adresse est constituée de l’adresse de noyau et l’adresse de l’agent dans le noyau (l’AgentAddress). En plus de la gestion du cycle de vie des agents, Le passage de messages entre les agents est pris en charge par le micro noyau de MadKit qui doit aiguiller et distribuer les messages entre les agents locaux (exécutés sur un noyau). L’envoi d’un message est réalisé par la copie de ce dernier dans le tampon de l’agent récepteur. 6.3.2.1.1 Groupes et Rôles Sous MadKit Concernant la gestion des groupes et des rôles, Le micro noyau de MadKit fournit les opérations de base pour manipuler la structure organisationnelle Agent-Groupe-Rôle et de maintenir les informations de base correctes sur les agents de chaque groupe ainsi que leurs rôles attribués. Les opérations de base fournies par le noyau MadKit permettent la manipulation de l’appartenance des agents aux groupes ainsi que l’attribution des rôles aux agents. À titre d’illustration, dans le tableau 6.1 sont expliqués les rôles de quelques opérations de base.
172
Etudes de cas : Applications et évaluation
Opérations
Rôles
Remarques
createGroup(String nom_de_la_communauté ,String nom_du_groupe , null) ;
Création d’un groupe
Le paramètre null va recevoir le
requestRole(String nom_de_la_communauté,
Demande
String Nom_du_groupe, String Nom_du_role) ;
d’attribution de rôle
foundGroup(String Nom_du_Group) ;
Chercher un groupe
joinGroup(String Nom_du_Group) ;
Demande
nom d’un rôle plustard.
pour
Rejoindre un groupe
Un fois l’agent est admis dans le groupe il peut demander de jouer un
rôle
par
la
méthode
requestRole(String Nom_du_role) ;
Table 6.1 : Quelque opérations un micro noyau Madkit
6.3.2.1.2 Agent sous MadKit La classe de base d’un agent MadKit (AbstractAgent), définit quelques fonctionnalités de base pouvant être nécessaires dans les modèles classiques d’agents. Les fonctions associées à tout agent sont [53]: Cycle de vie : L’agent dispose de quatre états (création, activation, exécution, et destruction), il a la possibilité de démarrer d’autres agents sur le noyau local (et les désactiver par la suite). Par contre, aucun mécanisme concret d’exécution n’est défini à ce niveau. Communication : La communication est implémentée sous forme de passage de message asynchrone, soit d’agent à agent identifiés par leurs AgentAddress ou par leurs groupes et rôles, soit sous la forme d’une diffusion à tous les teneurs d’un rôle dans un groupe donné. Les messages sont définis par héritage à partir d’une classe de base qui ne définit que la notion d’émetteur et destinataires. Certain messages de base sont néanmoins fournis (encapsulation d’une chaîne ou d’un objet arbitraire, messages KQML et FIPAACL, messages XML), mais restent extensibles pour s’adapter à tout protocole d’interaction. Organisation : Tout agent dispose de primitives permettant d’observer son organisation locale (connaître les groupes et les rôles courants) et d’y agir (prise de rôle, entrée et retraits de groupes).
173
Etudes de cas : Applications et évaluation
Outils : La classe de base des agents permet également de manipuler une éventuelle interface graphique associée à l’agent, les flots d’entrée/sortie, etc. Threads et moteur synchrone : Pour faciliter les implémentations de modèles classique d’agents autonomes, cette classe de base est déclinée vers une implémentation associant un thread d’exécution à un agent. Néanmoins, pour certains types de systèmes, en particulier les SMA réactifs, il est nécessaire de gérer un grand nombre d’agents (jusqu’à des centaines de milliers) de granularité assez fine, et de contrôler leur ordonnancement. Cela est quasi-impossible si l’on se repose sur un mécanisme de thread à cause de la surcharge induite. Dans ce cas, on utilise ces agents “synchrones” via des agents externes qui vont définir leur politique d’exécution synchrone. Des agents d’observation peuvent être ajoutés pour avoir une vue globale sur certaines propriétés. 6.3.2.2 Aspects d’implémentations L’implémentation réalisée du système distribué de vente aux enchères est une implémentation adaptée. C'est-à-dire, il s’agit d’une implémentation faite sur mesure dont les objectifs sont : Simuler le mécanisme d’attribution de rôles aux agents basée sur la mesure floue proposée des capacités des agents pour jouer les rôles ainsi que l’appartenance partielle des agents aux groupes flous de l’organisation. Evaluer la performance du mécanisme de sélection de composants basé agents. Simuler les mécanismes d’adaptation des agents en simulant les mécanismes d’assemblage et de réassemblage de composants à l’intérieur des agents. L’implémentation consiste à créer trois groupes en utilisant la méthode createGroup(String nom_de_la_communauté ,String nom_du_groupe , null) du micro noyau Madkit (figure 6.4).
174
Etudes de cas : Applications et évaluation
Figure 6.4 : Utilisation de Madkit
Les groupes ainsi crées représente les trois groupe flous d’agents : le groupe flou des agents Auctioneers , le groupe flou des agents sellers et le groupe flou des agents Bidders. Dans MadKit les composants ne sont pas supportés comme étant des entités manipulables. Pour contourner ce problème, chaque composant est représenté par un fichier qui le remplace et qui contient une description dans laquelle sont définies les interfaces fournies et requises avec une description comportementale de chaque interface en utilisant le formalisme présentés dans la section 4.3.3.2.1 du quatrième chapitre. En plus de ces descriptions, le fichier contient les informations utilisables par le mécanisme de sélection des composants. La figure 4.12.présente un ensemble d’informations similaire à celui nécessaire pour les agents de sélection pour effectuer les choix de composants. Les agents de l’organisation sont créés sur le corps d’une classe qui hérite de la classe Agent qui est à son tour une sous classe de la classe AbstractAgent du MadKit, cette dernière définie les méthodes de bases que les agents possèdent. Les enveloppent logicielles des agents sont représenter par des structures de données dont les constituantes sont aussi des structures qui représentent les enveloppes composants. La structure qui représente une enveloppe composants incorpore plusieurs champs qui représentent les interfaces et leurs types aux quels sont assignés les noms et les types des interfaces des composants à contenir pour simuler les assemblages et les réassemblages de composants à l’intérieur des enveloppes logicielles des agents de l’organisation. Concernant les agents sélecteurs, ces derniers sont des agents réactifs simples de type fourmis, ils ne sont pas construits selon l’architecture proposée pour les agents de l’organisation. Les agents sélecteurs sont amenés à communiquer avec les agents de l’organisation. C'est-à-dire, communiquer avec les agents qui jouent les rôles services de l’organisation (Auctioneers, Sellers , Bidders). MadKit n’autorisent pas la communication 175
Etudes de cas : Applications et évaluation
entre les agents que si ces derniers appartiennent au même groupes. Pour cette raison les agents sélecteurs ne forme pas un groupe indépendant, ils appartiènnent aux groupes où sont joués les rôles Auctioneer, Seller , et Bidders . Pour illustrer le déroulement de quelques activités dans le système, examinant le scenario suivant : Si un agent A appartenant au f-groupe F-G3 désire jouer le rôle service (le rôle Bidder), l’agent A envoi un message à l’un des agents superviseurs du f-groupe F-G3. Ce dernier à l’aide de la méthode MadKit protected void handleMessage (ACLMessage m) traite le message et procède à extraire la liste des indicateurs de capacités depuis la matrice de paramètres implémentée sous forme d’un agent. A chaque demande d’attribution du rôle service, les agents superviseurs réextrairont la liste des indicateurs puisque la matrice de paramètres peut être sujette à des mises à jour à n’importe quel moment. Selon une manière interactive similaire à celle présentée dans le diagramme illustré dans la figure 4.7, l’agent A calcule les valeurs reflétant sa capacité à l’égard de chaque indicateurs. Une fois tous les indicateurs calculés, après avoir évaluer la fonction d’appartenance au F-groupe, l’agent superviseur détient le degré de capacité de l’agent A pour jouer le rôle Bidder. La fonction d’appartenance est implémentée comme une méthode Java dans laquelle la formule (ix) développée dans le chapitre V est utilisée. Les agents superviseurs du groupe F-G3 partagent les informations concernant les identités et les degrés d’appartenance des agents du F-G3. Les agents superviseurs du groupe F-G3 donnent une autorisation de jouer le rôle Bidder pour l’agent A en dépendance avec son degré d’appartenance exprimant son degré de capacité et son rang parmi les agents du même F-groupe désirant jouer le rôle. Dans le cas où l’agent A n’est pas autorisé pour jouer le rôle Bidder, il doit améliorer ses capacités par l’effectuation de réassemblages adéquats de composants s’il désire toujours jouer le rôle. La figure 6.5 présente une capture écran de l’application développé dans laquelle apparaissent plusieurs agents du groupe des Bidders désirant jouer le rôle. Les agents avec une barre de statu rouge prouvent de bonnes capacités envers le rôle Bidder.
176
Etudes de cas : Applications et évaluation
Figure 6.5 : Une capture écran du système de ventes aux enchères
A partir de quelques expérimentations, on a observé que les degrés d’appartenance des agents aux F-groupes augmentent et diminuent en accordance avec les compositions internes des agents et les descriptions des rôles. On a conduit une étude pratique dans laquelle plusieurs agents Ai sont impliqués. Chaque agent effectue plusieurs réassemblages de composants dans ces enveloppes logicielles. Périodiquement, suivant une période T chaque agent réalise un seul réassemblage. Après chaque période T, les degrés d’appartenance des agents sont capturés. Ainsi, les agents superviseurs peuvent établir un ordre de préférences sur les agents en fonction de leurs degrés d’appartenance. Pour mieux clarifier la situation, examinant le tableau 6.2 qui contient les degrés d’appartenance de 8 agents du groupe F-G3 dans des instants ti après chaque découlement de la période T. Nous faisons l’hypothèse que seuls 3 agents au maximum sont autorisés pour jouer le rôle Bidder à la fois. Instants t1 t2 t3 t4 t5 … ti
A1
A2
A3
A4
A5
A6
A7
A8
0,77 0,77 0,77
0,32 0,32 0,32
0,44 0,60 0,79
0,65 0,65 0,65
0,87 0,87 0,87
0,56 0,56 0,58
0,73 0,73 0,73
0,46 0,46 0,46
0,90
0,32
0,79
0,65
0,87
0,60
0,73
0,56
Tableau 6.2 : Quelques mesures expérimentales
Nous remarquons qu’à l’instant t1 et l’instant t2, les agents A1 ,A5 et A7 détiennent les meilleures capacités à l’égard du rôle Bidder. Par conséquence, A1 ,A5 et A7 seront autorisés pour jouer le rôle. À l’instant t3, l’agent A3 prouve des capacités meilleures que celles de 177
Etudes de cas : Applications et évaluation
l’agent A1. De ce fait, il sera autorisé pour jouer le rôle à la place de l’agent A1 dont l’autorisation pour jouer le rôle n’est plus valide. Si l’agent A1 désire encore jouer le rôle Bidder, il est dans l’obligation d’améliorer ces capacités à l’égard du rôle Bidder en réalisant un réassemblage de composants adéquat et tenter une nouvelle demande au prochain cycle. De cette manière, à fur et à mesure que le système progresse dans l’exécution, il converge vers un état où les meilleurs agents sont amenés à jouer les rôles. 6.4 Bilan
L’approche que nous avons proposée pour développer des applications distribuées, ouverte et adaptable est au centre des travaux constituant la thèse défendue dans ce manuscrit. Dans cette approche, nous avons cherché une combinaison entre les composants logiciels et les agents. Les agents peuvent être des agents mobiles ou des agents non mobiles vu qu’on a traité la mobilité des agents comme une simple propriété tout comme l’autonomie ou la flexibilité. Dans la littérature, il existe plusieurs travaux où les composants et les agents sont combinés selon une très grande diversité de manières que nous avons déjà présentées dans le chapitre III. De façon sommaire, les composants sont utilisés pour construire des agents ; les agents sont utilisés pour la sélection et la recherche des composants ou pour assister un assemblage de composant à travers les techniques de négociation entre les agents. Les agents sont aussi utilisés pour la reconfiguration dynamique des applications à base de composant ainsi que d’autres formes possibles de combinaison entre les deux concepts. L’approche que nous avons proposée consiste à utiliser des composants logiciels pour construire des agents dans le cadre d’une organisation SMA basée sur le concept de rôle joué par les agents dans des groupes flous d’agents où les agents appartiennent partiellement aux groupes selon des degrés d’appartenance exprimant leurs capacité pour jouer les rôles. La force de l’approche proposée se nourri d’un côté des points forts de chacun des concepts : composant, agent, rôle et organisation. De l’autre côté, la force de l’approche provient de la manière selon laquelle ces concepts sont combinés. Nous discutons dans les paragraphes suivants les apports et les points forts caractérisant notre approche de développent d’applications distribuées, ouvertes et adaptables en se basant sur une analyse de l’approche et sur les expérimentations pratiques sur l’implémentation réalisée du système de ventes aux enchères. L’utilisation des composants pour construire des agents offre les mêmes avantages que l’utilisation des composants pour développer tout système logiciel d’une manière générale. Particulièrement la structuration, la grande mise en valeur d’une réutilisation effective ainsi que les importantes possibilités d’adaptation de la structure et du comportement des agents à travers les possibilités d’assemblages et de reconfigurations dynamiques des composants. La réutilisation des composants lors du développement des agents porte deux avantages majeurs. En premier, la réutilisation a des impacts positifs sur la réduction des coûts de développement 178
Etudes de cas : Applications et évaluation
des agents. En second, à force de réutiliser des composants, ces derniers seront testés plusieurs fois dans plusieurs contextes, ce que augmente très probablement la qualité des composants et donc par conséquence augmente la qualité des agents construits à base de ces composants. L’utilisation des composants logiciels comme unités de base pour la construction d’agent permet d’avoir dans un même système des agents de granularités différentes. C’est-àdire, on peut avoir des agents incorporant un nombre important de composants, d’autres sont plus léger et incorpore moins de composants, ce que les rend mieux adaptés pour la mobilité. Le fait que l’architecture proposée des agents est à base de composants, les agents sont adaptables non seulement sur le niveau structure mais aussi sur le niveau comportement. En intégrant de nouveaux composants, l’agent acquit du savoir faire lui permettant de changer de comportement sur le plan service métier, manières de communication, gestion de la mobilité et sur le plan de perception de son environnement. Il est possible d’ajouter à n’importe quel moment de nouveaux composants dans les différentes bibliothèques de composants du système. Ainsi, de nouvelles compétences peuvent être mises à la disposition des agents et donc le système entier. Les composants ajoutés peuvent contenir par exemple des améliorations sur le plan performance de quelques compétences implémentées dans les composants qui existent dans les bibliothèques de composants. Les composants logiciels permettent d’améliorer le couplage structurel entre différentes entités constituant un agent par l’externalisation des interfaces des composants et leurs descriptions explicites sous formes d’interfaces requises et interfaces fournies. Cette externalisation des interfaces a permis de manipuler explicitement le couplage entre les composants indépendamment de ces derniers. La vision architecturale explicite apportée par les composants représente une avancée pour l’abstraction du couplage entre différentes entités constituant un agent du fait que l’accent est mis sur la logique du couplage entre les composants sans se soucier de leurs implémentations internes. De l’autre côté, le fait que l’approche est orientée agent est SMA, elle hérite naturellement les caractéristiques de ces derniers en bénéficiant ainsi des apports importants des agents et des SMA notamment : les niveaux d’abstractions élevés, les couplages flexibles entre agents, la manipulation et l’échange de connaissances et de concepts de haut niveau d’abstraction, la mobilité et les supports offerts pour la gestion de la distribution, l’hétérogénéité et l’adaptation. La considération d’un point de vue social pour la conception des systèmes multi agents pousse encore très loin le niveau d’abstraction. Cette conception dirigée par l’organisation rend tardives les questions d’implémentation et permet d’introduire des concepts de niveaux d’abstraction plus élevés encore comme les rôles, les groupes d’agents et les mécanismes de réorganisation. En plus des composants et des agents, l’approche proposée repose sur le concept de rôles. Cela a ses impacts intéressants. L’abstraction des agents vers des rôles permet une description générique de l’architecture de l’application à développer ainsi qu’une description générique des relations et des interactions entre les agents. En jouant un rôle les agents référencent tous 179
Etudes de cas : Applications et évaluation
les autres agents jouant le même rôle ou les rôles dont le concepteur a autorisé la communication avec au moment de l’interaction. De cette manière, le couplage structurel est externe avec un degré supplémentaire d’implicite par rapport aux connections entre les composants. Cette propriété qui permet à un agent de sélectionner sont interlocuteur de manière indirecte et implicite est particulièrement intéressante pour le développement d’applications ouvertes où des agents peuvent à tout moment rejoindre ou quitter l’application. D’un autre côté, l’utilisation des rôles pour le partitionnement de l’espace fonctionnel d’une application enrichit les possibilités d’adaptation de cette dernière. Dans un sens, il devient possible d’ajouter, de retirer des rôles dynamiquement ou de modifier la description et les propriétés de certains rôles pour des fins d’adaptation. Dans un autre sens, à travers l’attribution dynamique des rôles aux agents d’autres alternatives d’adaptation sont possibles. La mesure floue multidimensionnelle que nous avons proposée pour mesurer la capacité des agents pour jouer les rôles dans l’organisation présente une solution intéressante pour la formulation du problème de la conformité des agents avec les rôles. La mesure proposée se base sur des indicateurs de capacité où chaque indicateur reflète un aspect particulier de capacité. Trois catégories d’indicateurs de capacités sont à distinguer : des indicateurs de capacité fonctionnelle comme les savoirs faire dans le sens métier ou service ; des indicateurs de capacité opérationnelle comme la possession de mécanismes particuliers de communication ou de mobilité ; et des indicateurs de capacité non fonctionnelle comme la quantité d’énergie disponible sur une batterie dans le cas d’un agent qui s’exécute sur une machine dont la source d’énergie est une batterie. Cette mesure de capacité permet au système d’obtenir d’une manière souple un ordre de préférence entre les agents via à vis chaque rôle. Par conséquence, les rôles sont joués que par les agents armés des meilleures capacités. En outre, la capacité d’un agent pour jouer un rôle qui est traduit en un degré d’appartenance à un ensemble flou d’agents est une mesure décomposable faite selon plusieurs indicateurs de capacités. Cette décomposition de la mesure permet d’analyser les causes d’incapacités des agents et donc peut servir comme cadre pour diriger le processus d’adaptation des agents. La distance proposée de sous typage entre les comportements des agents et les comportements définis aux niveaux des rôles et que nous utilisons parmi les indicateurs de capacités spécifiés pour la mesure de capacités des agents selon un certain degré d’importance dirige l’opération de sélection des agents vers le choix des agents qui implémentent le comportement le plus proche de celui décrit au niveau du rôle. En d’autres termes, la sélection favorise les agents qui n’incluent pas considérablement du code inutile pour reproduire un comportement similaire à celui défini au niveau du rôle. Cette propriété est intéressante pour les agents mobiles qui doivent être allégés au maximum. C'est-à-dire, ces agent doivent contenir le strict minimum du code nécessaire pour la reproduction du code cible. 180
Etudes de cas : Applications et évaluation
Dans notre approche, l’adaptation est supportée à deux niveaux. Au niveau des agents et au niveau de l’organisation. Concernant le premier niveau, les agents sont adaptés par réassemblage automatiques adéquats des composants qui constituent les différentes enveloppes logicielles de l’agent permettant à ce dernier d’acquérir de nouvelles capacités et de rendre son comportement plus conforme avec la position qu’il veut occuper dans l’organisation. Par le terme position nous référençons : jouer un rôle. Le mécanisme intelligent de sélection de composants offert par cette approche assure aux agents le choix des composants les plus adaptés et les plus performants parmi les composants disponibles. Ainsi, les agents seront mieux adaptés après chaque réassemblage effectué. La séparation entre les différents types de capacités dans quartes enveloppes indépendantes à l’intérieur de l’agent (service, communication, perception de l’environnement et navigation) permet d’adapter chaque type de capacité séparément sans affecter les autres enveloppes. Au niveau de l’organisation, les agents ne sont pas attachés aux rôles d’une manière statique. Les rôles sont attribués aux agents dynamiquement dans un système de concurrence entre les agents qui provoque des adaptations aux niveaux des agents a fin d’occuper les positions qu’ils veulent occuper dans l’organisation. Les deux niveaux sont complémentaires et ont des influences mutuelles. Ensemble, les deux niveaux permettent d’assurer que dans chaque situation sont impliqués les meilleurs agents qui conviennent. 6.5 Conclusion Ce chapitre étant le dernier de ce manuscrit, il inclut principalement deux parties. Dans la première partie on a présenté deux études de cas différentes. La première consiste en une modélisation d’un système multi agents pour la mesure de la qualité du service dans un réseau. la seconde étude de cas consiste en une modélisation d’un système distribué de ventes aux enchères pour lequel on a réalisée une implémentation sous la plateforme Madkit qui semble la mieux adaptée parmi les plateformes multi-agent pour supporter les concepts organisationnels du model proposé. L’implémentation réalisé est une implémentation adaptée a cause des contraintes imposées par la plateforme soit par manque de support soit par la manière exigée par la plateforme en supportant les concepts organisationnels manipulés. La seconde partie du chapitre est un bilan dans lequel l’approche proposée est mise en valeur. Le bilan est fait par rapport aux objectifs visés en se basant sur des réflexions pour les apports des concepts misent en jeux, la manière dont les concepts mis en jeu sont combinés et finalement sur les résultats des expérimentations conduites sur l’implémentation réalisée du système de vente aux enchères.
181
Conclusion générale Dans le cadre de cette thèse, nous nous sommes intéressés au développement d’applications distribuées, ouvertes, et adaptables. Les propriétés de distribution, d’ouverture et d’adaptabilité s’imposent comme caractéristiques indispensables dans les applications informatiques de nos jours pour plusieurs raisons : la grande propagation de l’internet et des technologies Web ; la présence de processeurs et de moyens de traitement d’informations dans la majorité des équipements qui nous entourent ; ces équipements sont dotés de plus en plus de moyens de communications ; et du fait que les applications sont à exécuter dans des environnements différents et qui ne cessent de changer constamment. L’approche proposée pour développer de telles applications mobilise deux technologies différentes ayant chacune de son côté et sur des niveaux différents, des empruntes, des apports, et des impacts importants sur le développement de logiciel. L’approche présentée dans ce manuscrit s’inscrit dans un courant de travaux visant la recherche pour une combinaison entre les deux technologies mobilisées. C'est-à-dire, la recherche d’une combinaison dans laquelle nous impliquant le plus efficacement possible, les approches de développement par composants et celles qui s’appuient sur les agents. La combinaison cherchée devrait d’un côté fournir des éléments de solutions pour répondre aux exigences et aux caractères spécifiques imposés par les propriétés de distribution, d’ouverture et d’adaptabilité. D’un autre côté, la combinaison cherchée entre composants et agents devrait permettre de maximiser les gains que nous pouvons obtenir par l’utilisation des deux approches et de tirer profit de toute la puissance des deux paradigmes à la fois sur tous les plans couvrant le cycle de vie d’un logiciel depuis son développement jusqu’à son exploitation et sa maintenance. Dans ce travail, on a étudié chacune des deux approches – composants et agents séparément l’une de l’autre. Suite à ces études, on a conduit une analyse comparative entre les approches à base de composants et celles basées agents dans laquelle on a met l’accent sur les apports importants de chaque approche dans un cadre d’analyse repéré par deux axes ; le premier axe représente les niveaux d’abstraction alors que le second représente le couplage entre différentes entités constituant une application. La projection sur la dimension du niveau d’abstraction reflète le besoin progressif d’abstraction qui n’a pas cessé d’augmenter. Ce besoin est témoigné par l’évolution de la programmation et du développement du logiciel allant des procédures et des structures de données, passant par les objets, les acteurs, les composants, les services, les modèles, les ontologies, les agents, les connaissances jusqu’à l’arrivée aux organisations et aux sociétés artificielles. Le deuxième axe du repère d’analyse représente les aspects liés aux liaisons entre différentes entités logicielles mises en jeu. Cette dimension reflète le besoin croissant en matière de description des liaisons et des relations indépendamment des entités qu’elles relient ; elle exprime également la flexibilité des couplages signifiant la capacité de mettre des relations entre différentes entités logicielles et finalement, elle traite le besoin de repousser le plus tard possible la décision de choisir l’action à exécuter et le choix l’entité responsable de son exécution. Après avoir achevé 182
l’analyse comparative qu’on vient de décrire, on a pu mettre en clair les empruntes de chacune des deux approches ce que nous a permis de faire une analyse sur les apports mutuels des composants et des agents ainsi qu’une réflexion sur les possibilités de combinaisons et les fertilités croisées des deux approches. Suite à ces études et analyses avec l’étude des travaux existants dans les quels les deux approches ont été combinées et utilisées conjointement on, a pu tenir les points suivants :
Les agents et les systèmes multi agents présentent des avancés technologiques par rapport aux composants notamment sur le plan d’abstraction et de flexibilité de couplage, la manipulation et l’échange de connaissances et de concepts de haut niveau d’abstraction, la mobilité et les supports offerts pour la gestion de la distribution, l’hétérogénéité et l’adaptation.
La considération d’un point de vue social pour la conception des systèmes multi agents pousse encore très loin le niveau d’abstraction. La conception dirigée par l’organisation rend tardives les questions d’implémentation et permet d’introduire des concepts de niveaux d’abstraction plus élevés encore comme les rôles, les groupes d’agents et les mécanismes de réorganisation.
En plus d’être un cadre d’analyse et de conception des systèmes multi agents, l’organisation peut servir comme un support très puissant pour l’adaptation de ces derniers. C'est-à-dire, développer des SMA adaptables revient à développer des SMA selon des organisations évolutives qui s’auto organisent où dotées de mécanismes de réorganisations. La mobilité des agents de son côté peut servir aussi comme solution pour l’adaptation des applications, notamment les adaptations avec lesquelles les applications visent des réactions de types équilibrations de charges, minimisation de coûts de communications,…etc.
L’introduction du concept de rôles a poussé encore plus loin l’abstraction. L’abstraction des agents vers des rôles permet une description générique de l’architecture de l’application à développer ainsi qu’une description générique des relations et des interactions entre les agents. en outre, le concept de rôle a permet aussi d’introduire des mécanismes d’adaptation dans les systèmes multi agents en permettant l’attribution dynamique des rôles aux agents.
Plusieurs approches à base de composants témoignent une grande maturité des composants en termes de structuration, d’une grande mise en valeur de la réutilisation ainsi que les importantes possibilités d’adaptation de la structure et du comportement des applications à base de composants à travers les possibilités d’assemblages automatiques et de reconfigurations dynamiques des composants. La réutilisation des composants offre deux avantages majeurs. En premier, la réutilisation a des impacts positifs sur la réduction des coûts de développement. En second, à force de réutiliser des composants, ces derniers seront testés plusieurs fois dans plusieurs contextes, ce que augmente très 183
probablement leurs qualités et donc par conséquence augmenter la qualité des applications construits à base de ces composants.
On a remarqué qu’aucune des approches de développement dans lesquelles les composants et les agents sont combinés et utilisés conjointement n’a exploité la dimension sociale organisationnelle des SMA malgré les solutions importantes apportées par cette dernière.
En tenant compte de points cités ci-dessus, dans l’approche proposée les agents et les composants logiciels sont utilisés conjointement dans une perspective de recherche d’une combinaison entre les deux paradigmes dans laquelle nous pouvons tirer profit de tous les points forts de chacun des paradigmes en exploitant toutes les puissances des deux paradigmes en termes de structuration, réutilisations, possibilités d’adaptation, supports pour la gestion de l’ouverture, supports pour la distribution, les niveaux élevés d’abstraction et la flexibilité du couplage qu’offre chacun des paradigmes. L’approche proposée consiste à utiliser les composants logiciels pour construire des agents auto adaptatifs par réassemblages automatiques de composants. Les agents ainsi construits forment une organisation flexible et adaptable partitionnée en ensembles flous d’agents dans lesquels les agents jouent des rôles selon leurs capacités. Les capacités des agents sont estimées selon une mesure floue multidimensionnelle en dépendance avec l’ensemble de composants entrant dans la construction de chaque agent. La capacité d’un agent qui exprime son degré d’appartenance à un ensemble flou peut se définir par référence à un seuil. Si un système composé d’agents se trouve devant une situation où il doit autoriser des agents à jouer un rôle et interdire d’autres agents pour le faire, il s’agit de partitionner les agents en deux classes : capables et non capables de jouer le rôle en question. Or, cette restitution dichotomique des agents entre capables et non capables paraît abrupte car elle se présente comme une formulation du type « tout » ou « rien ». Il est donc question d’assouplir cette division abrupte et chercher un passage d’un état de privation de capacités à une situation de non privation qui se fait de manière graduelle. Pour se faire, on a recouru à la théorie des ensembles flous reflétant l’admission de l’existence de situations intermédiaires entre le tout et le rien à partir de l’idée d’appartenance partielle à une classe. La théorie des ensembles flous apparaît comme un outil bien adapté pour modéliser un concept vague tel que la capacité d’un agent ou de toutes entités logicielles pour jouer un rôle donné ou pour accomplir une tâche précise. En fait, il s’agit d’établir une fonction d’appartenance des agents à un ensemble d’agents (groupe) amenés à jouer un rôle qui, à ses extrémités, inclut les agents ou l’en exclut de façon certaine, mais qui, entre les valeurs extrêmes, varie à proportion de la proximité au groupe. L’avantage de cette théorie, c’est qu’elle offre la possibilité de combiner différents aspects de capacités des agents tels que la mobilité, le savoir faire, la possession de ressources,…etc. En plus de la mesure floue proposée pour mesurer les capacités des agents permettant ainsi de traiter le problème de la conformité des agents et des rôles, l’approche proposée montre plusieurs autres avantages et point forts que nous avons discutés dans la section bilan à la fin du sixième chapitre. Certains de ces derniers sont hérités naturellement de l’utilisation 184
des composants et des agents. D’autres résultent de la combinaison et de la manière dont sont combinés les deux paradigmes dans l’approche proposée, notamment sur le plan de l’adaptation qui est supportée à deux niveaux. Au niveau des agents, ces derniers sont adaptés par réassemblage automatiques adéquats des composants dans le but de rendre leurs comportements plus conformes avec leurs situations dans l’organisation. Au niveau de l’organisation, Les rôles sont attribués aux agents dynamiquement dans un système de concurrence entre les agents qui provoque des adaptations aux niveaux des agents a fin d’occuper les positions qu’ils veulent dans l’organisation.
L’inexistence d’une plate forme logicielle supportant et permettant la manipulation des composants au même titre que les agents, nous a empêchés de réaliser une mise en œuvre effective d’une application conformément à l’approche proposée. Pour cette raison, nous avons fixé comme perspective dans un futur proche de proposer une extension dans la plate forme multi agent Madkit pour permettre une intégration effective des composants logiciels dans les agents et par la suite mettre en œuvre des applications de tailles importantes pour faire une preuve réelle de la faisabilité et l’efficacité de l’approche proposée.
185
Bibliographie [1] Abraham B Z and Aguilar J C, « Software Component Selection Algorithm Using Intelligent Agents», Proceedings of the 1st KES International Symposium on Agent and Multi-Agent Systems: Technologies and Applications, Wroclaw, Poland, 2007. [2] Agha G, «Actors: a Model of Concurrent Computation in Distributed Systems», Series in Artificial Intelligence, MIT Press, 1986. [3] Aladenise N, Bouchon-Meunier B, « Acquisition de connaissances imparfaites : mise en évidence d’une fonction d’appartenance», Revue Internationale de Systémique, Vol 11,n° 2, pages. 109-127. 1997. [4] Alexander C, « The Timeless Way of Building», Oxford University Press, 1979. [5] Allen P, Frost S, « Component-Based Development for the Enterprise: Applying the Select Perspective», Cambridge University Press, 1998. [6] Ambler S W, « An Introduction to Process Pattern», AmbySoft White paper, 1998. http://www.Ambysoft.com. [7] Amiguet, M, MOCA: «un modèle componentiel dynamique pour les systèmes multi-agents organisationnels», thèse, Université de Neuchâtel,Switzerland, 2003. [8] Amor M, Pinto M, Fuentes L and Troya J M, « Combining Software Components and Mobile Agents», Proceeding of First International Workshop on Engineering Societies in the Agents' World, Berlin, Germany, August, 2000. [9] André J, «Moving From Merise to Schlaer and Mellor», SIG Publication vol n°3, 1994. [10] Appache organisation, http://www.apache.org/ [11] Arcangeli J, Maurel C,
Migeon F, «An api for high-level software engineering of distributed and mobil
applications», Proceedings of the 8th IEEE Workshop on Future Trends of Distributed Computing Systems, IEEE Computer Society, Washington,DC, USA, 2001. [12] Atkinson C, Bayer J, Bunse C, Kamsties E, Laitenberger O, Laqua R, Muthig D, Paech B, Wüst J, Zettel J, «Component-based Product Line Engineering with UML», Addison-Wesley, 2001. [13] Atkinson C, Bostan P, Brenner D, Falcone G, Gutheil M, Hummel O, Juhasz, M, Stoll D, « Modeling Components and Component-Based Systems in KobrA». In Rausch, Reussner, Mirandola, Plasil (editors): The Common Component Modelling Example, Springer, 2008. [14] Baciu A, Nagy A, «Coordination and reorganization in multi-agent systems», i. Sudia Univ. Babes-Bolyai – Informatica, vol 2,2003. [15] Back T and Kursawe F, «Evolutionary algorithms for fuzzy logic: a brief overview», Proceedings of the fifth international conference (IPMU) Information Processing and Management of Uncertainty in Knowledge-Based Systems, pages 659-664,1994. [16] BARIKA F A, «Vers un IDS Intelligent à base d’Agents Mobiles», Mémoire de DEA, Université de Tunis Institut Supérieur de Gestion, SOI2E-ISG-TUNIS, LERIA-EPITECH-PARIS, 2003. [17] Bellissard L, « Construction et configuration d’applications réparties», thèse, Institut National Polytechnique de Grenoble, France, Décembre 1997. [18] BERMEJO R A , «Reactive Operating SystemREactive Java Objects»,Electronic Journal on Networks and Distributed Processing, Vol 11, n° 3, pages 337−354, 2001.
182
[19] Bertoa M F, Troya J M, and Vallecillo A , «Usability metrics for software components», Proceedings of the 8th ECOOP Workshop on Quantitative Approaches in Object- Oriented Software Engineering, Oslo, Norway, 2004. [20] Beugnard A, Jézéquel J M, Plouzeau N, et Watkins D, «Making Components Contract Aware », IEEE , 1,1999. [21] Bezdek J C, «Fuzzy Models -What Are They, and Why ? », IEEE Transactions on Fuzzy Systems, Vol 1, N° 1, February 1993. [22] Bézivin J, «Sur les principes de base de l’ingénierie des modèles », revue RTSI-L’Objet, vol10, n°4 : Page 145-157, 2004. [23] Bialek R and Jul E, « A Framework for Evolutionary, Dynamically Updatable, Component- Based Systems», proceedings of the International Conference on Distributed Computing Systems Workshops, 2004. [24] Bouchon-Meunier B and Marsala C, « Logique floue, principes, aide à la décision», Hermes, 2003. [25] Boos J H, «A knowledge acquisition program for expert systems based on personal construct psychology», International Journal of Man-Machine Studies, Vol 23, pages 495-525, 1985. [26] Bradbury J S, Cordy J R, Dingel J, and Wermelinger M, «A survey of self management in dynamic soft ware architecture specifications», Proceedings of the ACM SIGSOFT International Workshop on Self-Managed Systems. ACM Press, October/November 2004. [27] Briot J-P, Meurisse T, and Peschanski F, « Une expérience de conception et de composition de comportements d’agents à l’aide de composants». L’OBJET, Vol 11, n° 3, 2006. [28] Brogi A, Canal C, and Pimentel E. «Behavioural types and component adaptation»,Proceedings of the 11th International Conference on Algebraic Methodology and Software Technology, 2004. [29] Brown A W, «Large-Scale, Component-Based Development», Prentice Hall, 2000. [30] Bruneton E, Coupaye T, Stefani JB, «The Fractal Component Model», 2004, http://fractal.objectweb.org/. [31] Bruneton E, Coupaye T, Leclercq M, Quéma V, and Stefani J-B, « An open component model and its support in java », In Ivica Crnkovic, Judith A. Stafford, Heinz W. Schmidt, and Kurt C. Wallnau, editors, CBSE, volume 3054 of Lecture Notes in Computer Science, pages 7–22. Springer, 2004. [32] Bures T, Hnetynka P, and Plasil F. «Sofa 2.0 : Balancing advanced features in a hierarchical component model», Proceedings of the 4th International Conference on Software Engineering Research, Management and Applications, IEEE Computer Society, Washington, DC, USA, 2006. [33] Cabri G, FERRARI L, Leonardi L, Klusch M, Ossowski S, Kashyap V and Unland R, « The RoleX environment for multi-agent cooperation», 8 th International workshop on cooperative information agents, Germany, 2004. [34] Casanave C, «Business Object Architectures and Standards», Data Access Corporation, Miami USA, 1996. [35] Chauvin S, «Evolution des théories de la décision appliquées à la fusion de capteurs en imagerie satellitaire», Thèse de doctorat d’Université, Nantes, France, 1995. [36] Cheesman J, Daniels J, «UML Components: A Simple Process for Specifying Component-Based Software», Addison-Wesley, 2000. [37] Chen D and Doumeingts G, « European initiatives to develop interoperability of enterprise applications –basic concepts, framework and roadmap», Annual Reviews in Control, vol 27, pages :153–162, 2003. [38] Chen J E and Otto K N, «Constructing membership functions using interpolation and measurement theory», Fuzzy sets and Systems, Vol 73, pages. 313-327,1995.
183
[39] Civanlar M R and Trussell H J, «Constructing membership functions using statistical data», Fuzzy Sets and Systems, Vol 18, pages 1-13, 1986. [40]COLMAN A, HAN J, « Organizational roles and players», Proceedings of AAAI Fall Symposium, Roles, an Interdisciplinary Perspective, pages 55-62, 2003. [41] Collier K, Carey B , Sauter D and Marjaniemi C, « A methodology for evaluating and Selection Data Mining Software», Proceedings of the thirty second Hawaii international conference on system Sciences,1999. [42] Corey A H, « Dublin Core metadata Initiative: beyond The element set », Information Standards Quarterly ,Vol 22,n°1,ISSN 1041-0031,2010. [43] Coutaz J, Crowley J L, Dobson S, and Garlan D, « Context is key », Commununication of the ACM, Vol 48 n°3, pages 49–53, 2005. [44] Crnkovic I and Larsson M, «Building Reliable Component-Based Software Systems», Artech House, 2002. [45] Dezani-Ciancaglini M and de’Liguoro U, «Sessions and Session Types: an Overview», 6th International Workshop Web Services and Formal Methods WS-FM, Bologna, Italy, 2009. [46] Dowling J and Cahill V, « The K-Component Architecture Meta-model for Self-Adaptive Software», proceedings of the International Conference on Metalevel Architectures and Separation of Crosscutting Concerns, 2001. [47] D’Souza D and Wills A C, «Objects, Components and Frameworks: The Catalysis Approach, Reading, MA», Addison-Wesley, 1998. [48] Dubois D, Prade H, « Fuzzy sets and systems, Theory and applications,» Academic Press, New. York , USA, 1985. [49] Dumant B, Horn F, Dang Tran F, and Jean-Bernard S, « an open distributed processing in Java». IFIP International Conference on Distributed Systems Platforms and Open Distributed Processing, The Lake District, U.K., 1998. [50] Eddon G, Eddon H, «Au coeur de Distributed COM», Microsoft Press, Les Ulis, ISBN : 2-84082-372-1, France, 1998. [51] Fassino J P, Stefani J B, Lawall J, and Muller G, «THINK : A software framework for component-based operating system kernels», proceeding of USENIX’02, Monterey,CA, USA, 2002. [52] Ferber J, «Les systèmes multi-agents, vers une intelligence collective», InterEditions,1995. [53]Ferber J, Gutknecht O, «A Meta-Model for the Analysis and Design of Organizations in Multi-Agents Systems»,1998. http://www.madkit.org [54] Filman R E, Elrad T, Clarke S, and Aksit M, « Aspect-Oriented Software Development», Addison-Wesley, Boston, 2005. [55] Finin T, Labrou Y, and Mayfield J, «KQML as an Agent Communication Language, Software Agents», edt J. Bradshaw, pages 291–316,MIT-Press, 1997. [56] FIPA, http ://www.fipa.org/repository/aclspecs.html, 2002. [57]
FIPA
Agent
Communication
LanguageOverview,
«
Foundation
for
Intelligent
Physical
Agents»,
http://www.fipa.org/specs/fipa00037/, 2000. [58] FIPA: Foundation for Intelligent Physical Agents. Specifications, 1997. http://www.fipa.org [59] Frances M, Brazier T, Catholijn M, Treur J, « Principles of component-based design of intelligent agents», Data & Knowledge Engineering, Vol41, n° 1, 2002.
184
[60] Gamma E, Helm R, Johnson R, Vlissides J, « Design Patterns, Elements of Reusable Oriented Software», AddisonWesley, 1995. [61] Gasser L, « Agents and Concurrent Objects», Special series on Actors and Agents, IEEE Concurrency, vol 6, n° 4 Pages:74–81, October-December, 1998. [62] Gatti S, Balland E, and Consel C,« A step-wise approach for integrating qos throughout software development», In Dimitra Giannakopoulou and Fernando Orejas, editors, Fundamental Approaches to Software Engineering, volume 6603 of Lecture Notes in Computer Science, pages Springer, 2011. [63] GAY S J, HOLE M, « Types for correct communication in client server systems», Technical report, Department of Computer Science, Royal Holloway, University of London, 2000. [64] Gay S, Vasconcelos V and Ravara A, «Session Types for Inter-Process Communication», citeseerx , Vol 1 n° 2, 2003. [65] Gelernter D, Carrierro D, « Coordination Languages and their Significance», Communications of the ACM, Vol 35, n° 2, 1992. [66] Giachino E, «Session Types: Semantic Foundations and Object-Oriented Applications», Thèse de l’université de Turin Italie et l’Université de Paris 7 France, 2009. [67] Grondin G, «MaDcAr-Agent : un modèle d’agents auto-adaptables à base de composants », thèse, l’École Nationale Supérieure des Mines de Saint-Étienne, 2008. [68] Gudgin M, «Essential IDL: Interface Design for COM», Addison-Wesley, 2001. [69]Gutknecht O, «Proposition d’un modèle organisationnel générique de systèmes multi-agents Examen de ses conséquences formelles, implémentatoires et méthodologiques», Thèse, Université de Montpellier I I France,2001. [70] Hannouns M, BoissierO, Sichman J S et SayettatC, «Moise : un modèle organisationnel pour la conception de systèmes multi-agents», Actes des 7èmes journées francophones sur l’Intelligence Artificielle distribuée et les systèmes multi-agents, France, 1999. [71] Hannouns M, BoissierO, Sichman J S et SayettatC «MOISE : An Organizational Model for Multi-Agent Systems», MONARD M. C., SICHMAN J. S., Eds., Proceedings of the International Joint Conference, 7th Ibero-American Conference on AI, 15th Brazilian Symposium on AI (IBERAMIA/SBIA’2000), Atibaia, SP, Brazil, LNAI 1952, Berlin, 2000. [72] Hart A , « Knowledge acquisition for expert systems», 2 nd edition, McGraw-Hill, 1992. [73] Hassine I, « Spécification et formalisation des démarches de développement à base de composants métier : La démarche Symphony», rapport de thèse, septembre 2005. [74] Heineman G, Councill W T, «Component-Based Software Engineering : Putting the Pieces Together», AddisonWesley, 2001. [75] Herzum P, and Sims O, «Business Component Factory: A Comprehensive Overview of Component-Based Development for the Enterprise», New York: John Wiley (OMG Press), 2000. [76] Hisdal E, « Are grades of membership probabilities? », Fuzzy Sets and Systems, Vol25, pages 325-348, 1988. [77] Hnetynka P and Tuma P, « Fighting class name clashes in java component systems». In JMLC, pages 106–109, 2003.
185
[78] Hua L, Parashar M, and Hariri S, «A component based programming model for autonomic applications», Proceedings of the First International Conference on Autonomic Computing, IEEE Computer Society, New York, USA, 2004. [79] Hübner J F, Sichman J S, Boissier O, « Spécification structurelle, fonctionnelle et déontique d’organisations dans les SMA», Actes des journées francophones sur l’Intelligence Artificielle distribuée et les systèmes multi-agents, 2002. [80] Inverardi P and Tivoli M, «Correct and automatic assembly of COTS components : an architectural approach», In Proceedings of the 5th ICSE Workshop on Component-Based Software Engineering (CBSE5) : Benchmarks for Predictable Assembly, 2002. [81] Jacobson I, Booch G, and Rumbaugh J, «The Unified Software Development Process», Addison-Wesley-Longman, 1999. [82] Jadhav A S and Sonar R M, « A hybrid system for selection of the software packages», Proceeding of first international conference on emerging trends in engineering and technology ICETET, IEEE Xplore, 337-342,2008. [83] Jeffrey L M and Tsai J P, « Security modeling and analysis of mobile agent systems», Series in Electrical and Computer Engineering Vol 5, 2006. [84] Jennings N R, « On agent-based software engineering», Artificial Intelligence Journal, 2000. [85] Jennings N R, «Automated négociation: prospects, methods, and challenges», Journal of Group Decision and négociation, 2000. [86] Jian L ,« Some Research on Componentware Frameworks Based on Mobile Agent Technology», Software Engineering Notes Volume 29 Number 2, ACM SIGSOFT, March 2004. [87] Johnson R E, «Frameworks = (Components + Patterns) », Communications of the ACM, Vol. 40, Num 10, 1997. [88] Kafura D, Briot J-P. «Introduction to Actors and Agents», Special Series, IEEE Concurrency, Vol 6, n° 2, 1998. [89] Ketfi A, Belkhatir N, and Cunin P Y, «Adaptation dynamique, concepts et experimentations». In Proceedings of the International Conference "Software and Systems Engineering and their Applications", Paris, France, 2002. [90] Kennedy J, Eberhart R, « Swarm Intelligence » , The Morgan Kaufmann Series in Evolutionary Computation, 2000. [91] Khayati o, «Modèles formels et outils génériques pour la gestion et la recherche de composants ». Thèse, INSTITUT NATIONAL POLYTECHNIQUE DE GRENOBLE, 2005. [92] Kiczales G, Lamping J, Mendhekar A, Maeda C, Videira Lopes C, Loingtier J M, and Irwin J, «Aspect-oriented programming», In Proceedings of the European Conference on Object-Oriented Programming, volume 1241 of LNCS. Springer-Verlag, 1997. [93] Kitio.T.R, «gestion de l’ouverture au sein d’organisations multi-agents», thèse de l’école nationale supérieure des mines, Saint-Etienne, France, 2011. [94] Kruchten PH, «The Rational’s Unified Process – An Introduction», Addison-Wesley, 1999. [95]
Krutisch
R,
Meier
P,
Wirsing
M,
«The
AgentComponent
Approach,
Combining
Agents
and
Components»,Multiagent System Technologies, Lecture Notes in Computer Science 2831, pages 1–12. SpringerVerlag, Heidelberg, Germany, 2003. [96] Lacouture J, Aniorté P, «vers l’adaptation dynamique de services : des composants monitorés par des agents », Journées Multi-Agents et Composants, JMAC 2006, Nimes, France, 21 mars, 2006.
186
[97] Layaïda O and Hagimont D, «Plasma : A component-based framework for building self-adaptive applications», Proceeding of SPIE/IS&T Symposium On Electronic Imaging, Conference on Embedded Multimedia Processing and Communications, San Jose, CA, USA, January 2005. [98] LEDOUX T, «État de l'art sur l'adaptabilité», Rapport technique, Ecole des Mines de Nantes, 2001. [99] Lemaître C and Excelente C B, «Multi-agent organization Approach », In Proceedings of II Iberoamerican Workshop on DAI and MAS, 1998. [100] Leriche S, « Architectures à composants et agents pour la conception d’applications réparties adaptables», Thèse de doctorat, Université Paul Sabatier, Toulouse, France, 2006. [101] Leriche S, Jean-Paul Arcangeli J-P, « Adaptive Autonomous Agent Models for Open Distributed Systems». In International Multi-Conference on Computing in the Global Information Technology, Guadeloupe,
IEEE
ComputerSociety, 2007. [102] Loughran N, Rashid A, Zhang W, and Jarzabek S. « Supporting product line evolution with framed aspects», In ACP4IS’04 : Proceedings of the 3rd Workshop on Aspects, Components, and Patterns for Infrastructure Software, Lancaster, UK, 2004. [103] Luckham D C, «Specification and Analysis of System Architecture Using Rapide», IEEE Trans, on Software Engineering, Special Issue on Software Architecture, 1995. [104] Malville E, « L’auto-organisation de groupes pour l’allocation de tâches dans les Systèmes Multi-Agents: Application à CORBA », Thèse, Université SAVOIE, 1999. [105] Mansour S , Ferber J, «Un modèle organisationnel pour les systèmes ouverts déployés à grande échelle», Université de Pau et des Pays de l'Adour, France, 2007. [106] Marcoux A, Maurel C, Migeon F, Sallé P, «Generic operational decomposition for concurrent systems : semantics and reflection», Progress in computer research, 2001. [107] Marvie R, and Merle P, «CORBA Component Model: Discussion and Use with Open CCM», rapport technique du Laboratoire d’Informatique Fondamentale de Lille Université des Sciences et Techniques de Lille, Lille, France, Jan. 2001. [108] Maxville V, Armarego J , and Lam C P, « Intelligent Component Selection», proceedings of 28
th
annual
international computer society and application conference, COMPSAC, 2004. [109] Magee J, Dulay N, and Kramer J, « A Constructive Development Environment for Parallel and Distributed Programs», Proceedings of 2nd IEEE International Workshop on Configurable Distributed Systems,1994. [110] Medividovic N, Taylor R N, «A Classification and Comparison Framework for Software Architecture Description Languages», IEEE Trans. on Software Engineering, Vol. 26, No. 1, 2000. [111] Mejdi K and Pautet L, « Cooperative approach for mobile application adaptability based on mobilejms», Proceedings of the 1st French-speaking conference on Mobility and ubiquity computing, 2004. [112] Melliti.T, Haddad.S, Suna.A, and Seghrouchni.A.E, « Web-MASI : Multi-agent systems interoperability using web services based approach», Proceedings of the IEEE/-WIC/ACM International Conference on Intelligent Agent Technology (IAT’05), pages 739–742, Compiègne, France, September 2005. IEEE Computer Society Press. [113] Meyer B, «design by contract», IEEE Computer, Vol 25, num 10, 1992. [114] Microsoft, «COM, Component Object Model: Technical Overview», Dr Dobbs Journal, December 1994, http://www.microsoft.com/com/wpaper/Com_modl.asp.
187
[115] Microsoft, « COM, COM Fundamentals », 2005, http://msdn.microsoft.com/library/ [116] Microsoft, .NET, http://www.microsoft.com/net/ [117] Microsoft,http://www.microsoft.com/global/svse/sommarkollo/RichMedia/introducing_visual [118] Mukhija A, Glinz M, «Runtime adaptation of applications through dynamic recomposition of components», Proceedings of the 18th International Conference on Architecture of Computing Systems, Innsbruck, Austria, March 2005. [119] Müller J P, «The Design of Intelligent Agents: A Layered Approach», Number 1177 in Lecture Notes in Artificial Intelligence (LNAI), Springer-Verlag, 1996. [120] Nagapraveen J, Coupaye T, Collet C, and Rivierre N, « Des règles actives au sein d’une infrastructure logicielle autonomique», RENPAR’16 / CFSE’4 / SympAAA’ 2005 / Journées Composants 2005, Le Croisic, France, 2005. [121] Neuman.B.C, « Scale in Distributed Systems». In Readings in Distributed Computing Systems, Los Alamitos, Calif: IEEE Computer Society Press,1994. [122] Norwich A M and Turksen I B, «A model for measurement of membership and the consequences of its empirical implementation», Fuzzy Sets and Systems, Vol 12, pages 1-25, 1984. [123] Occello M, Baeijs C, Demazeau Y, Koning J L, «Mask : An aeio toolbox to develop multi-agent systems». Knowledge Engineering and Agent Technology, IOS Series on Frontiers in AI and Applications, Amsterdam, Netherlands, 2002. [124] Odell J, Parunak H, Fleischer M «the role of roles in designing effective agent organization», LNCS, USA,2003. [125] OMG (Object Management Group), «The Common Object Request Broker: Architecture and Specification», Report v2.4, OMG Standards Collection, OMG, 2000. [126] OMG (Object Management Group),«Business Object Management Special Interest Group – BOMSIG Activities and direction», 1994. [127] OMG (Object Management Group),«Unified Modeling Language : Superstructure», Version 2.0, août 2003. [128] OSGI, OSGI Service Gateway Specification, Release 1.0, http://www.osgi.org [129]OMG Specifications, http://www.omg.org/spec. [130] Omicini.A, Ricci.A, and Viroli.M, «Agents Faber : Toward a theory of artefacts for MAS», Electronic Notes in Theoretical Computer Sciences, Vol 150, n°3, pages :21–36, 2006. [131] Oreizy P, « Issues in the runtime modification of software architectures», Technical Report UCI-ICS-96-35, University of California, Irvine, CA, USA, August 1996. [132] OSGi Alliance. « Osgi : Open services gateway initiative» . http ://www.osgi.org/. [133] Padiou G, Quéinnec P, Mauran P et Cubat C ,« Composants mobiles fondés sur des agents mobiles coopérants », Journées Composants, Le Croisic, 05/04/2005 – 08/04/2005 Association ACM-SIGOPS, France, 2005. [134] Paulo M, Luís S, «Component Agent Systems: Building a Mobile Agent Architecture That You Can Reuse», Architectural design of multi-agent systems : technologies and techniques ; Information Science Reference (an imprint of IGI Global) 2OO7.
188
[135] Pelliccione P, Tivoli M, Bucchiarone A, Polini A, « An architectural approach to the correct and automatic assembly of evolving component-based systems». The Journal of Systems and Software, no 81, p 2237–2251, 2008. [136] Picard G, Hübner J F, Boissier O and Gleizes M P, « Réorganisation et auto-organisation dans les systèmes multi-agents», Journées Francophones des Systèmes Multi-Agents jfsma, 2009. [137] Pierre-Charles D, Ledoux T, «Wildcat : a generic framework for context-aware applications», Proceeding of th 3rd International Workshop on Middleware for Pervasive and Ad-Hoc Computing, Grenoble, France, November 2005. [138] PLASIL F, VISNOVSKY S, «Behaviour Protocols for Software Components». Transactions on Software Engineering, IEEE ,2002. [139] Platt D S, «Understanding COM+», Microsoft Press, 1999. [140] Pokahr A, Braubach L, and Jander K, « Unifying Agent and Component Concepts Jadex Active Components», Proceedings of the 8th German conference on Multi-Agent System TEchnologieS (MATES-2010), C. Witteveen and J. Dix, eds., Springer, 2010. [141] Pokahr A, Braubach L , and Lamersdorf W, «Jadex: A BDI Reasoning Engine. In Multi-Agent Programming: Languages, Platforms and Applications»,Springer, 2005. [142] Ralescu D, « A survey of the representation of fuzzy concepts and its applications» , MM GUPTA, R K RAGADE, and R R YAGER, advances in fuzzy set theory and applications, North Holland, 1979. [143] Rank S, « A Reflective Architecture to Support Dynamic Software Evolution». Thèse de l’université de Durham, UK, 2002. [144] Renaux E, Olivier C and Jean-Mark G, «Chaîne de production de systèmes à base de compoants logiques », Proceeding of LMO (Langage et Modèles à Objets ), Lille, France,2004. [145] Ricordel P-M, Yves Demazeau Y, « La plate-forme volcano : modularité et réutilisabilité pour les systèmes multiagents», Numéro spécial sur les plates-formes de développement SMA. Revue Technique et Science Informatiques, 2002. [146] Ricci A, Viroli A, and Omicini A, «Give agents their artifacts: The A&A approach for engineering working environments in MAS». 6th International Conference, Autonomous Agents & Multi-Agent Systems, 2007. [147] Ritzau T and Andersson J, «Dynamic deployment of Java applications». In Java for Embedded Systems Workshop, London, 2000. [148] Rouvrais S, « Utilisation d’agents mobiles pour la construction de services distribués », thèse de l’université de Rennes, France, 2002. [149] Salzberg S L, « C4.5: Programs for Machine Learning by J. Ross Quinlan», Machine Learning, Vol 16, n° 3, pages 235-240, Morgan Kaufmann Publishers, Inc, 1994. [150] Savall M, Pécuchet J-P, Chaignaud N, Itmi M « YAMAM : Un modèle d’organisation pour les systèmes multiagents», Actes de la 3
ème
conférence francophone de modélisation et simulation, Troyes, France, 2001.
[151] Seghrouchni A E, Haddad S, Melliti T, and Suna A, « Interopérabilité des systèmes multi-agents à l’aide des services web». Actes des 12èmes Journées Francophones des Systèmes Multi-Agents), pages 91–104, Paris, France, November 2004. Hermès, 2004.
189
[152] Senart A, « Canevas logiciel pour la construction d’infrastructures logicielles dynamiquement adaptables». Thèse de l’institut National Polytechnique de Grenoble,France, 2003. [153] Seyler F, «Ugatze : métamodélisation pour la réutilisation de composants hétérogènes distribués», Thèse de l’Université de Pau et des Pays de l’Adour, France, 2004. [154]Shaw M, «Truth vs Knowledge: The Difference Between What a Component Does and What We Know It Does», Proceeding of 8th Int Workshop Software Specification and Design, Schloss Velen, Germany, IEEE Computer Society, 1996. [155] Shaw M, Garlan D, «Software Architectures - Perspective on an Emerging Discipline», Prentice Hall, 1996. [156] Siam A, MAAMRI R, SAHNOUN Z, « An approach based on software components and mobile agents for developing distributed applications with verification of validity criterion », The Sixth International Conference on Complex, Intelligent, and Software Intensive Systems, Palermo, Italy, 2012. [157] Silva L M, Simoes P, Soares G, Martins P, Batista V, Renato C, Almeida L, and Stohr N, «JAMES: A Platform of Mobile Agents for the Management of Telecommunication Networks», Proceedings of the third International Workshop in Intelligent Agents for Telecommunication Applications ,Stockholm, 1999. [158] Smith R G, «The Contract Net Protocol : High-Level Communication and Control in a Distributed Problem Solver», IEEE Transactions on Computers, C29, n° 12, pages 1104–1113, 1980. [159] Sommerville I, « Software engineering», 9th edition. Addison-Wesley, 2009. [160] Sora I, Matthijs F, Berbers Y, and Verbaeten P,« Automatic composition of systems from components with anonymous dependencies specified by semantic-unaware properties». Technology of Object-Oriented Languages, Systems & Architectures, n°732 , pages 154–179, March 2003. [161] Sun Microsystems, « JavaBeans 1.01 Specification», http://java.sun.com/beans. [162] Sun Micro, Enterprise JavaBeans Technology, http://java.sun.com/products/ ejb/, 2002. [163] Sycara K, Wido S, Klusch M, LARKS J Lu, «Matchmaking among Heterogeneous Agents in Cyberspace», Journal of Autonomous Agents and Multi-Agent Systems vol 5, n° 2, pages :173–203, 2002. [164] Szyperski C, «Component Software Beyond Object- Oriented Programming», Addison-Wesley, 1998. [165] Tinnemeier N, Dastani M and Meyer J J, «Roles and Norms for Programming Agent Organizations», 8th International Conference on Autonomous Agents and Multiagent Systems, Budapest, Hungary, 2009. [166] Vallecillo A, Vasconcelos V T and Ravara, A, «Typing the Behavior of Objects and Components using Session Types», Elsevier Science , 18,2003. [167] Vallecillo A, Vasconcelos V T and
Ravara A «Typing the Behavior of software Components using Session
Type», Fundamenta Informaticae, 72, 2006. [168] Van Gigch J P, « Applied general systems theory». HarperCollins-Publishers-Inc, 1974. [169] Vercouter L, «Conception et mise en oeuvre de systèmes multi-agents ouverts et distribués». Thèse de l’École des mines de Saint-Etienne,France, 2000. [170] Vercouter L, « MAST : Un modèle de composants pour la conception de SMA », Journées Multi-Agents et Composants (JMAC’04), pages 18–31, Ecole des Mines de Paris, France, Novembre 2004. [171] Wallnau K C, and Stafford J, «Ensembles: Abstractions for a New Class of Design Problem», Proceeding of the 27th Euromicro Conference, Warsaw, Poland, IEEE Computer Society, 2001.
190
[172] Wallisern B, «Systèmes et modèles : introduction critique à l’analyse de systèmes». Seuil, Paris, 1977. [173] Wang P Z, « From the fuzzy statistics to the falling random subsets »,P.P. WANG, Advances in Fuzzy Sets, Possibility Theory and Applications, pages 81-96,1983. [174] Warmer J, and Kleppe A, «The Object Constraint Language, Reading, MA», Addison- Wesley, 1999. [175] Warren L,«An Automated Formal Approach to Managing Dynamic Reconfiguration», proceedings of the IEEE/ACM International Conference on Automated Software Engineering, 2006. [176] Wermelinger M, Lopes A, and Luiz Fiadeiro J. «A graph based architectural (re)configuration language», Proceedings of the 8th European software engineering conference held jointly with 9th ACM SIGSOFT international symposium on Foundations of software engineering, 2001. [177] Weyns D, Van Dyke Parunak H, Michel F, Holvoet T, and Ferber J, «Environments for Multiagent Systems State-of-the-Art and Research Challenges», Environments for Multi-Agent Systems, edt D. Weyns et al , LNAI, No 3374, Springer- Verlag, 2005. [178] Xavier F,«Systematic formulation of non-functional characteristics of software», Proceeding of the International Conference on Requirements Engineering (ICRE'98), volume 00, IEEE Computer Society, Los Alamitos, CA, USA, 1998. [179] YAN Q, SHAN L J and MAO X J, « RoMAS: A Role-Based Modeling Method for Multi-Agent System», Proceedings of International Conference on Active Media Technology, 2003. [180] Zhang L, «Structural and functional quantization of vagueness», Fuzzy Sets and Systems, Vol 55, pages 51-60, 1993. [181] ZADEH L A, « Fuzzy sets», Information and Control, Vol 8, pages 338-353, 1965. [182] Zitouni A, « Utilisation des design Patterns et des méthodes formelles dans le développement des systèmes d’information », Constantine, 1998.
191
