Dépendances de données

Les dépendances de données sont calculées à partir des couples de variables définies et utilisées dans un diagramme à états/transitions en UML/OCL, qui respectent la définition de dépendances de données.

Nous définissons d’abord ce qu’est une transition de définition et transition utilisatrice.

Définition 7 (Transition de définition) La transition qui modifie la valeur d’une va- riable v lors d’une instruction OCL (affectation, déclaration) est appelée transition de définition.

Remarque : La modification d’une variables dans une instruction OCL d’une transition est notée Def.

Définition 8 (Transition utilisatrice) Une transition qui utilise la valeur d’une va- riable v dans son code OCL, par rapport à sa définition dans une autre transition (sans aucune redéfinition) est appelée transition utilisatrice.

Remarque : L’utilisation d’une variable dans le code OCL d’une transition est notée Use. En nous basant sur cette propriété, nous donnons la définition d’une transition data dépendante par rapport à une autre.

Définition 9 (Transition data dépendante) Une transition T0 est data dépendante d’une autre transition T par rapport à la variable v si et seulement si T est transition de définition de v et T0 transition utilisatrice de v .

L’ensemble de triplets hT , T0, v i est appelé graphe de dépendances de données. Ces définitions sont le point de départ pour proposer l’algorithme 2 de calcul des dépendances de données pour les diagrammes d’états/transitions en UML/OCL. Le calcul prend en compte les définitions et les utilisations des variables dans le code OCL, mais aussi les attributs des classes. Plus exactement les définitions sont collectées à partir du code OCL dans l’action ou de la post condition de l’opération événement déclencheur de la transition (trigger). Les utilisations sont déterminées dans la garde/action d’une transition ou dans la pre/post condition d’une opération. La spécificité du code OCL en UML4MBT nous autorise à faire des appels d’opérations dans l’action d’une transition ou dans la post condition d’une opération. Pour cela, nous devons prendre en compte ces appels afin de calculer toutes les définitions et les utilisations des variables.

Dans l’algorithme 2, nous proposons tout d’abord d’établir toutes les définitions et utilisations des variables dans la machine à états/transitions. Ensuite, nous proposons

6.2. Calcul des dépendances de lier chaque transition utilisatrice d’une variable à sa transition de définition, si et seulement si il n’y aucune redéfinition. Pour identifier cette condition dans l’algorithme, nous utilisons le nom def-clear.

Entrées : model : le modèle avec un diagramme d’états/transitions

Sorties : dataDependence(X,Y,v) : Tableau tri-dimensionnel de type booléenne, qui indique vrai si Y est data dépendent de X pour la variable v, et faux sinon

Données :

SethTransition,Variablei definitions = model->gatherAllDefinitions(); SethTransition,Variablei uses = model->gatherAllUses();

pour chaque <Transition,Variable> Def ∈ definitions faire Transition defTransition = Def.getTransition();

Variable variable = Def.getVariable();

pour chaque <Transition,Variable> Use ∈ uses faire Transition useTransition = Use.getTransition;

si def-clear(defTransition,useTransition,variable) alors

dataDependence(defTransition,useTransition,variable) = true; fin

fin fin

Algorithme 2: Dépendance de données entre transitions

L’algorithme ainsi proposé utilise cinq opérations dont nous allons donner l’explication ci-dessous :

– gatherAllDefinitions : s’applique sur le modèle de test et renvoie en résultat l’en- semble de couples <Transition,Variable> définies dans l’action de la transition ou encore dans la condition du trigger (variables locales ou attributs de classes ou associations).

– gatherAllUses : s’applique sur le modèle de test et en résultat renvoie l’ensemble de couples <Transition,Variable>, variables utilisées au sein de l’action/garde de la transition (attributs de classes ou associations) ou dans la pré/post condition du trigger. A noter que les appels d’opérations sont pris en compte.

– getTransition : s’applique sur le couple <Transition,Variable> et permet de recouper le premier élément du couple.

– getVariable : s’applique sur le couple <Transition,Variable> et permet de recouper le deuxième élément du couple.

– def-clear : opération permettant de calculer si un chemin entre la transition utili- satrice et la transition de définition par rapport à une variable est unique i.e. sans aucune redéfinition de la variable dans une autre transition faisant partie du chemin. Afin de représenter les liens de dépendances de données nous allons prendre les cas de succès des opérations : buyTicket, login et register, représentés par les transitions : buyTicket-success, login-success et register-success. Ces transitions sont représentées dans le diagramme d’états/transitions simplifié de la figure 6.1.

Dans le tableau 6.2, partie de gauche du tableau, nous récapitulons les variables défi- nies et utilisées dans chaque transition.

Figure 6.1 – Extrait du diagramme d’états/transitions d’eCinema

Variables Dépendances de données

Def Use buy-success register-success login-success

buy-success all bought tickets current user x x

register-success current user

all registered users all registered users x

login-success current user current user x x

all registered users x

Table 6.2 – Def/Use pour un extrait d’eCinema

Sur la partie de droite du tableau 6.2 nous définissons les relations de dépendance de données. La condition de chemin def-clear est satisfaite par tous les couples def/use. Nous pouvons constater que buy-success et login-success sont dépendantes de register-success et de login-success par rapport à l’utilisation/définition de la variable current user . Les transitions register-success et login-success sont dépendantes de register-success par rap- port à l’utilisation/définition de la variable all registered users.

Nous allons voir dans la section 6.3 comment les dépendances de données en mêlant les dépendances de contrôle, définies dans la sous-section suivante 6.2.2, contribuent à l’identification des exigences impactées par les changements.