Modélisation avec UPPAAL

Dans UPPAAL, un système est décrit par un réseau d’automates temporisés (TA) (Définition 3.3)

étendus à l’aide de variables entières, de types de données structurés et de la synchronisation de

canaux.

Lors de la phase de modélisation, la définition du système se décompose en trois parties :

- La déclaration de variables globales : Il est possible de définir des variables globales et des

fonctions qui sont accessibles et partagées par tous les TA. UPPAAL accepte la définition de

tableaux de variables, de canaux ou d’horloges ainsi que la définition de nouveaux types. La

103

Figure 3-3 présente un exemple d’une déclaration de variables globales d’un système UPPAAL

avec la définition d’une horloge h, d’un nouveau type step_t_{, tel que si} 𝑖 _{est une variable de}

type step_t _alors 0 ≤ 𝑖 ≤ 8_{, et d’un tableau de 3 canaux de synchronisation nommés} 𝑢𝑟𝑖 _qui

est un tableau de deux dimensions.

//Déclaration d’une constante

constint MAX_STEP = 9;

//Déclaration d’un type

typedefint[0, MAX_STEP-1] step_t;

//Déclaration d’une horloge

clock h;

//Déclaration d’un tableau de canaux de dimension deux

chan uri[MAX_STEP][MAX_STEP];

Figure 3-3 Déclaration de variables globales dans UPPAAL.

- La définition de modèles : dans un système UPPAAL, les TA sont définis comme des instances

de modèle. Ces modèles sont indépendants de toute implantation. Cela fait de nos TA des

éléments appartenants au PIM. Dans la définition de ces modèles de TA, il est possible

d’ajouter des déclarations de variables locales ou des paramètres. Ces paramètres sont alors

considérés comme des variables locales aux instances de TA et sont initialisés lors de la

déclaration du système. La Figure 3-4 présente la définition d’un modèle de TA (appelé

Template) sous le nouveau format XML d’UPPAAL.

<template>

<name>Client</name>

<parameter>step_t id, step_t host</parameter>

<locationid="id18"x="-120"y="-16">

<namex="-130"y="-46">Invocking</name>

</location>

<locationid="id19"x="-272"y="-16">

<namex="-282"y="-46">Ready</name>

</location>

<initref="id19"/>

<transition>

<sourceref="id18"/>

<targetref="id19"/>

<labelkind="synchronisation"x="-240"y="48">callback[host][id]!</label>

<nailx="-208"y="48"/>

</transition>

<transition>

<sourceref="id19"/>

<targetref="id18"/>

<labelkind="synchronisation"x="-216"y="-104">uri[host][id]?</label>

<nailx="-208"y="-80"/>

</transition>

</template>

Figure 3-4 Définition d’un modèle d’automate temporisés UPPAAL en XML.

La Figure 3-5 présente l’interface graphique du modèle de TA défini dans la Figure 3-4. Ce TA

104

Figure 3-5 Représentation graphique d’un modèle d’automate temporisés UPPAAL.

- La déclaration du système : La déclaration du système consiste en la définition d’un ou

plusieurs processus concurrents, chacun modélisé par un TA. Un processus est une instance

d’un modèle de TA. L’instanciation d’un modèle d’automate demande de lier une variable à

chaque paramètre défini par le modèle. Si le paramètre n’est pas défini par un type borné alors

le paramètre doit être lié explicitement. Dans le cas contraire, où le paramètre est d’un type

borné, il est possible de laisser UPPAAL lier automatiquement une instance du modèle avec

chaque valeur du type défini comme paramètre. La Figure 3-6 présente la déclaration d’un

système qui utilise une instance du modèle « client » défini dans la Figure 3-4. où URI1 _et

HOST_1 sont deux constantes

...

client = Client(URI1,HOST_1);

...

system ...,client,... ;

Figure 3-6 Déclaration d’un système UPPAAL.

Parmi les différents éléments qui composent un système défini dans UPPAAL, nous listons ceux que

nous utilisons dans la suite de ce chapitre :

- les actions de synchronisation non-déterministes. Il est possible de définir des actions de

synchronisation non-déterministes via la définition d’un tableau de canaux associée à la

déclaration d’une plage d’identifiants propre à une transition. Dans ce cas, une action de

synchronisation se situe dans une plage d’actions liées à la plage d’identifiants définie. Par

exemple, dans la Figure 3-7 la transition entre les états 𝐼𝑑𝑙𝑒 et 𝑅𝑒𝑎𝑑𝑦 définit un identifiant a

de type step_t défini dans la Figure 3-4. Les actions de synchronisation possibles sont alors

𝑎𝑐𝑡𝑖𝑣𝑎𝑡𝑒[𝑜𝐼𝑑][ℎ𝐼𝑑] avec 0 ≤ 𝑜𝐼𝑑 ≤ 8 et 0 ≤ ℎ𝐼𝑑 ≤ 8. Le canal 𝑎𝑐𝑡𝑖𝑣𝑎𝑡𝑒 écoute donc sur 18

possibilités différentes. Afin de garder une trace des valeurs 𝑜𝐼𝑑 et ℎ𝐼𝑑, elles peuvent être

affectées à des variables associées au modèle. Cette opération appelée mise à jour est

105

Figure 3-7 Exemple d’utilisation d’une action de synchronisation non-déterministe.

- les localités urgentes. Si une localité est déclarée urgente alors le temps ne peut pas s’écouler

dans cette localité. Définir une localité 𝑙 urgente est équivalent à définir une horloge ℎ qui est

remise à zéro par toutes les transitions arrivant dans la localité 𝑙 et définir un invariant ℎ ≤ 0

pour la localité 𝑙. Par la suite, nous modélisons une localité 𝑢𝑟𝑔𝑒𝑛𝑡𝑒 par un cercle avec la lettre

majuscule 𝑈 (U comme Urgent). Par exemple, dans la Figure 3-7, la localité 𝐼𝑑𝑙𝑒 est définie

comme une localité urgente.

- les localités atomiques. Une localité dite committed est une localité urgente qui impose que

la prochaine transition du système soit une transition sortante de cette localité (ou d’une autre

localité committed_{). Ce type de localité permet de modéliser une suite de transitions}

atomiques qui garantit que toutes les transitions sont effectuées sans être interrompues, ou

qu’aucune transition n’est effectuée. Par la suite, nous modélisons une localité committed par

un cercle avec la lettre majuscule 𝐶 (C comme Committed). Par exemple, dans la Figure 3-7, la

localité 𝑅𝑒𝑎𝑑𝑦 _{est définie comme une localité} committed_.

La Figure 3.7 présente la représentation graphique de deux modèles d’automate temporisé à l’aide de

l’outil UPPAAL. Elle représente les instances des modèles 𝑃𝑜𝑟𝑡𝑒 _et 𝐼𝑛𝑡𝑒𝑟𝑟𝑢𝑝𝑡𝑒𝑢𝑟 _{définis dans la Figure}

3-2.

Figure 3-8 Modélisation de deux modèles d’automate (cf. Figure 3.2) à l’aide de l’outil UPPAAL.

Dans le document Orchestration d'agents mobiles en communauté (Page 103-106)