Modélisation des contraintes sur un système

4.3.1.1 Approche générique

Nous considérons dans notre approche les spécifications comme des contraintes dont on peut évaluer la satisfaction vis à vis du système architectural sur lequel elles por-tent. Une première étape a donc consisté à modéliser de manière indépendante de leur formalisme ces contraintes. Pour ce faire nous avons remarqué que basiquement chacune était composée d’un prédicat et des observations du système que ce dernier contraignait. Ceci nous a permis de définir un Domain Specific Language [22], qui a pour objet de décrire ces contraintes de manière générique et lisible par un humain1. La traduction automatique d’une spécification de son formalisme original dans ce DSL incombe à l’intégrateur du formalisme qui la fournit dans le cadre de l’"adaptateur de formalisme" (cf. 3.3.4) :

1NB : nous rappelons que dans nos travaux nous privilégions malgré tout une production automa-tique des contrats

On <un element d a r c h i t e c t u r e >

Observe {

( v a l: <valeur > a t: < i n s t a n t s >; )+

}

V e ri fy <p r op r ie t e >

La sémantique de cette expression est relativement simple. Le bloc "On" définit le do-maine spatial du système que la règle peut voir, il s’agit de la portée d’un élément d’ar-chitecture, composant ou service. Le bloc "Observe" décrit les observations effectuées dans ce domaine. Le bloc "Verify" décrit la partie d’évaluation de la propriété passée en argument, qui s’appuie sur les observations décrites précédemment. Au delà de ces parties communes à tous les formalismes, l’interprétation des observations du bloc

Observe et de la propriété du bloc Verify doivent être spécialisés pour chacun des formalismes qu’on souhaite manipuler à l’aide de notre langage. Cette tâche incombe à l’intégrateur de formalisme dans le système de contrat, sachant que par défaut le système prévoit que l’outil d’évaluation de la propriété du bloc Verifysoit notifié de l’occurence des observations à l’aide d’événements dits d’observation.

Instants d’observation.Les instants d’observation sont définis par les événements que l’architecture ou ses systèmes de monitoring peuvent émettre. Comme dans le cadre de l’exécution d’un système il est courant de disposer d’une manière ou d’une autre d’interception de l’exécution du système, nous proposons dans notre approche deux mots clés :entry et exitqui désignent l’entrée de l’exécution dans un élément d’ar-chitecture et sa sortie de celui-ci. Ainsi, dans le cas de l’exemple du système contraint de CruiseControl : On <Engine > Observe { v a l : t h r o t t l e a t : entry s e t T h r o t t l e ( f l o a t t h r o t t l e , f l o a t TS ) ; }

cette expression observe la valeur du paramètre (throttle) au moment où l’exécution entre dans la méthodesetThrottleofferte par le composant<Engine>. Par ailleurs il est possible que des formalismes requiert des observations s’appliquant à des durées, dans ce cas il revient à la charge du traducteur de spécification (humain ou informa-tique) de discrétiser cet intervalle en instants discrets.

Cohérence temporelle. Nous n’abordons pas ici explicitement le problème de l’organ-isation temporelle des observations. En effet, il est possible que la spécification du bloc

Verifyrequiert que les observations soient effectuées dans un certain ordre, ou fasse de manière générale porter une contrainte sur leur organisation temporelle. La descrip-tion de l’organisadescrip-tion temporelle générique des observadescrip-tions nous a en effet semblé un problème trop vaste pour être traité dans le cadre de cette thèse. Nous proprosons que dans la description des instants puissent être incluses des conditions temporelles faisant éventuellement intervenir les autres observations du bloc en désignant leurs événements déclencheurs. Toutefois la syntaxe, la sémantique de ces expressions et leur interprétation sont laissés à la charge de l’intégrateur de formalisme, c’est à dire la personne fournissant l’outil de traduction du formalisme dans notre langage. Il faut noter que cette solution autorise la mise en oeuvre d’événements composites pour déclencher les observations ce qui est d’un intérêt certain. Par contre, il faut prendre

garde aux cycles d’événements qui pourraient apparaître si par exemple une observa-tion était déclenchée par une condiobserva-tion externe (par exemple une intercepobserva-tion sur le système) ou par une autre observation, alors que cette dernière se produit consécutive-ment à la première. Ainsi l’événeconsécutive-ment relatif à une observation est notée_valoùval

est le nom de la valeur observée. Le mot cléwithdésigne une condition temporelle sur les événements, il est à noter que cette condition peut faire intervenir l’événement de déclenchement de l’observation à laquelle elle appartient (notée_this). Par exemple, si le " ;" dénote une séquence et "*" une répétition indéfinie d’un ensemble d’événe-ments :

On <Engine >

Observe {

v a l : evt . getSpeed a t : e x i t sns . getSpeed ( ) ;

v a l : t h r o t t l e a t : entry csp . s e t T h r o t t l e ( f l o a t t h r o t t l e , f l o a t TS ) with ( e_getSpeed ; e _ t h i s )_* ;

}

Dans cette expression, la première valeur observée est simplement un événement nommé

getSpeed associé à la sortie de l’exécution de la méthode getSpeed(). Ensuite l’ob-servation porte sur le paramètre throttlelu à l’entrée de l’exécution dans la méth-ode setThrottle. Toutefois le blocwith vient contraindre l’instant de la lecture du paramètre en spécifiant que cet instant doit toujours se produire juste après une oc-curence de l’événementgetSpeed(soit la lecture de la vitesse courante).

Moment d’évaluation de la spécification.Le moment d’évaluation de la spécification n’est pas décrit explicitement dans notre langage car il dépend de l’outil d’évaluation utilisé ou de la configuration du système. Classiquement une observation peut aussi bien être utilisée au moment de son obtention pour évaluer au plus tôt sa spécification afin de pouvoir réagir en quasi temps réel à un problème, ou bien elle peut être stockée pour une évaluation différée du comportement du système. Un compromis peut être atteint dans le cas d’une évaluation qui tire partie de moments de faible charge du sys-tème pour s’exécuter sur des données sauvegardées etc. Dans ces différents cas l’ob-servation et la spécification sont identiques, seul diffère le moment d’évaluation.

4.3.1.2 Application à des formalismes concrets

Nous allons dans cette partie étudier comment deux formalismes, CCLJ et les Be-haviour Protocol peuvent être interprétés dans le langage simple que nous venons de décrire. Pour ce faire nous nous placerons dans le cas du système contraint décrit dans la partie 3.2.

CCLJ

La traduction de spécifications écrites en CCLJ est relativement immédiate, ainsi une spécification de la forme :

on <Composant> c o n t e x t f ( f l o a t valeur ) :

pre : c ond it ion ( valeur )

se réécrira sous la forme :

On <Composant>

v a l: valeur a t : entry f ( f l o a t valeur ) ; }

V e ri fy : c ond it ion ( valeur )

L’interprète de notre langage comportera alors un interprète du formalisme du prédi-catconditionpour calculer sa valeur à l’aide de la valeur observéevaleurdont il est notifié.

Behavior Protocol

Si nous considérons la spécification du composant<CruiseCtrl>suivante :

(?sns . on ; !csp . s e t T h r o t t l e_*; ?sns . o f f )_*

Elle traduit qu’après avoir reçu un appel sur la méthode sns.on(), le<CruiseCtrl>

va émettre un nombre non limité d’appels à csp.setThrottle, avant de recevoir un appel sur sa méthodesns.off().

Elle peut se réécrire de la manière suivante :

On <C r u ise C t r l > Observe { v a l : evt . on a t : entry sns . on ( ) ; v a l : evt . on a t : entry sns . o f f ( ) ; v a l : evt . s e t T h r o t t l e a t : entry csp . s e t T h r o t t l e ( ) ; } V e ri fy : (?on ; !s e t T h r o t t l e_*; ?o f f )_*

Dans ce cas l’interprète de notre langage doit être spécialisé pour qu’un "runtime checker" vérifie l’expression du Behaviour Protocol du blocVerifyau fur et à mesure qu’il est notifié des événements d’observations spécifiés dans le blocObserve.

4.3.1.3 Modélisation

Du point de vue du modèle de contrat, les spécifications appliquées aux éléments d’ar-chitecture peuvent être modélisées en suivant les concepts de notre langage spécialisé, comme montré sur la figure 4.11. Nous nommons description de règle (RuleDescrip-tion) la traduction d’une spécification d’un formalisme quelconque dans notre langage. Nous distinguerons cette forme descriptive d’une forme évaluable que nous nom-merons EvaluableRule que nous décrirons dans la partie suivante. L’objectif de la description est de contenir des expressions (spécifications et observations) dont l’inter-prétation mécanique produit, pour chacun des outils d’évaluation potentiel, une forme évaluable de la contrainte.