Un modele de substitution pour les composants

logiciels

Bart George, Regis Fleurquin, and Salah Sadou

VALORIA Lab., University of South Brittany, France{Bart.George,Regis.Fleurquin,Salah.Sadou}@univ-ubs.fr

Abstract. L’un des buts majeurs du Genie Logiciel est de construiredes applications complexes de facon simple. Pour ce faire, les composantslogiciels doivent etre decrits a la fois par leurs proprietes fonctionnelleset non-fonctionnelles. Le probleme est alors de savoir quel composantpeut satisfare un besoin specifique dans un contexte de compositionspecifique, que ce soit pendant la conception ou pendant la maintenancedu logiciel. Nous pensons que dans les deux cas il s’agit d’un problemede substitution. Pour resoudre ce probleme, nous proposons un modelede substitution qui prend en compte les proprietes fonctionnelles et non-fonctionnelles, ainsi que le contexte de composition.

1 Introduction

La programmation par composants devrait permettre de construire une applica-tion comme un puzzle dont les pieces seraient des unites ”sujettes a compositionpar une tierce personne” [18]. Par exempe, des composants ”sur etagere”, ouCOTS (Component-Off-The-Shelf ), qui sont des produits commerciaux, de con-structeurs et d’origines quelconques, achetes et utilises par des tiers pour leursapplications. Lorsqu’on developpe et qu’on maintient ces applications, de nom-breux problemes se posent. Nous en citerons deux : comment savoir, parmi ununivers de composants de toutes origines, lequel sera le plus a meme de repondrea un besoin identifie lors de la conception d’une application? Et lors d’une main-tenance, si ce besoin evolue, le composant choisi sera-t-il toujours adapte oudevra t-on le remplacer?

Nous pensons que ces questions peuvent etre ramenees a un probleme desubstitution. En effet, lorsqu’on concoit ou qu’on maintient une application, desbesoins emergent, et pour les decrire, le concepteur peut imaginer les composantsqui satisferaient pleinement ces besoins : des composants ideaux. Le problemeserait alors de trouver les composants ”concrets” qui se rapprocheraient le plusde ces composants ideaux, et qui pourraient donc se substituer a eux. En d’autrestermes, le probleme de la composition et celui de l’evolution de composantspeuvent se ramener a un probleme de substitution de l’ideal par le concret.

Cependant, les besoins d’une application ne sont pas uniquement fonction-nels : ils concernent aussi sa qualite. La plupart des composants sont des ”boıtesnoires”, qui doivent decrire leurs proprietes fonctionnelles et non-fonctionnelles

pour etre pleinement utilisables. Et toute application ayant des obligations dequalite, donc relatives a de telles prorpietes non fonctionnelles, il est impens-able d’assembler au hasard des composants muets sur ce point en esperant aufinal obtenir le niveau de service specifie. C’est pourquoi une substitution de com-posants doit tenir compte de leurs proprietes fonctionnelles et non-fonctionnelles.

Quel mode de substitution faut-il choisir ? On pourrait utiliser le sous-typage,deja present dans les autres paradigmes de programmation tels que l’objet.Cependant, un composant ideal decrit plus que de simples besoins : il decritaussi le contexte dans lequel ces besoins emergent, une notion qui est absente dumonde objet. Qu’entend-on par ”contexte” ? Si l’on considere un besoin modelisepar un composant ideal, le probleme est de trouver le composant concret quipourra se substituer a lui. Maintenant, supposons que ce composant concret aete trouve. Peut-etre qu’entre temps un autre est apparu, qui repondrait mieuxau besoin initial. Cependant, comparer ce nouveau candidat avec l’ancien seraitune erreur : le coeur du probleme n’est pas le candidat, mais le besoin qu’ilest sense satisfaire. Et si ce besoin evolue, le composant ideal qui le modelisepourrait aussi evoluer, et le composant concret precedemment trouve pourraitne plus etre capable se se substituer a ce nouvel ideal. C’est pourquoi la substi-tution d’un composant ideal par un composant concret n’a de sens que dans lecontexte du besoin modelise par ce composant idal. Et chaque candidat concretetant compare a ce composant ideal (et seulement a celui-ci), un candidat peutle remplacer, ou remplacer un autre candidat, sans qu’il y ait de relation desous-typage entre eux.

Nous allons maintenant nous placer dans le cadre de modeles de composantet de qualite generiques (section 2), et dans ce cadre, nous allons definir (section3) un modele de substitution oriente composants, dont les regles s’appliquentaux differents elements fonctionnels et non-fonctionnels de ce modele. Pour il-lustrer ses possibilites, nous decrirons les differents cas de substitution appliquesa un exemple (section 4). Avant de conclure, nous situerons notre approche parrapport aux travaux existants (section 5).

2 Modeles de composant et de qualite

Pour le reste de ce papier, nous nous placons dans le cadre suivant : un mememodele de composant, possedant un systeme de types (exemple : Java pourFractal [6]), et un meme modele de qualite (exemple: le standard ISO-9126 [13]).Dans ce cadre, nous supposons l’existence de metriques pour gerer les aspectsnon-fonctionnels (exemples: [2, 20]), afin que notre contribution se concentre surla definition du modele de substitution.

2.1 Des modeles generiques

Notre but n’est pas de donner une nouvelle definition de ce qu’est un modelede composant ou une propriete non-fonctionnelle. Notre but est de definir unesubstitution orientee composants que nous pouvons appliquer a la plupart des

modeles de composant et de qualite existants. C’est pourquoi nous avons choiside prendre pour base des modeles generiques, sur lesquels nous pouvons appli-quer nos concepts de substituabilite.

Fig. 1. Modeles generiques

On appelle artefacts les elements du modele de composant generique quisont communs a la plupart des modeles de composant existants, et qui sontsusceptibles d’avoir des proprietes non-fonctionnelles. Comme indique Figure 1,nous avons retenu trois types d’artefacts : les composant eux-memes, les inter-faces, et les operations. Par la suite, nous parlerons de composants substituants

(ou candidats) et substituables quand on testera si les premiers peuvent sesubstituer aux seconds. De meme, leurs elements seront appeles respectivementdes elements substituants ou candidats, dotes de l’indice 1 (A1, C1...), et deselements substituables, dotes de l’indice 0 (A0, C0...). Et quand nous auronstrouve le meilleur candidat pour une substitution, nous dirons que le composantou l’element substituable peut etre remplace par ce candidat.

En plus de ce modele de composant generique, nous definissons un modelede qualite generique, constitue de caracteristiques de qualite (telles que cellesdu standard ISO-9126 [13]) et de metriques. Nous avons choisi d’utiliser lesmetriques existantes (exemple: [2, 20]) pour mesurer et comparer les proprietesnon-fonctionnelles. En effet, il existe de nombreuses methodes pour definir etevaluer de telles proprietes, comme les reseaux de Petri temporels et les processusstochastiques [9], les completions [21] ou les contrats de qualite de service [8].Mais en general, de telles methodes se focalisent sur une propriete ou une famillede proprietes en particulier (par exemple, la qualite de service, qui n’est qu’unepartie de la qualite). Or nous avons choisi les metriques parce qu’elles peuventetre appliquees a plusieurs familles de proprietes differentes et permettent descomparaisons entre les differentes mesures.

Nous allons maintenant decrire les elements de ces modeles generiques. Nousallons d’abord voir ceux du modele de qualite, puis ceux du modele de com-posant, avant d’introduire le lien entre les deux modeles.

2.2 Elements du modele de qualite

Le modele de qualite comprend deux elements: les caracteristiques de qualite, etles metriques qui mesurent ces caracteristiques (partie gauche de la Figure 1).Nous supposons qu’une meme metrique peut mesurer plusieurs caracteristiquesde qualite (comme c’est propose dans le standard IEEE 1061-1998 [12]), maisque chaque caracteristique ne peut etre mesuree que par une seule metrique.Voici leur definition:

Caracteristiques de qualite: Une caracteristique de qualite, ou plus simple-ment caracteristique, represente une certaine propriete non-fonctionnelle, telleque la maintenabilite, l’interoperabilite, ou la portabilite. Elle contient la metriquequi mesure sa valeur.

Metriques: Une metrique contient principalement l’ensemble de caracteristiquesqu’elle mesure, le type d’artefact sur lequel elle peut etre utilisee (exemple: com-posant, interface...), le type du resultat, son unite, et sa variance. Ce dernierchamp interprete la relation entre le resultat de la metrique et la caracteristiqueevaluee. Par exemple, si une metrique calcule un temps d’execution, la varianceindiquera que plus ce temps sera bas, meilleur sera le resultat.

Deux valeurs de metriques sont comparables uniquement si elles proviennentde la meme metrique. Donc quand on parle de ”metriques comparables” M1

(appartenant a un arteface substituant A1) et M0 (appartenant a un artefactsubstituable A0), cela signifie que nous sommes en presence d’une meme metriqueM et qu’on compare la valeur de M sur A1 avec la valeur de M sur A0. Si M1

et M0 sont comparables, alors on peut determiner si M1 est superieur a M0

selon la variance. Par exemple, si une metrique de type entier represente untemps d’execution en millisecondes, sa variance est decroissante. Dans ce cas, sila valeur de M1 est un entier plus grand que la valeur de M0, en fait, M1 estinferieure a M0 selon la variance.

2.3 Specifications non-fonctionelles

Le modele de qualite et le modele de composant sont lies par un element appelespecification non-fonctionnelle ou NFS. Une NFS est un attribut d’artefactqui comprend, outre cet artefact ”parent”, une caracteristique de qualite, lametrique qui mesure cette caracteristique, et le resultat du calcul de cette metriquesur l’artefact parent (l’attribut resultValue sur la Figure 1). Dans le cas d’uncomposant ideal, cette valeur est donnee par le concepteur de ce composant.

Comme un artefact peut posseder plusieurs proprietes non-fonctionnellesdifferentes, un artefact peut avoir plusieurs NFS, mais une NFS ne peut ap-partenir qu’un seul artefact. De meme, plusieurs NFS appartenant a un memeartefact peuvent se partager la meme metrique, mais pas la meme caracteristique.

Deux NFSs sont comparables si leurs artefacts sont de meme type et sontcomparables (voir section suivante), et si elles mesurent la meme metrique. DeuxNFSs sont egales si elles sont comparables et si leur attribut resultValue ont lameme valeur.

2.4 Artefacts

Les artefacts sont les principaux elements de notre modele de composant generique.Un artefact, quel que soit son type, possede un champ qualite, qui est l’ensemblede ses NFSs. Deux champs qualite d’artefacts sont comparables si, pour aumoins une NFS d’un champ qualite il existe une NFS comparable appartenant al’autre champ qualite. Deux champs qualite sont egaux si pour chaque NFS d’unchamp qualite, il existe une NFS egale appartenant a l’autre champ qualite, etvice versa.

Voici maintenant la description des differents types d’artefacts:

Operations: Une operation d’interface est definie par sa signature (on ditaussi son type). Un type d’operation est defini par l’ensemble des types de sesparametres (α1, ... , αn)1 et le type de son resultat β. Le type est note (α1, ... ,αn) −→ β.

Deux operations sont comparables si leurs signatures sont comparables. Deuxsignatures d’operations T et U sont comparables si elles sont egales au renom-mage de noms de types pres, ou s’il existe une substitution de types V telle queV .T est egal a U , ou T est egal a V .U , au renommage de noms de types pres.

Par exemple, α −→ α est egal a β −→ β si l’on renomme α en β, mais α

−→ α n’est pas egal a β −→ γ. Et si l’on considere le type Object de Java, lasignature Object −→ Object peut etre remplacee par Integer −→ Integer siInteger substitue Object. Cela correspond aux matchings exact et generalise deZaremski et Wing [22].

Deux operations sont egales si leurs signatures sont egales au renommage denoms de types pres, et si leurs champs qualite sont egaux.

Interfaces: Une interface de composant est definie par l’ensemble de ses operations.Une interface fournie candidate PI1 (”PI” pour ”provided interface”) est

comparable a une interface fournie substituable PI0 si pour chaque operationde PI0 il existe une operation comparable dans PI1. Une interface requise sub-stituable RI0 (”RI” pour ”required interface”) est comparable a une interfacerequise candidate RI1 si pour chaque opeeration de RI1 il existe une operation

1 Pour des raisons de simplicite, dans la version actuelle de notre modele, nous neprenons pas en compte l’ordre des parametres.

comparable dans RI0. Deux interfaces (fournies ou requises) sont egales si leurschamps qualite sont egaux et si, pour chaque operation de l’une des interfaces,il existe une operation egale dans l’autre interface, et vice versa

Composants: Un composant logiciel est defini par l’ensemble de ses interfacesfournies et l’ensemble de ses interfaces requises.

Un composant candidat C1 est comparable a un composant substituable C0

si pour chaque interface fournie de C0 il existe une interface fournie comparableappartenant a C1, et si pour chaque interface requise de C1, il existe une inter-face requise comparable appartenant a C0. Si C1 n’est pas comparable a C0, sacandidature pour la substitution de C0 est rejetee d’emblee.

3 Notre modele de substitution

On alloue a chaque NFS un poids de comparaison, note ComparisonS , etune penalite notee PenaltyS (S etant la NFS). Ces deux valeurs represententl’importance de la NFS pour l’artefact auquel elle appartient. Plus ces valeurssont elevees, plus la NFS est importante a l’interieur d’un composant substitu-able. Si un arteface substituable A0 possede une certaine NFS S0, et si un arte-fact candidat A1 comparable possede une NFS comparable S1 avec une valeurde resultat superieure a celle de S0, les chances du composant candidat d’etreretenu augmentent proportionnellement au poids de S0. Dans le cas contraire, cemanque sera sanctionne proportionnellement a la penalite de S0. Il arrive qu’uncomposant candidat apporte ses propres NFSs que le composant substituable n’apas. En d’autres termes, le composant candidat peut avoir ses propres qualitesnon prevues par le concepteur du composant ideal. Dans ce cas, il aura la charged’evaluer lui-meme ces nouvelles NFSs.

En utilisant et en combinant les poids, les penalites et les resultats des NFS,on definit une distance de substitution entre un element candidat et un elementsubstituable. Cette distance va informer sur la substituabilite d’une NFS oud’un artefact. Le meilleur candidat pour la substitution est celui pour lequella distance avec le substituable est la plus petite. Si la distance est negative,le candidat peut etre considere, en termes de qualite, comme ”meilleur” que lesubstituable d’apres le contexte. Si la distance est positive, le candidat est moinsbon. Si la distance est nulle, il est ”equivalent” au substituable, sans forcementetre egal.

Chaque composant substituable possede une distance maximale pour lasubstitution, fixee par le concepteur de celui-ci. Si la distance entre un composantcandidat C1 et un composant substituable C0 est superieure a la distance max-imale associee a C0, alors la candidature de C1 sera rejetee.

3.1 Distance de substitution entre artefacts

Nous allons maintenant d efinir le calcul qui va donner la distance separantun composant candidat C1 d’un composant substituable C0 dans un contexte

donne. Ce contexte est defini par les poids et les penalites alloues aux NFSs desartefacts de C0. Donc avant d’examiner la distance entre chaque type d’artefacts,nous allons definir la distance entre les champs qualites d’artefacts (tous typesconfondus).

Nous supposons qu’il existe une relation MINx∈E f(x), qui selectionne unelement x de l’ensemble E tel que la fonction f(x) a la plus petite valeur.

Distance entre champs qualite d’artefacts. Soient un artefact substituableA0, un artefact candidat A1 comparable a A0, et leurs champs qualite respectifs(notes QA0

et QA1. La distance de substitution entre ces champs qualite (notee

QD) est definie comme suit:

QD(QA1, QA0

) =∑

S0∈QA0

QDSpec(QA1, S0) -

∑S1∈QA0

QDBonus(S1, QA0)

avec:

QDSpec(QA1, S0) = MINS1∈QA1

ComparisonS0* (resultV alueS0

−V ariance

resultV alueS1) si S0 et S1 sont comparables; PenaltyS0

sinon.

et:

QFBonus(S1, QA0) = 0 si ∃ S0 ∈ QA0

qui est comparable a S1; une valeurentree par le concepteur de C0 sinon.

Pour mesurer la distance entre deux champs qualite, nous prenons en comptela plus petite difference trouvee pour chaque S0. Pour chaque S0 substituablequi n’a aucun S1 comparable, nous prenons en compte leur penalite PenaltyS0

.Pour chaque S1 qui n’a aucun S0 comparable, nous prenons en compte une valeurentree par le concepteur de C0 (c’est lui-meme qui estimera la valeur de cetteNFS supplementaire).

resultV alueS0−V ariance resultV alueS1

est une soustraction de resultV alueS0

par resultV alueS1dependant de la variance V ariance de la metrique commune

a S1 et S0. Par exemple, si le type de celle-ci est entier ou reel et si V ariance estcroissante, la mesure sera egale a: resultV alueS0

- resultV alueS1. Si V ariance

est decroissante, la mesure sera egale a: resultV alueS1- resultV alueS0

.

Distance entre artefacts incomparables. Si deux artefacts sont incompa-rables, il n’y a pas de calcul de distance.

Distance entre operations comparables. Soient une operation substituableO0 et une operation comparable O1. La distance de substitution entre elles (noteeOpD) est definie comme suit:

OpD(O1, O0) = QD(QO1, QO0

)

Quand O1 et O0 sont comparables, la distance entre elles est en fait la distanceentre leurs champs qualite.

Distance entre interfaces fournies comparables. Soient une interface fourniesubstituable I0, une interface fournie candidate I1 comparable a I0, et leurs en-sembles d’operations respectifs OpsI0 et OpsI1 . La distance de substitution entreI1 et I0 (notee PID) est definie comme suit:

PID(I1, I0) =∑

O0∈OpsI0

MINO1∈OpsI1OpD(O1, O0) -

∑O1∈OpsI1

POBonus(O1,

I0) + QD(QI1 , QI0)

avec:

POBonus(O1, I0) = 0 si ∃ O0 ∈ OpsI0 qui est comparable a O1; une valeurentree par le concepteur de C0 sinon.

Pour mesurer la distance entre les interfaces, nous prenons en compte laplus petite distance trouvee pour chaque O0. Pour chaque O1 qui n’a aucun O0

comparable, nous prenons en compte une valeur entree par le concepteur de C0

(c’est lui-meme qui estimera la valeur de cette operation supplementaire).

Distance entre interfaces requises comparables. Soient une interface req-uise substituable I0, une interface requise candidate I1 qui est comparable aI0, et leurs ensembles d’operations respectifs OpsI0 et OpsI1 . La distance desubstitution entre I1 et I0 (notee RID) est definie comme suit:

RID(I1, I0) = -∑

O0∈OpsI0

MINO1∈OpsI1OpD(O1, O0) -

∑O0∈OpsI0

ROBonus(I1,

O0) - QD(QI1 , QI0)

avec:

ROBonus(I1, O0) = 0 si ∃ O1 ∈ OpsI1 qui est comparable a O0; une valeurentree par le concepteur de C0 sinon.

Le principe de la distance entre interfaces requises est symetrique du principede la distance entre interfaces fournies. Si I1 et I0 sont deux interfaces fournies,il vaut mieux que I1 fournisse une meilleure qualite que I0. Si I1 et I0 sont deuxinterfaces requises, il vaut mieux que I0 requie une meilleure qualite que I1.

Distance entre composants comparables. Soient un composant substitu-able C0, un composant candidat C1 qui est comparable a C0, leurs ensemblesd’interfaces fournies respectifs PIntC0

et PIntC1, et leurs ensembles d’interfaces

requises respectifs RIntC0et RIntC1

. La distance de substitution entre C1 etC0 (notee CD) est definie comme suit:

CD(C1, C0) =∑

PI0∈PIntC0

MINPI1∈PIntC1PID(PI1, PI0) +

∑RI1∈RIntC1

MINRI0∈RIntC0RID(RI1, RI0) -

∑PI1∈PIntC1

PIBonus(PI1, C0) -∑

RI0∈RIntC0

RIBonus(C1, RI0) + QD(QC1, QC0

)

avec:

PIBonus(PI1, C0) = 0 si ∃ PI0 ∈ PIntC0qui est comparable a PI1; une

valeur entree par le concepteur de C0 sinon.

et:

RIBonus(C1, RI0) = 0 si ∃ RI1 ∈ RIntC1qui est comparable a RI0; une valeur

entree par le concepteur de C0 sinon.

Pour mesurer la distance entre C1 et C0, nous prenons en compte la pluspetite distance trouvee pour chaque PI0 et chaque RI1. Pour chaque PI1 quin’a aucun PI0 comparable, et pour chaque RI0 qui n’a aucun RI1 comparable,nous prenons en compte une valeur entree par le concepteur de C0 (c’est lui-memequi estimera la valeur, respectivement de cette interface fournie supplementaireou de cette interface requise en moins).

4 Mise en pratique

Considerons maintenant une application qui requiert un composant de typecamera numerique, fournissant une interface pour la video et une interface pourle controle des fonctionnalites de la camera. En tant que camera numerique, lecomposant doit aussi etre conforme au standard Digital Video (”DV”) et avoirune interface requise pour la lecture des cassettes DV. Cet exemple est inspirede [4].

4.1 Modelisation d’un composant ideal

Fig. 2. Exemple de composant ideal: videoCamera.

Les exigences precedentes peuvent etre exprimees sous la forme d’un com-posant ideal, appele videoCamera. Celui-ci contient une interface fournie videoStream

(possedant une operation outputV ideoF low pour le flux video), une interfacefournie cameraControl (possedant quelques operations telles que on pour al-lumer, record pour enregistrer et eject pour sortir la cassette2), et une interfacerequise DV Format (possedant une operation inputDV F low qui demande unecassette DV).

Ces besoins ne sont pas seulement fonctionnels, mais aussi non-fonctionnels,chaque besoin ayant son importance particuliere. Par exemple, supposons qu’unehaute fiabilite soit exigee pour les operations record et eject (afin que la camerane plante pas pendant l’enregistrement, ou ne refuse pas d’ejecter une cassette).Supposons egalement qu’une bonne qualite d’image, telle qu’une resolution d’1million de pixels (1 MPixels) soit exigee pour l’interface videoStream. D’apresle modele de qualite Figure 3, les caracteristiques de qualite suivantes sont a notredisposition : reliability pour la fiabilite (mesuree par la metrique MeanT imeToFailure,ou MTTF ) et imageQuality pour la qualite de l’image (mesuree par la metriquescreenResolution). Nous allons donc attacher un certain nombre de NFSs auxartefacts du composant ideal. A chaque operation de l’interface cameraControl

nous attacherons une NFS utilisant la caracteristique reliability (a l’operationon la NFS onReliability, a record la NFS recordReliability, et a eject la NFSejectReliability). A l’interface videoStream nous attachons la NFS cameraResolution

qui utilise la caracteristique imageQuality.

Fig. 3. Example of quality model.

Enfin, le concepteur va fixer pour chaque NFS les valeurs de resultat at-tendues ainsi que les poids et les penalites. Puis le composant videoCamera severra attribuer une distance maximale autorisee. Sur la Figure 2, nous pouvonsvoir que la valeur demandee pour cameraResolution est de 1 million de pix-els, et que les valeurs demandees pour recordReliability et ejectReliability (3jours) sont plus elevees que pour onReliability (1 jour). Les penalites allouees

2 Pour des raisons de simplicite, nous nous limiterons a ces trois operations

a cameraResolution, recordReliability et ejctReliability sont tres elevees afind’obliger les composants candidats a posseder ces NFSs. En ce qui concerne lespoids de comparaison, cameraResolution a un faible poids (ce qui signifie qu’unecart dans la resolution n’est pas prejudiciable) tandis que les poids alloues arecordReliability et ejectReliability sont tres eleves (ce qui signifie qu’un ecartde fiabilite pour ces operations sera sanctionne). Pour finir, la distance maximaleest assez faible en comparaison de ces poids et de ces penalites, ce qui signifiequ’une absence d’une NFS importante dans un composant candidat conduirapresque ineluctablement au rejet de ce candidat.

4.2 Cas de substitution

Maintenant que le composant ideal est modelise, nous pouvons rechercher lemeilleur candidat pour le substituer, selon le cas de substitution dans lequel onse trouve. Voici les differents cas:

Premiere composition. Integrer un composant dans une application afin desatisfaire un besoin revient a substituer ce composant ”concret” au composantideal qui correspond a ce besoin. Reprenons l’exemple de la camera video. Nousavons un composant ideal videoCamera et nous allons maintenant partir a larecherche du meilleur candidat qui pourra se substituer a ce composant.

Fig. 4. Example of candidate: V HSCamera.

Premierement, d’apres notre modele de substitution, un candidat doit satis-faire toutes les exigences fonctionnelles, ce qui signifie qu’il doit posseder toutesles interfaces fournies (ainsi que toutes leurs operations) du composant ideal,et qu’il ne doit rajouter aucune interface requise (ou operation d’interface req-uise) supplementaire. Sinon, ce candidat sera rejete sans meme qu’on examinesa qualite. Prenons par exemple le cas du composant V HSCamera Figure 4. Saqualite pourrait etre meilleure que celle de videoCamera. Malheureusement, cecandidat requiert non pas des cassettes DV, mais des cassettes VHS. Il ne peutdonc pas etre compare a videoCamera, et il est rejete des le depart.

Fig. 5. Example of candidate with its distance measurement: fluidCamera.

Ensuite, nous avons un candidat fluidCamera (Figure 5) qui rajoute unenouvelle NFS a l’operation outputV ideoF low. Cette nouvelle NFS calcule lenombre de frames par secondes du flux video. Ce qui correspond (Figure 3)a la metrique FPS qui peut mesurer les caracteristiques flowPerformance

(qui s’interesse a l’aspect performance d’un flux video) et flowQuality (quiexprime la ”qualite” d’un flux). Un tel ajout pourrait etre interessant, mais encontrepartie, il manque au candidat fluidCamera une NFS importante. Et lapenalite encourue est si elevee qu’il est rejete.

Nous pouvons egalement nous trouver en presence de candidats qui ont a lafois, en terme de qualite, des proprietes inferieures et des proprietes superieuresa celles exigees. Par exemple, le candidat goodImageCamera (Figure 6) possedeune excellente qualite d’image mais une fiabilite moyenne, tandis que le candi-dat reliableCamera (Figure 7) possede une qualite d’image moyenne, mais uneexcellente fiabilite. Nous n’allons pas les comparer entre eux pour determinerlequel est ”meilleur composant” que l’autre, mais nous allons comparer chacund’entre eux separement avec le composant ideal pour determiner lequel est plusa meme de se substituer a lui. Dans notre cas, les deux candidats sont accept-ables, mais reliableCamera est un bien meilleur candidat, car sa distance avecvideoCamera est tellement basse qu’elle est negative.

Maintenance a besoin constant. Nous supposons que l’application a desormaisson composant camera ”concret”. Cependant, un autre composant concret pour-rait s’averer ”meilleur”. Les besoins et le contexte sont les memes, donc le com-posant ideal est exactement le meme, mais nous pouvons avoir sans cesse denouveaux candidats. Nous devons donc comparer chacun d’entre eux separementavec le composant ideal, en ignorant le candidat qui a precedemment ete retenu.Nous revenons donc au cas de premiere composition.

Fig. 6. Example of candidate with its distance measurement: goodImageCamera.

Supposons que le candidat precedent, reliableCamera, a ete retenu. Un nou-veau candidat (appelons-le goodAndReliableCamera) peut se presenter, en pro-posant la meme fiabilite que reliableCamera mais avec une resolution superieure,egale a 1 MPixels. Une fois encore, nous n’allons pas comparer pas les can-didats entre eux, mais chaque candidat separement avec le composant ideal.Et nous allons nous rendre compte que le calcul de distance est en faveur degoodAndReliableCamera.

Maintenance avec evolution du besoin. L’application a toujours un com-posant camera ”concret”, mais les besoins ont change. Du coup, le composantideal a lui aussi change. Donc nous devons nous posser les questions suivantes :le candidat precedemment choisi est-il toujours le meilleur candidat pour se sub-stituer au nouveau composant ideal ? Et d’ailleurs, est-il toujours un candidatvalable ?

Ces nouveaux besoins peuvent etre fonctionnels, comme par exemple un nou-vel artefact. On pourrait ainsi avoir besoin, non plus d’une camera numeriquelisant des cassettes DV, mais d’une camera analogique lisant des cassettes VHS.Cela entraınerait dans le composant ideal le retrait de l’interface requise DV Format

et son remplacement par une interface requise V HSFormat. Dans ce cas, parmitous les candidats que nous avons precedemment examines, seul V HSCamera,precedemment rejete (Figure 4) serait comparable au nouveau composant ideal.Son accpetation dependrait de sa qualite.

Fig. 7. Example of candidate with its distance measurement: reliableCamera.

Ces nouveaux besoins peuvent etre uniquement non-fonctionnels, commepar exemple l’ajout d’une nouvelle NFS dans le composant ideal. On pourraitainsi avoir besoin de mesurer le nombres de frames par seconde du flux video,afin de s’assurer de la fluidite de notre camera. Cela entraınerait dans le com-posant ideal l’ajout d’une NFS utilisant la metrique FPS pour mesurer la car-acteristique flowPerformance ou flowQuality (voir Figure 3) sur l’operationoutputV ideoF low. Dans ce cas, le candidat fluidCamera, precedemment rejete(Figure 5), pourrait cette fois avoir ces chances. Il faudrait pour cela que la nou-velle NFS du composant ideal ait un poids tres important et qu’elle mesure lameme caracteristique que la NFS utilisee par fluidCamera (sinon, la compara-ison serait impossible).

Enfin, ces nouveaux besoins pourraient concerner une redistribution des poids,des penalites et des valeurs de resultats de NFS demandees. Par exemple, lenouveau composant ideal pourrait demander une valeur de 1.5 MPixels et unpoids de 20/1M (ou 2/100000) pour la NFS cameraResolution, et un poids de10 pour les NFSs recordReliability et ejectReliability. Soit une qualite d’imageplus elevee avec un poids plus important, et en contrepartie un poids moins elevepour pour la fiabilite. Dans ce cas, les candidats goodImageCamera (Figure 6)et reliableCamera (Figure 7) seraient toujours acceptables, mais leurs distancesseraient differentes. Pour reliableCamera, elle serait egale a : 20/1M * (1.5M -0.5M) + 2 * 10 * (3 - 4) + 5 * (1 - 2) = -5, tandis que pour goodImageCamera,elle serait egale a : 20/1M * (1.5M - 2M) + 2 * 10 * (3 - 2.5) = -10. Du coup,cette fois ce serait goodImageCamera qui serait le meilleur candidat.

5 Travaux connexes

La substituabilite dans le monde composant est en grande partie issue destravaux sur le typage [7] et le sous-typage [14], principalement dans le mondeobjet. Il s’agit egalement d’un probleme industriel, comme le souligne Van Om-mering dans [19], quand il se demande comment etre sur que les changementseffectues sur un composant n’affecteront pas les applications concernees. Lareponse qu’il preconise passe par des regles basees sur le sous-typage. Bien qu’ilsoit tentant de se baser nous-memes dessus pour substituer des composants, etainsi beneficier d’une theorie deja eprouvee [17], nous avons pris en compteles critiques de certains concepts issus du monde objet, comme par exemple letypage tel qu’il etait utilise [16], l’heritage [18], et le sous-typage [18]. Eneffet, chacun d’eux etait juge trop restrictif pour le monde des composants etne permettait pas de prendre en compte le contexte. C’est pourquoi nous avonsvoulu tenter une autre approche, plus flexible.

Premysl Brada, par exemple, a explore les notions de ”contexte de deploiement”et de ”substituabilite contextuelle” [5]. Le contexte de deploiement d’un com-posant est en fait le sous-ensemble de ses services qui sont reellement utilises parles autres composants de l’application, c’est-a-dire les services requis qui sont ap-provisionnes par les services requis d’autres composants, et les services fournisqui sont utilises par les services requis d’autres composants. La substituabilitecontextuelle de Brada consiste donc a comparer un composant candidat avec cesous-composant qui est le contexte de deploiement, plutot qu’avec tout le com-posant. Bien que ces notions semblent proches des notres, nous nous placcons aun niveau different. L’approche de Brada consiste, comme il le dit, en une substi-tuabilite ”architecture-aware”, et son contexte concerne un composant ”concret”qui depend de son deploiement dans l’architecture globale. Notre approche estplutot ”need-aware”, c’est-a-dire a l’ecoute des besoins de l’application, et notrecontexte repose sur le composant ideal qui modelise ces besoins et qui doit etreremplace par un composant ”concret”.

Notre modele de substitution est inspire par le ”matching” de signature etde specification d’Amy Zaremski et Jeannette Wing [22, 23], qui est consacrea la recherche de composants (au sens d’ensembles de fonctions) dans une bib-liotheque, et qui peut etre utilise dans des cas qui ne peuvent etre pris en comptepar le sous-typage. Cependant, nous sommes alles au-dela de cette approche enprenant en compte le contexte et les proprietes non-fonctionnelles. En dehors deZaremski et Wing, il existe d’autres travaux sur la recherche et la reutilisationde bibliotheques de composants [15] qui ont retenu notre attention. Par exem-ple, nos notions de poids et de penalite peuvent etre comparees aux outils deScott Henninger [11]. Ces outils extraient des ”composants” a partir de mots-clesd’un code source, puis les placent dans une bibliotheque ou un graphe value secree entre les mots-cles et les composants. Ainsi, quand on cherche un mot ouun composant dans cette bibliotheque, un poids est calcule en propageant lesvaleurs des noeuds du graphe, et le meilleur composant est celui qui a le poids leplus eleve. Notre approche est a un niveau different, parce que notre recherchede candidats est basee sur la structure des composants plutot que sur les mots-

cles. Elle peut donc etre utilisee en complement du mecanisme precedent afin deraffiner la recherche de composants et de creer des bibliotheques plus sures.

Pour notre modele de qualite generique, nous nous sommes inspires de stan-dards de qualite tels que ISO-9126 [13], et de standards de metriques tels queIEEE-1061 [12]. Des exemples de metriques qui peuvent etre utilises par notremodele se trouvent dans [2, 20]. Mais la partie qualite de notre modele peutetre egalement utilisee avec des langages d’expression de contrats de qualite deservice (bases sur le quatrieme niveau de contrats de composant d’Antoine Beug-nard [3]), tels que QML [10] et QoSCL [8]. En particulier, notre volonte d’inclureles proprietes non-fonctionnelles peut etre rapprochee du langage CQML de JanAagedal [1], qui gere la substituabilite des ”profils de qualite de service”. Cepen-dant, contrairement a CQML, qui comme beaucoup de langages similaires, neprend pas en compte les aspects fonctionnels, notre modele combine la par-tie fonctionnelle et la partie fonctionnelle. Et contrairement a Aagedal qui faitla distinction entre la substitution des composants primitifs et celle des com-posants composites, nous avons choisi de ne nous occuper que de la substitutioncontextuelle de deux composants, sans nous soucier de leur structure interne.

6 Conclusion

Nous avons propose un modele de substitution incluant plusieurs elements: i)un modele de qualite generique, capable d’utiliser les metriques et les contratsde qualite de service existants. ii) un modele de composant generique, capa-ble d’utiliser les composants issus de modeles academiques et industriels exis-tants. iii) une distance de substitution, capable de mesurer la substituabilite d’uncomposant candidat dans un contexte donne. Nous avons egalement introduitla notion de contexte de composition, dans lequel s’effectue la substitution decomposants, ainsi que la notion de composant ideal, qui modelise les besoinsfonctionnels et non-fonctionnels d’une application.

Dans un premier temps, nous nous sommes limites au cas ou nous sommesen face de composants d’origines differentes, mais issus d’un meme modele, et decaracteristiques de qualite issues egalement d’un meme modele de qualite. Cettelimitation est dictee par deux faits : d’une part, dans l’etat actuel des choses,une composition ne concerne que des composants issus d’un meme modele ;d’autre part, le probleme de correspondance entre composants issus de modelesdifferents est orthogonal a celui qui concerne la substitution. Il peut donc etretraite a part.

En ce moment, nous disposons d’un outil qui nous permet de dire si uncomposant peut se substituer a un autre d’apres notre mesure de distance desubstitution. Cet outil a pour but d’aider les developpeurs a trouver les meilleurscomposants pour leurs applications.

References

1. J. Aagedal. Quality of Service Support in Development of Distributed Systems.PhD thesis, University of Oslo, 2001.

2. M. Bertoa and A. Vallecillo. Quality attributes for cots components. In Proceedingsof the ECOOP Workshop on Quantitative Approches in Object-Oriented SoftwareEngineering, June 2002.

3. A. Beugnard, J.-M. Jezequel, N. Plouzeau, and D. Watkins. Making componentscontract aware. IEEE Computer, 32 (7), 1999.

4. G. Blair and J.-B. Stefani. Open Distributed Processing and Multimedia. Addison-Wesley, 1997.

5. P. Brada. Specification-Based Component Substituability and Revision Identifica-tion. PhD thesis, Charles University in Pragues, 2003.

6. E. Bruneton, T. Coupaye, and J.-B. Stefani. The fractalcomposition framework specification. final release, version 1.0.http://fractal.objectweb.org/doc/index.html, July 2002.

7. L. Cardelli. Type systems. In A. B. Tucker, editor, The Computer Science andEngineering Handbook, chapter 97. CRC Press, 2004.

8. O. Defour, J.-M. Jezequel, and N. Plouzeau. Extra-functional contract support incomponents. In Proceedings of 7th International Symposium on Component-BasedSoftware Engineering (CBSE 7), May 2004.

9. R. Dumke, C. Rautenstrauch, A. Schmietendorf, and A. Scholz. PerformanceEngineering. Berlin : Springer, 2001.

10. S. Frolund and J. Koistinen. Qml : A language for quality of service specification.Technical report, Hewlett-Packard Laboratories, Palo Alto, California, USA, 1998.

11. S. Henninger. Constructing effective software reuse repositories. In ACM TOSEM1997, 1997.

12. IEEE. IEEE Std. 1061-1998 : IEEE Standard for a Software Quality MetricsMethodology, ieee computer society press edition, 1998.

13. ISO Int. Standards Organisation, Geneva, Switzerland. ISO/IEC 9126-1:2001 Soft-ware Engineering - Product Quality - Part I : Quality model, 2001.

14. B. Liskov and J. Wing. A behavioral notion of subtyping. In ACM Transactionson Programming Languages and Systems 1994, 1994.

15. D. Lucredio, A. Prado, and E. S. D. Almeida. A survey on software componentssearch and retrieval. In EUROMICRO, 2004.

16. D. E. Perry and A. L. Wolf. Foundations for the study of software architecture.ACM SIGSOFT Software Engineering Notes, 17 (4):40–52, October 1992.

17. J. C. Seco and L. Caires. A basic model for typed components. In Proceedings ofthe 14th ECOOP, 2000.

18. C. Szyperski. Component Software : Beyond Object-Oriented Programming.Addison-Wesley / ACM Press, second edition, 2002.

19. R. Van Ommering. Software reuse in product populations. IEEE Transactions onSoftware Engineering, 31 (7):537–550, july 2005.

20. H. Washizaki, H. Yamamoto, and Y. Fukazawa. A metrics suite for measuringreusability of software components. In Metrics 2003, 2003.

21. M. Woodside, D. Petriu, and K. Siddiqui. Performance-related completions forsoftware specifications. In Proceedings of International Conference on SoftwareEngineering (ICSE), 2002.

22. A. Zaremski and J. Wing. Signature matching : a tool for using software libraries.In ACM TOSEM 1995, 1995.

23. A. M. Zaremski and J. Wing. Specification matching of software components. InACM TOSEM 1997, 1997.