Une Approche Multi Agents D’identification Précoce Des Interactions Entre Les aspects

République algérienne démocratique et populaire
Ministère de l’enseignement supérieur et de la recherche scientifique
Université 20 Aout-1955-SKIKDA
Faculté des Sciences
Département d’informatique
Mémoire de Fin d’études En Vue De l’obtention Du Diplôme
On Master professionnel
Option : Génie Logiciel et Applications Avancées(G.L.A.A)
Thème
Réalisé par : Encadré par :
• Bouleknafet Samir • Dr : BOUBENDIR AMEL
• LahLah Houssem
Session : juin 2018
Une Approche Multi Agents D’identification
Précoce Des Interactions Entre Les aspects

Résumé
L’approche orientée aspect est un nouveau paradigme de développement des logiciels qui
améliore les autres paradigmes précédents (fonctionnel, objet, composant) au niveau
modularité, par l’encapsulation des préoccupations transverses dans une nouvelle unité
modulaire nommée aspect. La séparation entre les aspects et les modules de base, réduit les
dépendances entre modules et améliore la modularité. Cependant, la complexité et la diversité
des interactions entre les aspects et entre les aspects et les modules de base, peut réduire la
valeur de l’approche par aspects. Alors, il est indispensable de détecter et résoudre les
interactions et conflits potentiels entre les aspects pour pouvoir les composer correctement.
Cependant nous proposons une nouvelle approche orienté agent de traitement précoce des
interactions d’aspects, notre approche est basé multi agents qui favorise une identification
précoce des interactions dans les artefacts d’analyse des exigences qui permet un traitement
consistant et certain des interactions.
Notre nouvelle approche orienté agents de traitement précoce des interactions entre les
aspects. Permet de libérer l’analyste qui a saisi la spécification de ces exigence orienté aspect,
et permet de surveiller d’une manière autonome la spécification et d’alerter l’analyste en cas
de problème pour corriger d'une manière précoce sa spécification et ainsi permet de
minimiser les erreurs de spécification. Notre système multi agents est dédié à l’identification
des conflits d’ordre et des conflits de type récursivité accidentelle.
.

Abstract
Aspect Oriented software development (AOSD) is an emerging technology that, provides
explicit mean to model concern that tend to crosscut multiple system components. From the
point of view of modularity, adaptability and evolutionarily, the separation of aspects in the
base modules may reduce dependency between modules and improves modularity. However,
the complexity of interactions among aspects and between aspects and base modules may
reduce the value of aspect oriented separation of cross-cutting concerns. The software engineer
has to systematically detect and resolve potential conflicts between aspects in order to
successfully reason about aspects and successfully compose them.
Right now, in oriented aspect research, the problem of interaction between aspects was treated
in two different directions: Approaches to formal verification and testing proposed for aspect-
oriented programs and early aspects approaches such as aspect oriented requirement
engineering approaches proclaiming the benefit of early treatment of aspects for all the process
of development.
As part of our work, we have chosen early treatment of interactions, in addition we promote a
level of concern about conflicts and interactions that allows consistent and certain treatment of
interactions.
Our goal is to propose a new agent-oriented approach for identifying the interactions between
aspects. which frees the user who has been entered the specification of these aspect-oriented
requirement, the specification will be corrected in an early manner that minimizes specification
errors. in our approach we focus on the identification of order conflicts and accidental recursion
type of conflicts.

‫ﻣﻠﺧص‬
‫ﯾوﻓر‬ ‫اﻟذي‬ ‫اﻟﺟذﯾذ‬ ‫اﻟﺗطوﯾر‬ ‫ﻧﻣوذج‬ ‫ھو‬‫ﻣﻔﮭوم‬ (AOSD) ‫ﺑﺎﻟﺟواﻧب‬ ‫اﻟﻣوﺟﮭﺔ‬ ‫اﻟﺑرﻣﺟﯾﺎت‬ ‫ﺗطوﯾر‬ ‫ﻧﻣوذج‬
‫واﻟﺗطور‬ ‫اﻟﺗﻛﯾف‬ ‫ﻋﻠﻰ‬ ‫اﻟﻘذرة‬ ‫ﻣﻧظور‬ ‫.ﻣن‬ ‫اﻟﺟﺎﻧﺑﯾﺔ‬ ‫اﻻﻧﺷﻐﺎﻻت‬ ‫ﻟﺗﻐﻠﯾف‬ ‫واﺿﺢ‬‫اﻟﺠﻮاﻧﺐ‬ ‫ﺑﯿﻦ‬ ‫اﻟﻔﺼﻞ‬ ،
‫ﻣﻦ‬ ‫ﯾﻘﻠﻞ‬ ‫اﻷﺳﺎﺳﯿﺔ‬ ‫واﻟﻮﺣﺪات‬‫اﻟﺘﺒﻌﯿﺎت‬، ‫وﻟﻜﻦ‬ ‫اﻟﺒﺮاﻣﺞ‬ ‫ﻧﻮﻋﯿﺔ‬ ‫وﯾﺤﺴﻦ‬ ‫اﻟﻮﺣﺪات‬ ‫ﺑﯿﻦ‬‫ﺗﻌﻘﺪ‬‫اﻟﺘﻔﺎﻋﻼت‬ ‫وﺻﻌﻮﺑﺔ‬
‫ﺑﯿ‬‫ﻦ‬‫ﺧﻔﺾ‬ ‫ﻣﻦ‬ ‫ﯾﻤﻜﻦ‬ ‫اﻷﺳﺎﺳﯿﺔ‬ ‫واﻟﻮﺣﺪات‬ ‫اﻟﺠﻮاﻧﺐ‬. ‫ﺑﺎﻟﺠﻮاﻧﺐ‬ ‫اﻟﻤﻮﺟﮭﺔ‬ ‫اﻟﻤﻨﮭﺠﯿﺔ‬ ‫ﻗﯿﻤﺔ‬‫ﻣﮭﻨﺪس‬‫اﻟﺒﺮﻣﺠﯿﺎت‬
‫اﻟﺠ‬ ‫ﺑﯿﻦ‬ ‫اﻟﻤﺤﺘﻤﻠﺔ‬ ‫اﻟﻨﺰاﻋﺎت‬ ‫ﺗﺴﻮﯾﺔ‬ ‫إﻣﻜﺎﻧﯿﺔ‬ ‫إﻟﻰ‬ ‫ﺣﺎﺟﺔ‬ ‫ﻓﻲ‬‫ﻟﺘﻜﻮن‬ ‫ﻣﻨﮭﺠﻲ‬ ‫ﺑﺸﻜﻞ‬ ‫ﻮاﻧﺐ‬‫ﻗﺎدرة‬‫ﻋﻠﻰ‬‫اﻻﺗﺼﺎل‬
‫ﻣﺨﺘﻠﻔﯿﻦ‬ ‫اﺗﺠﺎھﯿﻦ‬ ‫ﻓﻲ‬ ‫اﻟﺠﻮاﻧﺐ‬ ‫ﺑﯿﻦ‬ ‫اﻟﺘﻔﺎﻋﻞ‬ ‫ﻣﺸﻜﻞ‬ ‫ﺗﻌﺎﻟﺞ‬ ‫اﻟﺠﺎﺑﻲ‬ ‫اﻟﺘﻮﺟﮫ‬ ‫ﺣﻮل‬ ‫،اﻷﺑﺤﺎث‬ ‫ﺣﺎﻟﯿﺎ‬ ‫ﺻﺤﯿﺢ‬ ‫ﺑﺸﻜﻞ‬:
‫ﻣﻨﺎھﺞ‬‫ﻟﻼﺧﺘﺒﺎر‬‫واﻟﺘﺤﻘﻖ‬‫اﻟﺪﻗﯿﻖ‬‫اﻟﻤﻮﺟﮭﺔ‬ ‫اﻟﺒﺮاﻣﺞ‬ ‫ﻣﺴﺘﻮى‬ ‫ﻋﻠﻰ‬ ‫اﻟﺘﻔﺎﻋﻼت‬ ‫ﻣﺸﻜﻞ‬ ‫ﻟﻤﻌﺎﻟﺠﺔ‬ ‫أﺳﺎﺳﺎ‬ ‫ﻣﻘﺘﺮﺣﺔ‬
‫اﻟﺠﻮاﻧﺐ‬ ‫ﻣﻨﺎھﺞ‬ ‫و‬ ‫ﺑﺎﻟﺠﻮاﻧﺐ‬‫اﻟﻤﺒ‬‫ﺑﺎﻟﺠﻮاﻧﺐ‬ ‫اﻟﻤﻮﺟﮭﺔ‬ ‫اﻟﻤﺘﻄﻠﺒﺎت‬ ‫ھﻨﺪﺳﺔ‬ ‫ﻣﻨﺎھﺞ‬ ‫ﻣﺜﻞ‬ ‫ﻜﺮة‬‫ﺗﺼﺮح‬ ‫اﻟﺘﻲ‬‫وﺗﻨﺎدي‬
‫ﺑﻔﺎﺋﺪة‬‫ﻣﺮ‬ ‫ﻟﻜﻞ‬ ‫ﻟﻠﺠﻮاﻧﺐ‬ ‫اﻟﻤﺒﻜﺮ‬ ‫اﻟﻌﻼج‬‫ا‬‫اﻟﺒﺮﻣﺠﻲ‬ ‫اﻟﺘﻄﻮﯾﺮ‬ ‫ﺣﻞ‬.
‫ﺑﺎﻟﻨﺴﺒﺔ‬‫ﻟﻨﺎ‬‫اﻟﺠﻮاﻧﺐ‬ ‫ﺑﯿﻦ‬ ‫ﻟﺘﻔﺎﻋﻼت‬ ‫اﻟﻤﺒﻜﺮ‬ ‫اﻟﻌﻼج‬ ‫أﺧﺘﺮﻧﺎ‬‫اﻋﺘﻤﺪﻧﺎ‬ ‫ﺑﺎﻹﺿﺎﻓﺔ‬‫ﻣﻨﮭﺠﯿﺔ‬‫ﺗﺤﺪﯾﺪ‬‫ﻣﺴﺘﻮى‬ ‫ﻋﻠﻰ‬
‫ا‬‫اﻟﻤﺘﺴﻘﺔ‬ ‫ﻟﻠﻤﻌﺎﻟﺠﺔ‬ ‫ﺗﺴﻤﺢ‬ ‫اﻟﺘﻲ‬ ‫اﻻﺣﺘﯿﺎﺟﺎت‬ ‫ﺗﺤﻠﯿﻞ‬ ‫اﻟﺘﺤﻠﯿﻼت‬ ‫ﻓﻲ‬ ‫ﻟﺘﻔﺎﻋﻼت‬،‫اﻟﺘﻔﺎﻋﻼت‬ ‫وﺑﻌﺾ‬‫ﻛﻤﺎ‬‫أن‬‫ﻣﻨ‬‫ﮭ‬‫ﺠﯿﺘﻨﺎ‬
‫ﻋﻦ‬ ‫ﻋﺒﺎرة‬ ‫ھﻲ‬‫ﻣﻨﮭﺠﯿﺔ‬‫ﻣﺘﻌﺪد‬‫ة‬‫اﻟﺠﻮاﻧﺐ‬ ‫ﻟﺘﺤﺪﯾﺪ‬ ‫اﻟﺠﻮاﻧﺐ‬ ‫ﻋﻦ‬ ‫اﻟﻠﻐﺔ‬ ‫ﻋﻦ‬ ‫ﻣﺴﺘﻘﻠﺔ‬ ‫اﻟﺘﻔﺎﻋﻼت‬ ‫ﻟﺘﺤﻠﯿﻞ‬ ‫اﻟﻮﻛﻼء‬
‫وﺗﺮﻛﯿﺒﮭﺎ‬‫ﺑﯿﻨﮭﻤﺎ‬ ‫واﻟﻨﺰاﻋﺎت‬ ‫اﻟﺼﺮاﻋﺎت‬ ‫وﺣﺴﻢ‬ ‫وﻛﺸﻒ‬ ‫اﻟﺠﻮاﻧﺐ‬ ‫ﺑﯿﻦ‬ ‫اﻟﺘﻔﺎﻋﻼت‬ ‫ﻋﻠﻰ‬ ‫ﺑﺎﻟﺘﻌﺮف‬ ‫ﺗﺴﻤﺢ‬ ‫واﻟﺘﻲ‬
‫ﺗﺤﻠﯿﻞ‬ ‫ﻣﺮﺣﻠﺔ‬ ‫ﺧﻼل‬.‫اﻟﻤﺘﻄﻠﺒﺎت‬
‫ﻣﺘﻌﺪ‬ ‫ﻧﻈﺎم‬ ‫أﺳﺎﺳﮭﺎ‬ ‫اﺳﺘﺮاﺗﯿﺠﯿﺔ‬ ‫ﻋﻦ‬ ‫ﻋﺒﺎرة‬ ‫اﻟﻤﻨﮭﺠﯿﺔ‬ ‫ھﺬه‬‫د‬‫ﻣﻦ‬ ‫اﻟﻮﻛﻼء‬‫ا‬ ‫ﻣﺴﺘﻮى‬‫وﯾﻌﺰز‬ ‫ﯾﻠﺘﻘﻂ‬ ‫اﻟﺬي‬ ‫ﻟﻨﺰاﻋﺎت‬
‫اﻟﻘﯿﻮد‬‫ﺣﯿﺚ‬ ،‫ﺻﺤﯿﺢ‬ ‫ﻧﻈﺎم‬ ‫ﻟﺒﻨﺎء‬‫ﺗﻘﻮم‬‫ﻣﻮاﻗﻊ‬ ‫ﺑﺎﺳﺘﻐﻼل‬‫ﺗﻨﺸﺆھﺎ‬ ‫اﻟﺘﻲ‬ ‫واﻟﺘﺒﻌﯿﺎت‬ ‫اﻷﺳﺎﺳﯿﺔ‬ ‫اﻟﻮﺣﺪات‬ ‫ﻣﻦ‬ ‫اﻟﺠﻮاﻧﺐ‬
‫اﻟﻨﺴﯿﺞ‬ ‫ﻣﻌﺎﻣﻠﺔ‬ ‫ﺑﻮاﺳﻄﺔ‬‫اﻟﺠﻮاﻧﺐ‬ ‫ﻟﺘﺮﻛﯿﺐ‬ ‫اﻟﻤﺴﺘﻌﻤﻠﺔ‬‫ﻣﺜﻞ‬،‫ﻗﺒﻞ‬‫اﺳﺘﺒﺪال‬ ،‫ﺑﻌﺪ‬،.‫ﺣﻮل‬
‫اﻟﮭﺪف‬‫ﻣﻦ‬‫ﻧﮭﺠﻨﺎ‬‫اﻟﺠﺪﯾﺪ‬‫اﻟ‬‫ﻤﻮﺟﮫ‬‫ھﻮ‬ ‫ﻟﻠﻌﻤﯿﻞ‬‫ا‬‫ﻟﻌﻼج‬‫اﻟﻤﺒﻜﺮ‬‫ﻟﻠﺘﻔﺎﻋﻼت‬‫ﺑﯿﻦ‬‫اﻟﺠﻮاﻧﺐ‬.‫اﻟﺬي‬‫ﯾﺤﺮر‬‫اﻟﻤﺴﺘﺨﺪم‬
‫اﺛﻨﺎء‬‫إدﺧﺎل‬‫ﻣﻮاﺻﻔﺎت‬‫ھﺬه‬‫اﻟﻤﺘﻄﻠﺒﺎت‬‫اﻟﻤﻮﺟﮭﺔ‬‫ﻟ‬،‫ﻠﺠﻮاﻧﺐ‬‫ﺳﯿﺘﻢ‬‫ﺗﺼﺤﯿﺢ‬‫ھﺬه‬‫اﻟﻤﻮاﺻﻔﺎت‬‫ﺑﻄﺮﯾﻘﺔ‬‫ﻣﺒﻜﺮة‬
‫ﺗﻘﻠﻞ‬‫ﻣﻦ‬‫أﺧﻄﺎﺋﮭﺎ‬.‫ﻓﻲ‬‫ﻧﮭﺠﻨﺎ‬‫ﻧﺮﻛﺰ‬‫ﻋﻠﻰ‬‫ﺗﺤﺪﯾﺪ‬‫اﻟﺘﺮﺗﯿﺐ‬ ‫ﺻﺮاﻋﺎت‬‫و‬‫ﺻﺮاﻋﺎت‬‫اﻟﺤﻮادث‬‫اﻟﻌﻜﺴﯿﺔ‬‫ﻛﻤﺎ‬
‫وﺗﺴﻮﯾﺔ‬ ‫ﻟﺘﺤﺪﯾﺪ‬ ‫اﻟﺘﺒﻌﯿﺎت‬ ‫ﺑﯿﺎن‬ ‫ﻓﻲ‬ ‫اﻟﮭﺎﻣﻠﺘﻮﻧﯿﺔ‬ ‫اﻟﻤﺴﺎرات‬ ‫إﯾﺠﺎد‬ ‫ﺗﺴﺘﺨﺪم‬.‫اﻟﺼﺮاﻋﺎت‬
.

Remerciement
Avant tout, nous remercions Allah tout puissant qu'il nous a guidé tout
au long de notre vie, qu'il nous a donné le courage et la patience pour
passer tous les moments difficiles et qu'il nous a permet d'achever ce
travail et de pouvoir le mettre entre vos mains aujourd'hui.
Ce mémoire est aujourd'hui l'occasion de remercier notre encadreur Mme
BOUBENDIR Amel et qui nous offre une confiance et nous permet de
travailler sur un sujet de mémoire et qu'ils ont mis à notre disposition
tous les moyens et les ressources nécessaires à sa réalisation.
Nous remercions par ailleurs vivement les membres de jury de nous avoir
fait l'honneur de juger notre travail et d'assister à la soutenance.
Finalement nous remercions toutes personnes qui ont participé de près ou
de loin à la concrétisation de ce mémoire.
1

Dédicace
Au tout puissant Allah
A toi la louange, Õ la lumière des cieux; de la terre et de ce qu'il
renferme Gloire à toi de nous avoir assisté de
ta lumière et en toute circonstance matin et Soir.
Je dédie ce travail à Mon père qui m’a toujours orienté vers tous
ce qui est bien et à qui je dois tous le respect que Dieu lui
accorde santé et longue vie.
Ma très chère mère qui m'a toujours entouré de tendresse,
d’amour, d’encouragement de tous ce que je lui dois.
A tout les membres de ma très chère famille. .
Et à toutes mes amies
Et à tous ceux qui me connaissent.

Sommaire
L
Chapitre 01 : le développement Orientée Aspect
1. Introduction………………………………………………………………………………… 1
2. le développement orienté Aspects…………………………………………………………. 1
2.1 Définitions………………………………………………………………………………… 1
2.2 Pourquoi développement Orientée Aspect ? …………………………………………… 1
2.3 Méthodologie du développement orienté aspects………………………………...…….. 3
2.3.1 Décomposition aspectuelle……………………………………………………………..….. 3
2.3.2 Implémentation des préoccupations……………………………………….…… 3
2.3.3 Recomposition aspectuelle………………………………………………….……… 3
3. Les concepts de base de la programmation orientée Aspect……………………………… 4
3.1 Préoccupations……………………………………………………………..………………...4
3.1.1 Préoccupation de Base………………………………………………………………. 4
3.1.2 Préoccupation d'aspect…………………………………………………………………4
3.2 Point d’exécution (JoinPoint)……………………………………………………………….4
3.3 Coupe (pointcut) ……………………………………………………………………….……4
3.4 Code advice (advice code……………………………………………………………….…...5
3.5 Mécanisme d’introduction …………………………………………………………….……5
3.6 Aspect………………………………………………………………………………….……..5
3.7 Tissage (weaving)……………………………………………………………………….…...5
4. L’Ingénierie des Exigences orientées Aspect ……………………………………...………..6
4.1 L’aspect dans l’ingénierie des exigences orienté aspect…………………………………..7
4.2 Objectif de l’ingénierie des exigences orientée aspect…………………………………….7
4.3 Les approches d’ingénierie des exigences orientées Aspect……………...……………….7
4.4 Les avantages et les inconvénients des approches d’ingénierie des exigences
Orientées Aspect……………………………………………………………………………8
5. Conclusion……………………………………………………………………………………..9
. Introduction Générale

L
Chapitre 02 : Le problème d’interaction entre les aspects
1. Introduction……………………………………………………………………………… 10
2. Définition d’interaction entre aspects …………………………………………………… 10
3. Classification des interactions et conflits entre les aspects………………………………..11
4. Exemples des interactions et conflits entre les aspects……………………………………… 15
5. Comment traiter le problème d'interaction entre les aspects?…………………..………… 17
5.1 Le cycle de vie des aspects (les aspects précoces dans le cadre d’AOSD……....... 17
5.2 Approches pour traiter le problème d'interaction entre les aspects dans le cycle de vie…. 19
5.2.1 Les approches de test et de vérification formelle……………………………… 19
5.2.2 Approches des aspects précoces…………………………………………………..…… 20
6. Conclusion………………………………………………………………………………..……… 20
Chapitre 03 : Les Systèmes Multi Agents
1. Introduction………………………………………………………………………………… 21
2. Systèmes multi-agents……………………………………………………………………….… 21
2.1 Définition……………………………………………………………………………………… 21
2.2 Quand et Pourquoi opter pour les SMA………………………………………………… 22
3. La notion d’agent………………………………………………………………………………… 22
3.1 La définition d’un agent………………………………………………..………… 23
3.2 Caractéristiques des agents………………………………………………………………… 23
3.3 Les différentes catégories des agents…………………………………...………………… 24
3.3.1 Agents réactifs……………………………………..…………………… 24
3.3.2 Agents cognitifs………………………………………………………… 24
3.3.3 Agents hybrides……………………………………………….………………… 25
4. Environnement……………………………………………………………….…………………… 26
5. Interactions entre agents…………………….…………………………………………………… 27
5.1 Coopération entre agents…………………………………….…………………………… 28
5.2 Coordination entre agents………………………………………………..………………… 28
5.3 Négociation entre agents………………………………………………….…………………. 28
5.4 Communication entre agents………………………………………………………..……… 29
6. Organisation des agents………………………………………………………………..………… 31
7. Plateformes pour les systèmes multi agents……………………………………………….……… 32
7.1 MadKit……………………………………………………………………..……………….… 32
7.2 Mace…………………………………………………………………………..………………… 32
7.3 Swarm……………………………………………………………………………………… … 33
7.4 Jade……………………………………………………………………………………….……...… 33
8. Conclusion……………………………………………………………………………….………....…… 33

Chapitre 04 : Approche proposée et contribution
1. Introduction……………………………………………………………………………… 34
2. Travail de base ...……………………………..…………………...…………………....... 35
3. Description et Objectifs de notre approche basé Agent….…………..…………….………..... 36
4. Application Utilisateur (Système de Spécification)……………..………………………………… 37
5. Le système multi agents de surveillance des interactions entre les aspects …........................ 40
6. Les déférents agents de système de surveillance des interactions entre les aspects ………….. 41
6.1 L’agent Analyseur ………………………………………………..……………………..... 42
6.1.1 La structure de l’agent Analyseur...………………………………….............................. 42
6.1.2 L’aspect fonctionnel et L’interaction de l'agent Analyseur …………………………… 42
6.2 L’agent Conflit …………………………………………..………..……………………..... 43
6.2.1 La structure de l’agent Conflit…………………..…………………….............................. 43
6.2.2 L’aspect fonctionnel et L’interaction de l'agent Conflit ……………………………… 43
6.3 L’agent Interaction ………………………………………………..……………………..... 44
6.3.1 La structure de l’agent Interaction………………………………….............................. 44
6.3.2 L’aspect fonctionnel et L’interaction de l'agent Interaction ………………….……… 45
6.4 L’agent Graphe ………………………………………………..…..……………………..... 46
6.4.1 La structure de l’agent Graphe………………………….................................................. 46
6.4.2 L’aspect fonctionnel et L’interaction de l'agent Graphe……….……………………… 47
6.5 L’agent Conflit Graphe…………………………………………..………………………..... 48
6.5.1 La structure de l’agent Conflit Graphe …………..………………….............................. 48
6.5.2 L’aspect fonctionnel et L’interaction de l'agent Conflit Graphe ……………....……… 50
7. Conclusion……………………………………………...…………………………………………………51

Chapitre 05 : Conception et implémentation
1. Introduction…………………………………………………………………………………..52
2. Description de l'outil de notre approche proposée …………………………………………............52
3. Modélisation et conception de notre outil …………………..……………………………………….54
3.1 Système de spécification ……………………………………..…………………………………….55
3.1.1 La vue fonctionnelle …………………………..………………………………………………..55
3.1.2 La vue statique ……………………………………………………..…………………………...56
3.1.3 La vue dynamique ………………………………………………………………………………57
3.1.4 La conception de la base de données…………………………………………………………...58
3.2 Système de surveillance (multi-agent)……………………………………………………………….58
3.2.1 La vue fonctionnelle ……………………………………………………………………………58
3.2.2 La vue statique ………………………………………………………………………………….59
3.2.3 La vue dynamique ……….……………………………………………………………..……….60
4. Implémentation………………………………………………………………………………………….60
4.1 Outils du développement…………………………………………..……………………………......60
5. Conclusion……………………………………………………………….……………………………… 63
. Conclusion Générale
. Bibliographié

L
Liste des figures
Chapitre01
Figure 1.1 Un système vu comme un ensemble de préoccupations.……………………………………..2
Figure 1.2 Etapes de développement dans une méthodologie AOP……………………………………3
Figure 1.3 L’encapsulation des préoccupations transversales…………………………………………..5
Figure 1.4 La mise en œuvre du tissage des aspects………………………………………………...……6
Chapitre02
Figure 2.1 Exemple d’interaction d’aspect : ordre de tissage………………………………………….15
Figure 2.2 Aspect appliqué à trois classes différentes…………………………………………………..16
Figure 2.3 Aspect appliqué à une classe qui n'a pas besoin…………………………………………….17
Figure 2.4 Mapping des préoccupations vers des modules dans le cycle de vie……………………….18
Figure 2.5 Le cycle de vie des aspects…………………………………………………………………….19
Figure 2.6 Les aspects précoces……………………………………………………………………...…...19
Chapitre03
Figure 3.1 : Architecture d’un SMA………………………………………………………………………22
Chapitre04
Figure 4.1 : Le processus global de l'approche de base.………….....………...…...………………..….…35
Figure 4.2 : Schéma générale de l'approche proposée…………………………….………………………37
Figure 4.3 : Diagramme d'activité qui illustre les déférentes sessions du système de spécification ……39
Figure 4.4 : Un exemple d'une boite rapport indiquant l'Identification des interactions : niveau 1…..39
Figure 4.5 : Diagramme d'activité qui illustre les déférentes sessions du système de surveillance ...…40
Figure 4.6 : Un exemple d'une boite rapport indiquant l'Identification des conflits Récursifs : niveau
1………………………………………………………………….…………………………...….40
Figure 4.7 : Architecture générale du système multi agents proposé …….…..………...………………. 41
Figure 4.8 : Diagramme d'activité qui représente les tâches fonctionnelles et l'interaction de l’agent
Analyseur ……………………………...……………………………………………………... 42
Conflit………………….……………………………………………………………….……… 43
Interaction……………………………………………………………………………………. 45
Figure 4.11 : Un graphe de dépendance avec marquage……………………………………...…………. 46
Graphe ………………….…………………………………………………….…… ……….. 47
Figure 4.13 : Le code source qui permet la recherche des chemins hamiltoniens.……………….………. 48
Figure 4.14 : Un graphe de dépendance avec coefficients …………..…………………..…….………….. 49

L
Liste des figures
Chapitre04
Figure 4.15 : L’algorithme du chemin critique.………………..……………………………………….…49
Figure 4.16 : diagramme d'activité qui représente les tâches fonctionnelles et l'interaction de l’agent
Conflit Graphe.……………… …… ……………………………...………………………..50
Chapitre05
Figure 5.1 : Schéma générale de notre implémentation…………………..………………………….…52
Figure 5.2 : Interface saisir/modifier spécification …………………………..…………………….…...53
Figure 5.3 : Interface spécification de coupure …………………….…………..……….………………53
Figure 5.4 : Interface Boite Rapport des Conflits Récursifs ……………………………..…………….54
Figure 5.5 : Interface Boite Rapport des Interactions ………………………………………………….54
Figure 5.6 Diagramme de cas d’utilisation du système de spécification …..…………………………55
Figure 5.7 : Diagramme de classe du système de spécification …………………………..…………… 56
Figure 5.8 : Diagramme de séquence de système de spécification ………………………………..……57
Figure 5.9 Diagramme de cas d’utilisation du système de surveillance ………………………………58
Figure 5.10 : Diagramme de classe du système de surveillance …………………………..…………… 59
Figure 5.11 : Le diagramme d’interaction entre les agents du système de surveillance ….……..……60
Figure 5.12 : Le modèle de référence pour une plate-forme multi-agents FIPA ….……………...……61
Liste des Tables
Chapitre03
Tableau 3.1 : Comparatif entre agent cognitif et agent réactif………………………..…………………25
Chapitre04
Tableau 4.1 : La liste des déférents messages d'alerte ………………………..………………………….38

Introduction Générale
Le développement orienté Aspect (AOSD) est un nouveau paradigme de développement
des logiciels qui fournit un concept clair pour l’encapsulation des préoccupations
transverses.au niveau modularité, par l’encapsulation des préoccupations transverses dans
une nouvelle unité modulaire nommée aspect. La séparation entre les aspects et les modules
de base, réduit les dépendances entre modules et améliore la modularité. Cependant, la
complexité et la diversité des interactions entre les aspects et entre les aspects et les modules
de base, peut réduire la valeur de l’approche par aspects. Alors, il est indispensable de
détecter et résoudre les interactions et conflits potentiels entre les aspects pour pouvoir les
composer correctement.
L'ingénieur des logiciels a besoin systématiquement d'outil qui assiste à l'identification et
traitement des interactions et conflits potentiels entre les aspects pour pouvoir les composer
correctement.
Actuellement, dans les travaux de recherche orientés aspect, le problème d’interaction entre
les aspects a été traité en deux axes distincts : Des Approches de test et de vérification
formelles, proposées pour des programmes orientés aspect, et des approches d’aspects
précoces tel que d’ingénierie des exigences par aspect qui proclament l’avantage du
traitement précoce des aspects pour le développement par aspect.
Dans le cadre de notre travail, nous favorisons le traitement précoce des interactions, nous
concentrons sur l’identification des interactions et des conflits entre les aspects au niveau de
préoccupation.
En outre nous favorisons l’utilisation des systèmes multi agents pour l’identification précoce
des interactions entre les aspects dans les artefacts d’analyse des exigences qui permet un
traitement consistant et certain des interactions.
Le développement orienté agent (AOD) est un paradigme de programmation bien connu , qui
permet de développé des systèmes décidant eux-mêmes ce dont ils ont besoin pour atteindre
leurs objectifs, et pour atteindre certains de cette objectifs l'agent est capable d’accomplir des
actions autonomes. Ainsi, nous allons adopter le développement orienté agent pour une
identification des interactions autonomes afin de faire face à ce problème difficile.

Notre objectif est de proposé une nouvelle approche orienté agents d'identification des
interactions entre les aspects qui permet de libérer l'utilisateur qui saisi la spécification des
exigences orienté aspect, la spécification sera corrigé d'une manière précoce qui permet de
minimiser les erreurs de spécification. Dans notre approche nous concentrons sur
l’identification des conflits d’ordre et des conflits de type récursivité accidentelle.
Notre mémoire est organisé comme suit :
Le chapitre 1 (Le développement orienté aspects) : ce chapitre est consacré à présenter le
domaine du développement orienté aspects. D’abord, nous allons donner un aperçu général
sur le développement orienté aspects, ses concepts de base, puis nous présentons L’Ingénierie
des Exigences orientées Aspect nous allons donner une explication sur L’aspect dans
l’ingénierie des exigences orienté aspect et l'Objectif de l’ingénierie des exigences orientée
aspect, Et enfin, nous discutons sur Les approches d’ingénierie des exigences orientées aspect
et les avantages et les Inconvénients de ces approches.
Le chapitre 2 (Le problème d’interaction entre les aspects) : dans ce chapitre nous décrivons
l’état de l’art du problème d’interaction entre les aspects. Nous allons citer quelques
définitions d’interaction entre aspects et nous détaillons également un ensemble des
classifications d’interactions et conflits entre les aspects proposées dans des travaux de
recherche orientés aspects. Ensuite, nous proposons quelques exemples des interactions et
conflits.
Le chapitre 3 (Les systèmes multi-agents) : Dans ce chapitre nous allons donner un aperçu
général sur les systèmes multi-agents, ses concepts de base.
Le chapitre 4(approche proposé et contribution) : Ce chapitre est consacré à la présentation
de notre approche basé agent d’identification des interactions et conflits entre les aspects.
En premier pas, on commence par une description et objectifs de notre approche proposé,
puis ont présenté notre architecture multi agent dédié à l'identification des interactions entre
les aspects.
Le dernier chapitre, chapitre 5 (Conception et implémentation) : concerne l’étude
conceptuelle et l’implémentation de notre approche multi agents d’identification des
interactions entre les aspects.

Chapitre 01
Le Développement Orientée
Aspect

Chapitre 01 : Le développement Orientée Aspect
1. Introduction
Le développement Orientée Aspect est apparue pour résoudre le problème d'enchevêtrement
des fonctionnalités désirées dans une application, ce qui permet d'éviter l'entrelacement des
sous-problèmes techniques ou fonctionnels.
Le but de cette section est d'introduire le développement orientée aspect telle qu'elle a été
définie par Kicz.ales [Kiczales et al. 01]. Pour ce faire, nous commençons par une présentation
générale de cette paradigme, puis nous proposons un survol à l’ingénierie des exigences par
aspect, et nous parlons aussi sur Les approches d’ingénierie des exigences orientées Aspect
avec ces avantages et inconvénients.
2. le développement orienté Aspects
2.1 Définitions :
Definition1 : Le développement orienté aspect (AOSD) est un nouveau paradigme
de développement des logiciels qui complète et améliore les approches de développement
modernes actuels tel que les approches orientées objet et orienté composant. Il fournit des
nouvelles techniques avancées pour la structuration et modulation des programmes tout en
s’occupant des préoccupations transverses, qui par conséquent améliorent la qualité des
logiciels[1].
Definition2 : Le développement de logiciels orientés aspect (AOSD) est un
développement qui vise à traiter les préoccupations transversales par fournir les
moyens pour leur systématique identification, séparation, représentation et
composition. Les préoccupations transversales sont encapsulées dans des modules
séparés, nommés aspects, de sorte que leur localisation peut être améliorée. [2]
2.2 Pourquoi développement Orientée Aspect ?
Dans la programmation structurelle, procédurale et orienté-objet, l'implémentation des
besoins non-fonctionnels tels que la sécurité ou la gestion des transactions est dispersée sur
plusieurs modules.
Ce qui conduit à dupliquer des parties du code dans les différents modules fonctionnels du
système.
1

Autrement dit, les besoins non-fonctionnels ne bénéficient pas d'une encapsulation adéquate ni
au niveau des modèles de conception ni au niveau des langages de programmation. Cette
situation est désignée par l'entre coupage des préoccupations «crosscutting concern » ce qui
rend difficile la lecture du code source ainsi que sa maintenance. La programmation orienté
aspect tente de résoudre les problèmes des approches actuelles en séparant les préoccupations
d'une application moyennant des concepts spécifiques. [4]
Donc, le but d'une AOP est de séparer le code de programme lié aux buts principaux (la
préoccupation de noyau) du code lié aux buts secondaires (la préoccupation qui se recoupe).
[3]
Cette séparation des préoccupations ("separation of concerns") techniques des descriptions
métier dans une application a permis l'utilisation de l'aspect dans les travaux sur l'adaptation
logicielle en considérant l'aspect comme une unité d'adaptation. Ceci a permis de rendre les
adaptations indépendantes de l'application elle-même. C'est la propriété qui permet aux
programmeurs de prévoir des adaptations sans connaître de manière spécifique les applications
qui seront déployées. [5]
Figure 1.1 : Un système vu comme un ensemble de préoccupations.
2

2.3 Méthodologie du développement orienté aspects
Le développement de logiciels en utilisant l'approche orientée aspect est similaire au
développement de logiciels avec d'autres méthodologies : identification des préoccupations,
leur implémentation, et leur combinaison pour former le système final. La communauté des
chercheurs de l'AOP définit ces trois étapes comme suit :
2.3.1 Décomposition aspectuelle : Les besoins sont ici décomposés pour identifier les
préoccupations fonctionnelles et transversales. Par exemple, un développeur pourra identifier
les préoccupations suivantes : logique métier, logging, cache, gestion transactionnelle de la
persistance, authentification, etc. Ensuite, il pourra décider que seul le logique métier est une
préoccupation fonctionnelle. Toutes les autres préoccupations sont des préoccupations
transversales au système et qui Vont être utilisées par plusieurs modules.
2.3.2 Implémentation des préoccupations : Chaque préoccupation est implémentée
indépendamment des autres. Comme pour l'exemple du paragraphe précédent, le développeur
aura à implémenter le logique métier, le logging, le cache, la gestion transactionnelle de la
persistance, l'authentification, etc.
2.3.3 Recomposition aspectuelle : Des règles de recompositions sont spécifiées en créant des
unités appelées aspects. Le processus de recomposition, aussi connu sous le nom de tissage ou
d'intégration, utilise ces informations pour composer le système final. Comme pour l'exemple
précédent, le développeur peut créer une règle qui s'assure que chaque opération effectuée par
le logique métier doit d'abord être mise en journal (loggée). [6]
Figure 1.2 : Etapes de développement dans une méthodologie AOP.
3

3. Les concepts de base de la programmation orientée Aspect
Chaque nouveau paradigme de programmation propose un ensemble de nouveaux
concepts. La programmation procédurale apporte les notions de module, fonction et de
procédure. La programmation objet apporte les notions de classe et d’héritage, d’objet et de
méthode. A son tour, la programmation orientée aspect (POA) apporte aussi des nouveaux
concepts à savoir les concepts d’aspect, de point de jonction, de coupe et d’advice, qui seront
présentés, de manière indépendante de l’implémentation, dans les sections suivantes : [7].
3.1 Préoccupations : Une préoccupation est définie comme un intérêt relatif au développement
d'un système. Une préoccupation est alors soit une préoccupation non transversale qui peut être
liée à sa fonctionnalité appelée préoccupation de base, soit une préoccupation transversale, qui
peut être liée à des exigences non fonctionnelles appelée préoccupation d'aspect ou simplement
aspect. [7]
3.1.1 Préoccupation de Base : Une base est une unité de modularisation qui peut être
représentée dans un module de manière isolée en respectant une décomposition dominante.
Elle représente donc une préoccupation non transversale (fonctionnelle) qui peut être capturée
de manière efficace avec des approches traditionnelles telles que l'approche orientée Objet.
3.1.2 Préoccupation d'aspect : Un aspect est une unité de modularisation qui est entremêlée
avec les autres préoccupations, quelles soient de base ou d'aspect. Elle représente donc une
préoccupation transversale (non fonctionnelle) qui peut être capturée de manière efficace avec
l'approche orientée Aspect.
3.2 Point d’exécution (JoinPoint) : aussi appelé point de jonction, c'est un endroit
particulier où il est possible de greffer des aspects [8]. Potentiellement, ils peuvent être
de différents types (exemple : appel d'une méthode ou d'un constructeur, exécution
d'une méthode, accès aux attributs get et set, levés des exceptions...) [9]
3.3 Coupe (pointcut) : Selon [7] : une coupe désigne un ensemble de point de jonctions. Les
points de jonction et les coupes sont liés par leur définition, mais leur nature est très différente.
Un point de jonction représente un point dans l’exécution d’un programme, une coupe est un
morceau de code défini dans un aspect. Une coupe est définie à l’intérieur d’un aspect. Dans le
cas simples, une seule coupe suffit pour définir la structure transversale d’un aspect. Dans les
cas plus complexes, un aspect est associé à plusieurs coupes [10].
4

3.4 Code advice (advice code) : Un code advice est un bloc de code définissant le
comportement d'un aspect. Concrètement, un code advice est un bloc d'instruction qui spécifie
le comportement de l'aspect. Le code greffon joue en quelque sorte le même rôle qu’une
méthode. A la différence des méthodes, les greffons sont associés à une coupe, et donc à des
points de jonction, et ont un type qui détermine le moment de leur exécution (before, after,
arround).
Figure 1.3 : L’encapsulation des préoccupations transversales [11].
3.5 Mécanisme d’introduction : Le mécanisme d’introduction de la POA permet d’étendre
des classes par l’ajout des éléments. Ces éléments peuvent être des attributs ou des méthodes,
mais ce ne sont pas les seuls exemples [10]. L’introduction est donc un mécanisme purement
additif, qui ajoute de nouveaux éléments à une classe. Le mécanisme d’introduction est toujours
sans condition, l’extension est réalisée dans tous les cas [7].
3.6 Aspect : l'aspect est une entité qui ressemble à une classe mais modélise une
préoccupation qui entrecoupe plusieurs classes. Les aspects sont définis séparément et
plusieurs aspects peuvent exister dans un même système.
3.7 Tissage (weaving) : Le tissage (weaving) est le processus qui prend en entrée un ensemble
d'aspects et une application de base et fournit en sortie une application dont le comportement
et la structure sont étendus par les aspects. [8]
5

Figure 1.4 : La mise en œuvre du tissage des aspects [8].
Ils y a Deux types de tissage : [1]
Le tissage statique S’effectue à la compilation ou au chargement. Une fois un aspect tissé, il
est impossible de le retirer. Lors ce tissage, le code aspect est fusionné avec le code métier
soit pour donner un nouveau code source.
soit pour donner un pseudo-code intermédiaire.
Le tissage dynamique Permet de garder les aspects et le code applicatif complètement séparés.
Ainsi, l'exécution, les aspects peuvent être tissés, donc ajoutés au code ou retirés. Cela accroît
l’intérêt porté sur la POA pour le prototypage et le test rapides, car on n'a plus besoin de
recompiler, redéployer et relancer l'application.
4. L’Ingénierie des Exigences orientées Aspect
L’ingénierie des exigences (IE) est la première étape fondamentale de n’importe quel
projet de développement de système. Selon le GTIE (Groupe de Travail sur l’Ingénierie des
Exigences) de l’AFIS (Association Française de l‘Ingénierie des Systèmes) [12], l’IE désigne
l’ensemble des activités destinées à découvrir, analyser, valider et faire évoluer un ensemble
d’exigences relatives à un système. Elle permet de montrer la satisfaction des besoins et des
engagements durant tout le cycle de vie d’un système [13].
Les approches d’analyse des exigences orientées aspects sont des approches d’analyse
d’exigences qui explicitement reconnaissent l'importance d’identifier, traiter, raisonner sur des
préoccupations transversales/besoins durant la phase d'analyse des exigences [14].
6

4.1 L’aspect dans l’ingénierie des exigences orienté aspect
Un aspect au niveau des exigences est généralement une propriété de porté globale qui
contraint le système, représenté par une seule exigence ou un ensemble cohérent d’exigences,
telles que les exigences de sécurité, temps de réponse, confidentialité...ect. Ces propriétés
touchent plusieurs autres exigences, dans le système de sorte que :
Ils contraignent le comportement des exigences influencées.
Ils influent sur les exigences concernées, afin de modifier leur comportement.
4.2 Objectif de l’ingénierie des exigences orientée aspect
• AORE fournit un moyen systématique pour l'identification, la modulation, la représentation
et la composition de tous les besoins fonctionnels, non fonctionnels et transversales durant
toute l'ingénierie des exigences [14].
• L’AORE permet de prévoir une égalité de traitement des préoccupations fonctionnelles et
non fonctionnelles [23]. Des approches orientées aspect propagent l'idée que tous les types de
préoccupations sont aussi importants et doivent être traitées de manière cohérente et non
discriminative [15].
• L’un des insuffisances à traiter par AORE est celle de l'absence du mécanisme de composition
des exigences. La composabilité est le fait de combiner les exigences individuelles avec
d’autres exigences, elle permet d'examiner les exigences dans leur intégralité, et de détecter
des conflits potentiels très tôt pour prendre des mesures correctives ou de prendre des décisions
appropriées pour la prochaine étape [14].
4.3 Les approches d’ingénierie des exigences orientées Aspect
L’utilisation du paradigme aspect dans la phase d’implémentation du cycle de développement
des applications logicielles apporte des solutions aux difficultés du paradigme de l’objet qui
sont la dispersion et l’enchevêtrement du code.
Mais l’utilisation du paradigme aspect, lors des premières phases du cycle de développement,
n’a pas atteint encore un stade de maturité suffisant pour faire face à la complexité des
applications. Beaucoup de travaux sont en cours notamment dans la phase de l’IE.
7

Les techniques d’IE qui reconnaissent de manière explicite l’importance accordée au même
titre pour les préoccupations transversales fonctionnelles et non-fonctionnelles ainsi que pour
celles de base (non transversales) sont qualifiées d’approches d’IE orientées aspect (Aspect
Oriented Requirements Engineering : AORE).
Les trois facteurs suivants sont à l’origine de l’émergence de ces approches [Kiczales et al.,
1997].
– Le facteur de composition : l’intégration (assemblage) des exigences séparées.
– Le facteur de traçabilité : suivi des propriétés transversales durant le cycle de vie.
– Le facteur de l’émergence de la programmation orientée aspect (POA).
4.4 Les avantages et les inconvénients des approches d’ingénierie des exigences orientées
Aspect
Avantages :
 Réduit la complexité.
 Met en valeur la compréhensibilité et la traçabilité à travers tout le processus de
développement.
 Permet l’encapsulation des préoccupations et des besoins non fonctionnelles (besoins
de qualité).
 Elle bénéficie des avantages des préoccupations Crosscutting.
 Elle fournit de bons moyens d’identification, séparation, représentation et composition
des préoccupations dans des étapes plus tôt dans le processus de développement.
 Permet une bonne maîtrise des situations conflictuelles.
Inconvénients :
 Son support logiciel est plutôt maigre.
 Le langage de définitions des règles de composition est incomplet.
 Les méthodes proposées ne suivent pas un chemin purement systématique.
 Les méthodes proposées ne prennent pas en considérations toutes les situations
conflictuelles émergentes.
 Les études sur le domaine, et l’influence du paradigme d’aspect sur le cycle de vie sont
maigres.
8

5. Conclusion
Dans ce chapitre, nous avons fait un survol général sur le développement orienté aspect.
Après avoir expliqué les problèmes auxquels l'AOP apporte des solutions efficaces, nous avons
abordé les principaux concepts de ce paradigme. Ensuite, nous avons présenté l’Ingénierie des
Exigences orientées Aspect Et en terminant dans la section des approches d’Ingénierie des
Exigences orientées Aspect avec ces avantages et inconvénients.
Dans le chapitre suivant, nous essayons de décrire l’état de l’art du problème d’interaction entre
les aspects.
9

Chapitre 02
Le problème d’interaction
Entre les aspects

1. Introduction
L’approche orientée aspect apporte des mécanismes simples à appréhender et puissants
qui permettent de séparer entre les préoccupations transversales et les préoccupations métiers.
Cependant, la complexité des interactions entre les aspects et les modules de bases peut réduire
la valeur de la séparation par aspects. Dans ce chapitre, nous commençons tout d’abord par
quelques définitions d’interaction entre aspects. Ensuite, nous détaillons également un
ensemble des classifications interactions et conflits entre les aspects proposées dans des travaux
de recherche orientés aspects. Enfin, nous terminons par quelques exemples des interactions et
conflits entre les aspects.
2. Définition d’interaction entre aspects
Il existe de nombreuses et différentes définitions d’interaction entre aspects aussi
connues par problème d’interférence et par conséquent différentes approches permettent leur
traitement. En ce qui suit, nous citons quelques définitions, telles que décrites dans [16] :
Definition1 : Un type d'interférence peut survenir lorsque un point de jonction correspond à
plusieurs aspects et l'ordre d’exécutions des advices influe le résultat, la possibilité qu’un
comportement imprévisible des aspects peut survenir [16].
Definition2 : Un autre type d'interférence entre les aspects est lorsque, suite au tissage d'un
aspect, l'ensemble des points de jonction qui correspond à un autre aspect change, de nouveaux
points de jonction sont ajoutés ou supprimés par l'aspect qui a été tissé [16].
Définition 3 : les aspects interfèrent ensemble lorsque les mêmes variables modifiées par un
aspect influencent le comportement d'un autre aspect. Un cas possible de cette influence est si
des variables communes sont accédés ou modifiés par deux aspects [16].
Definition4 : contrairement à la définition 3, les aspects interfèrent ensemble bien que Les
aspects n'ont pas à partager des variables. Une influence indirecte peut se manifester aussi,
lorsque une variable modifiée par un aspect peut influer la valeur des variables de la base, en
conséquence, pourrait influer des variables ou le flux de contrôle d’un autre aspect [16].
Définition 5 : une interférence entre les aspects peut survenir lorsque les
aspects ajoutent des attributs ou des méthodes aux classes du système et ces introductions sont
contradictoires. Ils peuvent provoquer un comportement ambigu (le comportement du système
dépend de l'ordre de compilation), un changement non attendue d’implémentation de certaines
10

méthodes héritées, conflits de type et de nom peuvent apparaître ou un échec dans la
compilation du système tissé [16].
Définition 6 : Les interférences entre aspect peuvent également surgir si un aspect invalide le
résultat attendu d’un autre aspect, bien que chacun des aspects une fois tissé seul, il soit correct
par rapport à sa spécification. Une telle interférence peut être décrite comme une contradiction
entre les spécifications des deux aspects [16].
3. Classification des interactions et conflits entre les aspects
Il y a peu de travaux qui couvrent de manière explicite le problème d'interaction entre les
aspects, y compris l'un de ceux qui donnent des classifications de ces interactions. Dans cette
section, nous donnerons quelques classifications tel que proposé dans ce domaine de recherche
et quelques classifications qui ont été incluses dans le travail de base sur lequel nous travaillons
où l'étudiant a présenté quelques classifications.
Classification 1 :
Dans [17] et [18], nous proposons une classification des interactions au niveau du code
à partir les modifications de variables par des aspects.
 Indépendant : les deux aspects n’interagissent pas.
 Flot de contrôles dépendant : la présence d’un aspect crée un nouveau flot de contrôle
qui conduit à l’application d’un autre aspect.
 Flot de données dépendant : un aspect change les valeurs des variables utilisées par
l’autre aspect.
 Co-dépendant : les aspects s’influencent mutuellement, à la fois par leur flot de
données, et par leur flot de contrôle.
Classification 2 :
Dans [20] et [18], une classification des conflits entre aspects est proposée. Les
interactions décrites par BUSSARD et al. [19], concernent les greffons HAVINGA et al. [18]
s’intéressent aux interactions liées aux modifications structurelles introduites par les aspects.
Trois classes de conflits ressortent de ces travaux.
 Les conflits inhérents : liés à l’incompatibilité de deux aspects.
 Les conflits structurels accidentels : lorsqu’un aspect capture accidentellement une
introduction fais par un autre aspect (problème de visibilité) ou lorsqu’un aspect ne
11

capture pas une introduction qui a dû être réalisée par un autre aspect (problème
d’ordre).
 Les conflits comportementaux accidentels : lorsque deux aspects s’appliquent à un
même point d’un programme où ils ont des conflits sémantiques.
Classification 3 :
Aussi dans [21], les auteurs proposent une classification des interactions structurelles :
 Interactions avec le code de base : Un aspect ajoute un élément structurel déjà présent
dans le code de base.
Exemple :
 Ajoutez une classe C mais C existe déjà.
 Ajouter la méthode m à la classe C qui a déjà cette méthode (soit directement ou par
héritage).
 Interactions entre les actions : Deux aspects ajoutent un élément avec la même
signature dans le même conteneur structurel.
Exemple :
 Les aspects A1 et A2 ajoutent une classe C.
 Les aspects A1 et A2 ajoutent une méthode m à la classe C (directement ou
via l'héritage).
 Interactions Action-Couper :
Un aspect ajoute un élément qui appartient à la coupe intensionnelle d'un autre aspect.
Exemple :
 L'aspect A1 ajoute une classe C au package p, et l'aspect A2 ajoute une méthode m à
toutes les classes de p.
 L'aspect A1 ajoute une annotation à tous les champs de la classe C, et l'aspect A2 ajoute
un champ à la classe C.
Classification 4 :
Dans [19], nous proposons une classification des interactions aux points de jonction
partagés ;
À l’arrivée à un point de jonction partagé les aspects sont exécutés de manière séquentielle.
Des effets de bord se produisent alors en raison d’accès en lecture / écriture aux données
partagées (interaction de flot de données) ou en raison d’actions affectant le passage du flot
12

de contrôle d’un greffon à un autre ou d’un greffon au code de base (interaction de flot de
contrôles).
Afin de définir les interactions de flot de données et de contrôle nous définissons au préalable
les données manipulées par un aspect.
Classification 5 :
Cette classification en dite quelque classifications des interactions ile présenté à leur
travail de base sur lequel nous travaillons :
Classification a :
Aussi dans [22], les auteurs proposent une classification d'aspect basé sur leur
incidence sur le code de base. Pour cette classification nous apercevons au premier lieu trois
grands groupes d'aspects :
 Aspects comportementaux purs, qui interviennent seulement dans le flux de contrôle
protégé du code de base.
 Aspects de données pures, qui ne manipulent des structures de données protégés du
code de base.
 Aspects hybrides, qui non seulement interviennent dans le flux de contrôle protégé du
code de base, mais aussi de manipuler ses structures de données protégées.
Comme la première classification, cette classification peut servir à comprendre
comment les aspects se comportent avec les modules de base, mais il n’est pas assez
riche pour modéliser des interactions aspect-aspect.
Classification b :
Comme plus complète que les classifications précédentes, il y a un autre qui
contient des types plus détaillés. Selon [22], on peut distinguer quatre principales catégories
d'interactions :
 Spécifications transverses : l’utilisation actuelle des points de jonction pour la
spécification des aspects et leurs localisations où ils doivent être insérés, peut conduire
à deux problèmes : les points de jonctions accidentelles et la récursivité accidentelle.
Le premier problème capture les cas où accidentellement le comportement des aspects
est inséré à des mauvaises et indésirables localisations (point de jonction). Cela peut se
produire par exemple lors de l'utilisation des wildcards dans AspectJ, cependant, la
13

récursivité accidentelle se réfère à la situation lorsque le comportement de l’aspect lui-
même correspond à une spécification de point de jonction conduisant à la récursivité.
 Conflits aspect-aspect : aussi appelé interaction des aspects, ce genre de problème se
produit lorsque plusieurs aspects co-existent dans un système. Les aspects dans ce cas
peuvent être en conflit, et on identifie ici cinq types d’interaction :
 L’exécution conditionnelle : où l’application d’un aspect dépend d'un autre aspect
qui doit être appliqué pour son bon fonctionnement.
 Exclusion mutuelle : c’est le cas où la composition d’un aspect implique qu'un autre
ne doit pas être composé.
 Conflit d’ordre : lorsque les aspects influencent le même point de jonction dans la
préoccupation de base.
 Conflit d’ordre dépendant du contexte dynamique : la différence avec le type précèdent
consiste que l’ordre des aspects dépend de l'état dynamique du système et du contexte
dans lequel les aspects soient appliqués.
 Négociation des conflits au niveau d’exigences et d’architecture (traddoff) : ce type de
conflit se produit lorsque des aspects affectant un même élément pouvant compromettre
les besoins et la spécification des uns aux autres.
 Conflits de type base-aspect : ces types de conflits surviennent lorsque la base se
réfère explicitement ou dépendent du comportement d’aspect.
 Conflits de type préoccupation : ce genre de conflit entre les préoccupations se
produit
lorsque des préoccupations affectent l'exécution ou l'état des autres préoccupations
Classification c :
Les classifications précédentes sont trop orientées vers les programmes d'aspect
(trop détaillé). Cependant, cette classification est plus générale et abstraite. Selon [22], ce
problème de l'interaction se produit lorsque plusieurs aspects coexistent dans un système. Les
aspects peuvent interagir de multiples façons. Les auteurs distinguent quatre types différents
d'interactions d'aspect :
14

 Exclusion mutuelle : encapsule l'interaction de l'exclusivisme mutuel. Par exemple,
s'il y a deux aspects qui implémentent des politiques similaires, ou des algorithmes, la
situation peut survenir où un seul de ces aspects doit être utilisé.
 Dépendance : couvre la situation dans laquelle un aspect a besoin explicitement un
autre aspect et dépend donc sur lui.
 Renforcement : survient quand un aspect influe sur le bon fonctionnement d'un autre
aspect positif et renforce donc sur lui.
 Conflit : capture la situation d'interférence sémantique : un aspect qui fonctionne
correctement dans l'isolement ne fonctionne plus correctement quand il est composé
avec d'autres aspects.
4. Exemples des interactions et conflits entre les aspects
Un exemple typique d'une interaction est lié à l’ordre de tissage. On considère l'exemple
de la figure 2.1 tiré de [23], où l'aspect Counter compte les accès aux attributs. Cet aspect
capture l’exécution des setters (ligne 3) et incrémente l’attribut counter introduit comme un
nouveau variable dans la classe Point (ligne 2). L’aspect Counter peut être appliqué dans la
classe Point (lignes 8 à 13). Maintenant, on considère les aspects ThreeD (lignes 15 à 18) et
Color (lignes 20 à 23). Ces deux aspects aussi introduisent des nouveaux variables dans la
classe Point et leur setter correspondants. Le but d’appliquer ces trois aspects (tisser) dans le
code de la classe Point est indéterminé. En conséquence, les différents ordres de tissage
conduisent à des programmes ayant des comportements différents, puisque les nouveaux
membres introduits par les aspects ThreeD et la Color peuvent ou ne peuvent pas être comptés.
15

Figure 2.1 : Exemple d’interaction d’aspect : ordre de tissage [9].
Comme pris dans [24], la figure2.2 représente un exemple d’AOSD. Dans la figure, une classe
abstraite A contenant une méthode m (..), est prolongée par les classes B, C et D avec un aspect
ciblant toutes les occurrences de la méthode m (..).
Figure 2.2 : Aspect appliqué à trois classes différentes [24].
Si le code de base ne change pas, l'aspect se peut comporter comme prévu. Mais, ce qui arrive
quand une nouvelle classe E étendant A. L'aspect sera également applicable à la méthode m
(..) dans E, peu importe si elle est nécessaire ou non. Dans le pire des cas, la classe E n'a pas
besoin de l'application d'aspect et il va conduire à un comportement incorrect (Figure 2.3).
Dans ce cas, le motif correspondant sur les noms permet aux développeurs de faire abstraction
16

sur la syntaxe, et d'éviter ainsi l'énumération des points de jonction. Cela offre une certaine
souplesse, mais dans certaines situations, il ne suffit pas. Toutefois, si le logiciel est assez petit,
aspect et le code de base des changements seront faciles à coordonner au besoin. Dans les
projets du monde réel, la taille et la complexité augmentent très rapide en rendant la gestion
des aspects délicate et sujette aux erreurs.
Figure 2.3 : Aspect appliqué à une classe qui n'a pas besoin [24]
5. Comment traiter le problème d'interaction entre les aspects ?
5.1 Le cycle de vie des aspects (les aspects précoces dans le cadre d’AOSD)
Apparemment, les approches existantes du développement logiciel orientées aspects ont
essentiellement focalisé sur la spécification des aspects au niveau de la programmation et moins
d'attention ont été prises sur l'impact des aspects au niveau de la conception de l'architecture.
Cependant, dans toutes les phases du cycle de vie du développement logiciel que nous avons à
faire face à des modules et des préoccupations [25].
17

Figure 2.4 : Mapping des préoccupations vers des modules dans le cycle de vie [25].
Ainsi, les aspects sont classés aux : aspects précoces, aspects intermédiaires, et aspects tardifs
(voir la figure 2.5). Les aspects dans les phases précoces du cycle de vie sont les aspects
précoces qualifiés pour distinguer les aspects au niveau d’implémentation (aspects tardifs). Ils
se concentrent sur les aspects à un haut niveau d'abstraction au niveau de la programmation ou
même à la conception des programmes. Cependant, les aspects au cours de l'analyse de
conception sont des aspects intermédiaires [25].
Figure 2.5 : Le cycle de vie des aspects [16].
18

Certainement, il est favorable d’identifier les aspects précoces dans le processus de
développement au cours des étapes précoces du développement logiciel, d’analyse des besoins,
d’analyse de domaine et de la phase de conception d'architecture, il améliore le développement
orienté aspects. L'influence des aspects précoces du cycle de développement du logiciel
survient par deux manières :
 Les aspects précoces influent les aspects dans les phases tardifs. De nombreux aspects
précoces identifiés dans les phases précoces seront passés à travers les autres phases.
 En outre, d'autres aspects précoces pourraient être spécifiques à des étapes précoces, et
couper à travers les modules spécifiques dans les phases précoces.
 De même, il se pourrait bien que les nouveaux aspects non identifiés apparaissent
précédemment alors que nous progressons dans le cycle de vie du logiciel [16].
En outre, il apparaît que certaines préoccupations aux phases précoces du cycle de vie ne
peuvent pas être mappés à des unités modulaires uniques, mais elles ont tendance à recoupées
sur plusieurs modules. Les aspects au cours des phases précoces du cycle de vie ont été appelés
les aspects précoces pour les distinguer des aspects au niveau du code. Les modules peuvent
être par exemple des exigences, cas d'utilisation, des composants architecturaux, des
diagrammes d'interaction, etc. Nous soutenons que les aspects devraient être identifiés tôt dans
le cycle de vie du développement de logiciels, ce qui est, au cours de l'analyse des besoins,
analyse de domaine et des phases de conception de l'architecture.
Figure 2.6 : Les aspects précoces [25].
19

5.2 Approches pour traiter le problème d'interaction entre les aspects dans le cycle de
vie
Actuellement, ce problème est traité par deux axes distincts :
5.2.1 Les approches de test et de vérification formelle
Des approches de test et de vérification formelles ont été proposées pour des programmes
orientés aspects, ces approches tardives reposent sur une spécification opérationnelle complète
(programme) et généralement elles sont classées à des approches basées sur le modèle
Checking , d’analyse statique, et le tranchage (slicing) [1].
5.2.2 Approches des aspects précoces
Des approches d’aspects précoces telles que d’ingénierie d’exigence par aspect qui proclament
l’avantage du traitement précoce des aspects pour le développement par aspect. Et elles
proclament l’avantage de traiter tôt les interactions et les conflits entre les aspects pour tous les
processus de développement [16].
6. Conclusion
Dans ce chapitre, nous avons étudié en détail le problème d’interaction entre les aspects :
nous citons les définitions et les classifications les plus répandus de l’interaction entre les
aspects dans des travaux de recherche orientés aspects, ainsi que nous avons proposé quelques
exemples des interactions et conflits. Nous clôturons ce chapitre par les approches actuelles
pour traiter ce problème.
Dans le chapitre suivant nous présenterons notre paradigme de développement : Les Systèmes
multi-agents qui nous utilisons pour traiter le problème d’interaction entre les aspects.
20

Chapitre 03
Les Systèmes multi-agents

1. Introduction
Les systèmes multi-agents C'est une discipline qui s'intéresse aux comportements
collectifs produits par les interactions de plusieurs entités autonomes et flexibles appelées
agents, Les SMA sont particulièrement adaptés pour proposer des solutions réactives et
robustes à des problèmes complexes pour lesquels il n'existe pas de contrôle centralisé. Dans
ce cadre, nous utilisons les systèmes multi-agents pour traiter le problème de la complexité
d'interaction entre les aspects qui présente dans le chapitre précédent.
Dans ce chapitre introduit, tout d'abord, un premier temps étudié en détail l'approche voyelles
(AEIO) de Demazeau [31]. L'approche (A, E, I, O) utilise 4 dimensions pour analyser et
concevoir un SMA : Agent, Environnement, Interaction, Organisation, et enfin étudié les
Plateformes utilisé pour le développement des systèmes multi agents.
2. Systèmes multi-agents
Les Systèmes multi-agent sont apparus au carrefour des recherches sur l’IAD
(l'Intelligence Artificielle Distribuée) et sur la vie artificielle. Les SMA sont particulièrement
adaptés pour proposer des solutions réactives et robustes à des problèmes complexes pour
lesquels il n'existe pas de contrôle centralisé [31]. En effet, un SMA est un regroupement
d'agent où chaque agent possédant une ou plusieurs compétences élémentaires. Le but est de
faire travailler ensemble les agents pour résoudre un problème ou effectuer une tâche
spécifique. En quelque sorte, on distribue l'intelligence, chaque agent autonome n'ayant qu'une
vision locale du problème ou une tâche élémentaire d'un travail à effectuer.
2.1 Définition :
Ferber [32] définit un SMA de la manière suivante :
1. Un environnement E, c’est-à-dire un espace disposant généralement d’une métrique.
2. Un ensemble d’objets O situé dans E. Ces objets sont passifs, c’est-à-dire qu’ils peuvent
être perçus, créés, détruits et modifiés par les agents.
3. Un ensemble A d’agents, qui représentent les entités actives du système.
4. Un ensemble de relations R qui unissent des objets (et donc des agents) entre eux.
5. Un ensemble d’opérations Op permettant aux agents de A de percevoir, produire,
consommer, transformer et manipuler des objets de O.
21

6. Des opérateurs chargés de représenter l’application de ces opérations et la réaction de
l’environnement envers les tentatives de modification
Figure 3.1 : Architecture d’un SMA.
2.2 Quand et Pourquoi opter pour les SMA
Les SMA sont utilisés en général lorsque le problème est trop complexe pour être résolu
par un seul système à cause de quelques limitations logicielles ou matérielles. En particulier,
si les composantes entretiennent des relations multiples entre elles. Les SMA représentent un
excellent outil pour assurer un contrôle autonome dans un système largement distribué et dont
les caractéristiques sont très dynamiques.
Pour qu'un SMA soit efficace, il faut que plusieurs agents travaillent en même temps,
ce qui réduit le temps de résolution vu la vitesse utilisée qui est due principalement au
parallélisme.
22

3. La notion d’agent :
3.1 La définition d’un agent :
Un agent est une entité logicielle ou physique à qui est attribuée une certaine mission
qu’elle est capable d’accomplir de manière autonome et en coopération avec d’autres agents.
[26]
D’après (Ferber, 1995) ,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 .[27]
M.Wooldridge propose la définition suivante : un agent est un programme
informatique qui est situé dans un environnement et qui est doté de comportements autonomes
(action) lui permettant d’atteindre, dans cet environnement, les objectifs qui lui ont été fixé à
sa conception. [28]
3.2 Caractéristiques des agents :
Situé : l'agent est capable d'agir sur son environnement à partir des entrées
sensorielles Qu’il reçoit de ce même environnement.
Autonome : 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.
Proactif : l'agent doit exhiber un comportement proactif et opportuniste, tout en
étant Capable de prendre l'initiative au bon moment ; capable de répondre à temps –
l'agent doit Être capable de percevoir son environnement et d'élaborer une réponse dans
le temps Requis.
Social : l'agent doit entrer capable d'interagir avec des autres agents (logiciels ou
humains) afin d'accomplir des taches ou aider ces agents à accomplir les leurs. [27]
23

3.3 Les différentes catégories des agents :
Généralement il existe deux catégories d’agent et la troisième c’est la combinaison entre ces
deux types :
3.3.1 Agents réactifs :
Les agents réactifs ont un comportement du type « stimulus – réponse ». L'agent
réactif ne possède pas une représentation complète de son environnement et n'est pas capable
de tenir compte de ses actions passées. De ce fait, un agent réactif est extrêmement simple. Il
dispose d'un processus de raisonnement procédural, d'un protocole et d'un langage de
communication réduit [33].
Les agents réactifs ne sont pas "intelligents" pris individuellement. Cependant, du fait, de
leur nombre, ces agents réactifs peuvent résoudre des problèmes qualifiés de complexes. Les
systèmes multi-agents constitués uniquement d'agents réactifs possèdent un grand nombre
d'agents. La convergence du comportement de l'ensemble des agents vers un état décisionnel
stable n'est pas forcément assurée, et si un état stable est atteint, il n'est pas sur qu'il s'agisse
de la solution optimale.
3.3.2 Agents cognitifs :
Les agents cognitifs sont plus évolués. Ils sont le résultat direct des recherches
menées dans le domaine de l'intelligence artificielle. Les agents cognitifs ont une
représentation globale de leur environnement et des autres agents avec lesquels ils
communiquent. Ils savent tenir compte de leur passé et s'organisent autour d'un mode social
d'organisation.
Les agents cognitifs disposent d'une base de connaissances comprenant les diverses
informations liées à leurs domaines d'expertise et à la gestion des interactions avec les autres
agents et leur environnement. Les agents sont généralement "intentionnels" c'est à dire qu'ils
possèdent des buts et des plans explicites leur permettant d'accomplir leurs buts [30].
Les systèmes multi-agents constitués uniquement d'agents cognitifs sont constitués d'un
nombre d'agents assez faible. Ils réclament des ressources plus importantes que les systèmes
d'agents réactifs.
24

Le tableau 2 ci-dessous établit la différence entre les agents cognitifs et les agents réactifs.
La liste des caractéristiques n'est pas exhaustive .[33]
Tableau 3.1 : Comparatif entre agent cognitif et agent réactif.
3.3.3 Agents hybrides
Il existe des problèmes où ni une architecture complètement réactive, ni complètement
Délibérative n’est appropriée.
Les agents doivent réagir très rapidement dans certaines situations, tandis que
dans D’autres, ils doivent avoir un comportement peu réfléchi.
Une architecture conciliant à la fois des aspects réactifs et délibératifs est requise.
L’architecture hybride est composée de plusieurs couches logicielles arrangées de
Manière hiérarchique.
Les différents niveaux de la hiérarchie traitent les informations provenant de
L’environnement à différents niveaux d’abstractions.
Les couches doivent interagir ensemble pour produire le comportement global de
L’agent. [32]
25

4. Environnement
Un agent ne peut exister sans environnement. L'environnement est une structure dans
laquelle l'agent évolue. Un agent va agir sur son environnement et l'environnement va agir sur
l'agent.
L'environnement est un élément important dans le processus dynamique d'un système
multi agents. C'est la fusion entre le contexte de déploiement (entités externes et ressources
avec lesquelles le SMA interagit) et l'environnement d'application.
Un environnement peut être vu comme un état e parmi un ensemble d'états E= {e1, e2, …,
en}.
L'agent perçoit son environnement à l'aide des capteurs, choisit la ou les actions à faire
selon sa fonction interne et exécute ces actions dans l'environnement à l'aide de ses effecteurs.
Les propriétés de l'environnement influencent la façon dont on conçoit un agent car il
faut tenir compte de l'évolution de l'environnement, de la capacité de l'agent de saisir cette
évolution et de sa capacité à décider en conséquence. Par exemple, si on a plusieurs agents qui
agissent dans un même environnement, chaque agent va percevoir l'environnement comme
dynamique et non déterministe, car l'état de l'environnement changera en raison des actions des
autres agents, et une même action exécutée dans un certain état aura des résultats différents en
fonction des actions de ces autres agents.
5. Interactions entre agents
L'interaction est le composant de base de toute organisation, à la fois source et produit de
la permanence de cette organisation, et la dissolution d'une organisation est concomitante de la
disparition (ou en tout cas de la diminution) des interactions des individus présents dans cette
organisation.
Une des principales propriétés de l'agent dans un SMA est celle d'interagir avec les autres
agents. Ces interactions sont généralement définies comme toute forme d'action exécutée au
sein du système d'agents et qui a pour effet de modifier le comportement d'un autre agent.
26

Une interaction est une mise en relation dynamique de deux ou plusieurs agents par le biais
d'un ensemble d'actions réciproques. Les interactions s'expriment ainsi à partir d'une série
d'actions dont les conséquences exercent en retour une influence sur le comportement futur des
agents [30].
L'interaction peut être décomposée en trois phases non nécessairement séquentielles :
La réception d'information ou la perception d'un changement.
Le raisonnement sur les autres agents à partir des informations acquises.
Une émission de messages ou plusieurs actions (plan d'actions) modifiant
L'environnement. Après avoir considéré les interactions vis-à-vis de l'environnement.
il reste aux agents la possibilité de communiquer entre eux. Il peut y avoir plusieurs objectifs
liés aux actes de communication entre agents. Les interactions inter-agents et la manière dont
celles-ci sont organisées permettent aux agents de se coordonner, de coopérer ou encore de
négocier. La coordination est un point essentiel, surtout vis-à-vis d'une implémentation
informatique du modèle multi-agents.
Les types courants d'interaction incluent la coopération (travailler ensemble à la résolution
d'un but commun); la coordination (organiser la résolution d'un problème de telle sorte que
les interactions nuisibles soient évitées ou que les interactions bénéfiques soient exploitées);
et la négociation (parvenir à un accord acceptable pour toutes les parties concernées).
5.1 Coopération entre agents
S'ils sont en coopération, alors le but des agents n'est plus seulement de maximiser sa
propre satisfaction mais aussi de contribuer à la réussite du groupe. Les agents travaillent
ensemble à la résolution d'un problème commun.
On peut considérer la coopération comme une attitude adoptée par les agents qui décident
de travailler ensemble ou on peut adopter le point de vue d'un observateur extérieur au SMA
qui interprète a posteriori les comportements des agents pour les qualifier de coopératifs ou
non suivant des critères préétablis tels que l'interdépendance des actions ou le nombre de
communications effectuées [30].
27

5.2 Coordination entre agents
La coordination est une question centrale pour les SMA et la résolution de systèmes
distribués. En effet, sans coordination un groupe d'agents peut dégénérer rapidement en une
collection chaotique d'individus. On pourrait penser que la façon la plus simple d'assurer un
comportement cohérent du groupe d'agents serait de le faire par un agent centralisateur qu
détiendrait des informations de haut niveau sur ces agents. Ainsi, l'agent centralisateur pourrait
créer des plans d'action et assigner les tâches aux divers agents du groupe. Cette approche est
pratiquement impossible à mettre en œuvre dans des applications réalistes en raison de la
difficulté de réaliser un tel agent centralisateur qui puisse tenir compte des buts, des
connaissances et des activités de chaque agent, sans compter qu'on perdrait les avantages d'un
SMA composé d'agents autonomes [35].
On distingue deux composantes fondamentales de la coordination entre agents, ce sont:
L'allocation de ressources rares: pour l'allocation des ressources partagées, les agents doivent
être capables de faire des transferts de ressources.
La communication de résultats intermédiaires : les agents doivent être capables de
communiquer entre eux de façons à pouvoir échanger les résultats intermédiaires.
5.3 Négociation entre agents
La négociation joue un rôle fondamental dans les activités de coopération en permettant
aux personnes de résoudre des conflits qui pourraient mettre en péril des comportements
coopératifs. En général les chercheurs en IAD utilisent la négociation comme un mécanisme
pour coordonner un groupe d'agents.
Dans le cas des SMA, la négociation est une composante de base de l'interaction surtout
parce que les agents sont autonomes; il n'y a pas de solution imposée à l'avance et les agents
doivent arriver à trouver des solutions dynamiquement, pendant qu'ils résolvent les problèmes.
Le choix du protocole de négociation est très important, surtout parce qu'un protocole ou
un autre peut imposer un certain comportement (préféré) aux agents. Le nombre de participants
et les interactions possibles peuvent varier: négociation un-à-un, négociation un-à-plusieurs,
négociation plusieurs-à-plusieurs.
28

5.4 Communication entre agents
Les agents peuvent interagir soit en accomplissant des actions linguistiques (en
communiquant entre eux), soit en accomplissant des actions non-linguistiques qui modifient
leur environnement. En communiquant, les agents peuvent échanger des informations et
coordonner leurs activités.
Pour qu'un agent puisse interagir avec d'autres agents et réagir à son environnement, il a
besoin de langage de communication entre agents. Pour que ceci soit possible, les agents ont
besoin d'un langage commun de communication qui, davantage est concerné par l'échange de
l'information que son contenu. Dans les systèmes multi-agents deux stratégies principales ont
été utilisées pour supporter la communication entre agents :
Envoi de message : les agents peuvent échanger des messages directement.
Partage de ressources : les agents peuvent accéder à une base de données partagée dans
laquelle les informations sont postées.
La communication : est généralement basée sur les 3 éléments suivants :
1. Protocole d'interaction : ceci se rapporte à la stratégie de niveau élevé poursuivi par les
agents logiciels qui interagissent avec d'autres agents.
2. Protocole de transport : c'est le mécanisme réel de transport utilisé pour la communication
en utilisant le langage de communication.
3. Langage de communication : c'est le medium par lequel les attitudes concernant le contenu
du message échangé sont communiquées.
a Protocole d'interaction entre agents : L'interaction entre agent exige un ensemble de
messages convenus, de règles pour des actions basées sur la réception de divers messages, et
d'acceptations des voies de transmission [36]. Ces contraintes, règles et modèles peuvent être
soustraits et formalisés comme AIP (Agent Interaction Protocol), qui font la base de la
négociation et de la coopération d'agents. En utilisant les protocoles, les comportements
autonomes des agents peuvent être de façon ou d'autre prévisibles.
L'AIP sont des modèles représentant les messages de communication et les contraintes
correspondantes sur le contenu de tels messages.
29

b Transport de messages : La communication entre agents est nécessaire aussi bien pour
échanger les données entre les agents que les connaissances. Pour cela, plusieurs moyens
existent : au niveau le plus bas, il existe des sockets qui permettent aux différents agents codés
en Java de communiquer entre eux ; il existe aussi d'autres technologies (en Java notamment).
On peut citer l'invocation de méthodes distantes (RMI pour Remote Method Invocation) et la
technologie CORBA (Common Request Broker Architecture).
c Langages de communication entre agents : L'ACL (Agent Communication Language) a été
créé pour assurer l'interopérabilité entre des agents autonomes et distribués. L'ACL a trois
composants : un vocabulaire, un langage de communication entre agent et un langage spécifiant
le contenu appelé KIF (Knowledge Interchange Format). Ci-dessous, une définition des deux
ACL les plus connus actuellement : KQML et FIPA-ACL.
KQML (Knowledge Query and Manipulation Language) est issu d'un projet de la DARPA
[12]. C'est un langage qui vise à définir un ensemble d'actes de langage qui soient standards et
utiles. Ces actes de langages, appelés aussi performatives, sont utilisés par les agents pour
échanger des informations. Un message est divisé en trois couches : La couche communication,
La couche message et la couche contenu. KQML fournit la couche linguistique pour rendre la
communication efficace en considérant le contexte des messages. Il a été conçu comme format
de message et comme protocole qui permet l'identification, le raccordement et l'échange de
l'information entre des programmes.
FIPA-ACL a été créé par l'organisme international FIPA (Foundation for Physical Intelligent
Agents) avec le but de créer un langage de communication agent standard. FIPA-ACL a
également été conçu pour pallier aux faiblesses des différentes versions de KQML. Tout
comme KQML, FIPA-ACL se base sur la théorie des actes du langage et la structure de ses
messages est similaire à celle des messages KQML. FIPA-ACL diffère de KQML en ce qu'il a
été directement doté d'une sémantique. En effet, la version originale de KQML ne décrivait que la
syntaxe de ses messages et rien n'était dit sur leur sens précis. Ce n'est que plus tard, qu'une
sémantique a été proposée pour KQML.
30

6. Organisation des agents
Une organisation est la façon dont le groupe est constitué pour pouvoir travailler.
L'organisation décrit l'ensemble des composants, leur nature, leurs responsabilités, leurs
besoins en ressource (processeurs) et leurs liens de communication ou d'arrangement. Nous
allons présenter ici les différents types d'organisation d'agents qui existent [38]:
Hiérarchies : les agents sont hiérarchisés selon la structure d'un arbre, dans lequel chaque
nœud représente un agent, et possède un lien d'autorité sur ses nœuds-fils. Ce modèle permet
de décomposer la tâche globale du système.
Holarchies : L'holarchie se rapproche de la hiérarchie, mais il existe quand même une
différence majeure. En effet, il n'y a pas de relation d'autorité entre un agent et son sous-groupe,
mais les agents du sous-groupe constituent "physiquement" leur sur-agent.
Coalitions : Une coalition est une alliance temporaire d'agents qui s'unissent et collaborent car
leurs intérêts individuels se rencontrent. La valeur de la coalition doit être supérieure à la
somme des valeurs individuelles des agents la composant.
Équipes : Les agents constituant l'équipe travaillent ensemble à la réalisation d'objectifs
communs. À la différence des agents d'une coalition, les agents d'une équipe cherchent à
maximiser les intérêts de l'équipe plutôt que leurs intérêts personnels.
Congrégations : Les congrégations sont assez similaires aux coalitions et aux équipes.
Cependant, elles sont destinées à être permanentes et ont généralement plusieurs objectifs à
réaliser. De plus, les agents peuvent entrer et sortir des congrégations, et appartenir à plusieurs
congrégations en même temps.
Sociétés : La société est un ensemble d'agents variés, qui interagissent et communiquent. Ils
possèdent différents objectifs, n'ont pas le même niveau de rationalité, ni les mêmes capacités,
mais sont tous soumis à des lois communes (normes).
Fédérations : Les agents d'une fédération cèdent une partie de leur autonomie au délégué de
leur groupe. Les agents d'un groupe n'interagissent qu'avec leur délégué, qui lui-même interagit
avec les délégués des autres groupes.
Marchés : Des agents vendeurs proposent des objets à la vente, sur lesquels des agents
acheteurs peuvent enchérir. Ce genre d'organisation permet, par exemple, de simuler des
marchés réels et/ou de comparer différentes stratégies de négociation.
31

Matrices : Les agents d'une organisation en matrices sont hiérarchisés. Cependant, à la
différence de la hiérarchie présentée plus haut, où un agent n'était soumis qu'à l'autorité d'au
plus un seul autre agent, les agents dans une organisation matricielle peuvent être soumis à
plusieurs autres agents.
Combinaisons : Une organisation combinée mélange plusieurs styles présentés ci-dessus (ou
d'autres qui auraient été oubliés dans cette liste). Cela peut être, par exemple, une fédération de
coalitions ou une hiérarchie d'équipes.
7. Plateformes pour les systèmes multi agents :
Il existe des plateformes qui permettent la prise en charge des fonctions de base d’un
simulateur multi-agents comme la communication, le cycle de vie des agents, la perception et
l’environnement. Parmi les plateformes les plus connus il y JADE, MACE, et MADKIT pour
les agents cognitifs, et SWARM pour les agents réactifs. Il faut noter que cette liste n'est pas
unique, et qu'il y a aussi d'autres plates-formes qui ont été utilisées avec beaucoup de succès
pour bâtir diverses applications.
7.1 MadKit : MADKIT [Gutknecht et Ferber, 2001] est une plate-forme développée par le
Laboratoire d'Informatique, de Robotique et de Microélectronique de Montpellier (LIRMM)
de l'Université Montpellier II. MADKIT est écrit en Java et est fondé sur le modèle
organisationnel ALAADIN. Il utilise un moteur d'exécution où chaque agent est construit en
partant d'un micro-noyau. Chaque agent a un rôle et peut appartenir à un groupe. Il y a un
environnement de développement graphique qui permet facilement la construction des
applications. [37]
7.2 Mace : MACE [Gasser et al. 1987] est le premier environnement de conception et
d'expérimentation de différentes architectures d'agents dans divers domaines d'application.
Dans MACE, un agent est un objet actif qui communique par envoi de messages. Les agents
existent dans un environnement qui regroupe tous les autres agents et toutes les autres entités
du système. Un agent peut effectuer trois types d'actions : changer son état interne, envoyer des
messages aux autres agents et envoyer des requêtes au noyau MACE pour contrôler les
événements internes. Chaque agent est doté d'un moteur qui représente la partie active de
l'agent. Ce moteur détermine l'activité de l'agent et la façon dont les messages sont interprétés.
MACE a été utilisé pour développer des simulations d'applications distribuées. [39]
32

7.3 Swarm : SWARM [Minar, 1996] est une plate-forme multi-agent avec agents réactifs.
L'inspiration du modèle d'agent utilisé vient de la vie artificielle. SWARM est l'outil privilégié
de la communauté américaine et des chercheurs en vie artificielle. L'environnement offre un
ensemble de bibliothèques qui permettent l'implémentation des systèmes multi-agent avec un
grand nombre d'agents simples qui interagissent dans le même environnement. [40]
7.4 Jade : JADE (Java Agent Development Framework) [Bellifemine , 1999] est une plate-
forme multi-agent développée en Java par CSELT (Groupe de recherche de Gruppo Telecom,
Italie) qui a comme but la construction des systèmes multi-agent et la réalisation d'applications
conformes à la norme FIPA [FIPA, 1997]. JADE comprend deux composantes de base : une
plate-forme agents compatible FIPA et un paquet logiciel pour le développement des agents
Java. [38]
5. Conclusion
Dans ce chapitre nous avons présenté une vision globale des agents et des systèmes multi-
agents. Ces systèmes c’est un réseau d’agents qui interagissent, communiquent et coopèrent
entre eux pour accomplir une mission bien précise, et nous avons décrit tous les éléments
constituant un système multi-agents en partant de l'agent à l'organisation en passant par
l'environnement et les interactions et enfin les Plateformes utilisé pour le développement des
systèmes multi agents.
Le chapitre suivant est consacré à présenter notre approche multi agents et contribution concernant le
traitement des interactions durant la phase d’analyse des exigences.
33

Chapitre 04
Approche proposée et
Contribution

Chapitre 04 : Approche proposée et Contribution
1. Introduction
Le développement orienté Aspect (AOSD) est un nouveau paradigme de développement
des logiciels qui fournir un concept clair pour l’encapsulation des préoccupations
transverses.au niveau modularité, par l’encapsulation des préoccupations transverses dans
une nouvelle unité modulaire nommée aspect. La séparation entre les aspects et les modules
de base, réduit les dépendances entre modules et améliore la modularité. Cependant, la
complexité et la diversité des interactions entre les aspects et entre les aspects et les modules
de base, peut réduire la valeur de l’approche par aspects. Alors, il est indispensable de
détecter et résoudre les interactions et conflits potentiels entre les aspects pour pouvoir les
composer correctement.
Actuellement, dans les travaux de recherche orientés aspect, le problème d’interaction entre
les aspects a été traité en deux axes distincts : Des Approches de test et de vérification
formelles, proposées pour des programmes orientés aspect, et des approches d’aspects
précoces tel que d’ingénierie des exigences par aspect qui proclament l’avantage du
traitement précoce des aspects pour le développement par aspect. Dans le cadre de notre
travail, nous avons choisi le traitement précoce des interactions entre les aspects.
Le développement orienté agent (AOD) est un nouveau paradigme de programmation, qui
permet de développé des systèmes décidant eux-mêmes ce dont ils ont besoin pour atteindre
leurs objectifs, et pour atteindre certains de cette objectifs l'agent est capable d’accomplir des
actions autonomes. Ainsi, nous adoptons le développement orienté agent pour une
identification des interactions autonomes afin de faire face à ce problème difficile.
Dans ce chapitre, nous allons proposer notre approche basé agent, En premier pas, nous
commençons par une description et objectifs de notre approche proposé, puis dans les étapes
suivant nous détaillons notre approche et nous allons présenter notre architecture multi agents
qui identifie les interactions entre les aspects. Nous allons présenter des détails sur la
structure et les fonctionnalités des différents agents de cette architecture.
34

2. Travail de base
Article : Un Framework d’identification précoce et multi-niveaux des interactions entre
les aspects durant la phase d'analyse des exigences
Selon [22] B.Amel, et B.Amine proposent une approche d'identification des interactions entre
les aspects, cette approche est un approche de traitement multi niveaux des interactions entre
les aspects durant la phase d’analyse des exigences et la contribution à la constitution d’un
processus de traitement multi-niveaux des interactions et conflits, Ce processus est illustré
par la figure 4.1. Il comporte quatre étapes, à savoir :
1. Définir des préoccupations, des bases et des aspects.
2. Identification des conflits récursifs accidentels : niveau 1 et niveau 2.
3. Identification des interactions : niveau 1 et niveau 2.
4. Identification des conflits d’ordre : niveau 1 et niveau 2.
35

Figure 4.1 : le processus global de l'approche de base.
À partir de ce travaille de base Nous allons proposer une approche basée multi agent. Nous
allons exprimer notre objectif et l'idée générale de l'approche proposée dans la section
suivante.
3. Description et objectif de notre approche basé agent
Essentiellement nos idées de la nouvelle approche basées agent est basé sur le processus de
l’approche ci-dessus. C’est est une nouvelle perspective sur ce processus en utilisant les
systèmes multi agents, et qui permet un bon soutient pour l’analyste pour identifier les
interactions le plutôt possible et qui lui permet de corriger sa spécification ou d’ajouter des
contraintes essentielle pour spécifier le bon comportement du système multi agent durant sa
spécification.
36

Notre solution consiste donc de deux système autonome qui travaillé complètement d'une
manière indépendant. Le premier système est le système de spécification et le deuxième est
le système de surveillance des interactions et de conflits entre les aspects. Le système de
surveillance surveille la spécification saisie par l'utilisateur, qui permet de libérer l'analyste de
se préoccuper sur les conflits entre les aspects et lui permettra de corriger sa spécification
d'une manière précoce durant la spécification cela va permettre de minimiser les erreurs de
spécification. La figure 4.2 montre l’idée globale de notre approche et comment ces deux
systèmes autonomes interagirent et travaillent ensemble :
Figure 4.2 : Schéma générale de l'approche proposée.
Basé sur le processus décrit dans la section précédant, dans le cadre de notre contribution,
nous concentrons sur l'identification de niveau 1 des conflits et des interactions dans la phase
d’analyse des exigences qui permet un traitement consistant et certain des interactions.
Nous concentrant sur la surveillance d’occurrence des problèmes suivants pour alerter
l’analyste :
- Identification des Conflits récursifs : niveau 1.
- Identification des Interaction : niveau 1.
- Identification des Conflits d'ordres : niveau 1.
4. Application Utilisateur (Système de Spécification)
Cette application ce concentre sur la spécification des exigences orienté aspect, l’analyste ici
se concentre à saisir ses aspects et ses préoccupations de base d’une manière à spécifier un
comportement cohérent de l’application orienté aspect. L’analyste est libérer de tout
traitement et d’identification des conflits dédié au deuxième system qui surveille et lui envoi
des alertes.
37

Une Approche Multi Agents D’identification Précoce Des Interactions Entre Les aspects

Une Approche Multi Agents D’identification Précoce Des Interactions Entre Les aspects

Recommandé

Recommandé

Contenu connexe

Tendances

Tendances (20)

Similaire à Une Approche Multi Agents D’identification Précoce Des Interactions Entre Les aspects

Similaire à Une Approche Multi Agents D’identification Précoce Des Interactions Entre Les aspects (20)

Une Approche Multi Agents D’identification Précoce Des Interactions Entre Les aspects