Instance de groupe

Chaque instance de groupe d’une entité organisationnelle gère des rôles de sa spé- cification qui sont joués par des agents. En effet, une instance de groupe est créée à par- tir d’un type de groupe défini dans la spécification structurelle. D’après l’équation 5.5, un type de groupe comprend entre autre un ensemble de rôles. Ces derniers peuvent être adoptés par des agents. Ainsi, l’entrée d’un agent dans une instance de groupe se fait par l’adoption d’un rôle. Les adoptions de rôles d’une instance de groupe sont gérées par l’instance de portail qui gère les entrées des agents dans cette instance de groupe. Nous présentons le processus d’entrée dans la section 6.2.1. Lorsqu’un agent entre dans une instance de groupe, un contrat pour cet agent est créé et enregistré dans cette instance de groupe. Chaque agent d’une instance de groupe a un seul contrat au sein de cette instance. Ce contrat comporte toutes les clauses relatives à chaque rôle adopté dans l’instance de groupe.

Une instance de groupe peut également avoir des instances de sous-groupes (Cf. fonction isubGrp définie dans l’équation 6.2 présentée ci-dessus). Une instance de groupe qui a des instances de sous-groupes gère la vérification des cardinalités d’ins- tances de sous-groupes spécifiées par la fonctionnggr de l’équation 5.5.

Par ailleurs, dans une entité organisationnelle, une instance de groupe est géné- ralement responsable d’une ou plusieurs instances de schémas-sociaux (Cf. fonction igrpIS définie dans l’équation 6.2 et Figure 6.1). Les clauses des contrats des agents d’une instance de groupe sont relatives aux missions gérées dans les instances de schémas-sociaux dont est responsable l’instance de groupe.

La gestion des agents jouant des rôles dans une instance de groupe se fait donc au moyen des clauses de leur contrat respectif, des cardinalités des rôles et des contraintes de compatibilité intra et inter groupes ainsi que les liens intra et inter groupes entre rôles qui sont définis dans sa spécification (Cf. Équation 5.5) et qui régissent la structure de l’instance de groupe. Rappelons que les contraintes de com- patibilité et les liens intra-groupes ont une portée qui inclue l’instance de groupe à ses instances de sous-groupes (Cf. section 5.3.3). Cette gestion intègre également la gestion des abandons de rôles et donc des exigences d’abandons associées aux rôles Cf. 5.3. Nous reviendrons sur cette gestion dans la section 6.2.2.

En résumé, étant donnée une instance de groupe d’une entité organisationnelle, on détermine :

– Son type à partir de la fonctiongrpT ype de l’équation 6.2 et donc la spécifica- tion du groupe définie dans la SS de l’entité organisationnelle.

Entité organisationnelle 119 – Les instances de schémas sociaux dont elle est responsable à partir de la fonction

igrpIS.

– Les agents de l’instance de groupe à partir des contrats obtenus par la fonction igrpCo.

Appartenance d’un agent à un groupe

Un agent est membre d’une instance de groupe signifie qu’il a réussi la procédure d’entrée dans cette instance et donc qu’il a un contrat enregistré dans cette instance de groupe. La seule exception à cette règle est lorsqu’un agent entre dans une instance de groupe qui est sous-groupe d’une autre instance de groupe. Dans ce cas, lorsqu’un agent est admis dans une instance de sous-groupe, il est également membre du ou des instances de groupe(s) parent(s) de cette instance de sous-groupe. Cependant, l’in- verse n’est pas vrai. En effet, lorsqu’un agent entre dans une instance de groupe qui a des instances de sous-groupes, cet agent n’est pas automatiquement membre de ces instances de sous-groupes. Il n’en sera membre que s’il y est admis à l’issue de l’exé- cution d’un processus explicite d’entrée.

La formalisation de cette notion d’appartenance d’un agent à une instance de groupe est représentée par la fonction ismember(ag, igr) présentée ci-dessous.

Nous verrons dans la section 6.16 qu’un contrat notéco est composé de deux prin- cipales parties, une entête et un ensemble de clauses. Parmi les éléments de l’entête d’un contrat on a l’identifiant de l’agent noté ag. Ainsi, la notation co.ag utilisée ci- dessous permet d’obtenir l’identifiant de l’agent auquel correspond un contrat.

∀ag ∈ A, ∀igr ∈ IG,

ismember(ag, igr) ⇐⇒ ∃co ∈ Co, co.ag = ag ∧ co ∈ coGrp(igr)
∨ ∃igr′ ∈ isubGrp(igr), ∃co′ ∈ Co, co′ .ag = ag ∧ co′ ∈ coGrp(igr′ )
(6.3) Remarques

1. Afin de simplifier le calcul de l’appartenance d’un agent membre de igr′

, ins- tance de groupe, aux instances de groupes englobants deigr′

, nous avons choisi de créer un contrat pour cet agent dans chacune de ces instances de groupe. Dans de tels contrats, seules les informations relatives à l’entête de contrat sont renseignées. En effet, l’agent étant implicitement membre du groupe parent, il n’y a donc pas lieu de mettre une clause. Ainsi selon la définition 6.16 d’un contrat présentée dans la section 6.1.6, la fonctionismember(ag, igr′

Entité organisationnelle 120 nie comme suit :

∀ag ∈ A, ∀igr, igr′

∈ IG, igr′

∈ isubGrp(igr) ismember(ag, igr′

) ⇐⇒ ∃co ∈ Co, co.ag = ag ∧ co ∈ coGrp(igr′

) ∧ ∃co′ ∈ Co, co′ .ag = ag ∧ co′ ∈ coGrp(igr), ∧ co′ .ContractantClauses = φ ∧ co′ .ContracteeClauses = φ
(6.4) 2. Les ensemblesco′ .ContractantClauses et co′

.ContracteeClauses sont vides à l’instantt où le contrat co′

est créé. Ils pourront être différents de l’ensemble vide plus tard à un instant t′

> t si l’agent ag adopte des rôles, missions et buts dans une instanceigr qui gère co′

. Ces adoptions donneront alors lieu à la création de clauses qui seront enregistrés dans co′

.ContractantClauses et/ou co′

.ContracteeClauses.

Exemple : Considérons la figure 6.2 qui représente trois instances de groupes group0, group1, group2, ainsi que deux instances de portails portal1, portal2. Les

instancesgroup1, group2 sont des instances de sous-groupes degroup0. On suppose

que (1) portal1 gère les entrées et les sorties de group2 pour les portesgate6, gate7.

(2) portal2 gère les entrées et les sorties degroup0 pour les portes gate1, gate2. (3)

portal2gère également les entrées et les sorties degroup1pour les portesgate3, gate4.

Pour les processus d’entrée, à chaque porte correspond un appel à candidature qui n’est pas représenté sur la figure.

– L’agent1est membre degroup0 suite à réussite de la procédure d’entrée auprès

de portal2 pour la porte gate1. Cependant il n’est ni membre de group1 ni

membre degroup2.

– L’agent2 est membre de group1 suite à la réussite de la procédure d’entrée

auprès de portal2 pour la porte gate4. Puisque group1 est un sous-groupe de

group0, il est aussi membre degroup0mais il n’est pas membre degroup2.

– L’agent3 est membre de group0 suite à la réussite de la procédure d’entrée

auprès deportal2 pour la portegate2. Il est également membre degroup2suite

à la réussite de la procédure d’entrée auprès de portal1 pour la portegate26. Il

n’est pas membre degroup1.

Remarque : Lorsque deux instances de groupes gr1etgr2 ne sont pas liées par une

Entité organisationnelle 121 group0 group1 group2 gate1 gate3 portal2 gate6 gate7 portal1 gate2 gate4 agent1 agent2 agent3 légende relation de sous-groupe

relation découlant de la fonction hasgatep(gr) relation découlant de l'ensemble Grp

relation ismember(ag, igr)

relation qui montre la porte via laquelle on a ismember(ag, igr)

FIGURE6.2 – illustration des cas d’entrées valides dans des groupes

entité organisationnelle est fonction des procédures de gestion des entrées de chaque instance groupe et donc des instances de portails qui leurs sont associées. Ainsi, en considérant l’exemple de la figure 6.2 l’agent3pour être membre degroup1doit réus-

sir une procédure d’entrée auprès de portal2 pour l’une des portes de group1. De

même, si l’agent1 qui est déjà dansgroup0 veut entrer dansgroup1, qui est associée

à la même instance de portailportal2 quegroup0, alors il doit réussir une procédure

d’entrée auprès deportal2pour l’une des portes de group1.