une modification de la variablePics : en suivant les relations causales sortants de cette va-
riable sur le modèle causal, l’architecte peut identifier l’activitéFormat comme directement
affectée, mais également la variablePicsF et l’activité Reply par transitivité.
Dans cette section, nous avons présenté les concepts de causalité, de relation causale fonctionnelle et de modèle causal. En faisant le focus sur le moteur d’exécution du système, nous avons exhibé deux types de relations opérant dans un système. À l’aide de ces deux types, nous avons montré à quoi pouvait ressembler un modèle causal. Si la description faite ici ne représente qu’une infime partie de la sémantique du moteur, elle n’a pour but que de poser les bases nécessaires à la compréhension des modèles causaux et à montrer comment faire le lien entre la sémantique de la description du système et celle du moteur d’exécution, ainsi qu’avec la notion de causalité. Toutefois, s’il est possible de construire le modèle causal de PicWeb à la main, la prise en compte d’autres types de relations causales, ainsi que la taille plus conséquentes des systèmes sont des critères qui nous limitent dans cette méthode. Il est nécessaire pour l’architecte du système de pouvoir automatiser la constitution du modèle causal. Dans la suite de ce chapitre, nous introduisons une méthode permettant d’extraire les relations causales d’un système donné, en caractérisant les types de relations sous la forme de règles causales. Cette méthode est implémentée dans Smile, afin de déduire automatiquement le modèle causal d’un système.
6.4
Déduction des relations causales d’un système
Nous venons de définir la notion de modèle causal d’un système, permettant d’identifier les interactions entre ses éléments. Si son utilité n’est plus à montrer, une limitation réside dans son établissement. En effet, la construction manuelle d’un modèle causal est fastidieuse et sujette à erreur, compte tenu du nombre de relations causales présentes dans un système. Dans cette section, nous présentons une méthode permettant de déduire de manière auto- matisée le modèle causal fonctionnel d’un système. Après avoir présenté les principes de
notre méthode, nous définissons la notion de règle causale qui nous sert à décrire, indé-
pendamment de tout système, les types de relations causales que l’on peut déduire d’un système. Nous montrons enfin comment, en appliquant les règles causales sur un système donné, il est possible d’en déduire automatiquement ses relations causales.
6.4.1 Méthodologie
Le but de la méthodologie est de décrire une transformation permettant, en partant de la description d’un système, d’obtenir son modèle causal. Nous avons présenté précédemment différents types de relations causales fonctionnelles. Il est important de noter que ces types de relations sont décrits indépendamment du système étudié, mais en fonction de la plate- forme d’exécution. Il convient donc de souhaiter "instancier" par la suite ces types de relations causales, pour un système donné. Pour cela, notre méthode est un procédé de
déduction : il s’agit d’appliquer au système étudié des règles correspondant aux types de
relations causales, pour en déduire ses relations causales.
Afin de pouvoir mettre en œuvre un tel procédé, nous introduisons la notion de règle causale.
Définition 6.4.1 (Définition d’une règle causale)
Une règle causale est une requête permettant de sélectionner dans un système donné des couples (a, b) ∈ (SystemElement × SystemElement) tels qu’il existe une relation causale entre a et b.
6.4. Déduction des relations causales d’un système
Table 6.1 – Règle causale pour les relations causales de paramètre d’entrée.
Situation Action
A: Activity, M : Message, v : Variable and (A.type = Invoke or A.type = Receive) and M= A.input and
v ∈ M.content
v−→in A
Notre méthode consiste à définir en une seule fois les règles causales d’un moteur d’exé- cution, dans le but de les appliquer sur n’importe quel système pour en extraire ses relations
causales. Pour cela, nous proposons le procédé représenté dans la Figure 6.10.
Système Règles Causales Relations Causales Génération de Relations Causales SMILE expert du moteur d'exécution user
Action d'un acteur Légende : Génération de Règles Causales Règles Causales step élément step élément Étape du processus Donnée
L'étape step produit la donnée élément La donnée élément est en entrée de l'étape step
Figure6.10 – Procédé de déduction des relations causales.
6.4.2 Expression des règles causales
Concrètement, nous avons choisi de représenter les règles causales comme unsystème de
règles de production. Selon le spécification de l’OMG [OMG 2009a], une règle de production
est"une instruction de logique de programmation qui spécifie l’exécution de une ou plusieurs
actions dans le cas où ses conditions sont satisfaites. Les règles de production ont donc une sémantique opérationnelle (formalisant les changements d’état, e.g., sur la base d’un formalisme d’un système de transition d’état)". Une règle de production est représentée
comme une instructionSi [condition] alors [liste d’actions]. À titre d’exemple, la Table6.1
et la Table 6.2 sont l’expression des règles causales correspondant respectivement aux
relations causales d’entrée et de sortie. On parle de Situation pour décrire la condition, et
d’Action pour l’ensemble des actions à effectuer. Dans le contexte de la règle causale de paramètre d’entrée, la situation décrite consiste à raisonner sur une activité A, un message
M et une variable v. Nous posons comme condition que A soit une activité de type Invoke
ou Receive, que M soit le message d’entrée de A, et que v soit contenue dans M. Dans
ces conditions, la situation, i.e., la relation causale à déduire, est v −→in A. Le principe
est similaire pour la règle causale de paramètre de sortie, en considérant ici les activités de
typeInvoke et Reply. En utilisant ces deux règles causales sur PicWeb, notre méthodologie
6.5. Conclusion du chapitre
Table6.2 – Règle causale pour les relations causales de paramètre de sortie.
Situation Action
A: Activity, M : Message, v : Variable and (A.type = Invoke or A.type = Reply) and M = A.output and
v ∈ M.content
A−→out v
6.5
Conclusion du chapitre
Dans ce chapitre, nous nous sommes centrés sur les besoins de l’architecte du système. Nous avons introduit les différents concepts nécessaires pour modéliser un système. Partant de cette modélisation, nous nous sommes intéressés à la notion de causalité pour retrans- crire les interactions existantes au cours de l’exécution d’un système. À travers la notion de modèle causal, nous avons établi un ensemble de relations causales telles que les relations causales de paramètres d’entrée et de sortie, représentant l’effet d’un élément du système sur un autre. Nous avons enfin présenté une méthode permettant, en exprimant une fois pour toute des types de causalité par le biais de règles causales, de déduire de manière automatique le modèle causal d’un système. Notre approche reste cependant limitée par l’intervention d’un expert du moteur d’exécution qui doit transcrire la sémantique du mo- teur en règles causales. De plus, si le modèle causal obtenu permet de représenter la causalité d’un point de vue fonctionnel, nous pouvons toutefois nous demander ce qu’il en est de la causalité en vue de l’étude de la variation de la qualité de service dans un système. Nous traitons ce point dans le chapitre suivant.
Chapitre 7
Modélisation de la qualité de
service pour l’évolution
Sommaire
7.1 Motivations . . . 65 7.2 Modélisation de la qualité de service d’un système . . . 66 7.2.1 Propriété, unité et critère de comparaison . . . 67 7.2.2 Domaine d’application . . . 67 7.2.3 Valeur de propriété. . . 68 7.2.4 Influence et ressource . . . 68 7.2.5 Discussion. . . 69 7.3 Définition des relations causales de propriété. . . 69 7.3.1 Relations d’environnement. . . 71 7.3.2 Relations de dérivation de propriétés . . . 71 7.3.3 Relations d’agrégation de valeurs . . . 73 7.3.4 Discussion. . . 74 7.4 QoS4Evol, un langage de description de la qualité de service . . 74 7.4.1 Présentation de QoS4Evol . . . 75 7.4.2 Définition du langage . . . 75 7.4.3 Caractéristiques du langage . . . 76 7.5 Déduction des règles causales d’une propriété . . . 77 7.5.1 Principe . . . 77 7.5.2 Obtention des relations causales d’environnement . . . 78 7.5.3 Obtention des relations causales de dérivation. . . 79 7.5.4 Obtention des relations causales d’agrégation . . . 79 7.5.5 Discussion. . . 80 7.6 Conclusion du chapitre . . . 81
D
ans l’étude d’un système,maintien de la QoS du système, à tout moment de son cycle de vie. Il apporte sonl’expert en qualité de service a pour rôle de s’assurer du expertise du domaine pour vérifier le respect des contrats de QoS, et pour identifier les causes d’une potentielle violation. Nous présentons dans ce chapitre un ensemble d’outils nécessaire à l’expert en QoS pour étudier l’effet d’une évolution sur la QoS.7.1
Motivations
Pour rappel, nous considérons qu’une évolution est une modification des fonctionnalités du système dans le but de satisfaire de nouveaux besoins des différentes parties prenantes. Si une évolution cherche en premier lieu à satisfaire de nouveaux besoins fonctionnels, il