Description des Besoins Fonctionnels des Systèmes Multi...

FACULTE DES SCIENCES DE L’INGENIEUR ANNEE 2010 DEPARTEMENT D’INFORMATIQUE

MEMOIREPrésenté en vue de l’obtention du diplôme de MAGISTER

Option

Intelligence Artificielle

Par

LAOUADI Mohamed Amin

DIRECTEUR DE MEMOIRE : Hassina SERIDI M. Conférences classe A U. Annaba

DEVANT LE JURY

PRESIDENT : Halima BAHI M. Conférences classe A U. Annaba

EXAMINATEURS : Habiba BELLEILI M. Conférences classe A U. Annaba

Yamina MED BENALI M. Conférences classe A U. Annaba

INVITE : Farid MOKHATI M. Conférences classe A U. Oum el Bouaghi

BADJI MOKHTAR-ANNABA UNIVERSITYUNIVERSITE BADJI MOKHTAR-ANNABA

ةـــــــــــــــعناب –جامعة باجي مختار

Description des Besoins Fonctionnels des Systèmes Multi-Agents Temps Réel à l’aide de Real Time Maude

وزارة الــتـعـلـیم الـعــالـي و الـبـحـث الـعـلـمـي

الملخص

في ھذا العمل، نقدم أسلوبا جدیدا للمواصفات الرسمیة للمتطلبات الوظیفیة " لألنظمة متعددة األعوان ذات الوقت الحقیقي". أوال ، ھذا النھج یسعى إلى الجمع بین مزایا عون لغة النموذج الموحدة و لغة المواصفات الرسمیة "آرتى مود" في أسلوب واحد. ھذا األسلوب یعتمد على عملیة الترجمة من المخططات الممددت لعون لغة النموذج الموحدة إلى مواصفات آرتى مود من خالل اإلطار الرسمي المقترح. الشئ الجدید في ھذه التقنیة ھو األخذ بالحسبان كل من الجوانب الوظیفیة، الثابتة، والدینامكیة " لأل نظمة متعددة األعوان ذات الوقت الحقیقي. الجوانب الوظیفیة یتم وصفھا عن طریق رسم تخطیطي لحالة استخدام لعون لغة النموذج الموحدة ذو الوقت الحقیقي ، من جانبھم الجوانب الثابتة للنظام سوف تمثل باستخدام رسم تخطیطي لفئة لعون لغة النموذج الموحدة ذو الوقت الحقیقي ، أما الجوانب الحیویة ھي من نوعین : السلوك الفردي لألعوان وكذا سلوكھم الجماعي. كال النوعین من السلوك تمثل على التوالي من قبل مخططات الحالة و البروتوكول. إذا المنھجیة التي نقترحھا تعتمد على األسالیب المبنیة على حاالت اإلستخدام التي یوفرھا عون لغة النموذج الموحدة و لغة المواصفات الرسمیة "آرتى مود". المثال الذي قمنا من خاللھ تطبیق ھذه المنھجیة ینتمي إلى میدان إدارة السالسل اللوجستیكیة.

األھداف التي وضعناھا لھذا المشروع ھي : (1) تحدید منھجیة لمساعدة المصممین إلضفاء الطابع الرسمي على المتطلبات الوظیفیة " لألنظمة متعددة األعوان ذات الوقت الحقیقي من خالل الجمع بین عون لغة النموذج الموحدة و لغة المواصفات الرسمیة "آرتى مود". (2) تحدید ما ھي تمثیالت عون لغة النموذج الموحدة التي ینبغي تعدیلھا لتأخذ في االعتبار القیود الزمنیة. (3) إثبات بأن عون لغة النموذج الموحدة یمكن تطبیقھا على أمثلة مھمة، في سیاقنا، اخترنا حالة إدارة سلسلة لوجستیكیة.

الكلمات الرئیسیة : مواصفات رسمیة ؛ األنظمة متعددة األعوان ذات الوقت الحقیقي ؛ االحتیاجات الوظیفیة ؛ عون لغة النموذج الموحدة ؛ آرتى مود ؛ منطق إعادة الكتابة ؛ إدارة السالسل اللوجستیكیة.

Abstract

In this manuscript, we present a new approach for the formal specification of functional requirements of real-time multi-agent system. Firstly, this approach seeks to combine the benefits of graphical modeling formalism Agent UML and formal specification language RT-Maude in a single technique. This technique is based on a process of translation from extended AUML diagrams to a formal notation RT-Maude through the formal framework proposed. The novelty brought the technique is to consider both the functional, static and dynamic of a real-time multi-agent system integrated manner. The functional aspects are described by a temporel AUML use case diagram, the static aspects of the system will be represented using a temporel AUML class diagram. For their part, the dynamic aspects are of two kinds: the behavior of individual agents and their collective behavior. Both types of behavior are represented respectively by state transition diagrams and extended AUML protocol diagrams. Therefore, the methodology we propose is based on modeling techniques based on existing use cases provided by the graphical modeling language Agent UML and the formal specification language RT-Maude. A case study from the field of supply chain management (SCM) accompanying the development methodology.

The goals we have set for this project are: (1) Define a methodology to help designers to formalize the functional requirements of real-time multi-agent system by combining the graphical modeling formalism AUML with the formal specification language Real Time Maude. (2) Establish what Agent UML representations should be modified to take account of time restrictions. (3) Prove Agent UML can be applied to real application, in our context we have chosen the supply chain management.

Keywords: Formal Specification; Real-Time Multi-Agent System ; Functional Requirements; Agent UML; Real-Time Maude; Rewriting Logic; Supply Chain Management (SCM).

Résumé

Dans ce mémoire, nous présentons une nouvelle approche pour la spécification formelle des besoins fonctionnels des systèmes multi-agents temps réel. Tout d’abord, cette approche se propose de combiner les avantages du formalisme de modélisation graphique Agent UML et du langage de spécification formelle RT-Maude dans une seule et unique technique. Cette technique est basée sur un processus de translation de diagrammes AUML étendu vers une notation formelle RT-Maude à travers le framework formel proposé. La nouveauté qu’apporte la technique est de considérer à la fois les aspects fonctionnels, statiques et dynamiques d’un système multi-agent temps réel de façon intégrée. Les aspects fonctionnels seront décrit par un diagramme de cas d’utilisation AUML temporisé, les aspects statiques du système seront représentés à l’aide d’un diagramme de classes AUML temporisé. Quant à eux, les aspects dynamiques sont de deux natures : le comportement individuel des agents, ainsi que leur comportement collectif. Ces deux types de comportement seront représentés respectivement par des diagrammes d’état transition et de protocole étendu AUML. Donc, la méthodologie que nous proposons est fondée sur les techniques de modélisation existantes basée sur les cas d’utilisation fournies par le langage de modélisation graphique Agent UML, ainsi que sur le langage de spécification formelle RT-Maude. Une étude de cas à partir du domaine de la gestion de chaine logistique (Supply Chain Management, ‘’SCM’’) accompagne l’élaboration de la méthodologie.

Les objectifs fixés pour ce projet sont les suivants : (1) Définir une méthodologie pour aider les concepteurs à formaliser les besoins fonctionnels des systèmes multi-agents temps réel en combinant le formalisme de modélisation graphique AUML avec le langage de spécification formel Real Time Maude. (2) Déterminer quelles représentations d’Agent UML sont à modifier pour tenir compte des restrictions temporelles. (3) Montrer qu’Agent UML peut être appliqué à des applications grandeur nature, dans notre contexte nous avons choisi la gestion de chaîne logistique (ou Supply Chain Management ‘’SCM’’).

Mots clés : Spécification formelle; Système Multi-Agents temps réel; Besoins Fonctionnels ; AgentUML; Real-Time Maude ; Logique de réecriture ; Supply Chain Management (SCM).

Je dédie ce Mémoire

À ma famille qui m’a soutenu tout au long de mes études, et à mes amis.

Laouadi Mohamed Amin

Remerciements

Il est toujours délicat de remercier l’ensemble des personnes qui ont contribuées à l’aboutissement de ce travail de recherche. Que ceux qui ne sont pas mentionnés ne m’en tiennent pas rigueur.

Je tiens à exprimer mes profonds remerciements à Mme. SERIDI- BOUCHELAGHEM Hassina, Maître de Conférences à l’Université Badji Mokhtar Annaba, pour son encadrement, sa disponibilité, sa confiance et pour le soutien qu’elle a su m’accorder. Son expérience et ses compétences scientifiques ont toujours été sources d’enrichissement me permettant de mener à bien ce travail de recherche.

Je désire sincèrement remercier Mr. MOKHATI Farid, Maitre de Conférences à l’Université de Oum-el bouaghi, pour avoir eu le privilège d’être son étudiant. Ses qualités scientifiques, ses conseils et son dynamisme ont contribués à l’aboutissement de ce travail de recherche. Je le remercie pour la grande confiance qu’il m’a accordée et pour la vision innovante de la recherche qu’il a toujours su m’inculquer.

Je tiens à remercier chaleureusement Mme. BELLEILI Habiba, Maître de Conférences à l’Université Badji Mokhtar Annaba, et Mme. MOHAMED BENALI Yamina, Maître de Conférences à l’Université Badji Mokhtar Annaba, pour avoir acceptés de rapporter mon document de thèse et de m’avoir apportés leur regard sur mon travail.

Je remercie Mme. BAHI Halima, Maître de Conférences à l’Université Badji Mokhtar Annaba de m’avoir honoré en acceptant de présider mon jury.

Enfin, de manière plus personnelle, je souhaite remercier ma famille pour leur soutien inconditionnel. Merci pour m’avoir encouragé, supporté et pour avoir accepté tant de sacrifices durant ces années.

Liste des Tableaux

TAB TITRE PAGE

1.1. CONTEXTE/OBJECTIVES ET PRINCIPALES PHASES DES METHODOLOGIES DE CONCEPTION DES SMATEMPS REEL

19

1.2. APPROCHES D’IDENTIFICATION/DEFINITION D’AGENTS TEMPS REEL. 19

1.3. COMPARAISON GENERALE 21

Liste des Figures

FIG TITRE PAGE

1.1. ARCHITECTURE D’AGENT 10

1.2. VUE CANONIQUE D’UN SMA 11

1.3. CARACTERISATION D’UN SMA 12

2.1. DIAGRAMME DE CAS D’UTILISATION D’UN AGENT CLIENT 29

2.2. EXEMPLE DE CAS D’UTILISATION AVEC 1 ACTEUR ET 3 CAS D’UTILISATION 30

2.3. SCENARIO REPRESENTE PAR UNE NOTE ASSOCIEE AU CAS D'UTILISATION 31

2.4. RELATIONS ENTRE CAS D'UTILISATION : UC2 HERITE DE UC1, UC2 INCLUT UC3, UC4 ETEND UC2 31

2.5. RELATION "INCLUDE" ENTRE CAS D'UTILISATION 32

2.6. RELATION "EXTEND" ENTRE CAS D’UTILISATION 33

2.7. EXEMPLE D’UN EVENEMENT DECLENCHANT UNE TRANSITION 36

3.1. VISUALISATION DES REGLES D’INFERENCE D’UNE THEORIE DE REECRITURE 41

3.2. LE MODULE SYSTÈME BANK-ACCOUNT 49

3.3. LE MODULE ORIENTE-OBJET BANK-ACCOUNT 50

3.4. L'EXECUTION DU MODULE BANK-ACCOUNT 50

3.5. LE MODULE TEMPORISE DISCRETE-CLOCK-1 53

3.6. LE MODULE TEMPORISÉ DISCRETE-BROKEN-CLOCK-1 54

3.7. LE MODULE TEMPORISE DISCRETE-CLOCK-24-2 54

3.8. LE MODULE TEMPORISE DISCRETE-CLOCK-24 54

3.9. LE MODULE TEMPORISE DENSE-CLOCK-1 55

3.10. LE MODULE TEMPORISE ORIENTE-OBJET RTT-1 56

3.11. LE MODULE TEMPORISE ORIENTE-OBJET DISCRETE-RTT-1 56

4.1. AGENT 61

4.2. AGENT EXTERNE 62

4.3. AGENT TEMPS REEL 62

4.4. CAS D’UTILISATION POUR AGENTS 62

4.5. CAS D’UTILISATION POUR AGENTS TEMPS REEL 62

4.6. DIAGRAMME DE CLASSE AUML PROPOSE 63

4.7. LE PROTOCOLE CONTRACT NET DANS AGENT UML 65

4.8. LA GESTION DU TEMPS DANS LES DIAGRAMMES DE PROTOCOLES 65

4.9. METHODOLOGIE DE L’APPROCHE 67

4.10. LA DESCRIPTION DU MODE D’INTERACTION ‘AND’ DANS RT-MAUDE 68

4.11. LA DESCRIPTION DU MODE D’INTERACTION 'INCLUSIVE OR' DANS RT-MAUDE 68

4.12. LA DESCRIPTION DU MODE D’INTERACTION 'EXCLUSIVE OR’ DANS RT-MAUDE 68

4.13. LES MODULES GENERES PAR LE PROCESSUS DE TRANSLATION 69

4.14. LE MODULE FONCTIONNEL STATE 69

4.15. LE MODULE FONCTIONNEL ACTION 70

4.16. LE MODULE FONCTIONNEL CONDITION 70

4.17. LE MODULE FONCTIONNEL STATE-OPERATIONS 70

4.18. LE MODULE FONCTIONNEL AGENTI-BEHAVIOR 70

4.19. LE MODULE FONCTIONNEL LINKED-BEHAVIOR 71

4.20. LE MODULE ORIENTE OBJET IDENTIFICATION 71

4.21. LE MODULE ORIENTE OBJET MESSAGE 71

4.22. LE MODULE FONCTIONNEL MAILBOX 71

4.23. LE MODULE FONCTIONNEL AQUAINTANCE-LIST 72

4.24. LE MODULE FONCTIONNEL ROLE 73

4.25. LE MODULE OO MESSAGE-MANAGEMENT 73

4.26. LE MODULE OO EXTERNAL-AGENT-CLASS 73

4.27. LE MODULE OO AGENT-CLASS 73

4.28. LE MODULE OO TEMPORISÉ REAL-TIME-AGENT-CLASS 74

4.29. LE MODULE OO EXTERNAL-AGENTS 74

4.30. LE MODULE OO AGENTS 74

4.31. LE MODULE OO TEMPORISÉ REAL-TIME-AGENTS 74

4.32. UN MODULE ORIENTE OBJET TEMPORISE DECRIVANT UN CAS D'UTILISATION 74

4.33. LE MODULE ORIENTE OBJET TEMPORISE RTMAS-FUNCTIONAL-REQUIREMENTS 75

4.34. SPECIFICATION RT-MAUDE DE DEUX CAS D'UTILISATION RELIES PAR LA RELATION D’INCLUSION 75

4.35. SPECIFICATION RT-MAUDE DE DEUX CAS D'UTILISATION RELIES PAR LA RELATION D’EXTENSION 75

4.36. SPECIFICATION RT-MAUDE DE DEUX CAS D'UTILISATION RELIES PAR LA RELATION DE

GENERALISATION

76

5.1. LA GESTION DE CHAINE LOGISTIQUE 78

5.2. LA GESTION DE CHAINE LOGISTIQUE SELON UNE APPROCHE MULTI-AGENTS 80

5.3. DIAGRAMME DE CAS D’UTILISATION AUML TEMPORISE DU ‘’SCM’’ 80

5.4. DIAGRAMME DE CLASSE DU SCM (LE NIVEAU CONCEPTUEL) 81

5.5. DIAGRAMME DE CLASSE DU SCM (LE NIVEAU IMPLEMENTATION) 81

5.6. DIAGRAMME DE PROTOCOLE DU CAS D’UTILISATION ‘’PLACE ORDRE’’ 82

5.7. DIAGRAMME DE PROTOCOLE DU CAS D’UTILISATION ‘’MODIFY ORDRE’’ 82

5.8. DIAGRAMME DE PROTOCOLE DU CAS D’UTILISATION ‘’DELETE ORDRE’’ 83

5.9. STATE-CHART DE L’AGENT EXTERNE ‘’CLIENT’’ 83

5.10. STATE-CHART DE L’AGENT ‘’ORDRE ’ACQUISITION’’ 83

5.11. STATE-CHART DE L’AGENT TEMPS REEL ‘’LOGISTICS’’ 84

5.12. STATE-CHART DE L’AGENT TEMPS REEL ‘’SCHEDULER’’ 84

5.13. STATE-CHART DE L’AGENT ‘’TRANSPORTER’’ 84

5.14. STATE-CHART DE L’AGENT ‘’DISPATCHER’’ 85

5.15. STATE-CHART DE L’AGENT ‘’RESOURCE’’ 85

5.16. STATE-CHART DE L’AGENT EXTERNE ‘’PROVIDER’’ 85

5.17. LE MODULE FONCTIONNEL CLIENT-BEHAVIOR QUI CORRESPOND A L’AGENT EXTERNE

‘’CLIENT’’86

5.18. LE MODULE FONCTIONNEL ORDRE-ACQUISITION-BEHAVIOR QUI CORRESPOND A L’AGENT

‘’ORDRE-ACQUISITION’’86

5.19. LE MODULE FONCTIONNEL LOGISTICS-BEHAVIOR QUI CORRESPOND A L’AGENT TEMPS REEL

‘’LOGISTICS’’87

5.20. LE MODULE FONCTIONNEL SCHEDULER-BEHAVIOR QUI CORRESPOND A L’AGENT TEMPS REEL

‘’SCHEDULER’’87

5.21. LE MODULE FONCTIONNEL TRANSPORTER-BEHAVIOR QUI CORRESPOND A L’AGENT

‘’TRANSPORTER’’88

5.22. LE MODULE FONCTIONNEL DISPATCHER-BEHAVIOR QUI CORRESPOND A L’AGENT

‘’DISPATCHER’’88

5.23. LE MODULE FONCTIONNEL RESSOURCE-BEHAVIOR QUI CORRESPOND A L’AGENT

‘’RESSOURCE’’88

5.24. LE MODULE FONCTIONNEL PROVIDER-BEHAVIOR QUI CORRESPOND A L’AGENT EXTERNE

‘’PROVIDER’’89

5.25. LE MODULE FONCTIONNEL LINKED-BEHAVIORS 89

5.26. LE MODULE FONCTIONNEL ROLE 90

5.27. LE MODULE ORIENTE OBJET EXTERNAL-AGENTS 90

5.28. LE MODULE ORIENTE OBJET AGENTS 91

5.29. LE MODULE ORIENTE OBJET TEMPORISE PLACE-ORDRE 93

5.30. TICK RULE DE L’AGENT TEMPS REEL ‘’ LOGISTICS’’ 97

5.31. TICK RULE DE L’AGENT TEMPS RÉEL ‘’ SCHEDULER’’ 97

5.32. LE MODULE ORIENTE OBJET TEMPORISE MODIFY-ORDRE 97

5.33. LE MODULE ORIENTE OBJET TEMPORISE DELETE-ORDRE 98

5.34. LE MODULE ORIENTE OBJET TEMPORISE RTMAS-FUCTIONAL-REQUIREMENS 99

5.35. CONFIGURATION INITIALE 1 100

5.36. EXECUTION DU CONFIGURATION INITIALE1 101

5.37. CONFIGURATION INITIALE2 101

5.38. EXECUTION INTERMIDIERE DU CONFIGURATION INITIALE 2 102

5.39. EXECUTION DU CONFIGURATION DE LA FIGURE 5.38 102

5.40. CONFIGURATION INITIALE 3 103

5.41. EXECUTION DU CONFIGURATION INITIALE 3 103

Table des matières

Introduction Générale .......................................................................................................................................... 1

1. CONTEXTE DE LA RECHERCHE ................................................................................................................................. 2

2. MOTIVATIONS ............................................................................................................................................................. 3

3. OBJECTIFS SCIENTIFIQUES........................................................................................................................................... 4

4. DEMARCHE SUIVIE....................................................................................................................................................... 4

5. ORGANISATION DU MANUSCRIT .............................................................................................................................. 5

Chapitre 1 : Les Systèmes Multi-Agents Temps Réel .......................................................................... 6

RESUME …………………………………………………............................…………………………………….……. 7

INTRODUCTION …………………………………………………………............................………………….…… 8

1. LES SYSTEMES MULTI-AGENTS........................................................................................................................... 9

1.1. LE CONCEPT D’AGENTS …..………………………………………………..……………..............................…. 9

1.2. LES SYSTEMES MULTI-AGENTS …………………………………………………………………....................... 10

1.3. ENVIRONNEMENT …………………………………………............................……………………………….. 11

1.4. INTERACTION …………………………………………………………………............................……………. 11

1.5. ORGANISATION …………………………………………………………………………….............................. 11

1.6. APPROCHE ORIENTEE-AGENT ET APPROCHE ORIENTEE-OBJET …………………………............................… 12

1.7. AVANTAGES ET INCONVENIENTS DE L’APPROCHE CENTREE SUR L’AGENT ………………............................ 13

1.7.1. LA MODELISATION DES SYSTEMES …………………………...…………………………....................... 13

1.7.2. LATOLERANCE AUX FAUTES ……………………………………………………………....................... 13

1.7.3. L’AUTONOMIE DES SYSTEMES …………………….…………………………………............................ 14

1.7.4. AUTRES AVANTAGES ……………………………………………………………….............................. 14

1.7.5. LES DIFFICULTES DE L’APPROCHE ORIENTEE-AGENT ……………………………………..................... 14

1.7.5.1. METHODOLOGIES NON-STANDARDISEES ……………………….............................……….. 14

2. LES SYSTEMES TEMPS REEL ........................................................................................................................... 15

2.1. DEFINITION …………………………………………………............................…………………………. 15

2.2. LES CARACTERISTIQUES D’UN SYSTEME TEMPS REEL …………………………………............................ 16

3. LES SYSTEMES MULTI-AGENTS TEMPS REEL .......................................................................................... 16

3.1. INTRODUCTION ........................................................................................................................................... 16

3.2. DEFINITION ................................................................................................................................................ 17

4. TRAVAUX SIMILAIRES ..................................................................................................................................... 17

4.1. INTRODUCTION ............................................................................................................................................ 17

4.2. ANALYSE DES METHODOLOGIES DE DEVELOPPEMENT DES SMA-TEMPS REEL ....................................... 18

5. CONCLUSION ...................................................................................................................................................... 22

Chapitre 2 : AUML & La Modélisation des Systèmes à base D’Agents ................................... 23

RESUME ......................................................................................................................................................................... 24

INTRODUCTION ........................................................................................................................................................ 25

1. LE LANGAGE DE MODELISATION AUML ............................................................................................... 26

1.1. RAPPEL SUR AUML ........................................................................................................................................... 26

1.2. LES INCOHERENCES DU LANGAGE AUML........................................................................................................ 27

2. LES PRINCIPALES REPRESENTATIONS D’AGENT UML ....................................................................... 27

2.1. LES DIAGRAMMES DE CAS D’UTILISATION AUML ......................................................................................... 28

2.1.1. INTRODUCTION ...................................................................................................................................... 28

2.1.2. LES ACTEURS ........................................................................................................................................... 30

2.1.3. LES CAS D'UTILISATION .......................................................................................................................... 30

2.1.4. LES SCENARIOS ........................................................................................................................................ 31

2.1.5. LES RELATIONS ENTRE CAS D'UTILISATION ........................................................................................... 31

2.1.5.1. LA RELATION D'INCLUSION ................................................................................................. 32

2.1.5.2. LA RELATION D'EXTENSION .................................................................................................. 32

2.1.5.3. LA RELATION D'HERITAGE ................................................................................................... 33

2.2. LES DIAGRAMMES DE CLASSE AUML ETENDUS ............................................................................................ 33

2.3. LES DIAGRAMMES DE PROTOCOLE AUML ETENDUS ................................................................................... 35

2.4. LES DIAGRAMMES D’ETAT TRANSITION AUML ............................................................................................. 35

3. CONCLUSION ...................................................................................................................................................... 37

Chapitre 3 : Real-Time Maude ........................................................................................................................ 38RESUME ............................................................................................................................................................................ 39

1. INTRODUCTION........................................................................................................................................... 39

2. MAUDE...................................................................................................................................................................41

2.1 CARACTERISTIQUES DE MAUDE......................................................................................................................42

2.2 CONCEPTS DE BASE...........................................................................................................................................42

2.2.1 Sortes................................................................................................................................................................422.2.2 Sous-sortes......................................................................................................................................................432.2.3 Opérations.......................................................................................................................................................432.2.4 Variables..........................................................................................................................................................44

2.3 LES MODULES FONCTIONNELS.........................................................................................................................45

2.3.1 Équations inconditionnelles........................................................................................................................45

2.3.2 Équations conditionnelle.............................................................................................................................452.3.3 Attributs équationnels..................................................................................................................................46

2.4 LES MODULES SYSTEMES..................................................................................................................................46

2.4.1 Règles de réécriture.......................................................................................................................................472.4.2 Règles non conditionnelles de réécriture ..................................................................................................472.4.3 Règles conditionnelles de réécriture .........................................................................................................48

2.5 LES MODULES ORIENTES-OBJET........................................................................................................................48

3. REAL TIME-MAUDE (RTMaude)............................................................................................................. 50

3.1 LES MODULES TEMPORISES (TIMED MODULES)...............................................................................................51

3.1.1 Les Domaines de Temps (Time Domains) ................................................................................................513.1.2 Les règles Tick................................................................................................................................................53

3.2 EXEMPLES DE MODULES TEMPORISES : MODELISATION D’UNE HORLOGE....................................................53

3.3 LES MODULES TEMPORISES ORIENTES-OBJET (TIMED OBJECT-ORIENTED MODULES).................................55

4. CONCLUSION.....................................................................................................................................................56

Chapitre 4 : Formalisation des Besoins Fonctionnels des SMA-Temps Réel ..................... 57RESUME ......................................................................................................................................................................... 58

1. INTRODUCTION ................................................................................................................................................. 59

2. L’APPROCHE PROPOSEE .................................................................................................................................. 60

2.1. INTRODUCTION .................................................................................................................................................. 60

2.2. LES DIAGRAMMES DE CAS D’UTILISATION AUML TEMPORISES (ASPECT FONCTIONNEL) ........................... 61

2.3. LES DIAGRAMMES DE CLASSE AUML TEMPORISES (ASPECT STRUCTUREL) .................................................. 63

2.4. LES DIAGRAMMES DE PROTOCOLES AUML ETENDU (COMPORTEMENT COLLECTIF) ................................... 64

2.5. LES DIAGRAMMES D’ETAT TRANSITION AUML (COMPORTEMENT INDIVIDUEL) ......................................... 65

3. PROCESSUS DE TRANSLATION PROPOSE ............................................................................................... 66

3.1. TRANSLATION DES DIAGRAMMES AUML VERS UNE SPECIFICATION FORMELLE RT-MAUDE

............................................................................................................................................................................. 66

3.2. LA DESCRIPTION DES DIFFERENTS MODES D'INTERACTION ENTRE AGENTS .................................................... 68

3.3. ARCHITECTURE DU FRAMEWORK PROPOSE ..................................................................................................... 69

3.4. LES RELATIONS ENTRE CAS D’UTILISATION DANS RT-MAUDE ....................................................................... 75

4. CONCLUSION …..………………………………………………………………………………………………. 76

Chapitre 5 : Etude de Cas : ‘’Gestion de Chaîne Logistique’’ ……………………..................... 77INTRODUCTION ……………………………………………………………………………………...…………….. 78

1. PRESENTATION …………………………………………..................................................................................... 78

2. APPLICATION DU PROCESSUS DE TRANSLATION ................................................................................... 79

2.1. LA DECOMPOSITION AGENTS DE LA GESTION DE CHAINE LOGISTIQUE ................................................... 79

2.2. MODELISATION DE L’EXEMPLE AVEC LES DIAGRAMMES AUML ETENDUES ........................................... 80

2.2.1. LE DIAGRAMME DE CAS D’UTILISATION AUML TEMPORISE DU ‘’SCM’’ .................................. 80

2.2.2. LE DIAGRAMME DE CLASSE AUML TEMPORISE DU ‘’SCM’’ ....................................................... 81

2.2.3. LES DIAGRAMMES DE PROTOCOLE AUML ETENDU DU ’’SCM ‘’ ................................................ 82

2.2.4. LES DIAGRAMMES D’ETAT TRANSITION AUML DU ’’SCM ‘’ ..................................................... 83

2.3. GENERATION DE SPECIFICATION RT-MAUDE ............................................................................................ 86

2.4. VALIDATION DE LA DESCRIPTION GENEREE ............................................................................................. 99

3. CONCLUSION ........................................................................................................................................................ 104

CONCLUSION & PERSPECTIVES ........................................................................................................... 105

BIBLIOGRAPHIE ................................................................................................................................................ 107

1

Introduction Générale


2

Dans ce qui suit, nous présentons le contexte général de notre travail de recherche et les motivations qui les sous-tendent. Nous présentons ensuite les objectifs et la démarche suivie pour les atteindre. Nous terminons par une description de l’organisation du reste de ce manuscrit.

1. Contexte de la recherche

Notre travail de recherche se place naturellement dans le contexte du génie logiciel et de l’intelligence artificielle distribuée où nous nous occupons de plus pré de l’aspect génie logiciel dans le développement des SMA temps réel ; dès lors, il est devenu impératif de s’investir dans les méthodologies orientées-agents. Les systèmes multi-agents temps réel sont actuellement très largement utilisés, particulièrement pour les applications complexes nécessitant l’interaction entre plusieurs entités ayant des restrictions temporelles à respecter. Plusieurs méthodologies ont été proposées pour le développement des SMA temps réel. Cependant, ces méthodologies qui constituent soit une extension des méthodologies orientées objet, soit une extension des méthodologies orientées-agent, demeurent insuffisantes pour la formalisation des besoins fonctionnels des SMA temps réel. Par ailleurs, peu d’effort ont été déployés en matière de standardisation des méthodes de conception des SMA. Il apparaît donc évident que le développement des SMA temps réel reste encore un domaine ouvert. Le succès du paradigme orienté-agent exige des méthodologies systématiques pour la spécification et la conception des SMA temps réel.

Plusieurs techniques d’analyse sont utilisées en génie logiciel pour la spécification des besoins. Allant du simple langage naturel de spécification des besoins aux méthodes formelles qui utilisent des langages mathématique.

L’analyse basée sur les cas d’utilisation (Use case analysis) est une technique particulière qui a fait ses preuves pour la spécification des besoins de différents types de système. Ce type d’analysea gagné de l’ampleur puisqu’il fait partie du langage de modélisation unifié UML [Boo99], et par conséquent Agent UML.

Selon [Pap00], l’approche guidée par les cas d’utilisation pour le développement de systèmes a plusieurs bénéfices : un cas d’utilisation est une vue de la fonctionnalité du système du point de vue de l’utilisateur ; il peut être considéré comme une collection de scénarios d’utilisation du système. Développeurs et utilisateurs utilisent souvent les scénarios pour les aider à comprendre les besoins. Ces besoins peuvent être spécifiés par des termes non techniques que l’utilisateur peut comprendre sans pour autant être un ingénieur logiciel (Software Engineer). Enfin la traçabilité des besoins à travers les phases de conception, d’implémentation et de tests du projet est améliorée.

Le génie logiciel orienté agent (Agent Oriented Software Engineering ’’AOSE’’) exige la spécification des comportements des agents afin de fournir des besoins documentés pour les phases de conception et d’implémentation. D’une façon générale, il y’a deux nouvelles classes de génie logiciel orienté agent. La première classe est intéressée par la ‘’construction des systèmes logiciels’’ et voit les agents comme un outil d’abstraction utile pour la spécification, la conception, et la documentation de ces systèmes [Hei00]. La deuxième classe est basée sur ‘‘les technologies de génie logiciel’’ pour développer les systèmes multi-agent. Nous nous intéressons à cette deuxième classe.


3

Cependant, depuis maintenant de nombreuses années, les concepteurs des systèmes multi-agent disposent de méthodologies de développement et de langage de modélisations sans pour autant tenir compte des différentes restrictions temporelle que peut avoir ces systèmes. De plus, même les méthodologies proposées pour le développement des SMA temps réel tels que: RT-Message [Jul04b]; BDI-ASDP étendue pour le temps réel [Mel05]; et la Méthode de développement de Lichen Zhang [Zha06], présentent des insuffisances. De ce fait, la méthodologie que nous proposons est fondée sur les techniques de modélisation existantes basées sur les cas d’utilisation fournies par le langage de modélisation graphique Agent UML, ainsi que sur le langage de spécification formelle RT-Maude. Une étude de cas à partir du domaine de la gestion de chaine logistique (Supply Chain Management, ‘’SCM’’) accompagne l’élaboration de la méthodologie.

2. Motivations

Une tendance récente dans le développement des systèmes distribués temps réel, est l’utilisation des systèmes multi-agents temps réel. A l’opposé des SMA classiques, les SMA temps réel tiennent compte des caractéristiques intrinsèques des systèmes temps réel, plus spécialement, les contraintes temporelles. Durant ces dernières années, plusieurs méthodologies de développement des systèmes multi-agents (RT-Message [Jul04b], BDI-ASDP étendue pour le temps réel [Mel05], et la Méthode de développement de Lichen Zhang [Zha06]) ont émergées dans la littérature dans le but de faciliter le développement des applications multi-agents temps réel. Ces méthodologies ont certes apportés des réponses importantes au processus de développement des SMA temps réel. Cependant, l’aspect méthodologique n’est pas encore maîtrisé. En effet, aucune de ces méthodologies ne tiennent compte de la formalisation des besoins fonctionnels du futur système. Formaliser les besoins fonctionnels des SMA temps réel est à notre avis, une tâche d’importance extrême notamment pour les activités de vérification et de validation.

Néanmoins, La conception des systèmes multi-agent exige de l’associer avec des techniques du génie logiciel. Parmi ces techniques, UML [Boo99], qui est certainement le plus connu et le plus utilisé des langages de modélisation orienté objet. Les concepteurs de systèmes multi-agents disposent depuis peu des mêmes facilités en particulier avec le langage Agent UML [Bau00b] [Ode00]. Cependant, il n’existe pas à l’heure actuelle de travaux qui appliquent Agent UML à la spécification des SMA temps réel d’une part et à des applications réelles d’autre part.

Le langage AUML (langage semi-formel de modélisation graphique) est à notre avis le futur standard de l’industrie pour le développement des systèmes orientés agents. Il permet de modéliser et de décrire plusieurs vues complémentaires d’un même système. AUML comme UML souffre, cependant, d’un manque de sémantique formelle. Les modèles AUML développés pourront donc contenir des incohérences ou des inconsistances difficiles (voire impossibles dans le cas de certains systèmes complexes) à détecter manuellement.

Les méthodes formelles représentent une solution intéressante à ce problème. Les spécifications formelles auront pour effet d’éliminer les ambigüités au niveau de l’interprétation des modèles. La combinaison d’Agent UML avec un langage de spécification formelle éprouvé comme Real time Maude permettra de valider formellement les modèles AUML développés.

Notre objectif général étant de proposer une approche générique pour une spécification orientée cas d’utilisation des besoins fonctionnels des SMA temps réel. En se concentrant sur la formalisation des besoins fonctionnels du futur système pour contraindre les limites de développement, la


4

méthodologie que nous proposons diffère des autres méthodologies de modélisation par l’usage d’extensions au langage de modélisation graphique AUML en tenant compte bien sur, les travaux de Huget [Hug02c] [Hug02b], et Odell, Parnauk, Bauer [Ode00] qui présentent une vue du développement orienté agent qui allie attentivement les expériences de développement orienté objet.

3. Objectifs scientifiques

Les objectifs que nous avons poursuivis au cours de ce mémoire sont les suivants : (1) Définir une méthodologie pour aider les concepteurs à formaliser les besoins fonctionnels des systèmes multi-agents temps réel en combinant le formalisme de modélisation graphique AUML avec le langage de spécification formel Real Time Maude. (2) Déterminer quelles représentations d’Agent UML sont à modifier pour tenir compte des contraintes temporelles. (3) Montrer qu’Agent UML peut être appliqué à des applications grandeur nature, dans notre contexte nous avons choisi la gestion de chaîne logistique (ou Supply Chain Management ‘’SCM’’).

Donc, notre intérêt principale est de développer un cadre formel permettant la description des besoins fonctionnels des SMA temps réel, en utilisant les quatre types de diagrammes AUML : les diagrammes de classes (modélisant l’aspect statique d’un système), de cas d’utilisation (modélisant les besoins fonctionnels du système), d’état transition (comportement individuel des agents), et de protocole (modélisant le flux de messages échangés entre agents), que nous avons essayé d’étendre afin de prendre en compte les contraintes temporelles liées aux agents temps réels. Ces modèles AUML développés seront par la suite translatés vers des descriptions formelles en langage RT-Maude. L’approche développée a été évaluée sur un exemple concret qui est: la gestion de chaîne logistique (ou Supply Chain Management).

4. Démarche suivie

Dans ce mémoire, une nouvelle approche pour la formalisation des besoins fonctionnels des systèmes multi-agents temps réel est présentée. Tout d’abord, cette approche se propose de combiner les avantages du formalisme de modélisation graphique Agent UML et du langage de spécification formelle RT-Maude dans une seule technique. Cette technique est basée sur un processus de translation en trois étapes : (1) Description du système multi-agent temps réel à l’aide des quatre représentations semi-formelles AUML considérées; (2) Validation inter-diagrammes ; et (3) Génération de descriptions formelles RT-Maude à travers le framework formel proposé. Ce framework est composé de plusieurs modules : neuf modules fonctionnels, sept modules orienté objet, et quatre modules orienté objet temporisé.

La nouveauté qu’apporte la technique est de considérer conjointement les aspects fonctionnels, statiques et dynamiques d’un système multi-agent temps réel. Les aspects fonctionnels seront décrit par un diagramme de cas d’utilisation AUML temporisé, les aspects statiques du système seront représentés à l’aide d’un diagramme de classes AUML temporisé. Quant à eux, les aspects dynamiques sont de deux natures : le comportement individuel des agents, ainsi que leur comportement collectif. Ces deux types de comportement seront représentés respectivement par des diagrammes d’état transition et de protocole étendu AUML. Donc, la méthodologie que nous


5

proposons est fondée sur les techniques de modélisation existantes basées sur les cas d’utilisation fournies par le langage de modélisation graphique Agent UML, ainsi que sur le langage despécification formelle RT-Maude. Une étude de cas à partir du domaine de la gestion de chaine logistique (Supply Chain Management, ‘’SCM’’) accompagne l’élaboration de la méthodologie.

5. Organisation du manuscrit

Ce mémoire est divisé en cinq chapitres. Le chapitre 1 présente de façon détaillée les systèmes multi-agents temps réel et propose la revue de quelques méthodologies de développement de SMA temps réel. Le chapitre 2 présente une revue approfondie du formalisme de modélisation graphique Agent UML, des principes sous-jacents et de diverses approches qui le considère. Le chapitre 3 propose une revue de l’environnement Real Time Maude et de sa logique sous-jacente (la logique de réécriture). L’approche proposée ainsi que l’étude de cas réalisée dans ce mémoire sont discutées aux chapitres 4 et 5 respectivement. Cette étude de cas, servira à évaluer l’approche proposée. Par la suite, quelques remarques d’évaluation et quelques conclusions sont tirées.

6

Chapitre 1

Les Systèmes Multi-Agents

Temps Réel

Les Systèmes Multi-Agents Temps Réel

7

Résumé

L’application des systèmes multi-agents aux environnements temps réel est une voie très intéressante de travail qui peut fournir de nouvelles solutions aux systèmes complexes et restrictifs comme les systèmes temps réel. L’utilisation du paradigme agent dans des scénarios temps réel provient des propriétés des nouveaux systèmes temps réel (tel que l’intelligence et la distribution). Ce paradigme essaye d’incorporer la flexibilité, l’adaptabilité et la distribution dans un frameworktemps réel. Une méthode appropriée pour le développement des systèmes multi-agent temps réel doit prendre en compte les caractéristiques intrinsèques de ce type de système. Souvent, il est essentiel d’analyser les besoins dans le comportement global du SMA en relation avec les propriétés comportementales des agents, afin de développer un système avec des propriétés correctes.

Les systèmes d’intelligence artificiel temps réel (SIATR) ont émergés comme des techniques utiles pour résoudre des problèmes complexes nécessitant de l’intelligence et une réaction temps réel [Mel05]. Le développement des systèmes temps réel quant à lui a suivi le mode de distribution, principalement parce qu’un grand nombre d’applications temps réel sont fondamentalement distribuées et dynamiques.

Dans ce chapitre, nous commençons tout d’abord par introduire les concepts de base qui découlent du domaine de recherche que constituent les systèmes multi- agents (section 1), ainsi que leurs avantages et inconvénient. Ensuite, nous allons présenter brièvement les systèmes temps réel (section 2), pour passer à la description des systèmes multi-agents temps réel, en les définissant et en évoquant leur utilisation (section 3). Nous étudierons par la suite trois des principales méthodologies de développement des SMA temps réel que nous avons recensées de la littérature (section 4). Il y a, parmi celles-ci, certaines sur lesquelles nous ne possédons pas assez d’informations alors nous nous permettons de faire une étude plus détaillée. Il nous semble cependant que ces méthodologies sont les plus représentatives des méthodologies de développement des SMA temps réel existantes.


8

Introduction

La technologie agent a suscité beaucoup d’attention ces dernières années, en conséquence,l’industrie commence à s’intéresser et à employer cette technologie. Cependant très peu de travaux se sont intéressés aux techniques de développement utilisant la technologie d’agent. De ce fait, un nouveau thème de recherche, celui de l’ingénierie logicielle orientée agent (i.e. AOSE), s’est développé ces dernières années. L’objectif principal de l’ingénierie logicielle orientée agent, est de développer des méthodologies et des outils qui facilitent le développement et la maintenance des applications multi-agents [Tve01]. Nous trouvons dans le domaine de l’ingénierie logicielle, trois activités de recherche [Cer05] : (i) le développement d’outils conceptuels (outils de notation ou de modélisation formelle), (ii) le développement des outils d’assistance au cours du processus du développement (les CASE tools) et (iii) les méthodologies multi-agents.

Nous nous intéressons aux méthodologies multi-agents. Le rôle de ces méthodologies est d’assurer l’assistance durant toutes les phases du cycle de vie d’une application basée sur les agents [Tar06].

Notre travail de recherche se place naturellement dans le contexte du génie logiciel et de l’intelligence artificielle distribuée où nous nous occupons de plus pré de l’aspect génie logiciel dans le développement des SMA temps réel ; dés lors, il est devenu impératif de s’investir dans les méthodologies orientées-agents.

Les systèmes multi-agents temps réel sont actuellement très largement utilisés, particulièrement pour les applications complexes nécessitant l’interaction entre plusieurs entités ayant des restrictions temporelles à respecter. Plusieurs méthodologies ont été proposées pour le développement des SMA temps réel. Cependant, ces méthodologies qui constituent soit une extension des méthodologies orientées objet, soit une extension des méthodologies orientées-agent, demeurent insuffisantes pour la formalisation des besoins fonctionnels des SMA temps réel. Par ailleurs, peu d’efforts ont été déployés en matière de standardisation des méthodes de conception des SMA. Il apparaît donc évident que le développement des SMA temps réel reste encore un domaine ouvert. Le succès du paradigme orienté-agent exige des méthodologies systématiques pour la spécification et la conception des SMA temps réel.

Dans cet état de l’art nous allons essayer d’analyser trois des principales méthodologies de développement des systèmes multi-agents temps réel (SMATR) que nous avons recensé dans la littérature, en se basant surtout sur les propriétés associés à l’activité d’analyse du processus de développement de chacune, en guise de première contribution à ce travail.

Nous commençons tout d’abord par introduire les concepts de base qui découlent du domaine de recherche que constituent les systèmes multi- agents, ensuite, nous allons nous pencher sur l’ingénierie des SMA temps réel où nous allons décrire brièvement quelques méthodologies de développement à savoir : la Méthodologie RT-Message [Jul04b] ; la Méthodologie BDI-ASDP étendue pour le temps réel [Mel05] ; et la Méthode de développement de Lichen Zhang [Zha06].

Dans ce chapitre nous définissons les mots-clés et quelques concepts qui dominent notre axe de recherche. La définition du sens précis dans lequel nous utilisons constamment ces termes nous permettra sans doute de lever certaines ambiguités. De plus il nous permet de montrer les insuffisances des méthodologies étudiées pour le développement des systèmes multi-agents temps réel.


9

1. Les Systèmes Multi-Agents

L’expression Intelligence Artificielle (IA) est employée pour la première fois (1955-1970) par John McCarthy. Il fonde l’Intelligence Artificielle sur le postulat mécaniste qui veut que toute activité intelligente soit modélisable et reproductible par une machine.

« L’IA a pour but de faire exécuter par l’ordinateur des tâches pour lesquelles l’homme, dans un contexte donné, est aujourd’hui meilleur que la machine» [All94].

L’Intelligence Artificielle Distribuée (IAD) est un sous-domaine de l’Intelligence Artificielle qui s’occupe des situations où plusieurs systèmes interagissent pour résoudre un problème commun [Mou96b]. L’IAD se divise en deux branches principales :

- la Résolution Distribuée de Problèmes (RDP) qui étudie comment distribué des compétences au niveau de chaque partie du système, de façon à ce qu’il soit globalement plus compétent que chacune de ses parties;

- la Simulation des Systèmes Complexes (SSC), qui concerne plus particulièrement les Systèmes Multi-Agents (SMA). Les SMA traitent le comportement d’un ensemble d’agents autonomes qui essaient de résoudre un problème commun.

La différence notable entre la RDP et les SMA est que la RDP possède une approche descendante («top-down») et les SMA une approche ascendante («bottom-up»).

Bien qu’il y ait peu de consensus autour des concepts agents et SMA, plusieurs chercheurs ont des définitions qui convergent vers celles-ci :

1.1. Le Concept d’Agents

D’après [Woo00a]. Un agent est un système informatique encapsulé situé dans un environnement dans lequel il est capable d’effectuer une action flexible et autonome, compatible aux objectifs de la conception. Les agents sont :

- des entités clairement identifiables de résolution de problèmes avec des bornes et des interfaces bien définies;

- situés dans un environnement particulier ; ils reçoivent des entrées liées aux états de cet environnement par des capteurs et agissent sur cet environnement par des émetteurs;

- destinés à atteindre un objectif spécifique;

- autonomes et responsables de leur comportement;

- capables d’adopter un comportement flexible pour résoudre des problèmes selon les objectifs de la conception; ils sont réactifs (capables de s’adapter aux changements d’état de leur environnement) et proactifs (capables d’adopter un nouvel objectif);

- capables dans un univers multi-agents, de communiquer, coopérer, se coordonner, négocier les uns avec les autres.

La figure 1.1 donne, de façon générale, l’architecture interne d’un agent.


10

Figure 1.1. Architecture d’agent [Cot99].

Lorsqu’un agent perçoit une situation dans l’environnement, il essaie de la reconnaître. Si la situation lui est familière, il peut enclencher un processus de planification afin de résoudre le problème. Il peut aussi reconnaître la situation en terme d’action et donc, passe à l’exécution de la tâche (Reconnaissance- Exécution). Lorsque l’agent perçoit des situations qu’il connaît très bien, il peut faire intervenir son comportement réactif en passant directement à l’action (Perception-Exécution). S’il ne peut pas résoudre un problème (situation non-familière), il engage un processus de coopération pour demander de l’aide aux autres agents (Reconnaissance- Prise de décisions).

1.2. Les Systèmes multi-Agents

Les systèmes multi-agents mettent en oeuvre des agents homogènes et hétérogènes ayant des buts communs ou distincts. Ils sont dynamiques.

Un système multi-agent est un système distribué composé d’un ensemble d’agents qui interagissent le plus souvent, selon des modes de coopération, de concurrence ou de coexistence.

Selon [Cha99] un SMA est généralement caractérisé par :

chaque agent à des informations ou des capacités de résolution de problèmes limitées, ainsi chaque agent à un point de vue partiel;

il n’y aucun contrôle global du système multi-agents;

les données sont décentralisées;

le calcul est asynchrone.

Le principe récursif définit un SMA à un niveau supérieur d’abstraction comme étant un agent. Une vue canonique d’un SMA est donnée dans la figure 1.2.


11

Figure 1.2.Vue canonique d’un SMA [Woo00a].

1.3. Environnement

Selon [PES97], l’environnement peut être considéré comme la représentation du monde dans lequel les agents se situent. L’environnement est modifiable par les agents, soit de façon globale, soit en faisant la distinction entre objets passifs (soumis aux actions des agents) et entités actives (les agents) [Fer95].

1.4. Interaction

Ferber [Fer95] définit les interactions comme étant la mise en relation dynamique de deux ou plusieurs agents par le biais d’un ensemble d’actions réciproques. L’interaction entre agents s’effectue par la communication, les actes de langages et les protocoles d’interaction. Pour atteindre son objectif ou pour améliorer la coordination des actions, un agent peut demander des services à un autre agent.

Les interactions définissent un contexte organisationnel qui définit la nature des rapports entre agents et qui influence le comportement individuel des agents. Il est donc important de représenter explicitement ces rapports qui sont sujets à un changement continu. Les rapports existants évoluent dans le temps et de nouvelles relations se créent. Pour faire face à cette variété et cette forme dynamique de rapports, les chercheurs ont :

conçu des protocoles rendant capable la formation du contexte organisationnel;

spécifié des mécanismes permettant aux agents d’agir ensemble de façon cohérente;

et développé des structures pour caractériser le macro-comportement de l’ensemble.

1.5. Organisation

Étant donné que les SMA peuvent être considérés comme une société d’agents coopérant ensemble pour accomplir collectivement un objectif donné, il est nécessaire de résoudre un problème d’organisation, généralement de façon dynamique.


12

Selon Fox [Fox81], on peut définir une organisation comme une structure décrivant comment les membres de l’organisation sont en relation et interagissent afin d’atteindre un but commun.

L’autonomie et le comportement proactif des agents constituant les SMA suggèrent que la conception de ces applications peut être réalisée en imitant le comportement et la structure des organisations humaines, car l’une des missions principales des SMA est de supporter et/ou de contrôler des organisations du monde réel. Un SMA peut, par exemple, aider à contrôler les activités du commerce électronique. Selon [Zam00], la perspective organisationnelle conduit à une caractérisation générale d’un SMA décrite dans la figure 1.3.

Figure 1.3. Caractérisation d’un SMA [Zam00].

Le système peut être décomposé en des sous-organisations distinctes. Un agent peut jouer un ou plusieurs rôles tout en coopérant et en respectant ses sous-organisations. Les interactions entre agents apparaissent via les capteurs et les émetteurs. Le rôle d’un agent détermine la portion de l’environnement dans laquelle il peut recevoir et émettre des données.

1.6. Approche orientée-agent et approche orientée-objet

Au regard des caractéristiques d’agent, il apparaît que l’approche orientée-agent dans le développement de logiciel consiste en une décomposition du problème en agents ayant des interactions, une autonomie, et un objectif spécifique à atteindre. Les concepts clés d’abstraction liés à un système orienté-agent sont : agent, interaction, organisation.

Bien qu’il existe une similarité superficielle entre objet et agent, la terminologie objet n’est pas adaptée aux systèmes agents :

les objets sont généralement passifs alors que les agents sont permanents actifs;

les agents sont autonomes et responsables de leurs actions alors que les objets n’en sont toujours pas;

on ne peut prévoir tous les comportements des agents dans les systèmes;


13

l’approche orientée-objet ne fournit pas un ensemble adéquat de concepts et de mécanismes pour modéliser les systèmes complexes dans lesquels les rapports évoluent dynamiquement;

certains chercheurs définissent un agent comme un objet actif ayant une autonomie et un objectif. [Sab01]

1.7. Avantages et Inconvénients de l’approche centrée sur l’agent

Une nouvelle approche émerge pour palier aux manques des approches traditionnelles, il s’agit de l’approche orientée-agent. Parmi ces avantages :

1.7.1. La Modélisation des systèmes

L’approche OA offre une façon beaucoup plus naturelle de concevoir ce type de système. Selon [Gar03] trois grandes techniques sont utilisées pour la modélisation des SMA : l’approche centrée sur les tâches, l’approche centrée sur les buts et celle centrée sur les rôles. La première se base sur le fait que chaque agent peut effectuer des tâches, et que chaque tâche peut être effectuée par un ou plusieurs agents. Avec cette approche, il faut déterminer les tâches à effectuer pour l’atteinte du but global. Par la suite, il faut déterminer un ordonnancement et une cédule des tâches que chaque agent doit exécuter et coordonner leurs activités. La deuxième approche, celle centrée sur les buts, demande la spécification des buts intermédiaires des agents (ou sous systèmes) qui sont impératifs à l’atteinte du but global (but du système). De cette façon, lorsque tous les buts secondaires sont rencontrés, le but global est atteint et le système a donc atteint son objectif (les tâches pour lesquelles le système a été conçu). La troisième approche, soit celle centrée sur les rôles, nécessite une abstraction plus élevée que les deux premières. Les agents sont plutôt modélisés en fonction de leurs responsabilités au sein du groupe (sous-système ou système). Plusieurs méthodologies ont été développées pour chacune de ces approches. Cependant, de l’avis de la majorité des chercheurs dans le domaine, une méthodologie OA en particulier ne peut être utilisée pour la modélisation de tous les types de SMA.

La majorité des méthodologies développées s’appliquent à un ou quelques domaines en particulier mais ne sont pas appropriées dans d’autres circonstances. Que l’on utilise une méthodologie spécifique pour la modélisation d’un système ou que l’on applique des concepts génériques comme l’approche centrée sur les rôles, les buts ou celle centrée sur les tâches, l’approche agent offre une façon beaucoup plus naturelle de développer les systèmes « intelligents » et distribués d’aujourd’hui. L’approche OA permet une factorisation (décomposition en sous-systèmes) et une délégation naturelle des tâches, buts et/ou rôles à ces sous-systèmes et leurs agents. L’approche permet aussi de déterminer les protocoles de communication, d’interaction, de coordination et de négociation entre les agents. De cette façon, il est possible de superposer le problème réel sur le système à base d’agents.

1.7.2. La Tolérance aux fautes

Les systèmes à base d’agents possèdent un avantage marqué au niveau de la tolérance aux fautes par rapport aux systèmes centralisés. La majorité des SMA sont distribués sur plusieurs


14

machines et effectuent les différentes tâches en parallèle et/ou en concurrence. Par exemple, prenons plusieurs agents sur différents ordinateurs qui ont les qualifications requises pour effectuer des tâches de même nature. Donc, si une machine (ou un sous-système du SMA) est indisponible pour quelque raison que ce soit, les tâches à effectuer par ce sous-système peuvent être redistribuées à d’autres agents ayant la capacité d’effectuer ces dernières sur d’autres machines.

1.7.3. L’Autonomie des systèmes

L’approche OA suppose la mise en application des concepts inhérents aux agents. Il faut donc que les agents d’un système possèdent une certaine autonomie, un certain degré d’intelligence artificielle, une représentation de leur environnement, qu’ils puissent interagir avec celui-ci, qu’ils soient capables de « prendre de l’initiative », de communiquer entre eux et qu’ils soient capables de s’adapter à différentes situations. La nécessité de ces concepts à différents niveaux d’un programme indique un certain besoin d’autonomie et valide en quelque sorte le choix de l’approche SMA plutôt que l’approche OO.

1.7.4. Autres avantages

Plusieurs autres avantages sont attribuables aux agents et SMA :

La facilité de « changement d’échelle d’une architecture » (scalability) car plusieurs agents peuvent s’ajouter ou se retirer dynamiquement d’un système.

La configuration automatique d’un SMA grâce à la plus grande « proximité » du monde réel des agents.

La résolution plus rapide et efficace de problèmes en exploitant le parallélisme.

La réduction des coûts de développement de logiciel : plus un logiciel est modulaire, plus la complexité et les coûts de développement diminuent.

Flexibilité des systèmes : les systèmes sont composés de plusieurs agents ayant des habiletés différentes, ils peuvent donc résoudre différents problèmes (ils peuvent aussi résoudre des problèmes en coopérant et en se partageant les tâches dépendamment des capacités de chacun).

1.7.5. Les Difficultés de l’approche orientée-agent

Dans de nombreuses situations, le développement OA procure plusieurs avantages marqués par rapport à l’approche OO. Cependant, l’utilisation de ce nouveau paradigme engendre plusieurs difficultés. Voyons la principale difficulté de cette approche.

1.7.5.1. Méthodologies non-standardisées

Le développement d’applications OO permet l’utilisation de standards comme OMT et UML (Unified Modeling Language) pour la modélisation, la conception et l’implémentation. Cependant, la même chose n’est pas possible lorsque l’on développe une application OA. Aucun standard


15

n’existe encore aux niveaux des méthodologies et de la technique de développement. Quelques standards sont définis par la FIPA (Foundation for Intelligent Physical Agents) pour l’implémentation des SMA [FIPA97]. Par contre, les standards définissent beaucoup plus le niveau architectural et les modes de communication que le niveau conceptuel qu’impliquent la modélisation et la conception. Si nous voulons impérativement utiliser une méthodologie pour la création d’un SMA, il faut donc déterminer la méthodologie qui représente le mieux le type de système à développer. Un tel choix suppose une connaissance relativement bonne des différentes méthodologies disponibles, ce qui est rarement le cas [Gar03].

2. Les Systèmes Temps Réel

2.1. Définition

De nombreuses définitions ont été proposées pour clarifier la notion de système temps réel (STR). Cependant, comme les caractéristiques des systèmes temps réel sont très variées, aucunedes définitions proposées n’est vraiment complète pour tenir compte de tous les domainesd’applications. En effet, selon l’aspect abordé dans les STR, on choisit une définition qui s’approche le plus de la problématique traitée. Ainsi, on assimile, selon le cas, un système temps réel à un système rapide, à un système en interaction directe avec un procédé physique, àun système réactif, à un système qui ne fournit pas de réponse en différé, à un système avec uncomportement prédictible, à un système qui travaille sur des données fraîches, à un systèmerobuste, etc.

Il existe différentes définitions d’un système temps réel. Par exemple J-P Haton et ses coauteurs [Hat91] définissent le fonctionnement temps réel en référence au temps de réponsed’un système, c’est-à-dire le temps utilisé par le système pour identifier un évènement extérieur et y répondre. I. Benyahia [Ben93] définit un système temps réel comme un système capable de répondre à un évènement avant une date fixée par le processus extérieur. Toutes ces définitionsont en commun la notion de temps de réponse. Cette notion est définie par le délai limitenécessaire pour émettre un résultat.

Une définition plus générale qui résume ce que doit être un système temps réel est la suivante : ‘ ’c’est un système dont le comportement dépend non seulement de l’exactitude des traitements effectués, mais également de l’instant où les résultats de ces traitements sont fournis. Dans ces systèmes, un retard dans la production d’un résultat est considéré comme uneerreur, pouvant souvent entraîner de graves conséquences [Kav92].

On distingue, en général, deux principaux types de tâches temps réel : (1) à échéances dures ou strictes (hard), où le non respect de l’échéance peut provoquer une exception dans le système, et peut avoir de graves conséquences sur l’application, (2) à échéances molles, ou relatives (soft), où le retard d’une tâche ne provoque pas d’exception, c.à.d. que les tâches de ce type peuvent manquer leurs échéances occasionnellement sans engendrer de graves conséquences [Sad04].


16

2.2. Les Caractéristiques d’un système temps réel

Le temps de réponse d'un système temps réel est une caractéristique importante, mais il ne représente pas le seul paramètre à prendre en compte. Dans [Dod89], les auteurs ont défini les caractéristiques suivantes d’un système temps réel :

La Réactivité : Elle peut être définie comme étant la capacité à réagir à des stimulations extérieures. Un système temps réel doit être réactif face aux événements externes asynchrones de l’environnement. Il doit pouvoir classer ces événements en fonction de leur urgence et donner la priorité au plus urgent. Il doit également focaliser ses ressources en fonction des données. Dans la majorité des applications temps réel (surveillance, procédés industriels,...), ces événements asynchrones sont délivrés par des capteurs.

L’Adaptabilité : Elle peut être définie comme la capacité du système à adapter son comportement à de nouvelles données. Contrairement à la réactivité, cette caractéristique n’est en général que partiellement traitée. Certains modèles ne sont pas facilement extensibles ou modifiables [Gue96].

Les Types d’interaction (forte/faible) : Toute application temps réel est en interaction (forte ou faible selon les cas) avec son environnement. Lequel environnement peut être un procédé industriel, un moteur d’avion, un malade, etc. la nature de l’environnement a une incidence directe sur la ‘’criticité’’ des actions entreprises dans une application temps réel. La notion de ‘’criticité’’ (ou ‘’criticality en anglais) est utilisée comme critère pour pouvoir classer les applications temps réel selon la sévérité, en termes de coût engendré par le non respect des contraintes temporelles. Ainsi, on classe les applications temps réel en deux types : les applications à contraintes temporelles strictes (‘’hard real time applications’’), où le non respect des contraintes de temps peut conduire à des défaillances avec des conséquences pouvant être graves, et les applications à contraintes temporelles relatives (‘’soft real time applications’’), où le dépassement des échéances est considéré comme une faute bénigne [Duv01].

Le Déterminisme : c’est le but à atteindre pour tout système temps réel, pour assurer la prévisibilité, i.e., enlever toute incertitude sur le comportement des activités (individuelles et mises ensemble). Dans un STR dur (à contraintes strictes), on cherche à ce que toutes les échéances soient respectées, alors que dans un STR à contraintes relatives, on cherche à minimiser le retard moyen des activités, ou maximiser le nombre de tâches qui respectent leurs échéances par exemple [Sad04].

3. Les Systèmes Multi-Agents Temps Réel

3.1. Introduction

De nos jours, l’incorporation du paradigme des systèmes multi-agent dans les systèmes temps réel offre la flexibilité, l’adaptabilité et la distribution. Ces caractéristiques aident à relever les nouveaux défis dans ce domaine comparé aux applications temps réel traditionnelles.


17

D’après [Eur00], ‘’Si on se concentre dans les sytèmes temps réel distribués, on peut distinguer plusieurs nœuds indépendants qui travails pour achever des objectifs commun dans un environnement ayant des contraintes temporelles strict. Le developpement de nouvelles applications dans le domaine des sytèmes temps réel distribué à ajouter de la compléxité aux systèmes de ce type. En générale, ces systèmes ont une distribution physique du problème et leurs nœuds doivent partager les ressources limitées. Par conséquent, il est nécessaire pour ces nœuds de travailler de maniére coordonée et de s’engager à réaliser les tâches spécifique ‘’.

Le paradigme agent semble être très puissant et très prométeux pour être utilisé dans le développement des systèmes complexe, en particulier dans le développement des sytèmes temps réel d’où émerge le concept des sytèmes multi-agent temps réel [Eur00].

3.2. Définition

Selon Botti et al. [Bot95], un agent temps réel (ATR) est un agent ayant des contraintes temporelles dans quelques un de ses responsabilités. Généralement, un ATR (Agent Temps Réel) est un agent composé d’une série de tâches, dont quelques unes ont des contraintes temporelles. Dans ces agents, il est aussi nécessaire de prendre en compte l’exactitude temporelle, qui est exprimé au moyen d’un ensemble de restrictions temporelles imposé par l’environnement. Par conséquent l’ATR assure la satisfaction de ses restrictions temporelles. Si le non respect de ces restrictions temporelles engendre des conséquences catastrophiques, l’agent est de type Hard. D’autre part, si l’insatisfaction de ces mêmes restrictions n’engendre qu’une dégradation dans les réponses alors l’agent est de type Soft.

La définition suivante d’un système multi-agents temps réel est basée sur la définition ci-dessus d’un agent temps réel :

‘’Un système multi-agents temps réel est un système multi-agents où au moins un de ses agents est un agent temps réel’’ [Jul04a].

Dans la section suivante, nous allons analyser brièvement les principales méthodologies de développement de SMA temps réel que nous avons recensées dans la littérature. Il y a, parmi celles-ci, certaines sur lesquelles nous ne possédons pas assez d’informations, nous nous permettons de faire une étude plus détaillée. Il nous semble cependant que ces méthodologies sont les plus représentatives des méthodologies de développement des SMA temps réel existantes.

4. Travaux Similaires

4.1. Introduction

L’approche orienté agent consiste à décomposer les problèmes en agents autonomes. Ces agents peuvent interagir à haut niveau et sont organisés en sociétés. Cette organisation sert à décrire l’activité du système. L’identification du rôle et des capacités de chaque agent y est donc essentielle.

Selon [Woo00b], les approches orientée-objets existantes ne capturent pas convenablement le


18

comportement flexible et autonome de résolution de problèmes, la richesse des interactions et la complexité des structures organisationnelles d'un système multi-agents temps réel.

Pour faire face à ce problème que différentes méthodologies développées sur la base de notations ou méthodes orientées-objet ont vu le jour. Parmi elles nous trouvons : la Méthodologie RT-Message [Jul04b] ; la Méthodologie BDI-ASDP étendue pour le temps réel [Mel05] ; et la Méthode de développement de Lichen Zhang [Zha06]. Dans les paragraphes qui suivent nous allons essayer d’analyser ces trois méthodologies de développement des systèmes multi-agents temps réel (SMATR) en se basant surtout sur les propriétés associés à l’activité d’analyse du processus dedéveloppement de chacune, en guise de première contribution à ce travail.

4.2. Analyse des Méthodologies de Développement des SMA-Temps Réel

Durant les dernières années, il a été reconnu largement que la conception et le développement des systèmes multi-agents a été pour une grande part ad hoc. Luck et al. (2003) ont noté que : ‘’ il existe des méthodologies de développement orientées objet, mais celles ci ne sont pas applicable de même pour les systèmes orientés agents qui utilisent des méthodes inappropriées ou ad hoc ‘’[Kou07].

Plusieurs propositions méthodologiques pour le développement logiciel (‘’software enginieering’’) existent et peuvent être appliquées aux systèmes à base d’agents. Quelques une d’entre elles proviennent du domaine des systèmes à base de connaissances [Fer98], d’autres sont directement centré sur les propriétés des agents [Omi01], et d’autres sont des extensions de méthodologies de développement orienté objet et de langages, comme UML [Ode00]. Seulement très peu de ces méthodologies tiennent compte des comportements temporels des agents [Mel05].

Parmi ces méthodologies qui adressent directement la conception des systèmes multi agents temps réel, nous nous sommes intéressés aux trois suivantes : la Méthodologie RT-Message [Jul04b] ; laMéthodologie BDI-ASDP étendue pour le temps réel [Mel05] ; et la Méthode de développement de Lichen Zhang [Zha06].

La méthodologie ‘’RT-Message’’ [Jul04b] est un ensemble d’idées flexibles et adaptables, qui couvrent les phases d’analyses, de conception et d’implémentation des systèmes multi-agents temps réel. Elle utilise les mêmes modèles qu’utilise la méthodologie ‘’Message’’ [Mes99] [Mes01], lors de l’activité d’analyse auxquels elle ajoute quelques extensions temporelles dans le but de spécifier les comportements des agents temps réel. Dans la phase de conception, RT-Message propose l’utilisation de l’architecture SIMBA afin de modéliser les systèmes multi agent temps réel. [Jul04a]

Le deuxième travail est celui de Melián et al. [Mel05], son objectif principal est d’étendre la méthodologie de développement basé sur les agents BDI, afin de permettre la modélisation des systèmes multi-agent temps réel, et son application à un exemple pratique. Les auteurs de ce travail ont ainsi utilisés ‘’la méthodologie BDI-ASDP’’ (BDI-Agent Software Development Process) [Ein03], qui est basée sur la décomposition du problème en beliefs, desires et intentions, et ont étendue de capacité de modélisation des contraintes temporelles à travers les diagrammes de temps(timing diagrams) proposés dans UML 2.0. [Mel05]

La troisième approche est celle de ‘’Zhang’’ [Zha06], qui est basée sur UML pour l’analyse et la conception des systèmes multi-agents temps réel. Afin de satisfaire les besoins de modélisation des systèmes temps réel par l’approche agent, l’auteur à ajouté un nouveau stéréotype qu’il a appelé


19

« agent ». Les contraintes temporelles quant a elles ont été décrites comme une instance du stéréotype « agent » nommée ‘’TimeAspect’’.

Le tableau 1.1 ci-dessous donne une vue globale de ces trois méthodologies.

Auteurs Contexte / objectifs Principales phases

La Méthodologie RT-Message

Julian et Botti. [Jul04b]

Couvrir l’analyse, la conception, et l’implémentation des SMA temps réel.

Analyse, conception, et implémentation.

La Méthodologie BDI-ASDP étendue pour le temps réel

Melián et al. [Mel05]

Etendre la méthodologie de développement basée sur les agents BDI pour permettre la modélisation des SMA temps réel et leurs applications à un exemple concret.

Analyse, etconception.

La Méthode de développement de Lichen Zhang

Zhang [Zha06]

Modéliser les propriétés temporelles des systèmes temps réel en étendant UML via le mécanisme de stéréotype.

Analyse, et conception.

Tableau 1.1. Contexte/objectives et principales phases des méthodologies de conception des SMA Temps Réel.

Pour l’identification/définition des agents temps réel, ces méthodologies utilisent différent modèles à savoir : modèle de domaine ; modèle de rôle ; et modèle de temps. Comme illustré dans le tableau 1.2 ci-après.

Modèle de Domaine

Modèle de Rôle

Modèle de temps

Spécifications Fonctionnelles

La Méthodologie RT- Message[Jul04b]

La Méthodologie BDI-ASDP étendue pour le Temps réel [Mel05]


20

La Méthode de développement de Lichen Zhang[Zha06]

Tableau 1.2. Approches d’Identification/définition d’Agents Temps Réel.

La méthodologie ‘’RT-Message’’ [Jul04b], utilise un modèle de domaine pour définir les concepts inhérents de l’environnement dans lequel les agents se situent. Le résultat principal de ce modèle est un diagramme de domaine qui est à la base un diagramme de classe contenant toutes les entités et variables pertinentes dans le processus de développement. Tout comme ‘’Zhang’’ [Zha06] l’aproposé dans sa méthode de développement. Cependant, dans ‘’la méthodologie BDI-ASDP étendue pour le temps réel’’ [Mel05], un modèle symbolique de l’environnement est défini, basé sur la décomposition du problème en beliefs, desires, et intentions qui représentent respectivement l’information, les motivations et les décisions que doit avoir l’agent.

La notion de rôle quant elle est présente seulement dans la méthodologie ‘’RT-Message’’ [Jul04b], où les rôles sont identifiés indépendamment des agents du système à modéliser.

Concernant la modélisation des contraintes temporelles des agents temps réel, chaque méthodologie propose une approche. Premièrement, pour le cas de la méthodologie ‘’RT-Message’’, les extensions faites sur les différents modèles importés de la méthode ‘’Message’’ [Mes99] [Mes01], permettent d’analyser les systèmes multi-agents pour des environnements temps réel. Par exemple, ‘’le modèle de But/Tâche ‘’ (Goal/Task Model) a été modifié de façon à incorporer une taxonomie de Buts (Goal taxonomy) qui tient compte des critères temporels. C'est-à-dire, lors de la spécification des différents types de But, il est nécessaire d’étendre les schémas de but et tâche de la méthode ‘’Message’’ de manière à intégrer les caractéristiques temps réel. Les artefacts obtenus sont un ensemble ‘’de diagrammes d’implication’’ montrant les relations qui existent entre les buts et tâches.

Deuxièmement, dans ‘’la méthodologie BDI-ASDP étendue pour le temps réel’’ proposée par Melián et al. [Mel05], la modélisation des contraintes temporelles durant la phase de conception est faite via ‘’les diagrammes temporels’’ (timing diagrams) spécifier dans UML 2.0. Troisièmement, pour satisfaire le besoin de modéliser les systèmes temps réel par l’approche agent, ‘’Zhang’’ [Zha06] a proposé d’étendre UML par l’introduction d’un nouveau stéréotype qu’il a nommé « agent ». Les caractéristiques temporelles sont spécifiées comme une instance de ce stéréotype qu’il a appelé « TimeAspect ». Ce stéréotype « TimeAspect » utilise un modèle de temps conçuindépendamment, selon le principe de la programmation orientée aspect, pour exprimer l’aspect temporel d’un système temps réel.

Toutefois, la modélisation des systèmes multi-agents temps réel est fréquemment liée à des spécifications fonctionnelles dans le sens où ces spécifications offrent une base à la description des besoins fonctionnels des agents, en appliquant un ensemble de techniques de génie logiciel. Ces descriptions fonctionnelles sont modélisées dans la plupart du temps par UML qui est le standard le plus déployé, offrant de multiples notations. Ce concept à été négligé dans les trois méthodologies analysées comme illustré dans le tableau 1.2.


21

L’essentiel de l’analyse effectuée ci-dessus est donnée par le tableau 1.3, dans lequel on a ajouté d’autres caractéristiques jugées importantes tel que : ‘‘les caractéristiques d’interaction’’,’’ les restrictions’’,’’ l’orientation’’,’’ l’architecture agent’’, ‘’les capacités’’, etc.

Méthodologie RT-Message [Jul04b]

Méthodologie BDI-ASDP étendue pour le temps réel [Mel05]

Méthode de développement de Lichen Zhang [Zha06]

Activités Analyse, Conception, Implémentation.

Analyse, Conception. Analyse, Conception.

Orientation Extensions orienté objet Extensions orienté agent

Extensions orienté objet

Restrictions - Uniquement les agents BDI

-

Caractéristiques d’interaction

Conception AUML (diagrammes d’interaction AUML)

Conception UML (diagramme de séquence)

Conception UML (diagrammes de collaboration)

Architecture Agent Indépendante BDI Indépendante

Besoins fonctionnels NON NON NON

Contraintes temporelles

Ajouter quelques extensions temporelles à l’ensemble des modèles proposés dans la méthodologie ‘’Message’’ afin de spécifier les comportements ayant des restrictions temporelles.

Modéliser les contraintes temporelles à travers les diagrammes temporelles d’UML 2.0 dans la phase de conception.

Les propriétés temporelles sont décrites comme un aspect indépendant selon les techniques d’AOP.

Notion de Rôle (associé la notion de rôle aux autres attributs conceptuel des systèmes agents).

les rôles sont identifiés indépendamment des agents

N/A (N’est pas Applicable)

N/A (N’est pas Applicable)

Capacités N/A N/A N/A

Tableau 1.3. Comparaison générale.

Donc, après cette analyse nous constatons que ces trois méthodologies ne tiennent pas compte de la formalisation des besoins fonctionnels des systèmes multi-agents temps réel lors de leur modélisation du futur système. D’où il est important qu’elles soient complétées par des méthodes


22

qui encouragent fortement la formalisation des besoins fonctionnels capturés lors de l’analyse pour les phases amant du processus du génie logiciel.

5. Conclusion

Dans ce chapitre, nous avons défini les principaux concepts utilisés tout au long de ce mémoire. Ces définitions vont permettre au lecteur de comprendre le sens précis dans lequel nous les avons utilisés. Nous avons aussi analysé brièvement trois des principales méthodologies de développement des systèmes multi-agents temps réel que nous avons pu recenser dans la littérature. Cependant, aucune de ces méthodologies ne tiennent compte de la formalisation des besoins fonctionnels du futur système, ce qui nous a motivé à explorer cette voie, afin d’en proposer une approche générique de développement pour les systèmes multi-agents temps réel basé sur l’extension du formalisme de modélisation graphique Agent UML. Ce dernier fera l’objet du chapitre suivant.

23

Chapitre 2

AUML & La Modélisation des Systèmes à base D’Agents

AUML & la Modélisation des Systèmes à base d’Agents

24

Résumé

Dans l’approche SMA, la méthode consiste à décomposer les problèmes en agents autonomes. Ces agents peuvent interagir à haut niveau et sont organisés en sociétés. Cette organisation sert à décrire l’activité du système. L’identification du rôle et des capacités de chaque agent y est donc essentielle. Mais les approches orientées-objets existantes ne capturent pas convenablement le comportement flexible et autonome de résolution de problèmes, la richesse des interactions et la complexité des structures organisationnelles d'un système d'agents [Woo00]. Le rapprochemententre ces approches en particulier UML et les systèmes multi-agents a déjà été exploité, nous ne manquerons pas le projet AUML, qui a pour but d'étendre UML afin de pouvoir décrire les comportements d'agents. Certaines idées de ce projet ont été intégrées dans la norme UML.

Agent UML est certainement le plus connu des langages de modélisation graphique pour décrire les systèmes multi-agents, mais jusqu’à présent, il reste peu appliqué à la modélisation dessystèmes multi-agents temps réel. Le but de ce travail est d’adapter Agent UML à la description des besoins fonctionnels des SMA temps réel. Trois objectifs ont d’ores et déjà été énoncés pour ce chapitre : (1) étudier comment certaines notions vues au chapitre précédent peuvent être spécifiées dans AUML, (2) identifier quels éléments font défaut à Agent UML pour prendre en charge l’aspect temps réel, et (3) définir une méthodologie pour l’utilisation d’Agent UML.

Ce chapitre présente nos premières constatations et donne quels diagrammes AUML sont à considérer.


25

Introduction

Le génie logiciel orienté agent (Agent Oriented Software Ingineering ‘’AOSE’’) a émergé comme une discipline consacrée à l’engineering des systèmes logiciels complexes basés sur le paradigme des systèmes multi-agents. La recherche dans le domaine d’AOSE inclut l’identification et le développement d’outils conceptuels (e.g., modélisation formelle) ainsi que d’outils pratique (e.g., infrastructures basé agents) pour supporter les ingénieurs logiciels (‘’software ingineers’’) et les programmeurs dans l’analyse, la conception et le développement des systèmes multi-agents. Cependant, un grand défit à relever dans le domaine du génie logiciel orienté agent (AOSE) consiste à la définition de méthodologies pour guider le processus de développement des SMA [Gat07]. En effet les méthodologies proposées jusqu’ici ne tiennent pas en compte la formalisation des besoins fonctionnels du futur système.

Une méthodologie de développement est typiquement caractérisée par un ‘’langage de modélisation’’ utilisé pour la description des modèles, la définition des éléments de modèle avec une syntaxe spécifique et une sémantique associée, et ‘’un processus logiciel’’ définissant les activités de développement, les interrelations parmi les activités, et comment les différentes activités sont exécutées. Chaque activité résulte en un produit livrable ou plus, tel que les documents de spécification, les modèles d’analyse, les spécifications de conception, le code, les tests, les rapports de test, les rapports d’évaluation de performance, etc. qui servent comme entré aux activités amonts. [Bau05]

Afin d’arriver à un grand usage du paradigme agent, comme l’a mentionné [Bau01b], on a besoin de l’associer à la technologie antérieure la plus proche à savoir l’approche orientée Object, et d’utiliser les différents artefacts afin de supporter l’environnement de développement durant tous le cycle de vie du système. On adresse ces deux besoins en utilisant Agent UML1, qui est un ensemble de dialectes et d’extensions d’UML.

Le langage AUML (langage semi-formel de modélisation graphique) est à notre avis le futur standard de l’industrie pour le développement des systèmes orientés agents. Il permet de modéliser et de décrire plusieurs vues complémentaires d’un même système. AUML comme UML souffre, cependant, d’un manque de sémantique formelle. Les modèles AUML développés pourront donc contenir des incohérences ou des inconsistances difficiles (voire impossibles dans le cas de certains systèmes complexes) à détecter manuellement.

Les méthodes formelles représentent une solution intéressante à ce problème. Les spécifications formelles auront pour effet d’éliminer les ambigüités au niveau de l’interprétation des modèles. La combinaison d’Agent UML avec un langage de spécification formelle éprouvé comme Real time Maude permettra de valider formellement les modèles AUML développés.

Ce chapitre est une introduction à notre travail par la définition des notions et concepts liées au formalisme de modélisation Agent UML ainsi qu’aux différents travaux qui le considère. Nous allons parler premièrement d’Agent UML (section1), en suite on va présenter les quatre types de représentation AUML considérés à savoir, les diagrammes de cas d’utilisation (modélisant les besoins fonctionnels du système), les diagrammes de classes (modélisant la structure statique d’un système), les diagrammes de protocole (modélisant le flux de messages échangés entre agents), et les diagrammes d’état transition (modélisant le comportement individuel des agents), tout en faisant le lien avec les principaux travaux qui les considèrent (section 2).


26

Ce chapitre est basé sur les principaux articles et références d’AUML. Pour plus de détails le lecteur peut consulter les articles [Gat07], [Ode00], [Ode01], [Par02], [Bau01a], [Bau02], [Bau05], [Hug02b], [Hug02c], [Hug02e], [Per05], etc.

1. Le Langage de Modélisation AUML

1.1. Rappel sur AUML

UML a unifié et formalisé les méthodes de plusieurs approches, incluant les méthodes de Booch, Rumbaugh, Jacobson, et Odell. Bauer a noté dans [Bau01b] ‘’qu’UML soufre d’insuffisance pour la modélisation des systèmes à base d’agents [Bau00b]’’. Principalement, cela est dû à deux raisons majeurs : premièrement, comparé aux objets, les agents sont actives parce qu’ils peuvent prendre l’initiative et ont un contrôle globale sur leurs comportements. Deuxièmement, les agents n’interagissent pas de façon individuel mais plutôt en coopération ou en coordination avec d’autres agents. Les systèmes multi-agents sont des communautés sociales de membres interdépendants qui agissent individuellement.

De ce fait, plusieurs langages de modélisation des systèmes agents sont proposés, parmi eux nous citons : Agent Modelling Language (AML) [Tre05] ; et Agent UML1 (AUML) [Hah08].

AUML (Agent Unified Modeling Language) est un langage offrant de nombreux artefacts en vue de la construction d’un système logiciel. Avec ses vues et ses divers types de diagrammes, AUML offre la possibilité de modéliser la structure statique d’un système, ses besoins fonctionnels, en plus de son comportement collectif et individuel [Gag07].

AUML est un langage de modélisation graphique qui a été standardisé par FIPA2 (Foundation for Intelligent Physical Agents) comité technique de modélisation. Il a été proposé comme une extension du langage de modélisation unifié (UML). Jusqu’ à maintenant il n y’a pas de standard reconnu pour la modélisation des systèmes multi-agents et AUML a émergé comme un candidat pour assumer une tel position. Il utilise les caractéristiques de ‘’décomposition’’, ‘’d’abstraction’’, et ‘’d’organisation’’, qui réduisent la complexité de développement de logiciel. AUML décompose le système en petites parties d’objets, de modèles, de cas d’utilisation ou de classes, et d’actions opérationnelles. Concernant ‘’l’abstraction’’, elle offre une vue spécialisée abstraite de la modélisation (classe, cas d’utilisation, diagramme, interface, etc.).

‘’L’organisation’’ orientée agent définie un ensemble d’éléments et de notations comme la spécification des besoins pour la modélisation du domaine. Son objective est de fournir un modèle et une architecture interne d’un système agent. Elle offre généralement quelques Framework (classe, diagramme, interface, etc.) pour voir comment les agents peuvent être construits dans un système.

La partie principale d’AUML est les mécanismes de modélisation des protocoles d’interaction des systèmes multi-agents. Cela est réalisé par l’introduction d’une nouvelle classe de diagramme à UML : ‘’diagramme de Protocole’’. Ces diagrammes étendent les diagrammes de séquence en incluant : ‘les rôles d’agents’, ‘multithreaded lifelines’, ‘protocole templates’, etc. [Gag07].


27

1.2. Les Incohérences du Langage AUML

AUML tout comme UML [Ake02] offre la possibilité de décrire plusieurs "vues" d’un même système. Cependant, ces différentes vues peuvent être en conflit puisqu’elles peuvent présenter des incohérences. De plus, l’expérience montre que de très nombreuses fautes de modélisation sont perceptibles à travers la détection d’incohérences [Mus03] [Reg99] [Mor00] [Ast98]. Selon [Mal05], une incohérence est la violation d’une propriété associée au langage AUML qui doit être respectée par tout modèle AUML. En effet, la cohérence peut concerner un seul diagramme (on parle de cohérence intra-diagramme) ou plusieurs diagrammes (on parle de cohérence inter-diagrammes).

Parmi les incohérences intra-diagramme, on peut mentionner la présence de cycles dans un graphe d’héritage pour un diagramme de classes, l’existence d’une transition dont l’état source est un état final dans un diagramme d’états-transitions et le non respect de l’ordre d’envoi de message d’un point de synchronisation dans un diagramme de communication (par exemple, le numéro du message bloqué est inférieur au numéro du message bloquant). La représentation des systèmes complexes, en utilisant les différents diagrammes cités précédemment, peut engendrer des incohérences inter-diagrammes. On peut citer, entre autres, un événement appel d’un diagramme d’états-transitions qui ne figure pas comme méthode dans la classe correspondante. Aussi, un envoi de message (appel de procédure) dans un diagramme de communication ne figurant pas comme une méthode à visibilité appropriée dans la classe de l’objet destinataire. Par ailleurs, l’état final d’un système fini ne se compose pas de différents états finaux des différents objets impliqués dans le diagramme de communication [Gag07].

Dans la section suivante nous allons présenter quatre des principaux diagrammes d’AUML, ainsi que les travaux qui les considèrent.

2. Les Principales Représentations d’Agent UML

Comme nous l’avons indiqué dans l’introduction, Agent UML est une extension d’UML afin de prendre en compte les notions agent que ce dernier n’a pas. Puisqu’Agent UML est une extension, il hérite des représentations proposées par UML. En voici la liste :

1. Diagrammes de séquence

2. Diagramme de collaboration

3. Diagramme d’activité

4. Diagramme d’état transition

5. Diagramme de cas d’utilisation

6. Diagramme de classe

7. Diagramme d’objets

8. Packages

9. Diagramme de composants


28

10. Diagramme de déploiement

Les cinq premières représentations correspondent à des diagrammes dynamiques alors que les quatre dernières correspondent à des diagrammes statiques. Nous rappelons que notre but est de déterminer quelles représentations ont besoin d’être modifiées ou améliorées pour pendre en charge les spécificités des systèmes multi-agent temps réel. Les diagrammes de séquence ont déjà été modifiés puisqu’ils portent maintenant le nom de diagrammes de protocole [Ode00] [Bau00b]. Ces diagrammes de protocole ont été eux aussi améliorés par Huget [Hug02b], et correspondent à la représentation des protocoles d’interaction. Les diagrammes de classe ont aussi été modifiés. Il ne faut pas oublier qu’un agent diffère d’un objet par conséquent le diagramme de classes qui permet de représenter les classes constituant le système sera aussi modifié.

Nous trouvons deux approches pour ces diagrammes de classes : celle de Bauer [Bau01b] et celle de Huget [Hug02c]. La première approche [Bau01b], propose d’interpréter l’acceptation des actes de communication dans les diagrammes de classe agent. Selon Huget [Hug02c], cette approche est irréaliste dés que les agents englobent plusieurs protocoles complexes. ‘’L’agent head automata’’ ajouté par Bauer au diagramme de classe pose problème, il contient les actes de communication aussi bien que les actions déclenchés par les messages reçus. Cette interprétation des actes de communication ne doit pas être à l’intérieur des diagrammes de classe agent mais à l’extérieure. Il sera mieux d’utiliser les diagrammes de séquence si les concepteurs veulent représentés les protocoles ou les diagrammes d’activités s’ils veulent représentés les actions déclenchées par les messages. De plus, si les concepteurs insèrent ‘’l’agent head automota’’ dans les diagrammes de classe agent, ils violent un des principes d’UML portant sur le fait ‘’qu’un diagramme est uniquement utilisé pour décrire une seul vue du système’’ : les diagrammes de classe agent sont utilisés pour représenter le contenu des agents et non comment ces derniers réalisent les actions liées aux messages. De ce fait, nous nous sommes basés sur la deuxième proposition [Hug02c] jugée intéressante et qui sera décrite ci-dessous.

Dans les paragraphes qui suivent nous rappelons brièvement à quoi servent ces représentations (diagrammes de cas d’utilisation, de classe, de protocole, et d’état transition) et nous présentons les principaux travaux qui les considérent.

2.1. Les Diagrammes de Cas D’utilisation AUML

2.1.1. Introduction Les diagrammes de cas d’utilisation sont utilisés pour définir des cas d’utilisation du système et

donnent une analyse du système. Ils représentent les cas d’utilisation, les acteurs, et les relations qui existent entre les acteurs et les cas d’utilisation. Un cas d’utilisation peut être vu comme un scénario dans le système, par exemple quand un utilisateur essaye de se connecter au système et un mot de passe est nécessaire. Dans les systèmes multi-agents, les cas d’utilisation sont intéressants lorsqu’il s’agit de réaliser l’analyse des besoins (requirement analysis). Ils sont utiles durant le dialogue entre les utilisateurs finaux et les concepteurs puisqu’ils sont graphiques, et permettent aux utilisateurs de saisir les différents éléments du système. L’avantage principal des cas d’utilisation est de se concentrer sur le quoi et non sur le comment, c.à.d. sur le comportement du système et non sur comment le système est implémenté.


29

La figure 2.1 présente le diagramme de cas d’utilisation d’un agent client situé au sein d’une entreprise de production. Nous avons un seul acteur sur cette figure : l’agent client. Les cas d’utilisation sont annotés par un cercle : placer ordre, modifier ordre, et annuler ordre. Les lignes entre l’acteur et les cas d’utilisation dénote que l’acteur utilise ces scénarios.

Figure 2.1. Diagramme de cas d’utilisation d’un agent client.

Chaque cas d’utilisation dans le diagramme à besoin d’être complètement documenté et spécifié. Le type de documentation demandée pour chaque cas d’utilisation varie selon le type du système à spécifier. Il peut aller d’une description textuelle à inclure différent types dediagrammes UML [Pap00].

Peu de travaux considèrent les diagrammes de cas d’utilisation pour la modélisation des SMA,parmi eux nous trouvons les propositions de Michael Papasimeon et Clinton Heinze [Pap00],Clinton Heinze, Michael Papasimeon, et Simon Goss [Hei00], Bernhard Bauer et James Odell[Bau05].

Ce pendant, il n’y a jusqu’à maintenant aucune proposition essayant d’étendre ces diagrammes pour la description des besoins fonctionnels des systèmes multi-agent temps réel. Un besoin qui nous a motivés à exploiter cette voie de recherche, pour en proposer une solution. De plus, les diagrammes de cas d’utilisation semblent avoir un intérêt mineur lors de la conception des systèmes multi-agents temps réel. Mais ils pourraient être intéressants si les utilisateurs finaux nesont pas les concepteurs ou si ces utilisateurs n’arrivent pas à comprendre d’autres diagrammes.

Selon [Des08], Un modèle de cas d’utilisation UML décrit et formalise les relations entre le système logiciel à réaliser et le monde extérieur. Cette description se place du point de vue externe (boîte noire) sans jamais entrer dans les structures internes du logiciel. L’objectif est de préciser les frontières du système et les différentes interactions mises en oeuvre dans la réalisation des besoins métiers.

Le modèle est constitué par deux principaux types d’élément UML : les Acteurs et les Cas d’utilisation (voir figure 2.2 ci-dessous). Le container qui apparaît dans le diagramme (sous forme rectangulaire) représente le système. Les cas d’utilisation sont visualisés à l’intérieur du système, les acteurs à l’extérieur du système.

Placer ordre

Modifier ordre

Annuler ordre

Client


30

Figure 2.2. Exemple de cas d’utilisation avec 1 acteur et 3 cas d’utilisation [Des08].

Particulièrement employé au cours des phases amont du processus de développement, ce type de modèle est un outil de base pour la formalisation de besoins fonctionnels et une aide précieuse dans le dialogue avec les utilisateurs.

2.1.2. Les Acteurs

Un acteur est une entité externe au système qui est amenée à interagir directement avec celui-ci. Un acteur peut représenter aussi bien un utilisateur humain que tout dispositif matériel ou logiciel. Exemples : Usager, Client, Progiciel de facturation, ...

Un acteur représente un rôle joué vis-à-vis du système. Un utilisateur physique peut jouer successivement des rôles différents en fonction du mode d’utilisation du système [Des08].

2.1.3. Les Cas D'utilisation

Un cas d’utilisation représente une interaction entre acteurs et système, dans le but de répondre à un besoin fondamental. Il est décrit par un ensemble de scénarios, qui précisent le dialogue entre le système et les acteurs. Un cas d’utilisation doit rendre un service réel complet, apportant une valeur ajoutée à l’acteur. C’est sa caractéristique essentielle. A l’inverse, les fonctions comme "saisir son code secret" ou "choisir le montant" ne sont probablement pas des cas d’utilisation. Un cas d’utilisation est un élément atomique, qui doit satisfaire aux critères suivants :

Unité de temps : Le déroulement d’un scénario doit se réaliser dans un délai relativement bref. A l’inverse, une interaction ne peut pas durer plusieurs mois.

Unité de lieu : On évite un changement de lieu au cours d’un déroulement d’un scénario (on ne débute pas le scénario au bureau pour le terminer au domicile).

Unité d’acteur (un acteur bénéficiaire) : Le service est rendu pour un seul acteur (acteur principal), qui est souvent la source du déclenchement du cas d’utilisation. Les autres acteurs qui interagissent avec le cas d’utilisation sont des acteurs secondaires. Ils participent aux scénarios, mais ne sont pas les bénéficiaires du service.

Non interruptible : Il n’est pas possible (dans une utilisation normale) d’interrompre le déroulement d’un scénario, pour le reprendre plus tard. Le scénario s’arrête lorsque le


31

service est rendu. Typiquement, un acteur ne va pas ‘prendre ses congés’ au milieu du déroulement d’un scénario [Des08].

2.1.4. Les Scénarios Les scénarios d’un cas d’utilisation sont constitués par un enchaînement de séquences qui décrivent un dialogue entre le système et un ou plusieurs acteurs. Les scénarios s’expriment le plus souvent à l’aide de texte (Figure 2.3). Cependant, il n’y a pas de règles dans le standard UML surce point. Par exemple, on peut utiliser les diagrammes de séquences.

Figure 2.3. Scénario représenté par une note associée au cas d'utilisation [Des08].

2.1.5. Les Relations entre Cas D'utilisation Le standard UML définit un ensemble de relations entre cas d’utilisation (figure 2.4) :

Les relations d’inclusion (« include ») : pour factoriser

Les relations d’extension (« extend »)

Les liens d’héritage

Figure 2.4. Relations entre cas d'utilisation : UC2 hérite de UC1, UC2 inclut UC3, UC4 étend UC2 [Des08].

Bien que partie intégrante du standard, d’après la plus part des auteurs l’emploi de ses relations n’est pas clair et peut amener des difficultés. Ils conseillent vivement de limiter leur emploi.


32

2.1.5.1. La Relation d'Inclusion

L’inclusion peut être employée lorsque plusieurs cas d’utilisation comportent des enchaînements de séquences identiques. Un nouveau cas d’utilisation qui déclare cette partie commune est utilisé par référence par les cas d’utilisation et factorise cette partie.

Figure 2.5. Relation "include" entre cas d'utilisation [Des08].

Dans l’exemple ci-dessus (figure 2.5), les scénarios des deux cas d’utilisation "Consulter document" et "Annoter document" débutent avec le même enchaînement :

1) L’Agent demande la liste des documents disponibles

2) L’Agent sélectionne un document dans la liste

3) L’Agent visualise le contenu du document

x) …

y) …

Pour éviter les répétitions, le cas d’utilisation "Choisir document" déclare dans son scénario les trois premières séquences, puis les scénarios des deux cas d’utilisation sont modifiés pour référencer celui-ci.

1) include: Choisir document

x) …

y) …

Cependant, le standard UML n’indique pas le langage ou la technique pour référencer un cas d’utilisation dans un scénario, mais Agent UML le permet.

2.1.5.2. La Relation d'Extension

Cette relation permet d’introduire un chemin particulier dans un scénario, souvent associé à une condition exceptionnelle (effet de seuil, cas particulier …) appelé point d’extension. Un cas d’utilisation contient cet enchaînement exceptionnel et étend le cas d’utilisation initial.


33

Figure 2.6. Relation "extend" entre cas d’utilisation [Des08].

Dans l’exemple ci-dessus (figure 2.6), s’il s’agit d’un document critique, un point d’extension (PEA) est inséré dans le scénario du cas d’utilisation "Consulter document".

1) include: Choisir document

(PEA) Si document critique

2)

x) …

y) …

L’enchaînement correspondant est défini dans le scénario du cas d’utilisation "Contrôler acces".

(PEA)

1) Le système demande le mot de passe à l’Agent

2) L’Agent saisit le mot de passe

3) Le système vérifie le mot de passe

Néanmoins, le standard UML n’indique pas le langage ou la technique pour insérer ou définir un point d’extension, mais AUML le permet.

2.1.5.3. La Relation d'Héritage

L’héritage entre cas d’utilisation est représenté comme un héritage entre classes. Il peut être employé pour définir des "sous-cas d’utilisation". Pour le regroupement de cas d’utilisation (par catégories fonctionnelles par exemple), on utilisera le Package [Des08].

2.2. Les Diagrammes de Classe AUML Etendus

Les diagrammes de classes dans UML permettent de représenter les différentes classes utilisées dans le système. Ils donnent la structure du système et les relations qui unissent les classes. Ce type de diagrammes semble être intéressant pour représenter les différents rôles d’agents qui se trouvent dans le système et les relations entre ces rôles. Les agents diffèrent des objets en de nombreux points et en particulier sur l’autonomie. De plus, les agents sont dotés de plus de capacités que les objets. Les diagrammes de classes dans UML ne considèrent que les attributs et les opérations pour les objets. Ceci se révèle être insuffisant pour représenter les agents.

Un nouveau langage de modélisation graphique à surgit récemment, il s’agit d’Agent UML qui est une extension d’UML afin de prendre en compte les notions agent que ce dernier n’a pas. En


34

effet, les agents proposent des services, ont des capacités, utilisent des protocoles d’interaction, ont plusieurs rôles, etc. Une première proposition d’extension des diagrammes de classes a été faite dans [Bau01b], mais vu ses limites, une autre suggestion est apparue dans [Hug02c], où l’auteur considère deux niveaux d’abstraction. ‘’Un niveau conceptuel’’ et ‘’un niveau d’implémentation’’, le premier niveau ne fait pas intervenir les classes reliées aux agents mais uniquement ceux-ci, alors que le second niveau donne une vue détaillée des agents, des classes et des différentes relations.

Le diagramme de classe proposé par Huget [Hug02c], est constitué d’un ensemble de compartiments. ‘’Le premier compartiment ‘’donne le nom de la classe de l’agent. Ce nom est préfixe par le stéréotype « agent » afin de permettre de différencier un agent d’un objet, cependant le nom de l’agent est insuffisant pour représenter son rôle dans le SMA, d’où l’existence du ‘deuxième compartiment’ qui donne l’ensemble des rôles joués par cette classe d’agent. Cette information est ensuite utilisée pour les protocoles d’interaction et les organisations. ‘’Le compartiment des ‘’statecharts’’ correspond au comportement de la classe. Il ne s’agit pas d’insérer le diagramme d’états au sein du diagramme de l’agent mais de donner son nom.

Le compartiment suivant appelé ‘’attributs’’ est équivalent à celui présent dans les diagrammes de classes UML. Il donne l’ensemble des attributs de la classe d’agent. A chaque fois, le type des attributs est précisé. Les points de suspension à la fin du compartiment indiquent que tous les attributs ne sont pas présents sur le diagramme.

Le compartiment qui est au dessous du précédent est celui ‘’des opérations’’ qui est aussi présent dans les diagrammes de classes d’UML. Mais ces opérations correspondent aux actions exécutées par les agents. Elles sont divisées en trois catégories : ‘’internes’’, ‘’pro-actives’’ et ‘’réactives’. Les opérations internes ne sont pas visibles par les autres agents, par exemple si les agents ont un module d’interaction spécifique pour la communication [Hug02h], de telles opérations doivent être utilisées pour récupérer les messages. Les opérations pro-actives correspondent aux opérations déclenchées pour définir des conditions comme un timer, des exceptions, ou des conditions. Un exemple courant est celui d’un server qui informe les agents de valeurs spécifique chaque t unités de temps. Les opérations réactives sont des actions liées aux modifications faites sur l’environnement ou en réaction aux actions des autres agents.

Il y a des opérations qui ont des paramètres et d’autres ont des pré-conditions qui doivent être évaluées à vrai pour que l’opération soit effectuée. Le format des conditions est libre : il peut s’agir d’un texte ou d’une condition au format ‘’OCL’’ [Omg01]. Une fois de plus, il y a des points de suspension puisqu’il n’est pas précisé des opérations portant sur la gestion des messages par exemple. Ces trois types d’opérations sont distingués dans les diagrammes de classe par les mots clé : ‘int’ pour opérations interne, ‘pro’ pour opérations pro-active et ‘reac’ pour opérations réactives.

Le compartiment qui vient après donne ‘’les protocoles d’interactions’’ utilisés par la classe d’agent tout en précisant les rôles joué par celle-ci dans ces protocoles. Une fois de plus, il ne s’agit pas d’insérer le diagramme de protocoles au sein du diagramme de classe mais de donner le nom de celui-ci.

Les deux derniers compartiments concernent la ‘’vue organisationnelles’’ des agents. En effet plusieurs informations sont fournies selon cette vue : ‘les capacités’, ‘les services’ et ‘les organisations’ dans lesquelles l’agent est impliqué.


35

Les capacités décrivent ce qui est l’agent capable de faire. Ces capacités sont écrites sous forme textuelle et sont stockées dans ‘le compartiment Capacités’. Les capacités sont dérivées comme des services aux agents. Ces services ne sont pas représentés dans le diagramme de classe agent mais interconnecté. La dernière information dans cette vue est la liste des organisations dans lesquels l’agent appartient. Cette liste est placée dans ‘le compartiment organisation’. Les agents jouent des rôles dans les organisations, de ce fait ces rôles seront insérés pour chaque organisation.Cependant, L’entré et la sortie des organisations est contraintes par des conditions.

2.3. Les Diagrammes de Protocole AUML Etendus

Nous avons vu que les interactions entre les agents sont le concept primordial permettant auxsystèmes multi-agents de fonctionner. Cette notion d'interaction est également définie dans Agent UML. Il existe différents types de diagrammes AUML permettant de représenter les interactions. Dans cette sous section, nous étudions les diagrammes de protocoles.

Les diagrammes de protocole (appelés diagrammes de séquence dans UML) sont les plus commun pour décrire les protocoles d’interaction utilisés par les agents. Ils exploitent la richesse des communications entre agents et représentent les échanges de messages entre ces derniers. Ces agents vont être représentés par leurs ‘rôles’ dans l’interaction. En effet, les messages ne sont pas échangés d’un agent à un autre mais plutôt d’un rôle à un autre. L’avantage de cette approche est de réduire la taille du diagramme. Le concepteur ne représente pas le message envoyé par le client Smith à la compagnie ACME mais du rôle client au rôle vendeur [Hug02d].

Ces diagrammes sont certainement les plus achevés dans Agent UML puisque plusieurs travaux les considèrent [Ode00] [Bau00b], pour n’en citer que quelques uns.

On peut également citer l'article de Huget [Hug02b] où il propose des solutions pour qu'Agent UML puisse supporter d’autre propriétés tel que : ‘le broadcasting’, ‘la synchronisation’, ‘le traitement des exceptions’, ‘la gestion du temps’, etc. Nous nous intéressons à la dernière propriété que nous essayerons d’exploiter dans l’approche que nous proposons (voir chapitre 04).

2.4. Les Diagrammes d’Etat Transition AUML

Les diagrammes d’états-transitions d’UML décrivent le comportement interne d’un objet à l’aide d’un automate à états finis. Ils présentent les séquences possibles d’états et d’actions qu’une instance de classe peut traiter au cours de son cycle de vie en réaction à des événements discrets.

Le diagramme d’états-transitions est le seul diagramme, de la norme UML, à offrir une visioncomplète et non ambiguë de l’ensemble des comportements de l’élément auquel il est attaché. En effet, un diagramme d’interaction n’offre qu’une vue partielle correspondant à un scénario sans spécifier comment les différents scénarii interagissent entre eux. La vision globale du système n’apparaît pas sur ce type de diagramme puisqu’ils ne s’intéressent qu’à un seul élément du système indépendamment de son environnement.

Ce type de diagramme rassemble et organise les états et les transitions d’un classeur donné.Bien entendu, le modèle dynamique du système comprend plusieurs diagrammes d’états-transitions. Il est souhaitable de construire un diagramme d’états-transitions pour chaque classeur (qui, le plus souvent, est une classe) possédant un comportement dynamique important. Un


36

diagramme d’états transitions ne peut être associé qu’à un seul classeur. Tous les automates à états finis des diagrammes d’états-transitions d’un système s’exécutent concurremment et peuvent donc changer d’état de façon indépendante [Aud06].

Selon [Mul00], les diagrammes d’états-transitions sont en réalité des graphes orientés. Leur rôle principal est de décrire le cycle de vie des objets, les événements qu’ils subissent, leurs transitions et leurs états. Un diagramme d’états-transitions est composé de plusieurs éléments : les états (ou noeuds du graphe), ainsi que les événements et les transitions (les arcs du graphe).On pourrait définir un état par la condition dans laquelle se trouve un objet entre les divers messages qu’il reçoit. Un état se définit par deux choses différentes : par la valeur des attributs de l’objet et par la valeur des liens avec les autres objets à un instant donné. La valeur des attributs est critique ici, et particulièrement lorsque mise en contexte avec les divers liens qui existent avec d’autres objets. Toutes ces données mises ensemble peuvent avoir une influence sur la réaction qu’aura l’objet face au prochain message qu’il recevra de l’extérieur. Avec UML, on représente un état par une boîte aux coins arrondis.

Un diagramme d’états-transitions est habituellement constitué d’un état initial, d’états intermédiaires (zéro ou plusieurs) et d’un ou plusieurs états finaux (zéro ou plusieurs). Le second concept d’importance face aux diagrammes d’états est la transition. Une transition est le lien qui existe entre deux différents états. C’est par ce lien que l’objet peut changer d’état. Lorsqu’un événement se produit, il peut entraîner un changement d’état face à un objet, mais conditionnellement à ce que l’événement en question ne soit associé à une transition. Notons qu’il est impossible de transiter entre un état donné et un autre sans qu’une transition existe entre les deux. Avec UML, une transition est représentée par une flèche entre deux états. Par ailleurs, une transition peut être gardée. Les gardes sont évaluées dès l’occurrence de l’événement de déclenchement. Elles permettent de maintenir l’aspect déterministe d’un automate d’états finis, même lorsque le même événement est susceptible de déclencher plusieurs transitions. Les événements, quant à eux, pourraient être définis par quelque chose de remarquable par un objet.

Figure. 2.7. Exemple d’un événement déclenchant une transition [Gag07].

Cet événement se produit à un instant quelconque lors de l’exécution du système. La figure 2.7 montre un exemple d’un événement déclenchant une transition. Cet événement peut provenir du système ou de son interface, et peut être de trois natures différentes. Un événement dit externe, ou événement système, est un événement causé par un des acteurs. Un événement dit interne est un événement causé par une entité du système même. On pourrait citer comme exemple l’invocation d’une méthode de l’objet par l’envoi d’un message par un autre objet. Enfin, un événement temporelet lié à un temps écoulé ou à une date et une heure spécifique. Par exemple, on pourrait faire déclencher une méthode quelconque après qu’un laps de temps déterminé ce soit écoulé [Gag07].


37

3. ConclusionL’approche que nous proposons pour la description des besoins fonctionnels des systèmes

multi-agents temps réel est principalement basée sur le formalisme de modélisation graphique Agent UML. Vu que ce dernier offre plusieurs modèles conceptuels pour : décrire les besoins fonctionnels des agents ; spécifier les protocoles d’interaction agent ; représenter le comportement interne et collectif des agents ; etc.

Agent UML n'étant pas un outil destiné à la conception de SMA temps réel, il y a certaines ambigüités à lever lorsqu'on l'utilise dans ce contexte. En effet, la spécification des contraintes temporelles n'est pas définie par Agent UML. De même, la description des besoins fonctionnels des SMA temps réel n'est pas clairement spécifiée. Tout cela nous amène à dire que même si utiliser AUML présente des avantages, il est nécessaire d’adapter certains de ces diagrammes pour pouvoir les utiliser dans la modélisation des SMA temps réel. Dans notre contexte, on a utilisé les diagrammes d’état transition, de protocoles étendue, de classe étendue, et de cas d’utilisation. Seul les deux derniers type de diagramme ont subit des modifications afin d’intégrer la dimension temporelle, caractéristique essentielle des SMA temps réel. Ces différentes extensions seront détaillées dans le chapitre (04) du présent mémoire.

D’un autre côté, AUML souffre d’un manque de sémantique formelle. Les modèles AUML développés pourront donc contenir des incohérences ou des inconsistances difficiles (voire impossibles dans le cas de certains systèmes complexes) à détecter manuellement. La combinaison d’Agent UML avec un langage de spécification formelle éprouvé comme Real time Maude permettra à notre avis de valider formellement les modèles AUML développés. Donc, notre objectif est d’arriver à spécifier formellement les modèles AUML décrivant les besoins fonctionnels des SMA temps réel, c.à.d. translater les quatre types de diagrammes AUML vers une notation formelle du langage RT-Maude. Cette démarche permet d’éliminer certaines erreurs de façon précoce avant de passer aux phases de conception et d’implémentation. En effet, il semble qu’un formalisme unique ne soit pas suffisant pour décrire convenablement la totalité du comportement des agents.

38

Chapitre 3

Real-Time Maude

Real Time Maude

39

Résumé

Le système Maude est un environnement de programmation basé sur la logique de réécriture, celle-ci a été introduite dans le but de modéliser des systèmes informatiques, et plus particulièrement les systèmes concurrentiels.

Maude étant un méta-langage, utilisé pour développer d’autres langages. En effet Real-Time Maude (RT-Maude) est implémenté en Maude comme une extension de Full Maude. RT-Maude est un langage et un outil qui supporte la spécification et l’analyse des systèmes temps réel, et plus particulièrement les systèmes temps réel orientés-objet. Il constitue un candidat parfait pour la translation des diagrammes AUML vers une notation formelle.

Dans les deux sections qui suivent (section 1 et 2), la logique de réécriture et le langage Maude feront l’objet d’une étude un peu plus détaillée. Par la suite, le langage Real Time Maude proprement dit sera discuté en (section 3). L’ensemble des exemples présents dans les sections 2 et 3 ont été écrits dans le plug-in ‘’Maude Development Tools’’ qu’on a intégré dans la plateforme ‘’Java Eclipse’’.

1. Introduction

La logique en général est une méthode de raisonnement correct pour quelques classes d’entités. Pour la logique équationnelle, les entités sont les ensembles, les fonctions entre ces ensembles et la relation d’identité entre les éléments. Pour la logique de réécriture, les entités sont les systèmes concurrents ayant des états, et qui évoluent à travers des transitions. Elle est considérée également comme une logique de changement concurrent qui traite l'état et les calculs concurrents [Meg04].

Dans ce qui suit, une brève introduction à la logique de réécriture [Maa04] sera donnée afin de mieux saisir son fonctionnement lorsque viendra le temps de la mettre en application.

La logique de réecriture a été proposée par J.Messeguer comme une sémantique concurente des systèmes de réecritures de termes où les opérateurs peuvent être associatifs, cmmutatifs, idempotents ou doté d’un élément neutre à gauche ou à droite. La logique de réécriure formalise le processus de la réécriture, par opposition à la logique équationnelle qui considère les règles de récritures comme des égalités et utilise la réécriture pour calculer un représentant unique d’une classe d’équivalence. La logique de rééecriture utilise les règles de réécriture pour calculer une relation de ‘’réécrivabilité’’ entre des termes. Elle permet d’exprimer le fait qu’un terme peut êtreréécrit en un autre.

Cette logique exprime aussi une équivalence essentielle entre logique et calcule dans une représentation simple. Un axiome logique de réécriture de la forme, (t -> t’), a deux lectures.

Dans l’esprit calculatoire, un fragment t d’états de système, peut se transformer en t’, en concurrence avec d’autres changements d’états, c’est une transition local concurrente. Dans l’esprit logique, on peut dériver la forme t’ à partir de t, on l’appelle une règle d’inférence.

La logique de réécriture, utilisée comme une structure sémantique, supporte un large spectre d’applications. Premièrement ; elle est utilisée pour spécifier et unifier beaucoup de modèles de calculs concurrent. Deuxièmement ; la logique de réécriture est aussi une structure sémantique

Real Time Maude

40

pour les langages de programmation. Elle peut être vue comme un langage déclaratif de spécification où les programmes parallèles ou séquentiels peuvent être spécifiés par des règles de réécriture.

Les éléments définis ci-dessous sont tirés d’un texte de Meseguer [Mes02]. La première définition introduit le concept de la théorie de réécriture :

Une théorie de réécriture est un triple R = (∑;E;R) où :

– (∑;E) est une théorie d’équations ensemblistes ;

– R est un ensemble de règles de réécritures conditionnelles nommées ayant la forme suivante :

pour lequel r est un identificateur pour la règle, et où il existe un ensemble fini X de variables pour lequel t, t’ appartient à T∑(X)k pour un genre (kind) k, ainsi que tous les ∑ termes ui; u’i; vj ;wl;w’l

dans la condition sont également dans l’ensemble T∑(X)k. La condition est la conjonction d’équations, d’équations ensemblistes et de réécritures.

Lorsqu’une règle de réécriture ne comporte aucune condition, cette règle est alors appelée inconditionnelle. Ainsi, on peut introduire la définition d’une théorie de réécriture généralecomme suit : une théorie de réécriture générale est un

De façon similaire à une ‘théorie d’équations ensemblistes’, ‘une théorie de réécriture’ possède une série de règles d’inférence. Elles sont la Réflexivité, l’Égalité, la Congruence, le Remplacement et la Transitivité. La figure 3.1 permet de visualiser chacune de ces règles.

Real Time Maude

41

Figure 3.1. Visualisation des règles d’inférence d’une théorie de réécriture [Gag07].

La logique de réécriture supporte un large spectre d'applications. Premièrement ; elle est utilisée pour spécifier et unifier beaucoup de modèles de calculs concurrents. Deuxièmement ; la logique de réécriture est aussi une structure sémantique pour les langages de programmation où les programmes parallèles ou séquentiels peuvent être spécifiés par des règles de réécriture [Gar02]; de nombreux langages de programmation ont été conçus pour exploiter les concepts de la réécriture, Maude [Ekr02] est l’un d’eux.

Les quelques notions précédentes constituent les éléments les plus importants par rapport à la logique de réécriture. Les principales notions mathématiques pertinentes à la logique de réécriture ayant été discutées brièvement, l’environnement Maude peut être introduit [Gag07].

2. Maude

L’unité de base de spécification et de programmation dans Maude est le module, en effet trois types de modules sont définis dans le langage Maude. Les modules fonctionnels (fmod) permettent de définir les sortes de donnés et les opérations sur ces donnés à travers la théorie des équations. Les modules systèmes (mod) définissent le comportement dynamique d’un système. Ce type de module étend les modules fonctionnels en introduisant les règles de réécriture, qui permettent d’offrir un degré maximal de concurrence. Finalement, il y a les modules orientés-objets (omod), par rapport aux modules systèmes, ils offrent une syntaxe plus appropriée pour décrire les entités de base du paradigme objet comme : classe, objets, messages. Ces modules doivent être déclarés respectivement en respectant les syntaxes suivantes:

Real Time Maude

42

Les points représentent les déclarations et les expressions qui peuvent apparaître dans le module.

Il existe actuellement deux niveaux séparés de Maude : Core Maude et Full Maude, tel que n’importe quelle spécification dans Core Maude est également dans Full Maude, mais non pas l’inverse. Les Modules systèmes et les modules fonctionnels sont les deux définies dans Core Maude, mais non pas les modules orientés-objet. Pour utiliser Full Maude, Tous les commandes et les modules doivent être déclarés entre parenthèses, donc la déclaration d’un module orienté-objetsera comme suit:

2.1 Caractéristiques de Maude

Basé sur la logique de réécriture : Où les programmes sont des théories, et les règles de déduction logique de réécriture correspond exactement au calcul concurrent.

Spectre large (wide spectrume) : La spécification est rapide et efficace pour l'exécution parallèle et distribuée, aussi bien que la transformation formelle des spécifications des programmes.

Multi-paradigmes : Toutes les applications basées sur la logique équationnelle sont supportées facilement, donc la programmation fonctionnelle style équationnelle est naturellement représentée par un sous-langage. Le style déclaratif de programmation concurrente, orientée-objets est aussi supporté avec une sémantique logique simple.

Stratégies internes : Cette propriété permet de guider le processus de réécriture dont la sémantique peut être définie à l'intérieur de la logique par des règles de réécriture.

Dans ce qui suit nous introduisons d’abord les éléments communs aux modules fonctionnels, systèmes et aux modules orientés-objet : sortes, sous-sortes, opérations et variables. Nous présenterons ensuite la définition de la syntaxe et de la sémantique spécifique à chacun des types de modules. Toutes les notions citées dans cette section sont rédigées à partir du document [Cla05].

2.2 Concepts de base

2.2.1 Sortes

La première chose à déclarer dans une spécification est les sortes de données et les opérations correspondantes. Les sortes sont partiellement ordonnées via une relation de sous-sorte. Une sorte est déclarée en utilisant le mot-clé sort suivi d’un identificateur (le nom de sorte) suivi d’un espace et un point :

sort <Sort> .

Les sortes multiples seront déclarées en utilisant le mot-clé sorts :

sorts <Sort1> . . . <Sortn> .

Real Time Maude

43

2.2.2 Sous-sortes

La relation de sous-sorte subsort sur les sortes est équivalente à une relation de sous-ensemble sur un ensemble d’éléments (relation d’inclusion). Les sous-sortes sont déclarées en utilisant le mot-clé subsort ou subsorts. La déclaration :

subsort <Sort1> < <Sort2> .

Signifie que la sorte <Sort1> est une sous-sorte de <Sort2>. Par exemple, les déclarations :

subsort Zero < Nat .

subsort NzNat < Nat .

Signifient que les sortes Zero (contenant seulement la constante 0) et NzNat (les nombres naturels non nuls) sont des sous-sortes de Nat (les nombres naturels). On peut déclarer plusieurs relations de sous-sorte en utilisant subsorts :

subsorts <Sort1> . . . <Sort2> < . . . < <Sortn> .

Par conséquent les déclarations de l’exemple précédent peuvent être faites en une seule ligne :

subsorts Zero NzNat < Nat .

On peut également exprimer la relation subsort comme suit :

sorts NzInt Int .

subsorts NzNat < NzInt Nat < Int .

Où NzNat et Int sont les ensembles respectivement des entiers naturels non nuls et des entiers.

Un ensemble de déclarations de sous-sortes définit un ordre partiel sur l’ensemble de sortes. Toutefois, pour que cette déclaration soit correcte, l’utilisateur doit éviter les cycles dans les déclarations de sous-sortes. Graphiquement, nous pouvons visualiser cet ordre partiel de la façon suivante :

2.2.3 Opérations

Dans un module, une opération est déclarée à l’aide du mot-clé op suivi de son nom, suivi de deux points, suivis d’une série de sortes qui constituent ses arguments (arité), suivis de -> , suivi des sortes des résultats (co-arité), optionnellement suivis de la déclaration d’attributs (présentés plus loin) suivis d’un espace et un point. Le schéma général a la forme suivante :

op <OpName> : <Sort0> . . . <Sortk> -> <Sort> [<OperatorAttributes>] .

Voici quelques exemples de déclarations d’opérations :

op zero : -> Zero .

op s_ : Nat -> NzNat .

op sd : Nat Nat -> Nat .

Real Time Maude

44

ops _+_ _*_ : Nat Nat -> Nat .

Si l’arité des arguments est vide, l’opération est appelée une constante comme c’est le cas pour le Zero. Le nom d’opération est une chaîne de caractères. Les espaces soulignés (_) jouent un rôle spécial dans ces chaînes de caractères. En effet, si aucun espace souligné ne se produit dans la chaîne de caractères de l’opération comme dans le cas de sd alors l'opérateur est déclaré sous la forme préfixée. Si les espaces soulignés se produisent dans la chaîne de caractères, alors leur nombre doit coïncider avec le nombre de sortes déclarées comme arguments de l'opérateur. L'opérateur est alors sous la forme dite mixfixée où le nième espace souligné indique la position de l’argument de la nième sorte dans les expressions formées avec cet opérateur. Dans l'exemple précédent les opérateurs s_, _+_, et _*_ sont sous la forme mixfixée.

Il peut y avoir tous les autres caractères avant ou après n'importe lequel de ces espaces soulignés. Si aucun caractère n'apparaît, nous dirons que l'opérateur a été déclaré avec la syntaxe vide. Par exemple, nous pourrions déclarer une sorte NatSeq séquence des nombres naturels avec la syntaxe vide comme suit :

sort NatSeq .

subsort Nat < NatSeq .

op _ _ : NatSeq NatSeq -> NatSeq [assoc] .

L’attribut assoc dans l’exemple ci-dessus est un attribut déclarant que la concaténation est associative. Avec cette déclaration d'opérateur nous pouvons écrire des termes comme : zero (s zero) (s s zero).

Des opérations ayant les mêmes arité et co-arité peuvent être déclarées simultanément en employant ops comme mot-clé et en donnant les sortes non vides après le mot-clé ops et avant deux points, comme pour les déclarations de _+_ et _*_ dans l'exemple plus haut.

2.2.4 Variables

Les variables peuvent être déclarées à tout moment avec une syntaxe comportant un identificateur (le nom de la variable), deux points et un autre identificateur (sa sorte).

Par exemple, N: Nat déclare une variable nommée N de sorte Nat.

Une variable doit être accompagnée de sa sorte. Une variable peut également être déclarée dans un module en utilisant le mot clé var suivi d'un identificateur (le nom de variable) suivi des deux points avec l'espace avant et après les deux points, suivi d'un identificateur (sa sorte), suivi d'un espace et d’un point :

var N : Nat .

Des variables de la même sorte peuvent être déclarées en utilisant le mot-clé vars:

vars M N : Nat .

Real Time Maude

45

2.3 Les Modules Fonctionnels

Les modules fonctionnels définissent les sortes de données et les opérations sur ces données à travers des théories équationnelles. Les sortes de données se composent des éléments qui peuvent être appelés par des termes. Un module fonctionnel est déclaré selon la syntaxe suivante :

fmod <MODULE-NAME> is [<DeclarationsAndStatements>] endfm

Par exemple:

fmod NUMBERS is ... endfm

déclare un module fonctionnel appelé NUMBERS. Les points représentent les déclarations et les expressions qui peuvent apparaître dans le module. Les déclarations incluent l'importation d’autres modules fonctionnels, les sortes, les sous-sortes, et des déclarations d'opérations. Les expressions incluent des axiomes équationnels et d'appartenance.

2.3.1 Équations inconditionnelles

Les équations sont déclarées en utilisant le mot-clé eq, suivi par un terme (la partie gauche), le signe d’égalité, puis un terme (la partie droite), et optionnellement suivi par des attributs encadrés par des crochets, terminés par un espace et un point. Ainsi le schéma général est le suivant :

eq <Term1> = <Term2> [<StatementAttributes>] .

Les termes t et t’ dans une équation t = t’ doivent être de même sorte. Pour que l’équation s’exécute, chaque variable qui apparaît dans t’ doit apparaître dans t. Nous pouvons par exemple ajouter des équations relatives à l’addition dans le module NUMBERS :

vars N M : Nat .

eq N + zero = N .

eq N + s M = s (N + M) .

Avec s défini précédemment comme opérateur unaire.

2.3.2 Équations conditionnelle

Les conditions dans les équations conditionnelles se composent de différentes équations t = t0. Une condition peut être une équation simple, ou une conjonction d’équations en utilisant le ‘’and ‘’qui est associative.Ainsi la forme générale des équations conditionnelles (ceq) est la suivante :

ceq <Term1> = <Term2> if <EqCondition-1> and ... and <EqCondition-k> [<StatementAttributes>] .

En plus, la syntaxe concrète de la condition équationnelle "EqCondition" est peut être une équation booléenne dite abrégée de la forme t, avec t un terme dans la sorte Bool abrégeant l'équation t = true.Ainsi, ces conditions peuvent apparaître dans une équation :

(N == zero) = true(M =/= s zero) = true

Real Time Maude

46

(N > zero or M =/= s zero) = true

2.3.3 Attributs équationnels

Les déclarations d'opérateur peuvent inclure des attributs qui fournissent des informations additionnelles à l'opérateur : sémantique, syntaxique, pragmatique, etc. Tous ces attributs sont déclarés dans une seule paire de crochets, après la sorte du résultat et avant le point.

assoc (associativité), comm (commutativité), id: <Term> (identité).

Ces attributs sont permis seulement pour les opérateurs binaires dont les arguments appartiennent au même composant. Un opérateur peut être déclaré avec n'importe quelle combinaison de ces attributs qui peuvent apparaître dans n'importe quel ordre dans la déclaration.

Dans notre exemple de nombres nous pouvons ajouter nil pour exprimer le vide et raffiner la déclaration de la concaténation des séquences des nombres, de sorte que la concaténation soit associative avec l'identité nil.

op nil : -> NatSeq .op _ _ : NatSeq NatSeq -> NatSeq [assoc id: nil] .

2.4 Les Modules SystèmesUn module système spécifie une théorie de réécriture. Une théorie de réécriture a des sortes, et

des opérations, et peut avoir des : équations et règles qui peuvent être conditionnelles.

Les règles spécifient les transitions concourantes locales qui peuvent avoir lieu dans un système si le patron dans le côté gauche de la règle correspond à un fragment de l'état de système et la condition de la règle est satisfaite. Dans ce cas, la transition indiquée par la règle peut avoir lieu, et le fragment de l'état correspondant est transformé en l’instance correspondante du côté droit. Par exemple, Comme cela a été déjà mentionné auparavant, un module système ‘’BANK-ACCOUNT’’ peut être déclaré comme suit :

mod BANK-ACCOUNT is ...

endm

Où les points de suspension correspondent à toutes les déclarations et expressions dans un module :

1. importations,2. sortes et sous-sortes,3. opérations,4. variables,5. équations (conditionnels et non conditionnels),6. règles de réécriture (conditionnelles et non conditionnelles).

Les déclarations 1-5 sont exactement les mêmes que celles dans les modules fonctionnels. Les modules systèmes rajoutent les règles de réécriture que nous présentons.

Real Time Maude

47

2.4.1 Règles de réécriture

Il n'y a (mathématiquement) aucun comportement dynamique dans des spécifications équationnelles. En effet, dans le modèle mathématique des spécifications équationnelles de même que dans la logique équationnelle, deux expressions sont soit équivalentes soit aucune relation n’existe entre elles. Hors pour les systèmes dynamiques, qui évoluent avec le temps, cet arrangement équationnel n’a pas de sens mathématique ou logique. Pour illustrer un système dynamique, regardons le modèle simplifié de la vie d'un être humain.

Dans cet exemple, un terme person(‘Peter, 32)

Dénote une personne avec le nom ‘Peter qui a 32 ans. Pour simuler sa vie (et par la suite son vieillissement), le prochain état devrait être :

person(‘Peter, 33)

Une façon de modéliser un système de simulation d’âge serait l’équation :person(X,N) = person(X,N+1)

Dans un tel système il serait logiquement vrai queperson(‘Peter,32) = person(‘Peter,33)

Ce changement est réversible – de part la propriété de symétrie de la logique équationnelle –de sorte qu’on aura aussi :

person(‘Peter,33)= person(‘Peter,32),Et

person(‘Peter,32) = person(‘Peter,20)

Cependant dans le système que nous modélisons, cette propriété intuitivement ne devrait pas se tenir car on ne peut malheureusement diminuer notre âge. Le changement n'est habituellement pas réversible dans les systèmes dynamiques.

En d'autres termes, pour spécifier (ou changer/évoluer) un système dynamique, nous ne pouvons pas employer seulement des équations. En revanche, nous employons la logique de réécriture, qui prolonge des techniques algébriques de spécifications équationnelles pour modéliser les systèmes dynamiques.

2.4.2 Règles non conditionnelles de réécriture

Le problème avec l’utilisation des équations pour modéliser le comportement dynamique est, comme indiqué auparavant, le fait que l'égalité soit symétrique.

En logique de réécriture, le comportement dynamique est modélisé par des règles de réécriture. Une règle de réécriture est essentiellement une équation "à sens unique", et la logique de réécriture est de ce fait une logique équationnelle sans symétrie. Ainsi, le comportement dynamique d'une personne dans notre exemple peut être modélisé par une règle de réécriture :

person(X, N) => person(X, N+1)

Pour des variables appropriées X et N. Dans la logique de réécriture t => t’, est prévu pour signifier que l'état t peut changer en un état t'. Les règles de réécriture donnent les changements d’états locaux et atomiques comme dans l'exemple précédent.

Real Time Maude

48

Les règles non conditionnelles sont déclarées avec la syntaxe :

rl [<etiquette > ] : < Term1 > => < Term2 > .

Une règle de réécriture peut avoir une étiquette qui appelle l’action ou l’événement qui change l’état. Dans notre exemple, une règle étiquetée s’écrit avec la syntaxe:

rl [birth_day] : person(X,N) => person(X,N+1) .

Ou

rl [getting_older] : person(X,N) => person(X,N+1) .

L'étiquette n'influence pas le calcul/déduction dans la logique de réécriture.

2.4.3 Règles conditionnelles de réécriture

Les règles conditionnelles de réécriture peuvent avoir des conditions très générales impliquant des équations et autre réécritures.

Dans leur représentation en Maude, les règles conditionnelles sont déclarées avec la syntaxe :

crl [<etiquette > ] : < Term1 > => < Term2 >

if <Condition-1> and .. and <Condition-k> .

2.5 Les Modules Orientés-Objet

Les modules orientés objets peuvent être réduit aux modules systèmes. Par rapport aux modules systèmes, les modules orientés objets offrent une syntaxe plus appropriée pour décrire les entités de base du paradigme objet comme, parmi autres: classes, objets, messages et configuration.

Dans un système orienté objet concurrent, l'état concurrent, appelé une configuration (ligne 1), a typiquement la structure d'un multi-ensemble, composé d'objets et des messages (ligne 2). Donc, nous pouvons voir la création des configurations par un opérateur binaire d'union de multi- ensembles que nous pouvons le représenter par la syntaxe de la cinquième ligne :

1) sort Configuration .

2) sorts Object Msg .

3) subsorts Object Msg < Configuration .

4) op null : -> Configuration .

5) op _ _ : Configuration Configuration -> Configuration [assoc comm

id : null] .

Où l'opérateur d'union des multi-ensembles est déclaré pour satisfaire les lois structurelles de l’associativité et la commutativité et avoir le null comme identité. La déclaration de subsort à la troisième ligne ci-dessus déclare que les états de l'objet et des messages sont des configurations singletons.

Un objet dans un état donné est représenté comme un terme :

< O : C | a1 : v1 ,…, an : vn >

Real Time Maude

49

Où O est le nom de l'objet ou l'identificateur, C est sa classe, ai sont les attributs de l'objet et les vi sont les valeurs correspondantes.

Chaque classe est déclarée par la syntaxe :

class C| a1 : S1, …, an : Sn .

Où C : nom de la classe, ai des attributs, Si : type de chaque attribut.

La déclaration d’un message est définit par la syntaxe:

msg m : p1 , …, pn -> Msg .

Où m : nom de message, pi : sortes des attributs associés.

Des messages de mêmes sortes peuvent être déclarés en utilisant le mot-clé msgs.

Maude permet aussi l'héritage de classe : une déclaration de sous-classe est définit par la syntaxe :subclass C’ < C.

Tous les attributs, messages, et règles de la superclasse C, aussi bien que les attributs récemment définis, messages et règles de la sous-classe caractérisent la structure et le comportement de la sous-classe C’. L'héritage multiple est supporté par Maude.

Une seule règle (conditionnelle) de réécriture permet d’exprimer la consommation de certains messages, l’envoi de nouveaux messages, la destruction d’objets, la création de nouveaux objets, le changement de l’état de certains objets, etc.

La forme générale de ces règles est donnée comme suit :M1 M2 . . Mn < O1 : C1 / ListeAt1 > . . . < Om : Cm / ListeAtm > => < O1 : C1 / ListeAt’1 > . . < Ok : Ck / ListeAt’k > < Ol : Cl / ListeAt’’l > . . < Op : Cp / ListeAt’’p > M’1 M’2 . . M’q

Les messages M1 M2 . . Mn sont supprimés après l’exécution de la règle. Les états des objets O1 , . . . ,Ok sont modifiés. Les objets Ok+1 , . . . ,Om qui n’apparaissent que dans la partie gauche sont supprimés. De nouveaux objets Ol, . . . , Op sont crées. De nouveaux messages M’1 M’2 . . M’q sont crées.

La figure (3.2) illustre le module système BANK-ACCOUNT qui définit un objet compte bancaire A et les deux opérations capables d’affecter le contenu de son (crédit et débit) en exécutant la règle de réécriture définie dans ce module. La figure (3.3) représente le même module BANK-ACCOUNT mais avec une syntaxe orienté objet plus appropriée.

Figure 3.2. Le module système BANK-ACCOUNT.

Real Time Maude

50

Figure 3.3. Le module orienté-objet BANK-ACCOUNT.

Nous notons, qu’après l’exécution de la règle inconditionnelle [credit], le message credit (A, M)est consommé et le contenu de compte A est augmenté de M. De la même façon l’exécution de la règle conditionnelle [debit] exige que la condition (N >= M) soit vérifié. L’exécution de telle règle produit la consommation du message debit (A, M) et la réduction du contenu de compte A (Figure 3.4).

Figure 3.4. L'exécution du module BANK-ACCOUNT.

Pour plus de détail sur les notions de bases inhérentes à Maude le lecteur pourra se référer à [Cla05].

Maude est considéré comme un méta-langage pour développer d’autres langages, en effet Real-Time Maude (RT-Maude) est implémenté en Maude comme une extension de Full Maude.

3. Real Time-Maude (RT-Maude)

Une théorie de réécriture RT-Maude est une théorie de réécriture Maude, qui contient en plus la spécification [Olv06] :

D’une sorte Time pour décrire le domaine du temps qui peut être discret ou continue,

d’une sorte GlobalSystem avec un constructeur ‘’{_}’’ :

Et un ensemble de règles tick qui modélisent le temps écoulé dans le système qui ont la forme suivante :

Real Time Maude

51

Où u est un terme, qui peut contenir des variables, de sorte Time qui dénote la durée de la règle, et les termes t et t’ sont des termes de sorte System qui dénote l’état du système. Les règles de réécriture qui ne sont pas des règles tick sont des règles instantanées supposées prendre un temps zéro.

L’état initial doit toujours avoir la forme {t’’}, où t’’est un terme de sort System, afin que la forme des règles tick assure que le temps s’écoule uniformément dans toutes les parties du système.

Les théories de réécriture temps réel sont spécifiées en RT-Maude comme des modules temporisés ‘’tmod’’ (timed modules) ou des modules temporisés orientés-objet ‘’tomod’’ (timed object-oriented modules).

Real-Time Maude est implémenté en Maude comme une extension de Full Maude, donc tous les commandes et les modules doivent être déclarés entre parenthèses:

Dans ce qui suit nous introduisons d’abord les modules temporisés (Timed modules). Nous présenterons ensuite quelques exemples spécifiques à chacun des types de modules (temporisés et temporisés orientés-objet), plus de détails pourront être trouvés dans [41].

3.1 Les Modules Temporisés (Timed modules) Chaque module temporisé importe automatiquement le module fonctionnel TIMED-PRELUDEqui inclue les déclarations cruciales

Sorts System GlobalSystem .

op {_} : System -> GlobalSystem .

L’état d’un système doit être représenté par un terme de sorte System. Un module temporiséimporte aussi le squelette du domaine de temps qui est décrit ci-dessous.

3.1.1 Les Domaines de Temps (Time Domains)

Chaque module temporisé importe automatiquement le module TIME suivant :

fmod TIME issorts Time NzTime .subsort NzTime < Time .op zero : -> Time .op _plus_ : Time Time -> Time [assoc comm] .op _monus_ : Time Time -> Time .ops _le_ _lt_ _ge_ _gt_ : Time Time -> Bool.eq zero plus R:Time = R:Time .eq R:Time le R’:Time = (R:Time lt R’:Time) or (R:Time = = R’:Time) .eq R:Time ge R’:Time = R’:Time le R:Time .

Real Time Maude

52

eq R:Time gt R’:Time = R’:Time lt R:Time .endfm

Ce module définie un squelette du domaine de temps, avec la valeur zéro et quelque symboles de fonction.

En effet l’utilisateur a la liberté complète pour spécifier le type de données des valeurs de temps qui peuvent être discret ou bien continue par :

Importer un type de donné spécifique de valeurs temporelles qui satisfont la théorie du Temps, avec une sorte, dit TimeValues pour telles valeurs, et

Déclarer une inclusion subsort TimeValues < Time et donner les équations appropriées pour interpréter le constant zéro et les opérateurs _plus_, _monus_, et _ lt_ dansTimeValues.

RT-Maude contient le module suivant qui définit le domaine de temps comme étant des nombres entiers :

fmod NAT-TIME-DOMAIN isincluding LTIME .protecting NAT .subsort Nat < Time .subsort NzNat < NzTime .vars N N’ : Nat .eq zero = 0 .eq N plus N’ = N + N’ .eq N monus N’ = if N > N’ then sd(N, N’) else 0 fi .eq N lt N’ = N < N’ .endfm

Pour spécifier les domaines de temps continue, RT-Maude définit un sous ensemble (subsort) NNegRat de nombres rationnels non négatifs, et, dans le module POSRAT-TIME-DOMAIN, il définit le domaine de temps comme étant des nombres rationnel.

fmod POSITIVE-RAT isprotecting RAT .sort NNegRat .subsorts Zero PosRat Nat < NNegRat < Rat .endfm

fmod POSRAT-TIME-DOMAIN isincluding LTIME .protecting POSITIVE-RAT .subsort NNegRat < Time .subsort PosRat < NzTime .vars R R’ : NNegRat .eq zero = 0 .eq R plus R’ = R + R’ .eq R monus R’ = if R > R’ then R - R’ else 0 fi .eq R lt R’ = R < R’ . endfm

Real Time Maude

53

Pour résumer et pour spécifier le domaine de temps, l’utilisateur peut : Soit laisser le domaine de temps non spécifié pour les instanciations plus tardifs, ou Importé soit de l’un des modules NAT-TIME-DOMAIN ou POSRAT-TIME-DOMAIN, ou définir explicitement son propre module temporisé.

3.1.2 Les règles Tick

La syntaxe des règles tick inconditionnelles est :

rl [l] : {t} => {t’} in time u .

Une règle tick conditionnelle est écrite avec la syntaxe :

crl [l] : {t} => {t‘} in time u if cond .

Il faut noter que chaque module temporisé import automatiquement les sortes System et GlobalSystem et l’opérateur {_} aussi bien qu’un domaine de temps réduit, nous sommes maintenant prêt à en spécifier quelques exemples.

3.2 Exemples de Modules Temporisés : Modélisation d’une horlogeDans une série d’exemples nous donnons la spécification d’une horloge simple qui montre le

temps. Le terme clock (t) dénote une horloge qui montre le temps. Le module suivant (Figure 3.5) spécifie une horloge discrète où le temps avance toujours par une unité de temps dans chaque pas ‘’tick’’. Puisque le temps est discret nous utilisons les nombres naturels comme un domaine de temps et donc nous importons le module NAT-TIME-DOMAIN :

Figure 3.5. Le module temporisé DISCRETE-CLOCK-1.

Le système avance le temps par 1 dans chaque pas, avec le résultat que la valeur de l’horloge augmente par 1.

Nous savons tous qu’une horloge peut s’arrêter à cause d’une batterie plate ou autres échecs. Le module prochain (Figure 3.6) modélise une horloge qui peut s’arrêter à tout moment, dans le cas où l’état est stopped-clock(r), où r était la valeur de l’horloge quand celle ci est arrêtée. Une horloge discrète qui peut s’arrêter peut être modélisée par le module temporisé suivant :

Real Time Maude

54

Figure 3.6. Le module temporisé DISCRETE-BROKEN-CLOCK-1.

Le temps peut s’écouler bien que l’horloge est arrêtée, car nous savons tous que le temps s’écoule sans faire changer l’état d’une horloge arrêtée.

Supposer maintenant des horloges qui comptent les heures, donc quand l’horloge atteint 24 elle devrait montrer 0. Ce cadre peut être modélisé de différentes façons. La spécification suivante (Figure 3.7) augmente juste la valeur de l’horloge modulo 24.

Figure 3.7. Le module temporisé DISCRETE-CLOCK-24-2.

Pour obtenir une spécification légèrement plus intéressante (et légèrement différente), le module suivant (Figure 3.8) a une opération reset qui réinitialise une horloge avec la valeur 24 à 0 :

Figure 3.8. Le module temporisé DISCRETE-CLOCK-24.

L’état {clock(24)} passe à l’état {clock(0)} en utilisant une transition instantanée. La condition dans la règle tick assure que le temps ne peut pas s’écouler quand l’horloge en montre 24, donc {clock(24)}doit être réinitialisé à {clock(0)} avant que le temps continuer à avancer.

Bien que le temps discret est approprié pour modéliser les systèmes temps réel tel que la planification des algorithmes temps réel et des protocoles de communication, les systèmes hybrides sont souvent modélisés en utilisant le domaine de temps continu. La spécificationsuivante (Figure 3.9) modélise l’horloge décrit précédemment en utilisant le domaine de temps continu, à savoir les nombres rationnels non négatifs :

Real Time Maude

55

Figure 3.9. Le module temporisé DENSE-CLOCK-1.

Bien que l’exemple soit assez simple, les règles tick au-dessus sont typiques pour les systèmes avec le domaine de temps continu. A partir d’un état donné, le temps peut s’écouler par n’importe quelle valeur de temps jusqu' à ce que l’horloge atteigne la valeur 24. Cette augmentation non déterministe du temps est modélisée dans les règles tick par l’existence d’une nouvelle variable R’qui n’apparait pas dans le côté gauche de la règle, et qui n’est pas instancié dans la condition de la règle. Cette variable R’ peut en suite prendre n’importe quelle valeur entre 0 et 24-R.

3.3 Les Modules Temporisés Orientés-Objet (Timed Object-Oriented Modules)

Les modules temporisés orientés objet, définit entre les mots clés tomod et endtom, étendent les modules orientés objet de full Maude et les modules temps pour supporter la spécification orientéeobjet des systèmes temps réel.

Nous prenons l’exemple d’une spécification de ‘’protocole’’ pour calculer le temps d’aller-retour (Round Trip Time) entre les nœuds d’un réseau (c.à.d. le temps que prend un message pour aller et retourner entre deux nœuds initiateur et répondeur, dans un réseau).

Dans le protocole qui suit nous supposons qu’il y a un nœud expéditeur (initiateur) et un nœud répondeur dans le réseau, chacun d’entre eux est modélisé par un objet. La communication est modélisée par des messages ordinaires.

Le protocole est très simple : l’objet sender (de la class Sender) qui a une horloge locale, débute le protocole (dans la règle rttRequest) par l’envoi d’un message rtt ?(r) à l’objet responder où r est la valeur actuelle de l’attribut clock du sender. Quand l’objet responder lit le message rtt?(r) (dans la règle rttResponse ), il répond en envoyant un message rttAck(r) (c.à.d. avec le même temps qu’il a lu dans le message rtt ? ) en retour à sender. Finalement (dans la règle treatRttresp), l’objet sender reçoit le message rttAck avec le temps (originale), et trouve la valeur rtt (round trip time) en comparant le temps reçu au temps réel, qui est donné par son horloge locale. Le module temporisé RTT-1 (Figure 3.10) ne fixe pas le domaine de temps ou les noms des objets.

Real Time Maude

56

Figure 3.10. Le module temporisé orienté-objet RTT-1.

Le temps peut s’écouler par toute valeur dans la règle tick. Dans ce chemin, toute valeur de temps (en incluant le zéro) peut s’écouler entre les évènements rttRequest et rttResponse et entre les évènements rttResponse et treatRttResp. L’effet de temps écoulé sur une configuration est que l’horloge locale du sender est augmentée relativement au temps écoulé.

Le module DISCRETE-RTT-1 (Figure 3.11) instancie les noms des objets et le domaine de temps et définit un état initial à partir duquel on peut exécuter la spécification.

Figure 3.11. Le module temporisé orienté-objet DISCRETE-RTT-1.

4. Conclusion

Nous avons présenté dans ce chapitre un langage de spécification de systèmes temps réel, à savoir Real-Time Maude. RT-Maude au même titre que Maude, est un langage très puissant et très expressif. Il offre un outil pour la spécification formelle, la simulation et l’analyse formelle des systèmes temps réel. Il met en évidence la facilité et la généralité de spécification, y compris un support pour les systèmes temps réel orientés objet qui peuvent être distribués, et où le nombre d’objets et de messages peut changer dynamiquement. Real Time Maude constitue à notre avis un candidat parfait pour la translation des diagrammes AUML vers une notation formelle.

57

Chapitre 4

Formalisation des Besoins

Fonctionnels des SMA-Tempts

Réel

Formalisation des Besoins Fonctionnels des SMA-Temps Réel

58

Résumé

Plusieurs techniques d’analyse sont utilisées en génie logiciel pour la spécification des besoins. Allant du simple langage naturel de spécification des besoins aux méthodes formelles qui utilisent des langages mathématique.

L’analyse basée sur les cas d’utilisation (Use case analysis) est une technique particulière qui a fait ses preuves pour la spécification des besoins de différents types de système. Ce type d’analysea gagné de l’ampleur puisqu’il fait partie du langage de modélisation unifié UML [Boo99], et par conséquent Agent UML.

Selon [Pap00], l’approche guidée par les cas d’utilisation pour le développement de systèmes à plusieurs bénéfices : un cas d’utilisation est une vue de la fonctionnalité du système du point de vu de l’utilisateur ; il peut être considéré comme une collection de scénarios d’utilisation du système. Développeurs et utilisateurs utilisent souvent les scénarios pour les aider à comprendre les besoins. Ces besoins peuvent être spécifiés par des termes non techniques que l’utilisateur peut comprendre sans pour autant être un ingénieur logiciel (Software Engineer). Enfin la traçabilité des besoins à travers les phases de conception, d’implémentation et de teste du projet est améliorée.

Le génie logiciel orienté agent (Agent Oriented Software Engineering ’’AOSE’’) exige la spécification des comportements des agents afin de fournir des besoins documentés pour les phases de conception et d’implémentation. D’une façon générale, il ya deux nouvelles classes degénie logiciel orienté agent. La première classe est intéressée à construire des systèmes logiciels (qui peuvent inclure ou non des agents intelligents dans le produit final) et voie les agents comme un outil d’abstraction utile pour la spécification, la conception, et la documentation de ces systèmes. Et la deuxième classe est basée sur les technologies de génie logiciel pour développer les systèmes multi-agent [Hei00]. Nous nous intéressant à cette deuxième classe.

La méthodologie que nous proposons est fondée sur les techniques de modélisation existantes basée sur les cas d’utilisation fournies par le langage de modélisation graphique Agent UML, ainsi que sur le langage de spécification formelle RT-Maude. Une étude de cas à partir du domaine de la gestion de chaine logistique (Supply Chain Management, ‘’SCM’’) accompagne l’élaboration de la méthodologie.

Ce chapitre est organisé comme suit. Nous commençons par décrire le cadre générale de notre travail (section 1). Ensuite nous exposerons dans la section (2) les extensions faites sur les représentations d’Agent UML considérées ainsi que leurs significations. La section (3) donne le processus de translation proposé afin de transformer les descriptions semi-formelles résultantes de la modélisation en spécifications formelles RT-Maude. La dernière section (section 5) tire un premier bilan de l’application d’Agent UML et de RT-Maude.


59

1. Introduction

Depuis maintenant de nombreuses années, les concepteurs des systèmes multi-agent disposent de méthodologies de développement et de langage de modélisations sans pour autant tenir compte des différentes restrictions temporelle que peut avoir ces systèmes. De plus, même les méthodologies proposées pour le développement des SMA temps réel présentent des insuffisances, comme nous l’avons illustré à travers l’étude comparative présentée dans le premier chapitre des trois méthodes : ‘RT-Message’ [Jul04b]; ‘BDI-ASDP étendue pour le temps réel‘[Mel05]; et ‘la Méthode de développement de Lichen Zhang ’ [Zha06].

Néanmoins, La conception des systèmes multi-agent exige de l’associer avec des techniques du génie logiciel. Notre objectif général étant de proposer une approche générique pour une spécification orientée cas d’utilisation des besoins fonctionnels des SMA temps réel. Parmi ces techniques on trouve ‘UML’ [Boo99] qui est certainement le plus connu et le plus utilisé des langages de modélisation orienté objet. Les concepteurs de systèmes multi-agents disposent depuis peu des mêmes facilités en particulier avec le langage Agent UML. Le langage de modélisation Agent UML [Bau00b] [Ode00] hérite des travaux sur UML et intègre les différences qui existent entre les agents et les objets [Jen00]. Même si de nombreux papiers présentent Agent UML, comme l’atteste le site Internet de ce langage1, il n’existe pas à l’heure actuelle de travaux qui appliquent Agent UML à la spécification des SMA temps réel d’une part et à des applications réelles d’autre part.

En se concentrant sur la formalisation des besoins fonctionnels du futur système pour contraindre les limites de développement, la méthodologie que nous proposons diffère des autres méthodologies de modélisation par l’usage d’extensions au langage de modélisation graphique AUML en tenant compte bien sur, des travaux de Huget [Hug02c] [Hug02b], et Odell, Parnauk, Bauer [Ode00] qui présentent une vue du développement orienté agent qui allie attentivement les expériences de développement orienté objet. Le développement d’Agent UML est proposé pour étendre UML afin de mieux représenter les agents, cependant AUML dans sa version actuelle reste mal adapté pour tenir compte des spécificités de modélisation des SMA temps réel. Nous proposons d’étendre AUML pour effectuer une analyse basée sur les cas d’utilisation (use case analysis).

Le langage AUML est à notre avis le futur standard de l’industrie pour le développement des systèmes orientés agents. Il permet de modéliser et de décrire plusieurs vues complémentaires d’un même système. Cependant, AUML comme UML souffre d’un manque de sémantique formelle. Les modèles AUML développés pourront donc contenir des incohérences ou des inconsistances difficiles (voire impossibles dans le cas de certains systèmes complexes) à détecter manuellement.

Les méthodes formelles représentent une solution intéressante à ce problème. Les spécifications formelles auront pour effet d’éliminer les ambigüités au niveau de l’interprétation des modèles. La combinaison du formalisme de modélisation graphique Agent UML avec un langage de spécification formelle solide comme Real Time Maude permettra à notre avis de valider formellement les modèles AUML développés. Cette démarche permet d’éliminer certaines erreurs de façon précoce avant de passer aux phases de conception et d’implémentation.

1 AUML : http://www.auml.org


60

Donc, notre intérêt principal est de développer un cadre formel permettant la description des besoins fonctionnels des SMA temps réel, en utilisant les quatre types de diagrammes AUML : les diagrammes de classes (modélisant la structure statique d’un système), de cas d’utilisation (modélisant les besoins fonctionnels du système), d’état transition (modélisant le comportement interne des agents), et de protocole (modélisant le flux de messages échangés entre agents) que nous avons essayé d’étendre afin de prendre en compte les contraintes temporelles liées aux agents temps réels. Ces modèles AUML développés seront par la suite translatés vers des descriptions formelles en langage RT-Maude. L’approche développée a été évaluée sur un exemple concret qui est : la gestion de chaîne logistique (ou Supply Chain Management).

Les objectifs que nous avons fixés pour ce projet sont les suivants : (1) Définir une méthodologie pour aider les concepteurs à modéliser les SMA temps réel en combinant le formalisme de modélisation graphique AUML avec le langage de spécification formel Real Time Maude. (2) Déterminer quelles représentations d’Agent UML sont à modifier pour tenir compte des restrictions temporelles. En effet, il ne faut pas oublier que la plupart des représentations utilisées sont en fait celles provenant d’UML. (3) Montrer qu’Agent UML peut être appliqué à des applications grandeur nature, dans notre contexte nous avons choisi la gestion de chaîne logistique.

Dans la section suivante nous présentons notre approche qui est basée sur l’extension des diagrammes de cas d’utilisation, et de classe, en tenant compte soigneusement des propositions suggérées par Huget [Hug02b] [Hug02c], concernant les diagrammes de classe et de protocoles.

2. L’approche Proposée

2.1. Introduction

Comme nous l’indiquions en introduction, Agent UML est une extension d’UML afin de tenir compte les spécificités des systèmes multi-agents. Notre intérêt principal est de déterminer quelles représentations ont besoin d’être modifiées ou améliorées afin de prendre en compte les contraintes temporelles lors de la description des besoins fonctionnels des systèmes multi-agents temps réel. Les diagrammes de séquence ont déjà été modifiés puisqu’ils portent maintenant le nom de diagramme de protocole [Ode00] [Bau00], et correspondent à la représentation des protocoles d’interaction. Ces diagrammes de protocole au même titre que les diagrammes de classe ont été étendus par Huget [Hug02b] comme nous l’avons évoqué au chapitre (02).

Pour les diagrammes de classes de SMA, deux approches ont été proposées : celle de Bauer [Bau01b] et celle de Huget [Hug02c]. Plusieurs points de ressemblance existent entre ces deux approches puisqu’elles considèrent toutes les deux les attributs, les connaissances, les opérations, et les rôles ou capacités. La principale différence est sur la gestion des interactions. Huget [Hug02i] a proposé d’interpréter les protocoles dans les diagrammes de classe ce qui pose problème lorsque le nombre de protocoles augmente et si le nombre de message est important. En effet, Bauer Bauer [Bau01b] n’a pas lié assez son travail aux représentations UML puisque ‘’un diagramme est uniquement utilisé pour décrire une seul vue du système’’ : les diagrammes de classe agent sont utilisés pour représenter le contenu des agents et non comment ces derniers réalisent les actions liées aux messages. Une des solutions est d’insérer un lien aux diagrammes de protocoles et d’état transition dans le diagramme de classe agent.


61

A ces deux types de diagrammes s’ajoute les diagrammes d’état transition qui modélisent le comportement interne des agents du système, et les diagrammes de cas d’utilisation qui sont utilisés pour définir les fonctionnalités du système et donnent une analyse fonctionnelle de ce dernier.

Néanmoins, les contraintes temporelles qui représentent le concept clé de notre travail n’ont pas été traitées dans aucun de ces quatre types de diagrammes AUML. Un besoin qui nous a amené à étendre quelques un d’entre eux de façon que la spécification des besoins fonctionnels des systèmes multi-agents temps réel soit correcte. Par la suite les descriptions semi formelle AUML développées seront translatées dans une spécification formelle RT-Maude.

2.2. Les Diagrammes de Cas d’Utilisation AUML Temporisés (Aspect Fonctionnel)

Il a été prouvé que l’analyse basée sur les cas d’utilisation est très utile pour la spécification des besoins des systèmes orientés objet. La question qui se pose maintenant : est ce que ce type d’analyse peut être utilisé pour les systèmes orientés agent ? Il a été proposé dans [Pap00] qu’avec quelques modifications et extensions, l’analyse basée sur les cas d’utilisation peut devenir un outil intéressant pour la spécification du comportement et des besoins des systèmes multi-agent.

Les acteurs sont des entités externes (personnes ou autre systèmes), qui interagissent avec un système logiciel particulier, alors que les agents peuvent faire partie du système logiciel en cours de développement. L’environnement dans le quel les agents sont situés peut être un environnement virtuel synthétique, un environnement réel, ou une combinaison des deux, tout dépend du type d’agents.

Les agents sont souvent attribués avec des qualités et des capacités qui doivent être normalement associés aux acteurs humains. Dans différents types de systèmes qui ont des entités qui peuvent être attribué avec des notions propres aux agents, cela aide énormément dans la spécification des comportements si on traite ces entités comme des humains réels.

Etant donné que l’analyse basée sur les cas d’utilisation à fait ses preuve en matière de spécification des besoins des systèmes multi-agent [Hei00], [Pap00], [Bau05]. Cela nous a motivé à appliquer ces mêmes techniques mais avec quelques modifications et améliorations pour la modélisation des systèmes multi-agent temps réel. En utilisant le mécanisme d’extension de ‘’stéréotypage’’ offert par le langage de modélisation Agent UML, les diagrammes de cas d’utilisation seront enrichis par les ‘cinq stéréotypes’ suivantes :

Le stéréotype « Agent »

Le stéréotype « Agent » est proposé pour dénoter les agents classiques qui font partie du système. Dans un diagramme de cas d’utilisation un agent est enfermé à l’intérieure du système, il peut interagir avec d’autres agents ou acteurs via les cas d’utilisation (au quels il est impliqué), sa notation est donnée par la figure 4.1.

<<Agent>>

Figure 4.1. Agent.


62

Le stéréotype « External Agent »

Pour représenter les agents externes au système, nous proposer le stéréotype « External Agent ». Dans un diagramme de cas d’utilisation un agent externe se trouve à l’exterieur du système, il peut interagir avec d’autres agents ou acteurs via les cas d’utilisation au quels il est impliqué, sa notation est donnée par la figure 4.2.

<<External Agent>>

Figure 4.2. Agent externe.

Le stéréotype « Real Time Agent »

Le stéréotype « Real Time Agent » est utilisé pour dénoter les agents temps réel. Ces derniers se caractérisent par des restrictions temporelles à respecter. Dans un diagramme de cas d’utilisation un agent temps réel est enfermé à l’intérieure du système, où il peut interagir avec d’autres agents ou acteurs via ‘’les cas d’utilisation temporisés Agent’’. La notation associée à ce type d’agents(figure 4.3) est la même que pour l’agent classique.

<<Real Time Agent>>

Figure 4.3. Agent temps réel.

Le stéréotype « Agent Use Case »

Le stéréotype « Agent Use Case » (figure 4.4) est ajouté aux cas d’utilisation UML afin de décrire les cas d’utilsaition pour les SMA. Ces cas d’utilisation, sont des collections de scénarios d’interactions des agents avec le système. Chaque scénario décrit une séquence d’événements que l’agent initie. Le résultat de la séquence d’événements est à utiliser par l’agent initiateur, par un autre agent, ou par un quelconque acteur.

Figure 4.4. Cas d’utilisation pour agents.

Le stéréotype « Temporal Agent Use Case »

Le stéréotype « Temporal Agent Use Case » (figure 4.5) est semblable au stéréotype « Agent Use case » à la différence que ce stéréotype est proposé pour dénoter les cas d’utilisation contenant des contraintes temporelles. Ces cas d’utilisation sont des collections de scénarios concernant les interactions des agents temps réel avec le système.

Figure 4.5. Cas d’utilisation pour agents temps réel.

« Agent Use Case »Use case name

« Temporal Agent Use Case »Use case name


63

Ces cinq stéréotypes que nous avons définis ci-dessus complètes le formalisme de modélisation Agent UML en ce qui concerne la notation des cas d’utilisation.

2.3. Les Diagrammes de Classe AUML Temporisés (Aspect Structurel)

Comme il a été mentionné dans le chapitre (02), il existe deux propositions d’extension des diagrammes de classe, celles de Bauer [Bau01b] et de Huget [Hug02c], mais vu les critiques apportées à la première proposition, nous avons analysé la deuxième approche comme illustré au chapitre (02) et nous somme arrivés à la conclusion que cette approche dans sa version actuelle est mal adaptée pour tenir compte des spécificités des SMA temps réel. Donc, on doit l’améliorée afin de spécifier correctement la structure statique de ces systèmes.

Nous nous intéressons aux deux niveaux d’abstraction proposées par Huget [Hug02c], lors de la conception des diagrammes de classe : ‘’le niveau conceptuel et le niveau implémentation’’. ‘Le niveau conceptuel’ reste inchangé, il donne une vue assez haute du système multi-agents temps réel éliminant toutes les informations qui sont superficielles pour comprendre la structure du système (les attributs, les opérations), alors que ‘le niveau implémentation’ qui donne en détail le contenu des agents est à modifier comme suit :

A l’ensemble des compartiments proposés dans le diagramme de classe AUML [Hug02c], nous avons ajouté un nouveau compartiment appelé ‘’temporal constraint’’ dans lequel se trouve l’ensemble des restrictions temporelles (soft/hard) que l’agent temps réel doit respecter (voir figure 4.6).

« Real Time Agent »

role1, role2, …..., rolen

temporal constraint1 (soft/hard)…

temporal constraintn (soft/hard)

statechart1statechart2

…statechartn

attribute1attribute2

………attributen

operation1operation2

…operationn

protocol1 : roleprotocol2 : role

…protocoln : role

Figure 4.6. Diagramme de classe AUML proposé.


64

2.4. Les Diagrammes de Protocoles AUML Etendu (Comportement Collectif)

La partie principale d’Agent UML est les mécanismes de modélisation des protocoles d’interaction des systèmes multi-agents. Cela est réalisé par l’introduction d’une nouvelle classe de diagramme à UML : ‘’diagramme de protocole’’. Les diagrammes de protocole étendent les diagrammes de séquence UML en incluant : les rôles d’agents, multithreaded lifelines, protocole templates, etc.

Les diagrammes de protocole représentent les échanges de messages entre agents. Ces agents vont être représentés par leur ‘rôle’ dans l’interaction. En effet, les messages ne sont pas échangés d’un agent à un autre mais plutôt sont échangé d’un ‘rôle’ à un autre. L’avantage de cette approche est de réduire la taille du diagramme [Hug02d].

Les diagrammes de protocole sont certainement les plus achevés dans Agent UML puisque plusieurs travaux les considères [Ode00], [Bau00b], [Hug02b], [Hug02c], [Hug02f] pour n’en citer que quelques uns. Nous nous somme intéressés en particulier au travail de Huget [Hug02b] où il propose d’étendre ces diagrammes en y ajoutant d’autre propriétés tel que : ‘le broadcasting’, ‘la synchronisation’, ‘le traitement des exceptions’, ‘la gestion du temps’, etc.

Nous avons exploité la propriété de ‘’gestion du temps (time management)’’ afin de mieux gérer les contraintes temporelles (tel que : les délais (delay) et les dates limites (deadlines)) impliquées dans les protocoles d’interaction utilisés par les agents temps réel. Nous essayerons autant que possible d’appliquer cette propriétés aux différents besoins de l’exemple de la gestion de chaine logistique (Supply Chain Management ‘SCM’).

Cette propriété nous permet de décrire les deadlines (date limites) avec des notes sur les flèches dans le diagramme de protocole. Par exemple, le commentaire deadline se trouvant dans le protocole Contract Net lors de la réception des propositions (proposals) (figure 4.7). De plus, dans [Hug02b], la gestion du temps (time management) est insérée à deux niveaux :

Un des domaines d’application des SMA et des protocoles d’interaction est le commerce électronique et la négociation. Il parait intéressant d’avoir un deadline sur l’interaction globale, par exemple, lorsque la négociation ne progresse pas. Ce deadline est inséré au début du diagramme de protocole au-dessus des rôles d’agent dés qu’il est appliqué à l’interaction globale. Ce deadline est donné par le mot clé time (figure 4.8.a).

Il est nécessaire d’avoir un certain délai entre deux messages comme Agent UML le propose avec les commentaires. A présent, le délai est donné entre des parenthèses sous les flèches et précédé par le mot clé ‘’d :’’ (figure 4.8.b).


65

Figure 4.7. Le Protocole Contract Net dans Agent UML. [Hug02b]

Figure 4.8. La gestion du temps dans les diagrammes de protocoles [Hug02b].

Cette propriété de ‘gestion du temps (time management)’ nous semble très intéressante pour expliciter les contraintes temporelles des systèmes multi-agents temps réel.

2.5. Les Diagrammes d’Etat Transition AUML (Comportement Individuel)

Les diagrammes d’états (statechart diagram) au même titre que les diagrammes de protocole font partie des diagrammes décrivant le comprtement d’un système multi-agents. Les diagrammes d’états comme il a été présenté au chapitre 2, s’intéressent aux différents états du système et quelles sont les actions qui permettent de passer d’un état à l’autre du système. Ils semblent être une solution efficace pour décrire le comportement individuel des agents. En effet, ceux-ci passent d’un état donné à un autre en fonction des actions se produisant dans l’environnement ou en fonction des messages reçus.

Comme montionné dans [Hug02a], le principal constat que nous pouvons faire sur ce type de diagramme est qu’il est difficile de connaître à qui s’adressent les actions et comment se produisent les événements, s’il s’agit d’événements extérieurs provenant de la réception de messages ou de la modification de l’environnement. Chose résolue à travers la spécification formelle RT-Maude que nous proposons pour ce type de diagramme.


66

La section suivante donne le processus de translation proposé. Ce processus a pour objectif de translater les modèles semi formels AUML développés pour la modélisation du système multi-agent temps réel vers des notations formelles RT-Maude.

3. Processus de Translation Proposé

Tel qu’étudié aux chapitres 02 et 03, les techniques de modélisation graphique et de spécification formelle offrent chacune plusieurs avantages considérables lors du développement de logiciels.

Au chapitre 02, les concepts pertinents au formalisme de modélisation graphique Agent UML ont été introduits. Visiblement, les avantages d’une telle technique pour la description des besoins fonctionnels des SMA temps réel sont nombreux. De plus, au chapitre 03, l’environnement RT-Maude a été introduit. Ce langage qui est une extension de Maude, permet la spécification et l’analyse des systèmes temps réel, et plus particulièrement les systèmes temps réel orientés-objet. Il dispose d’une base mathématique solide, est constitue un candidat parfait pour la translation de diagrammes AUML vers une notation formelle.

Dans ce qui suit nous allons présenter le processus de translation proposé. Ce processus a pour objectif de translater les diagrammes AUML décrits ci-dessus (section 2) pour la description des besoins fonctionnels des systèmes multi-agent temps réel vers des notations formelles RT-Maude.

3.1. Translation des diagrammes AUML vers une spécificationformelle RT-Maude

A l’opposé de la plupart des travaux portant sur la formalisation des besoins fonctionnels des SMA temps réel , qui ne prennent pas en considération l’aspects statique du système avec les aspects fonctionnels et comportementales, nous avons développé dans le cadre de ce mémoire un cadre formel intégrant ces trois aspects en même temps.

Cette section présente une technique pour la translation des quatre types de diagrammes AUML en une notation formelle RT-Maude. Les quatre types de diagrammes utilisés sont les diagrammes qui ont été présentés dans la section 2 : les diagrammes de cas d’utilisation temporisés, de classes temporisés, de protocoles étendu, et d’état transition.

La technique consiste à dériver systématiquement une description formelle RT-Maude à partir de l’analyse de ces quatre types de diagrammes. Le processus de translation (figure 4.9) est divisé en trois grandes étapes majeures, que nous pouvons décrire comme suit :

1. Décrire le système multi-agent temps réel à l’aide de diagrammes AUML, plus particulièrement les quatre types de diagrammes qui seront décrits formellement à l’aide de RT-Maude ;

2. Validation inter-diagrammes ;

3. Génération de la description formelle RT-Maude.


67

Figure 4.9. Méthodologie de L’approche.

La première étape du processus de translation est en réalité l’étape d’analyse habituelle du processus de développement d’un système logiciel. Elle consiste en la description du système multi-agent temps réel à l’aide des représentations d’Agent UML. En ce qui concerne l’approche proposée, elle prend en considération les quatre types de diagrammes décrits précédemment.

Tel que discuté au chapitre 01, il est plutôt rare d’avoir une approche de spécification qui considère à la fois les aspects fonctionnels, statiques et dynamiques, des systèmes multi-agent temps réel. L’approche proposée, quant à elle, considère tous ces aspects conjointement. Le fait de considérer tous ces aspects est le concept novateur de l’approche proposée dans ce mémoire :

Le diagramme de classe AUML temporisé est utilisé pour représenter la structure statique du système multi-agent temps réel, la structure de ces classes d’agent, etc. ;

Le diagramme de cas d’utilisation AUML temporisé est utilisé pour représenter les besoins fonctionnels du SMA temps réel ainsi que les différents types d’agents impliqués;

Les diagrammes de protocole étendu ont pour objectif de représenter le comportement collaboratif des agents impliqués dans l’accomplissement d’une tâche.

Les diagrammes d’état transion ont pour objectif de représenter le comportement individuel des agents du système.

La deuxième étape du processus de translation a pour objectif de valider, autant que possible, l’exactitude des diagrammes utilisés. Une validation inter-diagrammes est effectuée sur tous les diagrammes utilisés pour s’assurer de la présence de tous les éléments nécessaires. Par exemple, on vérifie que chaque appel d’une fonction par un message envoyé à un agent destinataire dans le diagramme de protocole doit apparaître comme une méthode dans la classe d’agent destinataire du diagramme de classe. Par ailleurs, les variables utilisées lors de l’appel d’une fonction doivent apparaître comme des attributs dans la classe de l’agent source ou dans d’autres classes du diagramme à condition que l’agent source puisse y accéder et les utiliser. L’approche que nous proposons ici se limite qu’à ces quatre types de diagrammes, et aux notations de base de ces derniers.


68

La dernière étape de ce processus de translation consiste en la génération systématique de code source du langage RT-Maude à partir des diagrammes AUML considérés. Tout en précisant que l’approche proposée considère un diagramme de cas d’utilisation, un diagramme de classes et un ensemble de diagramme de protocole et d’état transition à la fois, puisque chaque cas d’utilisation du diagramme de cas d’utilisation peut être réalisé par un ou plusieurs diagrammes de protocole et d’état transition.

3.2. La Description des différents Modes d'interaction entre Agents

Pour décrire les différents modes d’interaction introduit par le formalisme AUML dans RT-Maude, nous avons adopté l’alternative basée sur les messages proposée dans [Mok10]. En effet, les trois modes d’interaction définis dans AUML sont tous supportés par RT-Maude.

Le mode ‘AND’: nous utilisons une seule règle de réécriture (figure 4.10) pour décrire la forme d’interaction AND. Cette règle exprime l’envoi simultané de plusieurs messages Mi.

rl [L] : < A1 : C1 | PlayRole : R1, …> < A2 : C2 | PlayRole : R2, …>

=> < A1 : C1 | PlayRole : R1, …> < A2 : C2 | PlayRole : R2, …> M1( …) M2(…) … Mn(….)Figure 4.10. La Description du mode d’interaction ‘AND’ dans RT-Maude.

Le mode ‘inclusive OR’: pour décrire la forme d’interaction ' includive or ', nous utilisons mrègles de réécriture (m ≤ n) (n est le nombre de messages attachés au connecteur ‘OR’). Ces règles partagent dans leur partie gauche un même message M généré auparavant (figure 4.11).

rl [Li] : < A1 : C1 | PlayRole : R1, …> < A2 : C2 | PlayRole : R2, …> M(…)

=> < A1 : C1 | PlayRole : R1, …> < A2 : C2 | PlayRole : R2, …> M1( …) M2( …) … Mk( …)Figure 4.11. La Description du mode d’interaction 'inclusive or' dans RT-Maude.

Cette proposition permet à une seule instance du message M de lancer l’exécution d’une seule règle de réécriture parmi les m règles.

Le mode 'exclusive OR' : dans ce cas nous utilisons N règles de réécriture de la forme définie dans la figure 4.12, dont l’exécution de l’une exclut l’exécution du reste.

rl [Li] : < A1 : C1 | PlayRole : R1, …> < A2 : C2 | PlayRole : R2, …> M(..)

=> < A1 : C1 | PlayRole : R1, …> < A2 : C2 | PlayRole : R2, …> Mi(CA-i , …) .Figure 4.12. La Description du mode d’interaction 'exclusive OR’ dans RT-Maude.

De la même manière que celle définie pour le mode ‘inclusive OR’, chaque règle (parmi les N règles) contient dans sa partie gauche un message M généré auparavant. Cela permet d’exécuter une seule règle (celle qui consomme en premier le message M) tout en bloquant le reste.


69

3.3. Architecture du Framework Proposé

Tel que mentionné au chapitre 03, la structure d’un programme RT-Maude est divisé en modules de divers types. La génération systématique du code source RT-Maude lors de l’application du processus de translation décrit précédemment se fera au moyen de plusieurs modules RT-Maude. Notre framework est composé de plusieurs modules : neuf modules fonctionnels, sept modules orienté objet, et quatre modules orienté objet temporisé. La figure 4.13résume visuellement ces modules qui seront générés.

Figure. 4.13. Les Modules Générés par le Processus de Translation.

Dans les paragraphes qui suivent nous allons présenter l’ensemble des modules proposés, toute fois nous tenons à préciser qu’il y a deux types d’agents : les agents externes au système et d’autres internes. Ces agents internes peuvent être des agents classiques ou temps réel.

Le module fonctionnel STATE (figure 4.14) contient les déclarations des différents types nécessaires pour la description d’un état du diagramme d’état transition (ligne [1]) aussi bien que la définition des opérations utilisées pour la construction et la manipulation d’un état (lignes [2]).

(fmod STATE is sorts State NameState . ---[1] op AgentState : NameState -> State . ---[2] endfm)

Figure 4.14. Le module fonctionnel STATE.

Dans le module fonctionnel ACTION (figure 4.15), en plus du type Action (ligne [1]), nous définissons trois autres fonctions : IsInternalAction, IsReceivingAction, et IsSendingAction (lignes [2, 3, 4]). La première fonction détermine si une action est interne, alors que les deux dernières fonctions déterminent respectivement si l’action est une action de réception ou bien elle est destinée à un

ModuleImporter

Importation Optionnelle

STATE

CONDITION

ACTION

IDENTIFICATION

ACQUAINTANCE-LIST

ROLE

STATE-OPERATION

MESSAGE

MESSAGE-MANAGEMENT

MAILBOXAGENT-CLASS

REAL-TIME-AGENT-CLASS

EXTERNAL-AGENT-CLASS

AGENT BEHAVIOR

LINKED-BEHAVIORS

EXTERNAL-AGENTS

AGENTS

REAL-TIME-AGENTS

USE-CASE1

USE-CASE2

USE-CASEn

USE-CASEn-1

RTMAS-FUNCTIONAL-REQUIREMENTS


70

accointant de la liste d’accointances des agents.

(fmod ACTION is sort Action . ---[1] op IsInternalAction : Action -> Bool . ---[2] op IsReceivingAction : Action -> Bool . ---[3] op IsSendingAction : Action -> Bool . ---[4] endfm)

Figure 4.15. Le module fonctionnel ACTION.

Pour modéliser le méta-comportement des agents, nous avons défini un module fonctionnel STATE-OPERATIONS (figure 4.17). Ce module réutilise les modules STATE, ACTION ainsi que le module fonctionnel CONDITION (figure 4.16) qui est utilisé pour définir le type condition (ligne [1]). Ce module STATE-OPERATIONS inclut la définition de deux opérations : TargetState (ligne [1]) qui détermine le prochain état à partir de l’état source et d’une condition, et l’opération ActionToAccomplish (ligne [2]) qui détermine l’action à accomplir en tenant compte l’état de l’agent et la condition.

(fmod CONDITION is sort Condition . ---[1]endfm)

Figure 4.16. Le module fonctionnel CONDITION.

(fmod STATE-OPERATIONS is protecting STATE . protecting CONDITION . protecting ACTION . op TargetState : State Condition -> State . ---[1] op ActionToAccomplish : State Condition -> Action . ---[2]endfm)

Figure 4.17. Le module fonctionnel STATE-OPERATIONS.

Et pour rester conforme au comportement individuel des agents, nous proposons les modules fonctionnels : AGENTi-BEHAVIOR (figure 4.18), dans les quelles on a importé le module STATE-OPERATIONS. Le nom de chaque module est la concaténation du nom de la classe d'agentset la chaîne de caractères BEHAVIOR. Dans ces modules, l’utilisateur va spécifier dans cet ordre l’ensemble : des états de chaque agent, les conditions et les actions possible de chaque un, les états à atteindre selon l’état source et la condition, et finalement le type de chaque action (interne ou externe).

(fmod AGENTi-BEHAVIOR is protecting STATE-OPERATIONS.***************************** User Part….endfm)

Figure 4.18. Le module fonctionnel AGENTi-BEHAVIOR.

Pour respecter les interactions entre les différents agents, nous proposons de réaliser une sorte de liaison entre ces derniers (des points de synchronisation). Une telle liaison consiste à garantir qu’au moment de la réception d’un message, un agent ne peut consommer de tel message seulement s’il est dans l’état correspondant à l’état de l’agent expéditeur de ce message. En effet un agent qui est dans un état de communication génère un évènement externe ce qui implique une transition chez l’agent receveur de cet évènement. Cependant, pour recevoir de tel évènement, ce dernier (le receveur) doit être dans un état d’attente. Donc, les messages envoyés par l’agent expéditeur représentent des évènements pour l’agent destinataire. Alors nous pouvons dire qu’il y a une correspondance entre les


71

actions envoyées et les évènements reçus. Pour cela, nous avons défini un module nommé LINKED-BEHAVIORS (figure 4.19), dans lequel les modules AGENTi-BEHAVIOR ont été importés.

Dans ce module nous avons explicité la correspondance entre les différents états des agents d’une part et les actions de l’expéditeur et les évènements reçus par le receveur d’autre part, via les deux opérations CorrespondingState et CorrespondingCondition (lignes [1, 2]) respectivement.

(fmod LINKED-BEHAVIORS is protecting AGENTi-BEHAVIOR . op CorrespondingState : State -> State . ---[1] op CorrespondingCondition : Action -> Condition . ---[2]******************************* User Part…endfm)

Figure 4.19. Le module fonctionnel LINKED-BEHAVIOR.

Afin de décrire le mécanisme d’identification des agents, nous avons défini le module orienté objet IDENTIFICATION (figure 4.20).

(omod IDENTIFICATION is sort Identifier . subsort Oid < Identifier .endom)

Figure 4.20. Le module orienté objet IDENTIFICATION.

Pour la description de la structure des messages éventuellement échangés entres les différents agents, nous avons défini un module orienté objet nommé MESSAGE (figure 4.21) qui import les deux modules IDENTIFICATION, et ACTION. Ce module définit le type : Message (ligne [1]) ainsi qu’un ensemble d’opérations et d’équations pour les manipulées. Un message doit contenir les noms de l'émetteur et du receveur ainsi que son contenu (ligne [2]). Ces messages échangés doivent être stockés dans des boites aux lettres, c’est pour cela que nous avons proposé le module fonctionnel MAILBOX (figure 4.22) qui contient un ensemble d’opérations : FrontMBox ligne [1] (donne le premier élément de la liste), RemoveMbox ligne [2] (supprime le premier élément de la liste)…etc. et des équationspour implémenter ces opérations et tous cela dans le but de gérer la communication entre les agents(i.e. les agents internes).

(omod MESSAGE is protecting IDENTIFICATION . protecting ACTION . sort Message . ---[1] sort Content . ---[2] subsort Action < Content . op _:_:_ : Identifier Content Identifier -> Message . op GetIdent : Message -> Identifier . vars A A1 : Identifier . var Cont : Content . eq GetIdent (A : Cont : A1) = A . endom)

Figure 4.21. Le module orienté objet MESSAGE.

(fmod MAILBOX is protecting MESSAGE . sort MailBox . subsort Message < MailBox . op ErrorMessage : -> Message . op ErrorMailBox : -> MailBox .


72

op EmptyMailBox : -> MailBox . op FrontMBox : MailBox -> Message . ---[1] op RemoveMBox : MailBox -> MailBox . ---[2] op __ : Message MailBox -> MailBox . op InsertInMBox : Message MailBox -> MailBox . ---[3] var M : Message . var MB : MailBox . eq RemoveMBox(EmptyMailBox) = ErrorMailBox . eq RemoveMBox(M EmptyMailBox) = EmptyMailBox . eq RemoveMBox(M) = EmptyMailBox . eq RemoveMBox(M MB) = MB . eq FrontMBox(M MB) = M . eq FrontMBox(M) = M . eq FrontMBox(EmptyMailBox) = ErrorMessage . eq M EmptyMailBox = M . eq InsertInMBox(M, MB) = if MB == EmptyMailBox then M else M MB fi . endfm)

Figure 4.22. Le module fonctionnel MAILBOX.

Comme évoqué plus haut, un agent (externe ou interne) doit être doté d’une liste d’accointances(liste des agents avec lesquels il est amené à communiquer) afin d’identifier les agents avec lesquelles il va s’échanger des messages. C’est pour cela que nous avons défini le module fonctionnel AQUAINTANCE-LIST (figure 4.23) pour lui permettre de gérer sa liste d’accointances à travers un ensemble d’opérations.

(fmod ACQUAINTANCE-LIST is including STRING . sorts AcquaintanceList Acquaintance . subsort Acquaintance < AcquaintanceList . subsort String < Acquaintance . op HeadA : AcquaintanceList -> Acquaintance . ---[1] op TailA : AcquaintanceList -> AcquaintanceList . ---[2] op _:_ : Acquaintance AcquaintanceList -> AcquaintanceList . op ErrorAcquaintance : -> Acquaintance . op ErrorAcquaintanceList : -> AcquaintanceList . op EmptyAcquaintanceList : -> AcquaintanceList . op IsEmptyAcquaintanceList : AcquaintanceList -> Bool . var Ac : Acquaintance . vars AcL : AcquaintanceList . eq Ac : EmptyAcquaintanceList = Ac . eq IsEmptyAcquaintanceList(EmptyAcquaintanceList) = true . eq IsEmptyAcquaintanceList(Ac : AcL) = false . eq HeadA(EmptyAcquaintanceList) = ErrorAcquaintance . eq HeadA(Ac : AcL) = Ac . eq HeadA(Ac) = Ac . eq TailA(EmptyAcquaintanceList) = ErrorAcquaintanceList . eq TailA(Ac : AcL) = AcL . eq TailA(Ac) = EmptyAcquaintanceList .endfm)

Figure 4.23. Le module fonctionnel AQUAINTANCE-LIST.

Le module fonctionnel ROLE (figure 4.24) décrit un type nommé AgentRole (ligne [1]), que nous avons utilisé pour définir l’ensemble des rôles que peut jouer les différents agents internes du système(classique et temps réel).


73

(fmod ROLE is sort AgentRole . ---[1] *************** User Part …endfm)

Figure 4.24. Le module fonctionnel ROLE.

Maintenant pour la définition des opérations d’envoi et de réception : SendMessage et ReceiveMessage (lignes [1, 2]), nous avons défini le module orienté-objet MESSAGE-MANAGEMENT (figure 4.25). Ce dernier importe les deux modules AQUAINTANCE-LIST et MESSAGE.

(omod MESSAGE-MANAGEMENT is protecting ACQUAINTANCE-LIST . protecting MESSAGE . subsort Acquaintance < Identifier . op SendMessage : Message -> Msg . ---[1] op ReceiveMessage : Message -> Msg . ---[2] endom)

Figure 4.25. Le module OO MESSAGE-MANAGEMENT.

Pour définir la classe de base des différents agents externes au système, nous avons proposé le module orienté objet EXTERNAL-AGENT-CLASS (figure 4.26). Cette classe à comme attributs CurrentState, et AcqList, qui représentent dans cette ordre l’état courant et la liste des accointances de l’agent. Ce module importe les deux modules STATE, et MESSAGE-MANAGEMENT.

(omod EXTERNAL-AGENT-CLASS is protecting STATE . protecting MESSAGE-MANAGEMENT . class ExtAgent | CurrentState : State, AcqList : AcquaintanceList . ---[1] endom)

Figure 4.26. Le module OO EXTERNAL-AGENT-CLASS.

Pour la description formelle des agents internes (classique), nous proposons le module orienté objet AGENT-CLASS (figure 4.27), dans lequel est définie la structure de la classe de base des agents impliqués dans le système. Cette classe Agent (ligne [1]) a comme attributs : PlayRole, CurrentState, MBox, et AcqList pour contenir dans l'ordre, le rôle joué par l'agent, son état courant, sa boîte aux lettres et la liste de ses accointances. Ce module importe l’ensemble des modules STATE, ROLE, MAILBOX, et MESSAGE-MANAGEMENT.

(omod AGENT-CLASS is protecting STATE . protecting ROLE . protecting MAILBOX . protecting MESSAGE-MANAGEMENT . class Agent | CurrentState : State, PlayRole : AgentRole, AcqList : AcquaintanceList, MBox : MailBox . --[1] endom)

Figure 4.27. Le module OO AGENT-CLASS.

Afin d’avoir des agents temps réel nous avons défini une classe Real-TimeAgent avec l’attribut Clock (son horloge) (ligne [1]) dans le module orienté objet temporisé REAL-TIME-AGENT-CLASS (figure 4.28).

En résumé, la classe RealTimeAgent qui est une sous classe de la classe Agent (ligne [2]) contient l’ensemble des attributs : PlayRole, CurrentState, AcqList, MBox, et Clock, pour représenter dans l’ordre, le rôle actuel de l’agent, son état courant, sa liste d’accointances, sa boite aux lettres, et son horloge locale.

(tomod REAL-TIME-AGENT-CLASS is extending AGENT-CLASS .


74

class RealTimeAgent | Clock : Time . ---[1] subclass RealTimeAgent < Agent . ---[2] endtom)

Figure 4.28. Le module OO temporisé REAL-TIME-AGENT-CLASS.

Les trois modules EXTERNAL-AGENTS (figure 4.29), AGENTS (figure 4.30), et REAL-TIME-AGENTS (figure 4.31) qui étendent dans cet ordre les modules EXTERNAL-AGENT-CLASS, AGENT-CLASS, et REAL-TIME-AGENT-CLASS, sont définis afin de permettre à l’utilisateur d’en spécifier l’ensemble des ‘’agents externes’’ et ‘’des agents internes ’’ (classique et temps réel) dont il a besoins.

(omod EXTERNAL-AGENTS is extending EXTERNAL-AGENT-CLASS .*************** User Part … endom)

Figure 4.29. Le module OO EXTERNAL-AGENTS.

(omod AGENTS is extending AGENT-CLASS . *************** User Part … endom)

Figure 4.30. Le module OO AGENTS.

(tomod REAL-TIME-AGENTS is extending REAL-TIME-AGENT-CLASS . *************** User Partendtom)

Figure 4.31. Le module OO temporisé REAL-TIME-AGENTS.

A chaque cas d’utilisation du système est associé un module orienté objet temporisé USE-CASEi(figure 4.32), qui porte le même nom du cas d’utilisation correspondant. Dans chacun de ces modules sont définies les règles de réécriture décrivant les différents scénarios d’interaction entre les agents définis dans les différents diagrammes de protocole AUML correspondants. Notons, que ces règles peuvent être des règles classiques (instantanées) ou temporisées (tick rules), conditionnelles ou inconditionnelles.

(tomod USE-CASEi is *************************** User Part including NAT-TIME-DOMAIN . including EXTERNAL-AGENTS. including AGENTS . including REAL-TIME-AGENTS . including LINKED-BEHAVIORS . subsort String < Identifier .rl [1] : Configuration1 => Configuration2.…rl [m] : Configuration 2m-1 => <Configuration2m . endtom)

Figure 4.32. Un module orienté objet temporisé décrivant un cas d'utilisation.

Une fois générés, tous les modules USE-CASEi sont importés dans le module orienté objet temporisé RTMAS-FUNCTIONAL-REQUIEREMENTS (figure 4.33) qui décrit l’ensemble des besoins fonctionnels du système multi-agents temps réel. Ce module représente le noyau de notre travail.

(tomod RTMAS-FUNCTIONAL-REQUIREMENTS is


75

including USE-CASE1 . including USE-CASE2 . … including USE-CASEm . endtom)

Figure 4.33. Le module orienté objet temporisé RTMAS-FUNCTIONAL-REQUIREMENTS.

3.4. Les Relations entre Cas d’utilisation dans RT-Maude

L’aspect sémantique des trois relations ‘’d’inclusion’’, ‘’d’extension’’, et ‘’d’héritage’’ ont été présenté dans le chapitre 2 du présent mémoire, reste à décrire comment ces relations seront formulées dans le langage RT-Maude. Comme mentionné plus haut (figure 4.32) à chaque cas d’utilisation est associé un module orienté objet temporisé.

La relation d’inclusion stéréotypée « include » : nous aurons une spécification formelle qui importe une autre spécification. La figure 4.34 montre la spécification de la relation d’inclusion entre les cas d’utilisation A-INCLUDING et B-INCLUDED. Le comportement du premier inclut celui du deuxième.

Figure 4.34. Spécification RT-Maude de deux cas d'utilisation reliés par la relation d’inclusion[Ham09].

La relation d’extension stéréotypée « extend » : L’exécution du scénario du cas d’utilisation étendant (extending) est liée à la satisfaction de la condition ‘’point d’extension’’ (cas d’utilisation étendant peut être appelé au cours de l’exécution du cas étendu (extended)). Dans ce cas on peut utiliser une règle de réécriture conditionnelle qui représente le point d’extension au niveau du diagramme du cas d’utilisation. La figure 4.35 présente la spécification RT-Maude de la relation d’extension.

Figure 4.35. Spécification RT-Maude de deux cas d'utilisation reliés par la relation d’extension[Ham09].


76

La relation généralisation : Ce type de relation est également translaté avec RT-MAUDE par l’importation de modules (figure 4.36). Le module qui décrit le cas d’utilisation particulier (spécial) doit importer celui qui décrit le cas d’utilisation général tout en se basant sur la création des classes dérivées en utilisant le mot clé subclass dans le module spécial à partir des classes de base définies dans le modules général. Les instances des classes dérivées (qui sont définies dans le module spécial) peuvent réutiliser les règles de réécritures définies dans le module importé (le module général). Parfois, nous ne créons pas des sous classes mais nous proposons de nouvelles opérations. Autrement dit, nouspouvons se limiter à définir de nouvelles règles de réécritures dans le module spécial pour spécialiser le comportement du cas d’utilisation général.

Figure 4.36. Spécification RT-Maude de deux cas d'utilisation reliés par la relation de généralisation[Ham09].

4. Conclusion

Dans ce chapitre, une nouvelle approche pour la formalisation des besoins fonctionnels des systèmes multi-agents temps réel est présentée. Tout d’abord, cette approche se propose de combiner les avantages du formalisme de modélisation graphique Agent UML et du langage de spécification formelle RT-Maude dans une seule et unique technique. Cette technique est basée sur un processus de translation en trois étapes : (1) Décrire le système multi-agent temps réel à l’aide des quatre représentations semi-formelles AUML considérées; (2) validation inter-diagrammes ; et (3) Génération de descriptions formelles RT-Maude à travers le framework formel proposé. Ce framework est composé de plusieurs modules (neuf modules fonctionnels, sept modules orienté objet, et quatre modules orienté objet temporisé).

La nouveauté qu’apporte la technique est de considérer à la fois les aspects fonctionnels, statiques et les aspects dynamiques d’un système multi-agent temps. Les aspects fonctionnels sont décrits par un diagramme de cas d’utilisation AUML temporisé, les aspects statiques du système sont représentés à l’aide d’un diagramme de classes AUML temporisé. Quant à eux, les aspects dynamiques sont de deux natures : le comportement individuel des agents, ainsi que leur comportement collectif. Ces deux types de comportement sont représentés respectivement par des diagrammes d’état transition et de protocole AUML étendu. Donc, la méthodologie que nous proposons est fondée sur les techniques de modélisation existantes basée sur les cas d’utilisation fournies par le langage de modélisation graphique Agent UML, ainsi que sur le langage de spécification formelle RT-Maude. Dans le chapitre suivant une étude de cas à partir du domaine de la gestion de chaine logistique (Supply Chain Management, ‘’SCM’’) accompagne l’élaboration de la méthodologie.

77

Chapitre 5

Etude de cas:

‘’Gestion de Chaîne

Logistique’’

Etude de Cas : ‘’Gestion de Chaîne Logistique’’

78

Introduction

Dans le chapitre 4, un cadre formel pour la description des besoins fonctionnels des systèmes multi-agents temps réel à l’aide de l’environnement RT-Maude a été présenté. Ce processus, aux premiers abords, peut paraître abstrait et difficile à comprendre. Afin de mieux l’illustrer, une étude de cas à partir du domaine de la gestion de chaine logistique est présentée dans ce chapitre.

La gestion de chaîne logistique [Swa97], consiste à modéliser le processus de production et de vente au sein des entreprises. Elle met en jeu à la fois les clients et les fournisseurs de cette entreprise. Une exécution de la chaîne logistique permet de voir la réalisation d’une commande, de la génération de cette commande, et de la négociation du prix et du ‘délai’ jusqu’à la livraison chez le client.

Ce qui est à noter, c’est que la décomposition du système multi-agents temps réel proposée dans le cadre de l’application de gestion de chaîne logistique est semblable à celle présenté dans [Hug02a]. Nous ne cherchons en aucun cas à définir une nouvelle décomposition de la gestion de chaîne logistique. Notre travail ne porte que sur l’application d’Agent UML et de RT-Maude à cet exemple.

Nous commencons par présenter le domaine de la gestion de chaine logistique (section 1), en suite nous présentons le résultat de l’application du processus de translation à cet exemple (section 2), et nous terminons par une conclusion sur cette validation.

1. Présentation

La gestion de la chaîne logistique (ou Supply Chain Management, SCM) comme Huget [Hug02a], la fait savoir, modélise la production dans l’entreprise du passage de la commande du client jusqu’à la livraison. Elle fait intervenir un certain nombre de notions comme la réception de l’ordre, la planification de la réalisation du produit, la réalisation proprement dite, etc.

Dans cet exemple (figure 5.1) nous considérons deux agents externes qui sont: (1) les clients qui passent les ordres, les modifient et les annulent, et (2) les fournisseurs de matières premières ou de produits manufacturés pour la réalisation des produits, en plus de (3) l’entreprise là où se situentles agents internes modélisant l’ensemble de la chaîne de production.

Figure 5.1. La gestion de chaîne logistique [Hug02a].

La décomposition du système multi-agents temps réel que nous proposons dans le cadre de l’application de gestion de chaîne logistique est un peut proche de celle présenté dans [Hug02a]. Nous ne cherchons en aucun cas à définir une nouvelle décomposition de la gestion de chaîne


79

logistique. Notre travail ne porte que sur l’application d’Agent UML et de RT-Maude à cet exemple.

2. Application du Processus de Translation

2.1. La Décomposition Agents de la Gestion de Chaîne Logistique

La gestion de la chaîne logistique a déjà fait l’objet de réalisation par l’intermédiaire d’un système multi-agents. Shen et Norrie [SHE 99], présentent un ensemble de plates-formes et de réalisations avec des agents. Il s’agit de plus d’un des domaines de recherche du laboratoire Entreprise Integration de l’université de Toronto. Comme évoqué plus haut la décomposition que nous choisissons pour cette application est proche de celle présentée dans [Hug02a], à quelques différences conceptuels. Différents types d’agents vont intervenir dans cette application, on trouve deux agents externes et six agents internes (figure 5.2) comme illustré ci-dessous :

Le client qui est un agent externe au système, passe des ordres de commande, les modifient et les annulent.

Un agent order acquisition (agent interne) qui reçoit les commandes provenant des clients, gère les interactions avec ceux-ci et passe les commandes à l’agent temps réel logistics. Il négocie les contraintes imposées par le client avec l’agent temps réel logistics et informe le client de tout retard dans la livraison de sa commande.

Un agent temps réel logistics (agent interne) négocie les coûts et les délais avec l’agent order acquisition en fonction des contraintes imposées par le client. Une fois que la commande est effective, il demande la génération d’un plan à l’agent temps réel scheduler.

Un agent transporter (agent interne) qui se charge du transport des matières premières et des produits manufacturés entre les différentes chaînes de production en fonction du plan défini. Il assure de plus la livraison du produit au client.

Un agent temps réel scheduler (agent interne) qui définit le plan de production du produit et indique à l’agent temps réel logistics si les contraintes imposées sur la livraison du produit sont acceptables ou non. Ce plan est en mesure de varier si l’agent dispatcher ou l’agent resource indique qu’il y a des problèmes ou des retards entraînant une remise à jour du plan.

Un agent resource (agent interne) se charge de l’approvisionnement de l’usine et de la relation avec les fournisseurs.

Un agent dispatcher (agent interne) qui distribue les tâches en fonction de la planification qui a été faite par l’agent temps réel scheduler et informe celui-ci si un retard dans la production est à prévoir.

Le provider qui est aussi un agent externe au système, fournit les matières premières nécessaires pour la fabrication des produits, et négocie avec l’agent resource, le coût et le délai de livraison.


80

Figure 5.2. La gestion de chaîne logistique selon une approche multi-agents.

La liste précédente donne les différents types d’agents impliqués. Les relations entre ces agents sont résumées à la figure 5.2.

Dans ce qui suit nous présentons les différents diagrammes AUML appliqués pour la modélisation de l’exemple de gestion de chaîne logistique.

2.2. Modélisation de l’Exemple avec les Diagrammes AUML Etendus

2.2.1. Le Diagramme de Cas d’Utilisation AUML Temporisé du ‘’SCM’’

La figure 5.3, présente le diagramme de cas d’utilisation du ‘’SCM’’, où nous avons défini deux agents externes (le client et le Provider) et six agents internes (order-acquisition, logistics, scheduler, dispatcher, resource, et transporter), chacun deux joue un rôle particulier. Ces agentsinteragissent avec les trois cas d’utilisations temporisés : Place-Order ; Modify-Order ; et Delete-Order. Le cas d’utilisation Place-Order est lié au cas d’utilisation Modify-Order par la relation « Include », et au cas d’utilisation Delete-Order par la relation « Extend ».

Figure 5.3. Diagramme de Cas d’Utilisation AUML Temporisé du ‘’SCM’’.

Exernal AgentClient

AgentOrder Acquisition

AgentTransporter

Real Time AgentLogistics

AgentDispatcher

Real Time AgentScheduler

AgentResource

External AgentProvider


81

2.2.2. Le Diagramme de Classe AUML Temporisé du ‘’SCM’’

Le diagramme de classes pour le niveau conceptuel du ‘’SCM’’ se trouve à la figure 5.4. Nous voyons que ce diagramme de classes ne fait pas intervenir les classes reliées aux agents mais uniquement ceux-ci. Nous avons ajouté un package afin de regrouper tous les agents de l’entreprise.

Le second niveau que nous considérons est le niveau implémentation qui donne une vue détaillée des agents, et de leurs différentes relations (figure 5.5). Par exemple, dans la classe Real Time Agent ‘Logistics‘ on a défini les six compartiments suivant : Role (Logistics), Attributes (Acqlist, MBox), Operations (Request-Plan), Protocols (Create-Order, Modify-Order, Delete-Order), statecharts (Logistics), Temporal Constraint (Time of Negotiation).

Figure 5.4. Diagramme de Classe AUML du SCM. (Le Niveau conceptuel)

Figure 5.5. Diagramme de Classe AUML temporisé du SCM. (Le Niveau implémentation)


82

2.2.3. Les Diagrammes de Protocole AUML étendu du ’’SCM ‘’

Après la construction des diagrammes de cas d’utilisation et de classe, l’étape suivante est consacrée pour la représentation des différents scenarios qui implémentent les trois cas d’utilisations temporisés de la figure 5.3, à l’aide de diagrammes de protocole AUML. Par exemple, dans le diagramme de protocole du cas d’utilisation Place-Order (figure 5.6) on a utilisé les différents modes d’interaction (AND, exclusive OR) ainsi que les notions de référence et d’alternance (Ref, Alt).

Le Diagramme de Protocole du Cas D’utilisation ‘Place-Order’

Figure 5.6. Diagramme de protocole du cas d’utilisation ‘’Place-Order’’.

Le Diagramme de Protocole du Cas D’utilisation ‘Modify-Order’

Figure 5.7. Diagramme de protocole du cas d’utilisation ‘’Modify-Order’’.


83

Le Diagramme de Protocole du Cas D’utilisation ‘Delete Order’

Figure 5.8. Diagramme de protocole du cas d’utilisation ‘’Delete-Order’’.

2.2.4. Les Diagrammes d’Etat Transition AUML du ’’SCM ‘’

Les huit diagrammes d’états présentés ci-dessous (figure 5.9, 5.10, 5.11, 5.12, 5.13, 5.14, 5.15, 5.16), représentent respéctivement le comportement interne (individuel) des différents agents du ‘’SCM’’ : Client, Order-Acquisition, Logistics, Scheduler, Transporter, Dispatcher, Resource, et Provider.

Figure 5.9. State-Chart de l’agent Externe ‘’Client’’.

Figure 5.10. State-Chart de l’agent ‘’ Order Acquisition’’.

StartO WaitO

receiveAccept(order)/

IsPossible(order)SuccessO

Receive(order)/

SendAccept(order)

ReceiveRefuse(order)/SendPropose(order,bestdelay,bestprice)

StartC WaitCPurshase(order,delay, price)

SuccessCIsInitialized/

SendAck

ReceivePropose(order,bestdelay,bestprice)/Modify (order,delay,price)

ReceiveAccept(order)/


84

Figure 5.11. State-Chart de l’agent Temps Réel ‘’Logistics’’.

Figure 5.12. State-Chart de l’agent Temps Réel ‘’Scheduler’’.

Figure 5.13. State-Chart de l’agent ‘’Transporter’’.

StartT

DecisionProcess

OffEvalT

SuccessTFailureT

Refused/SendRefuse

Accepted/SendAccept

StartS WaitSExpiredTimeOutOfSched/

RequestAbilityOffEvalS

EvaluateProposals

SuccessSFailureS

NoExpiredTimeOutOfSched/AddProposal

ReceiveFail/SendRefuse(order)

ReceiveAccept/SendAccept(order)

ReceiveRequestPlan/

StartL WaitLExpiredTimeOutOfNego/

RequestPlanOffEvalL

ReceiveTreat(order)/

EvaluateProposals

SuccessL

NoExpiredTimeOutOfNego/AddProposal

ReceiveAccept/ SendAccept(order)

ReceiveFail/SendRefuse(order)

ReceiveRequestAbility/


85

Figure 5.14. State-Chart de l’agent ‘’Dispatcher’’.

Figure 5.15. State-Chart de l’agent ‘’Resource’’.

Figure 5.16. State-Chart de l’agent Externe ‘’Provider’’.

StartR

AskProvider

WaitR

SuccessRFailureR

ReceiveRefused/SendRefuse

ReceiveAccepted/SendAccept

StartPDecisionProcess

OffEvalPReceiveRequestAbility/

SuccessPFailureP

Refused/SendRefuse

Accepted/SendAccept

StartDDecisionProcess

OffEvalDReceiveRequestAbility/

SuccessDFailureD

Refused/SendRefuse

Accepted/SendAccept

ReceiveRequestAbility/


86

2.3. Génération de Spécification RT-Maude

La description formelle RT-Maude générée par l’application du processus de translation à cet exemple, implique les modules STATE, ACTION, CONDITION, STATE-OPERATIONS, MESSAGE-MANAGEMENT, IDENTIFICATION, MESSAGE, MAILBOX, ACQAINTANCE-LIST, EXTERNAL-AGENT-CLASS, AGENT-CLASS, et REAL-TIME-AGENT-CLASS qui restent inchangés avec la définition des autres modules.

Les modules CLIENT-BEHAVIOR (figure 5.17), ORDER-ACQUISITION-BEHAVIOR (figure 5.18), LOGISTICS-BEHAVIOR (figure 5.19), SCHEDULER-BEHAVIOR (figure 5.20), TRANSPORTER-BEHAVIOR (figure 5.21), DISPATCHER-BEHAVIOR (figure 5.22), RESOURCE-BEHAVIOR (figure 5.23), et PROVIDER-BEHAVIOR (figure 5.24) décrivent le méta-comportement des différents agents (internes et externes) qu’on a défini plus haut.

(fmod CLIENT-BEHAVIOR is protecting STATE-OPERATIONS .*************** User Part *************** States ops StartC WaitC SuccessC : -> NameState . ops AgentState (StartC) AgentState (WaitC) AgentState (SuccessC) : -> State . *************** Conditions and Actions op StopOrder : -> Condition . op Have-Pb : -> Condition . op IsInitialized : -> Condition . op ReceiveAccept : -> Condition . op ReceivePropose : -> Condition . op Purchase : -> Action . op NoAction : -> Action . op SendAck : -> Action . *************** Target State eq TargetState(AgentState (StartC), IsInitialized) = AgentState(WaitC) . …***************Action To Accomplish eq ActionToAccomplish (AgentState (StartC), IsInitialized) = Purchase . …***************Action Type eq IsSendingAction(Purchase ) = true . … endfm)

Figure 5.17. Le module fonctionnel CLIENT-BEHAVIOR qui correspond à l’agent externe ‘’Client’’.

(fmod ORDER-ACQUISITION-BEHAVIOR is protecting STATE-OPERATIONS .*************** User Part *************** States ops StartO WaitO SuccessO : -> NameState . ops AgentState (StartO) AgentState (WaitO) AgentState (SuccessO) : -> State . *************** Conditions and Actions op ReceiveOrder : -> Condition . op ReceiveAccept : -> Condition . op ReceiveRefuse : -> Condition . op IsPossible : -> Action . op SendAcceptO : -> Action . op SendPropose : -> Action .*************** Target State eq TargetState(AgentState (StartO), ReceiveOrder ) = AgentState(WaitO) . …*************** Action To Accomplish eq ActionToAccomplish (AgentState (StartO), ReceiveOrder ) = IsPossible .


87

…*************** Action Type eq IsReceivingAction (IsPossible ) = true . … endfm)

Figure 5.18. Le module fonctionnel ORDER-ACQUISITION-BEHAVIOR qui correspond à l’agent ‘’ORDER-ACQUISITION’’.

(fmod LOGISTICS-BEHAVIOR is protecting STATE-OPERATIONS .*************** User Part *************** States ops StartL WaitL OfferEvaluationL SuccessL : -> NameState . ops AgentState(StartL) AgentState(WaitL) AgentState(OfferEvaluationL) AgentState(SuccessL) : -> State . *************** Conditions and Actions op ReceiveTreatOrder : -> Condition . ops NoExpiredTimeOutOfNeg ExpiredTimeOutOfNeg : -> Condition . op ReceiveAccept : -> Condition . op ReceiveFail : -> Condition . op RequestPlan : -> Action . op EvaluateProposals : -> Action . op SendAccept : -> Action . op SendRefuse : -> Action .*************** Target State eq TargetState(AgentState(StartL), ReceiveTreatOrder) = AgentState(WaitL) . …*************** Action To Accomplish eq ActionToAccomplish(AgentState(StartL), ReceiveTreatOrder) = RequestPlan . … *************** Action Type eq IsReceivingAction(RequestPlan) = true . … endfm)

Figure 5.19. Le module fonctionnel LOGISTICS-BEHAVIOR qui correspond à l’agent temps réel ‘’LOGISTICS’’.

(fmod SCHEDULER-BEHAVIOR is protecting STATE-OPERATIONS .*************** User Part *************** States ops StartS WaitS OfferEvaluationS SuccessS FailureS : -> NameState . ops AgentState(StartS) AgentState(WaitS) AgentState(OfferEvaluationS) AgentState(FailureS) AgentState(SuccessS) : -> State . *************** Conditions and Actions op ReceiveRequestPlan : -> Condition . ops NoExpiredTimeOutOfSched ExpiredTimeOutOfSched : -> Condition . op ReceiveAccept : -> Condition . op ReceiveRefuse : -> Condition . op RequestAbility : -> Action . op EvaluateProposals : -> Action . op SendAccept : -> Action . op SendFail : -> Action . *************** Target State eq TargetState(AgentState(StartS), ReceiveRequestPlan) = AgentState(WaitS) . …*************** Action To Accomplish eq ActionToAccomplish(AgentState(StartS), ReceiveRequestPlan) = RequestAbility . … *************** Action Type


88

eq IsReceivingAction(RequestAbility) = true . … endfm)

Figure 5.20. Le module fonctionnel SCHEDULER-BEHAVIOR qui correspond à l’agent temps réel ‘’SCHEDULER’’.

(fmod TRANSPORTER-BEHAVIOR is protecting STATE-OPERATIONS .*************** User Part *************** States ops StartT OfferEvaluationT SuccessT FailureT : -> NameState . ops AgentState(StartT) AgentState(OfferEvaluationT) AgentState(FailureT) AgentState(SuccessT) : -> State . ************** Conditions and Actions op ReceiveRequestAbility : -> Condition . op Accepted : -> Condition . op Refused : -> Condition . op DecisionProcess : -> Action . op SendAccept : -> Action . op SendRefuse : -> Action .*************** Target Stateeq TargetState(AgentState(StartT), ReceiveRequestAbility ) = AgentState(OfferEvaluationT) .… *************** Action To Accomplish eq ActionToAccomplish(AgentState(StartT), ReceiveRequestAbility ) = DecisionProcess . …*************** Action Type eq IsInternalAction(DecisionProcess) = true . … endfm)Figure 5.21. Le module fonctionnel TRANSPORTER-BEHAVIOR qui correspond à l’agent ‘’TRANSPORTER’’.

(fmod DISPATCHER-BEHAVIOR is protecting STATE-OPERATIONS .*************** User Part *************** States ops StartD OfferEvaluationD SuccessD FailureD : -> NameState . ops AgentState(StartD) AgentState(OfferEvaluationD) AgentState(FailureD) AgentState(SuccessD) : -> State . *************** Conditions and Actions op ReceiveRequestAbility : -> Condition . op Accepted : -> Condition . op Refused : -> Condition . op DecisionProcess : -> Action . op SendAccept : -> Action . op SendRefuse : -> Action .*************** Target Stateeq TargetState(AgentState(StartD), ReceiveRequestAbility ) = AgentState(OfferEvaluationD) .…*************** Action To Accomplisheq ActionToAccomplish(AgentState(StartD), ReceiveRequestAbility ) = DecisionProcess . …*************** Action Typeeq IsInternalAction(DecisionProcess) = true . … endfm)

Figure 5.22. Le module fonctionnel DISPATCHER-BEHAVIOR qui correspond à l’agent ‘’DISPATCHER’’.

(fmod RESOURCE-BEHAVIOR is protecting STATE-OPERATIONS .*************** User Part


89

*************** States ops StartR WaitR SuccessR FailureR : -> NameState . ops AgentState(StartR) AgentState(WaitR) AgentState(FailureR) AgentState(SuccessR) : -> State . *************** Conditions and Actions op ReceiveRequestAbility : -> Condition . op ReceiveAccepted : -> Condition . op ReceiveRefused : -> Condition . op AskProvider : -> Action . op SendAccept : -> Action . op SendRefuse : -> Action .*************** Target State eq TargetState(AgentState(StartR), ReceiveRequestAbility ) = AgentState(WaitR) . ...*************** Action To Accomplish eq ActionToAccomplish(AgentState(StartR), ReceiveRequestAbility ) = AskProvider . …*************** Action Type eq IsReceivingAction(AskProvider) = true . … endfm)

Figure 5.23. Le module fonctionnel RESOURCE-BEHAVIOR qui correspond à l’agent ‘’RESOURCE’’.

(fmod PROVIDER-BEHAVIOR is protecting STATE-OPERATIONS .*************** User Part ************** States ops StartP OfferEvaluationP SuccessP FailureP : -> NameState . ops AgentState(StartP) AgentState(WaitP) AgentState(FailureP) AgentState(SuccessP) : -> State . *************** Conditions and Actionsop ReceiveRequestAbility : -> Condition . op Accepted : -> Condition .op Refused : -> Condition . op DecisionProcess : -> Action . op SendAcceptP : -> Action . op SendRefuseP : -> Action .*************** Target Stateeq TargetState(AgentState(StartP), ReceiveRequestAbility ) = AgentState(OfferEvaluationP) . …*************** Action To Accomplisheq ActionToAccomplish(AgentState(StartP), ReceiveRequestAbility ) = DecisionProcess . …***************Action Type eq IsInternalAction(DecisionProcess) = true . … endfm)Figure 5.24. Le module fonctionnel PROVIDER-BEHAVIOR qui correspond à l’agent externe ‘’PROVIDER’’.

Le module LINKED-BEHAVIORS (figure 5.25) : ce module nous permet de créer une sorte de liaison entre le comportement des différents agents que nous avons cité ci-dessus (des points de synchronisation). Une telle liaison consiste à garantir qu’au moment de la réception d’un message, un agent ne peut consommer de tel message seulement s’il est dans l’état correspondant à l’état de l’agent expéditeur de ce message.

(fmod LINKED-BEHAVIORS is protecting CLIENT-BEHAVIOR . protecting ORDER-ACQUISITION-BEHAVIOR . … op CorrespondingState : State -> State . ---[1]


90

op CorrespondingCondition : Action -> Condition . ---[2]*************** User Part *************** Client eq CorrespondingState(AgentState(StartC)) = AgentState(StartO) . eq CorrespondingCondition(Purchase ) = ReceiveOrder . *************** Order-Acquisition eq CorrespondingState(AgentState(StartO)) = AgentState(StartL) . … eq CorrespondingCondition(IsPossible ) = ReceiveTreatOrder . …*************** Logistics …*************** Scheduler …*************** Resource … *************** Provider ... endfm)

Figure 5.25. Le module fonctionnel LINKED-BEHAVIORS.

Le module ROLE (figure 5.26) nous permet de définir les rôles joués par les agents internes du système (lignes [1]). Nous définissons six rôles à savoir, Order-Acquisition, Logistics, Scheduler, Transporter, Dispatcher, et Resource.

(fmod ROLE is sort AgentRole .*************** User Part ops Order-Acquisition Logistics Scheduler Transporter Dispatcher Resource : -> AgentRole . ---[1] endfm)

Figure 5.26. Le module fonctionnel ROLE.

Le Module EXTERNAL-AGENTS (figure 5.27): Dans ce module sont définis les agents externes au système (lignes [1, 2]) comme des sous classes de la classe ExtAgent. Dans le ‘SCM’, on a l’agent Client avec les trois attributs Order, Deadline, et Cost qui désignent respéctivement le produit à commander, la date limite de livraison, et le prix proposé. Quand à l’agent Provider, il a les deux attributs PriceConstraint et Cost qui diterminent la contrainte imposé sur le prix et le prix proposé.

(omod EXTERNAL-AGENTS is extending EXTERNAL-AGENT-CLASS .*************** User Part including STRING . including NAT . subclass Client < ExtAgent . subclass Provider < ExtAgent . class Client | Order : String, Deadline : Nat, Cost : Nat . ---[1] class Provider | PriceConstraint : Nat, Cost : Nat . ---[2] endom)

Figure 5.27. Le module orienté objet EXTERNAL-AGENTS.

Le Module AGENTS (figure 5.28): nous permet de définir les agents faisant partie du système. Dans notre exemple, quatre agents sont défini, à savoir, l’agent Order-Acquisition, l’agentResource, l’agent Transporter, et l’agent Dispatcher. Les deux derniers agents possèdent les attributs DelayConstraint et Deadline (lignes [1, 2] qui définissent dans cet ordre la contrainte


91

imposée sur le délai défini et le délai proposé. Tout en faisant remarquer que ces quatre agents sont des sous classes de la classe Agent.

(omod AGENTS is extending AGENT-CLASS . *************** User Part including STRING . including NAT . subclass Transporter < Agent . subclass Dispatcher < Agent . class Transporter | DelayConstraint : Nat, Deadline : Nat . ---[1] class Dispatcher | DelayConstraint : Nat, Deadline : Nat . ---[2] endom)

Figure 5.28. Le module orienté objet AGENTS.

Dans cette étude de cas, on a défini deux agents temps réel, l’agent Logistics et l’agent Scheduler qui sont des sous classes de la classe RealTimeAgent.

Après avoir présenté les modules essentiels au développement des différents cas d’utilisation, nous entamons maintenant la description formelle de ces derniers. Pour chaque cas d’utilisation est associé un module orienté objet temporisé implémentant les différents scénarios possibles qui sont décrits à l’aide de diagramme de protocole AUML correspondant. Chaque envoi de messages entre deux entités au sein de diagramme de protocole est décrit à l’aide d’une règle de réécriture et le temps quand à lui il est décrit via des règles de réécriture temporié (tick rules). En effet, et comme il a été mentionné plus haut (figure 5.3), nous avons les trois cas d’utilisation temporisés (Place- Order, Modify-Order, et Delete-Order), que nous essayons de translater formellement.

Le Module PLACE-ORDER (figure 5.29): ce module importe les modules NAT-TIME-DOMAIN (afin de définir le domaine de temps pour être celui des entiers naturel) ainsi que les modules EXTERNAL-AGENTS, AGENTS, REAL-TIME-AGENTS, et LINKED-BEHAVIORS.

Pour exprimer l'apparence d'un événement, nous avons ajouté dans ce module les deux messages Event et GetEvent (ligne [1]). Et pour exprimer l’exécution d’une action, on a définit l’opération Execute (ligne [2]).

Comme évoqué plus haut (sous section 4.2.1), les agents Transporter, Dispatcher, et Resource ainsi que l’agent externe Provider après évaluation de la requète venant de l’agent temps réel Scheduler, ils peuvent l’accepter à travers l’acte IsAcceptedDelay ouIsAcceptedPrice (ligne [3]) ou bien la refuser. Dans ce cas, ils formulent l’acte IsRefusedDelay ou IsRefusedPrice (ligne [4]).

Sans oublier les fonctions ExpireTimerOfNeg, ExpireTimerOfSched, TimerOfNeg, et TimerOfSched, (lignes [5, 6, 7, 8]), qui sont utilisées pour indiquer l’expiration de la date limite de négociation et de planification.

Dans notre cas d’étude, le comportement dynamique des six agents internes et des deux agents externes c.à.d. le fait de changer d’état, est modélisé par un ensemble de règles de réécriture ‘’instantanées’’ et deux règles temporisées ([tick1] et [tick2]). Ces deux régles temporisées (figures 5.30 et 5.31) permettent de modéliser l’écoulement du temps (de négociation et de planification) explicité dans le système. Néanmoins le changement d’état de ces agents ne peut s’effectuer qu’après q’une transition interne ou bien externe ai lieu.

Les deux règles de réécritures [ExpireTimeOfNeg1] et [ExpireTimeOfNeg2], permettent d’informer l’agent temps réel Logistics de l’expiration de la date limite qu’il a fixé en


92

déclenchant un évènement interne. Cet évenement lui permet de changer d’état via la règle [Internal-Log2].

Aussi les règles de réécritures [ExpireTimeOfSched1], [ExpireTimeOfSched2], et [Internal-Sch2], jouent le même rôle que les trois précedentes mais vis-à-vis de l’agent temps réel Scheduler.

Les autres règles de réécriture (instantanées) ont été classées selon le séquencement des interactions explicitées dans le diagramme de protocole AUML (figure 5.6) correspondant au cas d’utilisation Place-Order (figure 5.3):

Lorsqu’un des agents (Client, Order-Acquisition, Logistics, Scheduler, Transporter, Dispatcher, Resource, et Provider) veut émettre un message vers ses accointants, il va exécuter la règle qui lui correspond parmi la liste des règles suivantes [Send-Cli] ; [Send-Ord2] ; [Send-Log2] ; [Send-Sch2] [Send-Sch3] [Send-Sch4] ; [Send-Res2] ; [Send-Pro4] [Send-Pro5] ; [Send-Tra4] [Send-Tra5] ; [Send-Dis4] [Send-Dis5] ; [Send-Sch5] [Send-Sch6]. Chacune d’entre elle exprime une boucle conditionnelle dans laquelle l’agent envoi le message à chaque élément de sa liste d’accointance par l’acte SendMessage (ligne [1], figure 4.25) en déclenchant un événement et cela tout en utilisant les deux opérations : HeadA (ligne [1], figure 4.23) qui détermine la tête de la liste et TailA (ligne [2], figure 4.23) qui détermine le reste de la liste. A la fin de cette boucle c.à.d. lorsque la liste d’accointances est totalement parcourue (IsEmptyAcquaintanceList (ACL) = = true), les agents concernés (Order-Acquisition, Logistics, Scheduler, et Resource) exécutent la règle qui leur correspond parmi la liste siuvante [Internal-Ord3] ; [Internal-Log3] ; [Internal-Sch5] ; [Internal-Res3] ; afin de passer à l’état suivant.

Quand un des agents Order-Acquisition, Logistics, Scheduler, et Resource reçoit un message via l’acte ReceiveMessage, il le met dans son MailBox via l’opération InsertInMBox (ligne [3], figure 4.22) comme illustré dans les règles [Receive-Ord1] ; [Receive-Log1] ; [Receive-Sch1] ; [Receive-Res1], et passe à l’état suivant après la mise à jour de sa liste d’accointances à travers l’opération UpDateAcqList (ligne [9], figure 4.65) qui est présente dans toutes les règles [Internal-Ord3] ; [Internal-Log3] ; [Internal-Sch5] ; [Internal-Res3].

Après l’expiration de la date limite fixée par l’agent temps réel Logistics celui-ci va exécuter la règle [Internal-Log2] qui le fait passer à l’état OfferEvaluation. Dans cet état et selon le contenu de son MailBox, il passe soit à l’état SuccessL si sa boite au lettre contient une acceptation de la commande via la règle [Internal-Log3], dans le cas contraire il passe à l’état failureL en éxécutant cette même règle. Quand à l’agent temps réel Scheduler lui aussi aura ce même comportement mais en utilisant les règles [Internal-Sch2], [Send-Sch5], [Send-Sch6].

L’agent externe Provider ainsi que les deux agents interne Transporter et Dispatcher peuvent envoyer des acceptations aux Scheduler en exécutant les règles [Send-Pro4] ; [Send-Tra4] ; [Send-Dis4], et passent à l’état Success, comme ils peuvent l’envoyer des refus en utilisant les règles [Send-Pro5] ; [Send-Tra5] ; [Send-Dis5], et passent à l’état Failure. Cela dépend bien évidement de l’évaluation qu’ils vont faire en comparant les contraintes imposées sur ‘le prix de production’ et sur ‘le délait de livraison’ de la commande (DelayConstraint et PriceConstraint) avec ceux proposés par le client (Deadline et Cost).


93

(tomod PLACE-ORDER is including NAT-TIME-DOMAIN . including EXTERNAL-AGENTS . including AGENTS . including REAL-TIME-AGENTS . including LINKED-BEHAVIORS .*************** User Part subsort String < Identifier . ops Event GetEvent : Identifier State Condition -> Msg . ---[1] op Execute : Action -> Msg . ---[2] ops IsAcceptedDelay IsAcceptedPrice : -> Msg . ---[3] ops IsRefusedDelay IsRefusedPrice : -> Msg . ---[4] op SchedulePlan : -> Msg . op ExpireTimerOfNeg : Bool -> Msg . ---[5] op ExpireTimerOfSched : Bool -> Msg . ---[6] op TimerOfNeg : Time -> Msg . ---[7] op TimerOfSched : Time -> Msg . ---[8] op Compter : Nat -> Msg . op UpDateAcqList : MailBox -> AcquaintanceList . ---[9] op ModifyOrder : -> Msg . vars A A1 A2 A3 A4 A5 A6 A7 : Identifier . vars S S1 S2 S3 S4 S5 : State . vars MB : MailBox . vars ACL : AcquaintanceList . vars Cond Cond1 : Condition . var Act : Action . vars T T' : Time . vars TimeOutOfNeg TimeOutOfSched : Time . var Cont : Content . var M : Message . vars Nbr Pr BPr D BD : Nat . var P : String . eq UpDateAcqList(MB) = if MB == EmptyMailBox then EmptyAcquaintanceList else GetIdent(FrontMBox(MB)) : UpDateAcqList(RemoveMBox(MB)) fi . --------------------------------|Expire Timer Of Negociation |-------------------------------------------------crl [ExpireTimeOfNeg1] : TimerOfNeg(TimeOutOfNeg) => ExpireTimerOfNeg(true) if (TimeOutOfNeg == 0). rl [ExpireTimeOfNeg2] : ExpireTimerOfNeg(true)

< A : RealTimeAgent | PlayRole : Logistics, CurrentState : S, Clock : T > => Event (A, S, ExpiredTimeOutOfNeg) SchedulePlan < A : RealTimeAgent | PlayRole : Logistics, CurrentState : S, Clock : T > . ---------------------------------|Expire Timer Of Schedule |----------------------------------------------------crl [ExpireTimeOfSched1] : TimerOfSched(TimeOutOfSched) SchedulePlan => ExpireTimerOfSched(true) if (TimeOutOfSched == 0). rl [ExpireTimeOfSched2] : ExpireTimerOfSched(true) < A : RealTimeAgent | CurrentState : S, PlayRole : Scheduler > => Event (A, S, ExpiredTimeOutOfSched) < A : RealTimeAgent | PlayRole : Scheduler, CurrentState : S > . ------------------------------|Internal action (Logistics)|---------------------------------------------------------crl [Internal-Log2] : GetEvent(A, S, Cond) Execute(Act) < A : RealTimeAgent | PlayRole : Logistics, CurrentState : S > => < A : RealTimeAgent | PlayRole : Logistics, CurrentState : TargetState(S, Cond) > if (Cond == ExpiredTimeOutOfNeg) and(IsInternalAction(ActionToAccomplish(S, Cond)) == true) .-----------------------------|Internal action (Scheduler)|--------------------------------------------------------crl [Internal-Sch2] : GetEvent(A, S, Cond) Execute(Act) < A : RealTimeAgent | PlayRole : Scheduler, CurrentState : S > => < A : RealTimeAgent | PlayRole : Scheduler, CurrentState : TargetState(S, Cond) > if (Cond == ExpiredTimeOutOfSched) and (IsInternalAction (ActionToAccomplish(S, Cond)) == true) . ---------------------------|Sending action (Client)|---------------------------------------------------------------


94

crl [Send-Cli] : Event(A, S, Cond) < A : Client | CurrentState : S, AcqList : ACL, Order : P, Deadline : D, Cost : Pr > => < A : Client | CurrentState : TargetState(S,Cond), AcqList : TailA(ACL), Order : P, Deadline : D, Cost : Pr > SendMessage(A : ActionToAccomplish(S, Cond) : HeadA(ACL)) Event(HeadA(ACL), CorrespondingState(S), CorrespondingCondition(ActionToAccomplish(S, Cond))) if (IsSendingAction(ActionToAccomplish(S, Cond)) == true) . ----------------------------|Receiving case (order-Acquisition)|----------------------------------------------crl [Receive-Ord1] : Event(A, S, Cond) SendMessage(A1 : Cont : A) < A : Agent | PlayRole : Order-Acquisition, CurrentState : S, AcqList : ACL, MBox : MB > => GetEvent(A, S, Cond) ReceiveMessage(A1 : Cont : A)

< A : Agent | PlayRole : Order-Acquisition, CurrentState : S, AcqList : ACL, MBox : InsertInMBox( ( A1 : Cont : A ), MB) > if (IsReceivingAction(ActionToAccomplish(S, Cond)) == true) .crl [Send-Ord2] : GetEvent(A, S, Cond) ReceiveMessage(A1 : Cont : A) < A : Agent | PlayRole : Order-Acquisition, CurrentState : S, MBox : MB, AcqList : ACL > => GetEvent(A, S, Cond) ReceiveMessage(A1 : Cont : A)< A : Agent | PlayRole : Order-Acquisition, CurrentState : S, AcqList : TailA(ACL), MBox : MB > SendMessage(A : ActionToAccomplish(S, Cond) : HeadA(ACL)) Event(HeadA(ACL), CorrespondingState(S), CorrespondingCondition(ActionToAccomplish(S, Cond))) if (IsReceivingAction(ActionToAccomplish(S, Cond)) == true) and (HeadA(ACL )=/= ErrorAcquaintance) .

crl [Internal-Ord3] : GetEvent(A, S, Cond) ReceiveMessage(A1 : Cont : A) < A : Agent | PlayRole : Order-Acquisition, CurrentState : S, MBox : MB, AcqList : ACL > => < A : Agent | PlayRole : Order-Acquisition, CurrentState : TargetState(S, Cond), MBox : MB, AcqList : UpDateAcqList(MB) > if (IsReceivingAction(ActionToAccomplish(S, Cond)) == true) and (IsEmptyAcquaintanceList (ACL) == true) . ----------------------------|Receiving case (Resource)|--------------------------------------------------------------------------crl [Receive-Res1] : Event(A, S, Cond) SendMessage(A1 : Cont : A) < A : Agent | PlayRole : Resource, CurrentState : S, AcqList : ACL, MBox : MB > => GetEvent(A, S, Cond) ReceiveMessage(A1 : Cont : A) < A : Agent | PlayRole : Resource, CurrentState : S, AcqList : ACL, MBox : InsertInMBox( ( A1 : Cont : A ), MB) > if (IsReceivingAction(ActionToAccomplish(S, Cond)) == true) .

crl [Send-Res2] : GetEvent(A, S, Cond) ReceiveMessage(A1 : Cont : A) < A : Agent | PlayRole : Resource, CurrentState : S, MBox : MB, AcqList : ACL > => GetEvent(A, S, Cond) ReceiveMessage(A1 : Cont : A)< A : Agent | PlayRole : Resource, CurrentState : S, AcqList : TailA(ACL), MBox : MB > SendMessage(A : ActionToAccomplish(S, Cond) : HeadA(ACL)) Event(HeadA(ACL), CorrespondingState(S), CorrespondingCondition(ActionToAccomplish(S, Cond))) if (IsReceivingAction(ActionToAccomplish(S, Cond)) == true) and (HeadA(ACL )=/= ErrorAcquaintance) .

crl [Internal-Res3] : GetEvent(A, S, Cond) ReceiveMessage(A1 : Cont : A)< A : Agent | PlayRole : Resource, CurrentState : S, MBox : MB, AcqList : ACL > => < A : Agent | PlayRole : Resource, CurrentState : TargetState(S, Cond), MBox : MB, AcqList : UpDateAcqList(MB) > if (IsReceivingAction(ActionToAccomplish(S, Cond)) == true) and (IsEmptyAcquaintanceList (ACL) == true) . ----------------------------|Receiving case (Logistics)|---------------------------------------------------------------------------crl [Receive-Log1] : Event(A, S, Cond) SendMessage(A1 : Cont : A) < A : RealTimeAgent | PlayRole : Logistics, CurrentState : S, AcqList : ACL, MBox : MB > => GetEvent(A, S, Cond) ReceiveMessage(A1 : Cont : A) < A : RealTimeAgent | PlayRole : Logistics, CurrentState : S, AcqList : ACL, MBox :


95

InsertInMBox( ( A1 : Cont : A ), MB) > if (IsReceivingAction(ActionToAccomplish(S, Cond)) == true) .

crl [Send-Log2] : GetEvent(A, S, Cond) ReceiveMessage(A1 : Cont : A) < A : RealTimeAgent | PlayRole : Logistics, CurrentState : S, MBox : MB, AcqList : ACL > => GetEvent(A, S, Cond) ReceiveMessage(A1 : Cont : A) < A : RealTimeAgent | PlayRole : Logistics, CurrentState : S, AcqList : TailA(ACL), MBox : MB > SendMessage(A : ActionToAccomplish(S, Cond) : HeadA(ACL)) Event(HeadA(ACL), CorrespondingState(S), CorrespondingCondition(ActionToAccomplish(S, Cond))) if (IsReceivingAction(ActionToAccomplish(S, Cond)) == true) and (HeadA(ACL )=/= ErrorAcquaintance) .

crl [Internal-Log3] : GetEvent(A, S, Cond) ReceiveMessage(A1 : Cont : A) < A : RealTimeAgent | PlayRole : Logistics, CurrentState : S, MBox : MB, AcqList : ACL > => < A : RealTimeAgent | PlayRole : Logistics, CurrentState : TargetState(S, Cond), MBox : MB, AcqList : UpDateAcqList(MB) > if (IsReceivingAction(ActionToAccomplish(S, Cond)) == true) and(IsEmptyAcquaintanceList (ACL) == true) .

----------------------------|Receiving case (Scheduler)|--------------------------------------------------------------------------crl [Receive-Sch1] : Event(A, S, Cond) SendMessage(A1 : Cont : A) < A : RealTimeAgent | PlayRole : Scheduler, CurrentState : S, AcqList : ACL, MBox : MB > => GetEvent(A, S, Cond) ReceiveMessage(A1 : Cont : A) < A : RealTimeAgent | PlayRole : Scheduler, CurrentState : S, AcqList : ACL, MBox : InsertInMBox( ( A1 : Cont : A ), MB) > if (IsReceivingAction(ActionToAccomplish(S, Cond)) == true) and (Cond == ReceiveRequestPlan) .

crl [Send-Sch2] : GetEvent(A, S, Cond) ReceiveMessage(A1 : Cont : A)< A : RealTimeAgent | PlayRole : Scheduler, CurrentState : S, MBox : MB, AcqList : ACL > => GetEvent(A, S, Cond) ReceiveMessage(A1 : Cont : A) < A : RealTimeAgent | PlayRole : Scheduler, CurrentState : S, AcqList : TailA(ACL), MBox : MB > SendMessage(A : ActionToAccomplish(S, Cond) : HeadA(ACL)) Event(HeadA(ACL), AgentState (StartT), CorrespondingCondition(ActionToAccomplish(S, Cond))) if (IsReceivingAction(ActionToAccomplish(S, Cond)) == true) and (HeadA(ACL )== "transporter").

crl [Send-Sch3] : GetEvent(A, S, Cond) ReceiveMessage(A1 : Cont : A) < A : RealTimeAgent | PlayRole : Scheduler, CurrentState : S, MBox : MB, AcqList : ACL > => GetEvent(A, S, Cond) ReceiveMessage(A1 : Cont : A) < A : RealTimeAgent | PlayRole : Scheduler, CurrentState : S, AcqList : TailA(ACL), MBox : MB > SendMessage(A : ActionToAccomplish(S, Cond) : HeadA(ACL)) Event(HeadA(ACL), AgentState (StartD), CorrespondingCondition(ActionToAccomplish(S, Cond))) if (IsReceivingAction(ActionToAccomplish(S, Cond)) == true) and (HeadA(ACL )== "dispatcher") .

crl [Send-Sch4] : GetEvent(A, S, Cond) ReceiveMessage(A1 : Cont : A) < A : RealTimeAgent | PlayRole : Scheduler, CurrentState : S, MBox : MB, AcqList : ACL > => GetEvent(A, S, Cond) ReceiveMessage(A1 : Cont : A) < A : RealTimeAgent | PlayRole : Scheduler, CurrentState : S, AcqList : TailA(ACL), MBox : MB > SendMessage(A : ActionToAccomplish(S, Cond) : HeadA(ACL)) Event(HeadA(ACL), AgentState (StartR), CorrespondingCondition(ActionToAccomplish(S, Cond))) if (IsReceivingAction(ActionToAccomplish(S, Cond)) == true) and (HeadA(ACL )== "resource") .

crl [Internal-Sch5] : GetEvent(A, S, Cond) ReceiveMessage(A1 : Cont : A) < A : RealTimeAgent | PlayRole : Scheduler, CurrentState : S, MBox : MB, AcqList : ACL > => < A : RealTimeAgent | PlayRole : Scheduler, CurrentState : TargetState(S, Cond), MBox : MB, AcqList : UpDateAcqList(MB) > if (IsReceivingAction(ActionToAccomplish(S, Cond)) == true) and (IsEmptyAcquaintanceList(ACL) == true) . -------------------------------------|Internal action (Provider)|--------------------------------------------------


96

crl [Send-Pro4] : < A : Provider | CurrentState : S2, AcqList : ACL, PriceConstraint : BPr, Cost : Pr > GetEvent(A, S, Cond) ReceiveMessage(A1 : Cont : A) IsAcceptedPrice => < A : Provider | CurrentState : AgentState(SuccessP), AcqList : TailA(ACL), PriceConstraint : BPr, Cost : Pr > SendMessage(A : ActionToAccomplish(S, Cond) : HeadA(ACL)) Event(HeadA(ACL), CorrespondingState(S2), CorrespondingCondition(SendAcceptP)) if (IsInternalAction(ActionToAccomplish(S, Cond)) == true) .

crl [Send-Pro5] : < A : Provider | CurrentState : S2, AcqList : ACL, PriceConstraint : BPr, Cost : Pr > GetEvent(A, S, Cond) ReceiveMessage(A1 : Cont : A) IsRefusedPrice => < A : Provider | CurrentState : AgentState(FailureP), AcqList : TailA(ACL), PriceConstraint : BPr, Cost : Pr > SendMessage(A : ActionToAccomplish(S, Cond) : HeadA(ACL)) Event(HeadA(ACL), CorrespondingState(S2), CorrespondingCondition(SendRefuseP)) if (IsInternalAction(ActionToAccomplish(S, Cond)) == true) .---------------------------------|Internal action (Transporter)|-------------------------------------------------crl [Send-Tra4] : < A : Transporter | CurrentState : S1, AcqList : ACL, DelayConstraint : BD, Deadline : D > GetEvent(A, S, Cond) ReceiveMessage(A1 : Cont : A) IsAcceptedDelay => < A : Transporter | CurrentState : AgentState(SuccessT), AcqList : TailA(ACL), DelayConstraint : BD, Deadline : D > SendMessage(A : ActionToAccomplish(S, Cond) : HeadA(ACL)) Event(HeadA(ACL), CorrespondingState(S1), CorrespondingCondition(SendAccept)) if (IsInternalAction(ActionToAccomplish(S, Cond)) == true) .

crl [Send-Tra5] : < A : Transporter | CurrentState : S1, AcqList : ACL, DelayConstraint : BD, Deadline : D > GetEvent(A, S, Cond) ReceiveMessage(A1 : Cont : A) IsRefusedDelay => < A : Transporter | CurrentState : AgentState(FailureT), AcqList : TailA(ACL), DelayConstraint : BD, Deadline : D > SendMessage(A : ActionToAccomplish(S, Cond) : HeadA(ACL)) Event(HeadA(ACL), CorrespondingState(S1), CorrespondingCondition(SendRefuse)) if (IsInternalAction(ActionToAccomplish(S, Cond)) == true) .---------------------------------|Internal action (Dispatcher)|---------------------------------------------------crl [Send-Dis4] : < A : Dispatcher | CurrentState : S1, AcqList : ACL, DelayConstraint : BD, Deadline : D > GetEvent(A, S, Cond) ReceiveMessage(A1 : Cont : A) IsAcceptedDelay => < A : Dispatcher | CurrentState : AgentState(SuccessD), AcqList : TailA(ACL), DelayConstraint : BD, Deadline : D > SendMessage(A : ActionToAccomplish(S, Cond) : HeadA(ACL)) Event(HeadA(ACL), CorrespondingState(S1), CorrespondingCondition(SendAccept)) if (IsInternalAction(ActionToAccomplish(S, Cond)) == true) .

crl [Send-Dis5] : < A : Dispatcher | CurrentState : S1, AcqList : ACL, DelayConstraint : BD, Deadline : D > GetEvent(A, S, Cond) ReceiveMessage(A1 : Cont : A) IsRefusedDelay => < A : Dispatcher | CurrentState : AgentState(FailureD), AcqList : TailA(ACL), DelayConstraint : BD, Deadline : D > SendMessage(A : ActionToAccomplish(S, Cond) : HeadA(ACL)) Event(HeadA(ACL), CorrespondingState(S1), CorrespondingCondition(SendRefuse)) if (IsInternalAction(ActionToAccomplish(S, Cond)) == true) .---------------------------------|Internal action (Scheduler)|---------------------------------------------------------------------crl [Send-Sch5] : Compter(Nbr) < A : RealTimeAgent | PlayRole : Scheduler, CurrentState : S, AcqList : ACL, MBox : MB > => < A : RealTimeAgent | PlayRole : Scheduler, CurrentState : AgentState(SuccessS), AcqList : TailA(ACL), MBox : MB > SendMessage(A : SendAccept : HeadA(ACL))


97

Event(HeadA(ACL), CorrespondingState(S), CorrespondingCondition(SendAccept)) if (Nbr == 3) .

crl [Send-Sch6] : Event(A, S, Cond) SendMessage(A1 : Cont : A) < A : RealTimeAgent | PlayRole : Scheduler, CurrentState : S, AcqList : ACL, MBox : MB > => < A : RealTimeAgent | PlayRole : Scheduler, CurrentState : TargetState(S,Cond), AcqList : TailA(ACL), MBox : MB > SendMessage(A : ActionToAccomplish(S, Cond) : HeadA(ACL)) Event(HeadA(ACL), CorrespondingState(S), CorrespondingCondition(ActionToAccomplish(S, Cond)))if (IsInternalAction(ActionToAccomplish(S, Cond)) == true) and (Cond == ReceiveRefuse) . endtom)

Figure 5.29. Le module orienté objet temporisé PLACE-ORDER.

----------------------------------|Tick Rule|-----------------------------------------------------------------crl [tick1] : {TimerOfNeg(TimeOutOfNeg) < A : RealTimeAgent | Clock : T, CurrentState : S > REST:Configuration} => {TimerOfNeg(TimeOutOfNeg monus 1) < A : RealTimeAgent | Clock : T plus 1, CurrentState : S > REST:Configuration} in time 1 if (TimeOutOfNeg > zero) and (S == AgentState (WaitL)) .

Figure 5.30. Tick rule de l’agent temps réel ‘’ Logistics’’.

----------------------------------|Tick Rule|-----------------------------------------------------------------crl [tick2] : {TimerOfSched(TimeOutOfSched) SchedulePlan < A : RealTimeAgent | CurrentState : S, Clock : T' > REST:Configuration } => {TimerOfSched(TimeOutOfSched monus 1) SchedulePlan < A : RealTimeAgent | CurrentState : S, Clock : T' plus 1 > REST:Configuration } in time 1 if (TimeOutOfSched > zero) and (S == AgentState (WaitS)) .

Figure 5.31. Tick rule de l’agent temps réel ‘’ Scheduler’’.

En ce qui concerne les deux autres cas d’utilisation (‘Modify Order’ et ‘Delete Order’), ils peuvent ètre spécifier formelement via les deux modules OO temporisés MODIFY-ORDER et DELETE-ORDER en définissant d’autres règles de réécritures.

Le Module MODIFY-ORDER (figure 5.32) : ce module implémente le cas d’utilisation Modify Order de telle sorte que lorsque l’agent externe client reçoit un message lui indiquant que sa commande qu’il a formulé au début est refusée du fait qu’elle est au dela des capacités desdifférents agents internes du système, il est dans l’obligation de changer les parmètres de cette commande concernant le côut et le délait à proposer, pour qu’ils soient plus appropriés cette fois, comme illustré à la ligne [1] de la règle [Modify-Order]. Ce module importe le module PLACE-ORDER puisque il y a une relation d’inclusion entre le cas d’utilisation Modify Orderet le cas d’utilisation Place Order.

(tomod MODIFY-ORDER is including PLACE-ORDER .*************** User Part vars A1 A2 A3 A4 A5 A6 A7 A8 : Identifier . vars S S1 S2 S3 S4 S5 S6 S7 : State . vars MB MB1 MB2 MB3 MB4 MB5 MB6 : MailBox . vars ACL ACL1 ACL2 ACL3 ACL4 ACL5 ACL6 ACL7 : AcquaintanceList . vars T T' : Time . vars TimeOutOfNeg TimeOutOfSched : Time . vars Nbr Pr BPr D BD : Nat . var P : String . rl [Modify-Order] : ModifyOrder< A1 : Client | AcqList : ACL, Cost : Pr, CurrentState : S, Deadline : D, Order : P >


98

< A2 : Agent | AcqList : ACL3, CurrentState : S3, MBox : MB2, PlayRole : Order-Acquisition > < A3 : RealTimeAgent | AcqList : ACL2, Clock : T, CurrentState : S2, MBox : MB1, PlayRole : Logistics > < A4 : RealTimeAgent | AcqList : ACL6, Clock : T', CurrentState : S6, MBox : MB4, PlayRole : Scheduler >< A5 : Transporter | AcqList : ACL7, CurrentState : S7, Deadline : D, DelayConstraint : BD, MBox : MB5, PlayRole : Transporter >< A6 : Dispatcher | AcqList : ACL1, CurrentState : S1, Deadline : D, DelayConstraint : BD, MBox : MB, PlayRole : Dispatcher > < A7 : Agent | AcqList : ACL5, CurrentState : S5, MBox : MB3, PlayRole : Resource >< A8 : Provider | AcqList : ACL4, Cost : Pr, CurrentState : S4, PriceConstraint : BPr > => Event(A1, AgentState(StartC), IsInitialized)< A1 : Client | CurrentState : AgentState(StartC), AcqList : "order-Acquisition", Order : P, Deadline : D plus 5, Cost : Pr plus 5 > ---[1]< A2 : Agent | PlayRole : Order-Acquisition, CurrentState : AgentState(StartO), MBox : EmptyMailBox, AcqList : "logistics" >< A3 : RealTimeAgent | PlayRole : Logistics, CurrentState : AgentState(StartL), MBox : EmptyMailBox, AcqList : "scheduler", Clock : T >< A4 : RealTimeAgent | PlayRole : Scheduler, CurrentState : AgentState(StartS), MBox : EmptyMailBox, AcqList : ("transporter" : ("dispatcher" : "resource")), Clock : T' > < A5 : Transporter | PlayRole : Transporter, CurrentState : AgentState(StartT), MBox : EmptyMailBox, AcqList : "scheduler", DelayConstraint : 10, Deadline : D plus 5 > < A6 : Dispatcher | PlayRole : Dispatcher, CurrentState : AgentState(StartD), MBox : EmptyMailBox, AcqList : "scheduler", DelayConstraint : 10, Deadline : D plus 5 > < A7 : Agent | PlayRole : Resource, CurrentState : AgentState(StartR), MBox : EmptyMailBox, AcqList : "provider" > < A8 : Provider | CurrentState : AgentState(StartP), AcqList : "resource", PriceConstraint : 15, Cost : Pr plus 5 > TimerOfNeg(60) TimerOfSched(40) . endtom)

Figure 5.32. Le module orienté objet temporisé MODIFY-ORDER.

Le Module DELETE-ORDER (figure 5.33) : ce module décrit formellement le cas d’utilisation Delete Order c.à.d. lorsque le client veut annuler la commande qu’il vient de passer à travers la règle [StopOrder] qui permet aux agents Client, Order-Acquisition, et Logistics de passer à leurs états initaux. Ce module étend le module PLACE-ORDER puisque il y a une relation d’extension entre le cas d’utilisation Delete Order et le cas d’utilisation Place Order.

(tomod DELETE-ORDER is extending PLACE-ORDER . ************ User Part vars S3 S4 S5 : State . vars A1 A2 A3 : Identifier . crl [StopOrder] : Event(A1, S3, StopOrder)< A1 : Client | CurrentState : S3 > < A2 : RealTimeAgent | CurrentState : S4 >< A3 : Agent | CurrentState : S5 > => < A1 : Client | CurrentState : AgentState(StartC), AcqList : "order-Acquisition", Order : "Machine", Deadline : 10, Cost : 10 >< A2 : RealTimeAgent | PlayRole : Logistics, CurrentState : AgentState(StartL), MBox : EmptyMailBox, AcqList : "scheduler", Clock : 0 > < A3 : Agent | PlayRole : Order-Acquisition, CurrentState : AgentState(StartO), MBox : EmptyMailBox, AcqList : "logistics" >if (S3 == AgentState(WaitC)) and (S4 == AgentState(WaitL)) and (S5 == AgentState(WaitO)) . endtom)

Figure 5.33. Le module orienté objet temporisé DELETE-ORDER.


99

Le Module RTMAS-FUCTIONAL-REQUIREMENTS (figure 5.34): les trois modules présentés ci-dessus décrivant les trois cas d’utilisation du Supply Chain Management sont importés dans le module orienté objet temporisé RTMAS-FUNCTIONAL-REQUIREMENTS et ce dans l’objectif de spécifier les besoins fonctionnels du système en entier.

(tomod RTMAS-FUNCTIONAL-REQUIREMENTS is including PLACE-ORDER . including MODIFY-ORDER . including DELETE-ORDER . endtom)

Figure 5.34. Le module orienté objet temporisé RTMAS-FUCTIONAL-REQUIREMENS.

En outre, il faut noter que Real Time Maude offre une grande flexibilité en terme de simulation de spécification, en particulier le choix de la configuration initiale. Ce choix joue un rôle primordial dans la validation de la description formelle du ‘’SCM’’ que nous venons de présenter ci-dessus.

2.4. Validation de la Description Générée

La particularité de la description formelle qu’on a générée pour l’exemple de la gestion de chaine logistique (SCM), sachant qu’elle a été développée à l’aide de messages et de règles de réécriture, est qu’elle est exécutable. En effet, comme il a été étudié au chapitre 3, un programme RT-Maude est à la fois un programme informatique et une théorie logique à partir de laquelle il est possible de faire plusieurs déductions.

Afin d’avoir une interface conviviale, on a utilisé l’environnement Eclipse qui nous a permet d’intégrer le langage RT-Maude. Ce dernier est un langage très versatil en termes de simulation, il permet de définir un état initial personnalisé ce qui rend aisé de valider la description générée, c.à.d. simuler le système global pour vérifier que toutes les règles de réécriture mises en commun accomplissent bel et bien le comportement qu’on désire avoir.

Dans cet exemple du ‘’SCM’’, nous avons considéré les trois cas suivants : (1) le cas où la commande passé par l’agent client satisfait les exigences des autres agents de l’entreprise en particulier l’agent Transporter, l’agent Dispatcher et l’agent externe Provider, (2) le cas où la commande du client sera au dela des capacités de ces mèmes agents, et (3) le cas où le client veut annuler la commande qu’il vient de passer. Pour implémenter ces trois cas, nous avons défini le module orienté objet temporisé SUPPLY-CHAIN-MANAGEMENT, dans lequel on a importé le module RTMAS-FUNCTIONAL-REQUIREMENTS.


100

Pour le premier cas, nous proposons la configuration suivante (Figure 5.35) :

Figure 5.35. Configuration initiale 1.

Dans cette configuration initiale, les agents order-Acquisition, logistics, scheduler, transporter, dispatcher, et resource sont dans leurs états initiaux (StartO, StartL, StartS, StartT, StartD, StartR) avec des boites aux lettres vides, et jouant les rôles : Order-Acquisition, Logistics, Scheduler, Transporter, Dispatcher, et Resource. Concernant leurs listes d’accointances, elles sont définies comme suit tout en respectant l’ordre ci-dessus : ‘’logistics’’, ‘’scheduler’’, (‘’transporter : (‘’dispatcher : ‘’resource’’), ‘’scheduler’’, ‘’scheduler’’, ‘’provider’’.

Les deux agents temps réel Logitics et Scheduler ont leurs horloges initialisées à zero (Clock = 0), alors que les deux attributs DelayConstraint et Deadline associés aux agents Transporter et Dispatcher prennent les valeurs 10 et 15 dans cet ordre.

L’agent externe Client est dans son état initial (StartC), ayant comme accointant l’agent ‘’order-acquisition’’, et ses trois attributs Order, Deadline, et Cost prennent les valeurs respectivent : ‘’Machine’’, 15, et 20.

Quant à l’agent externe provider, lui aussi démarre de l’état StartP, ayant comme accointant l’agent ‘’resource’’, et ses deux attributs PriceConstraint, et Cost prennent les valeurs respectivent : 10, 20.

Par ailleurs, cette configuration contient les deux messages : TimerOfNeg, et TimerOfSched, qui représentent respéctivement le temps nécessaire à la négociation de la réalisation de la commande et celui de la planification de cette même commande et dont les contenus sont respectivement 50, 30. L’évenement Event ("client", AgentState(StartC), IsInitialized) est défini pour démarrer le processus de la ‘’SCM’’.

L’exécution de cette configuration est donnée par la figure 5.36, qui montre que les agentsinternes (order-Acquisition, logistics, scheduler, transporter, dispatcher, et resource) ainsi que l’agent externe provider passent tous à l’état Success puisque les contraintes imposées par le client sur la côut de production et la date de livraison ont été évaluée acceptable, c.à.d. que la commande


101

du client peut être réalisée et livrai sans difficulté. Vu ce résulat le client va à son tour à l’état Success.

Figure 5.36. Exécution du Configuration initiale1.

Pour le deuxième cas, nous proposons la configuration initiale de la figure 5.37 suivante :

Figure 5.37. Configuration initiale2.

Cette configuration ressemble à celle de la figure 5.35, à la différence que les attributs : DelayConstraint, Deadline, PriceConstraint, Cost, ainsi que les deux messages TimerOfNeg, et TimerOfSched prennent de nouvelles valeurs. Les valeurs considérées sont classées dans cet ordre (10, 5, 15, 10, 60, 20).


102

Le résultat illustré par la figure 5.38 est celui d’une execution intermidière de la configuration initiale 2, où on voit que les agents internes (scheduler, transporter, dispatcher, et resource) ainsi que l’agent externe provider passent tous à l’état Failure du fait qu’ils ne peuvent pas acceptés les contraintes imposées par le client sur la côut de production et la date de livraison. Alors que les deux agents (order-Acquisition, et logistics) parts à leurs états initiaux (StartO, StartL). Le message ‘’ModifyOrder’’ indique à l’agent externe client qui va lui aussi à son état initiale (StartC) que sa commande doit être modifié pour qu’elle soit acceptée.

Figure 5.38. Exécution intermidière du Configuration initiale 2.

Après une ittération de l’exécution de la configuration de la figure 5.38, on constate que le coùt de production et le délai de livraison proposés par le client sont modifiés puisqu’ils passent respéctivement de 10 à 15 et de 5 à 10. Vu ce résultat les agents (Order Acquisition, Logistics, scheduler, transporter, dispatcher, et resource) ainsi que les deux agents externes provider, et Client passent tous à l’état Success (figure 5.39).

Figure 5.39. Exécution du Configuration de la figure 5.38.


103

Pour le troisième cas, nous proposons la configuration initiale de la figure 5.40 suivante :

Figure 5.40. Configuration initiale 3.

Cette configuration est la même présentée à la figure 5.35, sauf que l’évenement Event ("client", AgentState(WaitC), StopOrder) est ajouté. Ce dernier à pour effet de stoper la chaine de production.

L’exécution de cette configuration est donnée par la figure 5.41, qui montre que les les agents (Client, order-Acquisition, et logistics) passent à leurs états initiaux (StartC, StartO, StartL), du fait que la commande à été annuler par le client. Cependant, les autres agents (scheduler, transporter, dispatcher, et resource) ainsi que l’agent externe provider vont tous à l’état Success puisque les contraintes imposées au début par le client sur la côut de production et la date de livraison ont été jujées acceptable.

Figure 5.41. Exécution du Configuration initiale 3.


104

5. Conclusion

Dans ce chapitre nous avons appliqué notre approche à l’exemple de la gestion de chaîne logistique qui nous parait assez important pour illustrer les contraintes temporelles qu’un système multi-agents doit respecter. A traves cette étude de cas, nous avons montré la possibilité d’utiliser RT-maude pour la description des SMA temps réel.

105

Conclusion & Perspectives

Il existe différents travaux de recherche qui essayent de présenter des approches pour le développement des systèmes multi-agent temps réel. Néanmoins, aucune de ces approches ne tient compte de la formalisation des besoins fonctionnels des SMA temps réel. Ce qui nous a encouragés à proposer une méthode de développement générique qui soit orienté aux systèmes de ce type.

Le développement des SMA temps réel implique l’utilisation d’un formalisme de modélisation qui soit adaptée à incorporer les propriétés temporelles associées. Le langage de modélisation graphique Agent UML nous semble le candidat parfait pour réaliser cette tâche. Il est maintenant l’outil des concepteurs de système multi-agent. L’avantage d’un tel langage est le fait qu’il soit graphique et basé sur un langage connu parfaitement par les concepteurs et les compagnies. Les concepteurs auront moins de difficultés de passer à Agent UML dès qu’ils sont familiers à UML dans leurs développements. Cependant, Agent UML est dans ses premiers pas et plus d’efforts doivent être déployés afin de l’adapter complètement au domaine des systèmes multi-agent temps réel. Jusqu’à présent, il y a peu de travaux sur Agent UML et trés peu sur l’application d’Agent UML aux systèmes multi-agent temps réel et à des applications réel.

Dans ce mémoire nous avons présenté nos premiers résultats concernant l’application d’Agent UML et de Real Time Maude à la formalisation des besoins fonctionnels des SMA temps réel. La suite de cette conclusion va nous permettre de tirer un bilan de cette première application et de définir des directions de recherche. Un certain nombre de constats peuvent être déjà faits :

1. L’utilisation d’Agent UML pour la modélisation des SMA temps réel est complexe à mettre en œuvre, car elle nécessite l’usage de plusieurs diagrammes complémentaires. D’autre part, elle ne permet pas une quelconque validation des modèles créés.

2. L’ensemble des représentations provenant d’AUML semblent pouvoir être appliquées aux SMA temps réel mais avec quelques modifications, comme l’atteste ce travail. Nous avons en effet pu appliquer les diagrammes de cas d’utilisation, de classe, d’état transition, et de protocole.

3. Les diagrammes de cas d’utilisation AUML temporisés permettent de représenter la vue fonctionnel du système en décrivant les différents types d’agents (agents externes, agent temps réel,…) et les cas d’utilisation temporisé. Ces diagrammes présentent un intérêt majeur puisqu’ils définissent le quoi et non pas le comment du comportement des agents, c.à.d. le comportement du système et non pas comment le système est implémenté.

4. Les diagrammes de classe AUML temporisé sont certainement les diagrammes qui ont subi le plus de modifications. En effet, un agent ne peut se résumer à la fourniture d’un ensemble d’attributs et d’opérations. Il faut aussi préciser ‘les rôles’ des agents, ‘les protocoles’ qu’ils utilisent, ‘les contraintes temporelles’ à respecter, etc. De tous les diagrammes, c’est certainement les plus complexe et les plus difficile à réaliser, malheureusement il n’y a pas de recette miracle pour les concevoir. L’expérience semble primer. Un effort pour rendre plus facile la conception de ces diagrammes doit être envisagé.

Conclusion & Perspectives

106

5. Les diagrammes de protocole AUML étendu permettent de représenter les protocoles d’interaction. A notre avis, peu de modifications ont été apportées à ces diagrammes si ce n’est la présence de la propriété ‘de gestion du temps (time management)’.

6. Les diagrammes d’état transition AUML ont été utlilisés sans aucune modification.

7. L’absence de méthodologie pour aider le concepteur des systèmes multi-agents temps réel, lui indiquant par quel diagramme commencer et comment réaliser ces diagrammes. En effet, Il n’existe pas encore d’outils pour réaliser ces diagrammes. A l’heure actuelle, les concepteurs utilisent soit des outils UML, soit ils conçoivent à la main ces diagrammes.

AUML tout comme UML souffre cependant, d’un manque de sémantique formelle. Les modèles AUML développés pourront donc contenir des incohérences ou des inconsistances difficiles (voire impossibles dans le cas de certains systèmes complexes) à détecter manuellement. Les méthodes formelles représentent une solution intéressante à ce problème. Les spécifications formelles auront pour effet d’éliminer les ambigüités au niveau de l’interprétation des modèles. La combinaison d’Agent UML avec le langage de spécification formelle Real time Maude nous a permis de valider les modèles AUML développés pour la description des besoins fonctionnels des SMA temps réel. Cette démarche permet d’éliminer certaines erreurs de façon précoce avant de passer aux phases de conception et d’implémentation. En effet, il semble qu’un formalisme unique ne soit pas suffisant pour décrire convenablement la totalité du comportement des agents.

La validation de l’approche proposée est faite sur l’exemple de la gestion de chaine logistique (Supply Chain Management ‘’SCM’’). Cet exemple nous parait assez important pour illustrer les contraintes temporelles qu’un SMA doit respecter.

Enfin, nous voyons que l’application d’Agent UML avec RT-Maude ouvre de très intéressantes voies de recherche, nous suivrons en particulier la suivante : la vérification et la validation des modèles semi-formelles AUML translatés en descriptions formelle RT-Maude avec la technique de model checking.

107

Bibliographie[Ake02] Akehurst, D., Derrick, J. and Borten, E., A Framework for UML Consistency. In Proceedings of the IEEE Workshop on Consistency Problems in UML-based Software Development, Department of Software Engineering and Computer Science of Blekinge Institute of Technology, pages 30–45, 2002.

[All94] Alliot Jean-Marc, Schiex Thomas, Intelligence Artificielle et Informatique Théorique ; CEPAD ; Mars 1994.

[Ast98] Astesiano, E., UML as Heterogeneous Multiview Notation. Strategie for a Formal Foundation. In L. Andrade, A. Moreira, A. deshpande, and S. Kent, editors, Proceedings of the Conference on Object Oriented programming, Systems, Languages and Applications (OOPSLA’98) - Workshop on Formalizing UML. Why ? How ?, Canada, 1998.

[Aud06] Audibert Laurent. « UML 2.0 », Institut Universitaire de Technologie de Villetaneuse –Département Informatique 2006.

[Bau00a] Bauer, B., Müller, J. P., Odell, J., Agent UML: A Formalism for Specifying Multiagent Interaction. In P. Ciancarini and M.JWooldridge, editors., Agent oriented softxare ingineering (AOSE-00), 2000

[Bau00b] Bauer B., Muller J. P., Odell J., «An extension of UML by protocols for multiagent interaction», International Conference on MultiAgent Systems (ICMAS’00), Boston, Massachussetts, july, 10-12 2000, p. 207-214.

[Bau01a] Bauer, B., Müller, J. P., Odell, J., Agent UML: A Formalism for Specifying Multiagent Interaction. Agent-Oriented Software Engineering, Paolo Ciancarini and Michael Wooldridge eds., Springer-Verlag, Berlin, pp. 91-103, 2001.

[Bau01b] Bauer B., «UML Class Diagrams Revisited in the Context of Agent-Based Systems », WOOLDRIDGE M., CIANCARINI P., WEISS G., Eds., Proceedings of Agent- Oriented Software Engineering (AOSE 01), nˇr 2222 LNCS, Montreal, Canada, May 2001, Springer-Verlag, p. 1–8.

[Bau02] Bauer, B., (2002) "UML Class Diagrams revisited in the context of agent-based systems." In: M. Wooldridge, P. Ciancarini, and G. Weiss (Eds.) Proceedings of Agent-Oriented Software Engineering, Second International Workshop, AOSE 2001, LNCS 2222 Springer, Canada, p. 101-118.

[Bau05] Bauer B., Odell J., (2005) ‘’UML 2.0 and Agents: How to Build Agent-based Systems with the new UML Standard’’.

[Bee03] Beer, M., et al., Designing Community Care Systems with AUML, in Proceedings of the International Conference E.U-LAT e-Health, Cuernavaca, Mexico, 2003.

[Ben93] Benyahia, I., «Automatisation de la circulation des informations en temps réel». Thèse de l'université de Paris 6, Laforia, Décembre 1993.

[Boo99] Booch, G., Rumbaugh, J., Jacobson I., The Unified Modeling Language User Guide, Addison-Wesley, Reading, Massachusetts, USA, 1999.

Bibliographie

108

[Bör00] Börger, E., Cavarra, A. and Riccobene, E., Modeling the Dynamics of UML State Machines. In ASM ’00 : Proceedings of the International Workshop on Abstract State Machines, Theory and Applications, Springer-Verlag, pages 223–241, 2000.

[Bot95] Botti, V., Barber, F., Crespo, A., Onaindia, E., Garcia-Fornes, A., Ripoll, I., Gallardo, D., and Hernndez, A temporal black-board for a multi-agent envirnment, Data and Knwoledge Engineering 15 (1995), 189-211.

[Cer05] Cernuzzi, L., Cossentino, M., and Zambonelli, F., Process models for agent-based development. Journal of Engineering Applications of Artificial Intelligence, Elsevier. Vol.18(2) :205–222, March 2005.

[Cha98] Chan, W., Anderson, R. J., Beame, P., Burns, S., Modugno, F., Notkin, D. and Reese, J. D., Model Checking Large Software Specifications. IEEE Transactions on Software Engineering, 24(7) :498–520, July 1998.

[Cha99] Chaïb-Draa Brahim, Agents et Systèmes Multiagents (IFT 64881A). Notes de cours. Département d’informatique, Faculté des sciences et de génie, Université Laval, Québec. Novembre 1999.

[Cla03] Clarke, E. M., Model Checking Overview. Presentation Slides, 2003.

[Cla05] Clavel, M., Duran, F., Eker, S., Lincoln, P., Marti-Oliet, N., Meseguer, J., et Talcott, C.,«Maude Manual (version 2.2)». SRI International, Menlo Park, CA 94025, USA. December 2005.

[Des08] Desfray Philippe, « Le Guide Pratique Des Cas D’utilisation », Equipe Conseil Softeam (version 1.0) 2008.

[Dod89] Dodhiawala, R., Sridharan, N. S., Raulefs, P., and C. Références - 169 - Pickering. Real-time AI systems: a definition and an architecture. Proc. 11 th IJCAI, Détroit, 1989.

[Duv01] Duvallet Claude., Des systèmes d'aide à la décision temps réel et distribuées : modélisation par agents. Le 5 octobre 2001.

[Eal99] Ealmmari M., Lalonde W., An Agent-Oriented Methodology : High-Level and Intermediate Models. Proceedings of AOIS-1999. Heidelberg (Germany), June 1999.

[Ein03] Einhorn, J. M., and C.-H. Jo, 2003, “A use case based bdi agent software development process,” in Proceedings of the 2nd. International Workshop on Agent Oriented Methodologies - OOPSLA-2003, Anaheim, CA, USA.

[Ekr02] Eker, S., Meseguer, J. and Sridharanarayanan, A. The Maude LTL Model Checker. F. Gaducci and U. Montanari, editors, Proc. of the 4th International Workshop on Rewriting Logic and its Applications (WRLA 2002), 2002.

[Eur00] Eurescom, MESSAGE : Methodologie For Engineering Systems Of Software Agents. Initial methodologie. Technical report P907-D1, eurescom, July2000.

[Fer95] Ferber J., Les systèmes Multi-Agents : vers une intelligence collective. InterEdition, Paris, France, 1995.

[Fer98] Fernández, C. Ángel Iglesias, January 1998, “Definición de una metodología para el desarrollo de sistemas multiagente,” Ph.D. dissertation, Universidad Politécnica de Madrid.

Bibliographie

109

[FIPA97] Foundation for Intelligent Physical Agents, FIPA 97 Specification Part 1 Agent Management, Specification Oct 10, 1997.

[Fox81] Fox, M.S., An organizational view of distributed systems. IEEE Trans. Syst.Man. Univ. Cybern., vol. SMC-11; 1981, pp. 70-80.

[Gag07] Gagnon, Patrice., Vérification formelle de diagrammes UML: une approche basée sur la logique de réécriture. Université du québec. Août 2007.

[Gar02] García Roselló, E., Ayude, J., García-Schofield, J. B. and Pérez Cota, M. Design Principles for Highly Reusable Concurrent Object-Oriented Systems. In Journal of Object Technology, 1(1) :107–123, 2002.

[Gar03] Garneau, Tony., La Programmation Orientée-Agent DMAS Builder : Un environnement de Développement De Systèmes Multi-Agents Totalement Distribués. Département de mathématiques et d’informatique Université du Québec à Trois-Rivières ; Août 2003.

[Gat07] Gatti, Maíra Athanázio de Cerqueira., Arndt von Staa, Carlos José Pereira de Lucena. AUML-BP: A Basic Agent Oriented Software Development Process Model Using AUML. Pontifícia Universidade Católica Do Rio De Janeiro. August 2007.

[Gue96] Guessoum, Zahia., Un environnement opérationnel de conception et de réalisation de systèmes multi-agents. Université Pierre et Marie Curie. Le 22 mai 1996.

[Hah08] Hahn Christian · Cristián Madrigal-Mora · Klaus Fischer. A platform-independent metamodel for multiagent systems. Le 10 Avril 2008.

[Ham09] Hamidane, Fathi. Formalisation des Besoins Fonctionnels des Systèmes Multi-Agents à l’aide de Maude. Mémoire de Magister, Université Cheikh Larbi Tbessi-Tebessa (2009).

[Hat91] Haton, J.P., Bouzid, N., Charpillet, F., Haton, M-C., Laasri, B., Laasri, H., Marquis, P.,Mondot, T., et Napoli, A., «Le raisonnement en intelligence artificielle». InterEditions, Paris, 1991.

[Hei00] Heinze, C., Papasimeon, M., and Goss, S., Specifying Agent behaviour with use case (2000).

[Hug02a] Huget, M.-P., Une application D'AUML au Supply chain Management (2002).

[Hug02b] Huget, M.-P., Extending agent UML protocol diagrams. In F. Giunchiglia, J. Odell, and G. Weiss, editors, AAMAS Workshop on Agent-Oriented Software Engineering (AOSE), Bologna, Italy, July 2002.

[Hug02c] Huget, M.-P., ‘’Agent UML class diagrams revisited’’. Technical Report, Department of Computer Science, University of Liverpool, 2002. p. 1-13

[Hug02d] Huget, M.-P., ‘’An application of agent UML to supply chain management’’. Technical Report ULCS-02-015, Department of Computer Science, University of Liverpool, 2002. p. 1-14

[Hug02e] Huget, M.-P., ‘’An application of agent UML to supply chain management’’. Technical Report ULCS-02-015, Department of Computer Science, University of Liverpool, 2002. p. 1-5

Bibliographie

110

[Hug02f] Huget, M.-P., A Langage For Exchanging Agent UML Protocol Diagrams. Department of Computer Science, University of Liverpool, 2002.

[Hug02g] Huget, M.-P., (2002) "Generating Code for Agent UML Sequence Diagrams." In Proceedings of Agent Technology and Software Engineering (AgeS), Bernhard Bauer, Klaus Fischer, Jorg Muller and Bernhard Rumpe (eds.), Erfurt, Germany, October.

[Hug02h] Huget, M.-P., Design Agent Interaction As A Service To Agent. In M.-P. Huget, F. Dignum, and J.-L. Koning, editors, AAMAS Workshop on Agent Communication Langages And Conversation Policies (ACL2002), Bologna, Italy, July 2002.

[Hug02i] Huget, M.-P., ‘’Agent UML Class Diagram Revisited’’, Technical Report, Department of Computer Science, University of Liverpool, 2002. p. 1-12

[Igg99] Iglesias, C., Garrijo, M., and Gonzalez, J., A survey of agent-oriented methodologies. InJörg Müller, Munindar P. Singh, and Anand S. Rao, editors, Proceedings of the 5th International Workshop on Intelligent Agents V : Agent Theories, Architectures, and Languages (ATAL-98), volume 1555, pages 317–330. Springer-Verlag : Heidelberg, Germany, 1999.

[Jen00] Jennings, N. R., Wooldridge, M., «Agent-Oriented Software Engineering», BRADSHAW J., Ed., Handbook in Agent Technology, MIT Press, 2000.

[Jul04a] Julián, V., Botti, J.V., Developing Real-Time Multi-Agent System (2004).

[Jul04b] Julián, V., Soler, J., Moncho, M.C., Botti, V., Real-Time Multi-Agent System Development and Implementation (2004).

[Kav92] Kavi, K., «Real-Time Systems: Abstractions, Languages, and Design Methodologies». IEEE Computer Society Press, 1992.

[Kou07] Koutsabasis Panayiotis et Darzentas John. Methodologies for agent systems development: underlying assumptions and implications for design. 8 May 2007 ; Springer-Verlag London Limited 2007.

[Maa04] Maarouk, T. M., (2004). Spécification Formelle Des Systèmes Mobiles Temps Réel.Equipe vision et infographie, laboratoire LIRE, université mentouri Constantine.

[Mal05] Malgouyres, H., Jean-Pierre, S. W., and Motet, G., Identification de Règles de Cohérence d’UML 2.0. Journée SEE "Systèmes Informatiques de Confiance" sur le thème "Vérification de la cohérence de modèles UML", Paris, France, Mars 2005.

[Meg04] Megzari, K., (2004). REFINER : Environnement logiciel pour le raffinement d’architectures logicielles fondé sur une logique de réécriture. Laboratoire d’Informatique, Systèmes, Traitement de l’Information et de la Connaissance ESIA – Université de Savoie.

[Mel05] Melián Susel Fernández ; Marsá Iván ; MaestreUkrania ; Díaz RosarioMiguel ; A. López-Carmona. Extending the BDI ASDP methodologie for real time (2005).

[Mes99] Message web site : http://www.eurescom.de/public/projects/P900-series/p907/

[Mes01] Message, Metamodel web site : http://www.eurescom.de/~public-webspace/P900-series/P907/MetaModel/index.htm

[Mes02] Meseguer, J., Software Specification and Verification in Rewriting Logic. Germany, August 2002.

Bibliographie

111

[Mok10] Mokhati, F., Sahraoui, B., Bouzaher, S., Kimour, M.T., "A Tool for Specifying and Validating Agents’ Interaction Protocols: From Agent UML to Maude", in Journal of Object Technology, vol. 9, no. 3, May - June 2010, pp. http://www.jot.fm/issues/issue_2010_05/article2/

[Mor00] Moreira, A., Bruel, J. M., Lilius, J. and Robert, B., Defining Precise Semantics for UML. In ECOOP’2000 Workshop Reader, number 1964. Springer-Verlag, November 2000.

[Mou93] Mouaddib, A., Contribution au raisonnement progressif et temps réel dans un univers multi-agents. Thèse de l'université de Nancy I, octobre 1993.

[Mou96b] Moulin Bernard, Chaib-draa B., An Overview of Distributed Artificial Intelligence. In : O’HARE, G. ; JENNINGS, N. (eds.) Foundations of Distributed (1996).

[Moy00] Moyaux, Thierry., Specification De Comportements D’agents Dans Des Systemes Multi-Agents. Université de Droit, d’Économie et des Sciences d’Aix-Marseille III. Le 27 septembre 2000.

[Mul00] Muller, P. A. and Gaertner, N. Modélisation Objet avec UML. Deuxième édition, Paris, 2000.

[Mus03] Muskens, J., Somers, L., Lange, C., Chaudron, M. and Dortmans, E. An Empirical Investigation in Quantifying Inconsistency and Incompletness in UML Designs. In Proceedings of the IEEE Workshop on Consistency Problems in UML-Based Software Development II, pages 26–34. IEEE and Department of Software Engineering and Computer Science of Blekinge Institute of Technology, 2003.

[Ode00] Odell J., Parunak H. V. D., Bauer B., «Extending UML for Agents», WAGNER G., LESPERANCE Y., YU E., Eds., Proceedings of the Agent-Oriented Information Systems Workshop at the 17th National conference on Artificial Intelligence, Austin, Texas, july, 30 2000, ICue Publishing.

[Ode01] Odell, J., Parunak, H. and Bauer, B. (2001) "Representing agent interaction protocols in UML," In Agent-Oriented Software Engineering, First International Workshop, AOSE 2000, Ciancarini, P., Wooldridge, M., Eds., LNCS 1957 Springer, Limerick, Ireland. pp. 121-140.

[Ode03] Odell, J., Parunak, H. and Fleisher, M., "The Role of Roles in Designing Effective Agent Organizations" In Software Engineering for Large-Scale Multi-Agent Systems, Garcia, A., Lucena, C., Zamobnelei, F., Omicini, A and Carstro, J., Eds., LNCS, Springer-Verlag, 2003.

[Olv06] Olveczky, P. C., «Real-Time Maude 2.2 Manual». Department of Informatics. University of Oslo, 2006.

[Omi01] Omicini, A., 2001, “Soda: Societies and infrastructures in the analysis and design of agent-based systems,” in Agent Oriented Software Engineering, P. Ciancarini and M. Wooldridge, Eds., vol. 1957. New York: Springer, pp. 185– 193.

[Pad02] Padgham L., Winikoff M. "Prometheus: A Methodology for Developing Intelligent Agents" Proceedings of the third International Workshop on Agent-Oriented Software Engineering, (AAMAS 2002), Bologna, Italy.

[Par02] Parunak, H. and Odell, J. (2002), "Representing social structures in UML," In Agent-Oriented Software Engineering II, Wooldridge, M., Weiss, G. and Ciancarini, P., Eds., LNCS 2222, Springer-Verlag, Berlin, pp. 1-16. 23

Bibliographie

112

[Pap00] Papasimeon, M., and Heinze, C., Specifying Requirement in Multi-agent system with use cases. Le 07/03/00.

[Per05] Peres, J., Bergmann, U., Experiencing AUML for MAS Modeling : A Critical View, SEAS 2005, Uberlandia, MG.

[Pes97] Pesty, S., Brassac, C., et Ferrent, P., Ancrer les agents cognitifs dans l’environnement. In : Actes des 5e Journées Francophones sur l’Intelligence Artificielle Distribuée et les Systèmes Multi-Agents. – La Colle sur Loop, Avril 1997.

[Reg99] Reggio, G. and Wieringa, R. Thirty One Problems in the Semantics of UML 1.3 Dynamics. In Conference on Object Oriented programming, Systems, Languages and Applications (OOPSLA’99) - Workshop "Rigorous Modeling an Analysis of the UML Challenges and Limitations", 1999.

[Sab01] Sabas, A., Systèmes Multi-Agents : Une Analyse Comparative Des Méthodologies De Développement, Vers la convergence des méthodologies de développement et la standardisation des plateformes SMA. Département de mathématiques et d’informatique ; Université du Québec à Trois-Rivières, Octobre 2001.

[Sad04] Sadeg, Bruno., Contributions à la gestion des transactions dans les SGBD temps réel. Universite Du Havre Ufr Des Sciences Et Techniques. 26 Novembre 2004.

[She99] Shen, W., Norrie, D. H., «Agent-Based Systems for Intelligent Manufacturing : A State-of-the-Art Survey», Knowledge and Information Systems, vol. 1, nˇr 2, 1999, p. 129-156.

[Swa 97] Swaminathan, J., Smith, S., Sadeh-Koniecpol, N., «Modeling Supply Chain Dynamics : A Multiagent Approach», Decision Sciences, 1997.

[Tar06] Tarek, J., ‘’Réutilisation des protocoles d’interaction et Démarche orientée modèles pour le développement multi-agents’’. Thèse de doctorat, Université de Reims champagne-ardenne. Le 8 décembre 2006, à Reims.

[Tre05] Trencansky, I., & Cervenka, R. (2005). Agent modeling language (AML): A comprehensive approach to modeling MAS. Informatica, 29(4), 391–400.

[Tve01] Tveit, A., A survey of agent-oriented software engineering. May 2001.

[Woo00a] Wooldridge, M., Jeennings, N. R., (2000), «Agent-Oriented Software Engineering» in Handbook of Technology (ed. J. Bradshaw) AAAI/MIT Press.

[Woo00b] Wooldridge, M., Jennings N., Kinny, D., "The GAIA methodology for agent-oriented analysis and design", 2000.

[Woo01] Wooldridge, M., Ciancarini, P., Agent-Oriented Software Engineering : The State of the Art. In P. Ciancarini and M. Wooldridge, editors, First Int. Workshop on Agent-Oriented Software Engineering, volume Lecture Notes in AI Volume 1957, pages 1–28. Springer-Verlag, Berlin, 2001.

[Zam00] Zambonelli, F., Jennings N. R., and Wooldridge M . (2000), «Organisational Abstrations for the Analysis and Design of Multi-Agent Systems» Proc. 1st Int. Workshop on Agent-Oriented Software Engineering, Limerick, Ireland, 127-141.

[Zha06] Zhang, Lichen., Development Method for Multi-Agent Real-Time Systems. Faculty of Computer Science and Technology Guangdong University of Technology (2006).

Description des Besoins Fonctionnels des Systèmes Multi...

Documents

Transcript of Description des Besoins Fonctionnels des Systèmes Multi...