Description des NFT et des NFS

Je viens de pr´esenter le langage ACL qui permet de documenter des d´ecisions architectu- rales. Il me reste `a proposer un moyen pour documenter les liens unissant ces d´ecisions (que j’appelle des AD) aux besoins de qualit´e (que j’appelle des NFP). Dans cette approche, un tel lien est appel´e Tactique Non Fonctionnelle (NFT). L’ensemble des NFT d’un composant constitue une Strat´egie Non Fonctionnelle (NFS). Dans un premier temps, je vais d´etailler la structure adopt´ee pour documenter les NFT. Je donnerai, dans un deuxi`eme temps, un exemple de ce type de documents.

6.5.3.1 La structure des NFT

Les d´efinitions introduites pr´ec´edemment sont illustr´ees par la figure 6.6. Les d´ecisions architecturales (AD) sont construites selon un mod`ele hi´erarchique. Une AD peut donc ˆetre construite sur la base d’autres AD. La d´ecision AD1 a ´et´e construite sur les d´ecisions AD2 et AD3. Une d´ecision architecturale est d´ecrite par une contrainte ´ecrite en ACL. Une NFT est la donn´ee d’un couple (AD, NFP). Elle manifeste que le d´eveloppeur a fait le choix AD dans le but de satisfaire la totalit´e ou une partie du besoin NFP. Une d´ecision peut apparaˆıtre dans plusieurs NFT. Ainsi la d´ecision AD3 se retrouve dans deux NFT (NFT1 et NFT2). Une mˆeme d´ecision peut donc ˆetre li´ee `a plusieurs NFP. Ainsi AD3 participe `a l’obtention des besoins NFP1 et NFP2. Inversement, une mˆeme NFP peut ˆetre associ´ee `a plusieurs d´ecisions architecturales. Ainsi NFP2 est li´ee aux d´ecisions AD3 et AD6 (via respectivement NFT2 et NFT3).

Une NFP est un des besoins de qualit´e formul´es dans le document de sp´ecification d’un composant logiciel. Une NFP doit ˆetre un besoin atomique. Une NFP est dite atomique si elle n’est associ´ee qu’`a un et un seul attribut qualit´e dont la port´ee est unique. Ce mod`ele accepte

FIG. 6.6 – Expression des NFS

actuellement comme attribut qualit´e, les caract´eristiques et les sous-caract´eristiques du mod`ele de qualit´e ISO/IEC 9126 [67] (par exemple, la maintenabilit´e, la portabilit´e, etc.). Un attribut qualit´e est port´e par un artefact architectural externe. Un artefact externe repr´esente un concept architectural public d’un composant ; c’est-`a-dire un artefact visible par les autres composants. Dans mon approche, les artefacts externes sont les composants, les interfaces et les op´erations. Une NFP est donc un triplet compos´e : d’un artefact architectural externe cible, d’un attribut qualit´e et du texte provenant du document de sp´ecification non fonctionnelle qui d´ecrit ce besoin. Voici deux exemples de NFP qui pourrait ˆetre construites depuis la documentation d’un composant : (Maintenabilit´e, composant C, “le composant C doit supporter facilement d’autres formats de fichier”) et (Performance, op´eration o() de l’interface I, “L’op´eration o() doit garantir un temps de r´eponse inf´erieur `a 10ms”). Le d´eveloppeur a donc pour obligation de d´ecouper la sp´ecification non fonctionnelle d’un composant en autant de NFP que n´ecessaire.

En l’´etat je ne fais aucune hypoth`ese sur le format d’´ecriture des besoins dans la docu- mentation du composant. Ils peuvent ˆetre formul´es sous forme de textes libres (c’est le cas le plus fr´equent) ou en usant d’un langage d´edi´e `a l’expression de certaines propri´et´es non fonc- tionnelles (par exemple QML [48] pour certains aspects de la qualit´e de service). L’absence d’un langage d’expression de propri´et´es non fonctionnelles digne de ce nom restreint le niveau de formalisation d’une NFP et donc d’une NFT. Je suis ici tributaire des avanc´ees dans un do- maine encore ouvert et en devenir, objet de nombreux travaux. Face `a une telle situation et dans le but de g´erer le maximum de cas possibles, la seule contrainte que j’impose, pour des raisons

de stockage et d’affichage, est que le format d’expression des besoins permette un stockage sous la forme de chaˆınes de caract`eres. Bien sˆur, cette flexibilit´e se paye par l’absence de toute structure pour la troisi`eme composante du triplet d´efinissant une NFP ; absence pr´ejudiciable `a la mise sur pied de m´ecanismes de lien NFT plus puissants.

6.5.3.2 Le stockage des NFS

Tr`es concr`etement, dans cette approche, une NFS qui d´etaille l’ensemble des NFT prend la forme d’un document XML respectueux d’un sch´ema XML reprenant la structure que je viens de d´ecrire. Le listing ci-dessous repr´esente l’exemple d’une NFS (un contrat d’´evolution).

<n o n f u n c t i o n a l −s t r a t e g y i d =”000001”> <n o n f u n c t i o n a l −t a c t i c i d =”000100”> <d e s c r i p t i o n > C e t t e t a c t i q u e g a r a n t i t l a NFP p o r t a b i l i t e p a r l e b i a i s du p a t r o n de c o n c e p t i o n Facade </ d e s c r i p t i o n > <n o n f u n c t i o n a l −p r o p e r t y i d =”001000” name =” P o r t a b i l i t e ” c h a r a c t e r i s t i c =” P o r t a b i l i t e ” e x t e r n −arch −a r t i f a c t =”MACS”> <d e s c r i p t i o n > Le composant d o i t e t r e p o r t a b l e s u r d i f f e r e n t s e n v i r o n n e m e n t . I l p e u t s e r v i r d i f f e r e n t s t y p e s d ’ a p p l i c a t i o n s c l i e n t e s . </ d e s c r i p t i o n > </ n o n f u n c t i o n a l −p r o p e r t y > <a r c h i t e c t u r e −d e c i s i o n i d =”010000”> <d e s c r i p t i o n > P a t r o n de c o n c e p t i o n Facade </ d e s c r i p t i o n > <f o r m a l i z a t i o n i d =”100000” p r o f i l e =”CCM”> <!−− I c i on r e t r o u v e l a c o n t r a i n t e −−> </ f o r m a l i z a t i o n > </ a r c h i t e c t u r e −d e c i s i o n > </ n o n f u n c t i o n a l −t a c t i c > </ n o n f u n c t i o n a l −s t r a t e g y >

Cet exemple illustre une NFS compos´ee d’une seule NFT. Cette NFT repr´esente le couple (AD, NFP) o`u AD est le choix du patron de conception Fac¸ade. La NFP ici est form´ee du triplet : i) l’attribut qualit´e Portabilit´e, ii) l’artefact architectural externe auquel est associ´e cet attribut et qui repr´esente le composant nomm´e MACS et iii) la description textuelle du besoin qualit´e impliquant cette NFP. La derni`ere partie de cette NFS contient la contrainte qui formalise la d´ecision architecturale (patron de conception Fac¸ade). Dans cet exemple, la contrainte est ´ecrite avec le profil ACL pour le mod`ele de composants CORBA (CCM).

6.6 En r´esum´e

Dans ce chapitre, j’ai pr´esent´e une approche par contrats qui vise, au del`a de la simple do- cumentation d’une architecture logicielle pour sa meilleure compr´ehension, `a automatiser cer- taines v´erifications durant l’´evolution. Ces v´erifications peuvent, `a la demande du d´eveloppeur, assister l’activit´e d’´evolution et lui notifier l’impact des changements architecturaux sur les d´ecisions architecturales. Cette assistance permet d’alerter des cons´equences sur les besoins qualit´e associ´ees `a ces d´ecisions. Elle oriente donc le d´eveloppeur durant l’´evolution vers une certaine direction de telle mani`ere `a ce que la d´eviation des sp´ecifications de qualit´e initiales soit minimale (voir Figure 6.7). Cela r´eduit bien ´evidemment le nombre de tests effectu´es a posteriori et durant lesquels on d´etecte cette d´eviation. La r´eduction de ce nombre de tests contribue `a la minimisation du coˆut global de la maintenance.

Notifications

Evolution avec assistance -Minimisation du delta- Axe fonctionnel

Axe non-fonctionnel

Evolution sans assistance

FIG. 6.7 – Assistance `a l’´evolution dirig´ee par la qualit´e

Supposons maintenant que l’´evolution architecturale vise, pour certaines modifications, plutˆot l’aspect non-fonctionnel. Dans ce cas, comme ce fut propos´e dans la section 6.3.2, l’algo- rithme d’assistance impose la modification des sp´ecifications non-fonctionnelles et des contrats d’´evolution. Il garantit ainsi une assistance prenant en compte l’´evolution des sp´ecifications non-fonctionnelles. Sur la Figure 6.8, la ligne ´epaisse avec pointill´es (en haut de la figure) repr´esente le nouvel axe th´eorique d’´evolution avec sp´ecifications non-fonctionnelles constantes.

Assistance qui est fonction aussi de l’evolution des specifications non-fonctionnelles Evolution des specifications

non-fonctionnelles

Evolution avec assistance -sans prise en compte de l’evolution des specifications non-fonctionnelles-

Axe fonctionnel Axe non-fonctionnel

Evolution sans assistance

FIG. 6.8 – Assistance avec ´evolution des sp´ecifications non-fonctionnelles

L’´evolution de l’architecture atteint ainsi le premier point (en haut) `a droite, au lieu du deuxi`eme. Dans ce dernier cas, nous supposons que l’assistance `a l’´evolution a ´et´e effectu´ee sans prise en compte de l’´evolution des sp´ecifications non-fonctionnelles. Nous concluons que les contrats d’´evolution ´evoluent avec les sp´ecifications de besoins non-fonctionnels et garan- tissent ainsi une assistance coh´erente et `a jour vis `a vis de ces derniers. Cet aspect est important dans la documentation logicielle et contribue consid´erablement dans la r´eduction des coˆut de maintenance [25].

Trac¸abilit´e des d´ecisions

architecturales dans un processus de

d´eveloppement

Sommaire

7.1 Introduction au besoin de tracer les d´ecisions architecturales . . . 123