Opérations et propriétés observables des OrgArts

Les opérations et les propriétés observables d’un artefact organisationnel per- mettent aux agents d’interagir avec l’entité organisationnel à laquelle ils appar- tiennent.

Les propriétés observables permettent essentiellement aux agents d’obtenir des in- formations sur l’entité organisationnelle. Comme nous l’avons dit ci-dessus, elle sont définies à partir d’attributs de l’OrgArt auquel ils appartiennent et les valeurs de leur données peuvent changer au cours du cycle de vie de l’entité organisationnelle. Ces changements sont généralement dûs à l’exécution d’une opération. C’est pour cette raison que nous ne présentons pas l’implémentation des propriétés observables dans

Implémentation des artefacts organisationnels 180 une section distincte de celle des opérations. Dans les paragraphes ci-dessous nous présenterons quelques propriétés observables dont les valeurs des données changent suite à l’exécution des opérations dont nous décrivons l’implémentation.

Les opérations encapsulent les mécanismes de gestion des entrées / sorties, des en- gagements aux missions et de régulation des agents. Elles ne peuvent être exécutées que si l’OrgArt est dans l’état "active". Nous présentons ci-dessous deux opérations de chacun des type d’OrgArt PortalBoard, GroupBoard et SchemeBoard. Nous ne présentons que deux opérations par type d’OrgArt pour réduire la longueur du cha- pitre. Les opérations que nous avons choisis de présenter sont celles qui assurent les principales fonctionnalités du type d’OrgArt auquel elles appartiennent.

Opération duPortalBoard

1. createCFAC : cette opération sert à créer des appels à candidatures qui se- ront gérés par lePortalBoard. La signature de cette opération est présentée ci- dessous.

@OPERATION v o i d c r e a t e C F A C ( S t r i n g c f a c I d , S t r i n g g a t e I d , S t r i n g g r p B o a r d I d , S t r i n g s c h B o a r d I d )

L’exécution de cette opération a besoin de quatre paramètres : – cfacId : l’identifiant qui sera attribué à l’appel à candidature.

– gateId : l’identifiant de la porte définie dans la spécification de l’instance de portail gérée par lePortalBoard. C’est cette porte qui fournira les principales données (cible, exigences, ...) du CFAC (Cf. Section 6.1.5).

– grpBoardId : l’identifiant de l’instance deGroupBoarddans laquelle est géré le rôle associé à la cible de gateId. C’est dans cette instance deGroupBoard

que seront enregistrés les candidats qui seront retenus pour cfacId.

– schBoardId : la valeur de ce paramètre peut être nulle si la cible de gateId est de la forme(r, _, _). Dans le cas contraire sa valeur est l’identifiant de l’ins- tance deSchemeBoarddans laquelle est gérée la mission associée à la cible de gateId. C’est dans cette instance deSchemeBoardque devront s’engager à la mission concernée, les agents dont la candidature aura été retenue pour cfacId.

L’exécution de cette opération consiste à créer un objet CFAC et à activer le compteur de sa durée de publication (timeout Cf. Section 6.1.5). L’appel à can- didature est alors enregistré dans la propriété observableCFACsduPortalBoard.

Implémentation des artefacts organisationnels 181

Un exemple d’appel de cette opération par un agent pour les portega1 etga2

de l’exemple write-paper est présenté dans l’annexe 6.1.1.

Les figures 8.6(a) et 8.6 présentent les données de la propriété observable

CFACsdans un exemple d’instance dePortalBoard.

2. submitCandidature : la signature de cette opération est la suivante.

@OPERATION v o i d s u b m i t C a n d i d a t u r e ( S t r i n g c f a c I d , S t r i n g c a n d i d a t u r e )

Ses deux paramètres représentent respectivement (1) l’identifiant de l’appel à candidature pour lequel l’agent soumet sa candidature et (2) une chaîne de ca- ractères qui comprend toutes les informations d’une candidature tel que décrit dans la Section 6.2.1.1.

Son exécution entraîne la création d’un objet candidature après une analyse syn- taxique du deuxième paramètre afin d’en extraire des données qui seront enre- gistrées dans la candidature. L’objet créé est ensuite enregistré dans une liste de candidatures de l’appel à candidature cf acId. Les candidatures sont analysées à la fin du délai de publication (timeout) du CFAC si sa valeur est finie, dans le cas contraire, elle sont analysées au fur et à mesure de leur soumission. Le résultat de l’analyse des candidatures est enregistré dans la propriété observable

selectedAgentdont un exemple est présenté sur la figure 8.7(a).

Lorsqu’un agent est admis pour un appel à candidature et que son contrat est créé et validé, il est transmis au GroupBoard associé à l’appel à candidature pour y être enregistré. Les propriétés observablesRolePlayersetContracts

sont mises à jour. Les figures Fig. 8.7(b), Fig. 8.8(a) et Fig. 8.8(b) montrent des exemples de valeurs des ces propriétés observables.

Opération duGroupBoard

1. addRespOrgArt : la signature de cette opération est présentée ci-dessous. Elle permet d’associer à une instance de GroupBoard soit des instances dePortal- Board qui gèreront les entrées et / ou les sorties des agents dans l’instance de GroupBoard, soit des instances de SchemeBoarddont les agents ayant un contrat dans leGroupBoard, pourront être en charge.

Implémentation des artefacts organisationnels 182 Le premier paramètre de l’opération est l’identifiant de l’artefact organisation- nel à enregistrer et le second paramètre est son type. Ce dernier permet de sa- voir dans quelle liste l’OrgArt doit être enregistré. Lorsque l’enregistrement se déroule correctement, le résultat est visible selon le type de l’OrgArt par les propriétés observables responsiblePortalset responsibleSchemesdu

GroupBoard(Cf. Figure 8.3(b)) et dans la propriété observableGroupBoards

duPortalBoardsi le type de l’OrgArt estGroupBoardouresponsibleGroups

duSchemeBoardsi le type estSchemeBoard(Cf. Figure 8.3(a) et 8.3(b)). 2. leaveClause : cette opération permet aux agents de faire une demande d’aban-

don de clause de leur contrat après que celui-ci soit enregistré dans le Group- Board. Une demande d’abandon de clause implique l’analyse des exigences d’abandon associées aux rôle, mission, et buts qui définissent la clause. Elle peut donner lieu à un échange de messages entre l’agent qui souhaite abandon- ner la clause et l’agent organisationnel qui supervise le GroupBoard. En cas d’accord entre l’agent organisationnel qui supervise le GroupBoard et l’agent qui veut abandonner la clause, cette dernière est supprimée dans le contrat. La signature de cette opération est la suivante.

@OPERATION v o i d l e a v e C l a u s e ( S t r i n g a g e n t I d , S t r i n g c l a u s e I d )

L’exécution de l’opération supprime la clause dont l’identifiant est clauseId dans le contrat de l’agent dont l’identifiant estagentId.

Opération duSchemeBoard

1. commitMission : cette opération permet aux agents de s’engager explicitement dans une instance deSchemeBoardaux missions pour lesquelles ils ont une ou plusieurs clause(s) dans leur(s) contrat(s) (CF. section 7.3.4). La signature de l’opération est présentée ci-dessous.

@OPERATION v o i d c o m m i t M i s s i o n ( S t r i n g a g e n t I d , S t r i n g m i s s i o n I d )

Cette opération nécessite deux paramètres : l’identifiant de l’agent qui veut s’engager et l’identifiant de la mission à laquelle il veux s’engager. Avant l’exé- cution de cette opération, l’état de la missionmissionId pour l’agent agentId dans la propriété observable NormStatus est notCommited dans l’instance de SchemeBoard concerné par l’opération (Cf. Figure 8.11(a)). Lorsque l’exécution de l’opération se déroule correctement l’état de la mission est mis à

Agents utilisant ORA4MAS 183 jour avec la valeur commited dans la propriété observable NormStatus et le nom de l’agent est rajouté dans la liste des nom des agent qui se sont engagés à la missionId dans la propriété observableMissionPlayers(Cf. Figure 8.9(a)).

2. updateGoalState : cette opération présentée comme la précédente dans la Sec- tion 7.3.4 permet aux agents de mettre à jour l’état des buts qu’ils ont à réaliser. La signature de l’opération présentée ci-dessous montre qu’elle nécessite deux paramètres. Le premier est l’identifiant du but dont l’agent voudrait mettre à jour l’état et le second est le nouvel état du but.

@OPERATION v o i d u p d a t e G o a l S t a t e ( S t r i n g g o a l I d , S t r i n g g o a l S t a t e )

Pour que cette opération s’exécute correctement pour un but dont l’identifiant est goalId, l’état de ce but doit avoir la valeur active dans la propriété obser- vablegoalStatus. Dans le cas contraire l’exécution de l’opération génère une erreur. Les valeurs de goalState peuvent êtreachieved ou impossible. Dans le cas où l’exécution se déroule correctement c’est-à-dire sans générer d’erreur, l’état du but est mis à jour avec sa nouvelle valeur.

Un exemple de changement des valeurs des buts de la propriété observable

goalstatusest présenté par les figures Fig. 8.11(a) et Fig. 8.11(b).