Vers une approche de maintenance préventive des systèmes

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


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


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


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


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


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


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.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


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


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.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


• 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


• 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


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


• 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


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


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.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.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.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


• 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


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


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

Documents

Vers une approche de maintenance préventive des systèmes