Upload
others
View
2
Download
0
Embed Size (px)
Citation preview
RÉPUBLIQUE ALGÉRIENNE DÉMOCRATIQUE ET POPULAIRE
MINISTÈRE DE L’ENSEIGNEMENT SUPÉRIEUR ET DE LA RECHERCHE SCIENTIFIQUE
UNIVERSITÉ LARBI BEN M’HIDI -OUM EL BOUAGHI
FACULTÉ DES SCIENCES EXACTES ET DES SCIENCES DE LA NATURE ET DE LA VIE
Département de Mathématiques et Informatique
MÉMOIRE PRÉSENTÉE EN VUE DE L’OBTENTION DU DIPLÔME DE MASTER
EN : INFORMATIQUE
OPTION : ARCHITECTURES DISTRIBUÉES
THÈME :
Vers une approche de maintenance
préventive des systèmes multi-agents
Présenté par :
GHORAB Mostafa AnouarSoutenue publiquement le : 06 Juillet 2019
ENCADRÉ PAR :
PR. MOKHATI FARID.
UNIVERSITÉ D’OUM EL BOUAGHI.
Devant le jury composé de :
DR.KOUAH SOFIA MCB UNIVERSITÉ D’OUM EL BOUAGHI PRÉSIDENT
MR.SEDAIRIA ABD-ALLAH MAA UNIVERSITÉ D’OUM EL BOUAGHI EXAMINATEUR
Remerciements
C’est avec un grand plaisir que je réserve cette page en signe de gratitude et de pro-
fonde reconnaissance à tous ceux qui ont bien voulu apporter l’assistance nécessaire au bon
déroulement de ce travail.
Avant toute chose ,Je tiens à remercier le bon Dieu de m’avoir accorde des connaissances,
de la science et de m’avoir aidé à réaliser ce travail.
Je profite de cette occasion pour adresser particulièrement mes vifs Remerciements a
mon encadreur Professeur MOKHATI Farid,pour toute l’attention qu’il m’a portée et son
soutien inconditionnel . Je suis sincèrement reconnaissant pour la confiance qu’il m’a témoi-
gné depuis le début et tout au long de ce projet , pour son encadrement, ses conseils et ses
orientations. J’espère avoir été digne de cette confiance.
Je remercie également Mme TORCHANE Nawel, Maitre-assistant.B à l’Université de
Tebessa pour son aide,ses conseils et ses encouragements pour la finalisation de ce travail.
Je remercie tous ceux qui ont, de près ou de loin, aidé à rendre ce travail possible, que ce
soit par des idées ou par des encouragements.
Résumé
Le paradigme agent ainsi que les techniques d’Assurance de la Qualité Logiciel (AQL)
constituent deux sujets qui attirent de plus en plus l’intérêt des chercheurs. Bien qu’il existe
plusieurs méthodologies de développement des systèmes multi-agents, ces dernières omettent
complètement l’activité de maintenance préventive de ce type d’applications.
Dans ce mémoire, nous proposons une approche de maintenance préventive des applica-
tions orientées agents en utilisant le paradigme Aspect. Notre approche consiste à mesurer
quelques métriques de qualité du programme en cours d’exécution d’une manière dynamique
et continue garce au code Aspect et les compare avec des seuils minimaux définis préalable-
ment par le concepteur de ce programme. En cas de dégradation anormale de la qualité une
alerte préventive sera lancée. Ensuite, le mainteneur intervient afin de préserver la qualité de
l’application et d’éviter ainsi les avaries potentielles.
Mot clés : Maintenance Préventive, Qualité Logicielle, Agents, JADE, Programmation Orien-
tée Aspect, AspectJ.
Abstract
The oriented-agent paradigm as well as the Software Quality Assurance (SQA) tech-
niques are two topics that are attracting more and more interest from researchers. Although
there are several methodologies for developing multi-agent systems, they completely omit
the preventive maintenance activity of this type of application.
In this desertation, we propose a preventive maintenance approach for agent-oriented
applications using the Aspect paradigm. Our approach consists in measuring some quality
metrics of the running program in a dynamic and continuous way to the Aspect code and
compares them with minimum thresholds previously defined by the designer of this program.
In case of abnormal deterioration of the quality a preventive alarm will be launched. Then,
the maintainer intervenes to preserve the quality of the application and thus avoid potential
damage.
Key words : Preventive Maintenance, Software Quality, Agents, JADE, Aspect Oriented
Programming, AspectJ.
Table des matières
Table des matières
Table des figures
1 Cadre et Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
2 Organisation du mémoire . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
1 Qualité et maintenance logicielles 3
1 Introduction : . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
2 La Qualité Logicielle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
2.1 Définitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
2.2 Assurance qualité logicielle . . . . . . . . . . . . . . . . . . . . . 4
2.3 Mesure de la qualité logicielle . . . . . . . . . . . . . . . . . . . . 5
2.4 Objectifs de l’assurance qualité logicielle . . . . . . . . . . . . . . 8
3 La maintenance de logiciel . . . . . . . . . . . . . . . . . . . . . . . . . . 8
3.1 Définitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
3.2 Historique . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
3.3 Catégories de maintenance logicielle . . . . . . . . . . . . . . . . . 10
3.3.1 Maintenance corrective . . . . . . . . . . . . . . . . . . 11
3.3.2 Maintenance adaptative . . . . . . . . . . . . . . . . . . 12
TABLE DES MATIÈRES
3.3.3 Maintenance perfective . . . . . . . . . . . . . . . . . . 12
3.3.4 Maintenance préventive . . . . . . . . . . . . . . . . . . 12
3.4 Différents types de maintenance préventive . . . . . . . . . . . . . 13
3.4.1 Maintenance préventive systématique (périodique) . . . . 13
3.4.2 Maintenance préventive prévisionnelle . . . . . . . . . . 14
3.4.3 Maintenance préventive conditionnelle . . . . . . . . . . 14
4 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
2 Systèmes Multi-Agents et Paradigme Aspect 16
1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
2 Systèmes Multi-Agents . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
2.1 Niveau micro : Notion d’agent . . . . . . . . . . . . . . . . . . . . 17
2.1.1 Définitions . . . . . . . . . . . . . . . . . . . . . . . . 17
2.1.2 Caractéristiques d’Agents . . . . . . . . . . . . . . . . . 18
2.1.3 Modèles d’agents . . . . . . . . . . . . . . . . . . . . . 19
2.2 Niveau macro : Notion des SMA . . . . . . . . . . . . . . . . . . . 21
2.2.1 Interaction dans les systèmes multi-agents . . . . . . . . 22
2.2.2 Les protocoles d’interaction dans les systèmes multi-agents 22
3 La Programmation Orientée Aspect (POA) . . . . . . . . . . . . . . . . . 24
3.1 Définition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
3.2 Les apports de la Programmation Orientée Aspect . . . . . . . . . . 24
3.3 Les concepts de la POA . . . . . . . . . . . . . . . . . . . . . . . 25
3.3.1 Aspect . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
3.3.2 Point de jonction . . . . . . . . . . . . . . . . . . . . . . 26
3.3.3 Différents types des points de jonctions AspectJ . . . . . 26
TABLE DES MATIÈRES
3.3.4 Les Coupes . . . . . . . . . . . . . . . . . . . . . . . . 26
3.3.5 Les wildcards . . . . . . . . . . . . . . . . . . . . . . . 27
3.3.6 Les codes advice . . . . . . . . . . . . . . . . . . . . . . 28
3.3.7 Les différents types de codes advice . . . . . . . . . . . 28
3.4 Le mécanisme d’introduction . . . . . . . . . . . . . . . . . . . . 29
4 Conclusion : . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
3 Une nouvelle approche de maintenance préventive conditionnelle pour les sys-
tèmes multi-agents 31
1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
2 L’Approche Proposée . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
2.1 Les métriques mesurées . . . . . . . . . . . . . . . . . . . . . . . 33
3 Présentation de l’outil développé . . . . . . . . . . . . . . . . . . . . . . . 34
4 Étude de cas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
5 Conclusion : . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
Table des figures
1.1 Les différentes définitions de la qualité logicielle. . . . . . . . . . . . . . . 4
1.2 Les différentes définitions pour la Mesure de la qualité logicielle. . . . . . . 6
1.3 Processus de mesure de la qualité logicielle. . . . . . . . . . . . . . . . . . 7
1.4 Les générations de maintenance. . . . . . . . . . . . . . . . . . . . . . . . 10
1.5 Catégories de maintenance logicielle. . . . . . . . . . . . . . . . . . . . . 11
1.6 Intervention corrective. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
1.7 Intervention préventive systématique. . . . . . . . . . . . . . . . . . . . . 14
1.8 Schématisation de la maintenance prévisionnelle. . . . . . . . . . . . . . . 14
1.9 Intervention préventive conditionnelle. . . . . . . . . . . . . . . . . . . . . 15
2.1 Un agent dans son environnement. . . . . . . . . . . . . . . . . . . . . . . 18
2.2 Cycle d’un agent cognitif. . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
2.3 Modèle d’un agent hybride. . . . . . . . . . . . . . . . . . . . . . . . . . . 21
2.4 Modélisation AUML du protocole FIPA-Contract-Net. . . . . . . . . . . . 24
2.5 Apports de la POA à la POO . . . . . . . . . . . . . . . . . . . . . . . . . 25
2.6 Les points de jonctions disponibles dans AspectJ. . . . . . . . . . . . . . . 26
3.1 Schéma illustratif de notre approche proposé. . . . . . . . . . . . . . . . . 32
3.2 L’interface principale de notre outil. . . . . . . . . . . . . . . . . . . . . . 35
TABLE DES FIGURES
3.3 L’interface réservée aux courbes des métriques mesurés. . . . . . . . . . . 36
3.4 La fenêtre de paramétrage. . . . . . . . . . . . . . . . . . . . . . . . . . . 36
3.5 Les différents rôles d’agents. . . . . . . . . . . . . . . . . . . . . . . . . . 38
3.6 L’interface principale de notre outil. . . . . . . . . . . . . . . . . . . . . . 39
3.7 Le paramétrage des seuils d’alerte. . . . . . . . . . . . . . . . . . . . . . . 40
3.8 Les causes de la diminution de l’autonomie. . . . . . . . . . . . . . . . . . 41
3.9 La fenêtre de paramétrage de notre étude de cas. . . . . . . . . . . . . . . . 41
3.10 L’autonomie de l’agent CarProd en terme de temps. . . . . . . . . . . . . . 42
3.11 Alerte générée à cause de la dégradation de l’autonomie. . . . . . . . . . . 42
3.12 Les causes de la diminution de la sociabilité. . . . . . . . . . . . . . . . . . 43
3.13 Suspension de l’agent qui simule le rôle des acheteurs. . . . . . . . . . . . 43
3.14 La sociabilité des agents en terme de temps. . . . . . . . . . . . . . . . . . 44
3.15 Alerte générée à cause de la dégradation de la sociabilité. . . . . . . . . . . 44
3.16 La trace d’exécution de notre étude de cas. . . . . . . . . . . . . . . . . . . 45
Introduction générale
1 Cadre et Motivation
Le paradigme agent est, actuellement, largement utilisé dans le développement des appli-
cations logicielles tant dans le secteur académique que dans l’industrie. Dans la littérature,
ce paradigme est considéré comme étant un standard pour la modélisation et l’implémen-
tation des applications reflétant le monde réel. Bien que le développement des applications
orientées agent ait atteint un niveau de maturité élevé, la maintenance de ces applications est
presque complètement omise. Cette activité est importante et indispensable pour la survie de
n’importe quel produit logiciel. Elle nécessite, en termes de dépenses, de 40 à 70% des coûts
du cycle de vie du logiciel. C’est dans ce contexte que se place notre contribution.
Dans ce mémoire, nous proposons une nouvelle approche de maintenance préventive
conditionnelle des applications orientées agents basée sur le paradigme Aspect. Notre ap-
proche de maintenance est accomplie en quatre étapes principales. La première étape consiste
à écrire le code de contrôle en AspectJ. Dans la deuxième étape, l’utilisateur doit définir les
différents seuils minimaux des métriques mesurées de chaque agent (ces différents seuils
sont prédéfinis par le concepteur de l’application à maintenir). La troisième étape consiste
à mesurer les différentes métriques de qualité d’une manière automatique et continue et les
comparer aux seuils minimaux. Si l’une des valeurs mesurée est inférieure au seuil corres-
pondant une alerte sera lancée. Dans la quatrième étape qu’il vient après une alerte préventif,
le mainteneur (utilisateur) doit intervenir manuellement pour maintenir l’application.
1
2. ORGANISATION DU MÉMOIRE
Dans le but de valider notre approche, nous avons développé un environnement de main-
tenance préventive des applications orientées agents. En utilisant notre outil, on peut mesurer
les différentes métriques de la qualité logicielle d’une manière continue, avec une présenta-
tion graphique claire et simple grâce aux différentes courbes fournies par notre outil.
2 Organisation du mémoire
Après cette introduction, et dans le but d’aborder les différents aspects, et afin d’aboutir à
l’objectif tracé, nous avons choisi de structurer notre mémoire de la manière suivante :
Le premier chapitre présente les notions de base de la qualité logicielle, la maintenance
de logiciels, les différents types de la maintenance de logiciels, en mettant l’accent sur la
maintenance préventive.
Dans le deuxième chapitre, nous présentons les systèmes multi-agents, les différents dé-
finitions et ses concepts de base, ainsi que le paradigme Aspect, ses concepts de base et ces
apports.
Nous consacrons le troisième chapitre à la présentation de l’approche proposée, et l’outil
que nous avons développé pour supporter notre approche, ainsi qu’une simple étude de cas
illustrant l’application de cette approche.
2
Chapitre 1
Qualité et maintenance logicielles
1 Introduction :
Au cours des deux dernières décennies, les logiciels sont devenus un atout extrêmement
précieux dans les environnements commerciaux et économiques. Cette très grande impor-
tance nous incite à réfléchir sérieusement sur la manière dans laquelle nous pouvons garantir
la qualité logicielle. Accorder plus d’importance à cet aspect facilitera les tâches des ingé-
nieurs de maintenance logicielle. Cette dernière nécessite, en termes de dépenses, de 40 à
70% des coûts du cycle de vie du logiciel.
2 La Qualité Logicielle
2.1 Définitions
Plusieurs définitions ont été proposées dans la littérature spécialisée pour la qualité logi-
cielle. La figure 1.1 présente quelques définitions.
3
2. LA QUALITÉ LOGICIELLE
FIGURE 1.1 – les différentes définitions de la qualité logicielle [Kát14].
2.2 Assurance qualité logicielle
L’assurance qualité est définie comme "un ensemble systématique et planifié de toutes les
actions nécessaires pour assurer de manière suffisante la certitude qu’un article ou un produit
est conforme aux exigences techniques établies". L’objectif du processus d’assurance de la
qualité des logiciels est, selon l’IEEE-12207, de garantir que les produits et les processus de
travail sont conformes aux dispositions et aux plans prédéfinis. En outre, l’IEEE-610 définit
l’assurance de la qualité des logiciels comme suit [Kla13] :
• Un ensemble planifié et systématique de toutes les actions nécessaires pour assurer de
manière adéquate qu’un article ou un produit soit conforme aux exigences techniques
établies.
• Un ensemble d’activités conçues pour évaluer le processus de développement ou de
fabrication des produits.
Cette définition est limitée au processus de développement du produit logiciel ainsi qu’aux
4
2. LA QUALITÉ LOGICIELLE
aspects techniques des exigences fonctionnelles.
Une autre définition a été proposée par DANIEL GALIN dans son livre "Software Quality
Assurance, From theory to implementation". Cette définition étend la définition de l’IEEE
et ajoute à l’assurance de la qualité des logiciels (AQL) plus d’espace dans le processus de
développement. Cette définition considère l’AQL comme un ensemble d’actions systéma-
tiques et planifiées nécessaires pour assurer avec suffisamment de certitude que le processus
de développement logiciel ou le processus de maintenance d’un produit système logiciel est
conforme aux exigences techniques fonctionnelles ainsi qu’aux exigences de la direction en
matière de maintien du calendrier et d’exécution dans les limites budgétaires [Dan04].
Enfin, l’Assurance qualité logiciel "AQL" peut être définie comme l’ensemble d’activités
planifiées et systématiques assurant la conformité du logiciel et des produits aux exigences
et normes.
2.3 Mesure de la qualité logicielle
Dans les sciences et l’ingénierie, il est essentiel de mesurer les attributs des choses. Me-
surer est la base pour formuler des hypothèses et les tester, ainsi que pour fixer des objectifs
et mesurer leur réalisation. La discipline de la mesure logicielle (souvent appelée métrique
logicielle) consiste à appliquer rigoureusement la mesure de certaines propriété logiciels
[Kla13].
La figure 1.2 présente deux définitions classiques de la mesure. Dans la définition 1,
Fenton et Pfleeger (1997) indiquent qu’une entité est un objet (une personne, un modèle ou
une pièce, par exemple) ou un événement. ISO / CEI 15939 (2007) résume qu’une entité est
un objet (processus, produit, projet ou ressource) caractérisé par la mesure de ses attributs.
Un attribut est une propriété d’une entité (telle que le coût d’un voyage, l’autonomie d’un
agent ou le temps écoulé de la phase de test). Les attributs sont souvent définis à l’aide de
chiffres et de symboles est mesuré en utilisant des méthodes de mesure spécifiques [Kát14].
5
2. LA QUALITÉ LOGICIELLE
FIGURE 1.2 – les différentes définitions pour la Mesure de la qualité logicielle [Kát14].
Le modèle ISO / CEI 15939 (2007) organise tous ces concepts associés au processus de
mesure dans un seul modèle d’information, ce dernier est présenté dans la Figure 1.3.
6
2. LA QUALITÉ LOGICIELLE
FIGURE 1.3 – Processus de mesure de la qualité logicielle.
7
3. LA MAINTENANCE DE LOGICIEL
2.4 Objectifs de l’assurance qualité logicielle
Le développement de logiciels est un processus complexe à risque complet. Il existe des
risques techniques tels que les logiciels ne fonctionneront pas comme prévu ou seront trop
difficiles à utiliser, à modifier et / ou à entretenir. Il existe des risques programmatiques tels
que le dépassement des coûts ou du calendrier. Les objectifs de l’AQL sont de réduire ces
risques de [Als09] :
• Surveillance appropriée du logiciel et du processus de développement.
• Assurer la conformité totale avec les normes et les procédures pour les logiciels et les
processus.
• Assurer que les insuffisances de produit, de processus ou de normes sont portées à
l’attention de la direction afin qu’elles puissent être corrigées.
Le processus de l’assurance qualité logicielle n’est pas responsable de la production de
produits de qualité ou de l’établissement de plans qualité. Il est responsable de l’audit des
actions relatives à la qualité et d’avertir la direction de tout écart [Als09].
Produire un logiciel de qualité a un impact très positif à sa maintenance. Un logiciel
de qualité rend l’activité de maintenance une tâche relativement facile. Par ailleurs, un bon
processus de maintenance permettra de garantir la stabilité de la qualité de logiciel. Dans le
reste de ce chapitre, nous allons mettre l’accent sur les différents concepts de la maintenance
Logicielle.
3 La maintenance de logiciel
3.1 Définitions
Dans la littérature, il existe plusieurs définitions proposées pour la maintenance. Nous
présentons dans cette section les définitions les plus intéressantes.
8
3. LA MAINTENANCE DE LOGICIEL
Selon Leplat et Savoyant [Lep72], la maintenance est une fonction qui vise à maintenir
les machines et plus généralement l’équipement technique en bon état de fonctionnement,
et à le remettre dans cet état en cas de panne ou dysfonctionnement. Plus simplement la
maintenance vise à assurer la fiabilité des systèmes " [Cor00].
D’autre part, Villemeur [Vil88] a défini la maintenance comme la combinaison de toutes
les actions techniques et administratives, y compris la supervision, qui garantissent que le
système est dans l’état de fonctionnement désiré [Cor00].
Si l’on s’en réfère à la norme AFNOR FD X 60-000 (2002), la maintenance est l’ensemble
de toutes les actions techniques, administratives et de management durant le cycle de vie d’un
bien, destinées à le maintenir ou à le rétablir dans un état dans lequel il peut accomplir la
fonction requise [Afn02] .
Enfin, Fadier et Mazeau [Fad96] considèrent la maintenance comme "l’ensemble des
actions (et activités) destinées à maintenir ou rétablir un produit ou une application (logiciel)
dans un état où ils peuvent établir les fonctions désirés".
3.2 Historique
Conformément à Moubray (2000), l’évolution de la maintenance peut être divisée en
générations illustrée par les besoins industriels de chaque génération, qui ont mis en évidence
les concepts centraux relatifs aux types de maintenance et à la manière dont ils auraient pu
être classés. La chronologie de ces générations a été adaptée comme présenté à la figure 1.4
[Fla17].
9
3. LA MAINTENANCE DE LOGICIEL
FIGURE 1.4 – Les générations de maintenance.
3.3 Catégories de maintenance logicielle
Plusieurs auteurs ont étudié le phénomène de la maintenance dans le but d’identifier les
raisons à l’origine des besoins de modifications, ainsi que leurs fréquences. À la suite de ces
études, plusieurs classifications des activités de maintenance ont été définies. Ces classifica-
tions aident à mieux comprendre la grande importance de la maintenance et ses implications
sur le coût et la qualité des systèmes utilisés. La division des tâches de maintenance en ca-
tégories a tout d’abord mis en évidence le fait que la maintenance logicielle représente plus
que la correction des erreurs [Ben15] .Dans la figure 1.5, nous présentons les différentes
Catégories de maintenance logicielle .
10
3. LA MAINTENANCE DE LOGICIEL
FIGURE 1.5 – Catégories de maintenance logicielle.
3.3.1 Maintenance corrective
La maintenance corrective consiste à réparer les défauts dans un système logiciel qui
peuvent être de caractères différents. Il y a des erreurs de codage, des erreurs de conception
et d’exigences. Les erreurs de code exigent le moins de ressources et les erreurs d’exigences
le plus. Les erreurs de codage peuvent être corrigées par un programmeur connaissant bien
le système. Les erreurs de conception peuvent prendre plus de temps et coûter plus cher. Les
erreurs relatives aux exigences sont les plus exigeantes car le système entier est construit pour
répondre à certaines exigences. Si celles-ci ne sont pas correctes, le système peut nécessiter
une refonte complète [Ann07]
FIGURE 1.6 – Intervention corrective [Ben15]
11
3. LA MAINTENANCE DE LOGICIEL
3.3.2 Maintenance adaptative
La maintenance adaptative fait référence aux modifications apportées à un système pour
satisfaire ou s’adapter aux modifications de l’environnement de traitement. Ces modifica-
tions environnementales échappent généralement au contrôle de la maintenance du logiciel
et consistent principalement en des modifications apportées aux éléments suivants [Rog83] :
• règles, lois et réglementations qui affectent le système.
• configurations matérielles, par exemple, nouveaux terminaux, local ,imprimantes.
• formats de données, structures de fichiers.
• logiciel système, par exemple, systèmes d’exploitation, compilateurs, utilitaires.
3.3.3 Maintenance perfective
La maintenance perfective est le type de maintenance le plus exigeant. Ce type de mainte-
nance consiste à ajouter ou modifier les fonctionnalités du système après la livraison. Lorsque
quelque chose dans le contexte d’un système change, en raison du développement de l’or-
ganisation ou des activités, les exigences du système changent souvent de façon radicale.
Les modifications nécessaires sont alors de grandes proportions. Ce type de maintenance est
utilisé aussi pour améliorer les performances ou la maintenabilité des logicielles [Ger00].
3.3.4 Maintenance préventive
La maintenance préventive (figure 1.7) est un calendrier des actions de maintenance pla-
nifiées visant à prévenir les pannes. L’objectif principal de la maintenance préventive est
d’empêcher la défaillance d’un équipement avant son apparition, il est conçu pour préserver
et améliorer la fiabilité des équipements et des systèmes en introduisant des solutions avant
la défaillance [Afe12] .Les tâches de la maintenance préventive sont généralement exécutées
au cours d’une période d’indisponibilité prévue, bien qu’elles puissent également l’être lors
12
3. LA MAINTENANCE DE LOGICIEL
de la maintenance corrective et même pendant le fonctionnement du système (maintenance
prédictive à l’aide de techniques d’inspection non destructive) [Ita16].
Une politique de maintenance préventive a pour objectifs :
• Augmenter la fiabilité du système.
• Améliorer la disponibilité du système.
• Augmenter la durée de vie efficace du Logiciel.
• Détecter des pannes possibles avant la défaillance du système.
• Réduire les coûts de défaillance.
• Améliorer le service client (interne ou externe) car les équipes de maintenance effec-
tuent moins de tâches de maintenance imprévues et peuvent réagir plus rapidement
aux nouveaux problèmes.
• Contribuer positivement à la réputation de l’entreprise.
3.4 Différents types de maintenance préventive
3.4.1 Maintenance préventive systématique (périodique)
Lorsque la maintenance préventive est effectuée dans des intervalles de temps définis, on
parle de maintenance systématique ou périodique (figure 1.8). Les opérations de maintenance
sont effectuées selon un échéancier ou un calendrier déterminé a priori. L’optimisation d’une
maintenance préventive systématique consiste à déterminer au mieux la périodicité des opé-
rations de maintenance sur la base du temps, du nombre de cycles de fonctionnement...etc
[Ben15].
13
3. LA MAINTENANCE DE LOGICIEL
FIGURE 1.7 – Intervention préventive systématique [Ben15].
3.4.2 Maintenance préventive prévisionnelle
Lorsque la maintenance préventive est effectuée sur la base de l’estimation du temps de
fonctionnement correct qui subsiste avant la défaillance, on parle de maintenance préventive
prévisionnelle [Ost16].
FIGURE 1.8 – Schématisation de la maintenance prévisionnelle [Ost16].
3.4.3 Maintenance préventive conditionnelle
D’après la définition Afnor [Afn02], il s’agit d’une forme de maintenance préventive
basée sur une surveillance de fonctionnement. La maintenance conditionnelle (figure 1.9)
permet d’assurer le suivi continu du matériel ou logiciel en service, et la décision d’inter-
vention est prise lorsqu’il y a une évidence expérimentale de défaut imminent ou d’un seuil
de dégradation prédéterminé. Cela concerne certains types de défaut, de pannes arrivant pro-
14
4. CONCLUSION
gressivement ou par dérive. L’étude des dérives dans le cadre des interventions de mainte-
nance préventive permet de déceler les seuils d’alerte, tant dans les technologies relevant de
la mécanique que celles de l’informatique. Au cours de la conception, on définit des tolé-
rances pour certains paramètres. La variation progressive d’un paramètre n’implique pas la
défaillance d’un organe. Mais lorsqu’un paramètre sort de la tolérance, le fonctionnement
peut être complètement perturbé [Jea10].
Les exemples les plus classiques des techniques utilisées pour mettre en place la mainte-
nance conditionnelle dans le domaine de l’industrie sont la thermographie infrarouge, l’ana-
lyse des lubrifiants et la mesure des vibrations. Ces techniques donnent lieu d’ailleurs à des
articles approfondis dans le cadre de ce traité [Ben15].
FIGURE 1.9 – Intervention préventive conditionnelle [Ben15] .
Dans le contexte de notre travail, nous nous intéressons à la maintenance préventive condi-
tionnelle des systèmes multi-agents.
4 Conclusion
Dans ce chapitre, nous avons donné un aperçu général sur les différents concepts de la
qualité logicielle ainsi que les objectifs désirés par l’assurance de la qualité logicielle. Nous
avons également présenté brièvement la notion de la maintenance logicielle : les différentes
définitions proposées dans la littérature, les différents générations de la maintenance, ainsi
que les diverses catégories de la maintenance logicielle tout en mettant l’accent sur la main-
tenance préventive.
15
Chapitre 2
Systèmes Multi-Agents et Paradigme
Aspect
1 Introduction
Depuis la naissance de l’informatique, plusieurs paradigmes de programmation sont ap-
parus. Parmi ces paradigmes le paradigme agent a prise une place de plus en plus importante
en informatique, que ce soit dans le domaine de l’intelligence artificielle, les systèmes dis-
tribues, de la robotique, ou même dans des autres domaines. Le paradigme orienté aspect a
prendre aussi une place particulière dans l’informatique grâce a sa séparation sa séparation
entre les besoins fonctionnels et les besoins non fonctionnels. Dans le reste de ce chapitre,
nous tenterons d’aborder les concepts de base de ces deux paradigme qui nous paraît les plus
appropriées pour notre travail.
16
2. SYSTÈMES MULTI-AGENTS
2 Systèmes Multi-Agents
2.1 Niveau micro : Notion d’agent
Le concept agent est issu de plusieurs disciplines comme la robotique, l’informatique,
l’automatisation de la fabrication, l’intelligence artificielle, etc .Cependant Plusieurs défini-
tions ont étés proposées dans la littérature, nous citons entre autres les deux définitions les
plus célèbres dans la littérature, la définition de Jack Ferber et celle de Wooldridge.
2.1.1 Définitions
2.2.1.1 Définition de Ferber
D’après Jacques Ferber, l’un des fondateurs des systèmes multi-agents, un agent est une
entité physique ou virtuelle [Fer99].
1. qui est capable d’agir dans un environnement,
2. qui peut communiquer directement avec d’autres agents,
3. qui est dirigé par un ensemble de tendances (sous la forme d’objectifs individuels ou
d’une fonction de satisfaction / fonction de survie qu’il essaie d’optimiser),
4. qui possède ses propres ressources,
5. qui est capable de percevoir son environnement,
6. qui n’a qu’une représentation partielle de cet environnement,
7. qui possède des compétences et peut offrir des services,
8. qui peut être capable de se reproduire,
9. dont le comportement tend à satisfaire ses objectifs, en tenant compte de ses ressources
et de ses compétences et en fonction de sa perception, de ses représentations et de la
communication qu’il reçoit.
17
2. SYSTÈMES MULTI-AGENTS
2.2.1.2 Définition de Wooldridge
Une autre définition, qui complète la précédente, est donnée par M. Wooldridge : « Un
agent est un système informatique situé dans un environnement donné et capable d’agir de
manière autonome dans cet environnement afin de répondre à ses objectifs de conception. »
[Woo95] . Cette définition mette l’accent sur l’environnement de l’agent.
FIGURE 2.1 – Un agent dans son environnement.
La figure 2.1 représente un agent qui prend les entrées sous la forme des stimulus de son
environnement et produit en sortie les actions qui les affectent d’une manière autonome. Le
but de ces actions et de réaliser ses objectifs de conception.
2.1.2 Caractéristiques d’Agents
D’après Wooldrige et Jennings, on peut identifier plusieurs caractéristiques pour la notion
d’agent. Un agent ne possède pas forcément toutes ces caractéristiques à la fois. Parmi ces
caractéristiques on trouve :
• L’activité et l’autonomie : Un agent est une entité active et autonome. Pour le dé-
clenchement de ses comportements, un agent autonome a la capacité de fonctionner
sans l’intervention des autres agents ou de l’opérateur humain. Pour être autonome, un
agent doit être doté d’un mécanisme de contrôle afin de gérer ses activités en fonction
de son état interne et de son monde externe [Zer10] .
18
2. SYSTÈMES MULTI-AGENTS
• La sociabilité : la sociabilité est l’une des caractéristiques les plus importantes dans
les systèmes Multi-Agents. Cette caractéristique met l’accent sur le groupe plutôt que
sur l’agent. Aussi, elle omet les mécanismes internes à l’agent, et s’intéresse aux in-
teractions entre les agents de la société [Zah96].
• L’intelligence : Un agent est dit Intelligent s’il possède des capacités de représentation
symbolique et/ou des fonctions cognitives. Il doit non seulement planifier ses propres
actions mais aussi tenir compte de celles des autres [Zer10].
• La situation : l’agent est capable d’agir sur son environnement à partir des entrées
sensorielles qu’il reçoit de ce dernier.
• La réactivité : La réactivité représente la capacité de l’agent de percevoir les change-
ments dans l’environnement et d’y réagir rapidement.
Les autres caractéristiques d’un agent peuvent être la mobilité, la bienveillance, La véra-
cité, la rationalité et la capacité d’apprentissage. La mobilité est la capacité de voyager entre
différents hôtes d’un réseau informatique. L’agent est dit bienveillant s’il effectue toujours ce
qu’il lui a été demandé de faire. La véracité est la caractéristique de l’agent qui ne commu-
nique pas des fausses informations. Un agent rationnel est un agent qui agit d’une manière
lui permettant d’obtenir le plus de succès possible dans la réalisation des tâches qu’on lui a
assignées. La capacité d’apprentissage est la capacité qui permet à l’agent de s’adapter à son
environnement et aux désirs de ses utilisateurs [Pat14].
2.1.3 Modèles d’agents
Il existe plusieurs critères de classification pour les agents dans la littérature. Dans notre
travail on va mettre l’accent sur les classifications du Ferber qui a proposé deux classifica-
tions pour les agents [Zak18].
19
2. SYSTÈMES MULTI-AGENTS
• Selon le caractère :
– Agents cognitifs ou délibératifs : Ce type d’agents est dit cognitif ou délibé-
ratif a cause de leur cycle Perception / Délibération / Action comme le montre
la Figure 2.2. Les agents ont une représentation explicite de leur environnement,
des buts explicites et sont capables de planifier leurs comportements et de mémo-
riser leurs actions. Ils sont capables à effectuer des opérations complexes et de
résoudre certains problèmes. On note qu’un système multi-agent de cette catégo-
rie est composé d’un petit nombre d’agents hétérogènes capable de communiquer
entre eux [Mar03].
FIGURE 2.2 – Cycle d’un agent cognitif [Mar03].
– Agents réactifs : Les agents réactifs sont capables uniquement de percevoir et
agir sur l’environnement. Ils n’ont pas de représentation explicite de l’environ-
nement et n’ont pas de mémoire de leurs historiques. Leurs capacités consistent
à réagir uniquement aux stimuli provenant de l’environnement. On note qu’un
système multi-agent de cette catégorie est composé d’un grand nombre d’agents
homogènes relativement simples et interagissent entre eux e façon très basique
[Zak18].
– Agents hybride : Dans ce modèle, les agents sont conçus comme étant compo-
sés de deux niveaux hiérarchiques qui interagissent entre eux, une couche pour
assurer les comportements réactifs et l’autre pour les comportements cognitifs
[Mar03] (figure 2.3).
20
2. SYSTÈMES MULTI-AGENTS
FIGURE 2.3 – Modèle d’un agent hybride [Zer14].
• Selon le comportement :
– Agent téléonomique : C’est un modèle d’agents dirigé vers la réalisation des
buts explicites.
– Agent réflexe : C’est le modèle le plus simple des agents intelligents. Il exécute
des actions en fonction de la situation actuelle. Lorsque quelque chose se passe
dans l’environnement l’agent analyse rapidement sa base de connaissances pour
savoir comment réagir à la situation en fonction de ses règles prédéterminées.
2.2 Niveau macro : Notion des SMA
Dans son livre « Les Systèmes Multi-Agents : Vers une Intelligence Collective », Fer-
ber a défini les systèmes multi-agents comme un système comprenant les éléments suivants
[Bof17] [Fer99] :
• Un environnement E, c’est-à-dire un espace qui disposant généralement d’une mé-
trique.
• Un ensemble d’objets O. Ces objets sont situés, c’est-à-dire qu’il est possible d’asso-
cier n’importe quel objet à une position donnée à un moment donné. Ces objets sont
passifs, c’est-à-dire qu’ils peuvent être perçus, créés, détruits. et modifié par les agents.
21
2. SYSTÈMES MULTI-AGENTS
• Un ensemble d’agents A, qui sont des objets spécifiques (A inclus dans O), représen-
tant les entités actives du système.
• Un ensemble de relations R, qui relie des objets (et donc des agents) les uns aux autres.
• Un ensemble d’opérations Op, permettant aux agents de A d e percevoir, produire,
consommer, transformer et manipuler des objets d’O.
• Un ensemble d’opérateurs chargés de représenter l’application de ces opérations et la
réaction du monde à cette tentative de modification.
2.2.1 Interaction dans les systèmes multi-agents
Les agents sont généralement caractérisés par un ensemble limité de compétences. En
conséquence, l’interaction entre les agents est très nécessaire pour que les agents atteignent
leurs objectifs individuels et collectifs. En fait, On ne peut parler d’un système multi agents
sans parler sur les interactions entre ces agents "par définition un système multi agents est un
ensemble d’agents en interaction" [Mar18]. Les interactions peuvent être direct par l’échange
de message ou indirect à travers l’environnement par la perception. Par la communication,
un agent fait un acte délibéré de transfert d’informations vers un ou plusieurs autres agents.
L’interaction peut être décomposée en trois phases principales [Zer10] :
• La réception des informations ou la perception des changements dans l’environnement.
• Le raisonnement sur les autres agents à partir des informations acquises.
• L’envoi de message(s) ou la réalisation des actions modifiant l’environnement. Cette
étape est le résultat d’un raisonnement de l’agent sur sa propre connaissance et celui
des autres agents.
2.2.2 Les protocoles d’interaction dans les systèmes multi-agents
Par définition un système multi agents est un ensemble d’agents où chaque agent doit in-
teragir avec les autres agents pour accomplir ses tâches. La fonction de base d’un protocole
22
2. SYSTÈMES MULTI-AGENTS
d’interaction est de fournir un moyen aux agents de communiquer efficacement sans avoir
à planifier explicitement chaque acte en délimitant l’espace des réponses possibles. Le pro-
tocole est plus efficace, car moins d’informations doivent être transmises et moins de temps
est consacré à la communication. Tous les agents assistent de manière appropriée entre diffé-
rents protocoles d’interaction. Par exemple, répondre au message, effectuer des actions dans
leurs domaines respectifs, ou mettre à jour leurs états locaux. Les protocoles peuvent donc
être considérés comme un moyen de spécifier la politique que les agents suivront dans leurs
interactions avec les autres. Cette politique déterminera les conditions dans lesquelles une
demande peut être satisfaite [Bor13].
2.2.2.1 Le protocole Contract Net
Le protocole réseau contractuel ("Contract Net" en anglais) a été développé pour spé-
cifier la communication et le contrôle de la résolution des problèmes pour les nœuds d’un
résolveur de problèmes distribué. La répartition des tâches est affectée par un processus de
négociation, une discussion entre les nœuds avec les tâches à exécuter et les nœuds pouvant
éventuellement exécuter ces tâches [Rei80].
FIPA-Contract-Net est une modification mineure du protocole de contrat initial en ajou-
tant des actes de communication de rejet et de confirmation. Dans le protocole contractuel, un
agent peut prendre le rôle de gestionnaire ou contractant. L’agent qui doit exécuter une tâche
(le gestionnaire) peut décomposer cette tâche en un ensemble des sous tâches et annonce
chaque sous-tâche sur un réseau d’agents (les contractants). Les contractants disponibles
évaluent les annonces de tâches faites par les gestionnaires et soumettent des offres ("bids"
en anglais) qui indiquent leurs capacités à réaliser la tâche. Cette offre est communément
exprimée sous forme de prix, d’une manière spécifique à un domaine, mais pourrait égale-
ment être le délai de réalisation le plus proche, une répartition équitable des tâches, etc. Les
gestionnaires évaluent les offres et attribuent les contrats aux agents qu’ils jugent les plus
appropriés [Gen97] .Le protocole FIPA-Contract-Net est décrit à l’aide d’un diagramme de
séquence AUML présenté par la Figure 2.4.
23
3. LA PROGRAMMATION ORIENTÉE ASPECT (POA)
FIGURE 2.4 – Modélisation AUML du protocole FIPA-Contract-Net.
3 La Programmation Orientée Aspect (POA)
3.1 Définition
La POA (Aspect Oriented Programming, Programmation Orientée Aspects) est une ap-
proche particulière de séparation des préoccupations. Elle a été définie par Gregor Kickzales
et son équipe (du laboratoire de recherche PARC de Xerox) en 1996. La POA est une exten-
sion de langage de programmation. Elle peut être appliquée au Java, C, C++,Smalltalk...etc.
Il est alors possible de l’appliquer sur les langages de programmation procédurale ou les
langages orientés objets [Arn09].
3.2 Les apports de la Programmation Orientée Aspect
La programmation orientée aspect (POA) complémente la POO en apportant des solu-
tions aux deux challenges que sont l’implémentation de fonctionnalités transversales et le
24
3. LA PROGRAMMATION ORIENTÉE ASPECT (POA)
phénomène de dispersion de code (figure 2.5) [Ren04].
La POA fournit des moyens pour séparer le code qui implante une propriété transversale
du code fonctionnel de l’application.
FIGURE 2.5 – Apports de la POA à la POO .
3.3 Les concepts de la POA
Dans cette section, nous introduirons quelque concepts de base de ce paradigme. Nous
expliquons les constituants de l’aspect, comme les points de jonction, les coupes, le ‘codes
advice’, ‘Tissage d’aspects’, ‘Mécanisme d’introduction .
3.3.1 Aspect
Un aspect est une entité logicielle qui capture une fonctionnalité transversale à une Ap-
plication [Ren04].
La définition d’un aspect est très similaire à la définition d’une classe ou d’une interface
en Java . Ainsi, tout comme les classes et les interfaces, les aspects portent un nom et peuvent
être définis au sein de paquetages [Bou10].
25
3. LA PROGRAMMATION ORIENTÉE ASPECT (POA)
3.3.2 Point de jonction
Un point de jonction est un point qui désigne un endroit du programme où l’on souhaite
ajouter un aspect [Ren04].
L’utilisation des points de jonction se fait essentiellement sous forme d’ensemble, une
coupe définissant tous les points de l’application auxquels elle souhaite greffer l’aspect. Ces
points de l’application peuvent être l’appel d’une méthode, l’exécution d’un constructeur, la
lecture d’un attribut [Elb10] .
3.3.3 Différents types des points de jonctions AspectJ
La table ci-après contient les différents types de points de jonction :
FIGURE 2.6 – Les points de jonctions disponibles dans AspectJ [Arn09] .
3.3.4 Les Coupes
Une coupe désigne un ensemble de points de jonction [Ren04]. Les points de jonction et
les coupes sont conceptuellement fort différents : 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.
C’est à elle qu’est attribué le rôle de définir la structure transversale d’un aspect.
/*la coupe */
pointcut Asp() :execution(* *..*(..)) }
26
3. LA PROGRAMMATION ORIENTÉE ASPECT (POA)
3.3.5 Les wildcards
L’AspectJ fournit un ensemble de symboles qui nous permettent de créer des expressions
englobant plusieurs méthodes. Au lieu d’écrire des expressions (call, execution,. . . ) pour
tout point de jonction quelque soit son type (méthode, attribut,. . . ) dans une classe ou dans
un package , nous allons créer des coupes dont des expressions utilisant les wildcards, alors
on va obtenir un nombre d’expressions plus petit qu’avant.
Wildcard Utilisation
* Remplace un nom (de classe, de paquetage, de méthode, d’attribut, etc..) ou
simplement une partie de nom. Il peut aussi remplacer un type de retour ou
un paramètre. Il signifie « n’importe quel nom » ou « n’importe quel type ».
Exemple pour une expression sur une méthode :
public * org.aspectj.*.init*(int, String, *)
.. Utilisé pour omettre les paramètres des méthodes ou le chemin complet des
paquetages. Exemple pour une expression sur une méthode :
public void org..Test.active(..)
Cet exemple signifie « toutes les méthodes publiques active quel que soient
leurs paramètres, retournant void et situées dans les classes Test situées dans
n’importe quel sous paquetage de org ».
+ Permet de définir n’importe quel sous-type d’une classe ou d’une interface.
Exemple pour une expression sur une méthode :
* void org.jade.test.application+.set* (..) ;
Cet exemple a deux sens : Si application est une interface alors « Toutes les
méthodes commençant par set des classes implémentant l’interface applica-
tion. » Si application est une classe alors « Toutes les méthodes commençant
par set de cette classe et toutes les classes qui l’héritent. »
27
3. LA PROGRAMMATION ORIENTÉE ASPECT (POA)
3.3.6 Les codes advice
Un code advice est toujours associé à une coupe ou plus exactement aux points de jonc-
tions sélectionnés par cette coupe. En effet, un code advice n’est jamais appelé manuelle-
ment, mais il est invoqué chaque fois qu’un point de jonction, sélectionné par la coupe à
laquelle il est associé [Zer14].
Avant d’écrire ce code advice il faut décider à quel moment exécuter le code : avant, après
ou autour des points de jonction sélectionnés par la coupe qui lui est associée.
3.3.7 Les différents types de codes advice
Il existe trois types principaux de code advice, qui se différencient par la façon dont le
bloc de code est exécuté lorsqu’un point de jonction de la coupe à laquelle ils sont associés
apparaît :
• before : le code est exécuté avant les points de jonction.
/*la coupe */
pointcut Asp() :execution(* *..*(..))
/*le code advice */
before() :Asp(){ System.out.println("Avant l’exécution de la methode verser") ;
}
• after : code est exécuté après les points de jonction.
/*la coupe */
pointcut Asp() :execution(* *..*(..))
/*le code advice */
after() :Asp(){ System.out.println("aprés l’exécution de la methode verser") ; }
28
3. LA PROGRAMMATION ORIENTÉE ASPECT (POA)
• around : le code est exécuté avant et après les points de jonction.
/*la coupe */
pointcut Asp() :execution(* *..verser(..))
/*le code advice */
void around() :Asp(){
System.out.println("Avant l’appel de la methode verser") ;
proceed() ;
System.out.println("Aprés l’appel de la methode verser") ;
}
3.4 Le mécanisme d’introduction
Dans la programmation orienté aspect le mécanisme d’introduction permet d’étendre des
classes en y ajoutant des attributs ou des méthodes, mais ce ne sont pas les seuls exemples.
Il permet aussi d’ajouter des interfaces Java et de super classe [Elb10].
Nous allons dans c qui suit définir un aspect permettant d’ajouter des attributs et des
méthodes à une classe Etudiant.
29
4. CONCLUSION :
public aspect MecanismeIntroduction {
/* Ajout d’une interface a Etudiant */
declare parents : Etudiant implements Personne ;
/* Ajout d’un attribut NumCarte a Etudiant */
private int Etudiant.NumCarte ;
/* Ajout d’une methode NumCarte a Etudiant */
public void Etudiant.SetNumCarte(int N){
NumCarte=N;
}
/* Ajout d’une methode NumCarte a Etudiant */
public int Etudiant.GetNumCarte(){
return NumCarte ;
}
}
4 Conclusion :
Dans ce chapitre, nous avons présenté un aperçu sur le paradigme multi agents, tout en
mettant l’accent sur les concepts de base utilisés tout au long de notre travail. Nous avons
mis l’accent sur la communication qui présente la brique de base des systèmes multi agents.
Nous avons présenté aussi les concepts principaux de la programmation orientée aspect, les
points de jonction, les coupes, les codes advice, et en fin le mécanisme d’introduction.
30
Chapitre 3
Une nouvelle approche de maintenance
préventive conditionnelle pour les
systèmes multi-agents
1 Introduction
Aujourd’hui, la maintenance préventive est la méthode de maintenance la plus simple et la
plus fiable à la fois. Dans le cadre de ce mémoire, nous proposons une nouvelle approche de
maintenance préventive conditionnelle pour les applications multi-agents. L’approche pro-
posée est basée sur certaines mesures de qualité de l’application à maintenir. Cette approche
est supportée par outil que nous avons développé et appliquée à une simple étude de cas.
2 L’Approche Proposée
Le travail que nous avons fait consiste à la proposition d’une nouvelle approche de main-
tenance préventive conditionnelle pour les systèmes multi-agents. Cette approche sert à me-
31
2. L’APPROCHE PROPOSÉE
surer continuellement quelques métriques de qualité à l’aide du code de contrôle écrite en
AspectJ et le comparer avec des seuils minimaux définis préalablement par le concepteur, si
la valeur mesurée est inférieure à celle spécifiée par le concepteur, une intervention préven-
tive doit se faire pour rendre le système dans son état de fonctionnement désiré. La figure
suivante illustre bien notre approche proposée :
FIGURE 3.1 – Schéma illustratif de notre approche proposé.
32
2. L’APPROCHE PROPOSÉE
2.1 Les métriques mesurées
Pour la validation de notre approche, nous avons choisi les deux métriques essentielles des
systèmes multi agents, l’autonomie au niveau d’agent et la sociabilité au niveau de système
multi agents.
• L’autonomie : afin de mesurer l’autonomie dans les applications JADE, nous avons
suivi la tendance basée sur l’absence des demandes de services en utilisant la formule
proposée par Marir Toufik [Mar15] :
RLRS = 1 - RS / EB
Tel que :
– Request Service (RS) : est le nombre de demande de services.
– Executed Behaviors (EB) : est le nombre de comportements exécutés.
• La sociabilité : C’est le degré de capacité qu’a un agent interagissant avec les autres
afin de satisfaire ses objectifs. La sociabilité peut être mesurée par plusieurs métriques
dans notre travail nous considérons que tout action de communication fait partie de la
sociabilité. La formule utilisée pour mesurer la sociabilité est la suivante :
SOC = 1 - MN / EB
Tel que :
– Message number (MN) : est le nombre des messages envoyé.
– Executed Behaviors (EB) : est le nombre de comportements exécutés.
Dans les deux formules précédentes nous supposons que l’agent ne fait pas plus qu’une
seule demande pour chaque comportement exécuté pour assurer les exigences de la norma-
lisation de valeurs dans l’intervalle [0,1] [Mar15].
33
3. PRÉSENTATION DE L’OUTIL DÉVELOPPÉ
3 Présentation de l’outil développé
Pour valider notre approche, nous avons développé l’outil PreMMAS (Preventive Main-
tenance for Multi-Agents Systems) qui fournit à l’utilisateur la possibilité d’écrire son code
métier (en Jade dans notre cas), ainsi que le code de contrôle (en AspectJ) qui consiste à
mesurer quelques métriques de qualité d’une façon dynamique et périodique et les comparer
avec des seuils définis préalablement par le concepteur.
Pour développer cet outil, nous avons utilisé un ordinateur portable dont la configuration
est la suivante :
• Processeur : Intel R© CoreTM i3-3110M Processor (3M Cache, 2.40 GHz) .
• Mémoire :6 Go RAM / 1 To Disque.
• Système d’exploitation : windows 7 professional 32 bits.
L’outil est développé en utilisant le langage java, suivant l’approche de développement
des plugins sous Eclipse RCP (Rich Client Platform). L’avantage majeur de suivre cette mé-
thode d’implémentation est l’architecture extensible qui permet l’intégration d’autres plu-
gins comme le JDT (Java Développement Tools) ou l’AJDT (AspectJ Development Tools),
ainsi que la possibilité de l’intégration de l’outil dans d’autre application RCP qui permet sa
réutilisation par d’autres utilisateurs.
La Figure 3.2 présente la fenêtre principale de notre application. Elle offre toutes les fonc-
tionnalités qui permettent de guider l’utilisateur de coder son programme et de le mettre sous
contrôle continu. PreMMAS est déployé comme une application autonome et indépendante
de l’EDI Eclipse. Il peut être aussi déployé sous la forme d’un Plugin.
34
3. PRÉSENTATION DE L’OUTIL DÉVELOPPÉ
FIGURE 3.2 – L’interface principale de notre outil.
Ces différentes sections représentent :
• 1 : l’explorateur des packages.
• 2 : la console.
• 3 : L’éditeur AspectJ.
• 4 : L’éditeur Java.
Notre outil développé est accompagné par un autre plugin java qui est responsable de gérer
les différentes courbes dynamiques des métriques mesurés, ainsi qu’une petite interface de
paramétrage pour paramétrer les différents seuils des métriques mesurés.
La figure 3.3 présente la fenêtre qui va contenir les différentes courbes dynamique des
métriques mesurés pour chaque agent par rapport aux temps logique présenté sur l’axe des
abcis.
35
3. PRÉSENTATION DE L’OUTIL DÉVELOPPÉ
FIGURE 3.3 – l’interface réservée aux courbes des métriques mesurés.
La figure 3.4 présente la fenêtre de paramétrage des différents seuils des métriques mesu-
rés.
FIGURE 3.4 – La fenêtre de paramétrage.
36
4. ÉTUDE DE CAS
4 Étude de cas
Après le développement de notre outil, nous allons illustrer l’application de notre ap-
proche sur un exemple concret de système multi agents. L’exemple représente une simple
simulation d’un système de production des voitures. Dans cet exemple il y a plusieurs uni-
tés de production des différents composants de la voiture avec une unité principale dont le
rôle est l’assemblage de ces composants. Chaque unité de production possède un stock de
taille limitée. L’unité principale possède plusieurs stocks : un stock à chaque composant et
un stock pour le produit final (les voitures).
L’unité principale essaie toujours d’assurer le bon fonctionnement du processus de pro-
duction en remplissant les stocks des différents composants et de commercialiser le produit
final en stock. Ll’unité principale cherche également à obtenir les différents composants avec
des meilleures offres par la négociation.
La figure ci-dessus présente les différents rôles d’agents dans notre étude de cas ainsi que
les icones correspondant.
37
4. ÉTUDE DE CAS
FIGURE 3.5 – les différents rôles d’agents.
L’interface principale de notre étude de cas est présentée dans la Figure 3.6. Dans la
partie droite de notre étude de cas il y a les différents rôles des agents, ainsi que les deux
boutons pour paramétrer et pour lancer la simulation. La partie gauche contient les instances
des différents agents ainsi que les quantités de stock des différents composants pour chaque
unité.
38
4. ÉTUDE DE CAS
FIGURE 3.6 – L’interface principale de notre outil.
Lors du lancement de la simulation La fenêtre de paramétrage des seuils sera apparue
.Après une simple analyse statique sur notre étude de cas nous avons trouvé que le système
et dans un état sain tant que les métriques mesurés sont supérieur aux seuils présenté dans la
figure 3.7.
39
4. ÉTUDE DE CAS
FIGURE 3.7 – Le paramétrage des seuils d’alerte.
Pour démontrer l’efficacité de notre outil et par conséquent notre approche nous avons
suivi la démarche de test par l’injection d’erreur qui consiste à injecter une cause d’erreur et
attendre l’apparition et la détection de l’erreur. Les causes d’erreur de notre étude de cas sont
modélisées sous la forme des diagrammes cause-effet, les figures 8 et 12 présentent quelques
causes d’erreurs possibles.
40
4. ÉTUDE DE CAS
FIGURE 3.8 – les causes de la diminution de l’autonomie.
Dans la figure ci-dessous, nous avons changé la taille de la quantité commandée à chaque
fois. Cette modification est l’une des causes de la diminution de l’autonomie.
FIGURE 3.9 – La fenêtre de paramétrage de notre étude de cas.
41
4. ÉTUDE DE CAS
La figure ci-dessous présente la courbe de l’autonomie de l’agent CarProd avant l’injec-
tion de la cause d’erreur et après l’injection de la cause et l’apparition de l’erreur.
FIGURE 3.10 – L’autonomie de l’agent CarProd en terme de temps.
La Figure 3.11 présente l’erreur générée lorsque l’autonomie est inférieure au seuil défini
préalablement par le concepteur.
FIGURE 3.11 – Alerte générée à cause de la dégradation de l’autonomie.
La figure 3.12 présente quelques causes de diminution de la sociabilité entre les agents
sous la forme d’un diagramme de cause/effet.
42
4. ÉTUDE DE CAS
FIGURE 3.12 – les causes de la diminution de la sociabilité.
L’un des cause de la diminution de la sociabilité est le manque des acheteurs qui conduit à
la saturation des stocks et par conséquence l’arrêt du processus de production. Dans la figure
ci-dessous nous avons suspendu l’agent qui simule le rôle des acheteurs.
FIGURE 3.13 – Suspension de l’agent qui simule le rôle des acheteurs.
La figure ci-dessous présente la courbe de la sociabilité des agents avant l’injection de la
cause d’erreur et après l’injection de la cause et l’apparition d’erreurs.
43
4. ÉTUDE DE CAS
FIGURE 3.14 – la sociabilité des agents en terme de temps.
La Figure 3.15 présente l’erreur générée lorsque la sociabilité est inférieure au seuil défini
préalablement par le concepteur.
FIGURE 3.15 – Alerte générée à cause de la dégradation de la sociabilité.
Notre étude de cas garde toujours la trace d’exécution dans un fichier externe pour per-
mettre au mainteneur de localiser la source de problème d’une manière simple et rapide, voir
la figure 3.16.
44
5. CONCLUSION :
FIGURE 3.16 – la trace d’exécution de notre étude de cas.
5 Conclusion :
Nous avons présenté, dans ce chapitre, une nouvelle approche de maintenance préventive
conditionnelle pour les applications multi-agents. L’approche proposée est basée dirigée par
les certaines mesures de qualité (l’autonomie et la sociabilité) de l’application à maintenir.
Pour concrétiser cette approche, nous avons développé un environnement baptisé PreMMAS
offrant tous les outils nécessaire pour tout le processus de l’approche proposée à partir de
codage jusqu’a la détection de la dégradation de la qualité de l’application. Pour valider
notre approche, nous l’avons appliquée sur une étude de cas simple mais réaliste.
45
Conclusion générale et perspectives
L’activité de maintenance apparaît aujourd’hui comme le moyen principal pour garantir
le bon fonctionnement et prolonger la durée de vie d’un logiciel. Bien qu’il ne soit pas ex-
haustif, la maintenance a pour objectif de minimiser les erreurs potentielles pouvant affecter
le bon déroulement du programme en cours d’exécution. En fait, plusieurs activités peuvent
être appliquées sur un programme afin de garantir son fonctionnement. Parmi ces activités
nous sommes intéressés dans le cadre de ce mémoire à la maintenance préventive. Le prin-
cipe de la maintenance préventive consiste à prévoir la panne avant leur apparition à partir
de la surveillance continue du programme sous l’exécution.
Nous avons proposé, dans ce mémoire, une approche de maintenance préventive des ap-
plications orientées agents basée sur le paradigme Aspect. Notre approche consiste à mesurer
quelques métriques de qualité du programme en cours d’exécution et les comparer avec des
seuils minimaux définis préalablement par le concepteur de ce programme. En cas de dégra-
dation anormale de la qualité une alerte préventive sera lancée.
Dans le but de valider notre approche, nous avons développé un environnement de main-
tenance préventive des applications orientées agents. En utilisant notre outil, on peut mesurer
les différentes métriques de la qualité logicielle d’une manière continue, avec une présenta-
tion graphique claire et simple de ces valeurs grâce aux différentes courbes fournies par notre
outil.
Comme perspectives a moyen terme, nous envisageons de :
• Étendre notre approche pour supporter les autres métriques fonctionnelle des systèmes
46
5. CONCLUSION :
multi-agents, tel que la Rationalité, l’adaptabilité. . . etc.
• Etendre notre approche pour supporter les métriques non fonctionnelle des systèmes
multi-agents, tel que la stabilité, la scalabilité.
• Améliorer notre outil pour supporter la génération automatique du code de contrôle
(AspectJ) à partir de code métier (Jade).
47
Bibliographie
[Afe12] Islam H. Afefy .
Maintenance Planning Based on Computer-Aided Preventive Maintenance Policy .
The international MultiConference of Engineers and Computer Scientists 2012 Vol
2,March 14-16,Hong Kong.
[Afn02] M GUSMINI, MLLE BENSALEM.
Maintenance industrielle AFNOR X60G.
Mai 2002, ISSN 0335-3931.
[Als09] Alshaimaa Adel Tantawy Abdou.
Software Quality Assurance Models : A Comparative Study.
Thèse de Master ,Zagazig University, Egypt ,September 2009.
[Ann07] Ann-Sofie Jansson.
Software Maintenance and Process Improvement by CMMI.
Rapport de recherche,Université d’Uppsala , Suède,December 2007,ISSN : 1650-
8319.
[Arn09] Arnaud Cogoluègnes , Thierry Templier , Julien Dubois , Jean-Philippe Retaillé ,
Spring par la Pratique,ISBN-13 : 978-2212124217.
48
[Ben15] Benaicha Halima.
Analyse des stratégies de maintenance des systèmes de production industrielle.
Thèse de Doctorat, Université d’Oran Mohammed Boudiaf, 2015.
[Bof17] BOFEI CHEN.
A multi-agent based cooperative control model applied to the management of vehicles-
trains.
Thèse de Doctorat ,l’Université de Technologie de Belfort-Montbéliard,France, 10
février 2017.
[Bor13] Borhen Marzougui, Kamel Barkaoui.
Interaction Protocols in Multi-Agent Systems based on Agent Petri Nets Model.
International Journal of Advanced Computer Science and Applications, Vol. 4,
No.7, 2013.
[Bou10] Boutaghane Rafika.
Test Automatique Des Préoccupations Dans Les Langages A Aspects .
Thése de magister université 20AOUT 1955-SKIKDA. ,2010 .
[Cor00] Corinne GRUSENMEYER.
Interactions maintenance/exploitation et fiabilité/sécurité des systèmes industriels.
Rapport de recherche, Janvier 2000, Institut national de recherche et de sécurité,N
ISSN 039 7 - 452 9.
[Dan04] DANIEL GALIN.
Software Quality Assurance From theory to implementation.
Angleterre ,2004, ISBN 0201 70945 7.
[Elb10] ELBAZ KHALIL.
49
Une méthode de développement d’architecture logicielle basée sur la notion d’as-
pect et orientée utilisateur.
Thèse de magister Université d’Oum el Bouaghi,2010.
[Fad96] Fadier E, Mazeau M.
L’activité humaine de maintenance dans les systèmes automatisés.
Journal Européen des Systèmes Automatisés Vol.30 N 10/1996.
[Fer99] Jacques Ferber.
Multi-Agent System : An Introduction to Distributed Artificial Intelligence.
Addison Wesley Longman,1999, ISBN 0-201-36048-9.
[Fla17] Flavio Trojan1, Rui F. M. Marçal.
Proposal of Maintenance-types Classification to Clarify Maintenance Concepts in
Production and Operations Management.
Journal of Business and Economics, July 2017, Volume 8, No. 7, pp. 560-572 .
[Gen97] Rapport de recherche ,Foundation for intelligent physical agents, 10th October,
1997.
[Ger00] Gerardo Canfora, Aniello Cimitile.
Software Maintenance.
Cours ,University of Sannio,29 November 2000.
[Ita16] Itamar Esdras Martínez García, Alejandro Sánchez Sánchez et Stefano Barbati.
Reliability and Preventive Maintenance.
January 2016, ISBN978-3-319-39095-6.
50
[IEE90]
Standard Glossary of Software Engineering Terminology.
The Institute of Eletrical and Electronics Engineers, USA, New York, 1990.
[ISO00] ISO9000.
Systèmes de management de la qualité – Principes essentiels et vocabulaire, Quality
management systems – Fundamentals and vocabulary.
December, 2000.
[ISO05] ISO/IEC 25000, ISO/IEC FDIS 25000
Systems and software engineering — Systems and software Quality Requirements
and Evaluation (SQuaRE).
December, 2000.
[Jea10] Jean Héng.
Pratique de la maintenance préventive.
3eme édition,Dunod Paris, 2011,ISBN 978-2-10-074550-0.
[Kát14] Káthia Marçal.
Software Quality Assurance by means of Methodologies, Measurements and Know-
ledge Management Issues.
Habilitation à Diriger des Recherches, University of Valenciennes and Hainaut-
Cambrésis, 30th June 2014.
[Kla13] Klaus Lochmann.
Defining and Assessing Software Quality by Quality Models.
Thèse de Doctorat, Université de Munich en allemand, 11 décembre 2013.
51
[Lep72] Leplat J, Savoyant A.
Fiabilité et sécurité : éléments pour une ergonomie des systèmes en milieu indus-
triel.
Communautés Européennes. Bruxelles (Direction générale),1972.
[Mar03] Marjorie LE BARS.
Un Simulateur Multi-Agent pour l’Aide à la Décision d’un Collectif.
Thèse de Doctorat, Université PARIS IX-Dauphine,France, 27 mai 2003.
[Mar15] Toufik MARIR.
Une demarche d’assurance qualité pour les systemes multi-agents.
Thèse de Doctorat,Université Badji Mokhtar Annaba ,27 juin 2015 .
[Mar18] Marir Toufik.
Les Systèmes Multi-Agents.
Cour , master 2, architecture distribuée, Université d’oum el bouaghi,2018.
[Pat14] Patricia Anthony, Chin Kim On, Dickson Lukose et al.
Agent Architecture : An Overview.
Transactions in science and technology 2014. Vol. 1, No 1, pp 18-35.
[Rei80] REID G. SMITH.
The Contract Net Protocol : High-Level Communication and Control in a Distribu-
ted Problem Solver.
IEEE Transaction on computers, VOL. C-29, NO. 12, December 1980.
[Ren04] Renaud Pawlak,Jean-Philippe Retaillé,Lionel Seinturier .
Programmation orientée aspect pour Java/J2EE,ISBN :2-212-11408-7,Code edi-
52
teur :G11408.
[Rog83] Roger J. Martin and Wilma M. Osborne.
Guidance on Software Maintenance.
National Bureau of Standards Washington, DC 20234, NBS Special Publication
500-106.
[Vil88] Villemeur A.
Sûreté de fonctionnement des Systèmes industriels.
Direction des études et recherches d’Electricité de France (EDF),Paris, Eyrolles,ISBN
978-2-212-01615-4.
[Woo95] Michael Wooldridge, Jörg Müller, Milind Tambe.
Intelligent Agents II : Agent Theories, Architectures, and Languages.
International Joint Conference on Artificial Intelligence ’95 Workshop : ATAL
(1995 : Montréal, Quebec).
[Zah96] Zahia Guessoum.
Un Environnement Opérationnel de Conception et de Réalisation de Systèmes Multi-
Agents.
Thèse de Doctorat, Université Pierre et Marie Curie, France,1996.
[Zak18] TOLBA Zakaria.
Une Nouvelle Approche de Planification Distribuée Dynamique : Application aux
problèmes DPDP.
Thèse de Master,Université d’oum el bouaghi ,2018.
[Zer10] ZERROUGUI Salim, OUDNI Abdelhamid.
53
Une approche de test des applications JADE basée sur le paradigme "ASPECT".
Thèse de Master,Université d’oum el bouaghi ,2010.
[Zer14] ZERROUGUI Salim.
Une approche pour l’extraction d’Aspects dans les Applications Multi-Agents .
Thèse de magister, Université d’oum el bouaghi ,2014.
54