Attributs de qualité 

Nous avons décidé d’utiliser les termes «attributs de qualité» au lieu de «exigences non fonctionnelles » lors de la rédaction de ce mémoire pour se conformer au vocabulaire utilisé en architecture logicielle.

La norme ISO/IEC 14598-1 (ISO/IEC, 1998) donne la définition suivante pour un attribut : « a measurable physical or abstract property of an entity » et pour une qualité : « the totality of characteristics of an entity that gear on its ability to satisfj; stated and implied needs ».

Nous allons donc adopter ces définitions pour la suite de la recherche.

Architecture 

La norme IEEE 1471 (2000) traite spécifiquement de la description architecturale des systèmes à forte composante logicielle et par conséquent fournit une définition qui est « The fundamental organization of a system embodied in its components, their relationships to each other, and to the environment, and the princip/es guiding its design and evolution ».

Toutefois, il existe d’autres références sur le sujet. En particulier, les ouvrages de Bass et al. (Bass, Clements, & Kazman, 1998, 2003) sur l’architecture logicielle offrent beaucoup d’informations pertinentes. Ils ont décomposé leurs ouvrages en quatre parties suivant grossièrement le cycle de vie. La première partie traite de l’architecture envisagée et se concentre sur la technique Architecture Business Cycle (ABC) et les définitions. La seconde partie porte sur la conception de l’architecture en s’aidant des attributs de qualités et des tactiques, pour faciliter la transition des attributs de qualité vers une architecture. La troisième partie concerne l’analyse d’une architecture existante avec des techniques telles que ATAM (Architecture Tradeoff Analysis Method) et CBAM (Cost Benefit Analysis Method). Enfin, la dernière partie examine la question de la migration d’une architecture monolithique vers une architecture modulaire. Les deux ouvrages donnent des exemples réels très intéressants et proposent des techniques applicables au contexte de cette recherche. En effet, les discussions sur les qualités architecturales et les tactiques, plus la technique AT AM pour l’ extraction de qualités architecturales d’une architecture existante, donnent de bonnes bases pour commencer la recherche dans le cadre de la problématique.

De plus, Bass et al. (2003) définissent l’architecture logicielle comme «The software architecture of a program or computing system is the structure or structures of the system, which comprise software elements, the external visible properties of those elements, and their relationships among them ». Dans la première version du livre (Bass et al., 1998), le terme « composant » était utilisé plutôt que celui d’« élément ». En utilisant ce dernier, les auteurs veulent éviter toute confusion avec les techniques de développement logiciel basées sur les composants. Toutefois, dans le contexte de notre partenaire, l’utilisation du terme «composant» semble plus appropriée (tout en gardant la définition initiale), car l’entreprise souhaite mettre l’ accent sur la réutilisation de composants.

Pour l’étude, nous allons considérer les deux définitions sans porter de jugement sur l’une et l’autre, car elles offrent une vision claire d’une architecture logicielle. Toutefois, il est possible de trouver d’autres définitions toutes aussi acceptables.

Ligne de produits 

Le concept de ligne de produits au niveau du développement logiciel est un concept relativement nouveau. Actuellement, plusieurs auteurs font des recherches dans ce domaine pour fournir des processus de support pour l’implémentation d’une ligne de produits dans une organisation.

Dans leur ouvrage, Clements et Northrop (2001) définissent« 29 skill areas in which an organization needs to be adept in order to achieve a software product line capability». De plus, ils proposent une définition d’une ligne de produits au niveau logiciel, qui est : « a set of software-intensive systems sharing a common, managed set of features that satisfy the specifie needs of a particular market segment or mission and that are developed from a common set of core assets in a prescribed way ». Enfin, ils donnent une définition d’une architecture de ligne de produits, qui est:

« A product tine architecture is a software architecture that will satisfy the needs of the product line in general and the individual products in particular by explicitly admitting a set of variation points required to support the spectrum of products within the scope ».

D’autres auteurs (Bass et al., 2003; Bosch, 2000) font ressortir deux principes de base pour une ligne de produits et proposent des processus pour soutenir ces deux principes. En effet, ces auteurs estiment que ces deux principes sont à la base de la définition d’une architecture logicielle dans le contexte d’une ligne de produits. Le premier principe est « la mise en commun » qui signifie de définir ce qui est commun entre les différents produits d’une ligne de produits et de le partager (c’est-à-dire de prévoir les mécanismes pour supporter les mises en commun). Le second principe est « la variabilité » qui signifie de définir ce qui est différent entre les produits formant la ligne de produits et de prévoir les mécanismes pour supporter ces différences. Ces deux principes permettent d’extraire des caractéristiques pour supporter les mises en commun et les différences au niveau de l’architecture. Par exemple pour les différences, Clements et Northrop (2001, page 64) soulignent que:

« In a conventional architecture, the mechanism for achieving different instances a/most a/ways cames dawn to modifying the code. But in a software product fine, support for variation can take many forms. Variation can be accomplished by introducing build-time parameters to a component, subsystem, or a collection of subsystems, whereby a product is conjigured by setting a collection of values ».

La définition fournie par Clements et Northrop est parfaite pour l’étude car elle montre bien la différence avec une architecture logicielle pour un seul produit et les points de variations. Donc, nous allons faire référence à cette définition tout au long de cette étude .

Composants

Cette section se concentre sur des définitions pour les composants seuls ou dans le contexte d’une ligne de produits. En effet, une architecture de ligne de produits doit supporter des mécanismes pour la mise en commun   et le concept de composants offre une solution concrète à cette problématique.

Dans son ouvrage, Bosch (2000) propose la définition suivante : « A software component is a unit of composition with explicitly specified provided, required and configuration interfaces and quality attributes ».

Il ajoute (Bosch, 2000, page 220) que:
« An interface defines a contract between a component requiring certain functionality and a component providing that functionality. The interface represents a first-class specification of the functionality that should be accessible through it. The interface specification is, ideally, independent of the component or components implementing that interface».

D’autre part, Szyperski et al. (2002, page 41) suggère que: «A software component is a unit of composition with contractually specified interfaces and explicit context dependencies only. A software component can be deployed independently and is subject to composition by third parties ». Il ajoute (2002, page 50) que : «An interface is a set of named operations that can be invoked by clients. Each operation ‘s semantics is specified, and this specification plays a dual role as it serves both providers implementing the interface and clients using the interface ».

Les points communs entre ces deux définitions sont qu’un composant est une unité de composition avec des interfaces fournies aux utilisateurs de ce composant et des interfaces requises au bon fonctionnement de celui-ci. Toutefois, il y a des différences entre les deux définitions. Le premier point est que seul Bosch mentionne les attributs de qualité. Un attribut de qualité souligne l’importance des caractéristiques décrivant une ou plusieurs contraintes du composant. Or, le respect ou non par le composant de certaines caractéristiques désirées pour une architecture logicielle peut limiter les possibilités de réutilisation. Le second point est que Bosch mentionne le besoin pour un composant d’avoir des interfaces pour sa configuration. Ces interfaces sont nécessaires pour gérer les points de variations (ceci fait référence aux besoins de gérer les variabilités comme expliqué dans la section précédente), ce qui est très important pour améliorer les possibilités de réutilisation du composant.