Dans le cadre de la description du modèle de contrat nous nous appuierons sur des exemples issus d’un petit système de composants, conçu uniquement à des fins d’il-lustration. Ce système repose sur un modèle de composants classique dans lequel les composants sont connectés les uns aux autres via des interfaces fournies et requises, et peuvent être composites. Un de nos objectifs est de découpler notre modèle de con-trat de la nature concrète de l’architecture, aussi la nature exacte des éléments de l’ex-emple n’est donc pas importante. Par contre, le fait que ce découplage permette de raisonner sur l’architecture indépendamment de l’implémentation concrète de cette dernière, suppose que pour un framework architectural donné un expert effectue un travail d’intégration de son système dans les termes de notre modèle.
3.2.1 Description
Nous considérons pour notre exemple un système de régulation de vitesse d’une au-tomobile inspiré de [67]. Ce système est contrôlé à l’aide de trois boutons : resume, on and off. Quand la voiture roule et que on est pressé le système enregistre la vitesse courante et maintient la voiture à cette allure. Quand l’accélérateur, le frein ou off est pressé, le système cesse d’agir mais retient la vitesse programmée. Si resume est pressé, le système accélère ou ralentit la voiture pour la ramener à la vitesse précédemment retenue. La figure 3.3 décrit l’architecture et les interfaces du système. Du point de vue de l’utilisateur d’un tel système, il est important qu’une erreur soit détectée rapide-ment, c’est à dire avant qu’elle n’ait des conséquences critiques, mais aussi que son diagnostic soit aussi précis que possible pour en appréhender la gravité. Par ailleurs il serait préférable que ce diagnostic soit aussi synthétique que possible, expurgé des détails d’implémentation que l’utilisateur du système ne saurait pas interpréter. D’un point de vue externe, le composant <Car> fournit une interface sns, du type
Sen-sor, dont les méthodes permettent au conducteur (<User>) de piloter l’automobile. De manière interne, <Car> est constitué de deux sous-composants. Le composant
seCtrl> est le système principal de commande, fournissant une interface Sensor et les attributs représentant la vitesse programmée et le code d’une éventuelle erreur. Il re-quiert par ailleurs une interface CarSpeed afin d’interagir avec le moteur. Le moteur, <Engine>, fournit une interface csp, du type CarSpeed, dont les méthodes permettent de fixer l’accélaration et d’obtenir la mesure de la vitesse courante. Nous pouvons au passage constater que pour le concepteur du système cette division des tâches n’est intéressante que s’il peut avoir l’assurance que chaque partie remplit bien la sienne, de manière compatible avec les autres.
Via l’interfaceFeedBackl’utilisateur de la voiture,<User>, se voit notifier des actions entreprises par le moteur <Engine> pour suivre les ordres du contrôleur de vitesse
<CruiseCtrl>. Dans une voiture réelle, cette interface pourrait prendre la forme d’un afficheur sur le tableau de bord tenant le conducteur informé des initiatives du sys-tème de contrôle de la vitesse. Par ailleurs nous faisons maintenant l’hypothèse que le système de contrôle de la vitesse est relié à des capteurs détectant d’éventuels ob-stacles devant ou derrière la voiture. Suivant la présence, la distance, la vitesse de tels obstacles le système de contrôle de la vitesse peut être amené à modifier la vitesse de la voiture pour conserver un certain niveau de sécurité. Pour fixer ce niveau de sécurité nous avons ajouté la méthodesetSecurityLevelà l’interfaceSensor. Cette méthode fournit en retour à un niveau de sécurité désiré un indicateur du niveau de confort que le système peut alors garantir, sachant que plus le niveau de sécurité est élevé, moins le confort sera prioritaire donc affecté d’un indicateur faible. Enfin au sein du système le moteur <Engine> est capable de donner le temps qu’il lui faut pour atteindre une certaine accélération grace à la méthodegetRTimede l’interfaceCarSpeed.
3.2.2 Spécifications du système
Afin d’autoriser la prise en compte de propriétés variées, nous avons pour objectif de découpler notre modèle de contrat des formalismes de spécification et de leurs inter-prètes et outils d’évaluation. Cette approche offrira une vision uniforme de ces pro-priétés à l’utilisateur du système, car elle ne considérera que les notions de conformité et de compatibilité des éléments et de leurs spécifications. Par contre à nouveau elle suppose, de la part d’un spécialiste du formalisme, l’intégration de ce dernier et de ses outils dans notre modèle. Nous considérerons pour notre exemple les formalismes CCLJ (cf 2.4.2.2) et Behavior Protocol (cf 2.4.2.3).
3.2.2.1 CCLJ
A l’aide de CCLJ, nous pouvons exprimer que le composant<Car>va demander quoiqu’il arrive, via l’interfacesnsqu’il requiert, un niveau de sécurité supérieur à 3. Tandis que composant <CruiseCtrl>n’accepte, via l’interface snsqu’il fournit, que les niveaux de sécurité inférieurs à 5. S1 : On <Car> c o n t e x t i n t sns . s e t S e c u r i t y L e v e l ( i n t l e v e l ) pre : l e v e l > 3 S2 : On <C r u ise C t r l >
c o n t e x t i n t sns . s e t S e c u r i t y L e v e l ( i n t l e v e l )
pre : l e v e l < 5
et d’autre part il est possible de spécifier que le composant <Engine> garantit un temps de réaction à une accélération inférieur à 5 unités. Tandis que le composant
<CruiseCtrl>requiert lui un temps de réponse inférieur à 10 unités.
S3 : On <Engine > c o n t e x t f l o a t csp . getRTime ( f l o a t t h r o t t l e ) p ost : r e t ou r < 5 S4 : On <C r u ise C t r l > c o n t e x t f l o a t csp . getRTime ( f l o a t t h r o t t l e ) p ost : r e t ou r < 10 3.2.2.2 Behavior Protocol
Les Behavior Protocol permettent de décrire les séquences d’appels entrants et sortants qu’un composant accepte. Nous les avons utilisés pour spécifier les comportements des
<CruiseCtrl>,<Engine>et<Car>. • <CruiseCtrl>:
(1) (?sns.on; !csp.setThrottle*; ?sns.off)*
Le composant <CruiseCtrl>commence par attendre un appel de la méthode
on() sur son interface fournie sns, puis il émet une série indéfinie d’appels à
setThrottle, jusqu’à ce qu’il reçoive un appel à méthodeoff()de son interface
sns. Cette séquence peut être répétée un nombre indéfini de fois. • <Engine>:
(2) (?csp.setThrottle; !fdk.notifyAction)*
L’<Engine>attend un appel à la méthodesetThrottle()qu’il fournit. Quand il le reçoit il émet un appel ànotifyAction(), puis attend à nouveau un appel à la méthode setThrottle(). Ce cycle peut se produire un nombre indéfini de fois.
• <Car>:
(3) (?sns.on; !fdk.notifyAction*; ?sns.off)*
Le composant<Car> englobe les deux précédents. Il attend un appel à la méth-ode on(), celui-ci arrivé il émet une série indéfinie d’appels ànotifyAction(), jusqu’à ce qu’il reçoive un appel à la méthodeoff(). Ce cycle peut se répéter un nombre indéfini de fois.
L’intérêt de notre approche est que la personne qui écrit les spécifications n’a pas be-soin d’être un expert de leur mise en oeuvre, leurs outils d’interprétation et de vérifi-cation ont déjà été intégrés au modèle de contrat. Elle n’a pas non plus à se soucier de l’implémentation du système contraint qui lui est masquée par le modèle de contrat.