• Aucun résultat trouvé

2.3 Architectures logicielles et composants

2.3.6 Qualit´e dans les architectures logicielles

Il est admis que les d´ecisions architecturales sont conduites par les attributs qualit´e requis dans les documents de sp´ecification [11]. En effet, ce ne sont pas les fonctionnalit´es attendues d’un logiciel qui d´eterminent son architecture, mais plutˆot la mani`ere avec laquelle ses fonc- tionnalit´es vont ˆetre fournies. Par exemple, si nous d´ecidons d’utiliser le style architectural de syst`eme en couches, c’est en r´eponse `a l’exigence d’un niveau de maintenabilit´e ´elev´e. Ici, l’attribut qualit´e est la maintenabilit´e et la d´ecision architecturale est un syst`eme en couches. Dans la section 1.2.1, j’ai pr´esent´e des exemples d’exigences sur certains attributs qualit´e et leurs impl´ementations sous forme de d´ecisions architecturales.

Dans le domaine de la qualit´e logicielle, on consid`ere une caract´eristique qualit´e comme toute propri´et´e observable ou mesurable, statique ou dynamique d’un produit ou un processus

logiciel. A un attribut qualit´e, des m´etriques peuvent ˆetre associ´ees. Une m´etrique est une mesure qualitative ou quantitative pour observer ou mesurer la qualit´e. Une exigence qualit´e est une sp´ecification des valeurs acceptables des caract´eristiques qualit´e.

Un mod`ele de qualit´e est une taxonomie des caract´eristiques qualit´e et des relations entre ces caract´eristiques. L’objectif de ces mod`eles est triple : i) une sp´ecification d´etaill´ee d’un syst`eme logiciel ; ii) une ´evaluation de la conception ; iii) des tests du syst`eme.

Il existe dans la litt´erature plusieurs mod`eles de qualit´e. En 1977, McCall et al. ont fourni une caract´erisation des propri´et´es (facteurs) de qualit´e bas´ee sur trois perspectives ou pr´eoccup- ations dans le d´eveloppement logiciel [99]. La premi`ere repr´esente la r´evision des produits lo- giciels. Elle est compos´ee des caract´eristiques suivantes : la maintenabilit´e, la flexibilit´e et la testabilit´e. La deuxi`eme perspective s’oriente vers la transition de produits. Elle est repr´esent´ee par la portabilit´e, la r´eutilisabilit´e et l’interop´erabilit´e. La troisi`eme pr´eoccupation concerne les op´erations des produits. Elle est constitu´ee des attributs suivants : correction, efficacit´e, fia- bilit´e, int´egrit´e et utilisabilit´e. Ces onze caract´eristiques qualit´e sont appel´ees facteurs. Elles d´ecrivent la vue externe d’un logiciel, telle qu’elle est perc¸ue par ses utilisateurs. Les au- teurs ont raffin´e ces facteurs en vingt trois crit`eres qualit´e. Chaque crit`ere d´ecrit la vue interne d’un logiciel, telle qu’elle est perc¸ue par ses d´eveloppeurs. A ces crit`eres, ils ont associ´e des m´etriques.

En 1978, Barry Bo¨ehm a propos´e un autre mod`ele de qualit´e [13]. Ce mod`ele ressemble beaucoup au pr´ec´edent, car il est hi´erarchique avec trois niveaux de caract´erisation. Le premier niveau (le plus haut dans la hi´erarchie) du mod`ele de Bo¨ehm d´efinit trois pr´eoccupations :

– l’utilit´e du logiciel, de trois points de vue : i) efficacit´e, ii) facilit´e d’utilisation iii) et fiabilit´e ;

– la maintenabilit´e ; – la portabilit´e.

Le second niveau est constitu´e de sept caract´eristiques : portabilit´e, fiabilit´e, efficacit´e, utilisabilit´e, testabilit´e, compr´ehensibilit´e, flexibilit´e. Comme dans le mod`ele de McCall, le troisi`eme niveau est repr´esent´e par les m´etriques associ´ees aux caract´eristique pr´ec´edentes. Malgr´e sa ressemblance avec le mod`ele de McCall, le mod`ele de Bo¨em contient une vari´et´e plus grande de caract´eristiques et se focalise plus sur la maintenabilit´e, ainsi que les caract´eristiques et les m´etriques qui lui sont associ´ees.

ISO39000 (et son ´evolution ISO 9000 :2000) est une famille de standards bien connue dans

le domaine de la qualit´e en g´en´eral (logicielle ou non). Cette famille est compos´ee de plusieurs standards li´es, entre autres, aux processus d’assurance qualit´e (ISO 9001 :2000), `a l’audit des syst`emes de gestion de la qualit´e (ISO 19011 :2000) et `a la gestion de la qualit´e des organisa- tions (ISO 9004 :2000). En plus de cette famille de standards, ISO a fourni en 2001 le standard ISO/IEC 9126 pour l’´evaluation de produits logiciels : caract´eristiques qualit´e et les directives pour leur utilisation [67]4. Ce standard est bas´e sur les deux standards pr´ec´edents et ajoute

une autre caract´eristique, qui repr´esente la fonctionnalit´e. Il est compos´e de quatre parties : i) Partie 1 : Mod`ele de qualit´e, ii) Partie 2 : M´etriques externes, iii) Partie 3 : M´etriques internes, et iv) Partie 4 : M´etriques de la qualit´e en utilisation. La partie 1 de ce standard (mod`ele de

3ISO veut dire International Organization for Standardization : www.iso.org

qualit´e) d´efinit deux niveaux de caract´eristiques qualit´e : le premier niveau repr´esente les fac- teurs de qualit´e classiques (illustr´es dans la Figure 2.5), et le deuxi`eme niveau repr´esente les sous-caract´eristiques de chacune des caract´eristiques du niveau sup´erieur.

ISO/IEC 9126 Capacite fonctionnelle Portabilite Maintenabilite Efficacite Utilisabilite

Fiabilite Comment le logicielest fiable ? Est-ce que les fonctions exigees

sont disponibles dans le logiciel ?

Comment le logiciel est facilement transferable sur un autre environnement ?

Comment le logiciel est facilement modifiable ?

Comment le logiciel est efficace ?

Est-ce que le logiciel est facile a utiliser ?

FIG. 2.5 – Extrait du mod`ele de qualit´e ISO/IEC 9126

Les diff´erentes caract´eristiques qualit´e du premier niveau sont d´efinies, dans ce standard, de la mani`ere suivante :

– Capacit´e fonctionnelle : C’est la capacit´e d’un logiciel `a r´epondre aux besoins fonc- tionnels, de s´ecurit´e et d’interop´erabilit´e (Functionnality),

– Portabilit´e : C’est la capacit´e d’un logiciel `a ˆetre transf´er´e d’un environnement `a un autre et la facilit´e de son int´egration, adaptation, installation et co-existence (Portability), – Maintenabilit´e : C’est la capacit´e d’un logiciel `a ˆetre facilement analysable, modifiable

et testable (Maintainability),

– Efficacit´e : C’est la capacit´e d’un logiciel `a fournir ses services de mani`ere efficace vis `a vis du temps d’ex´ecution et de la consommation des ressources syst`eme (Efficiency) – Utilisabilit´e : C’est la capacit´e d’un logiciel `a ˆetre attractif, facilement compr´ehensible

et op´erable (Usability),

– Fiabilit´e : C’est la capacit´e d’un logiciel `a fournir ses services dans des conditions pr´ecises et pendant une p´eriode d´etermin´ee (Reliability).

En 2002, le SEI5 propose un mod`ele de qualit´e sp´ecialis´e pour les architectures logi-

cielles [11]. Ils classifient les attributs qualit´e selon trois niveaux diff´erents. Le premier niveau repr´esente les qualit´es du syst`eme. Il est constitu´e des attributs suivants : disponibilit´e, mo-

difiabilit´e, performance, s´ecurit´e, testabilit´e et utilisabilit´e. Le deuxi`eme niveau concerne les qualit´es d’affaire (business qualities). Les auteurs citent les attributs suivants : le temps de mise sur le march´e (Time To Market), le coˆut et les b´en´efices, la dur´ee de vie projet´ee du syst`eme, le march´e vis´e, l’ordonnancement de la distribution du produit (Rollout Schedule) et l’int´egration aux anciens syst`emes. Le dernier niveau concerne les qualit´es directement li´ees `a l’architec- ture : l’int´egrit´e conceptuelle, la correction et la compl´etude, et la capacit´e de construction architecturale.

Klein et al. ont propos´e des styles architecturaux dits ABAS (Attribute-Based Architectural Style) [81]. Ces styles constituent, tout comme les styles architecturaux classiques, des mod`eles r´ecurrents de conception `a la seule diff´erence qu’un ABAS vise un attribut qualit´e particulier. Ceci permet de mieux cerner les exigences qualit´e et fournit une description r´eutilisable d’une solution `a un probl`eme r´ecurrent.

Comme vous pouvez le constater dans ce travail, les caract´eristiques qualit´e consid´er´ees sont les attributs en relation avec le produit. Ces attributs ne peuvent ˆetre observ´es ou me- sur´es que statiquement (`a l’arrˆet du logiciel). Tous les attributs qualit´e de type processus lo- giciel, comme la vitesse de d´ecouverte ou de fixation de bogues, ou les attributs qualit´e d’af- faire, comme, le time-to-market ne sont pas trait´es, car non impl´ement´es directement par des d´ecisions architecturales.

Je me base, dans le travail pr´esent´e dans ce m´emoire, sur le mod`ele de qualit´e ISO 9126. En effet, ce mod`ele me semble ˆetre le plus appropri´e pour les besoins de cette th`ese, car le plus complet et le plus fin. Il classifie les attributs qualit´e sous forme d’une forˆet, compos´ee de six arbres. Chaque arbre repr´esente un attribut qualit´e particulier. Ses feuilles sont les sous- caract´eristiques expos´ees pr´ec´edemment. Comme pr´ecis´e, ci-dessus, seuls les attributs qualit´e statiques sont consid´er´es. Les caract´eristiques qualit´e dynamiques comme l’efficacit´e ou la fiabilit´e ne sont pas prises en compte, car l’´evolution trait´ee dans ce travail est faite `a l’arrˆet de l’ex´ecution du logiciel (´evolution statique). Notez que, dans la suite de ce m´emoire, le terme performance se substitue au terme efficacit´e, car il est le plus utilis´e dans la litt´erature.

Bien que le mod`ele de qualit´e du SEI ait ´et´e bien sp´ecialis´e pour les architectures logi- cielles, celui-l`a est moins complet que le mod`ele ISO 9126 car il s’int´eresse `a d’autres types de qualit´es qui ne sont pas int´eressantes dans le cadre de cette th`ese, `a savoir les qualit´es d’af- faire. Par contre, le mod`ele ISO 9126 ne concerne que la qualit´e du produit comme pr´ecis´e dans [67], ce qui correspond exactement `a l’objectif vis´e dans cette th`ese. En effet, l’objectif est de documenter les d´ecisions architecturales li´ees aux ´el´ements architecturaux (composants, entre autres) et donc les produits et non pas les processus ou le domaine d’affaire.