Pendant de nombreuses années, les besoins extrafonctionnels des applications ont été écrites textuel- lement en tant que partie intégrante des documents de spécification des besoins. Depuis, de nombreux langages ont été proposés pour permettre de modéliser et de décrire les besoins extrafonctionnels des applications tout en les séparant du code métier. Ils s’adressent initialement à une utilisation humaine et présentent notamment des atouts de compréhensibilité et de réutilisabilité supportés par des mécanismes d’héritage, de regroupement ou encore de nommage des spécifications.
Dans le domaine des intergiciels et des infrastructuresCORBA, les langages QIDL [Becker et Geihs 2000] etQDL (QoS Description Language en anglais) [Pal et al. 2000b] ont été proposés.QIDL défini dans le cadre bien précis du systèmeMAQS (Management for Adaptive QoS-enabled Services en an- glais) [Becker et Geihs 1997] et permet de spécifier des contraintes de QdS très simples en étendant les descriptions des interfaces, et d’affecter ces contraintes aux interfaces fonctionnelles.QDL est un autre langage défini dans le système QuO4 [Quality Objects (QuO) Project (Web Site)] qui permet d’expri-
mer différents aspects de QdS (contrats de QdS, description des objets et des délégués, configuration des applications). Une caractéristique particulière deQDL est qu’il permet, en plus de la déclaration de spécifications de qualité, de définir des règles d’adaptation qui sont définies en combinant les caracté- ristiques de qualité à certains éléments spécifiques de l’implémentation. Toutefois, malgré cette qualité, l’entrelacement des concepts de qualité avec certains détails de l’implémentation de la plate-forme rend le langage complexe et difficile à appréhender.
Un autre langage QoSCL (QoS Constraint Language en anglais) [Defour et al. 2004b] a été défini récemment pour définir des niveaux de qualité aux interfaces fournies et requises des composants. Le langage s’appuie sur les concepts de qualité, niveau de qualité et dépendances extrafonctionnelles. Les qualités sont contraintes pour définir les niveaux de qualité requis et fournis, et des relations explicites permettent d’exprimer des dépendances entre QdS requises et fournies d’un composant. A partir de ces relations de dépendances, il est alors possible de valider, en phase de déploiement et par un moteur de résolution, les niveaux de qualité des composants individuels, mais aussi ceux de plusieurs composants connectés, par propagation des relations de dépendances.
Dans le domaine des applications multimédias distribuées, le langage de spécificationsHQML [Gu et al.2001b] basé surXML a été proposé dans l’environnement QoSTalk [Gu et al. 2001a]. Ce langage reste très spécifique au domaine multimédia. Il reprend les éléments de base des autres langages mis à part le fait qu’il permette de spécifier des aspects extrafonctionnels plus étendus concernant les qualités des utilisateurs, de l’application et des ressources système. De plus, il autorise la définition de règles simples d’adaptation qui permettent de choisir de nouveaux profils de QdS, construits à partir de configurations d’applications possibles.
Le langageQML (QdS Modeling Language en anglais) [Frølund et Koistinen 1998a,c,b], développé au sein des laboratoires Hewlett-Packard, propose un langage de spécification de qualité plus général. Il est implémenté comme une extension de UML et organise la définition des spécifications de QdS selon trois abstractions principales : le type de contrat, le contrat et le profil. Le type de contrat permet de modéliser une catégorie de QdS et il est, pour cela, composé d’un ensemble de dimensions de QdS représentant chacune une propriété extrafonctionnelle définie par, son domaine de valeurs, son unité et le sens de variation souhaité. Les contraintes sont définies sur ces dimensions, et regroupées dans une instance de contrat. Les contrats de qualité correspondent à de simples déclarations de contraintes de qualité qui définissent un intervalle de valeurs valides.QML permet aussi de caractériser l’évolution
3.3. Langages de spécification
des dimensions par le biais de concepts mathématiques statistiques simples comme la moyenne ou la variance. Enfin, le profil permet d’associer les contrats aux interfaces ou aux opérations, et le type de contrat (requis ou offert) dépend directement de type de l’entité (client ou serveur) auquel le profile est associé.
Le listing3.1qui suit décrit un exemple de contract type définissant la catégorie extrafonctionnelle de nom Reliability, et composée des dimensions numberOfFailures, TTR et availability.
type R e l i a b i l i t y = c o n t r a c t { n u m b e r O f F a i l u r e s : d e c r e a s i n g numeric no / y e a r ; TTR : d e c r e a s i n g numeric s e c ; a v a i l a b i l i t y : i n c r e a s i n g numeric; } s y s t e m R e l i a b i l i t y = R e l i a b i l i t y c o n t r a c t{ n u m b e r O f F a i l u r e s < 10 no / y e a r ; TTR{ p e r c e n t i l e 100 < 2 0 0 0 ; mean < 5 0 0 ; v a r i a n c e < 0 . 3 } ; a v a i l a b i l i t y > 0 . 8 ; } r a t e S e r v e r P r o f i l e f o r R a t e S e r v i c e I = p r o f i l e{ r e q u i r e s y s t e m R e l i a b i l i t y from o p e r a t i o n N a m e r e q u i r e a n o t h e r C o n t r a c t I n s t a n c e ; }
Listing 3.1 – Exemple de type de contrat, de contrat et de profil enQML.
L’instance de contrat de nom systemReliability définit des contraintes sur les dimensions précé- dentes. Celles-ci sont liées aux interfaces et opérations par le biais du profil rateServerProfile dé- fini sur l’interface RateServiceI et sur l’opération operationName. En plus de ces mécanismes de spécification,QML définit aussi un système de représentation des spécifications à l’exécution QRR (QdS Representation Runtimeen anglais) [Frølund et Koistinen 1998c]. Ce système se charge de construire des représentations des spécifications pour qu’elles puissent être gérées à l’exécution. Des structures de don- nées sont ainsi construites pour représenter les propriétés extrafonctionnelles et leurs contraintes. Par cela, le système rend alors possible la vérification des spécifications à l’exécution en évaluant les struc- tures de données par le biais d’interfaces prédéfinies à implémenter. Contrairement àQuO, rien dans ce langage ne permet de définir des stratégies d’adaptations. De plus, les spécifications définies dans ce langage restent très peu liées au éléments sous-jacents de l’application.
CQML (Component Quality Modeling Language en anglais) est un autre langage de spécification pour QdS proposé par J.Ø. Aagedal [Aagedal 2001]. Ce langage permet de spécifier la QdS offerte et requise dans les systèmes à composants de façon plus générale et plus précise queQML. Pour cela, trois éléments de base sont définis (QoS characteristic, QoS statement, QoS profile) respectivement inspirés des abstractions type de contract, contrat et profil deQML. Dans CQML, la construction de base est la QoS characteristic, défini par un nom unique, un domaine de valeurs (numérique ou ensembliste), et un sens de variation souhaité (croissant ou décroissant). Comparé àQML, une différence majeure est que les spécifications extrafonctionnelles enCQML peuvent être paramétrées par des attributs de l’application dont les valeurs ne seront connues qu’à l’exécution. Les QoS statements représentent les contraintes sur les concepts de qualité – QoS characteristic – précédents, et les QoS profiles définissent la mise en correspondance des contraintes de niveaux de qualité aux composants. Un composant peut ainsi
Chapitre 3. Aspects extrafonctionnels
soit fournir, soit requérir un QoS statement donné. L’avantage deCQML est qu’il est plus adapté aux composants logiciels car il permet d’exprimer les offres et les besoins en qualité des composants, et cela, de façon plus riche, par paramétrisation des spécifications. Toutefois, commeQML, les spécifications extrafonctionnelles restent encore peu liées aux composants à l’exécution, et on ne sait pas très clairement comment celles-ci se projettent et se réalisent dans une plate-forme d’exécution. Enfin,CQML permet aussi d’inclure différents profils de QdS pour un composant et de définir des règles de transitions entre ceux-ci à opérer sur certains callbacks. Cela fourni ainsi un mécanisme d’adaptation par changement de profils de QdS.
Enfin, le langage de spécificationCQML+ [Röttger et Zschaler 2003] s’inscrit directement dans la ligné deCQML et a été établi dans le cadre du projet COMQUAD afin de mieux décrire le traitement des spécifications de QdS à l’étape d’exécution. Pour cela, un méta-modèle définit notamment des évé- nements (e.g appel d’une méthode), des queues d’événements (e.g liste des appels de méthodes d’un composant) ainsi que des ressources permettant de modéliser des ressources physiques comme le CPU ou la mémoire. Bien que ces travaux permettent d’enrichirCQML et d’exprimer plus finement des spéci- fications extrafonctionnelles, la sémantique n’est toujours pas précise et est à déterminer par le système sous-jacent. Par ailleurs, au lieu de spécifier des domaines de valeurs déterminées statiquement, une clause QdS_dependencies est aussi définie pour expliciter par des équations la relation entre une QdS fournie et une QdS requise au niveau d’un même composant [Zschaler et Meyerhöfer 2003]. Ces équa- tions sont des formules exactes ou des formules intégrant des intervalles dont les bornes sont soit fixes ou soit définies par des fonctions. Toutefois, cette dépendance exprime un lien entre la QdS requise de celle fournie sur un même composant mais on ne dispose pas des contributions de plusieurs composants sur une même propriété de qualité.