Illustration des politiques

Cette sous-section illustre les principales caractéristiques des deux politiques présentées précédem- ment au travers des deux exemples de contrats présentés précédemment (cf. page72) :

– Le premier exemple concerne deux clauses d’un contrat de composition externe exprimant une pré et une postcondition. Pour la première clause de ce contrat, la politique par concession conduit à modifier tout ou partie de la clause négociée, alors que la politique par effort effectue une modifica- tion sur un attribut du composant bénéficiaire. La seconde clause, quant à elle, présente rapidement un exemple d’échec de négociation par les deux politiques ;

– Le second exemple porte sur un contrat de composition interne. La spécification exprimée concerne un invariant de configuration. La politique par concession conduit à différents scénarii de négocia- tion (refus de négociation, retrait total de la clause ou modification d’un terme paramétré), alors que la politique par effort se propage dans la hiérarchie du composant garant et conduit à effectuer une modification d’attribut d’un sous-composant contribuant à la propriété spécifiée dans la clause négociée.

Contrat de composition externe

CC BC LC ContractController (CTC) 000 000 000 000 000 111 111 111 111 111

: composite boîte noire par le contrat : entités référençées : portée du contrat 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 11111111 11111111 11111111 11111111 11111111 11111111 11111111 11111111 11111111 11111111 11111111

external omposition ontra t on< vs> parti ipants: <ia>< vs><s ><sf> lauseson server interfa e Video v:

void start() pre

guarantor: <ia> benefi iaries:< vs> ontributors: <s > .expe tedCPUUsage(getUrl().getDataSour e(),

<this>.attributes.getFrameRate(),

<this>.attributes.getNbClients())<=60 //in%

post

guarantor: <vs> benefi iaries:<ia><sf> v.isStarted(); Video frameRate, nbClients <sf> <vs> Instant

Service ConfiguratorService <sc> Facade InstantApp <ia> X X X X c:Config v:Video

Représentation textuelle du contrat réifié

FIGURE6.12 – Rappel du contrat de composition externe sur <vs>

• Clause sur l’utilisation estimée du CPU :

La clause du contrat externe sur <vs> (cf. Fig.6.12) vérifie à l’entrée de la méthode start() les bonnes conditions, en terme d’utilisation du CPU, pour la réalisation du service de diffusion vidéo, estimées à partir des valeurs de certains paramètres (flux multimédia courant, état des ressources CPU et nombre de clients). Cette clause est donc vérifiée à l’exécution du système et est violée, par exemple, si l’utilisation du CPU pour la diffusion vidéo est estimée à plus de 60%. Dans ce cas, les parties négociantes qui sont le gestionnaire de contrats de <ia> comme initiateur, le composant bénéficiaire <vs>, et le composant garant <ia>, interviennent dans une négociation atomique. Politique par concession. Dans la politique par concession, l’initiateur consulte <vs> et nous établissons un scénario dans lequel le composant <vs> propose une concession qui consiste à

Chapitre 6. Modèle de négociation

changer entièrement la clause. Ainsi, l’initiateur demande tout d’abord la négociabilité. Comme <vs> a les moyens de négocier, il accepte la négociation et s’appuie sur la liste d’alternatives suivante, pour orienter ses concessions successifs : Apre,<pr>:= {Ψ,STOP} avec Ψ, décrivant la

nouvelle clause :

c.expectedCPUUsage(getURL().getDataSource(), <this>.attributes.getFrameRate(), getNbClients()) ≤ 80.

Cette nouvelle clause spécifie un seuil d’utilisation de CPU plus élevé (80 % au lieu de 60 %), et exprime ici la capacité de <vs> à s’appuyer sur une contrainte moins forte11_.

Ainsi, à la première demande de concession de l’initiateur, <vs> propose la nouvelle clause Ψ, et l’initiateur effectue le remplacement et la revérification de la clause. Si la clause est revalidée alors la négociation se termine avec un succès. Sinon, si la modification n’est pas suffisante et ne permet pas de rétablir une clause valide, alors l’initiateur annule la dernière modification et demande de nouvelles concessions. <vs> répond alors en proposant la fin des concessions et la négociation s’arrête avec maintien de la clause par l’alternativeSTOP. Comme <vs> est le seul bénéficiaire, la négociation par concession s’achève ainsi sur un échec avec le maintien de la clause. Par ailleurs, au lieu de proposer l’alternativeSTOP, le composant <vs> aurait aussi très

bien pu proposer l’alternativeRELEASEpour indiquer le retrait de la clause. Dans ce cas, comme la clause est entièrement retirée, la négociation s’achève avec succès, mais plus aucune vérification n’est effectuée pour détecter une sur-utilisation du CPU au démarrage du service de diffusion vidéo.

Politique par effort. Dans la politique par effort, l’initiateur consulte maintenant le garant <ia> (voir Fig. 6.13). Comme la propriété est implémentée au niveau du sous-composant <vs> de <ia>, alors <ia> accepte de négocier par effort et propose de propager la négociation (étape 1). Son gestionnaire de contrats prend alors en charge la négociation et consulte <vs> pour des demandes d’efforts, car ce dernier réalise la propriété frameRate qui intervient dans la clause négociée (étape 2). <vs> propose alors des modifications sur cette propriété, en s’appuyant sur sa liste d’alternatives associée Apre,<vs>:= {(framerate←framerate2 ),STOP}.

Ainsi, à la première demande de concession de l’initiateur, <vs> propose d’ajuster son attribut frameRateavec l’alternativeframerate←framerate2 . L’initiateur effectue la modification et revé-

rifie la clause. Si la clause est revalidée alors la négociation se termine avec un succès. Sinon, si la modification n’est pas suffisante et ne permet pas de rétablir une clause valide, alors l’initiateur annule la dernière modification et demande de nouveaux efforts. <vs> répond alors en proposant la fin de la négociation avec maintien de la clause par l’alternativeSTOP, car diminuer davantage le

frameRaterisquerait d’entraîner une diffusion saccadée de la vidéo. Comme <vs> est le seul composant qui contribue à la clause négociée, la négociation par effort s’achève ainsi sur un échec avec le maintien de la clause.

Il est à noter que le composants <vs> est consulté dans chacune des deux politiques. En revanche, son rôle n’est pas le même dans les deux cas : dans la politique par concession, il agit en tant que bénéficiaire direct de la clause qui peut proposer des modifications concernant la clause sur laquelle il s’appuie, alors que dans la politique par effort, il intervient après propagation et agit plus indirectement en proposant de reconfigurer son paramètre frameRate car il implémente le terme correspondant frameRate dans la clause négociée.

• Clause sur l’état du service vidéo :

La clause qui vérifie l’état du service vidéo à la sortie de la méthode start est vérifiée à l’exécu- tion du système et est violée, si à la fin de la méhode start la méthode le service vidéo n’est pas

6.5. Politiques étape 1 ContractController (CTC) : Propagation de la négociation étape 2 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 11111111 11111111 11111111 11111111 11111111 11111111 11111111 11111111 11111111 11111111 11111111 <vs> frameRate InstantApp <ia> Video Service

FIGURE6.13 – Schéma de propagation pour la propriété FrameRate

dans l’état ’démarré’ (isStarted rend faux). Dans ce cas, une négociation atomique démarre avec les parties négociantes suivantes : le gestionnaire de contrats de <ia> dans le rôle de l’ini- tiateur consulte les composants bénéficiaires <ia> et <sf> dans la politique par concession, et le composant garant <vs> dans la politique par effort. Toutefois, comme cette violation traduit une erreur de fonctionnement du composant <vs>, nous considérons ici que la clause n’est pas destinée à être gérée par la négociation. Dans la politique par concession, le bénéficiaire principal accepte alors la négociation et propose l’alternativeSTOPpour demander le maintien de la clause (pas de concessions possibles et détection importante). Dans la politique par effort, le garant re- fuse directement la négociation car il est dans l’impossibilité de proposer des efforts pour revalider la clause (erreur vraisemblablement interne au composant <vs>). La négociation se termine en échec pour les deux politiques, et cet échec de négociation est ensuite signalée au plus haut-niveau. Contrat de composition interne

CC LC ContractController (CTC) BC 0000000000000 0000000000000 0000000000000 0000000000000 0000000000000 0000000000000 0000000000000 0000000000000 0000000000000 0000000000000 0000000000000 0000000000000 0000000000000 0000000000000 1111111111111 1111111111111 1111111111111 1111111111111 1111111111111 1111111111111 1111111111111 1111111111111 1111111111111 1111111111111 1111111111111 1111111111111 1111111111111 1111111111111 00 00 00 00 00 11 11 11 11 11 InstantCommunication <ic>

: composite boîte noire : portée du contrat par le contrat : entités référençées InstantGroup <ig> maxUsers X X

internal omposition ontra t on<i > parti ipants: <i ><ig>

parammax₋users=250 inv

guarantor: <i > benefi iaries:<i > <ig>.attributes.getMaxUsers()>=max₋users

Représentation textuelle du contrat réifié

FIGURE6.14 – Rappel du contrat de composition interne sur <ic>

• Clause sur le seuil minimal d’utilisateurs maximal :

Cette clause du contrat de composition interne de <ic> (cf. Fig.6.14) décrit certains aspects de son assemblage (seuil minimal du nombre maximal d’utilisateurs). L’invariant de configuration qui porte sur le seuil minimal d’utilisateurs maximal, est vérifié en fin de configuration et est violée, par exemple si le nombre maximal d’utilisateurs (maxUsers) effectifs vaut 100 alors que le seuil

Chapitre 6. Modèle de négociation

minimal spécifié (max-users) vaut 250. Les parties impliquées dans la négociation atomique sont : le gestionnaire de contrats de <ic> dans le rôle de l’initiateur, et <ic> lui-même dans le rôle de composant à la fois garant et bénéficiaire.

Politique par concession. L’initiateur consulte tout d’abord <ic> en tant que bénéficiaire pour lui demander la négociabilité. Ce dernier accepte la négociation et peut proposer, suite à la de- mande de concession de l’initiateur, différentes concessions qui correspondent à plusieurs scénarii.

– avec la liste d’alternative Ainv,<ic>:= {STOP}, <ic> exprime avecSTOPsa volonté de s’ap-

puyer sur cette clause telle quelle. <ic> traduit ainsi le fait que le système doit absolument ac- cepter un seuil minimal d’utilisateurs maximal de 250 utilisateurs. Dans ce cas, comme <ig> est l’unique bénéficiaire aucune autre concession ne peut être proposée et la négociation par concession se termine par un échec.

– avec la liste d’alternative Ainv,<ic>:= {RELEASE},<ic> propose le retrait de la clause avec

l’alternative RELEASE. Dans ce cas, il n’y a plus de contrainte de seuil minimal du nombre

d’utilisateurs maximal, et en particulier un composant <ig> qui ne supporte qu’un nombre maximal de 2 utilisateurs, conviendrait alors parfaitement. Comme <ig> est l’unique bénéfi- ciaire, l’initiateur effectue alors le retrait, et la négociation se termine avec succès.

– dans une situation intermédiaire, <ic> peut aussi proposer différents concessions successives sur le terme de la clause qui spécifie le paramètre maximal du nombre d’utilisateurs (max-users), avec la liste d’alternative suivante Ainv,<ic> := {max-users ← 150,

max-users← 100,max-users← 50,STOP}. <ic> propose alors successivement une concession qui consiste à modifier la valeur du paramètre max-users de la clause pour exprimer sa ca- pacité à s’appuyer sur une clause moins contrainte. Ainsi, pour chaque alternative, l’initiateur effectue la modification de la clause et réévalue celle-ci avec le contexte initial de la violation. Dès qu’une alternative suffit à revalider la clause, alors la négociation s’arrête avec succès. Si- non, avec l’alternativeSTOP, <ic> propose la fin de la concession avec maintien de la clause.

Ici, comme la clause est violée avec l’attribut maxUsers= 100, la première modification pa- ramètre max-users qui suffit à rétablir une clause valide estmax-users← 100.

Politique par effort. Dans la politique par effort, le gestionnaire de contrats de <ic> consulte toujours <ic> mais cette fois-ci dans son rôle de garant. Nous décrivons ici un scénario dans lequel le composant <ic> exploite sa responsabilité de garant vis-à-vis de son assemblage et de l’usage de son sous-composant <ig> pour accepter la négociation et négocier par effort (voir Fig.6.15). Ainsi, après la phase de consultation initiale pour la négociabilité de la clause, <ic> propose au gestionnaire de contrats de prendre en charge la négociation car la propriété négociée (maxUsers) est implémentée au niveau de son sous-composant <ig> (étape 1). Le contexte de la négociation atomique est alors transmis au gestionnaire de contrats de <ic> qui prend en charge la négociation, et consulte <ig> pour des efforts (étape 2). Par la suite, comme <ig> ne peut pas proposer de modifications à son niveau mais qu’il possède des éléments pour orien- ter la propagation de la négociation en exploitant la formule compositionnelle<ig>.maxUsers :=

<umgr>.maxUsers, il propose alors à son tour de propager la négociation. Cette formule composi- tionnelle traduit le fait que la propriété maxUsers implémentée au niveau de <ig> est réalisée au niveau de son sous-composant <umgr> ; c’est donc à ce dernier qu’il faut s’adresser si l’on souhaite exploiter jusqu’au bout la propagation de la négociation, et modifier effectivement la pro- priété maxUsers spécifiée dans la clause. Ainsi, la négociation est transmise au gestionnaire de contrats de <ig> (étape 3), qui exploite la formule compositionnelle pour s’adresser à <umgr> et obtenir de ce-dernier des propositions d’efforts visant à revalider la clause négociée (étape 4).

6.6. Discussion