Les protocoles A-UML dans ADELFE

Le diagramme de protocole développé pour ADELFE est une évolution du diagramme de séquences générique d’UML1.4. Il permet de faire intervenir des classes et des rôles de classe d’agent, et de les faire communiquer entre eux. Comme c’est un diagramme géné- rique, il peut être attribué à n’importe quel objet.

Il faut noter que la notion de rôle est uniquement relative à un protocole, et donc est très locale. Ce concept est légèrement différent du concept de rôle tel que l’on a pu en parler dans le paragraphe 2.4, qui représente un rôle dans une organisation générale et non point à point. Dans notre cas – celui des AMAS –, un agent ne joue pas un rôle dans le système, mais jour un rôle pour une interaction ponctuelle.

Outre les lignes de vie avec les rectangles d’activation et les envois de message, il est possible de saisir des embranchements (ou jonctions)AND (barre verticale), OR (losange), etXOR (losange avec une croix), comme il est spécifié dans les propositions A-UML, et de fournir certaines connaissances supplémentaires sur les envois de messages, comme le trai- tement coopératif à la réception d’un message, par exemple. Il est également possible d’y spécifier des clausesIF...ELSE...ENDIF, permettant plus d’expressivité lors de la conception des protocoles. L’introduction de ces clauses est la conséquence directe de l’analyse des spé- cifications d’ABROSE, dans lesquelles les protocoles de communication en faisait souvent usage de simple notes sur les diagrammes pour exprimer des alternatives de haut niveau ayant une sémantique particulière [Gleizes et al., 2000].

Un exemple de diagramme de protocole pour ADELFE est présenté en figure 4.1. Ce pro- tocole est celui présenté par Odell et al. dans les premières spécifications d’A-UML [Odell et al., 2000]. Cependant, quelques différences existent ; notamment, les flèches en pointillés signalent des interactions potentiellement non coopératives auxquelles sont associés des opérations de traitementcooperation.

4.2.1.1 Contraintes de spécification des protocoles

Les diagrammes de protocoles étant destinés à une transformation en machine à états pour tester le comportement par simulation, ces diagrammes doivent obéir à certaines contraintes :

– le temps graphique n’a de sens qu’au sein d’une activation, ceci en raison de l’intro- duction des jonctions_{AND, OR et XOR qui perturbent la disposition graphique ;}

– le diagramme de protocoles doit commencer par un message initial ;

– un déroulement du protocole sous forme d’arbre doit être possible à partir du message initial ; toutefois, certaines exceptions sont possibles.

Les rectangles d’activation du protocole fournissent une trame de continuité au sein d’un enchaînement possible d’envois de messages : le message qui suit un message est recher-

Buyer / Buyer Role contractInitiation() Seller / Seller Role seller_cfp() inform() «cooperation» : op2 cancel() x not_understood() propose() «cooperation» : op2 [NOT(deadline)] aptitude1() x refuse_1() «cooperation» : op2 refuse_2() analyze_failure() x test_proposal() accept_proposal() reject_proposal() Buyer / Buyer Role contractInitiation() Seller / Seller Role seller_cfp() inform() «cooperation» : op2 cancel() x not_understood() propose() «cooperation» : op2 [NOT(deadline)] aptitude1() x refuse_1() «cooperation» : op2 refuse_2() analyze_failure() x test_proposal() accept_proposal() reject_proposal()

Figure 4.1 — Un exemple de protocole dans ADELFE.

ché dans l’activation réceptrice de ce message (message graphiquement immédiatement en- dessous du départ de cette activation). Les embranchements sont dus à l’introduction des jonctionsAND, OR ou XOR, et de clauses IF. Les cas suivants, qui présentent une rupture de continuité, sont cependant compris :

– envoi de plusieurs messages successifs à partir d’une classe ou rôle d’agent ;

– réception de plusieurs messages successifs sur une classe ou rôle d’agent ;

– rupture de continuité, via les rectangles d’activation, suivie d’une clauseIF ;

– rupture de continuité, via les rectangles d’activation, suivie de la clause_{ELSE d’un IF ;}

– rupture de continuité, via les rectangles d’activation, suivie de la clauseENDIF d’un IF.

4.2.1.2 Utilisation des diagrammes de protocole

Lignes de vie. Lors de la création d’une ligne de vie, il faut lui associer une classe, et un rôle d’agent s’il s’agit d’un agent qui en possède plusieurs. Il est important de créer au moins un rôle d’agent par classe agent susceptible d’en avoir plusieurs, pour pouvoir éventuellement en introduire d’autres par la suite, et d’utiliser le rôle d’agent pour créer une ligne de vie, et non l’agent lui-même.

Messages. Les envois de messages ne peuvent être créés que sur des rectangles d’activa- tion et des jonctionsAND, OR ou XOR. Il est possible de créer sur une ligne de vie autant de rectangles d’activation que l’on veut. Sur création d’un envoi de message, ne doivent être

4.2. Extensions d'A-UML dans ADELFE AMA selectIndirectRequest() fillRequest() if infoNot Displayed else updateEvalInterface() updateEvalInterface() TA / Custom getMyUserList() displayUserList() treatMessage() displayUserList() treatMessage() getUserList() treatMessage() getInfo() displayInformationList() displayInformationList() treatInfoSpeed() displayInformationList() treatMessage() MA putMessage() treatMessage() TA / CP UAM getReferenceTAbyLoginName() FE connectTheRequested() putMessage() getReferenceTAbyLoginName()

Figure 4.2 — Un exemple de protocole de requête indirecte avec clauseIF (rectanggle de

couleur à gauche de la ligne de vie deAMA.

proposées que les opérations publiques stéréotypéesinteraction. Il est possible de préciser une opération stéréotypéecooperation à la réception d’un envoi de message : ceci permet de renvoyer à d’autres comportements traités dans d’autres protocoles, par exemple.

Jonction. Une jonction AND, OR ou XOR doit être rattachée à une classe ou à un rôle

d’agent. Cependant, il faut faire attention aux règles qui sont différentes selon le type de jonction. Le message interne qui va d’un agent à un losange " OR " ou " XOR " doit porter une opération agent stéréotypéeaptitude : l’indéterminisme des jonctions A-UML représente l’autonomie de décision des agents.

Clauses _{IF...ENDIF ou IF...ELSE...ENDIF.} Ces clauses sont liées, à leur création, à une classe ou un rôle d’agent, et doivent porter une condition qui est une opération booléenne de cette classe. La figure 4.2 présente un exemple de clauseIF bien formée. Le positionnement graphique d’une clause_{IF est de première importance :}

– Une clauseIF n’a d’effet que s’il y a rupture préalable d’enchaînement au travers des activations qui la précèdent (fin apparente via la trame de continuité des activations) ;

– Le point de départ de la clause correspond graphiquement au haut de son rectangle ;

– Il doit y avoir à nouveau rupture de la continuité des activations avant leELSE éven- tuel, puis redémarrage après leELSE éventuel d’une nouvelle chaîne d’activations, et de même, rupture avant la fin du rectangle de la clause_{IF qui correspond au ENDIF ;}

– Il est conseillé de placer, pour plus de lisibilité, la clauseIF à proximité de la classe ou du rôle d’agent auquel elle est rattachée.

4.2.1.3 Diagrammes de séquence d’instances enrichis

Le diagramme de séquence d’instances d’UML1.4 a également été enrichi de manière à prendre en compte le concept de rôle d’agent, ainsi que les jonctions_{AND, OR, et XOR. Ce} type de diagramme peut être utilisé à titre documentaire, mais il ne pourra être ni utilisé comme protocole associable à une classe, ni transformé en machine à états.

Le concept de rôle d’agent a été introduit de la manière suivante :

– un rôle d’agent est relatif à une et une seule classe agent ;

– une classe agent peut avoir plusieurs rôles d’agent ;

– il est toujours possible de représenter des instances sans rôle d’agent ;

– la ligne de vie peut être simple ou porter des rectangles d’activation ;

– dans la ligne de vie dédiée à une instance caractérisée par un rôle d’agent, le titre est construit avec :<nom instance>/<nom rôle agent> : <nom classe>.