CHAPITRE 3 : Vérification par Model Checking
2.2 Construction d’une orchestration
La construction d’une orchestration est l’étape qui consiste à transformer une définition
d’orchestration en une structure de donnée représentant cette définition. Afin de construire un
système capable de construire des structures d’orchestration. Nous avons identifié les termes définis
dans le Chapitre 2 et qui sont acteurs de cette construction. Nous avons donc retenu les termes Route
et Roues (cf : section 2.4.1.7 du chapitre 2) ainsi que le Template de migration (cf : 2.3 du chapitre 2).
Nous décrivons dans les sous sections suivantes les automates utilisés dans la définition de la
construction d’une orchestration, nous décrivons aussi les propriétés que nous avons prouvées
notamment le fait que suite à chaque appel de l’EIP « migrate », le Template de migration est appliqué
à la définition de l’orchestration.
2.2.1 Déclaration du système de construction
Le module de construction représente le premier sous-système entre les deux sous-systèmes qui
composent notre plateforme d’orchestration. Le second sous-système concerne l’activation des
orchestrations, il est décrit dans la section 2.3
La déclaration du système de construction consiste en une instanciation des modèles intervenants
dans la construction d’une orchestration. Nous avons défini un agent d’orchestration « agent1 » à trois
étapes comme le montre la Figure 3-9 :
Le système global est composé de quatre automates dont les rôles sont :
« agent1 » : est une orchestration simple
111
« route1 » : gère la construction d’une route
« template1 » : a pour rôle d’appliquer le Template de migration (cf : section 2.3 du chapitre
2)
agent1 = AgentDef(FROM,MIGRATE,TO); routes1 = Routes(); route1 = Route(); template1 = MigrationTemplate(); system route1,routes1,template1,agent1 ;Figure 3-9 Structure de données associée à une orchestration.
2.2.2 Le modèle de définition d’agent d’orchestration
Le modèle « AgentDef » est construit à partir de sa définition décrite dans la Section 2.2 du Chapitre
2. Son objectif est de représenter les combinaisons possibles d’une orchestration π-DSL. Afin de
respecter les limitations de l’usage mémoire d’UPPAAL nous n’autorisons pas d’instanciation de ce
modèle avec plus de trois EIP.
Cette limitation a pour but de limiter la taille des automates construits dans cette section. L’automate
Figure 3-10 décrit tous les EIPs qui peuvent apparaitre dans la définition d’une orchestration. Les
gardes présentes sur ce diagramme permettent de traiter chacun de ces EIPs. Par exemple, le garde
sur « INOUT » permet de traiter les communications entrainant une requête aller et une réponse
retour.
Chacune des communications telles que « inOut? » est une synchronisation avec l’automate « Route »
(cf : section 2.2.4). C’est par le franchissement de ces communications successives que la route est
créée. Dans notre exemple, seules trois communications sont effectuées :
la première sur « from? »
la deuxième sur « migrate? »
la troisième sur « to? »
Ce modèle est évalué une seule fois par simulation du système. Il communique durant cette simulation
sur les canaux EIP afin de dépiler sa définition. Une fois que la définition est construite, ce modèle
atteint l’état « EndDef » ou il reste bloqué jusqu’à la prochaine création de route.
Le modèle « AgentDef » est composé de quatorze états :
Un premièr état « Idle » qui représente l’état d’inactivité. La transition à la sortie de cet état
permet d’initialiser la définition de l’agent à base des paramètres.
Le second état « Wait » est atteint quand l’agent s’apprête à envoyer un signal EIP, l’automate
revient à cet état tant qu’il reste des EIPs dans la définition de l’agent.
Le troisième état « EndStep » représente la fin d’une étape de définition de l’agent. Suite à cet
112
Le quatrième état « EndDef » marque la fin de définition d’un agent. Comme la définition d’un
agent ne s’exécute qu’une seule fois pour une exécution du système, l’automate « AgentDef »
ne revient pas à l’état « Idle » mais reste bloqué sur l’état « EndDef ».
Les dix états restants représentent les états atteints suite à une émission sur l’EIP de même
nom.
Figure 3-10 Modélisation de la définition d’une orchestration.
2.2.3 Le modèle Routes
Le modèle « Routes » est construit à partir de sa définition décrite dans la Section 2.4.1.7 du Chapitre
2. Son objectif est d’initier la création d’une route suite à l’appel sur l’EIP « from » et de déléguer la
suite la construction au modèle « Route ». Il est composé de trois états :
Un premier état « Idle » représente l’état d’inactivité.
Le second état « BuildingRoute » est atteint tant que le reste de la route est en train d’être
113
Le troisième état « PurgeRoute » représente les nettoyages et réinitialisations effectués afin
de remettre le système dans un état prêt à traiter une nouvelle route.
Figure 3-11 Modélisation du terme Routes.
La communication sur « from ! » représente le début de la construction de la route associée à l’agent
en cours de traitement. A la fin de cette construction, la communication sur « endRoute? » est
effectuée avec l’automate « Route ». Cet événement matérialise la disponibilité de la structure de
données pour sa future activation.
2.2.4 Le modèle Route
Le modèle « Routes » est construit à partir de sa définition décrite dans la Section 2.4.1.7 du Chapitre
2. Son objectif est d’écouter sur tous les canaux EIP sauf le canal « from ». Suite à chaque réception
sur un des canaux EIP, un nouvel élément est ajouté à la structure représentant l’orchestration.
La réception sur l’EIP « migrate » donne lieu à un comportement particulier, c’est-à-dire l’invocation
du Template de migration (cf : 2.3 du chapitre 2) qui applique des émissions supplémentaires sur les
canaux EIP. Le modèle « Routes » est la pierre angulaire de la construction d’une orchestration car
c’est le support des EIP. Chaque émission de l’automate Figure 3-12 est associée à une réception de
l’automate associé à « AgentDef ».
Le modèle « Route » est composé de trois états :
Un premièr état « Idle » qui représente l’état d’inactivité.
Le second état « Build » est atteint suite à chaque réception sur un canal EIP ou bien à la fin
de l’application du Template de migration
Le troisième état « TemplateApplication » est urgent car l’application du Template de
migration est prioritaire par rapport aux émissions classiques sur les EIPs. Une fois cet état
atteint, le modèle « MigrationTemplate » prend la main jusqu’à ce qu’il ait fini son évaluation
vu que ces états sont committed. Il ne rend la main au terme « Route » qu’après la fin de son
évaluation.
114
Figure 3-12 Modélisation du terme Route.
2.2.5 Le modèle du Template de migration
Le modèle « MigrationTemplate » est construit à partir de sa définition décrite dans la Section 2.3 du
Chapitre 2. Son objectif est de représenter les étapes EIP supplémentaires ajoutées à la définition
d’une orchestration afin de permettre la migration de l’agent d’orchestration.
Ce modèle est composé de six étapes telles que décrites dans notre approche de migration. Les états
de ce modèle sont définis comme committed, cela veut dire que l’application du Template de
migration est une étape atomique où l’horloge n’avance pas. Cela suppose que les états de ce modèle
sont urgents et que les émissions sur les canaux EIP effectuées sont prioritaires par rapport aux
émissions effectuées par la définition de l’agent.
Figure 3-13 Modélisation de la définition d’une orchestration.
Le modèle « MigrationTemplate » est composé de sept états :
Un premier état « Idle » qui représente l’état d’inactivité. La transition de sortie de cet état
115
Les six autres états « StepX » où 1≤X≤6 sont atteints suite aux émissions sur les EIPs
composants le Template de migration qui sont définis dans la section 2.3 du chapitre 2.
Dans le document
Orchestration d'agents mobiles en communauté
(Page 111-116)