N dordre : REPUBLIQUE TUNISIENNE

MINISTERE DE LENSEIGNEMENT SUPERIEUR, DE LA RECHERCHE SCIENTIFIQUE ET DE LA TECHNOLOGIE

UNIVERSITE DE MONASTIR

FACULTE DES SCIENCES DE MONASTIR

MEMOIRE
Prsent pour lobtention du diplme de :

MASTERE
Spcialit : INFORMATIQUE Par :

Mohamed GAROUI
Sujet :

Vers une Approche de Spcification Formelle des Systmes Multi-Agents Holoniques

Soutenu le 24 Septembre 2011, devant le jury compos : Dr. Nazih OMRI Dr. Mohamed GRAIET Dr. Belhassen MAZIGH Prsident Rapporteur Encadreur Matre de Confrences FSM Matre Assistant ISIMM Matre Assistant, FSM

Laboratoire (Code : MESRST /UR/LR.)

Mmoire de Master DISCIPLINE : INFORMATIQUE

Vers une approche de Spcification formelle des systmes Multi-Agents Holoniques

Par

Mohamed GAROUI

Encadr par : Belhassen MAZIGH

Table des matires

CHAPITRE 1 INTRODUCTION ...................................................................................................................................... 9 1.1 1.2 1.3 1.3.1 1.3.2 1.3.3 1.3.4 1.3.5 1.3.6 Contexte.................................................................................................................................. 9 Premire analyse et objectifs de ces travaux ....................................................................... 9 Etat de lart .......................................................................................................................... 10 Les Mthodes formelles............................................................................................... 10 La spcification formelle ............................................................................................. 10 Les preuves formelles .................................................................................................. 10 Les systmes Multi-Agents.......................................................................................... 11 Les systmes Multi-Agents Holoniques ......................................................................... 12 Le mta modle CRIO (Capacit, Rle, Interaction, Organisation) ........................... 14

1.3.7 Le Processus ASPECS (Agent-oriented Software Process for Engineering Complex Systems) 14 CHAPITRE 2 LANGAGES FORMELS ........................................................................................................................... 18 2.1 2.2 2.3 2.3.1 2.3.2 2.3.3 2.4 Introduction ......................................................................................................................... 18 Systmes formels, vrification, preuve, model-checking.................................................. 18 Quelques langages formels.................................................................................................. 19 Z et Object-Z ................................................................................................................ 19 La mthode B ............................................................................................................... 21 Les rseaux de Petri..................................................................................................... 22 Conclusion ............................................................................................................................ 23

CHAPITRE 3 DEUX FORMALISMES COMPLEMENTAIRES : LES RESEAUX DE PETRI ET OBJECT-Z ...................... 25 3.1 3.2 3.2.1 3.2.2 3.2.3 3.2.4 3.3 3.3.1 Introduction ......................................................................................................................... 25 Les rseaux de Petri ............................................................................................................ 25 Concepts propres aux rseaux de Petri ..................................................................... 26 Concepts et dfinitions ................................................................................................ 26 Proprits usuelles ....................................................................................................... 28 Smantique des Rseaux de Petri ............................................................................... 29 Le langage Object-Z ............................................................................................................ 29 La Syntaxe dObject-Z ................................................................................................ 30 2

3.3.2 3.4

Smantique de trace et invariants temporels ............................................................ 33 Conclusion ............................................................................................................................ 34

CHAPITRE 4 METHODE DE COMPOSITION DES SPECIFICATIONS PARTIELLES .................................................... 35 4.1 4.2 4.3 4.3.1 4.3.2 4.4 4.4.1 4.5 4.5.1 4.5.2 4.5.3 4.5.4 4.5.4.1 i. 4.1 4.3 Introduction ......................................................................................................................... 35 Aperu de notre approche .................................................................................................. 35 Intgration syntaxique ........................................................................................................ 36 Principes ....................................................................................................................... 36 Aspects des RdP exprims en Object-Z ..................................................................... 36 Rgles de traduction du RdP vers le domaine syntaxique partag ................................. 45 Dfinition de la fonction Y .......................................................................................... 45 Intgration smantique ....................................................................................................... 46 Aperu .......................................................................................................................... 46 Systme de transitions ................................................................................................. 46 Systme de transitions temporises ............................................................................ 47 Technique de transformation ..................................................................................... 48 De la classe Object-Z un systme de transitions .................................................... 48 Exemple : classe Object-Z simpletrans....................................................................... 49 Exemple dintgration complte ........................................................................................ 55 Conclusion ............................................................................................................................ 62

CHAPITRE 5 APPROCHE DE SPECIFICATION FORMELLE DUN SYSTEME MULTI-AGENT HOLONIQUE ............... 64 5.1 5.2 5.2.1 5.2.2 5.2.3 5.3 5.3.1 5.3.2 5.3.3 5.4 5.4.1 5.5 Introduction ......................................................................................................................... 64 Domaine du Problme associ au mta-modle CRIO..................................................... 64 Spcification ................................................................................................................. 64 Lemmes......................................................................................................................... 67 Exemple ........................................................................................................................ 67 Domaine dagentification associ au mta-modle CRIO................................................ 75 Spcification ................................................................................................................. 75 Lemmes......................................................................................................................... 80 Exemple ........................................................................................................................ 81 Gnration semi-automatique des instances partir de la spcification........................ 85 Exemple ........................................................................................................................ 86 Conclusion ............................................................................................................................ 88

CHAPITRE 6 VERIFICATION DE SPECIFICATION DE SYSTEMES MULTI-AGENTS HOLONIQUE : CAS DE LENTREPRISE DE FABRICATION DES AUTOMOBILES PEUGEOT .................................................... 90 6.1 6.2 6.3 6.3.1 6.3.2 6.4 6.4.1 6.4.2 6.5 6.5.1 6.5.2 6.5.3 6.6 6.6.1 6.6.2 6.7 Introduction ......................................................................................................................... 90 Prsentation du systme ...................................................................................................... 90 Modlisation ......................................................................................................................... 91 Domaine du Problme ................................................................................................. 91 Domaine dagentification ............................................................................................ 93 Spcification ......................................................................................................................... 93 Domaine du Problme ................................................................................................ 93 Domaine dagentification ............................................................................................ 99 Vrification......................................................................................................................... 103 Dfinition des tats du systme de transitions......................................................... 104 Dfinition des transitions du systme de transition ................................................ 104 Preuve ......................................................................................................................... 105 Implmentation sur la plateforme Janus ........................................................................ 105 Plateforme Janus ....................................................................................................... 105 Exemple ...................................................................................................................... 105 Conclusion .......................................................................................................................... 111

CONCLUSION ...................................................................................................................................... 113 Annexes .............................................................................................................................................. 115 ANNEXE A FRAMEWORK SAL (SYMBOLIC ANALYSIS LABORATORY) ............................................................. 116 BIBLIOGRAPHIE.................................................................................................................................. 121

Table des figures

Fig. 1 : Un holon compos de trois holons membres ............................................................................ 12 Fig. 2: Structure Holonique (gure inspire de [Ferber, 1995, p. 100]) ................................................ 13 Fig. 3 : Modle du Rseau de Petri........................................................................................................ 26 Fig. 4 : Syntaxe dune classe Object-Z .................................................................................................. 30 Fig. 5 : Schma Object-Z du classe CreditCard .................................................................................... 31 Fig. 6 : Rseau de Petri Ordinaire ......................................................................................................... 37 Fig. 7 : Spcification dun RdP ordinaire base sur la syntaxe de classe OZ........................................ 38 Fig. 8 : Rseau de Petri gnralis......................................................................................................... 39 Fig. 9 : Spcification dun RdP gnralis base sur la syntaxe de classe OZ ...................................... 40 Fig. 10 : Exemple de Rseau de Petri arc inhibiteur.......................................................................... 40 Fig. 11 : Spcification dun RdP arcs inhibiteurs base sur la syntaxe de classe OZ ......................... 41 Fig. 12 : Rseau de Petri capacit ....................................................................................................... 42 Fig. 13 : Spcification dun RdP capacit base sur la syntaxe de classe OZ .................................... 42 Fig. 14 : Spcification dun RdP temporise base sur la syntaxe de classe OZ .................................... 43 Fig. 15 : Rseau de Petri Temporel ....................................................................................................... 44 Fig. 16 : Spcification dun RdP Temporel base sur la syntaxe de classe OZ .................................... 45 Fig. 17 : les lments dune classe Object-Z ......................................................................................... 49 Fig. 18 : Classe Object-Z "simpletrans" ................................................................................................ 50 Fig. 19 : Fichier SAL relatif la classe Object-Z "simpletrans" ........................................................... 53 Fig. 20 : Rseau de Petri pour le systme dinterrupteur....................................................................... 54 Fig. 21: Fichier SAL relatif au rseau de Petri du systme "interrupteur" ........................................... 55 Fig. 22 : Spcification du systme Key base sur la syntaxe PNOZ .................................................... 56 Fig. 23 : Spcification du systme Lock base sur la syntaxe PNOZ .................................................... 57 Fig. 24 : Spcification du systme Door base sur la syntaxe PNOZ .................................................. 58 Fig. 25 : Spcification du systme KeySystem base sur la syntaxe PNOZ .......................................... 59 Fig. 26 : Classe Capacity base sur la syntaxe PNOZ.......................................................................... 65 Fig. 27 : Classe Role base sur la syntaxe PNOZ................................................................................. 65 Fig. 28 : Classe Interaction base sur la syntaxe PNOZ ...................................................................... 66 Fig. 29 : Classe Organisation base sur la syntaxe PNOZ ................................................................... 67 Fig. 30: Description de lorganisation du simulateur des robots footballeurs ....................................... 68 Fig. 31 : Classe PlayersSimulatorRole base sur la syntaxe PNOZ ..................................................... 69 Fig. 32 : Classe RoleAssignerRole base sur la syntaxe PNOZ ........................................................... 70 Fig. 33 : Classe StrategySelectorRole base sur la syntaxe PNOZ ...................................................... 71 Fig. 34 : Classe GameObserverRole base sur la syntaxe PNOZ ........................................................ 72 Fig. 35 : Classe AssociateTacticalRoleAndPlayer Interaction base sur la syntaxe PNOZ ................. 73 Fig. 36 : Classe AssignsStrategy Interaction base sur la syntaxe PNOZ ............................................ 73 Fig. 37 : Classe ProvidesPlayersPositions Interaction base sur la syntaxe PNOZ ............................. 73 Fig. 38 : Classe PlayStrategy Capacit base sur la syntaxe PNOZ .................................................... 74 Fig. 39 : Classe ObserveGame Capacit base sur la syntaxe PNOZ .................................................. 74 Fig. 40 : Classe ChooseStrategy Capacit base sur la syntaxe PNOZ ............................................... 74 Fig. 41 : Classe TeamSimulation Organisation base sur la syntaxe PNOZ ........................................ 75 Fig. 42 : Classe AgentTask base sur la syntaxe PNOZ ....................................................................... 75 5

Fig. 43 : Classe Service base sur la syntaxe PNOZ ............................................................................ 76 Fig. 44 : Classe AgentRole base sur la syntaxe PNOZ ....................................................................... 76 Fig. 45 : Classe Goal base sur la syntaxe PNOZ ................................................................................ 76 Fig. 46 : Classe IndividualGoal base sur la syntaxe PNOZ................................................................ 77 Fig. 47 : Classe CollectiveGoal base sur la syntaxe PNOZ ................................................................ 77 Fig. 48 : Classe AutonomousEntity base sur la syntaxe PNOZ .......................................................... 77 Fig. 49 : Classe Agent base sur la syntaxe PNOZ............................................................................... 78 Fig. 50 : Classe HolonicRole base sur la syntaxe PNOZ .................................................................... 78 Fig. 51 : Classe HolonicMember base sur la syntaxe PNOZ .............................................................. 78 Fig. 52 : Classe Group base sur la syntaxe PNOZ ............................................................................. 79 Fig. 53 : Classe HolonicGroup base sur la syntaxe PNOZ ................................................................. 79 Fig. 54 : Classe ProductionGroup base sur la syntaxe PNOZ............................................................ 79 Fig. 55 : Classe Holon base sur la syntaxe PNOZ .............................................................................. 80 Fig. 56: La structure holonique du simulateur de robots footballeurs ................................................... 81 Fig. 57 : Classe Holon H1 base sur la syntaxe PNOZ ........................................................................ 82 Fig. 58 : Classe Holon H2 base sur la syntaxe PNOZ ........................................................................ 82 Fig. 59 : Classe Membre holonique H3 base sur la syntaxe PNOZ.................................................... 82 Fig. 60 : Classe Holon H3 base sur la syntaxe PNOZ ........................................................................ 83 Fig. 61 : Classe PlayersSimulator AgentRole base sur la syntaxe PNOZ .......................................... 83 Fig. 62 : Classe Groupe Holonique g3 base sur la syntaxe PNOZ ..................................................... 84 Fig. 63 : Classe Groupe Productive g4 base sur la syntaxe PNOZ ..................................................... 84 Fig. 64 : Classe Agent H11 base sur la syntaxe PNOZ ...................................................................... 84 Fig. 65 : Classe Interaction TeamToTeam base sur la syntaxe PNOZ ................................................ 85 Fig. 66 : Classe Groupe GameSimulation base sur la syntaxe PNOZ ................................................ 85 Fig. 67 : Instanciation du fichier XML partir du fichier XML schma .............................................. 86 Fig. 68 : XML schma du domaine de problme du mta modle CRIO ............................................. 86 Fig. 69 : fichier XML de domaine de problme Team Simulateur ................................................. 87 Fig. 70: Organigramme de lentreprise PEUGEOT de fabrication des automobiles ............................ 91 Fig. 71 : La classe de lorganisation DirectionGnrale ....................................................................... 93 Fig. 72 : La classe associe lorganisation DirectionProduction ....................................................... 94 Fig. 73 : La classe associe lorganisation DirectionCommerciale .................................................... 94 Fig. 74 : La classe associe lorganisation Emboutissage .................................................................. 94 Fig. 75 : La classe associe la capacit ProduireAutomobile ............................................................. 95 Fig. 76 : La classe associe la capacit GrerPersonnel .................................................................... 95 Fig. 77 : La classe associe la capacit Commerce............................................................................. 95 Fig. 78 : La classe associe la capacit EmboutirTle........................................................................ 96 Fig. 79 : La classe associe la capacit AssemblerTle ...................................................................... 96 Fig. 80 : La classe associe au Rle Production base sur la syntaxe PNOZ ...................................... 97 Fig. 81 : La classe associe au Rle Personnel base sur la syntaxe PNOZ ........................................ 98 Fig. 82 : La classe associe au Rle Emboutissage base sur la syntaxe PNOZ .................................. 99 Fig. 83 : La classe associe au holon AT1 base sur la syntaxe PNOZ ............................................. 100 Fig. 84 : La classe associe lAgentRole Emboutissage base sur la syntaxe PNOZ...................... 101 Fig. 85 : La classe associe au groupe holonique g5 base sur la syntaxe PNOZ.............................. 102 Fig. 86 : La classe associe lagent A1 base sur la syntaxe PNOZ................................................ 102 Fig. 87 : La classe associe lagent A2 base sur la syntaxe PNOZ................................................ 102 Fig. 88 : La classe associe au groupe de Production g6 base sur la syntaxe PNOZ ....................... 103 Fig. 89: Lhirarchie de la socit dagent/Holon de lentreprise ....................................................... 103 Fig. 90 : code source du rle ProductionRole ..................................................................................... 106 6

Fig. 91 : code source du lorganisation DirectionProductionOrganization ........................................ 107 Fig. 92 : code source du lorganisation EmboutissageOrganization .................................................. 107 Fig. 93 : code source du lagent MachineAgent ................................................................................. 108 Fig. 94 : code source du lagent RobotAgent ..................................................................................... 109 Fig. 95 : code source dHolon EmboutissageHolon ............................................................................ 109 Fig. 96 : code source du classe Main................................................................................................... 110

PREMIERE PARTIE

Contexte & Etat de lart

CHAPITRE 1

INTRODUCTION
1.1 Contexte
La thorie des systmes complexes a connu rcemment un sursaut majeur, et les travaux de recherche sur ces systmes sont de plus en plus considrs comme une discipline part entire, transversale de nombreux domaines scientifiques tels que la physique, la chimie, la biologie, linformatique, la sociologie ou encore lconomie. Les Systmes Multi-Agents, que nous dsignons par la suite SMA, forment un nouveau paradigme pour la conception des systmes complexes. En effet, ce paradigme propose de nouvelles stratgies pour analyser, concevoir et implmenter de tels systmes. Les systmes multi-agents sont considrs comme des socits composes d'entits autonomes et indpendantes, appeles agents, qui interagissent en vue de rsoudre un problme ou de raliser collectivement une tche. Les Systmes Multi-Agents Holoniques (SMAH) peuvent offrir une alternative intressante ce problme. Lide sous-jacente ce type de systmes considre que des agents peuvent se regrouper pour crer un agent de niveau suprieur ou quun agent peut tre dcompos en plusieurs agents de niveau infrieur. Ce processus de composition mutuelle donne naissance un systme hirarchique.

1.2 Premire analyse et objectifs de ces travaux

Lobjectif principal de notre mmoire peut tre rsum par lnonc suivant : Proposer une approche de spcification formelle des organisations holoniques qui permet dexprimer pleinement et de manire formelle les aspects des SMAH afin daboutir une spcification non ambigu et sans erreurs. Parmi les caractristiques des SMAH qui justifient la ncessit dutiliser une mthode de spcification formelle, on peut citer : Lvolution continuelle dun SMAH. La diversit et la complexit des composants formant un SMAH. En particulier, les agents et les holons peuvent tre trs divers et exhiber un comportement complexe. Concrtement, on se propose de dvelopper une approche multi-formalismes, base sur les rseaux de Petri (RdP ou PN) et le langage Object-Z (OZ) comme outil danalyse formelle de spcification. Cette approche servira formaliser la mthodologie ASPECS (Agentoriented Software Process for Engineering Complex Systems) propose par [Gaud, 2007] qui
9

sera utilise pour la spcification, la vrification et limplmentation des systmes dcisionnelles au sein des organisations complexes.

1.3 Etat de lart

1.3.1 Les Mthodes formelles En informatique, les mthodes formelles sont des techniques permettant de raisonner rigoureusement, l'aide de logique mathmatique, sur des programmes informatiques ou des composants lectroniques, afin de dmontrer leur validit par rapport une certaine spcification. Ces mthodes permettent d'obtenir une trs forte assurance de l'absence de bug dans les logiciels, c'est--dire d'acqurir des niveaux d'valuation d'assurance levs, elles sont bases sur les smantiques des programmes, c'est--dire sur des descriptions mathmatiques formelles du sens d'un programme donn par son code source (ou parfois, son code objet). Cependant, elles sont gnralement coteuses en ressources (humaines et matrielles) et actuellement rserves aux logiciels les plus critiques. Leur amlioration et l'largissement de leurs champs d'application pratique sont la motivation de nombreuses recherches scientifiques en informatique1. 1.3.2 La spcification formelle Les mthodes formelles peuvent tre utilises pour donner une spcification du systme que l'on souhaite dvelopper, au niveau de dtails dsir. Une spcification formelle du systme est base sur un langage formel dont la smantique est bien dfinie (contrairement une spcification en langage naturel qui peut donner lieu diffrentes interprtations). Cette description formelle du systme peut tre utilise comme rfrence pendant le dveloppement. De plus, elle peut tre utilise pour vrifier (formellement) que la ralisation finale du systme (dcrite dans un langage informatique ddi) respecte les attentes initiales (notamment en termes de fonctionnalit). 1.3.3 Les preuves formelles Les mthodes formelles prennent tout leur intrt lorsque les preuves elles-mmes sont garanties correctes formellement. On peut distinguer deux grandes catgories d'outils permettant la preuve de proprit sur des modles formels :

La preuve automatique de thorme, qui consiste laisser l'ordinateur prouver les proprits automatiquement, tant donnes une description du systme, un ensemble d'axiomes et un ensemble de rgles d'infrences. Cependant la recherche de preuve est connue pour tre un problme non dcidable en gnral (en logique classique), c'est--dire que l'on sait qu'il n'existe (et n'existera jamais) aucun algorithme permettant de dcider en temps fini si une proprit est vraie ou fausse. Il existe des cas o le problme est dcidable (fragment gard de la logique du premier ordre par exemple) et o des algorithmes peuvent donc tre appliqus. Cependant mme dans ces cas, le temps et les ressources ncessaires pour que les proprits soient vrifies peut dpasser des temps acceptables ou les ressources dont dispose l'ordinateur. Dans ce cas il existe des outils interactifs qui permettent l'utilisateur de guider la preuve.

http://fr.wikipedia.org/wiki/Mthode_formelle_(informatique)

10

La preuve de thorme, par rapport au model-checking, a l'avantage d'tre indpendante de la taille de l'espace des tats, et peut donc s'appliquer sur des modles avec un trs grand nombre d'tats, ou mme sur des modles dont le nombre d'tats n'est pas dtermin (modles gnriques). Le modle checking, qui consiste vrifier des proprits par une numration exhaustive et astucieuse (selon les algorithmes) des tats accessibles. L'efficacit de cette technique dpend en gnral de la taille de l'espace des tats accessibles et trouve donc ses limites dans les ressources de l'ordinateur pour manipuler l'ensemble des tats accessibles. Des techniques d'abstractions (ventuellement guides par l'utilisateur) peuvent tre utilises pour amliorer l'efficacit des algorithmes.

1.3.4 Les systmes Multi-Agents Dans ce paragraphe, on rappelle les concepts dagent et de systme multi-agents qui sont rfrences dans ce mmoire. a. Agent Dans la plupart des rfrences bibliographiques lies aux systmes multi-agents, lagent est dfini comme une entit relle ou virtuelle, dont le comportement est autonome, voluant dans un environnement, quil est capable de percevoir, sur lequel il est capable dagir et interagir avec les autres agents [Demazeau et al, 1994]. Un agent est rarement considr de manire individuelle, il est gnralement intgr dans une socit voluant dans un environnement commun ou chaque agent communique directement ou indirectement avec ses partenaires pour satisfaire des objectifs communs ou une tche partage [Gaud, 2007]. De plus, un agent est une entit adaptative (elle pourra modifie son comportement, etc.), rationnelle, autonome, capable de communication et daction. b. Les systmes multi-agents La plupart des auteurs saccordent gnralement pour dfinir un systme multi-agents (SMA) comme un systme compos dagents qui communiquent et collaborent pour achever des objectifs spcifiques personnels ou collectifs. La communication implique lexistence dun espace partag support de cette communication. Cet espace est gnralement qualifi denvironnement. Daprs Ferber [Ferber, 1995], un Systme Multi-Agents est un systme compos des lments suivants :

Un environnement E, cest--dire un espace disposant gnralement dune mtrique. Un ensemble dobjets O. Ces objets sont situs, cest--dire que pour tout objet, il est possible, un moment donn, dassocier une position dans E. Ces objets sont passifs, cest--dire quils peuvent tre perus, crs, dtruits et modifie par les agents.
11

Un ensemble A dagents qui sont des objets particuliers (A O), lesquels reprsentent les entits actives du systme. Un ensemble de relations R qui unissent des objets (et donc des agents) entre eux. Un ensemble doprations Op permettant aux agents de A de percevoir, produire, consommer, transformer, et manipuler des objets de O. Des oprateurs chargs de reprsenter lapplication de ces oprations et la raction du monde cette tentative de modification, que lon appellera les lois de lunivers.

En gnrale, un SMA est une socit organise dagents dans laquelle un certain nombre de phnomnes peuvent merger comme la rsultante des interactions entre les agents. Cette notion dmergence est essentielle dans les SMA, car cest lune des proprits qui les rendent si aptes modliser les systmes complexes [Gaud, 2007]. 1.3.5 Les systmes Multi-Agents Holoniques a. Notion de holon Un holon est une entit auto-similaire compose des holons comme sous-structures. La structure hirarchique compose des holons est appele holarchie. Un holon peut tre vu, en fonction du niveau dobservation, tantt comme une entit atomique, tantt comme un groupe des holons en interaction. De la mme manire, un ensemble constitu de diffrents holons peut tre considr comme un ensemble dentits en interaction ou comme des parties dun holon de niveau suprieur [Gaud, 2007]. La figure 1 dcrit la notion de holon. un niveau dobservation donn, le holon compos est qualifi de super-holon. Les holons qui composent un super-holon sont appels sousholons ou holons membres.

Fig. 1 : Un holon compos de trois holons membres

12

Un holon est la fois un tout compos dautres holons, et une partie composante dun (ou plusieurs) holon de plus haut niveau. En cela, la notion de holon peut tre rapproche de celle dorganisation en tant que comportement part entire ou composante dun comportement de plus haut niveau. Ce parallle entre ces deux concepts facilitera dautant le processus dagentification du modle issu de la modlisation dun problme [Gaud, 2007]. b. Les Systmes Multi-Agents Holoniques Un SMAH est considr comme un SMA avec les agents qui sont considrs comme des holons. Daprs [Koestler, 1967], un holon est une entit auto-similaire, compos des holons comme sous-structures. Une holarchie est une structure hirarchique compose par des holons. La modlisation de la composition hirarchique entre les groupes dagents et de la structure gigogne qui en dcoule fait partie intgrante des systmes multi-agents holoniques. En fonction de la complexit des tches, les agents holoniques peuvent crer des hirarchies de composition de profondeur arbitraire [Koestler, 1967]. La gure 2 rsume la notion de holon telle quelle est considre dans les SMA. Les holons de niveau n sont regroups en organisation qui au niveau n+1 peuvent tre considrs comme des entits individuelles. Inversement des holons considrs comme des entits individuelles de niveau n + 1 peuvent tre considrs comme des organisations au niveau n. Ce processus de composition hirarchique peut tre ritr sur un nombre arbitraire des niveaux.

Fig. 2: Structure Holonique (gure inspire de [Ferber, 1995, p. 100])

13

1.3.6 Le mta modle CRIO (Capacit, Rle, Interaction, Organisation) Cest un mta-modle organisationnel qui fournit les abstractions ncessaires pour dcrire la dcomposition hirarchique dun systme complexe en un nombre quelconque de niveaux dabstraction. CRIO est destin la modlisation des systmes complexes ouverts et de grande chelle. Le mta-modle CRIO est issu de lintgration et lextension de deux mtamodles existants. Le premier RIO a t propos dans [Hilaire, 2000] et fut conu pour la modlisation organisationnelle des systmes multi-agents non hirarchiques. Le second est le FrameWork gnrique pour la modlisation des systmes multi-agents holoniques propos dans [Rodriguez, 2005]. RIO tire son nom des trois principaux concepts sur lesquels il repose : Rle, Interaction, et Organisation. CRIO, quant lui prcise et redfinit certains des concepts prcdemment introduits dans RIO et leur adjoint celui de Capacit. Le mta-modle CRIO [Gaud, 2007] cherche exploiter les proprits hirarchiques des systmes complexes pour les analyser et les modliser. Il adopte une approche organisationnelle dont la notion de comportement est labstraction qui en constitue sa base. CRIO offre trois niveaux de modles. Chacun de ces trois modles est qualifie de domaine : Le domaine de Problme, il donne la description de l'organisation du problme indpendamment d'une solution spcifique. Les concepts introduits dans ce domaine sont principalement utiliss pendant la phase d'analyse et au dbut de la phase de conception. Le domaine dagentification, introduit les concepts de multi-agent et fournit une description dune solution multi-agents, ventuellement holonique, base sur un raffinement des lments du domaine du problme. Le domaine de la solution, est relatif la mise en uvre de la solution sur une plateforme spcifique. 1.3.7 Le Processus ASPECS (Agent-oriented Software Process for Engineering Complex Systems) Le mta-modle ASPECS, propos dans [Gaud, 2007], fournit les abstractions et la philosophie utilises pour modliser un problme et sa solution. Le processus dcrit les tapes suivre pour obtenir cette solution. Les rsultats intermdiaires, associs chacune des tapes, doivent galement tre dcrits. ASPECS fournit les moyens ncessaires pour dcomposer un systme complexe, niveau par niveau, et tudier les relations entre eux. Diffrents points de vue peuvent tre adopts pour dcrire un systme, ASPECS tente galement de les intgrer dans la conception dun modle unique. ASPECS est un processus dingnierie logicielle qui dcrit pas pas les tapes suivre pour le dveloppement des logiciels, depuis lanalyse des besoins jusqu la production du code et au dploiement de celui-ci sur une plate-forme spcique. Il est bas sur le mtamodle CRIO qui dnit les principaux concepts pour lanalyse, la conception et limplantation des systmes multi-agents holoniques [Cossentino et al, 2009].

14

Le cycle de dveloppement dASPECS est compos des quatre phases dcrites cidessous : 1. Lanalyse des besoins : vise fournir une description organisationnelle du systme (dcomposition hirarchique du systme). Elle doit galement collecter les connaissances disponibles sur le domaine du problme et les organiser au sein dune ontologie. 2. La conception dune socit dagents : cherche construire le modle dun SMA, dont le comportement global doit tre en mesure de fournir une solution au problme dcrit dans la phase prcdente. Les connaissances sur le systme sont affenes et intgrent les lments spciques la solution propose. 3. Limplantation de la solution : dcrit larchitecture des holons impliqus dans la solution et doit fournir le code source de lapplication. 4. Le dploiement de la solution constitue la phase finale en charge du dploiement de lapplication sur la plate-forme choisie. ASPECS fournit un guide complet, depuis lanalyse des besoins jusqu limplantation et au dploiement, permettant la modlisation dun systme diffrents niveaux de dtails, en procdant par raffinements successifs. Elle adopte lapproche holonique qui offre la possibilit au concepteur de modliser un systme avec des entits de granularits diffrentes. Il peut ainsi rcursivement dcomposer un systme en sous-systmes, jusqu atteindre un niveau o la complexit des tches demandes est suffisamment faible, pour tre excute par des entits considres comme atomiques et faciles implanter. ASPECS utilise UML comme un langage de modlisation. An de pleinement satisfaire les objectifs et les besoins spciques lapproche oriente-agent, la smantique et les notations dUML ont t tendues, et de nouveaux proles UML ont notamment t introduits. AGR Hierarchies Holarchies o Coalitions o Teams Congregations o Societies o Federations Markets Ext.Gaia Moise+ o o o o o o o o o o o MaSE o o o OperA o o o o o o o INGENIAS ASPECS o o o o o o o

Tableau 1 : les modles organisationnels dans les mthodologies d'analyse.

Concernant l'analyse des structures sociales, certaines conclusions peuvent tre nonces pour chaque mthode prsente dans le tableau 1. Les mthodologies les plus complets sont ASPECS et MaSE, supportant les structures complexes organisationnelles telles que Holarchies, dans lequel les agents sont rcursivement organiss en auto-rgul des structures appeles holons. Cependant ASPECS supporte les Holarchies d'une manire plus naturelle en diffrenciant clairement chaque niveau d'abstraction de l'organisation (les holons, sub-holons,
15

des groupes, des agents), alors que MaSE soutient une dfinition rcursive des organisations [Isern et al, 2011]. Hirarchies (considr comme simple holarchies) sont galement supporter par d'autres mthodes (AGR, Ext.Gaia et INGENIAS) en d'associant les agents en groupes. Cependant, seul INGENIAS sappuie sur la dfinition des hirarchies avec plusieurs niveaux de profondeur. Dans les deux autres cas (AGR, Ext.Gaia), la profondeur de la hirarchie est limite la dfinition des groupes d'agents [Isern et al, 2011]. Coalitions, teams et congrgations sont des structures sociales similaires, diffrencis par la possibilit de soutenir la communication inter-agent (uniquement pour le cas des quipes). La plupart des mthodes indiquant explicitement la notion de groupe d'agents (ou une notation alternatives telles que les holons ou sous-organisations), pour le soutien de ces trois structures, seul AGR ne supporte pas la dfinition de communication inter-agent, qui se traduit par le fait que les quipes ne peuvent pas tre directement modliss [Isern et al, 2011]. Moise+ et OperA restent comme les modles les moins flexibles du point de vue social. Cependant, OperA est la seule mthode qui supporte explicitement la structure de la socit, dfini comme un ensemble d'agents dpendants sur un contrat social [Isern et al, 2011]. Fdrations et markets sont des cas particuliers des quipes et des coalitions dans lesquelles les agents jouent des comportements concrets (par exemple, les vendeursacheteurs). Dans ces cas, la mthode doit soutenir spcifiquement les rles d'agent (comme INGENIAS) alors que dans d'autres cas, les agents doivent tre explicitement mis en uvre [Isern et al, 2011]. Un autre aspect qui influence considrablement les capacits de modlisation des mthodes en ce qui concerne les structures sociales et linteraction entre agents [Isern et al, 2011]. La communication est une caractristique trs importante et de diffrenciation des agents l'gard de paradigmes d'autres logiciels. Comme indiqu plus haut, dans les mta-modles, l'interaction dagent est gnralement reprsente par le biais d'associations. Selon l'origine et la destination d'une association et sa cardinalit, le processus de communication est dfini entre des agents individuels (comme dans Ext.Gaia, INGENIAS ou MaSE) ou aussi entre les organisations (comme dans Ext.Gaia ou ASPECS). Cet aspect dtermine si la communication dagent est autoris entre les diffrentes structures organisationnelles (telles que des groupes ou les holons) ou si elle est limite au commerce intra-agent de communication [Isern et al, 2011]. 1.3.8 Janus : une plate-forme organisationnelle pour limplantation et la simulation de systmes complexes

La plate-forme Janus est spcifiquement ddie limplantation de systmes multi-agents holoniques. Le mta-modle de cette plate-forme sintgre dans le troisime et dernier domaine du mta-modle CRIO : le domaine de la solution. An de faciliter la transition entre
16

la phase de conception et la phase dimplantation, le mta-modle de Janus dnit un ensemble de concepts relativement proches de ceux introduits dans le domaine dagent de CRIO [Gaud, 2007]. Lobjectif poursuivi de la plate-forme Janus est, terme, de faciliter le transfert de la technologie multi-agents et lutilisation des approches organisationnelle et holonique dans le cadre de projets industriels. [Dastani et al, 2005] considrent que les applications multi-agents ne pourront effectivement convaincre les industriels que si le foss qui spare, dune part, lanalyse et la conception des SMA et, dautre part, leur implantation est combl.

1.4 Plan du mmoire

Suivant les objectifs dgags au paragraphe 1.2, nous avons organis ce mmoire en quatre parties. La premire partie (chapitre 1 et 2) dresse un tat de lart sur la spcification formelle, les preuves formelles et les systmes multi-agents holoniques. Ainsi le chapitre 2, on prsentera quelques langages formels. La deuxime partie (chapitre 3 et 4) prsente les formalismes que nous avons utilise ainsi notre approche de composition de rseau de Petri et Object-Z. La troisime partie (chapitre 5) est consacre notre squelette de spcification du systme multi-agent holonique. La quatrime partie (chapitre 6) traitera un exemple pour valider notre approche de spcification et son implmentation et dploiement sur la plate-forme Janus.

17

CHAPITRE 2

LANGAGES FORMELS
2.1 Introduction
Les approches formelles en gnie logiciel sont arrives un certain degr de maturit et un cot raisonnable pour toutes les classes dapplications. Elles ont trouv leurs champs dutilisation dans un domaine du logiciel : celui des applications enfouies dites critiques, car industrielle mais ne peuvent pas tre considres comme des approches universellement praticables, utilisables soumises des proprits impratives de sret de fonctionnement. Ce sont des applications dont un dfaut de conception pourrait se traduire par une faille de fonctionnement, avec des pertes humaines et/ou matrielles. Les approches formelles sont incontournables dans ce domaine, car elles donnent la possibilit de prouver, au sens dune preuve mathmatique, que le modle formel dune application satisfait en toute circonstance une proprit donne. Dans de nombreux contextes (scientifique, etc.), on dsigne par langage formel un mode d'expression plus formalis et plus prcis (les deux n'allant pas ncessairement de pair) que le langage de tous les jours (voir langage naturel). En mathmatiques, logique et informatique, un langage formel est form : d'un ensemble des mots obissant des rgles logiques strictes (dites grammaire formelle ou syntaxe). d'une smantique. Le prsent chapitre dcrit les aspects du domaine formel, dans le but dintroduire les notions appliques par la suite et de justifier certains choix.

2.2 Systmes formels, vrification, preuve, model-checking

Un systme formel est un ensemble de formules, ou expressions formelles, que lon peut interprter. Ils sont des ensembles fondamentaux pour la logique et les mathmatiques. Un systme formel est souvent construit en se donnant un ensemble d'axiomes et en raisonnant partir de ces axiomes l'aide de la logique usuelle. Par exemple, la thorie axiomatique des ensembles est un systme formel. Rappelons qu'un axiome est une proposition non dmontre qui sert de point de dpart un raisonnement. Une spcification peut tre utilise comme base pour prouver des proprits sur le systme. La spcification est le plus souvent une reprsentation abstraite (avec moins de dtails) du systme en dveloppement : dbarrass de dtails encombrants, il est en gnral plus simple de prouver des proprits sur la spcification que directement sur la description complte et concrte du systme. Certaines mthodes, comme la Mthode B, s'appuient sur ce
18

principe : le systme est modlis plusieurs niveaux d'abstraction, en partant du plus abstrait et en allant au plus concret (ce processus est appel raffinement puisqu'il ajoute des dtails au fur et mesure); la mthodologie assure que toutes les proprits prouves sur les modles abstraits sont conserves sur les modles concrets. Cette garantie est apporte par un ensemble de preuves dites de raffinement. Les mthodes formelles prennent tout leur intrt lorsque les preuves elles-mmes sont garanties correctes formellement. On peut distinguer deux grandes catgories d'outils permettant la preuve de proprit sur des modles formels : La preuve automatique de thorme, qui consiste laisser l'ordinateur prouver les proprits automatiquement, tant donnes une description du systme, un ensemble d'axiomes et un ensemble de rgles d'infrences. Le model checking, qui consiste vrifier des proprits par une numration exhaustive et astucieuse (selon les algorithmes) des tats accessibles. L'efficacit de cette technique dpend en gnral de la taille de l'espace des tats accessibles et trouve donc ses limites dans les ressources de l'ordinateur pour manipuler l'ensemble des tats accessibles.

2.3 Quelques langages formels

2.3.1 Z et Object-Z Il sagit dun langage de spcification formelle dont la notation sinspire de la formalisation de la thorie des ensembles et de la logique du premier ordre. Z est un langage fortement typ : tout composant dune spcification Z possde un type, et donc peut tre associ un ensemble de valeurs. Z se prsente sous la forme dun langage et dun calcul des schmas. Le schma, unit de spcification de Z, encapsule une partie dclaration et une partie contrainte, comme le montre lexemple suivant :

Ce schma peut tre facilement interprt comme la dfinition prdicative dun ensemble, {(couleurs, passeurs) Etudiants2 | couleurs passeurs = couleurs passeurs= Etudiants} qui est justement le type du schma Classe. Le prdicat "couleurs passeurs = couleurs passeurs = Etudiants" est la partie contrainte du schma. Lexemple prsente un schma dtat, o des variables sont dclares avec des contraintes. La contrainte dun schma dtat est un invariant du modle. Ainsi, les proprits de sret qui pourraient tre associes au modle de spcification Z apparatraient comme des contraintes dans des schmas dtat. En plus des schmas dtat dautres types de schmas sont prsents : Doprations, de dfinition, ces
19

derniers peuvent tre de diffrents sous-types : ouverts, constants, gnriques. Les oprations sont dfinies par des schmas spcifiques. Elles dcrivent des changements dtat, c'est--dire des changements de valeur affectant une ou plusieurs variables. Ainsi, par exemple, le schma :

prsente une opration Ajouter_livre qui change les attributs de la classe Bibliotheque. Le paramtre dentre nouveau_livre? contient lincrment de cette valeur. Le principal intrt de Z rside dans sa richesse expressive, donne par un large ventail de constructeurs de types : ensemble, produit cartsiens, fonctions et relations, squences, types rcursifs, etc. A chaque constructeur sont associes des oprateurs. En arrire-plan, une thorie constitue daxiomes et de rgles de dduction prpare le terrain pour la vrification par la preuve. Le formalisme Object-Z [JTocher, 2007] donne un objet Z en permettant dencapsuler lensemble des schmas qui constituent le modle de spcification dun systme, dans un schma de classe. Toutes les variables dtat sont dclares et contraintes dans un schma anonyme dit schma dtat. Les contraintes de ce schma sont les invariants dtat de la classe. Une opration standard dinitialisation dcrit lensemble dtats initiaux possibles pour la classe. En outre, comme correspond tout formalisme de type objet, Object-Z propose des mcanismes pour lagrgation et lhritage. Si Z ninclut aucune construction pour dcrire le comportement dun modle, Object-Z peut inclure, dans la partie contrainte du schma de classe, une formule de la logique temporelle linaire, linvariant temporel du la classe qui exprime dventuelle restrictions sur lenchainement des oprations de la classe au cours du temps. Cet invariant dit temporel ne doit pas tre confondu avec linvariant dtat lequel, comme nous lavons dit, est un prdicat sans oprateur temporel, qui apparat dans la partie contraintes du schma dtat. Z et Object-Z, dont les notations se basent sur la formalisation de la logique du premier ordre, sont adapts la vrification par la preuve. En particulier, les proprits sret de fonctionnement, qui comme nous lavons dit, sintgrent facilement sous la forme dinvariants dtat, peuvent tre prouvs inductivement : prouver que lensemble dtats initiaux satisfait linvariant

20

pour chaque opration Op, prouver que si ltat immdiatement avant Op satisfait linvariant, alors ltat immdiatement aprs Op le satisfait aussi.

Malgr la place faite la logique, aucun environnement daide la preuve pour Z ou Object-Z nest arriv une maturit considrable. 2.3.2 La mthode B La mthode B [Abrial, 1996], ne dune volution du langage Z, appartient, comme ce dernier, la famille des formalismes bass sur la notation formelle de la logique et de la thorie des ensembles. Lvolution par rapport Z consiste particulirement en ladaptation des substitutions gnralises comme formalisme de description des transformations opres sur les donnes. Une substitution est un transformateur de prdicats. Si P un prdicat et Sop la substitution qui dcrit lopration op, alors on note [Sop]P le prdicat qui rsulte de lapplication de Sop P. Il a t prouv que le prdicat [Sop]P est la plus faible pr-condition que doit satisfaire un tat du systme auquel on applique lopration op, pour que ltat en rsulte satisfasse P. La preuve de proprits relatives aux oprations dun systme sinscrit ainsi dans une stratgie de dduction base sur le concept de plus faible pr-condition, ce qui en augmente lefficacit et le degr dautomaticit. Lautre volution par rapport Z consiste en lintroduction dune unit de spcification bien structure, la machine abstraite. Mais Z avait aussi marqu, avec Object-Z, une volution dans le sens dune structuration. Au cur de la mthode B il y a un langage, lAbstract Machine Notation (AMN). La mthode B inclut aussi un mcanisme de raffinement permettant de concevoir en allant de labstrait vers le concret, pour obtenir une spcification dite concrte, proche dun programme. Dautre part, la mthode B possde plusieurs mcanismes de structuration qui favorisent la modularit et la rutilisation. Un modle B est compos dun ensemble de machines abstraites lies mutuellement, suivant un certain nombre de relation. Une machine abstraite est constitue dune srie de sections. Une section peut contenir soit une liste didentification (section SETS, CONSTANTS, VARAIBLES), soit un prdicat (sections CONTRAINTS, PROPERTIES, INVARIANT), soit des substitutions (sections INIALISATION, OPERATIONS). Considrons le simple exemple suivant, dans lequel on na pas spcifi toutes les sections mentionnes ci dessus.

21

La mthode B introduit demble la notion de consistance dune machine abstraite. A chaque section contenant un prdicat ou des transformateurs des prdicats sont associes des obligations de preuve : des prdicats que la machine abstraite doit satisfaire. Une machine abstraite est consistance si elle satisfait toutes les obligations de preuve quelle produit. La mthode B est, parmi les approches formelles, celle qui a atteint le plus haut niveau de maturit technologique. En effet, deux environnement de niveau industriel sont disponible, Atelier-B et B-core, qui offrent lensemble doutils ncessaire au droulement de projet denvergure : gestionnaires de projet, diteurs, outils de preuve et danimation, gnrateur dobligation, gnrateur de code. La preuve est oriente vers linvariance, qui englobe les proprits de sret, qui nous intresse ici. Du ct des limitations, nous pouvons mentionner la prise en compte relativement basique des aspects comportementaux et labsence de types prdfinis correspond aux valeurs numriques relles. En ce qui concerne le premier aspect, li au comportement, il existe dsormais une variante de la mthode B, appele Event-B qui inclut la notion dvnement sous la forme dun type dopration. Il est, ds lors en principe possible de modliser des comportements par des machines abstraites qui reprsentent des automates dtat fini. La deuxime limitation, linexistence de type numrique rel, prend une importance non ngligeable lorsquil sagit de modliser des systmes qui comportent des aspects physiques ou inspirs par la physique. 2.3.3 Les rseaux de Petri Le rseau de Petri est un outil trs puissant pour la modlisation et lanalyse de systme. Le rseau de Petri est un outil graphique et mathmatique qui permet de modliser et analyser les systmes discrets, particulirement les systmes concurrents, parallles, non-dterministes, etc. En tant rle doutil graphique, il nous aide comprendre facilement le systme modlis, et plus il nous permet de simuler les activits dynamiques et concurrentes. Avec le rle doutil mathmatique, il nous permet danalyser le systme modlis grce aux modles de graphes, aux quations algbriques, etc.
22

En gnral, les mthodes de ltude de systme par rseau de Petri se composent 3 tapes : premirement on rcrit le systme en terme de rseau, on obtient le modle en rseau ; deuximement on analyse le modle obtenue, on dduit des proprits comme absence de blocage, existence dune solution, etc. ; finalement on fait la rvision des proprits obtenues pour montrer si le systme est bon. Le rsultat de cette mthode nous indique une analyse qualitative des systmes. Elle est une approche trs importante pour avoir une bonne valuation des systmes. Informellement, le rseau de Petri est un graphe biparti ayant 2 types des nuds. Les transitions reprsentent les actions lmentaires du systme, et les places reprsentent ses ressources.

2.4 Conclusion
Dans ce chapitre, nous avons prsentes les aspects du domaine formel ainsi que quelques langages formels: Z/Object-Z, la mthode B et les rseaux de Petri. La mthode B : la maturit technique de ce langage/mthode et des outils associs, les placent parmi les plus aptes a-priori dans la perspective dune approche formelle pour nos travaux. Dautant plus que la preuve de proprits de sret se fait en B de faon naturelle, par technique inductive de preuve des invariants. Comme nous lavons signal, le langage B ne possde pas en forme native, une reprsentation ou formalisation des nombres rels. Ds lors, elle peut tre applique la modlisation de systmes qui incluent des variables de ce type, au prix dune discrtisation des dites variables et une simplification des modles. Dans ces conditions, la confiance que lon puisse attribue aux rsultats de la vrification est en relation inverse avec la distance entre le modle et la ralit. Object-Z : permettant dencapsuler lensemble des schmas qui constituent le modle de spcification dun systme, dans un schma de classe. Object-Z, dont les notations se basent sur la formalisation de la logique du premier ordre, sont adapts la vrification par la preuve. En particulier, les proprits de sret de fonctionnement, qui comme nous lavons dit, sintgrent facilement sous la forme dinvariants dtat et peuvent tre prouvs inductivement. Les rseaux de Petri : nous aide comprendre facilement le systme modlis, et plus il nous permet de simuler les activits dynamiques et concurrentes. Avec le rle doutil mathmatique, il nous permet danalyser le systme modlis grce aux modles de graphes, aux quations algbriques, etc. Object-Z / Rseau de Petri et SAL : Dans ce mmoire, on a opt pour la composition de deux outils formel (RdP et Object-Z). Nous avons ainsi combin les facilits dObject-Z et rseaux de Petri en tant que des langages pour la construction des spcifications formelles structurelle et comportementale, avec la richesse de la boite outils SAL en termes de modelchecking. SAL inclut lui-mme un langage orient vers les systmes de transition, nous avons prfr conserver Object-Z et rseau de Petri parce quils produisent des modles plus lisibles. Dautre part, la traduction de ces formalismes vers SAL ne prsente pas de difficult majeure.
23

DEUXIEME PARTIE

Langage de spcification multi-formalismes

24

CHAPITRE 3

DEUX FORMALISMES COMPLEMENTAIRES : LES RESEAUX DE PETRI ET OBJECT-Z

3.1 Introduction Notre objectif premier est de spcifier des systmes multi-agents holoniques ainsi que leurs vrifications. Ce type de systme prsente des aspects aussi bien structuraux que comportementaux qui peuvent tre assez complexes. Pour rpondre ces besoins, nous avons opts pour la composition de deux langages formels, les rseaux de Petri et Object-Z. Dans ce qui suit, nous allons introduire ces deux formalismes. Nous commenons par prsenter quelques lments essentiels de leurs syntaxes, Puis, ainsi que la smantique associe une spcification crite avec lun et lautre des formalismes. Nous introduisons dabord le formalisme des rseaux de Petri, ensuite, nous dfinitions le langage Object-Z. 3.2 Les rseaux de Petri Le rseau de Petri est un modle mathmatique servant reprsenter divers systmes (informatiques, industriels, etc.) travaillant sur des variables discrtes ou continues. Ils ont t cres au dernier sicle dans les annes soixante par Carl Adam Petri (1962) pour tudier des systmes dynamiques complexes. Les rseaux de Petri furent ensuite dvelopps au MIT et appliqus dans de nombreux domaines. Cette technique de modlisation est aujourdhui lune des principales utilises pour des analyses la fois qualitatives et quantitatives de processus dans lesquels des informations, des documents ou des tches sont transmises dun individu un autre, lensemble du systme voluant vers une nouvelle phase chaque tape. Parmi lensemble des modles existants, les rseaux de Petri et leurs extensions possdent un intrt fondamental indniable: ils ont fourni les premires approches de modlisation utilises pour matriser les comportements des systmes parallles et distribus, synchroniss et communicants. Les fondements mathmatiques de ces modles sont trs robustes. De plus, ils reposent sur un support graphique ais pour lexpression et la comprhension des mcanismes de ces comportements, permettant des reprsentations faciles comprendre. Ils possdent un grand intrt dans de trs nombreux et importants domaines dapplications [Mazigh, 1994]. Les rseaux de Petri ont t utiliss dans de nombreuses recherches, particulirement dans les domaines suivants : recherche oprationnelle, informatique, systmes dinformation mais aussi science des organisations.

25

Les rseaux de Petri peuvent tre utiliss pour modliser et simuler des systmes de tout type. Ils sont en particulier trs utiles pour dcrire et analyser des systmes dynamiques complexes qui comportent des flux dinformations. Ces modles permettent de reprsenter des systmes dynamiques, cest--dire des systmes voluant dun tat un autre la suite dvnements internes ou externes. 3.2.1 Concepts propres aux rseaux de Petri Un rseau de Petri est constitu des composantes structurelles suivantes : Les places : notes graphiquement par des cercles ; lensemble de ces places constituer ltat du RdP complet lie au jetons (conditions). Les transitions : notes graphiquement sous forme de barres ou de rectangles. Elles dcrivent les vnements qui modifient les tats du systme ; des temporisations peuvent tre associes ces transitions reprsente par des variables alatoires voir dterministes. Les arcs : nots par des flches qui joignent les places aux transitions et inversement. Ils constituent les connecteurs entre une place et une transition dans un sens dtermin; Une distribution de jetons dans les places, traduit la dynamique du systme puisque les jetons se propagent dans le rseau en fonction du dclenchement des transitions (lies aux vnements qui surviennent).

Fig. 3 : Modle du Rseau de Petri

3.2.2 Concepts et dfinitions Lensemble des dfinitions prsentes dans ce paragraphe ont t repris de [Diaz, 2001].
Dfinition 1 :

Un rseau de Petri Places-Transitions R se dfinit sous forme dun tuple : (P, T, Pre, Post, M0)
26

avec : 1) P= {p1,, pi,, pn} est lensemble des places, quelquefois notes pi, pi ou p; 2) T = {t1, , ti, , tn} est lensemble des transitions, avec P T = , quelquefois note ti, ti ou t ; 3) Pre = P T N, une application dincidence avant o Pre(p, t) contient la valeur entire n associe larc allant de p t . 4) Post = P T N, une application dincidence arrire o Post(p, t) contient la valeur entire n associe larc allant de t p . propos des places : p est une place dentre de la transition t si Pre(p, t) > 0 p est une place de sortie de la transition t si Post(p, t) > 0

5) M0 est le marquage initiale du rseau, avec M0 0.

Dfinition 2 :

Le marquage dun RdP est une application M : P N donnant pour chaque place le nombre de jetons quelle contient. Le marquage initial sera not M0 et M(p) indique le marquage de la place p .
Dfinition 3 :

Le fonctionnement dun RdP se dfinit comme suit. Pour un marquage M , une transition t est dite tirable (ou franchissable ou sensibilise) si et seulement si

pi P, on a M(pi) Pre(pi, t)

(1)

cest--dire, pour toutes les places pi , entres de t , le nombre de jetons dans pi, M(pi) est suprieur ou gal au poids de larc allant de p t . Quelques notations supplmentaires : Le fait que t est tirable depuis M se notera : M[t. Le tir de t depuis M donnant le nouveau marquage M se notera : M[tM.

Dfinition 4 :

Dans le rseau de Petri place-transitions, toute transition tirable t peut tre tire (ou franchie) et son tir (ou franchissement) conduit son nouveau marquage M dfini, pour tout p, par : M(p)=M(p) - Pre(p, t) + Post(p, t) (2) La rgle de tir, lie {M, Pre, Post}, signifie que le nouveau marquage M(p) sera obtenu, partir du marquage prcdent M(p), en supprimant dabord, dans les places dentre
27

de t, le nombre de jetons indiqu sur les arcs entrants de t, par Pre(p, t), et en ajoutant ensuite, chaque place de sortie p de t, le nombre de jetons correspondant au poids indiqu sur larc sortant de t vers p, par + Post(p, t).
Dfinition 5 :

Lensemble des marquages accessibles ou ensemble daccessibilit, A(R, M0) ou A, se dfinit par le plus petit ensemble : M0 A et si M A et M[tM alors M A (3)

Lensemble A dfinit lensemble des marquages accessibles par une squence.

Dfinition 6 :

Le graphe des marquages accessibles G(R, M0) (ou graphe daccessibilit) est dfini comme le graphe dont les nuds sont les marquages accessibles de A(R, M0) et dont les arcs, tiquets par les noms des transitions, sont dfinis par la relation de tir entre les marquages. Pour M, M A, on a M t M G si et seulement si M[tM. Donc, si M[tM, alors la transition t tiquete larc de G qui transforme le marquage de dpart M en le marquage darrive M. 3.2.3 Proprits usuelles
Dfinition 7 :

Une place pi est dite k-borne par un marquage initial M0 sil existe un entier naturel k, tel que pour tout marquage accessible partir de M0, le nombre de marque dans pi est inferieur ou gale k (on dit que pi est k-borne).
Dfinition 8 :

Un RdP (ou PN pour Petri Net) est born par un marquage initial si toutes les places sont bornes par M0 (le rseau est borne si toutes les places sont k-bornes).

PN est k-borne si p est k-borne, pour tout places p PN. PN est sauf sil est 1-borns.

Dfinition 9 :

Une transition t est vivante par un marquage initiale M0 si pour tout marquage accessible M *M0 (*M0 : ensemble des marquages accessibles partir de M0). Il existe une squence de franchissement S qui contient la transition t, partir de M. Autrement dit, quelle que soit lvolution, il subsistera toujours une possibilit de franchir t.
Dfinition 10 :

Un RdP est vivant pour un marquage initial M0 si toutes ses transitions sont vivantes pour M0.

28

Dfinition 11 :

Un blocage (ou tat puits) est un marquage tel quaucune transition nest valide.
Dfinition 12 :

Un RdP est dit sans blocage si ti, squence de franchissement S passant par ti.
Dfinition 13 :

Un RdP possde un tat daccueil Ma pour un marquage initial M0 si pour tout marquage accessible Mi il existe une squence S telle que Mi[SMa.
Dfinition 14 :

Un RdP est rinitialisable (ou rversible) pour un marquage initial M0 si M0 est un tat daccueil. 3.2.4 Smantique des Rseaux de Petri Le principe gnral de la smantique est bas sur la description de lvolution du systme. Cette volution peut tre vue comme une suite de configuration et de pas. Chaque configuration est une situation du systme, constitue par un ensemble dtats actifs et une valuation des variables. La premire configuration est constitue par des tats par dfaut des rseaux de Petri spcifiant le systme. Chaque configuration est ensuite obtenue partir de la configuration prcdente par lexcution dun pas. La smantique dun RdP T = (P, T, Pre, Post, M0) est un systme de transitions temporis ST = (Q, q0, ) avec : Q = NP (R0)n, avec n =| T | ; (R0)n est une valuation telle que la valeur i reprsente le temps coul depuis le dernier instant o la transition ti a t sensibilise. q0 = (M0, 0), Q(T R0) Q est la relation de transition compose des transitions discrtes et continues [Franck et al, 2003].

3.3 Le langage Object-Z

La notation Z est un langage de spcification utilis pour dcrire et modliser les systmes informatiques. Un inconvnient de Z et de certains langages orients modle est la sparation des types/donnes et des oprations qui les manipulent. Le paradigme des langages Objets offre une solution intressante pour pallier ce problme. Des formalismes de spcification orients objets ont donc suivi lapparition de tels langages [Smith, 2000]. Nous avons choisi dutiliser Object-Z car il semble le plus mature que dautres langages. Sa syntaxe est proche dun langage orient objets classe. Le processus de raffinement
29

incrmental est vu comme une hirarchie de classes. De plus, des schmas ainsi constitus prsentent lavantage de factoriser les spcifications et donc dtre plus concis et plus clair dans le contexte dun grand projet. On peut galement prendre en compte le fait quavec Object-Z laboutissement de code dans un langage orient objet est plus direct [Smith, 2000]. 3.3.1 La Syntaxe dObject-Z Comme les spcifications en Z, les spcifications en Object-Z sont organises sous forme de schmas (en fait des schmas de classes). Par la suite, nous prsentons la syntaxe gnrique dune classe et un exemple de spcification. 3.3.1.1 Syntaxe dune classe La syntaxe du langage Object-Z est hrite du langage Z. Elle est base sur le principe de schmas reprsents par des boites. Dans le cas dObject-Z, lunit de construction est la classe qui est un schma nomm (figure 4) qui contient dautres schmas. Ces schmas spcifient respectivement lespace dtats de la classe, ltat initial de la classe et les oprations (un schma par opration). Au sein de chaque schma, la notation utilise est la notation ensembliste de Z.

Fig. 4 : Syntaxe dune classe Object-Z

La liste de visibilit introduit un ensemble de variables et doprations accessibles par dautres classes. Cette liste permet de rduire laccs une partie de la classe et procure un moyen dabstraction utile notamment pour viter le renommage lors de conflits de nom. Lorsque la liste de visibilit est absente toutes les variables et oprations de la classe sont visibles. Le langage Object-Z utilise la notion dhritage de classes. Une classe hrite des dfinitions dune ou plusieurs classes dsignes par superclasses. A ces dfinitions une classe peut ajouter des types, constantes, un schma dtat qui introduit les variables caractrisant la
30

classe et leurs valeurs initiales (schma INIT) ainsi que des schmas doprations qui manipulent les types, constantes et les variables de la classe. Lhritage des dfinitions dune classe A par une classe B est la conjonction des dfinitions de A et B. On peut ainsi ajouter des contraintes ltat ou aux oprations dune classe ou introduire de nouvelles dfinitions. Linvariant historique (history invariant) est une partie optionnelle dans la classe ObjectZ. Gnralement, il reprsente les prdicats temporaux qui entravent le comportement aux objets de la classe. 3.3.1.2 Exemple La figure 5 reprsente la spcification des oprations qui peuvent tre effectus par la carte de crdit associ un compte bancaire. Toutes ces figures dans cette section sont des imprims dcran de loutil JEdit (utilis pour dessiner les classes Object-Z.

Fig. 5 : Schma Object-Z du classe CreditCard

31

La liste de visibilit (Visibility List), numre les parties, et/ou les fonctionnalits, de la classe qui sont visibles lenvironnement contenant un objet CreditCard comme indiqu cidessus.

Dans le langage Object-Z, la liste de visibilit dfinit l'interface de la classe. Si la liste de visibilit est omise, toutes les fonctionnalits de la classe sont visibles par dfaut. Les constantes de classe : sont spcifies par un schma ouvert, ou une dfinition axiomatique.

Cette structure typique de langage Z est constitue d'une liste de dclarations (au-dessus de la ligne), et une liste dexpressions en logique de prdicats du premier ordre (en-dessous de la ligne). Dans l'exemple, la variable limite est dclare comme un entier naturel, et elle pourrait prendre lune des valeurs de l'ensemble {1000, 2000, 5000}. Schma d'tat ou State schema : cest une boite anonyme ferme.

Il suit exactement le mme modle que le schma des constantes, avec des dclarations et des prdicats. Cette fois-ci, les attributs dclars correspondent aux variables de classe, et les prdicats correspondent aux class invariants. Dans l'exemple, la seule variable est le nombre entier, balance. L'invariant prcise que balance + limit doit tre suprieure ou gale zro (c'est--dire que balance ne peut pas tre plus ngatif que limit. Lobjet CreditCard doit satisfaire cette condition avant et aprs chaque opration. Initial state schema : est un autre schma, contenant seulement des prdicats et toujours nomm INIT.

Le prdicat du schma INIT doit tre vrai pour tous les objets dans leurs premiers tats de dparts (c'est dire aprs leurs cration et avant qu'ils n'aient subi aucunes oprations). Le

32

schma initial de l'exemple spcifie que tous les comptes des cartes de crdit ont un solde d'ouverture et il est bien vide (gale zro). Les schmas restants dans la spcification de la classe CreditCard sont des schmas qui spcifiant les oprations :

Les schmas des oprations permetent de dfinir des mcanismes pour que les objets changent d'tat. La partie dclaration du schma commence par une delta list, note (balance). La liste delta montre tous les attributs de classe qui vont tre modifis par le schma. Tous les attributs qui ne figurent pas dans la liste delta restent inchangs lorsque l'objet subit une opration. Aprs la liste delta, vient la dclaration de toutes les entres ou sorties (les entres sont dcores avec un "?" et les sorties avec un '!'). 3.3.2 Smantique de trace et invariants temporels La smantique associe une classe Object-Z est base sur le fait quune classe est un type. On peut instancier une classe, en affectent des valeurs lensemble des attributs qui constituent cette dernire. Lensemble de ces valeurs dfinit ltat dun objet instance de la classe. Le changement dtat dun objet est produit par le changement dune au moins des valeurs de ses attributs. Ce changement dtat ne peut se faire que par une opration dfinie au sein de la classe. Formellement, il doit y avoir une relation entre les tats dun objet. Cette relation dcrit lvolution travers le temps dun objet. On peut voir cette relation sous forme dun diagramme dtat. Les tats du diagramme sont les valeurs des attributs de lobjet et les transitions sont tiquetes par les oprations applicables chaque tat. Les invariants temporels dune classe portent sur cette relation. Ce sont donc des prdicats qui conditionnent lvolution dun objet, cest--dire les suites des oprations et dtats savoir les associations attributs valeurs.

33

3.4 Conclusion Dans ce chapitre on a prsent les rseaux de Petri et Object-Z et qui sont la base de notre approche de spcification multi-formalismes. Nous les avons prsents de manire spare, permettant ainsi danalyser les avantages et les inconvnients de chacun. Object-Z possde les mmes caractristiques que le langage Z auxquelles il ajoute la structuration en classe et des aspects dynamiques par les invariants historiques. Object-Z est donc un langage bien adapt pour la spcification de systmes transformationnels. Sa structure orient objet rend une spcification plus concise, donc plus lisible et rutilisable. Les aspects dynamiques de ce langage permettent de spcifier certains aspects dynamiques des rseaux de Petri. Dans le chapitre suivant, on propose une approche de composition de ces deux formalismes. Le langage dfini sera utilis par la suite pour spcifier des SMAH.

34

CHAPITRE 4

METHODE DE COMPOSITION DES SPECIFICATIONS PARTIELLES

4.1 Introduction
Ce chapitre dfinit le formalisme de spcification que nous utilisons par la suite pour spcifier les systmes multi-agents holoniques. Le choix de formalisme devrait avoir une grande capacit dexpression pour couvrir les principaux aspects des SMAH ainsi que la possibilit de prototyper et de vrifier une spcification pour ce type de systmes. Pour ce raison, nous avons opts de composition de deux formalismes existants : les rseaux de Petri (PN comme Petri Net) et le langage Object-Z (OZ). Nous dfinissons dans la suite de ce chapitre les bases de notre approche de composition tant du point de vue syntaxique que du point de vue smantique pour btir un langage multi-formalisme nomm PNOZ (Petri Nets and Object-Z).

4.2 Aperu de notre approche

Pour ce travail nous avons choisi dutiliser deux formalismes de spcification : Petri Net et Object-Z. Chacun apporte ses spcificits (cf. les sections 3.2 et 3.3 du chapitre 3) aux spcifications que nous allons construire. Lapproche de composition est base sur lide dencapsuler un comportement dans une classe Object-Z. Cette encapsulation se fait par un schma particulier qui inclut un rseau de Petri. Ce schma dfinit un comportement pour la classe qui encapsule le schma. Ce procd de composition sapparente une intgration des deux formalismes. Notre dmarche dintgration se fait en deux tapes principales. La premire tape consiste intgrer les notations. La deuxime tape doit fournir une smantique formelle lensemble des spcifications partielles crites en utilisant les deux formalismes. La premire tape concerne la syntaxe de la composition des spcifications partielles. On dsigne par la suite cette tape sous le nom dintgration syntaxique. La dmarche dintgration syntaxique pour ces formalismes consiste : inclure dans des classes Object-Z un rseau de Petri spcifiant le comportement de ces classes, ce qui fait coexister les deux formalismes. utiliser des moyens dexpression rciproque pour pouvoir au sein dun des formalismes exprimer certains aspects spcifis avec lautre. Les deux points prcdents permettent dtablir une relation entre les rseaux de Petri et les structures de donnes et les oprations de la classe Object-Z.

35

La deuxime tape concerne la smantique de la composition des spcifications partielles. On dsigne cette tape sous le nom dintgration smantique. Lintgration smantique de ces deux formalismes est faite grce la transformation de spcification crite selon nos rgles syntaxiques en systme de transition. Nous rappelons, que dans les travaux de [Memmi, 2007], une premire tentative a t propose sans aboutir concrtement une intgration smantique telle quelle sera propose dans la suite de ce chapitre.

4.3 Intgration syntaxique

4.3.1 Principes Pour btir une spcification multi-formalisme dun systme, il faut tablir une relation de composition entre spcifications partielles. En effet, tout ensemble de spcifications partielles doit un moment ou un autre dsigner une partie du systme spcifi par un autre ensemble de spcification partielle. Cette composition peut sexprimer de plusieurs manires : du partage de variables aux contraintes exprimes sur une mme entit ou encore avec la traduction vers un formalisme unique de tous les formalismes utiliss. Le formalisme RdP est intgr dans le formalisme Object-Z pour spcifier des classes avec des aspects comportementaux. Cette intgration, du point vue syntaxique, est base sur un domaine syntaxique partag qui est constitu de deux parties :

Un ensemble de types et classes Object-Z spcifiant les principaux aspects des RdP. Une fonction qui transforme un RdP en lments du domaine syntaxique.

Ce domaine syntaxique partag ne tient pas lieu de traduction des rseaux de Petri en Object-Z mais sert rfrencer au sein dune classe Object-Z les lments du rseau de Petri inclue. 4.3.2 Aspects des RdP exprims en Object-Z Les rseaux de Petri (RdP), quils soient ordinaires, gnraliss, colors, temporiss, temporels, stochastiques, etc. sont des outils graphiques support mathmatique permettant de modliser, visualiser et analyser des volutions comportant le paralllisme, la synchronisation et le partage des ressources. Cette section prsente les aspects des rseaux de Petri exprime en Object-Z. Ces aspects sont obtenus par des raffinements successifs. C'est--dire que nous allons commences par les aspects dun RdP ordinaire, puis gnralis, jusqu aboutir la spcification dun RdPT.

36

4.3.2.1 Rseau de Petri Ordinaire Un RdP ordinaire est un graphe biparti dont les nuds sont des places et des transitions relies par des arcs. Le schma RdP (figure 6) est un modle qui reprsente ltat dun systme. En effet, un RdP ordinaire est un ensemble des places et des transitions relis par des arcs. Ces arcs peuvent relier une place une transition (Pre : matrice dincidence avant) ou une transition un arc (Post : matrice dincidence arrire). En Z/Object-Z, cela peut tre exprim par deux relations. Un RdP est aussi caractris par un marquage initial M0 et un marquage M suite au franchissement dune squence de transitions. Ainsi le marquage est une fonction des places vers des transitions. A ce niveau les invariants porte sur le fait quun RdP doit contenir au moins une place et une transition. Pour les oprations, la seule opration que nous allons dcrire est le Tir dune transition. Pour cela nous allons utiliser deux types libres : un pour les places et un autre pour les transitions (Place et Transition).

Fig. 6 : Rseau de Petri Ordinaire

La figure 7, reprsente la spcification dun RdP ordinaire exprim par la syntaxe Object-Z

37

RdP Place Transition place : Place transition : Transition Pre : Place Transition Post : Place Transition M0 : Place M : Place

Init M=M0 Tir M T : Transition P : Place Input : transition place Output : place transition T : transition Input ({ T })={ P : Place | PTPre T} T : transition Output ({ T })={ P : Place | TPPostP} P : Input ({ T }) M(P) 1 M(P) = M (P) 1 P : Output ({ T }) M(P) 1 M(P)= M (P) +1 Place 0 Transition 0
Fig. 7 : Spcification dun RdP ordinaire base sur la syntaxe de classe OZ

(L1) (L2) (L3) (L4)

Les deux premires lignes (L1 et L2) de la partie prdicative du schma Tir permettent de dterminer les places en amont et celles en aval pour une transition donne. Le troisime prdicat (L3) permet denlve les jetons des places en amont si la transition est franchissable, et la dernire ligne (L4) prsente lajout des jetons dans les places en aval. Le schma relatif au RdP ordinaire peut tre tendu pour spcifier des abrviations des RdP (RdPG rseau de Petri capacit titre dexemple) mais aussi des extensions (RdPT, RdPS, RdPObjet, etc.) de ce dernier.

38

4.3.2.2 Rseau de Petri gnralis (RdPG)

Pour un RdP gnralis (figure 8), on reprend la spcification relative au RdP ordinaires en utilisant les relations Pre et Post pour dfinir deux nouvelles fonctions (WeightPre, WeightPost) relatives aux poids des arcs. On modifie aussi la partie prdicative du schma Tir pour tenir compte les poids des arcs.

Fig. 8 : Rseau de Petri gnralis

Pour que t1 soit franchissable, les places P1 et P2 doivent contenir respectivement au moins 3 et 1 jetons. Aprs franchissement, un jeton sera dpos dans P3 et 2 dans P4. La figure 5 prsente la spcification dun RdPG en Object-Z. Les deux premires lignes (L1 et L2) de la partie prdicative du schma Tir relatif la classe RdPG (figure 9), spcifie lensemble des places en amont et celles en aval pour une transition donne. Le troisime prdicat (L3) permet denlve les jetons des places en amont, si le marquage dune place P est suprieur au poids de larc (WeightPre (PT)), et la dernire ligne (L4) spcifi lajout des jetons dans les places en aval.

39

RdPG RdP[redef Init, Tir] WeightPre :Pre 1 WeightPost : Post 1 Init M=M0 Tir M T : Transition P : Place Input : transition place Output : place transition T : Transition Input ({ T })={ P : Place |PT Pre P} T : Transition Output ({ T })={ P : Place |TP PostP} P : Input ({ T }) M(P) WeightPre (PT) M(P) = M( P) WeightPre(PT) P : Output ({ T }) M(P) WeightPre (PT) M(P)= M (P) + WeightPre(PT) Place 0 Transition 0
Fig. 9 : Spcification dun RdP gnralis base sur la syntaxe de classe OZ

(L1) (L2) (L3) (L4)

4.3.2.3 Rseau de Petri arcs inhibiteurs

On se limite aux arcs inhibiteurs dordre zro. On ajoute une relation qui dfini ces types darcs ainsi que la condition que devrait tre remplir lors du tir des transitions concernes. La spcification de ce type de rseau de Petri est reprsente par la figure 11.

Fig. 10 : Exemple de Rseau de Petri arc inhibiteur

40

RdPIn0 RdPG[redef Init, Tir] Ih0 : place transition Init M=M0 Tir M T : Transition P : Place Input : transition place Output : place transition T : Transition Input ({ T })={ P : Place |PT Pre P} T : Transition Output ({ T })={ P : Place |TP PostP} P : Input ({ T })| P T Ih0M(P)=0 P : Input ({ T }) M (P) WeightPre(PT) M(P) = M (P) WeightPre(PT) P : Output ({ T }) M (P) WeightPre(PT) M(P) =M(P) + WeightPre(PT) Place 0 Transition 0
Fig. 11 : Spcification dun RdP arcs inhibiteurs base sur la syntaxe de classe OZ

(L1) (L2) (L3) (L4) (L5)

Les deux premires lignes (L1 et L2) de la partie prdicative du schma Tir de la classe RdPIn0 (figure 11), permettent de dterminer les places en amont et celles en aval pour une transition donne. Le troisime prdicat (L3) permet de vrifier labsence de jetons dans les places en amont dune transition et qui sont relies cette dernire par un arc inhibiteur. Les dernires lignes (L4 et L5) spcifient le changement de marquage.

41

4.3.2.4 Rseau de Petri capacit

Un RdP capacit est un RdP dans lequel des capacits (nombres entiers strictement positifs) sont associes aux places. Le franchissement dune transition dentre Pi dont la capacit est Cap(Pi) nest possible que si le franchissement de cette transition ne conduit pas un nombre de marquage dans Pi qui dpasse cette capacit.

Fig. 12 : Rseau de Petri capacit

La figure 13 spcifi un RdPCap en langage Object-Z

RdPCap RdPG[redef Init, Tir] Cap : place 1 Init M=M0 Tir M T : Transition P : Place Input : transition place Output : place transition

T : Transition Input ({ T })={ P : Place |PT Pre P}

T : Transition Output ({ T })={ P : Place |TP PostP} P : Output ({ T }) | M(P) + WeightPre(TP) Cap(P) P : Input ({ T }) M(P) WeightPre(PT) M(P) = M (P) WeightPre(PT) P : Output ({ T }) M(P) WeightPre(PT) M (P) = M (P) + WeightPre(PT) Place 0 Transition 0
Fig. 13 : Spcification dun RdP capacit base sur la syntaxe de classe OZ

(L1) (L2) (L3) (L4) (L5)

42

Les deux premires lignes (L1 et L2) de la partie prdicative du schma Tir de la classe RdPCap (figure 13), spcifi les places en amont et celles en aval dune transition donne. Le troisime prdicat (L3) spcifi que la capacit dune place P (Cap(P)) doit tre suprieur ou gale la somme des jetons de la place P et le poids de larc (WeightPre(TP)), et les dernires lignes (L4 et L5) expliquent le passage des jetons dune place en amont une place en aval condition que le marquage dune place P doit tre suprieur ou gale au poids de larc entrant (WeightPre(PT)). 4.3.2.5 Rseau de Petri temporis (RdPt) Un RdP temporis permet de dcrire un systme dont le fonctionnement dpend du temps. Les RdP temporiss sont utiliss pour lvaluation des performances dun systme. Soit les temporisations sont associes aux places (RdP P-temporis) soit aux transitions (RdP T-temporis). Pour les RdP temporiss (RdPt), nous allons ajouter une fonction Tempo qui associ une dur de franchissement chaque transition (cette dure peut tre nulle).
RdPt RdPG[redef Init, Tir] Tempo : transition + Init M=M0 Tir M T : Transition P : Place D : + Input : transition place Output : place transition T : Transition Input ({ T })={ P : Place |PTPre P} T : Transition Output ({ T })={ P : Place |TPPostP} P : Input ({ T }) M(P) WeightPre (PT ) D =Tempo(T) M(P) = M (P) WeightPre (PT ) P : Output ({ T }) M(P) WeightPre (PT ) D =Tempo(T) M(P) =M (P) + WeightPost(TP) Place 0 Transition 0
Fig. 14 : Spcification dun RdP temporise base sur la syntaxe de classe OZ

(L1) (L2) (L3) (L4)

43

4.3.2.6 Rseaux de Petri Temporels (RdPT)

Un rseau de Petri Temporel (RdPT) est un 6-uplet (P, T, Pre, Post, M0, IS) ou (P, T, Pre, Post, M0) est un RdP et IS est une fonction associ chaque transition ti du rseau, un intervalle bornes rationnelles IS(t) = [min, max [ ; (avec 0 min max ; max peut tre infini. Le plus petit de ces temps est appel date statique de tir au plus tt de ti et la plus grande date statique de tir au plus tard de ti. La figure 15 prsente un rseau temporel. Lorsquun jeton arrive dans la place p1, il sensibilise la transition t1, qui pourra tre franchie dans un dlai compris entre zro et linfinie (exprime en unit de temps). Cependant, si un jeton arrive dans la place p2, il sensibilise la transition t2, qui pourra tre franchie dans un dlai compris entre une et deux units de temps.

Fig. 15 : Rseau de Petri Temporel

La figure 16 spcifi le comportement du RdPT en langage Object-Z. Les deux premires lignes (L1 et L2) de la partie prdicative du schma Tir de la classe RdPT (figure 16), permettent de dterminer les places en amont et celles en aval pour une transition donne. Le troisime prdicat (L3) permet dassocie chaque transition T un intervalle de temps. Les deux dernires lignes (L4 et L5) spcifiant le passage des jetons dune place en amont une place en aval dune transition T condition que son temps de franchissement soit dans lintervalle de temps associ la transition T et que le marquage de la place soit suprieur au poids de larc sortant de cette transition. .

44

RdPT RdPGT [redef Init, Tir]

IS : transition + (+ { })
Init M =M0 Tir M T : Transition P : Place D : + SMin : + SMax : (+ { }) Input : transition place Output : place transition T : Transition Input ({ T })={ P : Place |PT Pre P} T : Transition Output ({ T })={ P : Place |TP PostP} T : Transition IS(T)= { SMin .. SMax | 0 SMin < SMax } P : Input ({ T }) M( P) WeightPre (PT ) D IS(T) M(P) = M (P) WeightPre (PT ) P : Output ({ T }) M( P) WeightPre (PT ) D IS(T) M (P) =M(P) + WeightPost(TP) Place 0 Transition 0
Fig. 16 : Spcification dun RdP Temporel base sur la syntaxe de classe OZ

(L1) (L2) (L3) (L4) (L5)

4.4 Rgles de traduction du RdP vers le domaine syntaxique partag Maintenant nous avons exprim les aspects des RdP en Object-Z, nous devons disposer de rgles qui permettent de traduire un RdP en lments du domaine syntaxique. Pour cela nous nous inspirons de Hilaire [Hilaire, 2000] en utilisant une fonction comme relation entre RdP et les schmas Object-Z. La fonction que nous appelons Y est la base du mcanisme dintgration syntaxique de lapproche.
4.4.1 Dfinition de la fonction Y

La fonction Y est dfinie de la manire suivante : Si R est un RdP ordinaire alors Y (R) est une classe Object-Z RdP.
45

Si R est un RdPG alors Y (R) est une classe Object-Z RdPG. Si R est un RdPIh0 alors Y (R) est une classe Object-Z RdPIh0. Si R est un RdPCap alors Y (R) est une classe Object-Z RdPCap. Si R est un RdPt alors Y (R) est une classe Object-Z RdPt. Si R est un RdPT alors Y (R) est une classe Object-Z RdPT.

4.5 Intgration smantique 4.5.1 Aperu Le principe gnral de notre approche dintgration smantique rside dans la traduction des rseaux de Petri et dObject-Z vers un langage pivot (systmes de transitions). Une classe Object-Z, ainsi que le rseau de Petri qui spcifie son comportement, sont ainsi exprims laide dun formalisme unique confre une smantique aux formalismes intgrs. 4.5.2 Systme de transitions Le systme de transition [Manna, 1991] est une reprsentation compacte constitue dun ensemble de calculs qui reprsente la smantique de classe Object-Z. En outre, plusieurs techniques de vrification sont dfinies pour vrifier le modle dun systme de transition ainsi que les formules de la logique temporelle. Un systme de transition S =< V, , Te, Tc, > se compose de cinq lments : 1. 2. 3. 4. 5. un ensemble fini V des variables types. un ensemble dtat . Un tat s est une interprtation dune variable v V. un ensemble de transition lmentaires Te. un ensemble des transitions composes Tc. Un sous-ensemble des conditions initiales , tel que .

Lensemble des variables V se compose de trois classes : input (Vi), output (Vo), et prives (ou local) (Vp) tel que V= Vi U Vo U Vp. Avec la spcification OZ, un tat est dtermin par sa valeur. Si v Vp est une variable prive, on note s[v] la valeur affecter v dans ltat s . La condition initiale est un prdicat tel que, s0 est un tat initial si et seulement si s0[]=TRUE. On dit que s0 satisfait et on le note par s0 |= . Les ensembles Te et Tc sont constitus respectivement des transitions lmentaires et des transitions composes. Ces deux ensembles reprsentent les changements dtat, ce sont des fonctions du type : . Gnralement, une transition lmentaire t Te est caractrise par sa relation de transition t (voir expression (4)), i.e. un prdicat de conjonction. Pour les notations Z/ObjectZ, nous adoptons les conventions before/after (Pre/Post) pour dfinir les prdicats. Parmi les formes gnrales possibles pour la relation de transition, on adopte la forme suivante :
46

t = Pre(t) (v1 = Exp1) (vn= Expn).

(4)

avec Pre(t) est la pr-condition de la transition t et s est un tat source pour la transition t si et seulement si s |= Pre(t). Pour chaque conjoint (vj = Expj), vj Vp U Vo et Expj, j[1,n] est une expression sans variables primes. Lensemble {v1,, vn} Vp U Vo est un sous ensemble des variables qui changent leurs valeurs lors de dclanchement des transitions. Finalement, dans le cas dune transition lmentaire, on suppose que chaque variable v {v1,, vn}, est une fausse criture, signifie que les variables qui napparaissent pas dans t est suppose invariantes suite cette transition. Les transitions composes sont des sous ensembles de transitions lmentaires note [t1 ; ; tn]. On introduit les transitions composes pour reprsenter latomicit des oprations des classes Object-Z. On note par : V(t) lensemble des variable primes de la relation de transition t.

Une transition est dite cohrente si et seulement si :

ti , tj [t1, , tn] ij V (ti) V (tj)=

(5)

Le systme de transition S =< V,, Te, Tc, > est une squence des tats : : s0, s1, ..., sj,... tel que s0 |= et pour chaque sj , j 0 vrifie les possibilits suivantes : 1. Soit t Te tel que si |= Pre(t) et si+1 t(si). 2. Soit une transition compose [t1 ; ; tn] Tc qui vrifie les conditions ci-dessous. Soit = {te1 ; ; ten} est un ensemble des composants de Tc dans ltat si (i.e. pour tout j, si |= Pre(tej)) alors et si+1 te1(si) tem(si). (6)

Enfin, on note par C(S) lensemble de toutes les computations du systme de transition S. 4.5.3 Systme de transitions temporises Dans cette section, on se limite la dfinition du systme de transitions temporises et d'un ensemble de conditions en vertu desquelles une succession de situations systme peut tre admis un calcul de la classe. Les systmes de transitions temporiss (STT) permettent de dcrire la dynamique des systmes combinant des volutions discrtes et des volutions continues. Un STT est un graphe orient tiquet (ventuellement inni). Formellement : Le systme de transitions temporis St =< Vt, t, Tet, Tct, t>
47

(7)

se compose de cinq lments :

1. augmenter lensemble des variables avec une variable de temps t (V = V U {t}). 2. Condition initial t = (t =0). 3. Ajouter lensemble des transitions T = Te U Tc, une transition paramtre note
t

(, E), reprsente la date de dbut dexcution et E reprsente la date de fin dexcution de laction associe la transition. Donc la nouvelle relation de transition sera dfinie comme suit : = Pre(t) (v1 = Exp1) (vn= Expn) (t=t + (E-)) (8) En suite, on dfinie lensemble des calculs ou des estimations quun systme de transitions temporise pourra produire. Cet ensemble doit tre considr comme une smantique temporise d'une classe OZ. Dans ce qui suit, on note si si 1 pour affirmer que le systme de transition passe de l'tat si l'tat si+1 au moyen de la transition tk. Nous dfinissons un ensemble fini micro-tape pour tre un de succession finie des tats s0, s1, ..., sn telles que :

tk

s0

s1

s2, avec t1 Te ,

Pour tout j [2,.., n], sj sj+1 , avec tj Te. Pour tout t Te, sn[t]= FALSE.

4.5.4 Technique de transformation 4.5.4.1 De la classe Object-Z un systme de transitions Une classe de spcification crite en Object-Z peut tre vue comme une description dune machine abstraite. Les objets dune classe sont des instances capables de produire des computations sous forme dune squence de changement dtat caus par des oprations lies la classe en question. Le but de proposer une transformation, cest dobtenir une reprsentation compacte de lensemble des changements quun objet de la classe peut produire. Cette reprsentation permettra daboutir la forme dun systme de transitions. Le rsultat de la transformation est un tripl (S, A, H) avec : 1. S = < V,, Te, Tc, q > est un systme de transition comme il a t dfinit dans la section 4.5.3, 2. A et H sont des ensembles de formules de la logique temporelle linaire (LTL) nomme respectivement des invariantes axiomatiques et des invariants historiques (history invariant). Nous rappelons quune classe OZ peut tre dfini par les lments suivantes :

48

Fig. 17 : les lments dune classe Object-Z

Une classe Object-Z nomme cl est caractrise par les ensembles suivants : 1. Attr(cl) est lensemble des attributs de la classe, qui sont dclare dans llment state schma, 2. Param(cl) est lensemble des paramtres des oprations. Les deux ensembles sont dfinies de tel sorte que Attr(cl) Param(cl)=. 3. State(cl) Attr(cl ) Val est lensemble des tats de la classe, une fonction partial des attributs vers les valeurs. Lensemble Val contient tout les valeurs possibles que lattribut peut prendre pour chaque type. Finalement, Op(cl) est un ensemble des oprations associes la classe cl. On introduit les fonctions auxiliaires suivantes: IN: Op(cl) Param(cl) Et OUT : Op(cl) Param(cl) (10) (9)

qui donnent respectivement les ensembles des paramtres dentre (input) et des paramtres de sortie (output) de chaque opration. i. Exemple : classe Object-Z simpletrans Pour expliquer la technique de transformation dune classe OZ vers un systme de transitions, on a prise lexemple de simpletrans ci-dessous.

49

simpletrans y: x: Init y=0 x=0 OpA [operation schma] x=x+2 OpC [opration schma ] y=y-1 [state schma]

[ Init schma]

Fig. 18 : Classe Object-Z "simpletrans"

Une simple classe Object-Z nomme simpletrans qui respecte le modle : (Ssimpletrans, Asimpletrans, Hsimpletrans) (11)

avec Ssimpletrans= <Vsimpletrans, simpletrans, Te simpletrans, Tc simpletrans, q simpletrans>. On dclare que : Vsimpletransp = Attr (simpletrans) Vsimpletransi = O OP(simpletrans) IN(O) Vsimpletranso = O OP(simpletrans) OUT(O) Donc, pour la classe simpletrans, on a Vsimpletransp = {x, y} Vsimpletransi = Vsimpletranso = {x, y} Dans la classe OZ de la figure 18, le State schma de la forme [partie dclaration |Ax1 ; ;Axn] dclare des attributs et une liste des axiomes relatives aux attributs dclares. Les axiomes Ax1,,Axn sont des prdicats de 1ere ordre associe aux attributs dclares dans le state schma : Asimpletrans = {Ax1 ; ;Axn} La forme gnrale de initial state schma est INIT [Pr1 ; ; Prm] avec Pri (i [1..m]) sont des prdicats de 1ere ordre pour les attributs de la classe.

50

Par consquence, on a :

q simpletrans = Pr1 Prm

Dans notre exemple : q simpletrans = (y=0) (x=0). Pour les oprations de la classe Object-Z : OperationName [partie dclaration | listes des prdicats] sont des parties de spcification qui vont tre transformes aux transitions de Ssimpletrans. Dans tous les cas, une transition donne un ensemble de transitions lmentaires. Soit To= {t1,, ti} est un ensemble de transitions lmentaires rsultant de lopration o Op(simpletrans). Face la richesse du langage Object-Z, les rgles de translation deviennent difficiles. Nous avons illustre quelques aspects du principe de la translation en utilisant lexemple simpletrans de la figure 18. Lopration OpA de la classe simpletrans donne lieu une transition tOpA. Les prdicats avec les attributs amorcs dtermine Pre(tOpA) = . Les prdicats avec des attributs mixtes dterminent le reste de la relation de transition. Dans notre cas, on a : tOpA= (x=x+2) ( y=y-1) et T simpletrans = T OpA T OpC = {tOpA, tOpC} Finalement, la partie des invariants historiques de classe Object-Z est constitue dune liste des formules LTL : H1,, Hp. Donc Hsimpletrans= {H1,, Hp}.
ii. La boite outils SAL

Un modle SAL est encapsul par un contexte qui contient des dnition de constantes, des types et des fonctions. Un contexte contient galement un ensemble de modules. Chaque module est un systme de transitions dont ltat est dnie par un ensemble de variables locales, globales, dentre et de sortie. Les modules dun contexte peuvent tre composs de faon synchrone ou asynchrone. Une composition synchrone : M1||M2 est un module dont les transitions sont des compositions de transitions des modules M1 et M2 dont les gardes sont compatibles (cest--dire, des transitions qui peuvent se dclencher simultanment). Une composition asynchrone : M1[]M2 est un module dont le comportement rsulte dun entrelacement de transitions de M1 avec des transitions de M2.

51

SAL inclut tout un ventail de model-checkers qui, tant donns un modle M et une formule F de la logique temporelle, sont capables de dcider de la validit de F relativement M. En cas de rfutation, un contre-exemple est en gnral propos.
iii. Validation de classe Object-Z avec SAL

Dans cette partie, nous avons essaye de valider une classe Object-Z simpletrans avec le Framework SAL. La notion de schma utilise en Z/Object-Z pour dfinir les types utiliss et les diffrentes abrviations utilise dans les prdicats. Typiquement, une spcification en Object-Z comporte un state schma unique, un initial state schma et un ensemble des oprations schma. Par consquent cette spcification est reprsente par un fichier SAL. Les variables de state schma seront reprsentes par des variables locales (LOCAL) dans un module SAL, et les variables dentre et de sortie des oprations seront reprsentes par des variables INPUT et de sortie OUTPUT. Les oprations dune classe Object-Z est translate en des transitions dans la section Transition du module SAL. Un contexte SAL se compose des dclarations des types et des constantes, suivies par la dclaration des modules SAL. Ces modules reprsentent l'ensemble des tats des variables locales, les variables d'entre et de sortie, l'initialisation et le comportement dun tel tat et les schmas de fonctionnement. Les variables d'tat sont convertis en variables locaux dans un module SAL, qui sont ainsi utilises dans la dfinition des tats globaux de l'automate. Le schma d'initialisation est galement nomm Init qui est converti en une clause d'INITIALISATION non-constructive du la module SAL et les valeurs initiales peuvent tre affectes une ou plusieurs variables SAL. La traduction de chaque schma dopration dObject-Z en SAL peut tre ralise en trois tapes. Tout d'abord, toutes les variables dentres et de sorties, dclars dans le schma dopration sont extraites et traduites en SAL et qui sont dclares dans la clause module. Deuximement, une unique transition est gnre pour chaque schma opration. Et pour finir, des thormes voir des lemmes peuvent tre dfinis partir des prdicats associes aux diffrents classes OZ. Dans notre exemple, la classe Object-Z simpletrans est translate en un fichier SAL qui constitu dun contexte SAL (CONTEXT) nomme simpletrans . Ce contexte comporte des dclarations des types utiliss par la suite dans les modules SAL : NAT : TYPE = [0.. 3] ; dfinition du type NAT.

52

Par la suite nous avons ajout un module SAL nomme State qui comporte les dclarations des variables locales (LOCAL y : NAT, LOCAL x : NAT) correspond aux variables dclares dans le schma dtat de notre classe. Dans la clause INITIALIZATION, nous avons initialiss les variables dj dclares dans la partie dclaration du module "State" : y=0 AND x=0. Dans la classe simpletrans , on a deux oprations OpA et OpC. Chacune de ces deux est translate en une transition. Toutes les transitions sont regroupes dans la partie TRANSITION.
Simpletrans: CONTEXT = NAT : TYPE = [0..3]; BEGIN State: module = BEGIN LOCAL y : NAT LOCAL x : NAT INITIALIZATION [ y = 0 AND x=0 --> ] TRANSITION [ OpA : x' = x + 2 --> y' IN { x : NAT | TRUE}; x' IN { x : NAT | TRUE}; [] OpC : y'- 1 = y --> y' IN { x : NAT | TRUE}; x' IN { x : NAT | TRUE}; [] ELSE --> y' = y; x' = x; ] END; th1 : THEOREM State |- G(y/=3); th2 : THEOREM State |- G(x/=3); th3 : THEOREM State |- AG(NOT(x = 2 AND y = 3)); END

Fig. 19 : Fichier SAL relatif la classe Object-Z "simpletrans"

4.5.4.2 De rseaux de Petri aux systmes de transitions

Les rseaux de Petri sont des outils graphiques permettant de modliser les systmes vnement discrets. Cet outil formel peut tre utilis pour la spcification, la simulation et lanalyse des systmes. Un rseau de Petri comporte deux types de nuds : les places et

53

les transitions. Une place est reprsente par un cercle et une transition par un trait (ou un rectangle). Les places et les transitions sont relies par des arcs. Le franchissement dune transition ne peut seffectuer que si chacune des places en amont de cette transition contient au moins une marque. On dit alors que la transition est franchissable ou valide. Une transition source est donc toujours valide. Pour la translation des rseaux de Petri vers le langage SAL, les places, qui reprsentent les tats dun systme, seront reprsentes par un type qui regroupe les diffrents tats du systme. Le modle de la figure 20, relatif un systme interrupteur , il dispose deux tats (OFF et ON) alors il faut dclarer un type State de cette faon : State: TYPE = {OFF, ON};

Chaque transition du systme sera reprsente par une variable Boolenne qui prend la valeur TRUE ou FALSE pour indiquer que la transition est franchie ou non. Ces variables sont dclares comme des variables dentre (INPUT) et on ajoute une variable de sortie (OUTPUT) pour indiquer ltat du systme aprs le franchissement de lune des transitions S_ON ou bien S_OFF.

Fig. 20 : Rseau de Petri relatif au systme "interrupteur"

La figure 21 reprsente le fichier SAL relatif au systme interrupteur sous jacent au modle RdP de la figure 20.

54

interrupteur: CONTEXT = BEGIN State: TYPE = {OFF, ON}; Main: MODULE = BEGIN INPUT S_on : BOOLEAN INPUT S_off : BOOLEAN OUTPUT state: State TRANSITION [ p1: state = OFF AND S_on --> state'= ON [] p2: state = ON AND S_off --> state'= OFF [] ELSE --> ] END; th1: THEOREM Main |- G ((state = OFF) AND S_on => F (state = ON)); th2: THEOREM Main |- G ((state = ON) AND S_off => F (state = OFF)); END

Fig. 21: Fichier SAL relatif au rseau de Petri du systme "interrupteur"

4.1 Exemple dintgration complte Pour valider notre approche dintgration, nous prsentons dans cette section une tude de cas dun systme daccs par cls lectroniques. Une salle est accessible par une porte coulissante. Pour ouvrir la porte coulissante, une cl lectronique doit tre insre dans un verrou (Lock) lectronique de la porte. Lidentit de la cl (Key) (telle quelles sont encodes dans la carte de la cl) sera lue par le verrou qui vrifie ensuite si la cl nous permet daccder la salle. Lorsque lautorisation daccs nest pas vrifie, la cl est jecte du verrou. Si laccs est autoris, la porte souvre (opened) (ou reste ouverte (open)), sinon la porte se fermera (closed) (ou reste ferm (closed)).

55

La seule opration de la classe "key" (Figure 22) est supplyId prsentant linsertion de la cl dans le verrou. Si la cl est accepte, la transition "Accept" sera franchit sinon on franchit la transition "Ejected" et le systme retourne son tat initial "Wait".

Key State ::= wait Behavior

supplyId k : Key k! = self

(( k : Key k.supplyId)(k.Ejected k.Accept))

Fig. 22 : Spcification du systme Key base sur la syntaxe PNOZ

Le verrou est spcifi par la classe Lock (figure 23). Lattribut keys de la classe dsigne lensemble des cls qui ont la permission daccder la salle. Les oprations grant et deny permet daccepter ou de refuser une cl insrer dans le verrou.

56

Lock State ::= wait Behavior

keys : Key grant k? : Key k? keys deny k? : Key k? keys

((l: Lock(l.State = wait )) (( l: Lock l.State= wait)( l.grant l.deny))

Fig. 23 : Spcification du systme Lock base sur la syntaxe PNOZ

57

Une porte (figure 24) peut tre dans lune des deux tats : ferm (closed) ou ouvert (open).
Door State ::= opened | closed Behavior

status : State Init status = closed

open (status) status= opened close (status) status= closed

((d: Door(d.State = closed )) (( d: Door d.State= closed d.Open)( d.State = opened))

Fig. 24 : Spcification du systme Door base sur la syntaxe PNOZ

Le systme complet de cl lectronique (figure 25) peut maintenant tre spcifi par la classe KeySystem (figure 25). Cette classe utilise des instances des diffrents objets spcifis (Key, Lock et Door). Les attributs keys, lock et door dsigne respectivement lensemble de

58

toutes les cls lectroniques. (Lensemble des cls qui ont la permission daccder la salle sera un sous-ensemble des cls, le verrou du systme et la porte coulissante)
KeySystem Keys: Key lock : Lock door : Door lock.keys keys Init door.Init

(((l: Lock,k : Key)(l.State = wait k.State = wait)) ( d : Door d.State = closed))

Fig. 25 : Spcification du systme KeySystem base sur la syntaxe PNOZ

4.2

Validation avec SAL

Lenvironnement SAL (Salenv) offre un ensemble doutils qui peuvent vrifier certaines proprits du systme tudi. A titre dexemple, on peut siter : sal-wfc : cest un vrificateur de types limite pour SAL. Notez que sal-wfc n'est pas un vrificateur de types complet, de sorte que certaines spcifications de type incorrecte SAL chappent la dtection et de produisent des rsultats imprvisibles. Comme un langage intermdiaire, SAL est prvu pour tre mcaniquement (et correctement) gnr partir certaines d'autres notations, qui a son propre vrificateur de type. sal-smc : SAL vrificateur de modle symbolique; il s'agit d'un vrificateur de modle BDD (Binary Decision Diagram) pour les systmes d'tats finis. SAL utilise le package CUDD1 (CU Decision Diagram) BDD et donne accs de nombreuses options pour la commande variable, et pour le regroupement et le partitionnement de la relation de transition. Le vrificateur de modle peut effectuer la fois de recherche avant et arrire, et galement une priorit transversalle. sal-deadlock-checker : Un outil auxiliaire, bas sur le vrificateur de modle symbolique, pour dtecter les blocages dans les systmes tats finis. sal-bmc : vrificateur de modle born; Il s'agit d'un vrificateur de modle pour les systmes tats finis bas sur le SAT solvers. En plus de la rfutation (par exemple, la

CUDD: CU Decision Diagram : fournit des fonctions pour manipuler les diagrammes de dcision binaires (BDD).

59

dtection de bogues et la gnration de contre-exemple), le vrificateur de modle SAL born peut effectuer une vrification par k-induction. sal-sim : Le simulateur de SAL, est une interface d'autres outils interactifs du SAL. sal-path-finder : Cest un outil auxiliaire, bas sur le vrificateur de modle born, qui gnre des chemins alatoires.

Ces outils utilisent les thormes dfinie dans le fichier SAL correspond au systme spcifi. La figure ci-dessous prsente un fichier SAL correspond une partie du systme tudi, la classe "Door" spcifi dans la section prcdente, est constitu dun MODULE SAL nomme "system" et de deux thormes th1 et th2.
Door : CONTEXT = BEGIN State : TYPE ={closed, opened}; system : MODULE = BEGIN INPUT S_Open : BOOLEAN INPUT S_Close : BOOLEAN OUTPUT state : State INITIALIZATION state = closed TRANSITION [ Open : state = closed AND S_Open = true --> state' = opened [] Close : state = opened AND S_Close = true --> state' = closed ] END; %-----------------------% system properties %----------------------th1 : THEOREM system |- G((state = closed ) AND S_Open => F( state = opened)); th2 : THEOREM system |- G((state = opened ) AND S_Close => F( state = closed)); liveness : THEOREM system |- G(state = closed); END

A partir de ce fichier, on peut vrifier quelques proprits du systme comme deadlock, vivacit et extraire des contre exemple pour les thormes proposs.

Remarque La spcification SAL de la totalit du systme tudi est reprsente par une composition des diffrents sous-systmes. Cette composition sera explique en dtails dans la section 4.7.3.
4.7.1 Path Finder

Le sal-path-finder est un gnrateur de trace alatoire pour le module SAL. Il permet dobtenir une trace alatoire d'excution du module "system" localis dans le contexte Door.

60

./sal-path-finder Door system % ./sal-path-finder contextName moduleName

Assignment ======================== Path ======================== Step 0: --- Input Variables (assignments) --S_Open = true S_Close = false --- System Variables (assignments) --state = opened -----------------------Transition Information: (module instance at [Context: scratch, line(1), column(1)] (label Open transition at [Context: Door, line(12), column(18)])) ----------------------- -----------------------Transition Information: (module instance at [Context: scratch, line(1), column(1)] (label Close transition at [Context: Door, line(14), column(19)])) -----------------------Step 10: --- Input Variables (assignments) --S_Open = false S_Close = false --- System Variables (assignments) --state = closed

4.7.2 Model checking

SALenv contient un vrificateur de modle symbolique (symbolic model checker) nomme sal-smc. sal-smc permet aux utilisateurs de spcifier les proprits du systme avec la logique temporelle linaire. Dans notre exemple, nous avons proposs deux thormes (th1 et th2) : th1 : THEOREM system |- G((state = closed ) and S_Open => F( state = opened)); th2 : THEOREM system |- G((state = opened ) and S_Close => F( state = closed)); Ces proprits peuvent tre vrifies en utilisant sal-smc moduleName theoremName : ./sal-smc system th1 proved. ./sal-smc system th2 proved. SALenv contient aussi un vrificateur de modle borne (bounded model checker) nomme sal-bmc : ./sal-bmc system th2 no counterexample between depth : [0, 10]

61

Avant de prouver la proprit de liveness, il faut vrifie que le systme ne conduit pas une situation de blocage mortel. Pour cela, on peut utiliser loutil sal-deadlock-checker, l'option -v 3 dfinit le niveau de verbosit 3. ./sal-deadlock-checker v 3 Door system ok (module does NOT contain deadlock states) Ensuite, on peut prouver la proprit de liveness : ./sal-smc system liveness ================= Begin of Cycle =================
4.7.3 Vrication compositionnelle

SAL offre deux oprateurs pour compiler les systmes complexe partir dautres modules. Loprateur de composition asynchrone est not par [] . SAL offre ainsi un oprateur de composition synchrone not par || . Les deux types de compositions pouvant tre librement combines. Par exemple, on peut construire un systme comme la composition synchrone de deux modules qui sont eux-mmes construits par composition de sous-modules asynchrones. Les oprateurs de composition ont des smantiques habituelles. Dans une composition asynchrone, un seul module effectue une transition la fois. Dans une composition synchrone, tous les modules doivent faire des transitions simultanes. Dans le cas de lexemple de systme daccs, le systme complet est spcifi en excutant une composition asynchrone des modules Key, Lock et Door. Le module principal est construit par la composition asynchrone des modules Key, Lock et Door.
ElectronicDoor: context = Begin ElecDoorSystem: module = key [] Lock [] Door; End;

4.3 Conclusion Nous venons de poser les bases de l'approche de spcification multi-formalismes que nous utilisons dans la suite de ce mmoire pour spcifier les systmes multi-agents holoniques. Cette approche est compose par les formalismes Object-Z et PN pour bnficier de la puissance d'expression du premier concernant les donnes et leurs transformations et de la facilit d'expression des aspects comportementaux du second. L'intgration de ces deux formalismes dans une mme spcification se fait travers deux aspects : un domaine syntaxique partag et un domaine smantique commun qui dfinit la smantique d'une spcification crite avec les deux formalismes.

62

TROISIEME PARTIE

Approche de Spcification Formelle des Systmes Multi-Agents Holoniques

Nous ne raisonnons-que sur des modles Paul Valry Oeuvres (2t.) et Cahiers (2t.), Gallimard, Bibliothque de la Pliade

63

CHAPITRE 5

APPROCHE DE SPECIFICATION FORMELLE DES SYSTEMES MULTI-AGENTS HOLONIQUES

5.1 Introduction
Le but de ce chapitre est de formaliser les concepts de base de chacun des domaines associs au mta-modle CRIO. La spcification est constitue des classes Object-Z qui intgrent une partie comportementale spcifie en RdP au moyen des techniques prsentes dans le chapitre 4. Lutilisation dun squelette, nous permet dabstraire les aspects communs aux spcifications des systmes multi-agents holoniques bass sur le mta-modle CRIO. Cette approche se compose dun domaine de problme qui comprend les concepts de Rle, Organisation, Interaction et Capacit, ainsi quun domaine dagent bas sur la notion de Groupe, Interaction, Holon, Groupe Holonique, Membre Holonique et Agent. La dfinition de tous ces aspects dans un langage formel leur donne une smantique non ambige et oprationnelle. La structure oriente objet de cette approche nous permet de spcialiser les concepts spcifies et de faciliter leurs rutilisation. Nous commenons tout dabord par les classes correspondant aux concepts de domaine du problme puis celles correspondant au domaine dagentification du mta-modle CRIO. Les spcifications sont accompagnes par des exemples extraits du simulateur de robots footballeurs prsent dans [FIRA_Robot_Soccer].

5.2 Domaine du Problme associ au mta-modle CRIO

5.2.1 Spcification Nous proposons une spcification formelle des diffrents concepts du modle CRIO (Capacit, Rle, Interaction et Organisation).
a. Capacit

La capacit est une description abstraite dun savoir-faire. Elle regroupe la description des moyens qui permettent laccomplissement dune tche. Ceci reprsente une fonctionnalit logique aux yeux des entits qui la fournissent (les propritaires) et de celles qui lutilisent ou la requirent (les utilisateurs).

64

Une capacit est spcifie par la classe Capacity (Figure 26) ou une classe drive de cette dernire. Ce concept est caractrise par un ensemble des attributs prendre comme des inputs par la capacit et un ensemble des outputs produites par la capacit. Les ensembles requires et ensures sont des contraintes spcifies qui doivent tre vrifies avant et aprs lappelle dune capacit.
Capacity inputs : Attribute outputs : Attribute requires : Constraint ensures : Constraint

capacityCall (name) (rrequires ) (eensures e)

Fig. 26 : Classe Capacity base sur la syntaxe PNOZ

b. Rle

Un rle est une abstraction dun comportement ou dun statut. Nous avons choisi de le spcifier par la classe Rle (Figure 27). Cette classe reprsente les attributs caractristiques dun tel rle par lensemble attributes dont les lments sont de type [Attribute]. Les lments caractristiques auront leur type assimil au type Attribute et feront partie de lensemble attributes.
Rle Behavior requiredCapacity : Capacity obtainCondition, leaveCondition : Condition attributes : Attribute actions : Action stimulus : Event s: stimulus, e Behavior. t e.transitions

Fig. 27 : Classe Role base sur la syntaxe PNOZ

Laspect comportemental dun rle est spcifi par le schma Behavior qui inclut un rseau de Petri (Petri Net). Cest--dire que le schma Behavior spcifie les diffrents tats et transitions dans laquelle le rle peut se trouver. En dautres termes Behavior dfinit un rseau de Petri associe au rle. Les stimuli que dclenche une raction dans le comportement du rle sont spcifis par stimulus qui est un ensemble dlments de type [Event].

65

Chaque rle pourrait avoir ces propres capacits reprsentes par un ensemble fini des capacits nomme requiredCapacity. Ainsi que des conditions qui doivent tre remplir avant et aprs dutilisation dune capacit (obtainCondition, leaveCondition). En enfin, lensemble actions spcifie les actions pro-actives et les actions ractives dun rle (celles dclenches par le passage dun tat du rle un autre).
c. Interaction

Linteraction est le seul moyen de communication entre les rles. Une interaction est spcifie la classe Interaction (Figure 28) ou une classe drive de la classe Interaction. Une interaction est spcifie par un couple de rles qui dtermine lorigine de linteraction, premier composant du couple, et la cible de linteraction, deuxime composant du couple. Une interaction dfinit galement le nombre de rles impliqus. On peut contraindre linstanciation dune interaction de manire ce que les entits mettant en uvre les rles origines et cibles de linteraction correspondent aux entits dfinies. Linteraction est base sur un change dinformation induit par une action du rle origine de linteraction et qui un effet sur le rle cible de linteraction. Une interaction entre rles est compose de lvnement gnr par un premier rle et peru par les autres, ainsi que les ractions induites dans ces derniers. Les rles qui interagissent partagent automatiquement un contexte dinteraction commun. Une interaction est caractrise par lchange de message entre le rle origine et le rle cible. Ces changes sont les rsultats dune action des rles origines qui a un effet sur le comportement des rles cibles. On dfinit le type Evenement et stimulus comme une partie de lensemble dvnement.
Interaction orig : Role cible : Role roles : Role Role arite : msg : Evenement e msg (e orig.stimulus) (e cible.stimulus)

Fig. 28 : Classe Interaction base sur la syntaxe PNOZ

d. Organisation

Une organisation (Figure 29) est spcifie par un ensemble des rles et de boundaryrle1 et leurs interactions. Les interactions lient les lments de lensemble rles entre eux. La BoundaryRole est un type spcifique de Rle qui est responsable des interactions survenant la limite entre le systme et lenvironnement. C'est--dire que BoundaryRole hrite du concept Rle.
66
1

contrainte vidente est que les rles et les interactions dune organisation soient cohrents entre eux. De plus, chaque rle doit appartenir au moins une interaction. Chaque organisation pourra tre caractrise par une capacit qui permet de dnir comment cette organisation contribue au comportement global du systme.
Organisation rles : Rle interactions : Interaction

i interactions (i.orig roles i.cible roles) r roles, i interactions r (i.orig i.cible)

Fig. 29 : Classe Organisation base sur la syntaxe PNOZ

Cette premire tape de la spcification dun SMAH permet de spcifier les concepts de base associe au domaine de Problme du mta-modle CRIO et surtout les capacits, les rles, les interactions et les organisations issus de la modlisation. On a ainsi spcifi les comportements qui vont tre instancis par les concepts de domaine dagentification associe au mta-modle CRIO.
5.2.2 Lemmes

Lanalyse mene partir de cette spcication a permis de valider les proprits laide des thormes gnriques pour la 1re domaine du mta-modle CRIO. Le premier lemme peut tre interprt comme "chaque interaction doit avoir deux rles, lune origine et lautre destination". Ce lemme est exprim par la formule suivante :

( o : Organisation, r : Role r o.roles).

Le deuxime lemme peut tre interprt comme "pour chaque interaction, il existe deux rles lune source et lautre destination". Ce lemme est exprim par la formule suivante :

( i Interactions (i.orig roles i.cible roles).

Le troisime lemme peut tre interprt comme "chaque rle, peut avoir une capacit". Ce lemme est exprim par la formule suivante :

( r : Role, c : Capacity c r.requiredCapacity).

5.2.3 Exemple

Lexemple choisi illustre les notions de Rle, Interaction, Capacit et Organisation de lorganisation Team Simulation (figure 26) [Gaud, 2007]. Cette organisation est compose de

67

quatre rles : PlayerSimulator, RleAssigner, GameObserver, StrategySelector et des interactions entre eux ainsi que les capacits associes aux diffrents rles.

Fig. 30: Description de lorganisation du simulateur des robots footballeurs

Cet exemple est spcifi avec les classes Object-Z suivantes : PlayersSimulator, RoleAssigner, GameObserver et StrategySelector spcifient les rles PlayerSimulator et RoleAssigner [Mazigh et al, 2011]. La classe PlayersSimulatorRole (Figure 31) spcifie le rle PlayersSimulator. Il hrite de la classe Rle du CRIO et ajoute ces attributs: requiredCapacity qui est un ensemble de capacits requises par ce rle. Le rle requiert une capacit qui est nomm PlayStrategy. Le comportement de la PlayersSimulatorRole spcifi par le schma de comportement qui est compos de quatre tats. Nous supposons que notre systme peut tre dans ces quatre diffrents tats (PlayersSimulatorReady, PlayersReady, InitializationDone et Playing). Pour cette raison, nous utilisons un type State pour dcrire les tats du systme [Mazigh et al, 2011]. Les flches entrantes et sortantes indiquent quil existe des interconnexions entre les diffrents rles de la mme organisation. Le rle PlayersSimulatorRole change des donnes avec les autres rles de l'organisation TeamSimulation tels que RoleAssignerRole, GameObserverRole et autres actions extrieures [Mazigh et al, 2011].

68

Fig. 31 : Classe PlayersSimulatorRole base sur la syntaxe PNOZ

Les autres rles de l'organisation TeamSimulation (Figure 30) seront spcifis de la mme faon que PlayersSimulatorRole. La classe RoleAssignerRole (Figure 32), StrategySelectorRole (Figure 33) et GameObserverRole (Figure 34) spcifie respectivement les rles RoleAssigner, StrategySelector et GameObserver [Mazigh et al, 2011].

69

Fig. 32 : Classe RoleAssignerRole base sur la syntaxe PNOZ

Remarque : Probablement, dans le schma RoleAssigner (Figure 32), la capacit peut tre absente.

70

Fig. 33 : Classe StrategySelectorRole base sur la syntaxe PNOZ

Le rle StrategySelector est spcifi par la classe StrategySelectorRole (Figure 33) qui introduit une capacit nomme ChooseStrategy requise par ce rle. Il hrite de mme de la classe Rle du mta-modle CRIO. Les flches entrantes et sortantes indiquent quil existe des interconnexions entre StrategySelectorRole et le RoleAssignerRole [Mazigh et al, 2011].

71

Fig. 34 : Classe GameObserverRole base sur la syntaxe PNOZ

Pour finir avec la spcification des rles PlayersSimulator, StrategySelector et RoleAssigner, prcisions les comportements et les tats du systme. Les actions et les tats des rles sont dclenchs par les transitions du rseau de Petri associe et qui sont spcifies par des oprations de la classe Object-Z [Mazigh et al, 2011].
72

Les classes AssociateTacticalRoleAndPlayer (Figure 35), AssignsStrategy (Figure 36) et ProvidesPlayersPositions (Figure37) spcifient les interactions AssociateTacticalRoleAndPlayer, AssignsStrategy et ProvidesPlayersPositions. Chaque classe introduit les rles de chaque interaction.
AssociateTacticalRoleAndPlayer Interaction (RoleAssigner,PlayerSimulator) roles

Fig. 35 : Classe AssociateTacticalRoleAndPlayer Interaction base sur la syntaxe PNOZ

AssignsStrategy Interaction (StrategySelector, RoleAssigner) roles

Fig. 36 : Classe AssignsStrategy Interaction base sur la syntaxe PNOZ

ProvidesPlayersPositions Interaction ( PlayerSimulator, GameObsever) roles

Fig. 37 : Classe ProvidesPlayersPositions Interaction base sur la syntaxe PNOZ

Remarque : Perceive i avec i = {1, 2, 3} reprsente des interactions entre les diffrents rles.
Perceives1 Interaction ( GameObsever, PlayersSimulator) roles

73

Perceives2 Interaction ( GameObsever, StrategySelector) roles

Perceives3 Interaction ( GameObsever, RoleAssigner) roles

Les classes PlayStrategy (Figure 38), ObserveGame (Figure 39) et ChooseStrategy (Figure 40) spcifient les capacits PlayStrategy, ObserveGame et ChooseStrategy. Chacune de ces classes dispose des attributs suivantes : inputs et outputs pour spcifie les entres et les sorties du classe capacit. Par exemple, Le classe PlayStrategy spcifi la capacit PlayStrategy. Ses entres sont un ensemble de bestStrategy et il produit PlayingStrategy en sortie.
PlayStrategy Capacity {bestStrategy} inputs {PlayingStrategy} outputs requires = { inputs }

Fig. 38 : Classe PlayStrategy Capacit base sur la syntaxe PNOZ

ObserveGame Capacity {Game} inputs {Observing Game} outputs requires = { inputs }

Fig. 39 : Classe ObserveGame Capacit base sur la syntaxe PNOZ

ChooseStrategy Capacity {Strategy} inputs {best Strategy} outputs requires = { inputs }

Fig. 40 : Classe ChooseStrategy Capacit base sur la syntaxe PNOZ

74

La classe TeamSimulation (Figure 41) est spcifie lorganisation TeamSimulation. Elle spcifie les diffrents rles et leurs interactions. Elle possde les attributs suivants: roles reprsentant un ensemble des rles et des interactions qui reprsente un ensemble d'interaction dans la mme organisation.
TeamSimulation Organisation { PlayerSimulator, RoleAssigner, StrategySelector,GameObserver} roles { AssociateTacticalRoleAndPlayer, AssignsStrategy, ProvidePlayerPosition, Perceives1, Perceives2, Perceives3} interactions

Fig. 41 : Classe TeamSimulation Organisation base sur la syntaxe PNOZ

5.3 Domaine dagentification associ au mta-modle CRIO

5.3.1 Spcification Cette partie de squelette est consacre la spcification des aspects et des concepts de base lies au domaine dagent du mta-modle CRIO. Parmi ces concepts, on cite Agent, HolonicMember, AgentRole, HolonicGroup, Holon, Interaction et ProductionGroup.
a. AgentTask

La classe AgentTask est un raffinement de la notion de RoleTask du domaine de problme. Il reprsente une partie du comportement dagent. Il peut contribuer fournir un service dAgentRole.
AgentTask ProvidedService : Service

Fig. 42 : Classe AgentTask base sur la syntaxe PNOZ

b. Service

La classe Service fournit le rsultat de lexcution dun capacite ou de la classe Capacity ralisant ainsi un ensemble de fonctionnalits pour son propritaire qui peut tre un rle, un group, un Agent ou un Holon. Ces fonctionnalits peuvent tre effectivement considres comme la mise en uvre concrte de diffrentes capacits. Un rle peut donc publier certains de ses capacits et d'autres membres du groupe peuvent bnficier d'entre eux au moyen d'un change de service. De mme, un groupe, en mesure de fournir une capacit collective peut le partager avec d'autres groupes en fournissant un service.

75

Service Behavior

implements : Capacity

Fig. 43 : Classe Service base sur la syntaxe PNOZ

c. AgentRole

La classe AgentRole est une instance du rle de domaine de Problme. Il s'agit d'un comportement exprim par un ensemble de tches Agent (AgentTask) et il possde un ensemble de droits et obligations dans un contexte de groupes spcifiques. AgentRole interagie l'aide des communications dans le cadre du groupe auquel il appartient. Plusieurs AgentRole sont gnralement regroups dans l'entit autonome qui les coute.
AgentRole Behavior

providedservice : Service agenttask : AgentTask requiredCapacity : Capacity

Fig. 44 : Classe AgentRole base sur la syntaxe PNOZ

d. Goal

La classe Goal est une description d'un objectif poursuivre et reprsente une abstraction d'un tat projet des affaires obtenir. Le concept Goal est caractrise par des attribues comme le nom, etc.
Goal attributes : Attribute

Fig. 45 : Classe Goal base sur la syntaxe PNOZ

e. IndividualGoal

La classe IndividualGoal est un objectif poursuivi par un agent particulier qui peut tre lie ses dsirs personnels ou ses intentions.

76

IndividualGoal Goal

Fig. 46 : Classe IndividualGoal base sur la syntaxe PNOZ

f.

CollectiveGoal

La classe IndividualGoal est un objectif poursuivi par une communaut d'individus qui a la volont de (une partie) des membres de la communaut.
CollectiveGoal Goal

Fig. 47 : Classe CollectiveGoal base sur la syntaxe PNOZ

g. AutonomousEntity

La classe AutonomousEntity est une entit abstraite rationnelle qui adopte une dcision en vue d'obtenir la satisfaction d'un ou de plusieurs de ses propres objectifs. Une AutonomousEntity peut jouer les rles d'agent (AgentRole) au sein de divers groupes. Ces rles interagissent les uns les autres dans le contexte spcifique fourni par l'entit elle-mme. Le contexte dentit est donn par les connaissances, les capacits dtenues par l'entit ellemme.
AutonomousEntity goals : Goal playedRole : AgentRole AE : AutonomousEntity AE. goals AE : AutonomousEntity AE. playedRole
Fig. 48 : Classe AutonomousEntity base sur la syntaxe PNOZ

h. Agent

Un Agent est une entit autonome qui a des objectifs spcifiques individuels et la capacit ncessaire la ralisation de certaines tches. Un agent est reprsent par une classe qui hrite de la classe AutonomousEntity et qui possde des goals individuels (IndividualGoal).

77

Agent AutonomousEntity individualgoal : Goal

Fig. 49 : Classe Agent base sur la syntaxe PNOZ

i.

HolonicRole

La classe HolonicRole dcrire le statut d'un membre au sein d'un super-holon et participer la dfinition de l'organisation holonique. Chacun de ces rles peuvent tre jous par un ou plusieurs membres.
HolonicRole AgentRole Comportement

Fig. 50 : Classe HolonicRole base sur la syntaxe PNOZ

j.

HolonicMember

Chaque HolonicMember de super-holon joue au moins un HolonicRole dans le groupe holonique et divers AgentRole dans des groupes de production (au moins un rle dans un groupe de production). Trois HolonicRole (Representative, Head, Peer) ont t dfinies pour dcrire le statut d'un membre dans un super-holon et un autre (Stand-Alone) pour dcrire le statut des non-membres.
HolonicMember holonic_roles : HolonicRole agent_roles : AgentRole Hm : HolonicMember Hm. holonic_roles Hm : HolonicMember Hm. agent_roles
Fig. 51 : Classe HolonicMember base sur la syntaxe PNOZ

k. Group

La classe Group est une instance de la classe organisation dfinie dans le domaine du problme. Il est utilis pour modliser une agrgation des AgentRole jou par des holons et les interactions entre eux.

78

Group providedServices : Service agents : Agent holons : Holon interactions : Interaction

i interactions i.orig holons i.cible holons h holons , i interactions h (i.orig i.cible)

Fig. 52 : Classe Group base sur la syntaxe PNOZ

l.

HolonicGroup

La classe HolonicGroup est un groupe ddi contenir des HolonicMember. Il dcrit le niveau d'autorit d'un membre l'intrieur de holon membres de la communaut et le degr d'engagement d'un membre de son super-holon.
HolonicGroup Group members : HolonicMember

Fig. 53 : Classe HolonicGroup base sur la syntaxe PNOZ

m. ProductionGroup

La classe ProductionGroup dfinie lensemble des agents ncessaires la satisfaction des objectifs quils ont en commun.
ProductionGroup agents : Agent Pg : ProductionGroup Pg. agents
Fig. 54 : Classe ProductionGroup base sur la syntaxe PNOZ

n. Holon

Un Holon est une entit autonome qui a des objectifs collectifs (CollectiveGoal) (partag par tous les membres dun mme HolonicGroup) et peut tre compos des holons membres appels membre holonique ou sous-holons (HolonicMember).
79

Holon compos est appel super-holon. Un super-holon n'est pas seulement caractris par ses membres mais aussi par leurs modes d'interaction. Un super-holon contient au moins un groupe holonique (HolonicGroup) et ce dernier dfini comment les membres s'organises et gouvernes le super-holon, et un ensemble de groupes de production (ProductionGroup), au moins un, pour dcrire comment les membres cooprent et coordonnent leurs actions pour rpondre aux objectifs de super-holon.
Holon AutonomousEntity agent_roles : AgentRole holonic_groupes : HolonicGroup production_groupes : ProductionGroup collective_goals : Goal

h : holon, hg : HolonicGroup pg ProductionGroup hg h.holoniques_groupes

pg h.production_groupes
Fig. 55 : Classe Holon base sur la syntaxe PNOZ

o. Interaction Linteraction est une communication entre deux ou plusieurs holons. La communication est compose par des messages changs. Elle est reprsente par une classe Interaction suivante :
Interaction orig : holons cible : holons holons : Holon holon arite : msg : Evenement e msg (e orig.stimulus) (e cible.stimulus)

5.3.2 Lemmes Lanalyse mene partir de cette spcication a permis de valider les proprits laide des thormes gnriques associs au domaine dagentification du mta-modle CRIO. Le premier lemme peut tre interprt comme tant "chaque Holon doit avoir au moins une organisation Holonique et une organisation productive". Ce lemme est exprim par la lexpression suivante : ( h : Holon, (Hg : HolonicGroup Pg : ProductionGroup) (Hg h. holonic_groupes Pg production_groupes))

80

5.3.3 Exemple Lexemple prsent ci-dessous, prsente une holarchie compose de quatre niveaux. Chaque holon est dcompos en sous-holons. Le niveau le plus haut reprsente une quipe de robots footballeurs. Ce niveau a pour responsabilit de choisir une stratgie. Chaque anticorps du deuxime niveau reprsente une stratgie en termes daffectation de rles pour les robots (comme gardien de but, attaquant, etc.). Le troisime niveau dnit pour chaque rle un comportement spcique. Enfin, le dernier niveau associe pour chaque point destination un ensemble de trajectoires aptes amener le robot au point destination en vitant les obstacles et en respectant les rgles du jeu.

Fig. 56: La structure holonique du simulateur de robots footballeurs

Cet exemple illustre les notions de base de domaine dagent de mta-modle CRIO comme AgentRole, Holon, Group, HolonicGroup, HolonicRole, etc. Dans la structure holonique reprsent par la figure 56, les groupes (g1, g5, g3 et g7) sont des groupes holonique (HG). Au niveau 2 de lholarchie, deux super-holons H1 et H2 jouent le rle Team dans le groupe g0 (g0 est une instance de lorganisation GameSimulation. Chacun de ces deux super-holons contient une instance de lorganisation TeamSimulation (g2 et g6). Inspirant de gouvernement de type monarchique, les membres holonique jouant le rle StrategySelector (H5 et H9) sont automatiquement nomms Head et Representative.

81

Holon Part (H3) jouant le rle PlayersSimulator est dcompose et contient une instance de lorganisation PlayerSimulator. Son type de gouvernement est inspir dApanarchy, dans laquelle tous les membres sont des Head. Lholon autonome H6 joue le rle de Multi-part et partag par deux couples de super-holons (H1, H2) et (H3, H7). Ce holon reprsente la partie environnementale du systme. Remarque : Dans la suite de lexemple, on va spcifier et sintresser une partie spcifique du notre systme : Holons (H1, H2 et H3), PlayersSimulator AgentRole, HolonicGroup (g3), ProductionGroup (g4) et lAgent (H11) [Mazigh et al, 2011].
H1 Holon agent_role={Team} holonicgroup={g1} productiongroupes ={g2}

Fig. 57 : Classe Holon H1 base sur la syntaxe PNOZ

H2 Holon agentrole={Team} holonicgroup={g5} productiongroupes ={g6}

Fig. 58 : Classe Holon H2 base sur la syntaxe PNOZ

Remarque : Au niveau 2 dholarchie (Figure 56), H3 est vu comme un membre holonique par contre au niveau 1, il est considr comme holon compose. Donc on peut le spcifie comme suit :
H3 HolonicMember holonicroles= Part agentrole = {PlayerSimulator}

Fig. 59 : Classe Membre holonique H3 base sur la syntaxe PNOZ

et

82

H3 Holon agentrole={PlayersSimulator} holonicgroup={g3} productiongroupes ={g4}

Fig. 60 : Classe Holon H3 base sur la syntaxe PNOZ

La classe H3 (Figure 60) spcifie le PlayersSimulator Holon de la structure holonique. Il a les attributs suivants: agentrole (un ensemble dAgentRole jou), holonicgroup (un ensemble de HolonicGroup), productiongroupes (un ensemble de ProductionGroup) et collectiveGoal qui contient tous les objectifs de Holon [Mazigh et al, 2011].

Fig. 61 : Classe PlayersSimulator AgentRole base sur la syntaxe PNOZ

83

La classe de PlayersSimulatorAgentRole (Figure 61) spcifie lAgentRole PlayersSimulator. Il a les attributs suivants: requiredCapacity est un ensemble des capacits utilises par lAgentRole et de fournir des services illustre par un ensemble des services (providedService) et agenttask est un ensemble d'actions spcifiques l'agent [Mazigh et al, 2011]. Le comportement de la PlayersSimulatorAgentRole est spcifi par le schma de comportement (behavior schema). Ce schma contient des rseaux de Petri qui sont utiliss pour dcrire le comportement de PlayersSimulatorAgentRole classe. Cette dernire est joue par lholon H3.
g3 HolonicGroup members={ H10,H11,H12,H13,H14,H6}

Fig. 62 : Classe Groupe Holonique g3 base sur la syntaxe PNOZ

La classe g3 (Figure 62) spcifie HolonicGroup g3. Il ajoute les attributs suivants: ses membres sont un ensemble des membres holoniques (HolonicMembers). Remarque : lensemble agents regroupe des Agents simple et peut contenir aussi des Holons.
g4 ProductionGroup agents={H10, H11, H12, H13,H14,H6}

Fig. 63 : Classe Groupe Productive g4 base sur la syntaxe PNOZ

La classe g4 (Figure 63) spcifie ProductionGroup g4. Il a les attributs suivants: agents est un ensemble d'agent ou dagent compos. Parmi ces agents, la classe H11 (Figure 64) spcifie lAgent H11. Il introduit les attributs suivants: agentrole est un ensemble dAgentRole jou par l'agent H11 et individualgoal est un ensemble d'objectifs utiliss par les agents pour raliser certaines tches.
H11 Agent individualgoal={playing} agentrole={Player}

Fig. 64 : Classe Agent H11 base sur la syntaxe PNOZ

84

Remarque : Dans lexemple choisis, la mme dmarche de spcification utilise pour Team1 et ces composants pourra tre applique pour Team2.

TeamToTeam Interaction holons= {Team1,Team2}

Fig. 65 : Classe Interaction TeamToTeam base sur la syntaxe PNOZ

La classe TeamToTeam (Figure 65) spcifie linteraction entre deux quipes (Team1 et Team2). Il a lattribut suivant : holons est un ensemble dholon qui spcifi les composants de linteraction.
GameSimulation Group {H1,H2}=holons { TeamToTeam }=interactions

Fig. 66 : Classe Groupe GameSimulation base sur la syntaxe PNOZ

Pour finir avec la spcification, la classe GameSimulation (Figure 66) spcifie le groupe GameSimulation qui est une instance de lorganisation GameSimulation prsent dans le domaine de Problme du mta-modle CRIO. Cette classe a deux attributs : holons ensemble des holons de la groupe et interactions est ensemble qui regroupe les interactions entre les diffrents composants du groupe.

5.4 Gnration semi-automatique des instances partir de la spcification

Dans cette partie, on sintresse la gnration des instances partir de la spcification labore pour les deux premiers domaines du mta modle CRIO (domaine du problme et domaine dagentification). Lide est de transformer le squelette de chacun des domaines du mta-modle CRIO et ses notions sous-jacents en fichier XML. Ce fichier contient des instances des lments dclars dans XML schma. La structure dun document XML est dfinissable et validable par un XML schma. XML schma permet de valider automatiquement un document sur sa conformit au modle nonc dans le fichier XML schma.

85

XML Schma relatif au mta-modle

Instanciation

Fichier XML associ au XML schma

Fig. 67 : Instanciation du fichier XML partir du fichier XML schma

5.4.1 Exemple

Fig. 68 : XML schma du domaine de problme du mta modle CRIO

La figure 68 reprsente le fichier XML schma du squelette de domaine du problme. Ce schma reprsente les concepts et les lments de base quon peut les trouver dans le domaine du problme comme organisations, rles, capacit et dInteractions.

86

En important le fichier XML Schma dans un fichier XML, automatiquement les instances des lments de fichier XML schma apparaissent sous forme de balises. Ainsi, un fichier XML (Figure 69) sous-jacent XML schma sera gnr.
<Organisation name="Team Simulator"> <Role name="Player Simulator"> <Capacity name="Play Strategy" /> </Role> <Role name="Role Assigner"> <Capacity /> </Role> <Role name="StrategySelector"> <Capacity name="ChoseStrategy" /> </Role> <BoundryRole name="Game Observer"> <Capacity name="Observe Game" /> </BoundryRole> <Capacity /> <Interaction name="Associate tactical role and player"> <orig>Role Assigner</orig> <cible>Player Simulator</cible> </Interaction> <Interaction name="Assigns Strategy"> <orig>Strategy Selector</orig> <cible>Role Assigner</cible> </Interaction> <Interaction name="provide player position"> <orig>Player simulator</orig> <cible>Game Observer</cible> </Interaction> <Interaction name="percieves1"> <orig>Game Observer</orig> <cible>Player Simulator</cible> </Interaction> <Interaction name="percieves2"> <orig>Game Observer</orig> <cible>Startegy Selector</cible> </Interaction> <Interaction name="percieves3"> <orig> Game Observer</orig> <cible> Role Assigner</cible> </Interaction> </Organisation>

Fig. 69 : fichier XML de domaine de problme Team Simulateur

87

5.5 Conclusion
Dans ce chapitre nous avons montrs les avantages de notre approche multi-formalisme pour spcifier de faons formelle les deux domaines du mta-modle CRIO. Nous avons proposs une dmarche semi automatique pour gnrer les diffrentes instances associs au domaine du problme et au domaine dagentification pour guider lutilisateur dans sa dmarche de spcification et de validation.

88

QUATRIEME PARTIE

Prototypage et vrification de spcification des Systmes Multi-Agents Holoniques

89

CHAPITRE 6

VERIFICATION DE SPECIFICATION DES SYSTEMES MULTI-AGENTS HOLONIQUES : CAS DUNE ENTREPRISE DE FABRICATION DAUTOMOBILES

6.1 Introduction
Ce chapitre traite la vrification des proprits dune spcification de SMAH. Lobjectif est de montrer qu partir dune spcification base sur notre squelette de spcification propos dans le chapitre 5, on peut dmontrer certaines proprits de la spcification. Pour illustrer notre dmarche de vrification, nous avons choisi lentreprise de fabrication des automobiles PEUGEOT. Nous prsentons le problme de manire informelle dans la section 6.2. Nous modlisons le problme sous forme de deux domaines associs au mta-modle CRIO : domaine de Problme et domaine dagentification dans la section 6.3 et nous spcifions le problme laide dun squelette dans la section 6.4. La section 6.5 prsente la technique de vrification et la section 6.6 prsente limplmentation sur la plateforme Janus.

6.2 Prsentation du systme

Lentreprise de fabrication des automobiles PEUGEOT est une usine qui comporte plusieurs directions organises hirarchiquement. Lorganigramme de la figure 69 reprsente quelques directions de commande qui les constitue lentreprise. Ces directions sont organises suivant une structure hirarchique : le niveau 1 reprsente la direction gnrale qui a pour rle de contrler toutes les autres sousdirections de niveau 2 : directions spcialises (production, finances, personnels, etc.). Le niveau 3 reprsente les sous-directions de chaque direction de niveau 2, par exemple, les sousdirections associes la direction de production sont des ateliers de fabrication. Parmis ces ateliers, on peut citer : Emboutissage: Les diffrents composants mtalliques du vhicule (portires, chssis, pavillon...) y sont forms l'aide de presses hydrauliques. Ferrage: Assemblage, principalement l'aide de robots soudeurs, de diffrents sous ensembles mtalliques entre eux. La carrosserie prend forme ici. Peinture : La carrosserie traverse une succession de bassins, afin d'y subir diffrents traitements on fait galement appel des robots de peinture.

90

Montage : Pose des ensembles mcaniques : (moteur, transmission...), Habillage intrieur du vhicule (garnitures, siges, habitacle..), Finitions.

Fig. 70: Organigramme de lentreprise PEUGEOT de fabrication des automobiles

Ces quatre ateliers sont articuls autour d'un important service de logistique et relis entre eux par un systme complexe de convoyeurs automatiques. Le niveau 4, reprsente les entits autonomes qui se participent laboutissement des buts associs latelier concern. Ces entits se devisent en trois grandes catgories : des robots industriels, des machines et des employeurs.

6.3 Modlisation
Pour modliser cette usine sous forme de rles, dorganisation, capacity et dinteraction pour le domaine du problme du mta-modle CRIO et sous forme dAgent, de Holon, etc. pour le domaine dagentification de mme mta-modle, nous nous appuyons sur la mthode que nous avons propose dans le chapitre 5. Le premier point concerne lidentification les diffrents rles, organisations, capacits et les interactions qui vont tre mise en uvre dans le domaine du problme. Le deuxime point concerne lidentification de la socit dagent mise en uvre dans le deuxime domaine c'est--dire identifie les diffrents AgentRole, Holons, groupes Holoniques et des Agents. 6.3.1 Domaine du Problme Nous commenons par le domaine du problme, nous proposons les cinq organisations suivantes :

91

DirectionGnrale : grer les interactions entre la Production, la finance et le Personnel. DirectionProduction : grer tout les services et les ateliers de production. DirectionCommerciale : grer tout les services concernons la finance de lentreprise. DirectionPersonnel : grer le personnel de lentreprise Emboutissage : grer et contrler les entits impliques dans cette action (Employs, machines et robots). Chacune des organisations contient au moins un rle, lorganisation DirectionGnrale est constitue des rles suivants : ProductionRole : cest la partie responsable de la production de lensemble des pices des voitures. PersonnelRole : cest la partie responsable de la gestion du personnel. CommercialeRole : cest la partie responsable des oprations commerciale. Les rles de la mme organisation sont en interaction, par exemple, il y a une interaction entre le rle ProductionRole et le rle CommercialeRole. Chacun de ces rles requirent une capacit : Le rle ProductionRole requit la capacit Fabriquer automobile. Le rle PersonnelRole requit la capacit Grer Personnels. Le rle CommercialeRole requit la capacit Grer Commerce. Lorganisation suivante correspond la DirectionProduction, est constitue des rles suivants : EmboutissageRole : cest la partie responsable de lemboutissage des tles. FerrageRole : cest la partie responsable du ferrage des tles. Ces rles requirent des capacits suivantes : Le rle EmboutissageRole requit la capacit EmboutirTle. Le rle FerrageRole requit la capacit AssemblerTle. Les scnarios dinteraction dans lorganisation Direction Production, sont les suivants : Le rle EmboutissageRole interagit seulement avec le rle FerrageRole. La troisime organisation cest lorganisation Emboutissage et elle regroupe les rles suivants : MachineRole : cest le rle responsable de dcoupage de tle sous forme de pices mtalliques. RobotRole : cest le rle responsable de la mise en forme de tle pour fabriquer les diffrents composants mtalliques du vhicule.

92

6.3.2 Domaine dagentification Ce domaine est consacr la construction de la socit dagent relative au systme tudi. On est amen identifier les diffrents Agents, Holon et les groupes Holoniques, les groupes de productions dont le comportement global doit tre en mesure de fournir une solution au problme dcrit dans la phase prcdente. Il est consacr lagentication de la hirarchie organisationnelle et la dnition des entits en charge de lexcuter. Son objectif consiste dnir les holons du systme et en dduire la structure de la holarchie. Pour construire la holarchie du systme tudi, les organisations qui composent le systme sont instancies sous forme de groupes. Un ensemble de holons est ensuite cr chaque niveau, chacun deux jouant un ou plusieurs rles dans un ou plusieurs groupes du niveau considr.

6.4 Spcification
6.4.1 Domaine du Problme
6.4.1.1 Organisations

Les organisations de cette spcification sont composes des rles, rle environnemental (boundaryrle) et des interactions entre eux. Lorganisation DirectionGnrale cest lorganisation principale de lentreprise. Elle regroupe les rles ProductionRole, PersonnelRole et CommercialeRole ainsi que les diffrentes interactions entre ces rles.

DirectionGnrale
Organisation roles={ ProductionRole, PersonnelRole, CommercialeRole} interactions = {interProdPer, interProdComm, interPerComm }

Fig. 71 : La classe de lorganisation DirectionGnrale

Lorganisation DirectionProduction regroupe le rle EmboutissageRole et FerrageRole ainsi que les interactions entre eux.

93

DirectionProduction Organisation roles={EmboutissageRole, FerrageRole} interactions = {interEmbFerr}

Fig. 72 : La classe associe lorganisation DirectionProduction

Lorganisation DirectionCommerciale cest lorganisation gre les ventes, les achats et la facturation. Elle regroupe le rle FacturationRole, VenteRole et AchatsRole ainsi que les interactions. DirectionCommerciale Organisation roles={ FacturationRole, VenteRole, AchatsRole} interactions = {interFV, interFA}

Fig. 73 : La classe associe lorganisation DirectionCommerciale

Lorganisation Emboutissage cest lorganisation gre les services et les tches demboutissage des tles. Elle regroupe le rle MachineRole et RobotRole ainsi que les interactions. Emboutissage Organisation roles={ MachineRole, RobotRole} interactions = {interMR}

Fig. 74 : La classe associe lorganisation Emboutissage

6.4.1.2 Capacits

Les capacits de cette spcification sont composes dun ensemble inputs et un autre outputs et des contraintes (requires). Les classes ProduireAutomobile (Figure 74), GrerPersonnel (Figure 75), Commerce (Figure 76), EmboutirTle (Figure 77) et AssemblerTle (Figure 78) spcifient respectivement
94

les capacits ProduireAutomobile, GrerPersonnel, AssemblerTle modlises dans la section 6.3.1. ProduireAutomobile Capacity inputs={tle} outputs={automobiles} requires={inputs }

Commerce,

EmboutirTle,

et

Fig. 75 : La classe associe la capacit ProduireAutomobile

GrerPersonnel Capacity inputs={Personnel} outputs={} requires={inputs }

Fig. 76 : La classe associe la capacit GrerPersonnel

Commerce Capacity inputs={rapport} outputs={Facture} requires={inputs }

Fig. 77 : La classe associe la capacit Commerce

95

EmboutirTle Capacity inputs={tle} outputs={pieces carrosserie } requires={inputs }

Fig. 78 : La classe associe la capacit EmboutirTle

AssemblerTle Capacity inputs={pieces tle} outputs={ carrosserie } requires={inputs }

Fig. 79 : La classe associe la capacit AssemblerTle

6.4.1.3 Rles

Les rles de cette spcification ont les attributs suivants : un ensemble nomm "state" qui regroupe les diffrents tats du systme et les capacits requises prsent par un ensemble de capacits (not requiredCapacity). Ainsi, chaque rle possede un schma particulier nomme "Behavior". Ce schma inclut un rseau de Petri qui dfinit le comportement du rle. Les classes Production (Figure 79), Personnel (Figure 80) et Emboutissage (Figure 81) spcifis respectivement les rles ProductionRole, PersonnelRole et EmboutissageRole.

96

a. Rle Production

Production
Role Behavior

state= {Prt, Ordre,PlanificationTermine, ProductionTermine } Planification : Bool Production : Bool Rinitialiser : Bool requiredCapacity={ Produire automobile }

Planification state if Planification then state = { PlanificationTermine} Production state if Production then state = { ProductionTermine} Rinitialiser state

Fig. 80 : La classe associe au Rle Production base sur la syntaxe PNOZ

97

b. Rle Personnel

Personnel
Role Behavior

state= {Prt, Ordre,PlanificationTermine, Recrutement Termine } Planification : Bool Recrutement : Bool Rinitialiser : Bool requiredCapacity={GrerPersonnel}

Planification state if Planification then state = { PlanificationTermine} Recrutement state if Recrutement then state = { Recrutement Termine} Rinitialiser state

Fig. 81 : La classe associe au Rle Personnel base sur la syntaxe PNOZ

98

c. Rle Emboutissage Emboutissage AgentRole Behavior

state= {Prt, Ordre,PlanificationTermine, Emboutissage Termine } Planification : Bool Emboutissage : Bool Rinitialiser : Bool requiredCapacity={ EmboutirTle }

Planification state if Planification then state = { PlanificationTermine} Emboutissage state if Emboutissage then state = { Emboutissage Termine} MiseZro state

Fig. 82 : La classe associe au Rle Emboutissage base sur la syntaxe PNOZ

6.4.2 Domaine dagentification Dans cette section, nous ne spcifions pas toutes les parties du systme tudi. On va sintress la partie productive. C'est--dire au holon AT1 qui joue lAgentRole Emboutissage dans la structure holonique (Figure 88), AT1 appartient au groupe holonique (HolonicGroup) g3. Au niveau 3, lholon AT1 est vu comme holon compose des agents (A1, A2).
99

6.4.2.1 Les Holons

Les Holons de cette spcification sont composes par des groupes holoniques et dautres groupes de production que nous avons dcrire et des goals collectives. Lholon AT1 reprsente le niveau 3 de lhirarchie (Figure 88). Il est caractris par un AgentRole : Emboutissage, ainsi quun group holonique (g5), group de production (g6) et des goals collectifs.
AT1 Holon agent_roles={Emboutissage} holonic_groupes={g5} production_groupes={g6} collective_goals={Emboutissage}

Fig. 83 : La classe associe au holon AT1 base sur la syntaxe PNOZ

6.4.2.2 Les AgentRoles

LAgentRole Emboutissage est une instance du rle Emboutissage prsent dans le domaine de Problme du systme. La classe Emboutissage (Figure) spcifi lAgentRole Emboutissage

100

Emboutissage AgentRole Behavior

state= {Prt, Ordre,PlanificationTermine, Emboutissage Termine } Planification : Bool Emboutissage : Bool Rinitialiser : Bool requiredCapacity={ EmboutirTle }

Planification state if Planification then state = { PlanificationTermine} Emboutissage state if Emboutissage then state = { Emboutissage Termine} MiseZro state

Fig. 84 : La classe associe lAgentRole Emboutissage base sur la syntaxe PNOZ

6.4.2.3 Les groupes Holoniques

Les groupes holoniques de notre spcification sont composs par les membres holoniques. Le comportement de ces groupes holoniques est dtermin par le comportement de ces membres.

101

g5 HolonicGroup Members={A1, A2}

Fig. 85 : La classe associe au groupe holonique g5 base sur la syntaxe PNOZ

6.4.2.4 Les agents

Les agents de notre spcification sont caractriss par les rles quils jouent et des goals individuels. Les agents A1 et A2 reprsentent les entits autonomes du niveau le plus bas de lhirarchie. Chacun est caractris par les rles jous (playedroles) ainsi que des goals individuels.
A1 Agent individualgoal ={couper tle} playedroles = {Machine}

Fig. 86 : La classe associe lagent A1 base sur la syntaxe PNOZ

A2 Agent individualgoal={assemblage tles} playedroles = {Robot}

Fig. 87 : La classe associe lagent A2 base sur la syntaxe PNOZ

6.4.2.5 Les groups de production

Les groupes de production de notre spcification sont caractriss par un ensemble dagents qui participe la ralisation des buts du groupe. Le comportement de chaque groupe de production est dtermin par le comportement des agents du mme groupe.

102

g6 ProductionGroup agents ={A1, A2}

Fig. 88 : La classe associe au groupe de Production g6 base sur la syntaxe PNOZ

Fig. 89: Lhirarchie de la socit dagent/Holon de lentreprise

6.5 Vrification
Notre approche de vrification est base sur la transformation des spcifications en systmes de transitions. Les systmes de transitions sont ddis la reprsentation des systmes concurrents. Ce formalisme est bas sur la notion dtats et de transitions. Lvolution du systme est vue comme une suite de changements des valeurs des variables constituant ltat du systme. Chaque changement est le rsultat de lapplication dune transition.
103

Pour transformer une spcification en systme de transition, nous proposons une approche fonde sur la smantique que nous donnons la spcification. Cette smantique repose sur la transformation des classes Object-Z et les rseaux de Petri en un systme de transition. La transformation se fait en deux tapes : Dfinir les tats du systme de transition grce la transformation des tats des rseaux de Petri et des sous-schmas des attributs des classes Object-Z. Il faut galement dfinir les transitions du systme de transition partir des transitions du modle rseau de Petri et aux oprations des classes Object-Z.
6.5.1 Dfinition des tats du systme de transitions

Pour dfinir les tats du systme de transitions, il faut dfinir lensemble des variables typs not dont chaque tat est une interprtation. Lensemble de ces variables types est constitu, dune part des attributs des classes Object-Z, et dautre part des tats des rseaux de Petri inclus dans ces classes. Par exemple, pour le rle ProductionRole on a : Object-Z = {state, Planification, Production, Rinitialiser} Et RdP = {Prt, Ordre, PlanificationTermine, ProductionTermine} On a alors = Object-Z RdP La condition initiale qui caractrise les tats initiaux possibles est dfinie laide : Des oprations Init des classes Object-Z, Des prdicats des sous-schmas dattributs des classes Object-Z.
6.5.2 Dfinition des transitions du systme de transition

Pour dcrire les transitions, nous utilisons la relation t des transitions qui associe une transition une conjonction des prdicats. Cette notation est en fait trs proche de celle utilise par Z. En effet, ces prdicats portent sur les variables avant et aprs la transition (respectivement variables non primes et primes). Pour le rle ProductionRole, nous donnons trois transitions en exemple. Ces transitions correspondent lexcution des oprations de la classe. est dfinit de la manire suivante : t1 = (state= Prt) (Planification = true) (state=Planification) t2 = (state= PlanificationTermine) (Production = true) (state= Production) t3 = (state= ProductionTermine) (Rinitialiser = true) (state=Prt)

104

6.5.3 Preuve

Les comportements formaliss par une spcification peuvent tre dcris par un ensemble de squences vrifiant des proprits de suret et de vivacit. Intuitivement, une proprit de suret assure que chaque quelque-chose de mauvais narrivera pas et une proprit de vivacit assure que quelque chose de bon finit par se passer. Pour mettre en uvre notre approche de vrification sur le problme de la production des automobiles, nous avons choisi deux proprits. La premire est une proprit de suret. Elle garantit que pour le rle ProductionRole, il y a toujours un ordre de production qui dclenche la production. 6.6 Implmentation sur la plateforme Janus
6.6.1 Plateforme Janus

Janus est une plateforme particulire ddie limplantation de systmes multi-agents holoniques. Le mta-modle de cette plate-forme sintgre dans le troisime et dernier domaine du mta-modle CRIO : le domaine de la solution. An de faciliter la transition entre la phase de conception et la phase dimplantation, le mta-modle de Janus dnit un ensemble de concepts relativement proches de ceux introduits dans le domaine agent de CRIO. Lobjectif poursuivi de la plate-forme Janus est, terme, de faciliter le transfert de la technologie multi-agents et lutilisation des approches organisationnelle et holonique dans le cadre de projets industriels. Le cur de la plate-forme est constitu par son noyau qui fournit limplantation du modle organisationnel et de la notion de holon. Le noyau a ensuite t tendu pour intgrer le module de simulation et les holons en charge du fonctionnement de la plate-forme et de son intgration avec les applications. 6.6.2 Exemple La prsente section termine la description de lexemple dbut dans les sections prsidentes de ce chapitre. Elle dcrit une partie de son implantation sur la plate-forme Janus. Le programmeur dispose ce stade, de la description complte de larchitecture des diffrents groupes, holons et agents impliqus dans la modlisation du lexemple. La suite de cette section est consacre la description de limplantation du rle Production dnie par lorganisation DirectionGnrale et de celle du holon ProductionHolon qui doit jouer ce rle. Lorganisation DirectionProduction, comme les autres organisations de lapplication, dispose de son propre paquet Java contenant les classes de ses rles et sa propre classe. Daprs le modle de conception, le rle Production requiert la capacit Produire automobile Un fragment du code du rle ProductionRole (Figure 90) est fourni ci-aprs.

105

package DorectionGeneral; import org.janusproject.kernel.crio.core.HasAllRequiredCapacitiesCondition; import org.janusproject.kernel.crio.core.Role; import org.janusproject.kernel.message.Message; import org.janusproject.kernel.status.Status; import org.janusproject.kernel.status.StatusFactory; import capacity.ProduireAutomobileCapacity; public class ProductionRole extends Role{ private State state; public ProductionRole(){ addObtainCondition(new HasAllRequiredCapacitiesCondition(ProduireAutomobileCapacity.class)); } @Override public Status activate(Object... parameters) { //Initialize the role according to the parameters //coming from the agent which plays this role. //return a default ok status //Message msg = new StringMessage() this.state = State.WAITING_FOR_Production_Ordre; Message msg = new Message(); this.sendMessage(CommercialRole.class, msg); return StatusFactory.ok(this); } @Override public Status live() { //The core behavioral method of the role. this.state = Run(); return StatusFactory.ok(this); } @Override public Status end() { // Role finalization: free the resources.... // If this method is usless in your application, do // not override it and everything will work fine return StatusFactory.ok(this); } private State Run() { return state; } public enum State { /** * Waiting for Production Order. */ WAITING_FOR_Production_Ordre, /** * Wait until all Machine and Robot are ready */ WAITING_FOR_Machine_Robot_READY, } } Fig. 90 : code source du rle ProductionRole

Un fragment du code de lorganisation DirectionProductionOrganization (Figure 91) est fourni ci-aprs. Cette organisation regroupe deux rles : EmboutissageRole et FerrageRole.

106

package DirectionProduction; import org.janusproject.kernel.crio.core.CRIOContext; import org.janusproject.kernel.crio.core.Organization; public class DirectionProductionOrganization extends Organization{ /** * @param context */ public DirectionProductionOrganization(CRIOContext context) { super(context); addRole(EmboutissageRole.class); addRole(FerrageRole.class); } } Fig. 91 : code source du lorganisation DirectionProductionOrganization

Pour lorganisation Emboutissage est implmente comme il montre le code ci-aprs :

import org.janusproject.kernel.crio.core.CRIOContext; import org.janusproject.kernel.crio.core.Organization; public class EmboutissageOrganization extends Organization{ /** * @param context */ public EmboutissageOrganization(CRIOContext context) { super(context); addRole(MachineRole.class); addRole(RobotRole.class); } } Fig. 92 : code source du lorganisation EmboutissageOrganization

Cet organisation constitue par deux rles MachineRole et RobotRole. Ces deux rles sont jous par deux agents MachineAgent et RobotAgent. Le code de ces agents est fourni ciaprs :
package agents; import import import import import import org.janusproject.kernel.agent.Agent; org.janusproject.kernel.agent.AgentActivationPrototype; org.janusproject.kernel.crio.capacity.CapacityContainer; org.janusproject.kernel.crio.core.GroupAddress; org.janusproject.kernel.status.Status; org.janusproject.kernel.status.StatusFactory;

import capacity.CoupageTleCapacityImpl; import Emboutissage.EmboutissageOrganization; import Emboutissage.MachineRole; @AgentActivationPrototype( fixedParameters={} ) public class MachineAgent extends Agent{ /** *

107

*/ private static final long serialVersionUID = 1L; public MachineAgent() { } @Override public Status activate(Object... parameters) { //Initializes capacities and memory //Capacity initialization : adding the capacity required by the MachineRole role CapacityContainer cc = getCapacityContainer(); cc.addCapacity(new CoupageTleCapacityImpl()); //Creates or joins groups and requests roles GroupAddress EmboutissageG = getOrCreateGroup(EmboutissageOrganization.class); if (!requestRole(MachineRole.class, EmboutissageG)) { return StatusFactory.cancel(this); } return StatusFactory.ok(this); } } Fig. 93 : code source du lagent MachineAgent package agents; import import import import import import org.janusproject.kernel.agent.Agent; org.janusproject.kernel.agent.AgentActivationPrototype; org.janusproject.kernel.crio.capacity.CapacityContainer; org.janusproject.kernel.crio.core.GroupAddress; org.janusproject.kernel.status.Status; org.janusproject.kernel.status.StatusFactory;

import capacity.AssemblerTleCapacityImpl; import Emboutissage.EmboutissageOrganization; import Emboutissage.RobotRole; @SuppressWarnings("serial") @AgentActivationPrototype( fixedParameters={}) public class RobotAgent extends Agent{ public RobotAgent() { } @Override public Status activate(Object... parameters) { //Initializes capacities and memory //Capacity initialization : adding the capacity required by the RobotRole role CapacityContainer cc = getCapacityContainer(); cc.addCapacity(new AssemblerTleCapacityImpl()); //Creates or joins groups and requests roles GroupAddress EmboutissageG = getOrCreateGroup(EmboutissageOrganization.class);

108

if (!requestRole(RobotRole.class, EmboutissageG)) { return StatusFactory.cancel(this); } return StatusFactory.ok(this); }} Fig. 94 : code source du lagent RobotAgent package Holon; /* ... */ public class EmboutissageHolon extends LightHolon { // ... Attributs du holon ... private GroupAddress g4; //1ere tape du cycle de vie du holon : lactivation public void activate() { //Attribution des capacits au holon addCapacity(EmboutirTleCapacity.class, new EmboutirTleCapacity (this)); //Cration dun groupe ou //Accs ladresse dun groupe existant //qui implmente lorganisation TeamSimulation TeamGA = getOrCreateGroup(TeamSimulationOrganization.getInstance() ); println("About to request role "+ g4); //Demande daccs au rle PlayersSimulator // dans le groupe prcdent if(requestRole(Emboutissage.class, g4)){ //Journalisation dinformations getLogger().info("role Emboutissage assigned"); } } //2ieme tape du cycle de vie du holon : comportement public void live() { //Excution des rles while(true) { for (Role role : getRoles()) role.behavior(); } } //3ieme tape du cycle de vie du holon : Terminaison public void end() { //Demande de libration du rle PlayersSimulator if(leaveRole(Emboutissage.class,g4)){ getLogger().info("role ProductionOrganization: Emboutissage disassigned"); } else { getLogger().error("Pb during disassignation of ProductionOrganization: Emboutissage role"); } } } Fig. 95 : code source dHolon EmboutissageHolon

Pour tester et simuler lexcution de notre application Janus, il faut ajouter une classe nomme Launcher. Cette classe contient une instance du noyau de plateforme Janus et des instances de diffrents agents utilises.

109

package main; import java.util.logging.Level; import org.janusproject.kernel.agent.Kernel; import org.janusproject.kernel.agent.Kernels; import org.janusproject.kernel.locale.LocalizedString; import org.janusproject.kernel.logger.LoggerUtil; import agents.MachineAgent; import agents.RobotAgent; public class Launcher { /** * @param args */ public static void main(String[] args) { // TODO Auto-generated method stub LoggerUtil.setGlobalLevel(Level.ALL); LoggerUtil.setShortLogMessageEnable(true); // kernel instance Kernel k = Kernels.get(true); // Agent MachineAgent M1 = new MachineAgent(); RobotAgent R1 = new RobotAgent(); //Agents firing k.submitHeavyAgent(M1, LocalizedString.get(Launcher.class, "Machine1")); k.submitHeavyAgent(R1, LocalizedString.get(Launcher.class, "Robot1")); k.launchDifferedExecutionAgents(); } } Fig. 96 : code source du classe Main

Le rsultat de la simulation de notre application est reprsent par la figure ci-dessus. Ce rsultat montre comment les agents communiquent entre eux au sien dune mme organisation.
3f5080ba-edd2-4263-8c10-43e72dbdcdaf | INFO : Janus Multiagent Platform. Copyright (C) 2004-2011 Janus Core Developers. This program comes with ABSOLUTELY NO WARRANTY; for details see website http://www.janus-project.org/. This is free software, and you are welcome to redistribute it under certain conditions. Machine1| Machine1| INFO : Envoi d'une demande au Robot1 Machine1| Machine1| INFO : Envoi d'une demande au Robot1 Machine1| Machine1| INFO : Envoi d'une demande au Robot1 Machine1| Machine1| INFO : ACK reu du Robot1 3f5080ba-edd2-4263-8c10-43e72dbdcdaf | INFO : Le noyau JANUS est arrt.

110

6.7 Conclusion

Dans ce chapitre nous avons montrs notre approche sur un exemple rel partant de la phase danalyse jusqu limplmentation. Cette approche utilise un mcanisme de transformation de nos spcifications en systme de transitions. Une fois les spcifications transformes, on peut utiliser un outil de preuve automatique tel que SAL. Cet outil permet de vrifier par des techniques comme la vrification par valuation sur un modle ou la preuve interactive de proprits, la satisfiabilit ou la validit de formules exprimes en logique temporelle linaire du premier ordre. Pour illustrer cette approche, nous avons trait lexemple du lentreprise PEUGEOT de fabrication des automobiles. Nous avons modlis cet exemple sous la forme de deux domaines associe au mta-modle CRIO. Enfin, nous avons utilise la plateforme Janus pour implmenter et simuler notre application que nous avons spcifie en utilisant notre approche de spcification formelle.

111

Conclusion et Perspectives

112

CONCLUSION
Tout au long de ce travail, nous nous sommes efforcs de mettre en place un Framework comprenant un langage et un modle pour la spcification, le prototypage et la validation des SMAH. Les formalismes que nous avons utiliss couvrent, dune part les aspects fonctionnels grce Object-Z, et dautre part les aspects comportementaux grce aux rseaux de Petri. De plus, ces langages proposent des mcanismes de raffinement qui permettent daboutir une spcification proche dune implmentation. A prsent, analysons rapidement ce qui a t fait : Nous avons prsent au chapitre 1, le contexte de notre mmoire, la dfinition des notions de spcification formelle, systme multi-agents, systme multi-agents Holoniques, le mtamodle CRIO, la mthodologie ASPECS et la plateforme Janus. Dans une seconde tape, nous avons ports un grand intrt pour dfinir notre langage de spcification. Pour cela, nous avons prsent dans le chapitre 2 les principaux concepts des formalismes qui servent de fondement notre langage. La dmarche propose dans le chapitre 3, que nous avons adopte pour composer les spcifications partielles consiste : Construire un langage de description commun qui permet aux deux langages de se rfrencer mutuellement. Exprimer la smantique dObject-Z et des rseaux de Petri en termes de systme de transitions. En procdant ainsi nous autorisons la coexistence des rseaux de Petri et de classe ObjectZ dans une mme spcification. De plus, le langage de description commun permet lexpression, dans un des deux langages, des contraintes concernant une partie de la spcification exprime avec lautre langage. La smantique de ces spcifications partielles est unique. Nous avons ensuite proposs, dans le chapitre 4, un mta-modle formel bas sur le mta-modle CRIO. Ce mta-modle formel forme un squelette. Ce squelette nous permet dabstraire les aspects communs aux spcifications des systmes multi-agents holoniques (SMAH) bass sur le mta-modle CRIO et nous avons valid notre approche sur lexemple des robots footballeurs. Enfin, nous avons illustre notre approche en modlisant le systme de fabrication des automobiles dans lentreprise PEUGEOT.

113

Perspectives

1. Automatisation de notre approche Essayer dautomatiser partiellement notre approche pour quelle puisse tre utilise par des non spcialistes.

2. Intgrer le concept Goal dans la Phase danalyse des besoins du Processus ASPECS

Lide est quon peut partir des rsultats de lactivit Capacity Identification de la phase Analyse des besoins du processus ASPECS identifie les diffrents objectifs (Goal) du systme. Donc, ajout une nouvelle activit Goal Identification (GI) aura le diagramme de classe relatif lactivit Capacity Identification, comme paramtre dentre (Inputs). Lactivit GI produira un diagramme de classe Goal Diagram (GD) comme paramtre de sortie. Le GD est sera construit en se basant sur le point de vue des rles et des capacits en utilisant deux techniques de raisonnement de base : Contribution analysis et AND/OR decomposition. (Telle quest dfini dans la mthodologie Tropos)

114

Annexes

115

ANNEXE A FRAMEWORK SAL (SYMBOLIC ANALYSIS LABORATORY)

SAL est un Framework permettant de combiner la dmonstration de thormes, le model checking, et des outils d'analyse du programme pour l'analyse des systmes de transition. SAL est bas sur un langage intermdiaire pour la description modulaire de systmes de transitions. Le langage intermdiaire mdiatise la communication entre les diffrents outils de back-end pour vrifier des proprits et de gnrer des invariants et des abstractions. Nous discutons de l'architecture de la SAL, la syntaxe et la smantique de son langage intermdiaire, et les diverses fonctions d'analyse des systmes de transition SAL. Nous prsenterons galement la relation entre les SAL et les outils de vrification d'autres pays dvelopps au SRI comme PVS et ICS. Laboratoire d'analyse symbolique (SAL) est un cadre dvelopp au SRI pour combiner diffrents outils pour l'analyse du programme, l'abstraction, la dmonstration de thormes, et le modle de contrle des systmes de transition. SAL un langage pour dcrire les systmes de transition. Voici une courte liste de caractristiques importantes dans la langue de SAL. Pour plus de dtails, le lecteur peut se rfrer au manuel de langue SAL. Le bloc de base de tout programme de SAL est un module. Un module SAL consiste de: un tat, un tat d'initialisation de cet tat et une relation binaire de transition une forme spcifique de l'tat. L'Etat se compose de INPUT, OUTPUT, et GLOBAL Les variables locales. Les variables d'entre sont en lecture seule variables. Les autres sont en lecture crire des variables. Initialisation est effectue une seule fois et c'est alors que la l'excution du systme dmarre. Toutes les transitions sont dfinies dans la section de transition. Dans la section de transition, les variables de l'tat suivant peut tre renvoy l'aide d'un '?' suffixe. Proprits exprim sous forme du formules LTL peut tre spcifi dans SAL comme des thormes. SAL a une suite de model-checkers dont nous avons utilis SAL-smc, qui est un symbole model checker et SAL-bmc, qui est un modle limit-checker qui peut tre utilis pour vrifier les proprits. Une spcification SAL chantillon est donne ci-dessous titre d'illustration.

116

En outre, chaque module de ce contiendra des variables boolennes correspondant chaque transition. Cette variable est dfinie pour tre vrai chaque fois que le Statechart est dans le tat de la source de la transition et c'est permettant condition est vraie. Une spciale boolenne ElseTransition variable est dfini pour tre vrai quand aucune des transitions sont activs. Les transitions d'tat et les actions prsentes dans le Statechart sont traduits par surveill actions dans le corps du module correspondant. Voici un modle SAL cahier des charges qui illustre certains de ces concepts.

117

SAL stands for Symbolic analyse en laboratoire. Il est un cadre permettant de combiner diffrents outils pour l'abstraction, l'analyse des programmes, la dmonstration de thormes et la vrification de modle vers le calcul des proprits (analyse symbolique) des systmes de transition. Un lment cl du cadre de SAL est une langue intermdiaire pour dcrire les systmes de transition. Ce langage est destin servir de cible pour les traducteurs qui extraient la description du systme de transition pour la modlisation et d'autres langages de programmation, et comme une source commune pour la conduite des outils d'analyse diffrents. La langue SAL intermdiaire n'est pas si diffrente de la langue d'entre utiliss par les diffrents outils de vrification d'autres tels que SMV, Murphi, et Moka, Comme ces langues, SAL dcrit des systmes de transition en termes de commandes d'initialisation et de transition. Ils peuvent tre administrs par des dfinitions de variables-sage dans le style de SMV ou des commandes gardes dans le style de Murphi. The current generation of SAL tools comprises a collection of state of the art LTL model checkers and auxiliary tools based on them. In future we expect to add tools for static analysis, invariant generation, abstraction, and a tool bus to connect these together. La SAL 3,0 distribution comprend les outils suivants primaires. Ces sont pleinement oprationnelles et sont maintenus par nous. : Sal-wfc :

Le vrificateur SAL bien form, ce qui est un typechecker limite pour SAL. Vous ne devez pas appliquer d'autres outils de SAL jusqu' ce que les erreurs identifies par le vrificateur bonne formation aient t corriges. Notez que sal-WFC n'est pas une typechecker complet, de sorte que certaines spcifications de type SAL incorrecte chapper la dtection et de produire des rsultats imprvisibles. Comme un langage intermdiaire, SAL devrait tre mcaniquement (et correctement) gnr partir des notations d'autres, qui a son propre typechecker Sal-smc :

Le vrificateur de modle SAL symbolique, ce qui est un vrificateur de modle BDD pour les systmes d'tats finis. SAL utilise le paquet Cudd BDD et donne accs de nombreuses options pour la variable de commande, et pour le clustering et la rpartition de la relation de transition. Le vrificateur de modle peut effectuer la fois de recherche avant et arrire, et galement parmi les priorits de traverse. Sal-deadlock-checker

Un outil auxiliaire, bas sur le model checker symbolique, pour dtecter les blocages dans les systmes tats finis Sal-bmc

118

Le vrificateur de modle SAL born, ce qui est un vrificateur de modle pour les systmes tats finis base sur la rsolution SAM. En plus de rfutation (par exemple, la dtection et la gnration de contre-bug), le vrificateur de modle SAL born peut effectuer une vrification par k-induction. SAL pouvez utiliser plusieurs solveurs SAT, mais par dfaut Yices Sal-inf-bmc

La SAL vrificateur infinie modle born, ce qui est un vrificateur de modle pour les systmes infinis base sur la rsolution SMT. En plus de rfutation (par exemple, la dtection et la gnration de contre-bug), le vrificateur SAL infini born modle peut effectuer une vrification par k-induction. SAL pouvez utiliser plusieurs solveurs SMT, mais par dfaut Yices. Sal-atg

Le gnrateur de test automatis SAL, ce qui est un outil auxiliaire qui utilise les pions symbolique, born, born et infini modle pour effectuer la gnration automatique de squences d'entre dtermine par des variables pige spcifi. Les outils sont des scripts SAL, crit en Scheme, qui dclenchent certaines fonctions de l'API SAL; sal-ATG est un bon modle pour ceux qui souhaitent dvelopper leurs propres scripts. Salenv-exec

La SAL excutable rel. Tous les outils SAL autres scripts sur l'API de salenv-exec; salenvexec-safe est une version avec une dtection plus d'erreur, tandis que salenv et salenv de scurit sont les scripts shell de haut niveau invoqu par des outils autres SAL. En outre, la distribution inclut les outils suivants exprimentaux. Ce sont incompltes et peuvent tre buggy, nous ne nous engageons pas les maintenir. Ils sont mis disposition afin que d'autres peuvent exprimenter leurs capacits ou de construire sur leur source. Sal-sim

Le simulateur de SAL, ce qui est un frontal interactive des outils SAL autres. Sal-wmc

Le vrificateur tmoin SAL modle, ce qui est un vrificateur de modle exprimental CTL. Sal-path-finder

Un outil auxiliaire, bas sur le model checker born, qui gnre des chemins alatoires. Sal-emc

La SAL vrificateur explicite modle de l'tat. Sal-path-explorer : Un outil auxiliaire, bas sur le model checker explicite de l'tat.
119

Bibliographie

120

BIBLIOGRAPHIE
[Abrial, 1996]: Jean-Raymond Abrial. The B-Book: Assigning Programs to Meanings. Cambridge University Press, 1996. [Adam, 2000] : Emmanuel ADAM : Modle d'organisation multi-agent pour l'aide au travail coopratif dans les processus d'entreprise : application aux systmes administratifs complexes. PhD thesis, UNIVERSIT DE VALENCIENNES ET DU HAINAUTCAMBRSIS, 2000. [Cossentino et al, 2009]: Massimo Cossentino, Nicolas Gaud, Vincent Hilaire, Stphane Galland et Abderraa Koukam : ASPECS: an agent-oriented software process for engineering complex systems, How to design agent societies under a holonic perspective. Published online: 7 June 2009, Springer Science+Business Media, LLC 2009. [Cossentino et al, 2007]: Massimo Cossentino, Nicolas Gaud, Vincent Hilaire, Stphane Galland et Abderraa Koukam: A Verication by Abstraction Framework for organizational Multi-Agent Systems, 2007. [Dastani et al, 2005]: Mehdi Dastani, Jorge J. Gomez-Sanz: Programming multi-agent systems (promas), a report of the technical forum meeting, April 2005. URL: http://people.cs.uu.nl/mehdi/tfg/ljubljanafiles/report.pdf. [Derrick, 2005]: John Derrick, Siobhan North and Anthony J. H. Simons: Z2SAL building a model checker for Z, University of Sheffield, Sheffield, 2005. [Diaz, 2001] : Diaz, Michel. Les Rseaux de Petri Modles fondamentaux, Hermes Science Publications : Paris. [Duke, 2000]: Roger Duke and Gordon Rose: Formal Object-Oriented Specification Using Object-Z. MacMillan, 2000. [Demazeau et al, 1994] : Y. Demazeau, G. Masini, H. Skaf, O. Boissier, Une architecture Multi-Agents pour l'implmentation du bas niveau d'un systme de comprnsion de scnes, Actes des deuximes journes francophones sur les Systmes Multi-Agents organises par l'AFCET, 1994. [Ferber, 1995] : Jacques Ferber : Les Systmes Multi-Agents : Vers une Intelligence Collective. InterEditions, 1995. [Franck et al, 2003] : Franck Cassez et Olivier H. Roux : Traduction structurelle des Rseaux de Petri Temporels vers les Automates Temporiss, 1re soumission MSR 03, le 26 fvrier 2003.
[FIRA_Robot_Soccer] : FIRA Robot Soccer-ASPECSWiki : www.aspecs.org/FIRA_Robot_Soccer

121

[Gaud, 2007] : Nicolas A. GAUD : THSE : SYSTMES MULTI-AGENTS HOLONIQUES : DE LANALYSE LIMPLANTATION. Mta-modle, mthodologie, et simulation multiniveaux. Thse UTBM, 2007. [Graeme, 2002]: Graeme Smith and Ian Hayes: An Introduction to Real-Time Object-Z, University of Queensland, Brisbane, Australia, Formal Aspects of Computing, 2002. [Graeme, 2005]: Graeme Smith and Luke Wildman: Model checking Z specification using SAL, University of Queensland 4072, Australia, 2005. [Hilaire, 2000] : Vincent Hilaire : Vers une approche de spcification, de prototypage et de vrification de systmes Multi-Agents. PhD thesis, Universit de Technologie de BelfortMontbliard, 2000. [Isern et al, 2011]: David Isern, David Snchez, Antonio Moreno: Organizational structures supported by agent-oriented methodologies, The Journal of Systems and Software, 2011. [JTocher, 1994]: Alastair JTocher and Gray Girling: Z and Object Z Notations in FrameMaker Documents, 1994. [Jens, 2007]: Jens Zimmermann and Lars Mnch: Design and Implementation of Adaptive Agents for Complex Manufacturing Systems, 2007. [Kimber, 2007] : Tim G. Kimber: Object-Z to Perfect Developer. IMPERIAL COLLEGE LONDON DEPARTMENT OF COMPUTING, 2007 [Kulkarni, 2007]: Anikket Kulkarni, Ravindra Metta, Ulta Shrotri and R. Venkatesh : Scaling up Model-checking, @Springer, 2007. [Koestler, 1967] : Koestler, Arthur. The Ghost in the Machine. London: Hutchinson. 1990 reprint edition, Penguin Group, 1967 [Lemoigne, 1994] : J.L.Lemoigne : La thorie du systme gnral thorie de la modlisation, Editions Presses Universitaires de France, 4me d. 1994. [Leito, 2000]: Paulo Leito : A Formal Specification Approach for Holonic Control Systems. The ADACOR Case. Polytechnic Institute of Bragana, Quinta Sta Apolnia, Apartado 1134. [Manna, 1991]: Manna, Z and Pnueli, A: The Temporal Logic of Reactive and Concurrent System: Specification. Springer, 1991. [Mazigh, 1994] : Belhassen MAZIGH : Modlisation et valuation des systmes de production par les rseaux de Petri stochastiques gnraliss. PhD thesis, UNIVERSIT DE HAUTE ALSACE, 1994. [Mazigh et al, 2011]: Belhassen MAZIGH, Mohamed GAROUI, Abderraaa KOUKAM: Heterogeneous Formal specification of a Holonic MAS methodology based on Petri Nets and
122

Object-Z. MAS&S 2011. Proceedings of the Federated Conference on Computer Science and Information Systems pp. 661668, 2011. [Monch, 2005]: Lars Monch: Marcel Stehli, ManufAg: a multi-agent-system framework for production control of complex manufacturing systems, 2005. [Memmi, 2007] : Anis El Memmi; Une approche multi-formalisme pour la spcification formelle des systmes Multi-Agents. Master de recherche soutenu en janvier 2007 la facult des sciences de Monastir, pourcentage dencadrement : 100% [Pablo, 2003]: Pablo Gruer, Vincent Hilaire, Adder Koukam and P. Rovarini: Heterogenous formal specification based on Object-Z and statecharts: semantics and verification, The Journal of Systems and Software, 2003. [Pablo, 2004]: Pablo Gruer, Vincent Hilaire, and Adder Koukam, Verification of Object-Z Specification by using Transition Systemes: Application to the Radiomobile Network design problem. Universit de Technologie de Belfort-Montbliard, 2004. [Paige, 1997]: Richard Freeman Paige: FORMAL METHOD INTEGRATION VIA HETEROGENEOUS NOTATION. University of Toronto. 1997. [Pradat-Peyre, 2002] : J. F. Pradat-Peyre : Spcification des problmes concurrents : Modlisation avec les rseaux de Petri et les rseaux de haut-niveau, 2002. [Rodrguez, 2005]: Sebastin A. Rodrguez : FROM ANALYSIS TO DESIGN OF HOLONIC MULTI-AGENT SYSTEMS: A FRAMEWORK, METHODOLOGICAL GUIDELINES AND APPLICATIONS. PhD thesis, Universit de Technologie de Belfort-Montbliard, 2005. [Shankar, 2000]: Natarjan Shankar: Symbolic Analysis of Transition Systems, Computer Science Laboratory, Invited pape rat the ASM2000 Workshop, 2000. [Smith, 2000]: Graeme Smith: The Object-Z Specification Language. Kluwer Academic Publishers, 2000. [Smith, 2002]: Graeme Smith and Ian Hayes: An Introduction to Real-Time Object-Z. University of Queensland, Brisbane, Australia, 2002. [Spivey, 1992]: J. M. Spivey: The Z Notation: A Reference Manual; This edition rst published 1992 by Prentice Hall International (UK) Ltd. University of Oxford, 1992.

123