Formalismes acceptés par le modèle de contrat

Notre modèle de contrat n’est pas dédié à un formalisme spécifique comme CCLJ ou les Behavior Protocols. Néanmoins, il fait certaines hypothèses sur les formalismes des spécifications qu’il est susceptible de mettre en oeuvre. Pour que les spécifications soient organisées par notre modèle de contrat il faut que leur formalisme :

• soit modulaire, c’est à dire que chaque spécification doit porter sur une seule entité logicielle (à la concrétisation par hypothèse indépendante des autres), • permette d’extraire mécaniquement, de chaque spécification, les observations

(leurs descriptions) qu’elle contraint sur l’entité logicielle à laquelle elle est at-tachée,

• permette d’interpréter mécaniquement chaque spécification en un couple de con-traintes, sur son entité logicielle associée, répondant à la sémantique de l’ap-proche hypothèse-garantie,

• dispose d’outils pour évaluer la conformité d’une spécification à l’entité logicielle à laquelle on l’associe, et pour évaluer la compatibilité de deux ou plus spécifica-tions,

Tout comme pour l’applicabilité de notre modèle de contrat à différents types d’ar-chitectures, nous devrons implémenter l’intégration de différents formalismes pour valider qu’il en accepte bien de variés. Cependant, il nous est ici possible d’envisager d’un point de vue conceptuel les formalismes qui répondent à nos critères et d’extraire de notre état de l’art quelques exemples qui répondent ou non à nos hypothèses.

3.3.3.1 Modularité

Nous pouvons constater que le génie logiciel tend au découplage, et à la modularisa-tion, des entités logicielles mises en oeuvre dans les applications. En particulier, les ob-jets, composants et services expriment dans leur définition cette évolution. Il n’est donc pas surprenant que même ’il n ’est pas exhaustif, notre état de l’art des formalismes de spécification des objets, composants et services n’ait rencontré que des formalismes modulaires. Nous en concluons que la majorité des formalismes de spécification des objets, composants et services sont modulaires.

3.3.3.2 Extraction des observations

Si nous considérons une spécification, nous pouvons constater que plus son formal-isme est de haut niveau, c’est à dire éloigné de la réalisation concrète de l’application qu’elle contraint, plus il est délicat d’extraire de son expression les observations sur lesquelles elle s’appuie. Ainsi il est aisé d’extraire les observations contraintes par un formalisme assertionnel comme nous l’avons réalisé dans le cas du système de contrat Confract avec l’interprétation du langage d’assertion adapté aux composants nommé CCLJ. Par contre comme nous l’avons vu dans le cas de la logique temporelle TLA [22], les observations contraintes par une spécification doivent être fournies par le spécifica-teur au moment de l’application de la spécification à un système concret. Il existe bien sûr une gradation dans la facilité ou difficulté à extraire les observations contraintes par une spécification et il n’y a pas de frontière nette entre ceux pour lesquels cela est possible mécaniquement et les autres. Toutefois plus un formalisme autorise la désig-nation d’élément architecturaux d’implémentation (composants, interfaces, méthodes, etc...) plus facile en sera l’extraction automatique des observations de son expression.

3.3.3.3 Interprétation sous forme d’hypothèse et garantie

Notre approche suppose de pouvoir interpréter une spécification sous forme d’une hypothèse et ou d’une garantie (certaines pouvant être de pures hypothèses, d’autres de pures garanties), contraintes équivalentes à la spécification. A nouveau les obser-vations contraintes par la spécification jouent un rôle déterminant dans son interpré-tation. Ainsi une contrainte sur une observation du porteur de la spécification est une garantie que le porteur doit satisfaire, une contrainte sur une observation de l’envi-ronnement du porteur est une hypothèse dont le porteur attend la satisfaction. Deux grands cas de figures se présentent alors :

Hypothèse et garantie sous forme d’expressions distinctes

L’expression de la spécification peut être divisée en deux expressions contraignant chacune un ensemble distinct d’observations, d’un côté les observations sur le porteur, d’un autre les observations sur son environnement. La sémantique de ces deux expres-sions doit être telle que la satisfaction de la spécification originale soit équivalente à la

satisfaction de la garantie tant que l’hypothèse l’est. Par exemple si nous considérons sur notre exemple la spécification suivante :

On <Engine>

context float csp.getRTime (float throttle) pre : throttle < 10

post : retour < 5

Elle spécifie que pour autant que l’accélération demandée au moteur est inférieure à 10, son temps de réponse sera inférieur à 5. Elle peut se diviser en deux expressions respectant l’approche hypothèse-garantie :

• une hypothèse :throttle < 10qui porte sur la valeur dethrottlefournie par son environnement à<Engine>,

• une garantie :retour < 5qui porte sur la valeur de retour de la méthodegetRTime

fournie par le composant à son environnement,

telles que la garantie doit être satisfaite tant que l’hypothèse l’est.

Ces conditions peuvent paraître contraignantes, néanmoins de nombreux formalismes de description d’éléments d’architecture reposent sur, ou peuvent se ramener à cette approche hypothèse-garantie. En effet celle-ci met en oeuvre des contraintes inter-dépendantes entre un élément et son environnement. Nous avons vu que nous rete-nions les architectures dont le fonctionnement reposait sur la collaboration et donc les échanges entre leurs participants. Or dans ce cadre les éléments d’architecture sont définis par ce qu’ils fournissent et requièrent vis à vis de leur environnement. Ainsi la distinction entre l’élément d’architecture et son environnement, ainsi que la potentielle dépendance entre ce que l’élément fournit et requiert, font que l’approche hypothèse-garantie est particulièrement adaptée à la description des propriétés des éléments d’ar-chitectures collaboratives.

Hypothèse et garantie sous forme d’une seule expression

L’expression de la spécification ne peut être divisée en deux contraintes bien qu’il soit possible de distinguer les observations qui contraignent le porteur de la spécifi-cation de celles sur son environnement. Il se peut dans ce cas que l’évaluation de la contrainte ne fasse pas intervenir toutes les observations en même temps, ce qui nous permet alors de savoir, en fonction de l’observation contrainte à un instant donné, si la spécification doit être interprétée comme une hypothèse ou une garantie. Par exemple si nous considérons la spécification suivante en Behavior Protocol du<CruiseCtrl>:

(?sns.on; !csp.setThrottle*; ?sns.off)*

pour garantir sa non-contradiction par rapport à l’exécution concrète du système, cette contrainte est évaluée pour un appel à la fois2. Ainsi cette expression est une garantie de<CruiseCtrl>par rapport à l’appel desetThrottlecar il doit l’émettre, par contre c’est une hypothèse par rapport aux appels deonetoffcar il attend ces derniers de son

environnement. La sémantique "hypothèse-garantie" de cette expression est que tant que l’environnement appelleonet offaux bons moments, le<CruiseCtrl>garantit qu’il émet des appels àsetThrottleaux bons moments. Concrètement cela se traduit par l’affectation de la responsabilité en cas de contradiction entre la spécification et l’éxécution du système. En effet suivant que l’appel est entrant ou sortant, c’est re-spectivement l’environnement ou le composant qui est responsable. Nous pouvons donc constater qu’une hypothèse ou une garantie ne sont pas seulement de simples expressions mais l’association d’une contrainte avec les grandeurs sur lesquelles elle est évaluée.

3.3.3.4 Outils associés

Les outils associés aux différents formalismes sont variés. Certains permettent de véri-fier la conformité des spécifications à leur porteur comme souvent dans le cas des as-sertions, dans ce dernier cas ils peuvent aussi être utilisés pour s’assurer de leur com-patibilité. D’autres se focalisent plus exclusivement sur l’évaluation de la compatibilité de différentes spécifications comme dans le cas de formalismes logiques. Enfin certains formalismes comportementaux (Sofa) et de qualité de services (CQML) proposent à la fois l’évaluation de la conformité et de la compatibilité des spécifications.