4.2 Extensions d’A-UML dans ADELFE
4.2.2 Transformation en machine à états finis
Comme il a été précisé plus haut, afin d’unifier les notations et de faciliter la simulation, nous proposons de transformer les protocoles d’interaction, tels que spécifiés ci-dessus, en machines à états finis. Ce paragraphe expose la méthode à suivre et est illustré par la trans- formation du protocole de la figure 4.1.
4.2.2.1 Construction de machines à états finis à régions concurrentes
Tout d’abord, une machine à état initiale est attribuée à chaque classe cooperative agent. Cette machine est composée d’un état initial et d’un état composite Alive. Dans ce dernier, un région concurrente est ajoutée pour chaque rôle tenu par l’agent, comme le montrent les figures 4.3 et 4.4. Ici, un seul rôle provient d’un protocole (région du haut). Bien sûr, d’autres régions concurrentes peuvent être ajoutées pour d’autres comportements dy- namiques, par exemple la région du bas dans les figures présentées. Ensuite, chaque région concurrente est développée comme une machine à états. Ceci permet à l’agent de pouvoir répondre et participer à plusieurs protocoles à la fois.
Chacune de ces sous-machines est composée de deux états principaux : un étatIdle, par défaut, et un état, ayant, par convention, le même nom que l’événement initiateur du pro- tocole pour le rôle avec la première lettre en majuscule. Dans le protocole, le rôleBuyer Role est activé à la réception de l’événementcontractInitiation. Par conséquent, la région concur- rente correspondant à ce rôle contient un étatContractInitiation. De même, le rôle Seller Role est activé à la réception de l’événementseller_cfp. Par conséquent, la région concurrente correspondant à ce rôle contient un étatSeller_cfp. Ces deux états principaux sont reliés par des transitions bidirectionnelles : ainsi, un agent peut exécuter plusieurs fois un protocole. L’agent sort de l’étatIdle lorsqu’il reçoit l’événement de début de protocole (transition Idle vers "état de rôle"). Pour sortir du protocole (transition "état de rôle" versIdle), il y a deux possibilités : soit le protocole est arrivé à son terme pour ce rôle, soit une exception s’est produite suite à une SNC, par exemple.
4.2. Extensions d'A-UML dans ADELFE Alive ContractInitiation Idle BuyerRoleProtocoleAUML exception_BuyerRole contractInitiation Idle Alive ContractInitiation Idle BuyerRoleProtocoleAUML exception_BuyerRole contractInitiation Idle
Figure 4.3 — Machine à états finis pour la classe Buyer du protocole de la figure 4.1.
Alive Idle Idle Seller_cfp seller_cfp exception_SellerRole SellerRoleProtocoleAUML Alive Idle Idle Seller_cfp seller_cfp exception_SellerRole SellerRoleProtocoleAUML
Figure 4.4 — Machine à états finis pour la classe Seller du protocole de la figure 4.1.
ajouté à l’état composite du rôle pour chaque réception ou émission de message, comme le montre la figure 4.5. Par exemple, un sous-étatSeller_cfp_sent est associé à l’envoi du mes- sageseller_cfp. De même, un état Refuse_1 est associé à la réception du message refuse_1.
Les transitions entre états sont créées à la réception ou à l’émission d’un message. Par exemple, quand l’agentBuyer se trouve dans l’état Seller_cfp_sent et reçoit le message re- fuse_1, une transition est créée entre les états Seller_cfp_sent et Refuse_1. Si un état ne reçoit ou n’envoie plus aucun message, il est relié à un état final avec l’action de retour à l’étatIdle.
4.2.2.2 Jonctions A-UML et clausesIF
Concernant les jonctions A-UML, une opération stéréotypéeaptitude est associée au processus de décision du branchement, et, par conséquent, une action d’entrée (entry) est ajoutée dans l’état correspondant à l’envoi du message. Cette action exécute l’aptitude qui renvoie la signature de l’opération à activer et le résultat est mémorisé dans une variable conditionResult. Dans le cas de jonctions XOR ou OR à n branches, il faut créer n transitions. Dans la figure 4.5, les conditions correspondant à la jonction XOR sont [conditionResult = "seller.acceptProposal"] et [conditionResult = "seller.refuseProposal"]. Ces conditions sont at- tachées aux transitions vers les étatsAccept_proposal_sent et Reject_proposal_sent.
Pour les branchementsAND, un état appelé AND est créé, et la transition vers cet état est créée avec une action composite exécutant les opérations à effectuer en séquence. Les contraintes, comme des échéances (deadlines), sont exprimées par des opérations renvoyant des booléens et traitées par des transitions conditionnelles : si la condition est vraie, l’auto- mate continue (ainsi que le protocole), sinon il revient à l’étatIdle, comme le montre la figure 4.6.
La distinction des rôles d’agent d’un agent est faite dans la structure concurrente des
Contract Initiation Seller_cf p _sent / seller.seller_cfp(); Refuse_1 entry / op2; refuse_1 / BuyerRoleProtocoleAUML Refuse_2 entry / op2; refuse_2 / BuyerRoleProtocoleAUML Not_ understood not_understood / BuyerRoleProtocoleAUML Propose entry / test_proposal(); propose Accept_ proposal_ sent [conditionResult = "seller. accept_proposal()"] / seller.accept_proposal(); / BuyerRoleProtocoleAUML Reject_ proposal_ sent [conditionResult = "seller. reject_proposal()"] / seller.reject_proposal( ); Inform inform Cancel_ sent / seller.cancel(); / BuyerRoleProtocoleAUML
Figure 4.5 — Sous-machine de l’étatContractInitiation de la classe Buyer pour le rôle Buyer
Role. Seller_rfp [NOT(NOT(deadline))] / SellerRoleProtocoleAUML Aptitude1 entry / aptitude1(); [NOT(deadline)] Analyze_failure_sent entry / analyze_failure(); [conditionResult = "THIS.analyze_failure()"] Refuse_1_ sent entry / op2; [conditionResult = "buyer.refuse_1()"] / buyer.refuse_1(); / SellerRoleProtocoleAUML Refuse_2_ sent entry / op2; [conditionResult = "buyer.refuse_2()"] / buyer.refuse_2(); / SellerRoleProtocoleAUML Not_ understood _sent [conditionResult = "buyer.not_understood()"] / buyer.not_understood(); / SellerRole ProtocoleAUML Propose_ sent [conditionResult = "buyer.propose()"] / buyer.propose(); [NOT(conditionResult = "seller.acceptProposal")] / SellerRoleProtocoleAUML Accept_ proposal [conditionResult = "seller.acceptProposal"] Accept_ proposal1 accept_proposal / SellerRoleProtocoleAUML [NOT(conditionResult = "seller.refuseProposal")] / SellerRoleProtocoleAUML Reject_ proposal [conditionResult = "seller.refuseProposal"] Reject_ proposal1 reject_proposal Inform_ sent
/ buyer.inform(); cancel Cancel
/ SellerRoleProtocoleAUML
Figure 4.6 — Sous-machine de l’étatSeller_cfp de la classe Seller pour le rôle Seller Role.
machines à états ; ainsi, cette distinction n’est pas à faire au moment de l’envoi : l’événement est envoyé à un agent, dont une ou plusieurs de ses régions concurrentes sont capables de traiter l’événement, à ce moment-là.
La transition équivalente à une jonctionAND porte, en action à exécuter, l’envoi de tous les événements des branches du AND. Par contre, le même message envoyé à différents rôles d’une instance ne fait l’objet que d’un seul envoi. Le nom de l’état d’arrivée est consti- tué deAND, auquel s’ajoute éventuellement un numéro pour obtenir un identifiant unique. Il convient de rechercher ensuite les chemins de continuité (ceux qui permettent d’arriver à une réception d’événement pour le rôle d’agent courant) pour chacun des événements envoyés afin de poursuivre l’arbre de la machine à états.
Avec la jonctionAND, tous les événements sont envoyés ; avec la jonction XOR, un seul est envoyé. Nous étions alors dans des cas simples. Dans le cas des jonctions OR se pose le problème de la combinatoire de n événements. La proposition actuelle laisse l’opération aptitude effectuer dans son code les envois de messages selon son analyse, et la machine à états ne présume pas des chemins de continuité qui peuvent en résulter ; par contre, l’ex- ception est chargée de lever un éventuel blocage dans un état (cas où aucune des transitions
4.2. Extensions d'A-UML dans ADELFE
SelectIndirect
Request / tA.getMyUserList(); GetMyUserList_sent
DisplayUserList displayUserList entry / fillRequest(); GetUser List_sent / tA.getUserList(); Display UserList1 displayUserList IF [infoNotDisplayed] GetInfo_ sent / tA.getInfo(); DisplayInformationList displayInformationList entry / updateEvalInterface(); ELSE [NOT(infoNotDisplayed)] DisplayInformationList1 displayInformationList entry / updateEvalInterface(); ENDIF Multiple_ sent / fE.connectTheRequested(); tA.treatInfoSpeed(); DisplayInformationList2 displayInformationList / AMAProtocoleIndirectRequest2
Figure 4.7 — Sous-machine de l’étatSelectIndirectRequest de la classe AMA du protocole
de la figure 4.2.
proposées en sortie n’est franchissable). Un message réflexif, lui, est considéré comme un traitement interne et vient compléter le code de la clause entry de l’état courant.
Lors de la génération de la machine à états, il y a prise en compte de la branche cou- rante du protocole si des jonctions XOR sont rencontrées. Un problème peut survenir si l’on revient sur des rectangles d’activation distincts d’une même classe (ou rôle d’agent) via un même événement, sans qu’il y ait moyen de distinguer dans la machine à états d’où l’on vient ; cependant cette ambiguïté peut être détectée en traçant les messages et en les identi- fiant.
Les protocoles affichant des clauses IF sont transformables en machines à états finis, comme le montre la figure 4.7. A partir de l’état arrivant sur leIF, deux états, IF et ELSE sont créés avec des transitions dont la garde correspond à la condition de la clause. Les deux chemins résultants se rejoignent ensuite sur un étatENDIF.
4.2.2.3 Remarques
Voici un bref récapitulatif des règles de bonne formation d’un protocole A-UML dans ADELFE :
3 un protocole doit débuter par un message initial ;
3 les messages provenant d’un XOR, OR ou AND et arrivant sur une même classe doivent être sur des activations distinctes ;
3 nécessité d’une connaissance de la manière atteindre le récepteur d’un message : exis- tence d’une association unique entre les classes communicantes ;
3 un message peut s’accrocher à des activations ou des jonctions (pas directement sur la ligne de vie) ;
3 le temps graphique n’a de sens qu’au sein d’une activation ;
3 une opération de stéréotypeaptitude précédant une jonction XOR ou OR est placée dans la clause entry de l’état courant ;
3 un message réflexif doit voir sa flèche arriver sur sa propre activation, et donc avant
tout autre message envoyé à suivre ;
3 le déroulement d’un protocole doit avoir, a priori, une structure d’arbre ; cependant les cas suivants sont traités :
@ envoi de n messages consécutifs depuis une même activation (traité comme un AND) ;
@ réception de n messages consécutifs sur une même activation (traité comme la né- cessité de recevoir ces messages les uns après les autres) : l’ordre de réception est pris en compte, ce qui signifie que la machine à états ne fonctionne plus si l’ordre n’est pas respecté ;
@ rupture de continuité puis clauseIF, ELSE ou ENDIF ;
3 les choix conditionnels peuvent s’exprimer par unXOR ou par une condition ou par une clauseIF...ENDIF ou IF...ELSE...ENDIF :
@ leXOR convient lorsque le choix est suivi de différents messages issus de ce même émetteur ;
@ une condition sur un message permet au protocole de continuer si la condition est vraie, mais l’arrête si elle est fausse ;
@ une clauseIF...ENDIF ou IF...ELSE...ENDIF est rattachée à une activation : elle est testée à la position du sommet de sa boîte graphique, et permet de réaliser une ou deux dérivations ; elle n’est prise en compte que sur rupture de la chaîne des activations :
– il faut donc préalablement auIF qu’il y ait rupture de continuité des messages via les activations ;
– le message suivant est recherché sur l’activation liée auIF selon sa position en ordonnées (côté cible) ;
– il y a lecture des messages pour cette nouvelle chaîne d’activations qui doit se terminer avant leELSE éventuel ou le ENDIF (bas du rectangle du IF) ;
– s’il y a unELSE, une chaîne de messages, via des activations démarrant après le ELSE et finissant avant le ENDIF, doit être prise en compte ;
– pas d’imbrication possible de protocoles avec ces méthodes.