Une approche agile, fiable et minimale pour le maintien de la qualité de service lors de l'évolution d'applications à base de processus métiers - Thèse Informatique
Une approche agile, fiable et minimale pour le maintien de la qualité de service lors de l'évolution d'applications à base de processus métiers - thèse Informatique
- Revenir à l'accueil
Une approche agile, fiable et minimale pour le maintien
de la qualit´e de service lors de l’´evolution d’applications
`a base de processus m´etiers
Alexandre Feugas
To cite this version:
Alexandre Feugas. Une approche agile, fiable et minimale pour le maintien de la qualit´e de
service lors de l’´evolution d’applications `a base de processus m´etiers. Software Engineering.
Universit´e des Sciences et Technologie de Lille - Lille I, 2014. French.
HAL Id: tel-01073193
https://tel.archives-ouvertes.fr/tel-01073193
Submitted on 9 Oct 2014
HAL is a multi-disciplinary open access
archive for the deposit and dissemination of scientific
research documents, whether they are published
or not. The documents may come from
teaching and research institutions in France or
abroad, or from public or private research centers.
L’archive ouverte pluridisciplinaire HAL, est
destin´ee au d´epˆot et `a la diffusion de documents
scientifiques de niveau recherche, publi´es ou non,
´emanant des ´etablissements d’enseignement et de
recherche fran¸cais ou ´etrangers, des laboratoires
publics ou priv´es.Universit´e Lille 1 Sciences et Technologies
D´epartement de formation doctorale en informatique Ecole doctorale SPI Lille ´
UFR IEEA
Une Approche Agile, Fiable et
Minimale pour le Maintien de la
Qualit´e de Service lors de l’Evolution
´
d’Applications `a Base de Processus
M´etiers
THESE `
pr´esent´ee et soutenue publiquement le 8 octobre 2014
pour l’obtention du
Doctorat de l’Universit´e Lille 1 Sciences et Technologies
Sp´ecialit´e Informatique
par
Alexandre Feugas
Composition du jury
Rapporteurs : Marie-Pierre Gervais, Universit´e Paris Ouest Nanterre La D´efense
Jean-Michel Bruel, Universit´e de Toulouse
Directeur de th`ese : Laurence Duchien, Universit´e Lille 1
Examinateurs : Jean-Luc Dekeyser, Universit´e Lille 1
S´ebastien Mosser, Universit´e Nice - Sophia Antipolis
Laboratoire d’Informatique Fondamentale de Lille — UMR CNRS 8022
INRIA Lille - Nord EuropeUne Approche Agile, Fiable et Minimale pour le Maintien de la Qualité de
Service lors de l’Évolution d’Applications à Base de Processus Métiers
Les logiciels actuels adoptent une méthodologie de développement dite "agile" pour
mieux prendre en compte la nécessité de s’adapter constamment aux nouveaux besoins des
utilisateurs. Les concepteurs et développeurs se rapprochent alors des futurs utilisateurs
du logiciel en proposant des cycles courts d’itération, où le futur utilisateur fait un retour
rapide sur l’incrément apporté au logiciel, et fait part de nouveaux besoins à prendre en
compte dans les incréments à venir. Ces itérations peuvent être vues comme des évolutions,
faisant suite à la définition d’un nouveau besoin de l’utilisateur, à un changement de l’environnement
d’exécution, ou encore à une remise en question de l’architecture du logiciel.
Dans l’écosystème des architectures orientées services, la conception d’applications passe
par la chorégraphie ou l’orchestration de services par des processus métiers. Concevoir ces
applications consiste alors à mettre en relation les flots de contrôle et de données de ces
services. La phase d’évolution devient une phase complexe, où une simple modification localisée
à une sous-partie d’un processus métier peut avoir des conséquences sur l’ensemble
du système logiciel, causant par exemple son ralentissement lors de l’exécution. Du point
de vue de la qualité de service (QoS), la maîtrise de la fiabilité du processus d’évolution
pour maintenir la qualité de service d’un logiciel est alors critique.
Il est donc nécessaire de pouvoir proposer des mécanismes d’évolution agiles et fiables
permettant le maintien de la QoS lors de l’évolution d’applications à base de processus
métiers. En d’autres termes, il s’agit de s’assurer qu’une évolution ne viole pas les contrats
de QoS définis initialement. Cette garantie doit être établie en fonction du contrat soit lors
de la conception soit lors de l’exécution. Dans ce dernier cas, le processus de vérification
doit être minimal et localisé, afin de ne pas dégrader les performances du système logiciel.
Pour cela, nous proposons de mettre en œuvre un cycle de développement agile, centré
sur le maintien de la QoS lors de l’évolution. Il s’agit de prendre l’aspect évolutif du système,
ceci dès l’étape de conception initiale, en identifiant les informations requises pour déterminer
si la QoS est correcte et si elle est non violée par une évolution. Ces informations
étant détenues par plusieurs intervenants, il est également nécessaire d’établir les points
d’interaction au cours du cycle de développement, au cours desquels les informations seront
partagées de façon à ce que le logiciel qui en est issu reste syntaxiquement et sémantiquement
cohérent et que les contrats de QoS soient (re)vérifiés a minima. Les contributions de
cette thèse sont donc mises en œuvre dans Blink, un cycle de développement pour l’évolution,
et Smile, un canevas de développement pour le maintien de la qualité de service lors de
l’évolution d’applications orientées service définies à base de processus métiers. Tandis que
le cycle de développement Blink vise à identifier les différents rôles présents dans l’équipe
de développement et à expliciter leurs interactions, le canevas Smile propose la réalisation
d’une boucle d’évolution. Cette boucle permet de concevoir, d’analyser et d’appliquer une
évolution, en détectant les potentielles violations de contrat de QoS. Pour cela, l’analyse
de l’évolution détermine son effet sur la QoS du logiciel, en établissant des relations de
causalité entre les différentes variables, opérations, services et autres parties du système.
Ainsi, en identifiant les éléments causalement affectés par l’évolution et en écartant ceux
qui ne le sont pas, notre approche permet de limiter le nombre d’éléments à (re)vérifier,
garantissant ainsi une étape d’évolution fiable, avec une étape de (re)vérification minimale.
Nous montrons sur un cas concret de système de gestion de crises, constitué de onze
processus métiers et de dix scénarios, que l’utilisation conjointe de Blink et de Smile
permet d’identifier, pour chaque évolution, quel sera son effet sur le reste du système, et si
la qualité de service sera maintenue ou non.An Agile, Reliable and Minimalist Approach to Preserve the QoS of
Business-Processes Based Applications during their Evolutions
Current softwares are built using "agile" development methods, to better consider the need
to adapt to new user requirements. Developers and designers are getting closer to future
software users by making short iterative cycles, where the future user gives a fast feedback
on the increment made to the software and emits new user requirement to be fulfilled in
future increments. These iterations can be seen as evolutions, as an answer to the definition
of a new user requirement, or due to a change in the execution environment or in the
architecture of the software. In the Service-Oriented Architecture (SOA) world, the design
of software is composed of service choreography, or service orchestration using business
processes. The design of these applications is equivalent to connecting the services control
flow and data flow. As a result, the evolution step becomes a complex step, where a simple
modification on a sub-part of a business process can have consequences on the entire system,
causing for example its slowing down at runtime. From the Quality of Service (QoS) point
of view, ensuring the fiability of the evolution process to maintain software QoS is critical.
As a result, it is necessary to propose agile, reliable evolution mecanisms ensuring QoS
preservation during the evolution of software made of business processes. In other words,
we need to control that an evolution does not violate any QoS contract initially set up.
Depending of the contract, this garanty must be established either at design time or at
runtime. In the latter case, the verification process must be minimal and local, in order to
not degrade the software performance.
To achieve this goal, we propose to realise an agile development cycle, centered on the
QoS preservation during the evolution. It is necessary to care about the evolutive concern
of a system from the initial design step, by identifying required information to determine
if the QoS continues to be correct and not violated by an evolution. Considering that this
information is known by many stakeholders, it is also necessary to set up interaction points
during the development cycle, during which information is shared in order to keep building a
syntactically and semantically coherent software and to minimally (re)check QoS contracts.
The contributions of this thesis are applied in Blink, a development cycle for evolution,
and Smile, a framework to maintain QoS during the evolution of a service-oriented software
made of business processes. While Blink is intended to identify the different actors and to
make their interactions explicit, Smile proposes the realisation of an evolution loop. This
loop enables the design, analysis and application of an evolution, by detecting the potential
QoS contract violation. The evolution analysis determines its effect on the software QoS,
by defining causal relations among variables, operations, services and other parts of the
system. In this way, by identifying elements that are causally affected by the evolution, and
by avoiding the elements that are not, our approach enables the limitation of the number of
elements to (re)check in order to assure a reliable evolution step, with a minimal (re)check
step.
We show on the concrete case of a crisis management system, composed of eleven business
processes and ten scenarios, that the combined use of Blink and Smile enables for
each evolution the identification of its effect on the system, and the QoS preservation of the
system.Remerciements
La thèse est une aventure, une expérience humaine qui vous marque profondément tant
elle change vos habitudes,votre façon de penser. J’ai vécu au cours de ces quatre dernières
années quelque chose de beau, d’intense, de douloureux et de décourageant aussi. Mais
c’est avant tout l’ensemble des rencontres faites durant ce laps de temps qui ont fait de
cette thèse un moment fort à mes yeux. Dans cette page, je n’aurai pas la prétention d’être
exhaustif, j’oublierai sûrement quelques personnes qui, je l’espère, ne m’en voudront pas.
Mais sachez juste que, qui que vous soyez, que je vous ai croisé de près ou de loin, merci à
vous d’avoir joué un rôle dans mon aventure doctorante.
Je voudrais remercier en premier lieu mes encadrants, Laurence et Seb, qui ont dû avoir
quelques cheveux blancs à cause de moi. Merci de vous être impliqué dans ces travaux,
d’avoir su garder patience avec moi. J’espère que vous ne m’en voulez pas trop de vous
avoir mené la vie dure. A titre postume, j’ai également une pensée profonde pour AnneFrançoise,
qui a su croire en moi ; qui m’a encouragé et qui a été derrière moi à mes débuts.
Merci à toi. J’aurais aimé que tu sois présente, auprès de nous.
Plus généralement, je voudrais remercier l’équipe Adam/Spirals, qui a été ma deuxième
famille. Merci aux permanents, avec leurs remarques, leurs discussions passionnantes, ou
leurs reculs. Merci enfin aux doctorants et ingénieurs de l’équipe, qui ont partagé avec moi
le stress des différentes présentations et autres deadlines d’articles. On ne le dit jamais
assez, une thèse, c’est pas une sinécure... Et puis merci à tous les collègues embarqués dans
la même galère : bravo, merci et courage au 4 autres compagnons ayant démarré cette folle
aventure avec moi : Adel, Nico, Rémi et Rémi. Bonne continuation à vous, en espérant que
vous garderez le même souvenir d’Inria que moi.
Un clin d’œil pour Clément, frère de thèse, qui a su m’accueillir à Lille malgré son accent
sudiste, qui m’a fait découvrir de nombreux endroits sympathiques. J’ai beaucoup apprécié
nos longues conversations, autant scientifiques que footballistiques. J’espère que tu mèneras
une longue et brillante carrière académique, en démarrant par Milan. Obrigado également
à Antonio, mon frère de bière, compagnon de nuit et de braderie, qui m’a fait découvrir sa
culture, son pays, et bien plus encore. J’ai été heureux de faire ta connaissance, en espérant
te re-croiser un jour, ou dans une vie future. Je ne pourrai pas écrire ces remerciements sans
penser à mes camarades de l’association des doctorants, Tilda. Tout particulièrement, je
voudrais saluer Fabien et sa bonne humeur, avec qui j’ai eu le plaisir de travailler. Enfin, un
immense merci à Julie, voisine de thèse, compagnon de pause café et motivatrice intarissable.
Merci de m’avoir épaulé autant dans ma thèse que dans ma vie perso.
Enfin, merci à ma famille, qui m’a soutenu tout au long de ces quatre dernières années,
dans les bons et les mauvais moments. Merci d’avoir été auprès de moi, d’avoir cru en moi,
lorsque moi-même je n’y croyais plus. Encore une fois, merci à vous. Merci également à
tous mes amis sudistes, qui ont sû rester en contact avec moi, malgré la grande distance
séparant mon sud natal de cette terre d’accueil qu’a été le Nord. Je ne citerai personne
de peur d’oublier quelqu’un, exception faite bien sûr de Laetitia, qui a été mon accroche
immuable tout au long du doctorat. Tu as su rester auprès de moi malgré la distance, l’eau
qui coulait sur les ponts, et nos chemins qui tendaient à bifurquer. Tu as été présente au
bout du téléphone lorsque j’allais bien, lorsque j’allais mal, quand j’avais envie de parler
politique, ou simplement de la pluie et du beau temps pour oublier les difficultés de la
journée passée. Plus encore, c’est sans nul doute grâce à toi si aujourd’hui, je suis docteur...
(le 13ème ?) C’est toi qui, au moment où j’avais envie de baisser les bras, là où je ne voyais
plus aucun espoir ni réconfort, a réussi non seulement à me donner la force de terminer
ma thèse, mais qui m’a en plus redonné l’envie de sourire, et qui m’a donné un but en
m’attendant patiemment dans notre nouvelle contrée toulousaine. Merci, merci infiniment.
iiiTable des matières
Table des matières
1 Introduction 1
1.1 Problématique . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.2 Défis pour maintenir la qualité de service lors de l’évolution . . . . . . . . . 2
1.3 Proposition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.4 Organisation du document . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.5 Liste des publications liées à cette thèse . . . . . . . . . . . . . . . . . . . . 5
I Contexte et Motivations 7
2 Contexte 9
2.1 Les architectures orientées services . . . . . . . . . . . . . . . . . . . . . . . 9
2.1.1 Définitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
2.1.2 Organisation des architectures orientées services . . . . . . . . . . . 10
2.2 La Qualité de Service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
2.2.1 Qualité du logiciel . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
2.2.2 Méthodes de détermination de la qualité de service . . . . . . . . . . 14
2.2.3 Contrats de Qualité de Service . . . . . . . . . . . . . . . . . . . . . 17
2.3 Évolution des systèmes logiciels . . . . . . . . . . . . . . . . . . . . . . . . . 17
2.3.1 Définition de l’évolution . . . . . . . . . . . . . . . . . . . . . . . . . 17
2.3.2 Caractéristiques d’une évolution . . . . . . . . . . . . . . . . . . . . 18
2.4 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
3 État de l’art 25
3.1 Processus de développement . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
3.1.1 Les processus de développement généralistes . . . . . . . . . . . . . . 26
3.1.2 Les processus de développement spécialisés SOA . . . . . . . . . . . 27
3.1.3 Prise en compte de la Qualité de Service . . . . . . . . . . . . . . . . 28
3.1.4 Prise en compte de l’évolution . . . . . . . . . . . . . . . . . . . . . 28
3.1.5 Comparatif et limitations . . . . . . . . . . . . . . . . . . . . . . . . 29
3.2 Analyse d’impact . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
3.2.1 Fondements de la causalité . . . . . . . . . . . . . . . . . . . . . . . 29
3.2.2 Application de la causalité : les analyses d’impact . . . . . . . . . . 30
3.2.3 Analyse d’impact pour la qualité de service . . . . . . . . . . . . . . 32
3.2.4 Comparatif et limitations . . . . . . . . . . . . . . . . . . . . . . . . 32
3.3 Conclusion de l’état de l’art . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
4 Présentation du cas d’étude 37
4.1 Séduite, un système de diffusion d’informations à base de processus métiers 37
4.2 PicWeb, un processus métier de recherche d’images . . . . . . . . . . . . . 39
4.2.1 Description de PicWeb . . . . . . . . . . . . . . . . . . . . . . . . . 39
4.2.2 Évolution de PicWeb . . . . . . . . . . . . . . . . . . . . . . . . . . 40Table des matières
II Contributions 41
5 Un processus de développement pour le maintien de la qualité de service 43
5.1 Motivations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
5.2 Définition des acteurs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
5.3 Description du processus de développement . . . . . . . . . . . . . . . . . . 44
5.4 Coopération entre acteurs . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
5.5 Conclusion du chapitre . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
6 Modélisation d’un système à base de processus métiers 51
6.1 Défis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
6.2 Modélisation du système . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
6.2.1 Univers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
6.2.2 Variables et types . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
6.2.3 Messages et Opérations . . . . . . . . . . . . . . . . . . . . . . . . . 53
6.2.4 Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
6.2.5 Activités . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
6.2.6 Relations d’ordre . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
6.2.7 Processus métier . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
6.2.8 Système . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
6.3 Causalité de l’exécution d’un système . . . . . . . . . . . . . . . . . . . . . 58
6.3.1 Mise en œuvre de la causalité . . . . . . . . . . . . . . . . . . . . . . 59
6.3.2 Relations causales fonctionnelles . . . . . . . . . . . . . . . . . . . . 59
6.3.3 Exemple . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
6.4 Déduction des relations causales d’un système . . . . . . . . . . . . . . . . . 61
6.4.1 Méthodologie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
6.4.2 Expression des règles causales . . . . . . . . . . . . . . . . . . . . . . 62
6.5 Conclusion du chapitre . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
7 Modélisation de la qualité de service pour l’évolution 65
7.1 Motivations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
7.2 Modélisation de la qualité de service d’un système . . . . . . . . . . . . . . 66
7.2.1 Propriété, unité et critère de comparaison . . . . . . . . . . . . . . . 67
7.2.2 Domaine d’application . . . . . . . . . . . . . . . . . . . . . . . . . . 67
7.2.3 Valeur de propriété . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68
7.2.4 Influence et ressource . . . . . . . . . . . . . . . . . . . . . . . . . . 68
7.2.5 Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
7.3 Définition des relations causales de propriété . . . . . . . . . . . . . . . . . 69
7.3.1 Relations d’environnement . . . . . . . . . . . . . . . . . . . . . . . . 71
7.3.2 Relations de dérivation de propriétés . . . . . . . . . . . . . . . . . . 71
7.3.3 Relations d’agrégation de valeurs . . . . . . . . . . . . . . . . . . . . 73
7.3.4 Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74
7.4 QoS4Evol, un langage de description de la qualité de service . . . . . . . . . 74
7.4.1 Présentation de QoS4Evol . . . . . . . . . . . . . . . . . . . . . . . . 75
7.4.2 Définition du langage . . . . . . . . . . . . . . . . . . . . . . . . . . 75
7.4.3 Caractéristiques du langage . . . . . . . . . . . . . . . . . . . . . . . 76
7.5 Déduction des règles causales d’une propriété . . . . . . . . . . . . . . . . . 77
7.5.1 Principe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77
7.5.2 Obtention des relations causales d’environnement . . . . . . . . . . . 78
7.5.3 Obtention des relations causales de dérivation . . . . . . . . . . . . . 79
viTable des matières
7.5.4 Obtention des relations causales d’agrégation . . . . . . . . . . . . . 79
7.5.5 Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80
7.6 Conclusion du chapitre . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81
8 Analyse de l’évolution du logiciel orientée QoS 83
8.1 Présentation générale du processus d’évolution . . . . . . . . . . . . . . . . 84
8.1.1 Enjeux . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84
8.1.2 Spécification du processus d’évolution . . . . . . . . . . . . . . . . . 84
8.1.3 Hypothèses . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85
8.2 Un langage pour l’évolution des processus métier . . . . . . . . . . . . . . . 86
8.3 Spécification de l’analyse de l’évolution . . . . . . . . . . . . . . . . . . . . . 87
8.3.1 Aperçu des différentes étapes . . . . . . . . . . . . . . . . . . . . . . 88
8.3.2 Étape 1 : mise à jour du modèle causal . . . . . . . . . . . . . . . . . 89
8.3.3 Étape 2 : analyse causale . . . . . . . . . . . . . . . . . . . . . . . . 92
8.3.4 Étape 3 : re-vérification . . . . . . . . . . . . . . . . . . . . . . . . . 93
8.3.5 Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96
8.4 Résultat de l’analyse et prise de décision . . . . . . . . . . . . . . . . . . . . 96
8.4.1 Enjeux . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97
8.4.2 Vérification des contrats . . . . . . . . . . . . . . . . . . . . . . . . . 97
8.4.3 Détermination des causes racines . . . . . . . . . . . . . . . . . . . . 98
8.4.4 Déploiement et retour en arrière (roll-back) . . . . . . . . . . . . . . 99
8.4.5 Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99
8.5 Conclusion du chapitre . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101
III Validation 103
9 Mise en œuvre et utilisation de Smile 105
9.1 Réalisation de Smile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105
9.1.1 Présentation du canevas . . . . . . . . . . . . . . . . . . . . . . . . . 106
9.1.2 Besoins des utilisateurs de Smile . . . . . . . . . . . . . . . . . . . . 106
9.1.3 Architecture de Smile . . . . . . . . . . . . . . . . . . . . . . . . . . 106
9.2 Smile pour la description du système . . . . . . . . . . . . . . . . . . . . . 109
9.2.1 Import de système . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109
9.2.2 Description des règles causales . . . . . . . . . . . . . . . . . . . . . 111
9.3 Smile pour la qualité de service . . . . . . . . . . . . . . . . . . . . . . . . 113
9.3.1 Principe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113
9.3.2 Description d’une propriété . . . . . . . . . . . . . . . . . . . . . . . 113
9.3.3 Gestion des règles causales de propriété . . . . . . . . . . . . . . . . 114
9.3.4 Collecte des données . . . . . . . . . . . . . . . . . . . . . . . . . . . 115
9.3.5 Description d’un contrat . . . . . . . . . . . . . . . . . . . . . . . . . 116
9.4 Smile pour l’évolution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117
9.4.1 Description d’une évolution . . . . . . . . . . . . . . . . . . . . . . . 117
9.4.2 Analyse causale de l’évolution . . . . . . . . . . . . . . . . . . . . . . 118
9.4.3 Contrôle à l’exécution . . . . . . . . . . . . . . . . . . . . . . . . . . 119
9.5 Limites . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119
9.6 Conclusion du chapitre . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 120
viiTable des matières
10 Evaluation 121
10.1 Défis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122
10.2 Cas d’étude : le Système de gestion de crises . . . . . . . . . . . . . . . . . . 122
10.2.1 Contexte du cas d’étude . . . . . . . . . . . . . . . . . . . . . . . . . 122
10.2.2 Description du scénario . . . . . . . . . . . . . . . . . . . . . . . . . 123
10.2.3 Cas d’utilisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 124
10.3 Implémentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 127
10.4 Évolutions du scénario . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 128
10.4.1 Évolutions pour la construction du système . . . . . . . . . . . . . . 128
10.4.2 Évolutions du processus Gestion de la Mission . . . . . . . . . . . . 129
10.5 Évaluation quantitative des contributions . . . . . . . . . . . . . . . . . . . 132
10.5.1 Comparaison des éléments à re-vérifier . . . . . . . . . . . . . . . . . 132
10.6 Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 135
10.7 Conclusion du chapitre . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 135
IV Conclusion 137
11 Conclusion et Travaux Futurs 139
11.1 Résumé des contributions . . . . . . . . . . . . . . . . . . . . . . . . . . . . 139
11.2 Perspectives à court terme . . . . . . . . . . . . . . . . . . . . . . . . . . . . 140
11.3 Perspectives à long terme . . . . . . . . . . . . . . . . . . . . . . . . . . . . 141
Bibliographie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 145
viiiTable des figures
Table des figures
2.1 Exemple de détermination par dérivation. . . . . . . . . . . . . . . . . . . . 16
2.2 Exemple de détermination par agrégation. . . . . . . . . . . . . . . . . . . . 16
4.1 Utilisation de Séduite au cours de la nuit de l’info. . . . . . . . . . . . . . . 38
4.2 Architecture de Séduite. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
4.3 Évolutions de PicWeb. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
5.1 Schéma du processus de développement Blink. . . . . . . . . . . . . . . . . 46
6.1 Extrait du méta-modèle de Smile : variables et types. . . . . . . . . . . . . 53
6.2 modélisation du service Helper. . . . . . . . . . . . . . . . . . . . . . . . . . 54
6.3 Extrait du méta-modèle de Smile : services, opérations et messages. . . . . 55
6.4 Extrait du méta-modèle de Smile : activités. . . . . . . . . . . . . . . . . . 55
6.5 Extrait du modèle de PicWeb : activité receive. . . . . . . . . . . . . . . . 55
6.6 Extrait du modèle de PicWeb : relations d’ordre. . . . . . . . . . . . . . . 57
6.7 Extrait du méta-modèle : relations d’ordre. . . . . . . . . . . . . . . . . . . 57
6.8 Extrait du méta-modèle : processus métier. . . . . . . . . . . . . . . . . . . 58
6.9 Modèle causal fonctionnel de PicWeb. . . . . . . . . . . . . . . . . . . . . . 60
6.10 Procédé de déduction des relations causales. . . . . . . . . . . . . . . . . . . 62
7.1 Modèle et méta-modèle d’une propriété. . . . . . . . . . . . . . . . . . . . . 67
7.2 Modèle et méta-modèle du domaine d’application. . . . . . . . . . . . . . . 68
7.3 Méta-Modèle de propriété : Valeurs de propriété. . . . . . . . . . . . . . . . 69
7.4 Modèle du temps de réponse : Valeurs de propriété. . . . . . . . . . . . . . . 70
7.5 Modèle et méta-modèle des facteurs d’influence. . . . . . . . . . . . . . . . . 71
7.6 Modèle causal enrichi avec les relations d’environnement. . . . . . . . . . . 72
7.7 Modèle causal enrichi avec les relations de dérivation. . . . . . . . . . . . . 72
7.8 Modèle causal enrichi avec les relations d’agrégation. . . . . . . . . . . . . . 73
7.9 Définition du Temps de Réponse. . . . . . . . . . . . . . . . . . . . . . . . . 75
7.10 Chaîne de déduction des relations causales de propriété. . . . . . . . . . . . 78
8.1 Processus d’évolution. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85
8.2 Évolution de PicWeb. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88
8.3 Étapes de l’analyse de l’évolution. . . . . . . . . . . . . . . . . . . . . . . . 88
8.4 Traduction de l’évolution en actions sur le modèle causal. . . . . . . . . . . 90
8.5 Application à PicWeb de l’analyse causale. . . . . . . . . . . . . . . . . . . 93
8.6 Application à PicWeb de l’analyse causale. . . . . . . . . . . . . . . . . . . 94
8.7 Obtention des données brutes. . . . . . . . . . . . . . . . . . . . . . . . . . . 95
8.8 Contrat de QoS qualifiant le temps de réponse de PicWeb. . . . . . . . . . 98
8.9 Détermination des causes racines de la violation du contrat de PicWeb. . . 100
9.1 Diagramme des cas d’utilisation de Smile. . . . . . . . . . . . . . . . . . . . 107
9.2 Architecture de Smile. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108
9.3 Procédé dirigé par les modèles de l’approche Smile. . . . . . . . . . . . . . 109
9.4 Import de PicWeb. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110
9.5 Extrait de fichier composite. . . . . . . . . . . . . . . . . . . . . . . . . . . . 111Table des figures
9.6 Méta-modèle du modèle causal. . . . . . . . . . . . . . . . . . . . . . . . . . 112
9.7 Extrait d’une règle causale écrite en ATL. . . . . . . . . . . . . . . . . . . . 112
9.8 Processus de la partie QoS de Smile. . . . . . . . . . . . . . . . . . . . . . . 114
9.9 Chaîne d’outillage pour la description d’une propriété. . . . . . . . . . . . . 115
9.10 Méta-Modèle de traces de Smile. . . . . . . . . . . . . . . . . . . . . . . . . 115
9.11 Modélisation des contrat de qualité de service. . . . . . . . . . . . . . . . . 116
9.12 Méta-Modèle d’évolution de Smile. . . . . . . . . . . . . . . . . . . . . . . . 117
9.13 Utilisation de l’éditeur d’évolutions de Smile. . . . . . . . . . . . . . . . . . 118
10.1 Description des différents rôles opérationnels. . . . . . . . . . . . . . . . . . 123
10.2 Description des différents rôles d’observation. . . . . . . . . . . . . . . . . . 124
10.3 Description des différents rôles stratégiques. . . . . . . . . . . . . . . . . . . 124
10.4 Architecture du système de gestion de crises. . . . . . . . . . . . . . . . . . 127
10.5 Graphe de dépendance des processus métiers du système de gestion de crises. 127
10.6 Évolution de la taille du modèle causal au cours de la construction du système.128
10.7 Processus métier du cas d’utilisation "Exécution de la mission". . . . . . . . 129
10.8 Évolution du processus métier Gestion de la mission : UnavailableIntRes. . 130
10.9 Évolution du processus métier Gestion de la mission : UnavailableExtRes. . 131
10.10Évolution du processus métier Gestion de la mission : RehandleOnChange. 132
10.11Extrait du modèle causal du processus métier Gestion de la mission après
l’évolution RehandleOnChange. . . . . . . . . . . . . . . . . . . . . . . . . . 133
xListe des tableaux
Liste des tableaux
2.1 Taxonomie d’une évolution : la dimension "Où". . . . . . . . . . . . . . . . 19
2.2 Taxonomie d’une évolution : la dimension "Quoi". . . . . . . . . . . . . . . 20
2.3 Taxonomie d’une évolution : la dimension "Quand". . . . . . . . . . . . . . 21
2.4 Taxonomie d’une évolution : la dimension "Comment". . . . . . . . . . . . . 22
2.5 Récapitulatif des hypothèses de travail. . . . . . . . . . . . . . . . . . . . . . 23
3.1 Comparatif des différents processus de développement. . . . . . . . . . . . . 29
3.2 Comparatif des différentes analyses d’impact. . . . . . . . . . . . . . . . . . 35
5.1 Rôles intervenants dans la réalisation d’un système. . . . . . . . . . . . . . . 45
5.2 Description des étapes 0 à 2 du processus de développement (Blink). . . . 47
5.3 Description des étapes 3 à 5 du processus de développement (Blink). . . . 48
5.4 Description de l’étape 6 du processus de développement (Blink). . . . . . . 49
6.1 Règle causale pour les relations causales de paramètre d’entrée. . . . . . . . 62
6.2 Règle causale pour les relations causales de paramètre de sortie. . . . . . . . 63
7.1 Formules d’agrégation du temps de réponse. . . . . . . . . . . . . . . . . . . 76
7.2 Règle de production des relations causales d’environnement. . . . . . . . . . 78
7.3 Règle causale d’environnement générée. . . . . . . . . . . . . . . . . . . . . 78
7.4 Règle de production des relations causales de dérivation. . . . . . . . . . . . 79
7.5 Règle causale de dérivation générée. . . . . . . . . . . . . . . . . . . . . . . 79
7.6 Règle de production des relations causales d’agrégation. . . . . . . . . . . . 80
7.7 Règle causale d’agrégation générée. . . . . . . . . . . . . . . . . . . . . . . . 80
8.1 Liste des opérations d’évolution. . . . . . . . . . . . . . . . . . . . . . . . . 86
8.2 Correspondance entre opérations d’évolution et actions du modèle causal. . 90
8.3 Génération de la mise à jour du modèle causal de PicWeb. . . . . . . . . . 91
8.4 Description de l’opération collecte. . . . . . . . . . . . . . . . . . . . . . . . 92
9.1 Description des fonctionnalités par module. . . . . . . . . . . . . . . . . . . 108
10.1 Nombre de valeurs de propriété à re-vérifier pour chaque méthode d’analyse. 134Chapitre 1
Introduction
Sommaire
1.1 Problématique . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.2 Défis pour maintenir la qualité de service lors de l’évolution . . 2
1.3 Proposition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.4 Organisation du document . . . . . . . . . . . . . . . . . . . . . . . 4
1.5 Liste des publications liées à cette thèse . . . . . . . . . . . . . . . 5
L
’informatique prend aujourd’hui une place de plus en plus grande dans le quotidien des
personnes, et dans le quotidien des entreprises. L’outil numérique développé au cours
du dernier siècle est aujourd’hui omniprésent dans la société. Cela se traduit par l’existence
de nombreux systèmes logiciels, allant du simple jeu sur un téléphone portable au moteur de
recherche utilisé massivement. Ces systèmes, qui autrefois étaient monolithiques et centralisés,
sont devenus avec l’apogée de l’Internet et l’augmentation de la taille des organisations
des entreprises des systèmes distribués, de taille conséquente, et à la complexité croissante.
Les architectures orientées services (SOA) constituent une solution permettant de maî-
triser cette complexité. La conception d’applications se matérialise par le biais de la chorégraphie
ou de l’orchestration de services à l’aide de processus métiers, offrant ainsi un
mécanisme de composition permettant de gagner en abstraction et de réduire la complexité.
En ce sens, concevoir une application reposant sur les principes des architectures orientées
services consiste à mettre en relation les flots de contrôle et de données de ces services.
Au delà de la nécessité de produire des systèmes correspondant aux besoins des utilisateurs,
la qualité de service (QoS), définie par Crnkovic et al. comme "une caractérisation
de tout ou d’une partie du système, selon une préoccupation particulière" [Crnkovic 2005],
constitue une préoccupation à gérer au cours du développement de logiciels. L’analyse et le
maintien de la QoS d’un système sont des opérations critiques, car la QoS sert de base à
l’établissement de contrats de service entre fournisseurs et utilisateurs, et un non-maintien
de la QoS entrainerait une rupture de contrat. De par la composition des services, la dé-
termination de la QoS d’une orchestration s’effectue par calcul, dépendant ainsi de la QoS
des services la constituant. C’est ce que l’on appelle l’agrégation [Cardoso 2004].
Les logiciels que nous considérons ici, dont la taille et la complexité échappent à la
compréhension d’une seule personne, sont amenés à être modifiés tout au long de leur cycle
de vie. Les modifications opérées, que l’on appelle dans ce document évolutions, sont la
conséquence/réaction d’un changement de besoins de la part des utilisateurs, d’un changement
survenu dans l’environnement d’exécution ou encore dans l’architecture du système.
Ces évolutions, de par la modification du comportement du système qu’elles entraînent,
impliquent de s’assurer que la QoS n’a pas été détériorée. Ainsi, lors de chaque évolution,
les changements effectués sur le logiciel impliquent de re-vérifier la QoS de l’ensemble du
système.1.1. Problématique
1.1 Problématique
Dans un contexte où les attentes en termes de fonctionnalités et de qualités du logiciel
sont fortes, faire évoluer ce dernier est un processus critique, tant par l’effet que l’évolution
peut avoir que par la nécessité d’un processus court permettant d’être réactif à l’égard des
utilisateurs. Il est parfois même nécessaire d’appliquer l’évolution au cours même de leur
exécution. Dans ce cas, il est vital d’établir un processus d’évolution court et minimal, pour
ne pas parasiter ou ralentir son fonctionnement. Il s’agit ici d’un problème complexe, où
la nécessité d’effectuer une évolution maintenant les propriétés de QoS implique une collaboration
proche entre les différentes expertises de l’équipe de développement, notamment
entre l’expertise de la QoS et celle de l’évolution. Le processus d’évolution nécessite d’être
court dans sa réalisation, tout en s’assurant du maintien de la QoS du logiciel. L’objectif est
donc ici de minimiser la re-vérification des propriétés de QoS, en déterminant de manière
précise quelles parties du logiciel ont été réellement affectées par l’évolution.
Dans le cadre de cette thèse, nous nous intéressons tout particulièrement aux systèmes
reposant sur une architecture orientée services, pour lesquels le comportement est représenté
à l’aide de processus métiers. Les mécanismes d’évolution à définir doivent permettre d’établir
l’effet d’une évolution sur le reste du système, afin d’éviter un ensemble de dépendances
cachées entre les éléments. De plus, le processus d’évolution devra garantir le maintien des
contrats de qualité de service. Il s’agit donc non seulement de comprendre l’effet d’une évolution
sur le reste du système, mais également sur les différentes propriétés de QoS ayant
un intérêt pour l’équipe de développement ou pour la communauté d’utilisateurs. Enfin,
ces mécanismes d’évolution devront prendre en compte la répartition des compétences et
des expertises de l’équipe de développement, en définissant les différents rôles nécessaires à
un processus d’évolution fiable en termes de QoS, et en identifiant les points d’interaction
entre ces différents rôles pour partager leurs expertises propres.
1.2 Défis pour maintenir la qualité de service lors de
l’évolution
L’objectif de cette thèse est de fournir à l’équipe de développement et de maintenance les
outils permettant de s’assurer que la qualité de service est maintenue au cours des différentes
évolutions du logiciel, tout au long de son cycle de vie. Le maintien de la QoS lors d’une
évolution est une tâche complexe, nécessitant la collaboration de différentes expertises telles
que l’expertise du métier, de l’environnement d’exécution, ou encore de la propriété de QoS
considérée.
De plus, le contexte des architectures orientées services positionne notre travail dans un
environnement où l’agilité du développement est pré-dominante. En effet, avec des changements
fréquents des besoins des utilisateurs, mais également des services externes utilisés,
la fiabilité de la QoS et son maintien dans de tels systèmes sont des valeurs importantes.
Nous énumérons dans cette section les différents défis liés à l’évolution d’un logiciel en
terme de qualité de service :
1. Collaboration entre acteurs : pour gérer une évolution et assurer le maintien de la
qualité de service d’un système, la connaissance et la coopération des acteurs œuvrant
au niveau du système développé, des propriétés de qualité de service étudiées, et des
évolutions sont nécessaires. En effet, effectuer une évolution tout en s’assurant du
maintien de la qualité de service requiert une connaissance transversale à ces différents
domaines, que seule la coopération peut apporter. L’identification des différents rôles
et des différentes expertises au sein de l’organisation permettront de concevoir et de
21.3. Proposition
faire évoluer un système où la qualité de service est l’une des préoccupations. Cette
identification est nécessaire dans le but de responsabiliser et de définir les différentes
collaborations à mettre en place.
2. Interactions entre les différentes parties d’un logiciel : le logiciel réalisé par
l’équipe de développement est bien souvent constitué de sous-parties, qui interagissent
pour proposer des fonctionnalités attendues par les utilisateurs. Ces interactions in-
fluent sur la qualité du service du système, et sont bien souvent implicites. L’identi-
fication explicite des interactions entre les éléments d’un système permet d’améliorer
la compréhension du système dans son ensemble, notamment lors d’une évolution.
3. Minimisation de la vérification : afin de s’assurer du maintien de la qualité de
service, l’étape de l’évolution est accompagnée d’une étape de vérification, où chaque
propriété de QoS est contrôlée pour l’ensemble du système. Toutefois, avec l’augmentation
de la taille des systèmes, cette phase peut devenir chronophage. Ce phénomène
s’accentue si l’on considère des systèmes développés de manière agile, où les évolutions
sont fréquentes. Dans ces conditions, l’étape de vérification doit être la plus rapide
possible afin de ne pas interférer avec le bon fonctionnement du système et de ne pas
dégrader ses performances. Nous devons rendre l’étape de vérification la plus rapide
possible, en minimisant le nombre d’éléments à re-vérifier.
4. Identification de la cause de la violation d’un contrat : lorsqu’une évolution
viole un contrat de QoS, l’équipe de développement a pour tâche de détecter l’origine
de cette violation, dans le but de pouvoir corriger l’évolution. Partant du contrat
violé, il s’agit donc d’identifier l’ensemble des interactions du logiciel impliquées dans
la dégradation de la QoS, afin de cibler au plus près son origine. Pour cela, nous
cherchons à établir les dépendances existant entre l’exécution du logiciel et sa qualité
de service.
1.3 Proposition
Pour répondre à ces défis, nous présentons dans cette thèse un ensemble de contributions
constituant un mécanisme d’évolution à la fois agile dans la réaction aux besoins de
l’utilisateur, fiable dans le maintien de la qualité de service une fois l’évolution réalisée, et
minimale, dans le sens où le processus de vérification de la qualité de service doit être le
plus court possible dans le cas où l’évolution s’opèrerait à l’exécution.
Ces contributions s’articulent autour d’un cycle de développement agile, nommé Blink,
portant une attention particulière sur le maintien de la QoS lors de l’évolution. Notre cycle
de développement met au centre des préoccupations la notion d’évolution comme élément
à prendre en compte dès les premières étapes de conception du logiciel. En identifiant les
différents rôles nécessaires au maintien de la QoS de l’évolution, Blink permet d’identifier
l’ensemble des informations devant être fourni, et de délimiter les points d’interaction dans
le but d’échanger ces informations.
En complément du processus de développement, nous présentons Smile, un canevas
de développement mettant en œuvre Blink. Celui-ci implémente une boucle d’évolution,
permettant de concevoir, d’analyser et d’appliquer une évolution, en portant une attention
particulière au maintien de la qualité de service. Le but de cette boucle est de déterminer au
plus tôt l’effet que peut avoir une évolution sur le reste du système et sur sa QoS. Pour cela,
notre analyse de l’évolution consiste à déterminer les relations de causalité qu’une évolution
a sur le reste du système. Il s’agit ici d’utiliser ces relations causales, dans le but d’identifier
les différents éléments affectés et de re-vérifier par la suite si la qualité de service de ces
éléments a été affectée. Cela permet ainsi de pouvoir identifier dans un premier temps la
31.4. Organisation du document
portée d’une évolution, afin de pouvoir dans un second temps minimiser le processus de
re-vérification.
En résumé, les contributions de la thèse sont les suivantes :
– Blink, un processus de développement collaboratif pour le maintien de la
QoS lors de l’évolution : nous définissons dans ce document un processus de développement
pour lequel la problématique du maintien de la QoS lors de l’évolution est
au centre des préoccupations. Pour cela, nous définissons un ensemble d’acteurs, devant
collaborer tout au long du cycle de développement en partageant les informations
propres à leur expertise qui pourraient être utile au maintien.
– Une méthode de détermination des interactions entre les différentes parties
du système : nous définissons dans un premier temps quels types d’influence nous
pouvons retrouver dans un système et au niveau de la qualité de service. Puis, nous
présentons une méthode permettant, à partir d’un système et de la description d’une
propriété de qualité de service, de déterminer de manière automatique ces influences.
– Une analyse d’évolution permettant de déterminer l’effet d’une évolution
sur la QoS du système : en réutilisant les modèles représentant les interactions
existantes au sein d’un système, nous présentons une analyse permettant, à partir
d’une évolution, de savoir l’effet de cette dernière au sein du système, mais également
de déterminer si un contrat de QoS a été violé ou non, gage du maintien de la QoS.
– Smile, un canevas de développement automatisant les différents traitements
nécessaires à Blink : nous introduisons dans ce document notre canevas
supportant les différents points abordés ci-dessus, et montrons ce que ce canevas de
développement apporte lors de l’évolution.
Afin de valider l’apport de notre approche dans le maintien de la QoS lors de l’évolution,
nous appliquons Blink et Smile sur un cas d’étude nommé Système de gestion de crises.
Lors de cette validation, nous vérifions notamment si notre outil est en mesure de détecter
le non-maintien de la QoS lors de l’évolution du cas d’étude.
1.4 Organisation du document
Ce document est organisé en trois parties :
1. La première partie se concentre sur le contexte et les motivations de la thèse. Dans
le chapitre 2, nous posons le contexte de travail, d’un point de vue conceptuel et
technologique. Nous définissons ici les notions liées aux architectures orientées services,
à la qualité de service, et à l’évolution des systèmes logiciels. Dans le chapitre 3, nous
dressons l’état de l’art des travaux de recherche sur ce domaine. Pour cela, nous
nous focalisons sur deux axes, à savoir les cycles de développement d’un logiciel,
et les différentes analyses d’impact pouvant déterminer l’effet d’une évolution, ou
d’un changement en général. Enfin, dans le chapitre 4, nous décrivons PicWeb, que
nous utilisons comme exemple fil rouge nous permettant d’illustrer les différentes
contributions de la thèse. Après avoir présenté l’exemple, nous expliquons comment
un problème de qualité de service est survenu lors de son évolution.
2. La deuxième partie regroupe les contributions de la thèse, réparties en quatre chapitres.
Dans le chapitre 5, nous présentons Blink, un processus de développement
orienté pour le maintien de la qualité de service au cours des différentes évolutions.
Nous mettons notamment en évidence les différents acteurs nécessaires au maintien
de la QoS. Les chapitres 6 à 8 se focalisent alors successivement sur chaque acteur
41.5. Liste des publications liées à cette thèse
impliqué dans Blink. Le chapitre 6 se centre sur la réalisation d’un système, et
sur le rôle de l’architecte du système. Nous définissons un méta-modèle permettant
de représenter un système à base de processus métiers. Puis, nous introduisons la
notion de causalité dans un système, permettant de représenter les interactions entre
ses différentes parties, et dressons une liste de causalités que l’on peut retrouver. Le
chapitre 7 est focalisé sur le rôle de l’expert en qualité de service. Nous présentons
ici notre méta-modèle pour représenter une propriété, ainsi que QoS4Evol, un langage
permettant à l’expert en QoS de la définir de manière textuelle. De manière similaire
au chapitre précédent, nous définissons ensuite la notion de causalité pour les propriétés
de qualité de service. Nous listons les différents types de relation causale que
nous pouvons retrouver pour une propriété de QoS, et les illustrons sur PicWeb.
Enfin, nous présentons une méthode permettant d’extraire automatiquement les relations
causales de la description d’une propriété. Le chapitre 8 porte sur l’architecte
de l’évolution. Nous introduisons un langage d’évolution des processus métiers, permettant
d’ajouter ou de supprimer des fonctionnalités. Puis, nous nous focalisons sur
l’étape d’analyse d’une évolution, où nous utilisons les relations causales présentées
dans les chapitres précédents pour déterminer l’effet d’une évolution sur la qualité de
service d’un système, et ainsi qualifier si une évolution permet le maintien de la QoS
ou non.
3. La troisième partie du document s’intéresse à l’évaluation de notre approche. Le chapitre
9 détaille la mise en œuvre des différentes contributions au travers de notre
canevas, Smile, tandis que le chapitre 10 est une évaluation de notre approche sur un
autre cas d’étude, le système de gestion de crise. Ce cas d’étude a l’avantage d’être de
taille plus importante que PicWeb, d’être constitué de plusieurs processus métiers,
et d’être doté d’une base d’évolutions conséquentes. Enfin, nous terminons avec le
chapitre 11, où nous faisons le bilan des différents chapitres de la thèse, et présentons
quelques pistes à explorer dans de futurs travaux.
1.5 Liste des publications liées à cette thèse
Les communications mentionnées ci-dessous ont été réalisées dans des manifestations
avec comité de sélection.
Communications internationales
– A Causal Model to predict the Effect of Business Process Evolution on
Quality of Service. Alexandre Feugas, Sébastien Mosser et Laurence Duchien.
Dans International Conference on the Quality of Software Architectures (QoSA’13),
pages 143-152, Vancouver, Canada, juin 2013. (Rang A selon le classement CORE
Austalian)
Communications nationales
– Déterminer l’impact d’une évolution dans les processus métiers. Alexandre
Feugas, Sébastien Mosser, Anne-Françoise Le Meur et Laurence Duchien. Dans IDM,
pages 71-76, Lille, France, juin 2011.
51.5. Liste des publications liées à cette thèse
Posters
– Un processus de développement pour contrôler l’évolution des processus
métiers en termes de QoS. Alexandre Feugas, Sébastien Mosser et Laurence Duchien.
Poster dans GDR GPL, pages 237-238, Rennes, France, Juin 2012.
6Première partie
Contexte et MotivationsChapitre 2
Contexte
Sommaire
2.1 Les architectures orientées services . . . . . . . . . . . . . . . . . . 9
2.1.1 Définitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
2.1.2 Organisation des architectures orientées services . . . . . . . . . . . 10
2.2 La Qualité de Service . . . . . . . . . . . . . . . . . . . . . . . . . . 12
2.2.1 Qualité du logiciel . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
2.2.2 Méthodes de détermination de la qualité de service . . . . . . . . . . 14
2.2.3 Contrats de Qualité de Service . . . . . . . . . . . . . . . . . . . . . 17
2.3 Évolution des systèmes logiciels . . . . . . . . . . . . . . . . . . . . 17
2.3.1 Définition de l’évolution . . . . . . . . . . . . . . . . . . . . . . . . . 17
2.3.2 Caractéristiques d’une évolution . . . . . . . . . . . . . . . . . . . . 18
2.4 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
N
ous avons présenté dans l’introduction l’objectif de cette thèse. Dans ce chapitre,
nous présentons ses enjeux d’un point de vue conceptuel et technologique : nous abordons
dans un premier temps les architectures orientées services. Puis, nous présentons la
notion de qualité de service, ainsi que les approches existantes permettant de l’étudier.
Nous introduisons enfin la définition de l’évolution : quelles notions se trouvent derrière ce
concept, comment l’équipe de développement s’y prend pour faire évoluer un logiciel.
2.1 Les architectures orientées services
2.1.1 Définitions
Les architectures orientées services (SOA) sont un nouveau paradigme de conception apparu
dans la fin des années 90. Il existe différentes définitions pour caractériser les architectures
orientées service. Parmi elles, nous pouvons retenir la définition du W3C [Haas 2004] :
Définition 1
Architecture Orientée Services (W3C) : "une architecture orientée services regroupe
un ensemble de composants qui peuvent être invoqués, et pour lesquels les descriptions
de leurs interfaces peuvent être publiées et découvertes".
Cette définition peut être complétée par une autre définition, d’IBM :
Définition 2
Architecture Orientée Services (IBM) : "une architecture orientée services est un
canevas d’information qui considère les applications métiers de tous les jours pour les
fragmenter en fonctions et processus métiers individuels, appelés services. Une architecture
orientée service permet la construction, le déploiement et l’intégration de ces2.1. Les architectures orientées services
services indépendamment des applications et des plate-formes d’exécution".
De ces deux définitions, nous pouvons comprendre que la notion de service, comme entité
de calcul invocable, et pour lequel une interface est définie, est principale. Ces services sont
indépendants, ils sont déployés pour pouvoir par la suite être publiés, découverts et invoqués.
Il existe différentes technologies dites orientées services, reprenant les principes des architectures
orientées services plus ou moins fidèlement. Parmi elle, nous retiendrons notamment
les web-services [Kuebler 2001], où l’on considère que les services sont définis et exposés en
utilisant les standards du Web.
Propriétés remarquables
Les architectures orientées service ont été définies pour concevoir des systèmes logiciels
pour lesquels les entités de première classe sont les services, des entités autonomes,
invocables, dont l’interface est clairement explicitée. Plusieurs travaux ont proposé la caractérisation
des architectures orientées services [Papazoglou 2003, Huhns 2005, Breivold 2007,
Papazoglou 2007]. Dans la suite, nous recensons les propriétés suivantes :
– Couplage lâche des éléments : afin de pouvoir faciliter la reconfiguration d’un
service, e.g., son remplacement, les éléments d’un système doivent bénéficier d’un
couplage lâche, c’est-à-dire qu’il n’est pas nécessaire pour un appelant à un service
de connaître la structure ou l’implémentation de ce dernier pour pouvoir l’utiliser.
De même, une façon de permettre un couplage lâche au niveau d’un service consiste
à séparer l’interface de l’opération et son implémentation. Cela offre la possibilité de
pouvoir modifier l’implémentation, ou de pouvoir exposer facilement l’interface du
service.
– Neutralité technologique : pour permettre à tout système d’interagir avec un
service, la dépendance à un contexte technologique donné est à proscrire. Cette propriété
s’inscrit dans un contexte d’inter-opérabilité, facilitant ainsi l’établissement de
partenariats entre différentes organisations.
– Transparence de la localisation : un service doit être explicitement atteignable,
de façon à permettre à tout client de pouvoir l’invoquer, dans son périmètre de disponibilité.
Dans le cas des web-services, un service doit être disponible à n’importe
quel point de l’Internet.
– Modularité et Composabilité : les architectures orientées services mettent en
avant le côté réutilisable des services. Par le biais d’une interface exposée et de l’interopérabilité
des services, le concept de service a été conçu pour facilité la modularité, la
réutilisabilité et la composabilité d’une application. Ainsi, il est possible de délimiter
le cadre de modification d’un service par son aspect modulaire, l’exposition de son
interface permet de réutiliser le service dans une autre application, et, partant de différents
services, il est possible de composer un nouveau service avec une fonctionnalité
différente, en utilisant d’autres services par le biais d’invocations.
Pour atteindre cet ensemble de propriétés, un éco-système des architectures orientées services
a été défini par Papazoglou [Papazoglou 2003] comme étant constitué de trois couches.
Dans la suite de cette section, nous détaillons cette organisation en trois couches.
2.1.2 Organisation des architectures orientées services
Dans son travail sur la définition des architectures orientées service, Papazoglou a imaginé
l’éco-système des SOA comme étant constitué de trois couches, où chaque couche s’appuie
sur les définitions des couches précédentes. La première couche concerne les services à
102.1. Les architectures orientées services
leur niveau le plus simple. Ici, on s’intéressera aux notions d’interface, de publication et de
sélection d’un service. La seconde couche s’appuie sur les services basiques pour définir de
nouveaux services par composition. On appelle composition de services la réalisation d’un
service en réutilisant d’autres services, le plus souvent pour construire une fonctionnalité
de complexité supérieure. Ici, on attachera plus d’importance à la sémantique du nouveau
service composé, mais également à des caractéristiques non fonctionnelles d’un service telles
que les propriétés de qualité de service. Enfin, le dernière couche considère la gestion des
services. Ici, il s’agit en fait de considérer l’infrastructure dans son ensemble, en ayant en
tête des préoccupations telles que le cycle de vie du service, son contrôle, et la gestion du
changement d’un service.
2.1.2.1 Services simples
Définition d’un service
Comme introduit dans les propriétés des SOA, une opération d’un service, ou par abus
de langage un service, a une interface explicitement définie. Cette interface définit a minima
la signature de l’opération. Concrètement, il peut s’agir d’une structure écrite dans un Language
de Description d’Interface (IDL) [Bachmann 2002]. Dans le cadre des web-services, le
langage adopté est le Langage de Description des Web Services (WSDL) [Chinnici 2007]. Il
est ainsi possible d’y décrire des types de données, les signatures des différentes opérations,
tout comme consigner la localisation du service par le biais d’un identifiant de ressource
(Uniform Resource Identifier, URI en abbrégé) [Coates 2001]. Un service est en soi autonome
et indépendant. C’est cette caractéristique qui permet aux architectures orientées
services d’offrir un couplage lâche entre les éléments.
Interactions d’un service
Au niveau des interactions entre les services, il est important de différencier deux acteurs
différents. Ces acteurs auront des préoccupations différentes :
– Fournisseur de Service : il est en charge de l’implémentation des différentes opé-
rations du service. Il doit notamment prendre en compte la qualité de service, en
adoptant une politique, cette police pouvant aller d’une politique de "meilleur effort"
(où aucun niveau minimal de qualité est à atteindre), jusqu’à mettre la qualité de
service au rang de préoccupation majeure. Ce dernier scénario se rencontre fréquemment
dans les logiciels à base de services. En effet, dans un système où les services
sont publiés et disponibles pour tous, le critère de différenciation et de choix entre
deux services implémentant les mêmes fonctionnalités portera sur le niveau de qualité
de service garanti pour l’opération. Il est important dans ce cas de fournir le service
le plus efficient possible. Afin de pouvoir établir ces contraintes et ces attentes
en termes de qualité de service, il est nécessaire pour le fournisseur du service et
pour l’utilisateur du service d’établir un contrat, nommé Service Level Agreement
(SLA) [Ludwig 2003], où chacune des parties s’engagent respectivement à fournir un
certain niveau de qualité de service et à utiliser le service dans certaines conditions.
Nous reviendrons sur ce point dans la section 2.2.3.
– Utilisateur du service : il s’agit de l’entité faisant appel à l’opération proposée par
le fournisseur. Si l’utilisateur n’a a priori aucun engagement auprès du fournisseur de
service, ce dernier doit être en mesure d’établir des limites dans l’utilisation du service
invoqué, afin de pouvoir garantir un niveau de qualité de service satisfaisant. En
effet, invoquer un service de façon disproportionnée (trop fréquemment par exemple)
pourrait notamment détériorer les performances de ce dernier [Menasce 2002]. De
112.2. La Qualité de Service
plus, l’utilisateur du service doit être le garant de la bonne intégration du service
dans l’éco-système du logiciel qu’il réalise, notamment dans le cadre de transactions.
2.1.2.2 Composition de Services
La notion de service est enrichie avec le concept de composition, où l’on va chercher ici à
réutiliser des services existants pour, en les combinant, produire un nouveau service ayant
une fonctionnalité différente.
Dans les architectures orientées services, il existe principalement deux types de composition
: la composition par orchestration et la composition par chorégraphie. Nous appelons
orchestration de services un processus métier exécutable, pouvant interagir avec des services
internes et externes [Peltz 2003]. Il s’agit en fait de la combinaison d’un flot de contrôle et
d’un flot de données pour décrire la séquence des opérations à effectuer pour aboutir à
un but donné. L’orchestration d’un service diffère de la chorégraphie dans le sens où cette
dernière a un rôle de vision globale des interactions d’un système, là où l’orchestration
représente le comportement d’une seule opération, et ses échanges avec d’autres services.
2.1.2.3 Gestion de services
Le dernier niveau organisationnel consiste à gérer les différents services existants. Dans
cette partie, il s’agit de gérer le cycle de vie d’un service (marche/arrêt) ainsi que le contrôle
de son exécution. Dans certains cas, il pourra également s’agir de gérer le remplacement
à chaud de services par un autre, en cas de défaillance par exemple. Ces techniques sont
implémentées dans les Bus de Services pour les Entreprises (ESB), véritable plate-forme
d’exécution gérant entre autres l’exécution des services et leurs communication.
La modularité présente dans les architectures orientées services, associée à la notion
d’inter-opérabilité, permet notamment de faciliter la sélection ou le remplacement d’un
service par un autre aux fonctionnalités similaires. Dès lors, le concepteur a face à lui un
panel de services équivalents parmi lesquels il devra en choisir un. Pour effectuer son choix,
il peut désormais prendre en compte un nouveau critère de sélection : la qualité de service.
2.2 La Qualité de Service
Dans cette section, nous présentons la notion de qualité de service. Nous introduisons
dans un premier temps le domaine de qualité du logiciel, avant de nous concentrer sur
ce qu’est la qualité de service, quelles sont les différentes méthodes de détermination, et
comment il est possible de la maintenir dans les SOA.
2.2.1 Qualité du logiciel
La notion de qualité du logiciel regroupe l’ensemble des caractéristiques visant à évaluer
la manière dont le logiciel a été réalisé. Derrière ce terme, on retrouve un ensemble
de caractéristiques ; certaines sont quantifiables, tandis que d’autres sont totalement à l’appréciation
de l’humain. Afin de pouvoir caractériser les caractéristiques d’un logiciel qui ne
sont pas propres à son exécution ou à sa logique métier, la notion de qualité du logiciel a
été introduite dans le milieu des années 70 pour définir une classification d’un ensemble de
propriétés de qualité du logiciel [Boehm 1976]. Cette notion fut normalisée par la norme
ISO/CEI9126 [ISO 2001] et est régulièrement ré-actualisée [ISO 2004], pour s’inscrire désormais
dans une démarche d’établissement des besoins de qualité et de son évaluation. Cette
122.2. La Qualité de Service
démarche se nomme Square. On retrouve notamment dans cette norme une classification
regroupant l’ensemble des propriétés de qualité autour de 5 catégories :
– La capacité fonctionnelle : il s’agit de la manière dont les fonctionnalités développées
correspondent au cahier des charges. On s’intéresse notamment ici aux souscaractéristiques
d’aptitude, d’exactitude et d’interopérabilité [Brownsword 2004].
– La fiabilité : il s’agit de la faculté du logiciel à continuer d’être digne de confiance.
Pour cela, on s’intéresse aux sous-caractéristiques de maturité, de tolérance aux fautes
et de capacité de récupération [Ucla 2001, Clements 2003].
– La facilité d’usage : cette catégorie qualifie la capacité d’un utilisateur quelconque à
utiliser le logiciel développé. On s’intéresse ici aux sous-caractéristiques d’exploitabilité,
de facilité d’apprentissage et de facilité de compréhension
– L’efficacité : cette caractéristique étudie l’adéquation entre les moyens financiers et
humains mis en œuvre pour réaliser le logiciel, et les besoins effectifs. On s’intéresse
ici à l’efficacité en parlant des ressources employées, et des temps de réalisation
– La maintenabilité : cette catégorie regroupe toutes les caractéristiques propres à la
faculté de modifier le logiciel pour ,par exemple, corriger un bogue. On s’intéresse ici
aux sous-caractéristiques de stabilité, de facilité de modification, de facilité d’analyse,
et de facilité à être testé.
– La portabilité : enfin, une dernière caractéristique propre à la qualité se centre sur la
capacité à déployer une application sur une machine quelconque. On s’intéresse ici aux
sous-caractéristiques de facilité d’installation, de facilité de migration, d’adaptabilité
et d’interchangeabilité.
De toutes ces sous-caractéristiques, certaines sont mesurables et quantifiables, tandis
que d’autres sont subjectives. Dans le cadre de cette thèse, nous considérons que les propriétés
de qualité de service sont quantifiables, et dont un changement de valeur démontre
un changement dans le comportement du système. À noter qu’il est important pour les différentes
personnes gravitant autour du logiciel développé de prendre en compte la qualité
du logiciel. Pour le client, il s’agit du gage d’un système performant. Pour les développeurs,
développer un système de qualité permet de s’assurer que l’entreprise engrangera du profit
au lieu d’essuyer des pertes.
Qualité de Service
Il existe de nombreuses définitions de la qualité de service. Parmi elles, nous retenons
dans ce document la définition de Crnkovic et al. [Crnkovic 2005] :
Définition 3
Qualité de Service : On appelle propriété de qualité de service "une caractérisation
de tout ou d’une partie du système, selon une préoccupation particulière".
Il s’agit ici de propriétés portant directement sur le comportement du logiciel. Elles sont
le plus souvent quantifiables. Dans le cadre de cette thèse, nous restreignons notre étude
des propriétés de QoS aux propriétés quantifiables de manière non équivoque. Un exemple
de propriétés de qualité de service correspondant à notre définition est les propriétés de
performance telles que la sécurité, le temps de réponse ou la disponibilité [O’Brien 2007,
Rosenberg 2006], pour lesquelles il existe bien souvent des outils d’analyse ou de contrôle à
l’exécution permettant d’obtenir une valeur numérique. Tout particulièrement, on regardera
du côté de [Lelli 2007, Fakhfakh 2012] pour des exemples de propriétés de qualité de service
que l’on rencontre dans les SOA.
132.2. La Qualité de Service
Il existe de nombreux langages de modélisation de la qualité de service. Les travaux les
plus proche de notre thématique sont CQML [Rottger 2003], WQSDL [Newcomer 2002] et
MARTE [OMG 2009b]. Dans ces langages, une propriété est définie par son nom. À ce nom
est associé a minima une unité de grandeur et un critère de comparaison permettant de
savoir si une valeur est meilleure qu’une autre. Par exemple, on cherchera le plus souvent
à minimiser des durées (le plus petit est meilleur), mais on cherchera à augmenter un
pourcentage dans le cas de la disponibilité (le plus grand est meilleur).
Outre ces informations, les langages de QoS décrivent une, ou plusieurs manières de
déterminer la valeur de qualité de service. Nous discutons des différentes méthodes de
détermination dans la section suivante.
2.2.2 Méthodes de détermination de la qualité de service
Dans le contexte de la thèse, les propriétés de qualité de service sont des grandeurs
quantifiables caractérisant un spécimen donné, à savoir le service. Nous présentons dans
cette section les différentes méthodes de détermination de la qualité de service existantes.
Détermination par analyse statique
Une manière de déterminer les valeurs des propriétés de qualité de service consiste à
effectuer une analyse statique du logiciel. Cette méthode s’opère le plus souvent au cours
de la phase de conception, et peut s’appuyer sur des informations provenant de l’exécution
du logiciel. De nombreuses techniques existent pour analyser un logiciel. Par exemple, de
nombreux travaux transforment le logiciel/processus métier en réseau de Pétri [Reisig 1998]
pour effectuer des analyses formelles. On retiendra notamment les travaux de van der Aalst
et de Massuthe qui cherchent à déterminer si un logiciel est correct [Van der Aalst 2008,
Massuthe 2005].
Dans le domaine de l’ingénierie des performances, l’établissement de modèles tels que
les réseaux de file d’attente ("queuing network" en anglais) ou les modèles d’utilisation permettent
de simuler l’exécution du système. Il est également possible de traduire un processus
métier dans une logique temporelle linéaire (LTL) [Pnueli 1977, Giannakopoulou 2001] ou
dans un langage de Pi-Calcul [Milner 1999]. Cela permet par exemple de déterminer des
propriétés de sûreté et de correction (justesse). [Havelund 2002, Ferrara 2004].
La détermination par analyse est particulièrement adaptée pour des propriétés portant
sur la structure ou l’architecture du système, et qui ne dépendent pas de l’état des éléments
du système à l’exécution. Cette technique s’applique hors-ligne, à un moment où on peut se
permettre de prendre plus de temps pour exécuter les analyses. Toutefois, dans certains cas,
comme lorsqu’on souhaite déterminer la taille d’un message où la taille de certaines variables
n’est pas fixe, l’analyse n’est pas déterminable hors ligne. Dans ce cas, l’analyse raffine en
déterminant tout ce qui est possible à la conception, pour aller chercher uniquement les
informations nécessaires à l’exécution. On parle alors d’analyse dynamique.
Détermination par analyse dynamique
Dans le cas où certaines informations ne sont pas disponibles hors ligne, la détermination
d’une valeur de propriété s’effectue à l’exécution. C’est le cas notamment pour des
propriétés telles que le temps de transmission d’un message ou le temps de réparation d’un
service [OASIS 2010], qui ont une forte dépendance au contexte d’exécution. Pour cela, la
détermination s’effectue à l’aide d’un moniteur. Un moniteur a pour rôle d’observer un
142.2. La Qualité de Service
ou plusieurs événements survenant au cours de l’exécution d’un logiciel, en capturant des
informations sur l’état du logiciel avant, après, ou en parallèle de ces événements.
Outre la propriété qu’il observe, il est possible de qualifier un moniteur selon différents
critères. Nous retiendrons ici le type de moniteur. Wetzstein et al. classifient dans leurs
travaux trois types de moniteurs : moniteur externe au moteur d’exécution, instrumentation
du moteur d’exécution et instrumentation du processus métier [Wetzstein 2009]. Selon
la solution choisie, l’insertion de code lié à la capture des informations à l’exécution engendrera
un sur-coût en terme de performance pouvant influer sur le bon fonctionnement
du système et sur sa qualité de service. On dit que le contrôle à l’exécution est intrusif
[Cheng 2009]. L’intrusion du moniteur ainsi que son niveau d’interopérabilité seront plus ou
moins grands. Par exemple, un moniteur instrumentant le moteur d’exécution sera optimisé
pour que son intrusion soit moindre, mais il ne sera par compatible avec un autre moteur
d’exécution.
Nous retiendrons également la granularité de l’observation d’un moniteur : il s’agit
du degré de détail auquel le moniteur est sensible [Ghezzi 2007]. À titre d’exemple, une
mesure peut être effectuée au niveau du processus pour avoir une vision d’ensemble, au
niveau de l’activité, ou encore basé sur des événements bas niveau tels que le changement
d’état d’une activité en passe d’être exécutée [De Pauw 2005]. Ici encore, cette finesse dans
la granularité a un coût : plus le contrôle sera fin, et plus de données seront collectées et
précises. C’est autant de données qu’il faut par la suite analyser et interpréter. En revanche,
rester à niveau d’abstraction trop élevé empêchera l’observation de certains phénomènes.
Détermination par dérivation de propriétés
Il est également possible de définir la détermination d’une propriété comme étant une
fonction mathématique dépendant de valeurs d’autres propriétés. On parle de propriété
dérivée de sous-propriétés. La valeur de propriété pour un élément du système (tel qu’un
service) est définie en fonction de valeurs d’autres propriétés pour le même élément du
système. Par exemple, le temps de réponse d’un service peut être défini comme étant la
somme du temps de transmission et du temps d’exécution. Cette définition est opérée à
l’aide d’une formule mathématique, nommée formule de dérivation. La Figure 2.1 est un
exemple de dérivation où le temps de réponse est calculé en se basant sur les valeurs des
propriétés dont il dérive.
La détermination des valeurs de propriétés par dérivation a pour avantage d’être lé-
gère, les formules définies utilisant le plus souvent des opérateurs arithmétiques simples.
Toutefois, il est nécessaire de déterminer les opérandes utilisés dans la formule ; ces valeurs
étant d’autres valeurs de propriétés, la détermination par dérivation nécessitera au préalable
d’effectuer des analyses à la conception et/ou des mesures à l’exécution.
Détermination par agrégation de valeurs
Nous avons restreint dans le cadre de cette thèse le champ des propriétés étudiées aux
propriétés composables. Cela veut dire que pour un élément de composition (tels que les
processus métiers, les séquences, ou les appels en parallèle), il existe une formule mathématique
permettant de déduire la valeur de propriété de la composition, à partir des valeurs
de propriétés des activités contenues. Il suffit donc d’observer ces activités (par analyse
statique ou par mesure), et de composer une valeur de propriété pour la composition en
utilisant une formule mathématique nommée formule d’agrégation. Il est important de noter
qu’ici, contrairement à la détermination par dérivation de propriétés, la détermination
par agrégation de valeurs ne repose pas sur plusieurs propriétés différentes. Ici, il s’agit de
152.2. La Qualité de Service
Activity act
Monitor Report
Transmission Time = 30 ms
Monitor Report
Computation Time = 19 ms
Derivation Report
Response Time = 30 + 19 = 49 ms
Figure 2.1 – Exemple de détermination par dérivation.
déduire une valeur de propriété pour un élément de composition à partir des valeurs de la
même propriété, pour les éléments le constituant.
La Figure 2.2 illustre la détermination par agrégation sur un processus métier quelconque.
Ici, le temps de réponse du processus est la somme des temps de réponse des
activités qu’il contient. De nombreux travaux ont porté sur l’établissement de ces formules
d’agrégation. Les premiers à les avoir formalisées sont Cardoso [Cardoso 2004] et Jaeger
[Jaeger 2004]. Ces travaux furent repris par Mukherjee [Mukherjee 2008], et par Dumas pour
permettre leur établissement dans le cadre de processus métiers mal formés [Dumas 2010].
Canfora a même étendu le concept d’agrégation à des propriétés non fonctionnelles, mais
spécifiques au domaine du logiciel étudié [Canfora 2006].
a1
a2
a4
a3
Derivation Report
Response Time = 9 ms
Derivation Report
Response Time = 30 ms
Derivation Report
Response Time = 55 ms
Derivation Report
Response Time = 6 ms
Aggregation Report
Response Time = 9 + 30 + 55 + 6 = 100 ms Figure 2.2 – Exemple de détermination par agrégation.
De manière similaire à la détermination par dérivation, la méthode par agrégation est
peu coûteuse en elle-même en termes de ressources. Toutefois, elle nécessitera également
une phase préliminaire de détermination à la conception et/ou à l’exécution.
162.3. Évolution des systèmes logiciels
2.2.3 Contrats de Qualité de Service
Dans l’éco-système d’un service, différentes parties œuvrant pour sa réalisation et son
utilisation doivent collaborer. Il s’agit notamment du fournisseur du service, responsable de
son implémentation et de sa disponibilité, et du consommateur du service, qui l’utilise. Afin
de pouvoir garantir que le service proposé reste stable au niveau de sa qualité de service,
les différentes parties impliquées doivent se mettre d’accord.
Pour pouvoir établir cet engagement, il est nécessaire d’établir des contrats entre ces
différentes parties. Il existe différents supports pour pouvoir établir ces contrats. Le plus
utilisé se nomme Web Service Level Agreement (WSLA) [Keller 2003]. Un contrat est un
accord liant deux ou plusieurs parties sur certaines conditions, telles que les responsabilités
de chaque partie ou les engagements à respecter. Dans le cadre des WSLA, un contrat est
constitué de trois sections. D’abord, il s’agit d’établir l’identité de chaque partie impliquée.
Puis, le contrat se poursuit par la désignation du service pour lequel les parties se mettent
d’accord. Enfin, la dernière section du contrat établit les différentes clauses d’engagement.
On parle alors d’objectifs de niveau de service (SLO). Un objectif est constitué d’une partie
engagée par l’objectif (l’Obligee en anglais), d’une période de validité de l’objectif, et
d’une condition à respecter. Cette condition prend la forme d’une expression, indiquant un
ensemble d’opérateurs sur des métriques. Par exemple, on pourra décrire que la métrique
de disponibilité doit être supérieur ou égale à 80%, ce qui signifie que le service en question
doit être accessible pour le consommateur au minimum 80% du temps.
Une fois que le contrat est mis en place, il est nécessaire de s’assurer que tous les objectifs
sont bien respectés. Une approche possible pour cela consiste à utiliser un contrôleur, qui
vérifie bien qu’aucun objectif n’est violé. On retiendra notamment les travaux de Oriol et
al., qui ont développé un système nommé SALMon pour l’analyse et le contrôle de SLA
[Oriol 2008].
Nous venons de présenter dans cette section les travaux existants autour de la qualité
de service dans les architectures orientées services. Nous avons vu différentes manières de
déterminer une valeur de propriété de QoS permettent de qualifier un service, avant de
s’intéresser à la manière dont la QoS peut être conservée en définissant un contrat entre
le fournisseur du service et son consommateur. Si ce dernier point est facilement vérifiable
au moment du contrat, il convient de s’intéresser à l’étape de l’évolution, au cours de
laquelle les changements opérés peuvent interférer la validité du contrat. Pour cela, nous
nous intéressons dans la section suivante aux différentes caractéristiques de l’évolution des
systèmes logiciels.
2.3 Évolution des systèmes logiciels
2.3.1 Définition de l’évolution
Le domaine de cette thèse se concentre sur la manière de faire évoluer un logiciel au
fil du temps. Cela veut dire par exemple d’ajouter des fonctionnalités, ou de maintenir le
code pour effectuer les mêmes fonctionnalités. Traditionnellement, les logiciels ont besoin
de changer pour correspondre aux besoins des utilisateurs, pour corriger un bug ou pour
supporter l’évolution technologique.
La notion d’évolution est apparue dans la fin des années 60 [Lehman 1969]. Lehman et
al. ont été les premiers à en donner une définition [Lehman 1985] :
Définition 4
Évolution du logiciel : "La satisfaction [des besoins] continue demande des change-
172.3. Évolution des systèmes logiciels
ments continus. Le système aura à être adapté en fonction d’un environnement changeant
et des besoins changeants, en développant des concepts et en faisant progresser
les technologies. L’application et le système doivent évoluer. "
Ce genre de logiciel est appelé un logiciel de type-E.
Pour accompagner cette définition, les auteurs ont érigé une série de lois de l’évolution,
établies de manière empirique suite à l’étude de plusieurs systèmes industriels monolithiques
[Lehman 1997, Lehman 2006]. Parmi elles, nous retenons les suivantes, car elles s’inscrivent
tout particulièrement dans notre contexte :
Définition 5
Lois de l’évolution du logiciel :
– Continuité du changement : Un système satisfera progressivement de moins
en moins les besoins des utilisateurs au fil du temps, à moins qu’il s’adapte de
manière continue pour satisfaire les nouveaux besoins.
– Croissance de la complexité : Un système deviendra progressivement de plus
en plus complexe, à moins qu’un travail soit effectué pour réduire la complexité.
– Déclin de la qualité : Un système sera perçu comme perdant en qualité au fil
du temps, à moins que sa conception soit maintenue avec précaution et adaptée à
de nouvelles contraintes opérationnelles.
En s’appuyant sur des expériences industrielles concrètes, ces trois lois renforcent notre
position sur le besoin de faire évoluer un logiciel, et du besoin de s’assurer que la qualité
du système continue à être maintenue au fil du temps. Il est important de noter ici que
la notion de changement est au centre de ces définitions. Ce changement peut s’opérer
de plusieurs manières : si l’on considère l’éco-système d’un système logiciel comme étant
constitué du code source du système, de l’environnement dans lequel il est exécuté, des
besoins utilisateurs desquels le système a émané, le changement peut s’opérer sur chacun
de ces éléments.
Pour nous positionner dans cet éco-système, nous nous appuyons sur les travaux de
Godfrey et al. [Godfrey 2008]. Dans leur papier, les auteurs dressent un état des lieux du
vocabulaire utilisé et des différentes catégories d’opérations que l’on peut qualifier de "changement".
Ils se positionnent sur l’utilisation des mots maintenance et évolution. Dans le
contexte de la thèse, nous considérons que la maintenance est une phase au cours de laquelle
le logiciel est modifié pour corriger des bugs. Nous appelons adaptation la modification du
logiciel pendant son exécution pour réagir à un changement de son environnement. En-
fin, nous appelons évolution la modification d’un système logiciel suite à l’apparition de
nouveaux besoins des utilisateurs.
2.3.2 Caractéristiques d’une évolution
Cette section s’intéresse aux différents facteurs permettant de caractériser une évolution.
Nous présentons dans un premier temps les différentes catégories, avant de positionner nos
travaux pour chaque catégorie, dessinant ainsi le type d’évolution que nous traitons dans
cette thèse.
Afin de pouvoir décrire les caractéristiques d’une évolution, Mens et al. ont dressé une
taxonomie de l’évolution du logiciel [Mens 2003]. Dans ces travaux, les auteurs ont défini
quatre dimensions pour caractériser une évolution : le Où, le Quoi, le Quand et le Comment
de l’évolution. Sous chaque dimension, un ensemble de caractéristiques caractérise
182.3. Évolution des systèmes logiciels
cette dimension, proposant parfois diverses alternatives. Nous reprenons chacune de ces caractéristiques
dans la suite pour positionner les travaux de cette thèse, en définissant quel
type d’évolution nous traitons.
Le "Où" de l’évolution :
Cette dimension cherche à caractériser la localisation de l’application d’une évolution.
Pour cela, les auteurs se sont intéressés à différents facteurs :
– le type d’artéfact logiciel modifié : une évolution va consister en la modification d’un
élément du système au sens large. Ici, il peut s’agir bien évidemment du code source de
l’application ; mais on peut également considérer l’évolution comme un changement au
niveau des besoins de l’utilisateur, de l’architecture, ou encore de la documentation.
– la granularité de l’évolution : ce facteur est un ordre de grandeur évaluant à quel
niveau de finesse l’évolution opère. Il peut s’agir d’une granularité fine, telle qu’un
changement d’instruction ou de paramètre, jusqu’à un changement opéré à l’échelle
du fichier, du package, du service, ou même du système dans son ensemble.
– l’impact de l’évolution : le facteur d’impact est un critère d’importance pour qualifier
une évolution. Il a pour but de caractériser la portée de l’effet du changement sur le
reste du système. Il s’agit ici également d’un ordre de grandeur, allant d’un impact
local, jusqu’à un impact à l’échelle du système.
– la propagation du changement : ce facteur reprend la notion d’impact, en l’appliquant
à l’échelle du processus de développement. Là où le facteur d’impact d’une évolution
se concentre sur l’effet de l’évolution sur le comportement du système, la propagation
du changement s’intéresse aux effets sur d’autres éléments tels que la documentation
ou le modèle conceptuel.
Nous résumons l’ensemble des facteurs de la dimension "Où" dans la Table 2.1, où
les éléments notés en gras sont ceux que nous traitons dans le cadre de la thèse. Comptetenu
de la définition de l’évolution que nous avons choisie, nous traitons des évolutions
portant sur une partie du code source de l’application, à savoir les processus métiers. Ces
évolutions ont une granularité fine : nous souhaitons pouvoir caractériser tout changement
dans un processus métier, et un impact pouvant être local comme global. Enfin, nous nous
intéressons uniquement à son effet sur le comportement du système, nous ne traitons pas
la propagation du changement sur d’autres documents de conception.
Table 2.1 – Taxonomie d’une évolution : la dimension "Où".
Où
Type d’artéfact Granularité Impact Propagation du changement
Documentation Paramètre Local Documentation
Conception Instruction Système Conception
Implémentation Fichier Implémentation
Tests Package Tests
Le "Quoi" de l’évolution :
Cette dimension s’intéresse aux caractéristiques du système sur lequel l’évolution est
appliquée.
– Disponibilité : la disponibilité du système peut être définie comme la capacité du
système à répondre à une requête dans un laps de temps donné. Ici, il est important de
192.3. Évolution des systèmes logiciels
savoir quelles contraintes sont définies sur le système pour pouvoir prévoir l’application
d’une évolution. On considère qu’il peut être requis d’un système qu’il soit tout le
temps disponible, qu’il peut y avoir des périodes d’arrêt du système sur des périodes
courtes, ou simplement que le critère de disponibilité n’a pas d’importance.
– Dynamisme : ce facteur détermine si les changements à opérer sur le système sont
guidés de l’extérieur (système réactif), ou si les changements proviennent d’une observation
faites par des contrôleurs propres à l’application (système proactif). Pour ce
dernier cas, on parle de système autonome, et le changement est opéré à l’exécution.
– Exposition : les auteurs parlent d’ouverture du système pour désigner sa faculté à
autoriser son extension. On parle de système ouvert lorsque l’architecture et l’environnement
d’exécution sont constitués de mécanismes d’extension.
– Sûreté : la sûreté de l’évolution désigne la propriété du système à s’assurer que
l’évolution ne met pas le système dans un état erroné. Il peut s’agir de mécanismes
à la compilation, ou de contrôles effectués à l’exécution. On parle de sûreté statique
lorsque le contrôle de sûreté est effectué hors ligne. À l’inverse, la sûreté dynamique
consiste à vérifier l’évolution au cours de l’exécution du système.
Nous résumons l’ensemble des facteurs de la dimension "Quoi" dans la Table 2.2. Pour
cette dimension, nous nous positionnons dans un cadre où les systèmes doivent être réactifs
(le client pouvant potentiellement poser des contraintes fortes de disponibilité d’un service),
mais pour lesquels un temps d’arrêt pour effectuer de l’évolution est prévisible. Nous traitons
des évolutions réactives, dans le sens où elles sont déclenchées par un changement dans les
besoins du client, et ne sont pas le fruit d’une adaptation à l’environnement. De part le
contexte technologique des SOA, l’exposition du système est ouverte, donnant de par le
couplage lâche et l’aspect modulaire des services la possibilité de l’étendre. Enfin, nous nous
positionnons dans un contexte d’évolution dont nous assurons la sûreté à la conception, par
le biais d’une analyse.
Table 2.2 – Taxonomie d’une évolution : la dimension "Quoi".
Quoi
Disponibilité Dynamisme Exposition Sûreté
Toujours disponible Réactif Ouvert Statique
Temps d’arrêt acceptable Proactif Fermé Dynamique
Indifférent
Le "Quand" de l’évolution :
Cette dimension s’intéresse aux caractéristiques temporelles d’une évolution. Plus particulièrement,
les auteurs étudient dans cette dimension les propriétés suivantes :
– le moment au cours duquel une évolution peut survenir (à la conception, à la compilation,
ou à l’exécution)
– l’historique des évolutions. Cette caractéristique permet de savoir s’il est possible
d’appliquer plusieurs évolutions en concurrence. En effet, avec l’augmentation de la
taille des systèmes, la taille des équipes de développement a également augmenté,
décentralisant ainsi le développement et de fait les évolutions. On distingue ici trois
cas : les évolutions peuvent être prises de manière séquentielle, c’est à dire qu’il n’est
pas possible d’appliquer une évolution tant qu’une autre évolution est en cours, de
manière parallèle synchrone, où ici, le développement des évolutions peut être effectué
202.3. Évolution des systèmes logiciels
indépendamment, mais leur application concrète est réalisée à un point précis dans le
temps, ou encore de manière parallèle asynchrone, où le développement et l’application
des évolutions sont indépendants. Ce dernier cas est complexe à gérer, dans le sens
où l’aboutissement à un système incohérent est possible, sans pouvoir effectuer une
analyse lors du point de synchronisation, comme cela est possible dans la deuxième
méthode.
– la fréquence de l’évolution, à savoir si le système étudié évolue fréquemment de sorte
que des périodes de temps d’arrêt du système sont à prévoir, ou non. On distingue
ici une évolution continue, où le système est en perpétuel changement, une évolution
périodique, où les évolutions sont appliquées de manière régulière, ou encore arbitraire,
où les évolutions sont effectuées à un rythme irrégulier et peu soutenu.
Nous résumons l’ensemble des facteurs de la dimension "Quand" dans la Table 2.3.
Nous traitons dans cette thèse des évolutions subvenant au moment de la conception. De
part l’ensemble des problématiques liées à l’historique d’une évolution, nous nous focalisons
sur des évolutions entrant dans une logique d’application séquentielle. Enfin, la fréquence
n’influençant pas la nécessité du maintien de la qualité de service, nous traitons les évolutions
qu’elles soient à fréquence soutenue, ou plus disparates dans le temps.
Table 2.3 – Taxonomie d’une évolution : la dimension "Quand".
Quand
Moment Historique Fréquence
Conception Séquentiel Continue
Compilation Parallèle synchrone Périodique
Exécution Parallèle asynchrone Arbitraire
Chargement
Le "Comment" de l’évolution :
Cette dimension s’intéresse à la manière dont l’évolution est opérée. Pour cela, les auteurs
étudient les facteurs suivants :
– le degré d’automatisation de la mise en œuvre de l’évolution. Une évolution peut être
complètement automatisée, notamment dans le cadre des systèmes auto-adaptatifs,
partiellement automatisée, où l’équipe de développement décrit les modifications à
apporter dans un langage d’évolution, laissant au moteur d’évolution la tâche d’appliquer
ces modifications sur les différents documents formant le système, ou manuelle,
entraînant l’équipe de développement à modifier à la main tous les documents, en
prenant à bien garde à garder un système cohérent.
– le degré de formalité de la mise en œuvre de l’évolution. Ici, il s’agit de caractériser à
quel degré de formalisme est exprimée une évolution. Par exemple, une évolution peut
être effectuée de manière ad-hoc (i.e., sans aucun support), ou dans un formalisme
mathématique tel que la réécriture de graphe, permettant ainsi de pouvoir s’intéresser
à des propriétés de propagation de changement ou de re-factoring.
– le support du processus d’évolution. Il s’agit de savoir ici si l’évolution s’effectue de
manière manuelle, ou bien si un ou plusieurs outils viennent accompagner le développeur
de l’évolution pour automatiser certaines tâches.
– le type de changement, à savoir s’il s’agit d’un changement structurel ou comportemental.
Dans le premier cas, on modifiera les fonctionnalités par un ajout ou une
212.4. Conclusion
Table 2.4 – Taxonomie d’une évolution : la dimension "Comment".
Comment
Degré d’automatisation
Formalisme Support du processus Type de changement
Automatisé Ad-hoc Aucun Structurel
Partiellement automatisé
Formalisme mathématique
Re-factoring Sémantique
Manuel Analyse d’impact
suppression de paramètres ou de fonctions. Dans le deuxième, il s’agit de la modifi-
cation de la logique fonctionnelle du programme. À noter ici que ces deux critères ne
sont pas mutuellement exclusifs : une évolution est le plus souvent à la fois structurelle
et comportementale.
Nous résumons l’ensemble des facteurs de la dimension "Comment" dans la Table 2.4.
Nous traitons dans cette thèse des évolutions partiellement automatisées, dans le sens où
elle ne sont pas le fruit d’une auto-adaptation. Nous cherchons à faire évoluer des processus
métiers, en nous appuyant sur un langage pour exprimer ces évolutions. Ce langage nous
permettra de raisonner dans une logique des graphes. Enfin, nos évolutions, à la fois structurelles
et comportementales, seront analysées dans le but de déterminer son impact sur la
qualité de service.
2.4 Conclusion
Dans ce chapitre, nous avons présenté le contexte de cette thèse, en étudiant successivement
les architectures orientées services, la qualité de service et la notion d’évolution. Lors
de l’étude de ces domaines, nous avons émis un certain nombres d’hypothèses, que nous
récapitulons dans la Table 2.5. Cette thèse s’inscrit dans un contexte de développement
d’applications orientées services. Ici, les logiciels développés sont notamment modulaires et
autonomes. Afin de pouvoir différencier plusieurs services aux fonctionnalités similaires, la
notion de qualité de service peut être utilisée comme indicateur de comparaison. Enfin, ces
systèmes répondants à des besoins changeants de la part de l’utilisateur, il est nécessaire de
prévoir des évolutions semi-automatisées, subvenant à la conception, dans le but de pouvoir
les analyser pour savoir si, après leur application, la qualité de service est maintenue dans
le système.
222.4. Conclusion
Table 2.5 – Récapitulatif des hypothèses de travail.
Architectures Orientées Services
Hypothèse 1 Nous étudions l’évolution dans le contexte des services. Les entités étudiées,
nommées services, peuvent être distribuées. Nous considérons
qu’ils sont modulaires, que leur localisation est transparente vis-à-
vis de l’équipe de développement, et que leur couplage est lâche.
Qualité de Service
Hypothèse 2 Pour toutes les propriétés que nous étudions, il existe au moins une
méthode permettant de déterminer la valeur de propriété d’un service.
Hypothèse 3 Dans un système, les besoins en terme de qualité de service sont définis
à l’aide d’un contrat de qualité de service. Le plus souvent, ils sont
représentés sous la forme d’une SLA.
Évolution
Hypothèse 4 Les évolutions que nous considérons dans cette thèse s’opèrent au niveau
de l’implémentation du système. Elles sont définies au niveau
de granularité de la réalisation d’un processus métier, c’est-à-dire au
niveau des activités qui le constitue.
Hypothèse 5 Lorsqu’une évolution est appliquée, nous considérons qu’un temps
d’arrêt du système est acceptable. Cette évolution est réalisée en ré-
action à un changement dans les besoins de l’utilisateur. L’analyse de
la validité de l’évolution est effectuée de manière statique.
Hypothèse 6 Le processus d’évolution est effectué au moment de la conception.
Nous considérons dans notre cas que les évolutions sont appliquées de
manière séquentielle, i.e., qu’à tout moment du cycle de vie, il y a
au plus une évolution en train d’être appliquée. La fréquence de ces
évolutions, elle, n’importe peu.
Hypothèse 7 Une évolution, si elle est appliquée de manière automatique sur le
système, est déclenchée par un acteur humain. Il peut s’agir de changements
structurels, ou sémantiques. Pour supporter ce processus
d’évolution, nous cherchons à effectuer une analyse d’impact de son
effet sur le reste du système.
23Chapitre 3
État de l’art
Sommaire
3.1 Processus de développement . . . . . . . . . . . . . . . . . . . . . . 25
3.1.1 Les processus de développement généralistes . . . . . . . . . . . . . . 26
3.1.2 Les processus de développement spécialisés SOA . . . . . . . . . . . 27
3.1.3 Prise en compte de la Qualité de Service . . . . . . . . . . . . . . . . 28
3.1.4 Prise en compte de l’évolution . . . . . . . . . . . . . . . . . . . . . 28
3.1.5 Comparatif et limitations . . . . . . . . . . . . . . . . . . . . . . . . 29
3.2 Analyse d’impact . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
3.2.1 Fondements de la causalité . . . . . . . . . . . . . . . . . . . . . . . 29
3.2.2 Application de la causalité : les analyses d’impact . . . . . . . . . . 30
3.2.3 Analyse d’impact pour la qualité de service . . . . . . . . . . . . . . 32
3.2.4 Comparatif et limitations . . . . . . . . . . . . . . . . . . . . . . . . 32
3.3 Conclusion de l’état de l’art . . . . . . . . . . . . . . . . . . . . . . 33
N
ous avons vu dans le chapitre 2 que les applications à base de services avaient pour
particularité de devoir être réactives face aux changements des besoins des utilisateurs,
tout en ayant une préoccupation particulière pour la QoS. Dans ce contexte, l’équipe en
charge du système doit mettre en place une stratégie pour faire évoluer le logiciel, tout en
prenant en compte le maintien de la qualité de service. Dans ce chapitre, nous dressons
dans un premier temps l’état de l’art des processus de développement logiciel. Puis, nous
étudions la notion d’analyse d’impact comme possibilité d’établir l’effet d’une évolution sur
le reste du système.
3.1 Processus de développement
Nous présentons dans cette section l’état de l’art concernant les processus de développement.
Pour étudier les différents travaux, nous nous focalisons sur les critères suivants :
– Agilité : le critère d’agilité est le minimum requis pour pouvoir effectuer des évolutions
de manière continue. On considèrera ainsi que dans un processus de développement
agile, le côté itératif et incrémental peut être vu comme une évolution.
– Collaboration : nous étudions ici des systèmes complexes où plusieurs expertises au
niveau de l’élaboration de services, de processus métiers, d’évolution ou de qualité de
service sont requises. Il est donc important qu’une place soit accordée à ces rôles dans
le processus de développement.
– Prise en compte de la QoS : le but d’une équipe de développement est de produire
un logiciel fonctionnel. La qualité de service n’est pas forcément considérée comme
une préoccupation principale ; il s’agira de voir si elle est intégrée au sein du processus
de développement.3.1. Processus de développement
Dans la suite, nous considérons dans un premier temps les processus de développement
généralistes. Puis, nous nous centrons sur les processus orientés SOA, et étudions ceux qui
prennent en compte la qualité de service et l’évolution. Enfin, nous effectuons un comparatif
des différentes approches.
3.1.1 Les processus de développement généralistes
Les processus de développement ont pour rôle de guider l’équipe de développement dans
la réalisation de logiciels. Il existe de nombreux processus de développement, chacun ayant
ses avantages et ses inconvénients. Pour la plupart, ils sont construits autour des mêmes
grandes étapes, comme référencées dans l’ISO 12207 [IEEE 2008] :
– Analyse des besoins : au cours de cette étape, les besoins du client sont identifiés
(par exemple à l’aide d’un diagramme de cas d’utilisation UML) et consignés dans un
cahier des charges.
– Conception : l’architecte logiciel conçoit une solution en se basant sur les besoins
collectés précédemment. Ici, il s’agit d’une solution à haut niveau d’abstraction. L’architecte
décrit ce qui doit être réalisé, sans donner les détails de comment le réaliser.
– Implémentation : l’équipe de développement se base sur la conception de l’architecte
pour écrire le code du logiciel.
– Vérification et validation : une fois la solution logicielle développée, l’étape suivante
consiste à vérifier que l’on a bien implémenté le logiciel, i.e., que le logiciel ne
présente pas de bogue. Cette phase se nomme "vérification" du logiciel. On s’assure
également que l’on a implémenté le bon logiciel, i.e., que le comportement du logiciel
correspond aux besoins du client. Dans ce cas, on parle de validation du logiciel.
– Déploiement : enfin, l’étape de déploiement consiste à installer le logiciel sur la
machine de production, pour pouvoir être utilisé.
Parmi les processus de développement les plus utilisés, nous retenons le modèle en cascade
[Royce 1970], comme étant le déroulement séquentiel des étapes listées ci-dessus. Un
autre processus est le modèle en V [IABG 1997], développé dans les années 80 par la République
Fédérale d’Allemagne, qui est une extension du modèle en V. Ici, au lieu de considérer
les étapes de manière séquentielle, une association est faite entre les étapes de réalisation, et
les étapes de test, afin de pouvoir les mener en parallèle, et de renforcer leur cohérence. Ces
approches sont dites en cascade : le client établit en amont du projet un certain nombre de
besoins fonctionnels et non fonctionnels. Le porteur du projet déclenche alors le début du
cycle de développement choisi. S’en suit le déroulement des différentes étapes, pour aboutir
à la production d’un logiciel correspondant aux besoins établis. Toutefois, ce genre d’approche
a été vivement critiqué, principalement pour un manque de réactivité vis-à-vis des
besoins du client. Pour pallier ce genre de problème, de nouveaux cycles de développement
ont été proposés. C’est le début des méthodes dites agiles [Beck 2001] : ici, l’accent est
porté sur la livraison fréquente et le retour d’expérience, par le biais de méthodes dites
itératives, l’équipe en charge de réaliser le logiciel exécute plusieurs fois le processus de
développement, et incrémentales, où chaque itération augmente les fonctionnalités du logiciel
réalisé [Larman 2003]. Le client est désormais au centre du processus, là où il n’était
consulté auparavant qu’en début et en fin de projet, permettant ainsi d’éviter de réaliser
un logiciel trop éloigné des besoins. Parmi les méthodes agiles, nous retiendrons l’Extreme
Programming (XP) [Beck 2004], le Rationale Unified Process (RUP) [Kruchten 2004] ainsi
que la méthode Scrum [Schwaber 2004], qui font partie des méthodes de développement les
plus utilisées à ce jour.
263.1. Processus de développement
Pour positionner les processus de développement par rapport à la notion d’évolution, les
cycles de développement agiles sont les plus à même à en supporter les différents mécanismes
liés. En effet, le caractère itératif et incrémental des méthodes agiles permet une réalisation
naturelle de l’évolution, là où les cycles de développement classiques, de par leur long dé-
roulement, nécessite soit d’interrompre le déroulement classique du cycle pour prendre en
compte l’évolution, soit d’attendre la fin d’une itération pour prendre en compte l’évolution.
Dans le premier cas, cela peut engendrer des problèmes de consistance, par exemple en abandonnant
momentanément le développement en cours pour s’occuper de l’évolution. Dans le
second cas, cette approche ne permet pas d’être réactif face aux besoins de l’évolution. Les
approches agiles sont donc les plus à même de supporter l’évolution.
3.1.2 Les processus de développement spécialisés SOA
Selon les principes énoncés dans le chapitre 2, la construction de logiciels basés sur
des architectures orientées services diffère des systèmes traditionnels, notamment dans le
sens où la notion de réutilisabilité est prépondérante. Pour cela, de nombreux travaux ont
tenté d’adapter des processus de développement généralistes aux architectures orientées
services. Ceux-ci sont comparés dans les études de Ramollari et al., et de Shahrbanoo et al.
[Ramollari 2007, Shahrbanoo 2012]. Nous retiendrons ici les travaux de Papazoglou et al.,
qui ont développé un certain nombre de recommandations pour l’élaboration d’un processus
de développement pour les SOA [Papazoglou 2006]. Leur processus de développement agile
est constitué de six étapes :
– Planification : l’étape initiale consiste à étudier la faisabilité de la mise en œuvre
d’une solution à base de services. Il s’agit dans un premier temps d’établir les besoins
de l’utilisateur. Également, c’est dans cette phase que l’équipe de développement prendra
garde à s’assurer que la solution à développer s’intègrera dans un environnement
existant.
– Analyse et conception : Il s’agit de la première étape du cycle de développement.
Ici, on établit l’existant en énumérant les différents services, et en revenant potentiellement
sur les besoins de l’utilisateur pour identifier quels sont les services en place,
et quels sont les services à développer ou à faire évoluer.
– Construction et test : au cours de cette étape, on reprend les besoins identifiés dans
l’étape précédentes pour concevoir, réaliser et tester de nouveaux services et processus
métiers. Il s’agira de déterminer parmi l’ensemble des besoins quels services devront
être réalisés, réutilisés, ou composés.
– Approvisionnement : cette étape cherche à établir l’équilibre entre les services
fournis et leur offre en termes de propriétés. Ici, l’équipe s’intéresse à l’établissement
de contrats (de type SLA), en déterminant quel niveau de qualité peut être fourni,
comment il peut être monnayé à une potentielle entreprise, et quel usage doit être fait
du service pour garantir le niveau de qualité spécifié.
– Déploiement : une fois que les nouveaux services ont été validés, ils peuvent être
déployés et être promus au niveau des autres organisations potentiellement intéressées.
– Exécution et Contrôle : enfin, les nouveaux services peuvent être exécutés. S’il est
nécessaire, des contrôles (notamment de la qualité de service) peuvent être enclenchés,
afin de pouvoir collecter des données sur la qualité du système, et amorcer ainsi la
réflexion d’une autre boucle de développement.
La méthode de développement nommée "Service-Oriented modeling and Architecture"
(SOMA) est une autre approche développée par IBM [Arsanjani 2008]. Cette approche a
273.1. Processus de développement
la particularité de mettre en évidence les rôles nécessaires pour la réalisation d’un logiciel
à base de services. La méthode est constituée de sept activités assez similaire à l’approche
de Papazoglou et al..
La différence principale entre ces approches et les approches généralistes résident dans la
notion de réutilisation, mais également la notion de niveau de service fourni. Ainsi, certaines
actions, comme par exemple l’implémentation, diffèrent des approches généralistes de par
la sélection de services existants.
3.1.3 Prise en compte de la Qualité de Service
Si les cycles de développement se focalisent dans un premier temps sur la livraison
d’un logiciel fonctionnel correspondant au cahier des charges établi, tous ne considèrent pas
la qualité de service dans leurs préoccupations. Toutefois, certains travaux ont consisté à
dériver des processus de développement existants pour y inclure la qualité de service.
Par exemple, Koziolek et al. [Koziolek 2006] ont dérivé le cycle de développement RUP
pour intégrer la QoS dans les différentes étapes du développement de logiciels à base de
composants. Ce processus a notamment pour but d’aider l’architecte à choisir parmi des
composants sur l’étagère, en utilisant la QoS comme critère de comparaison. Comme RUP,
leur nouveau processus est itératif et incrémental, permettant aux développeurs de proposer
de nouveaux composants à chaque itération. Toutefois, chaque itération implique une revérification
complète de l’architecture. Cette approche identifie quatre rôles de référence :
l’expert du domaine, le responsable du déploiement du système, l’architecte du système, et
le développeur de composants.
Gatti et al. proposent également de prendre compte des propriétés de qualité comme
le temps d’exécution pire-cas à travers l’ensemble du cycle de développement [Gatti 2011].
Dans leur approche, chaque étape est guidée par des éléments émanant de l’étape précé-
dente, dans le but d’assurer la traçabilité d’une propriété de l’étape des besoins jusqu’à
l’exécution.
3.1.4 Prise en compte de l’évolution
Tous les processus de développement ne prennent pas en compte explicitement l’évolution
comme une de leurs étapes. Il est évidemment possible de considérer dans un processus
de développement itératif que l’itération est une évolution. Toutefois, il est également possible
de considérer l’évolution comme une étape à part entière, en allouant également un
temps pour analyser les effets de l’évolution sur le reste du système [Lewis 2010].
Il existe différents processus prenant en compte l’évolution comme une étape à part
entière : Kijas et al. ont développé un processus d’évolution pour les architectures orientées
services [Kijas 2013]. Pour cela, ils ont réalisé un modèle d’évolution de manière empirique,
en s’appuyant sur les différents scénarios que l’on peut rencontrer dans la modification
d’un système à base de services. Par exemple, la création d’un service entraîne d’autres
opérations, telles que la publication de l’interface de ce service. De là, ils analysent l’effet
de l’évolution sur le reste du code, en se reposant sur ces scénarios.
Kim et al. proposent une approche fondée sur le tissage d’aspect pour établir et faire
évoluer un système à base de services [Kim 2010]. Pour cela, ils se basent sur des réseaux
de Pétri et sur la séparation des préoccupations par aspects pour établir une évolution, sur
laquelle leur outil est en mesure d’effectuer des analyses de performance.
283.2. Analyse d’impact
Table 3.1 – Comparatif des différents processus de développement.
Rôles Support de la QoS Support de l’évolution Agilité
[Koziolek 2006] Oui Oui Non Oui
[Gatti 2011] Non spécifiés Oui Non Non
[Papazoglou 2006] Non spécifiés Oui Non Oui
[Kijas 2013] Non spécifiés Non Oui Non indiqué
[Kim 2010] Non spécifiés Oui Oui Oui
3.1.5 Comparatif et limitations
Le Table 3.1 regroupe les différents processus de développement que nous avons pré-
sentés. Nous effectuons la comparaison selon les points suivants :
– Rôles : nous pouvons voir ici qu’une minorité de processus intègre la notion de
rôles ; mais si un rôle est défini, aucun des travaux ne prévoit dans le processus de
développement des points de rencontre explicite où les rôles sont amenés à collaborer.
– Support de la QoS : de par l’importance donnée à la qualité de service dans les
fondements des architectures orientées services, presque tous les processus s’intéressent
à la qualité de service. Toutefois, si la majorité des processus supporte la qualité de
service, il est important de s’intéresser à la manière donc la QoS est étudiée. En effet,
pour chaque évolution, une complète réévaluation du niveau global de QoS du système
est effectuée. Si cette pratique permet d’obtenir le résultat escompté, bon nombre des
analyses effectuées sont ré-exécutées de manière arbitraire, sans porter attention au
fait que l’élément analysé n’a peut être pas été affecté par l’évolution.
– Support de l’évolution et agilité : seuls les travaux les plus récents ont choisi
de considérer l’évolution au sein du cycle de développement. Des cinq processus de
développement que nous étudions, seul le processus développé par Gatti et al. n’est
pas un processus agile, et avec un manque d’information sur le processus de Kijas et
al.. En mettant en perspective ce critère avec le support de l’évolution, nous pouvons
voir que tous à l’exception du processus de Gatti et al. ont une possibilité plus ou
moins évidente de réaliser une évolution du logiciel, que ce soit en considérant une
itération du processus, ou en l’exprimant de manière explicite.
Nous venons d’effectuer une comparaison des différents processus de développement.
De tous ces processus, aucun ne satisfait l’ensemble des critères nécessaires au maintien de
la QoS lors de l’évolution. De manière plus spécifique, chacun de ces processus considère
une re-vérification complète de la QoS du système pour chaque évolution, sans essayer de
cibler les éléments affectés par l’évolution. Pour pallier ce genre de problème, il s’agit de
considérer les techniques d’analyse d’impact.
3.2 Analyse d’impact
3.2.1 Fondements de la causalité
La notion de causalité est un principe trans-disciplinaire, touchant à la fois la physique,
les mathématiques, la philosophie. Nous retrouvons notamment les origines des concepts de
cause et de conséquence dès les dialogues de Platon, dans les récits d’Artistote, ou encore
dans le Discours de la méthode de Descartes.
Les travaux de Judea Pearl ont posé les fondements de la causalité, en les formalisant
d’un point de vue logique [Pearl 2000]. En accord avec ses travaux, nous parlons dans ce
293.2. Analyse d’impact
document de relation de dépendance causale (ou relation causale en abrégé) entre deux
éléments A et B, noté A −→ B, signifiant le fait que A est une cause de B, ou que B est la
conséquence de A.
De ces fondements, la notion d’analyse causale est apparue, introduisant des valeurs
probabilistes pour représenter la potentialité d’une relation causale. Ces travaux reposent
notamment sur l’établissement du modèle causal à l’aide d’un réseau Bayésien et de chaines
de Markov [Spohn 2001].
Le besoin d’effectuer une analyse d’impact pour comprendre une évolution a déjà été
évoqué dans les travaux de Papazoglou [Papazoglou 2011], où l’auteur explique que ce genre
d’analyse serait nécessaire pour prédire et réduire le sous-ensemble des éléments impactés,
et comprendre concrètement l’effet de l’évolution.
3.2.2 Application de la causalité : les analyses d’impact
Les théories établies dans la section précédente ont une applicabilité directe dans l’étude
de systèmes logiciels. En 2002, Moe et al. ont motivé le besoin d’étudier la causalité au sein
de systèmes distribués, dans le but de résoudre certains problèmes liés à la compréhension
de l’effet du système, d’un sous-système, ou même d’un message [Moe 2002]. Parmi ces
problèmes, on retiendra notamment la découverte de goulots d’étranglement. Dans la suite
de ce paragraphe, nous nous focalisons sur la causalité lié à un changement opéré dans un
système, en présentant différentes techniques permettant de déterminer son impact. Nous
les classons en deux catégories, à savoir les méthodes d’analyse de causes racines, et les
méthodes d’analyse de l’impact du changement.
Analyse des causes racines
La détermination de la ou les causes à l’origine d’un phénomène est une discipline
connue sous le nom d’analyse des causes racines (root cause analysis en anglais). Elle a été
formalisée dans les années 80 [Busch 1986] dans le contexte du département de l’énergie.
L’objectif des analyses de causes racine est, partant d’une situation établie (le plus souvent
un problème rencontré), d’obtenir les causes de cette situation. Il s’agit d’une approche
réactive, dans le sens où on cherche à remonter à l’origine d’un problème. On opposera
ainsi les approches réactives aux approches proactives, où la cause est connue, et où on
cherche à en prédire les conséquences.
Les analyses de causes racines fonctionnent en quatre temps [Rooney 2004] :
– Collecte de données : afin de pouvoir établir les causes du changement, il est
nécessaire de comprendre concrètement ce qu’il se passe dans le système. Pour cela,
il s’agit d’établir son état courant, c’est à dire l’état dans lequel se trouve chacun des
éléments qui le constituent, mais également l’ensemble des événements l’ayant mené
à cet état.
– Tracé des facteurs de causalité : en partant des informations collectées, il s’agit
de dresser une cartographie des différentes influences entre les éléments. Il s’agit le
plus souvent d’un diagramme de séquence, où les différents événements jouent le
rôle de garde et où la séquence représente la chaîne de causalité. Ainsi, une fois que
le diagramme est tracé, un ensemble de branches apparaît, menant au nœud final
correspondant à l’état courant.
– Identification des causes racines : une fois que tous les facteurs causaux ont été
intégrés au diagramme, un diagramme de décision, appelé carte des causes racine, est
établi pour identifier la ou les causes ayant mené à l’état courant. Cette carte permet
303.2. Analyse d’impact
d’établir comment, à partir d’une cause éloignée, par un effet de cascade, le système
a pu aboutir à son état courant.
– Recommandations : enfin, une fois que les causes racines sont établies, l’analyse
préconise une ou plusieurs actions à effectuer pour éviter à l’avenir de se retrouver
dans cet état.
Une manière de représenter les résultats de l’analyse s’effectue à l’aide des diagrammes de
Pareto. Dans ces diagrammes, l’ensemble des causes dont le problème émane est représenté
en colonnes, classées par ordre décroissant de probabilité d’implication sur la conséquence.
Les diagrammes de Pareto font partie, avec le diagramme en arêtes de poisson, des sept
outils à utiliser pour contrôler la qualité [Tague 2004].
Si cette catégorie de méthode permet d’établir un diagnostic face à un problème, tel
que la dégradation de propriété de qualité de service par exemple [Ben Halima 2008], elle
ne s’inscrit cependant pas complètement dans le cadre de cette thèse. En effet, nous avons
pour objectif de maintenir la qualité de service tout au long du cycle de vie du logiciel. Or,
ce genre de méthode se positionne davantage dans la situation où la qualité de service n’est
plus maintenue.
Analyse de l’impact du changement
L’analyse de l’impact du changement (change impact analysis en anglais) s’intéresse à
l’identification des conséquences d’un changement effectué sur un système. Ces méthodes ont
été définis à l’origine par Bohner et Arnold [Bohner 1996] comme étant "The determination
of potential effects to a subject system resulting from a proposed software change". Cette
description générale peut s’appliquer à l’ingénierie logicielle en particulier. On retrouve dans
la littérature de nombreuses applications de ce principe, agissant sur différentes parties du
cycle de vie : l’analyse de l’effet sur les phases de collecte des besoins, sur la conception de
la solution, sur son implémentation, et sur la vérification.
Les techniques d’analyse de l’impact du changement n’ont pas pour but unique de se
centrer sur l’effet d’une évolution. Dans leurs travaux, Xiao et al. utilisent ces techniques
pour calculer le coût d’une évolution [Xiao 2007]. En effet, modifier un processus métier
s’accompagne souvent d’une modification des interfaces, voir même de la logique d’implé-
mentation de certains services. Les auteurs effectuent une analyse d’impact sur le processus
métier dans le but de quantifier le coût de l’évolution sur le reste du système. Nous pensons
que cette technique serait une bonne approche si elle pouvait être étendue pour prendre en
compte non pas le coût d’une évolution mais son effet sur la qualité de service.
Cette approche contemplative de l’étude de l’évolution est appliquée de manière active
dans l’outil nommé Morpheus [Ravichandar 2008]. Ici, les auteurs proposent de s’appuyer
sur les relations de dépendance établies pour automatiser l’évolution, en propageant les
changements sur les autres éléments constituant le système.
Analyse des effets d’une évolution
Plusieurs travaux se sont intéressés à l’analyse d’impact de l’évolution d’un logiciel. Par
exemple, Elbaum et al. ont présenté une étude empirique sur l’effet de l’évolution du logiciel
sur les tests de couverture de code [Elbaum 2001]. Ils ont montré que même une modification
minime dans le logiciel peut modifier les instructions au niveau du code, impliquant de le
re-tester. Fondamentalement, nous visons à réaliser le même genre d’approche au niveau
des orchestrations de service, et en se préoccupant principalement de la qualité de service.
313.2. Analyse d’impact
Analyse de l’évolution dans les SOA
L’analyse d’impact, ou la détermination des éléments affectés par un changement, a été
étudiée dans le cadre des processus métiers. Soffer a défini dans ses travaux la notion de
portée du changement, dont l’identification permet de "faciliter l’ajustement du système
face aux changements des processus métiers" [Soffer 2005]. Pour cela, l’auteur dresse une
taxonomie des différentes modifications pouvant être effectuées sur un processus métier :
modification d’un état, modification d’une transition d’état (que ce soit au niveau de la
structure du flot de contrôle, ou d’une potentielle condition de garde), modification des
variables, ou modification totale, en remplaçant le processus métier par un autre.
Partant de cette taxonomie, l’auteur définit quel est le scope de changement pour chacune
des catégories, à savoir le changement contenu (où il n’y a pas de changement indirect),
le changement local, ou encore le changement global.
Le canevas proposé par Ravichandar et al. vise à contrôler l’évolution de processus mé-
tiers [Ravichandar 2008]. Ils établissent les relations entre les différents éléments du système,
et opèrent à la fois sur le code source et sur les descriptions de haut niveau d’abstraction
pour conserver la cohérence du système. Enfin, l’élaboration d’une évolution entraîne grâce
à leur outil une propagation du changement dans l’ensemble de l’architecture. Ces travaux
sont similaires à ceux de Dam et al. [Dam 2010] .
3.2.3 Analyse d’impact pour la qualité de service
Enfin, un certain nombre de travaux ont porté sur l’étude de l’effet d’un changement
sur la qualité de service. Dans le langage CQML+ [Rottger 2003], il existe la possibilité
de représenter les relations de causalité pouvant exister entre les différentes propriétés.
Toutefois, aucun outil, ou aucune application, n’est proposée pour pouvoir déterminer pour
un système donné la chaine de conséquences entre une évolution et son effet sur la qualité
de service. Becker et al. proposent une approche nommée Q-Impress visant à prédire les
conséquences des évolutions, au moment de la conception du logiciel, sur les différents
attributs de qualité. Pour cela, les auteurs se basent sur des modèles de prédiction tels que
les chaînes de Markov ou les réseaux de file d’attente [Becker 2008].
Cicchetti et al. ont développé une approche pour analyser les effets de l’évolution sur
la qualité de service d’applications à base de composants [Cicchetti 2011]. Leur approche
considère une évolution effectuée de manière ad-hoc : l’équipe de développement réalise
une nouvelle version du système, et l’incrément est calculé en effectuant la différence des
modèles architecturaux. En fonction de cette différence, leur outil calcule l’impact de cette
différence selon un ensemble de règles. Toutefois, l’inconvénient de leur approche réside dans
la nécessité de mesurer a priori l’ensemble des valeurs pour pouvoir ensuite déterminer quel
en a été l’impact. Il en résulte une re-vérification complète du système.
3.2.4 Comparatif et limitations
La Table 3.2 regroupe les différents types d’analyse d’impact que nous avons présentés.
Nous effectuons la comparaison selon les points suivants :
– Adaptabilité au contexte : notre contexte circonscrit les domaines des processus
métiers, de la QoS et de l’évolution. Sur l’ensemble des analyses que nous avons étudié,
aucune de ces méthodes ne s’inscrit complètement dans notre contexte, prenant en
compte au mieux deux des trois critères, comme le font Becker et al. ou Cicchetti et
al..
323.3. Conclusion de l’état de l’art
– Identification du sous-ensemble impacté : de par notre analyse précédente, nous
pouvons opposer les méthodes d’analyse des causes racines aux méthodes d’analyse
de l’impact du changement. En considérant que pour garantir le maintien de la QoS
lors de l’évolution, nous avons besoin de déterminer en premier lieu quel est l’impact
de l’évolution, l’analyse des causes racines n’est pas adapté à notre problématique.
– Quantification de l’impact : une fois que l’impact a été déterminé, c’est-à-dire que
l’analyse a identifié quels sont les éléments du système affecté par une évolution, il est
nécessaire de savoir si cet impact est bénéfique ou néfaste du point de vue de la QoS.
Toutes les méthodes d’analyse n’effectuent pas cette vérification cependant, essentielle
pour pouvoir dire si la QoS est maintenue. C’est le cas notamment de Ravichandar et
al., Elbaum et al. ou Rottger et al..
– Coût de l’analyse : enfin, le dernier critère de comparaison consiste à étudier le
coût pour l’utilisateur de l’analyse. Nous cherchons en effet ici à avoir une analyse la
plus automatisée possible, et pour laquelle l’utilisateur sera le moins impliqué. Si la
plupart des méthodes ont un coût important, en terme d’effort de modélisation ou de
temps d’exécution de l’analyse en elle-même, Ben Halima et al. ainsi que Ravichandar
et al. ont un faible coût.
En résumé, aucune approche ne propose une analyse d’impact qui soit à la fois adapté
à notre contexte, faible en coût, et fournissant l’ensemble des informations nécessaires à
garantir le maintien de la QoS lors de l’évolution d’un logiciel.
3.3 Conclusion de l’état de l’art
Nous venons de dresser l’état de l’art en matière de processus de développement et
d’analyses d’impact pour l’évolution. Beaucoup de travaux gravitent autour de ces domaines
depuis de nombreuses années. Il existe de nombreux processus de développement spécialisés
dans la détermination de la qualité de service, dans l’élaboration de systèmes à base de
services, ou incluant l’évolution comme étape du processus.
Nous avons également étudié les travaux portants sur la détermination des effets de
l’évolution en termes d’impact. Là encore, de nombreux travaux existent, s’intéressant à
la cause d’un changement ou à son effet. Ces techniques ont été appliquées à différents
domaines et dans différents contextes.
Dans cette thèse, nous souhaitons maintenir la qualité de service d’un logiciel au cours
de ses différentes évolutions, tout en minimisant la phase de re-vérification. Dans cette
optique, les défis sont :
– faire collaborer les acteurs de l’équipe de développement, en identifiant les
connaissances requises pour le maintien de la QoS lors de l’évolution, et en caractérisant
les moments au cours desquels les acteurs devront collaborer.
– déterminer les interactions au sein d’un logiciel, afin de pouvoir établir le
lien existant entre la modification d’un élément du système et la modification d’une
propriété de qualité de service.
– minimiser la vérification de la QoS, en déterminant les éléments du système
impactés par l’évolution de manière à ne vérifier la QoS que sur ces derniers.
– identifier la cause de la violation d’un contrat de QoS, en appliquant les
techniques d’analyse des causes racines sur le contrat déterminé comme violé.
Dans la suite de ce document, nous présentons nos différentes contributions permettant
d’assurer le maintien de la qualité de service lors de l’application à base de processus métiers.
333.3. Conclusion de l’état de l’art
Nous présentons dans le chapitre 5 un processus de développement, nommé Blink, mettant
en évidence les différentes collaborations entre acteurs. Il s’agit dans un premier temps
d’identifier ces acteurs, et de déterminer à quel moment du processus de développement
une coopération entre acteurs est nécessaire.
Puis, nous nous focalisons dans le chapitre 6 sur le rôle de l’architecte du système. Nous
présentons dans un premier temps comment modéliser un système selon les principes des
architectures orientées services. Nous cherchons pour cela à définir ce qu’est un système, et
quelles sont les informations que l’équipe de développement doit fournir pour établir son
bon fonctionnement. Puis, nous définissons le concept de causalité, à savoir l’influence que
peut avoir un élément d’un système sur un autre élément. À travers la notion de modèle
causal, nous identifions l’ensemble des interactions dans un système, dans le but de pouvoir
déterminer l’effet d’une évolution sur les éléments du système.
Dans le chapitre 7, nous considérons le rôle de l’expert en qualité de service. Après avoir
fourni une définition de la qualité de service, nous présentons un langage de modélisation
d’une propriété de QoS. À partir de la description d’une propriété, nous cherchons alors à
enrichir le modèle causal établi dans le chapitre 6 pour déterminer les interactions entre les
éléments du système et ses propriétés de QoS, et cibler les propriétés de QoS à re-vérifier
lors d’une évolution.
Enfin, dans le chapitre 8, nous nous intéressons au rôle de l’architecte de l’évolution.
Après avoir donné une définition de ce qu’est une évolution, nous présentons un langage
permettant à l’architecte de décrire des évolutions. Puis, nous présentons un outil d’analyse
permettant de déterminer si oui ou non la qualité de service est maintenue une fois
l’évolution appliquée. Le résultat de cette analyse est une chaine de conséquence, rendant
explicite la cause possible du non-maintien de la qualité de service.
L’ensemble des contributions de cette thèse est regroupé au sein de Smile, un canevas
de développement pour le maintien de la qualité de service. Notre canevas regroupe la
réalisation des contributions, en s’inscrivant de pair avec Blink, notre processus de développement
identifiant les interactions entre les expertises de l’équipe de développement, et
en implémentant les différentes contributions propres aux expertises de la modélisation du
système, de la qualité de service et de l’évolution. Ces contributions sont illustrés à l’aide de
PicWeb, notre exemple fil rouge dont la description est réalisée dans le chapitre suivant.
343.3. Conclusion de l’état de l’art
Critères
Adapté aux
processus métiers Adapté à la QoS Adapté à l’évolution Identification du sous-ensemble impacté Quantification de l’impact Coût de l’analyse
Analyses des causes
racines
[Ben Halima 2008]
Non Oui Non Non Oui Bas (analyse de trace)
Analyse de l’impact
du changement
[Ravichandar 2008]
Non Non Oui Oui Non Bas (analyse de dépendance)
Analyse de
l’évolution
[Elbaum 2001]
Non Non Oui Oui Non Élevé (étude empirique)
Analyse de
Processus Métiers
[Soffer 2005]
Oui Non Oui Oui Oui Élevé (taxonomie)
Analyse de
Processus Métiers
[Dam 2010]
Oui Non Non Oui Oui
Moyen
(modélisation du
système nécessaire)
Analyse de la QoS
[Rottger 2003] Non Oui Non Non Non élevé (pas d’outil disponible)
Analyse de la QoS
[Becker 2008] Non Oui Oui Oui Oui
Élevé (besoin de
modèles de
performance
supplémentaires)
Analyse de la QoS
[Cicchetti 2011] Non Oui Oui Oui Oui
Moyen (besoin de
re-vérifier
l’intégralité du
système)
Table 3.2 – Comparatif des différentes analyses d’impact.
35Chapitre 4
Présentation du cas d’étude
Sommaire
4.1 Séduite, un système de diffusion d’informations à base de processus
métiers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
4.2 PicWeb, un processus métier de recherche d’images . . . . . . . 39
4.2.1 Description de PicWeb . . . . . . . . . . . . . . . . . . . . . . . . . 39
4.2.2 Évolution de PicWeb . . . . . . . . . . . . . . . . . . . . . . . . . . 40
C
e chapitre présente PicWeb, un service de recherche d’images provenant de différentes
sources qui correspondent à un mot-clé passé en paramètre. PicWeb est
représenté par un processus métier dont le développement s’est déroulé de manière agile.
Au fil du temps, ce processus métier a évolué pour continuer de correspondre aux besoins
des utilisateurs. Il constitue à ce titre un cas d’étude idéal de par sa taille raisonnable et sa
compréhension aisée pour illustrer les problèmes rencontrés lors de l’évolution d’application
à base de processus métiers. Tout particulièrement, nous montrons ici qu’il est difficile de
garantir le maintien de la qualité de service lors de l’évolution. Nous utilisons PicWeb tout
au long du document pour illustrer l’apport des différentes contributions de cette thèse.
Dans ce chapitre, nous présentons le scénario d’utilisation de PicWeb : nous montrons
comment il s’inscrit dans un système plus large nommé Séduite [Delerce-Mauris 2009] et en
quoi les différentes évolutions de PicWeb ont été source de problèmes pour maintenir la
qualité de service du système.
4.1 Séduite, un système de diffusion d’informations à
base de processus métiers
Séduite est un système de diffusion d’informations à destination du personnel et des
étudiants d’une université. Son origine provient d’un besoin de diffuser sur un campus universitaire
des informations diverses, provenant de sources différentes telles que la scolarité,
le restaurant universitaire, ou encore les différentes associations étudiantes souhaitant communiquer
sur leurs activités. De par l’hétérogénéité du public ciblé, ces informations doivent
être affichables sur des périphériques variés tels que des écrans de contrôle positionnés au
sein de l’institution, des smartphones, ou encore via un site web. La Figure 4.1 illustre
l’interface graphique de Séduite.
Le développement de Séduite a débuté en 2005. Originellement utilisé comme prototype
de recherche à des fins d’expérimentation (il a servi notamment de validation au projet
FAROS 1
), le système prit de l’ampleur suite à l’implication d’une équipe de huit développeurs.
Le système est aujourd’hui constitué de vingt-six services implémentés en Java
et de sept processus métiers implémentés dans le Business Process Execution Language
1. Projet RNTL FAROS, 2005.4.1. Séduite, un système de diffusion d’informations à base de processus
métiers
Figure 4.1 – Utilisation de Séduite au cours de la nuit de l’info.
BPEL [OASIS 2007]. Ces services ont pour tâches de collecter les différentes informations
provenant des différents services administratifs de l’université, mais également de services
web externes. La Figure 4.2 représente l’architecture globale de Séduite.
En huit ans, Séduite a été déployé dans plusieurs institutions. Son développement s’est
effectué de manière agile : en s’appuyant fortement sur les nombreux retours de la part
des utilisateurs, l’implémentation de Séduite a subi de nombreuses évolutions. Nous nous
focalisons dans le cadre de cette thèse sur l’évolution de l’un de ces processus métiers,
nommé PicWeb.
Figure 4.2 – Architecture de Séduite.
384.2. PicWeb, un processus métier de recherche d’images
Activité Activité du
processus métier
Activité Activité modifiée au
cours de l'évolution
Légende:
(a) PicWeb V0
(b) PicWeb V1
Evolution
a1 Keyword:= receive()
Pics[] :=
Picasa:getPics(Keyword) a2
a3 PicsF[] = shuffle(Pics[])
a4 reply(PicsF[])
a1 Keyword:= receive()
PicsPicasa[] :=
Picasa:getPics(Keyword) a2 PicsFlickr[] :=
Flickr:getPics(Keyword) a21
a30 Pics[] := Helper:join(PicsPicasa[], PicsFlickr[])
a3 PicsF[] = shuffle(Pics[])
a4 reply(PicsF[])
a4 a4
Figure 4.3 – Évolutions de PicWeb.
4.2 PicWeb, un processus métier de recherche d’images
De l’ensemble des évolutions de Séduite, le cas des évolutions de PicWeb se dégage
particulièrement. En effet, à l’issue de l’une de ces évolutions, le déploiement de la nouvelle
version entraîna le ralentissement de l’ensemble du système. Nous nous focalisons dans cette
section sur cette évolution, qui nous servira d’exemple tout au long du document.
4.2.1 Description de PicWeb
PicWeb est un processus métier faisant partie de Séduite. Il a pour but d’afficher
sur les écrans de diffusion différentes photos de la vie du campus. Pour cela, le processus
métier interroge des services web de stockage de photos tels que Flickr de Yahoo! ou
encore Picasa de Google, en récupérant les photos correspondant à un mot-clé donné. Le
processus métier récupère ces ensembles de photos et effectue un mélange afin de rendre
l’affichage des photos aléatoire. Par exemple, sur le campus de Lille, PicWeb est utilisé
pour diffuser les photos des différents événements de la vie étudiante.
La Figure 4.3(a) est une représentation de la version initiale de PicWeb selon le formalisme
des diagrammes d’activités d’UML, permettant la description du processus métier. Au
départ, le processus métier récupère les photos correspondant à un mot-clé donné (activité
a1 ). Le processus reçoit le mot-clé, effectue une invocation au service Picasa (activité a2 )
pour récupérer les correspondances, les mélange pour obtenir un ordre aléatoire (activité
a3 ), et les retourne en tant que résultat (activité a4 ).
394.2. PicWeb, un processus métier de recherche d’images
Dans le cadre du développement de PicWeb, l’équipe de développement s’est intéressé
particulièrement à étudier le temps de réponse du service. Concrètement, il s’agissait de
caractériser un appel à un service ou à un processus métier, en mesurant le temps passé
entre la réception du message d’entrée, et l’envoi du résultat en sortie. Ce temps comprend le
temps passé pour l’envoi des messages d’entrée et de sortie (appelé temps de transmission),
et le temps passé pour calculer la réponse (appelé temps de calcul). Pour s’assurer que le
temps de réponse de PicWeb se situait dans un intervalle de temps acceptable, des mesures
ont été effectuées sur l’ensemble du processus. Puis, lors de chaque évolution, l’équipe de
développement considérait uniquement les activités modifiées par l’évolution pour s’assurer
du maintien de la qualité de service pour le temps de réponse.
4.2.2 Évolution de PicWeb
Au cours de son cycle de vie, PicWeb évolua à plusieurs reprises pour répondre aux
changements des besoins des utilisateurs. Nous nous focaliserons dans ce document sur
l’évolution décrite dans la Figure 4.3, car elle montre comment le simple ajout d’un appel
de service peut avoir un impact sur la qualité de service de l’ensemble du processus métier,
voire même du système tout entier. PicWeb évolue pour prendre en considération un
nouveau fournisseur d’images (Flickr), comme montré dans la figure Figure 4.3 (b). Ce
fournisseur est désormais appelé en parallèle de Picasa, avant que le résultat soit concaténé
dans la réponse.
Lors de cette évolution, si les temps de réponse des activités a20, a21 et a30 de la
Figure 4.3(b) présentaient individuellement des valeurs d’un ordre de grandeur attendu,
le déploiement de la nouvelle version de PicWeb révéla une toute autre réalité. En effet, les
temps de réponse de PicWeb, mais également de Séduite dans son ensemble, augmentèrent
de façon significative. Cette augmentation provoqua le ralentissement du système, obligeant
l’équipe de développement à déployer dans l’urgence une version précédente du système.
Il est intéressant de noter ici que la cause du problème ne vient pas directement de
l’évolution mais d’un autre service. Ici, l’appel à Flickr ou au service de concaténation
n’était pas la cause du ralentissement du système. Toutefois, l’augmentation de la taille
des données traitées par l’activité de formatage des images ralentit considérablement son
exécution, causant le ralentissement de l’ensemble du système. En effet, l’implémentation de
l’opération shuffle consiste, pour un ensemble de n éléments donnés en entrée, à effectuer n
2
permutations afin de mélanger l’ensemble. L’évolution appliquée à PicWeb n’a pas modifié
l’implémentation de shuffle ; toutefois, le contenu de la variable Pics, donnée en entrée de
shuffle, est passé de n éléments à 2n. Au niveau de shuffle, l’évolution a entrainé les n
2
permutations à devenir 4n
2 permutations, causant ainsi un ralentissement de l’exécution
de l’opération, de PicWeb et du système dans son ensemble.
De ce fait, il n’est pas raisonnable de limiter l’analyse de l’évolution aux seuls éléments
modifiés dans l’évolution, car cette modification peut avoir des effets indirects sur le reste
du système. Il est donc nécessaire de pouvoir déterminer la relation entre l’évolution et
son effet sur le reste du système, afin de pouvoir qualifier l’effet concret de l’évolution sur
l’ensemble du système.
Ce chapitre vient de présenter le cas d’étude de ce document. Dans le chapitre suivant,
nous présentons les différents problèmes rencontrés au cours de l’évolution de PicWeb.
Nous en extrayons les différents défis liés à l’évolution, avant de donner un aperçu des
contributions de la thèse pour apporter une solution à cette problématique.
40Deuxième partie
ContributionsChapitre 5
Un processus de développement
pour le maintien de la qualité de
service
Sommaire
5.1 Motivations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
5.2 Définition des acteurs . . . . . . . . . . . . . . . . . . . . . . . . . . 44
5.3 Description du processus de développement . . . . . . . . . . . . 44
5.4 Coopération entre acteurs . . . . . . . . . . . . . . . . . . . . . . . 45
5.5 Conclusion du chapitre . . . . . . . . . . . . . . . . . . . . . . . . . 46
C
e chapitre présente notre approche pour guider l’équipe de développement dans
la réalisation d’un système suivant les principes des architectures orientées services,
avec un point de vue particulier pour la qualité de service. Nous identifions tout d’abord les
différents acteurs opérant sur le logiciel, en décrivant leur rôle, et en quoi leurs expertises
propres interviennent dans le maintien de la QoS lors de l’évolution d’un logiciel. Nous
présentons ensuite le cycle de développement en lui-même. Enfin, nous mettons l’accent sur
le besoin d’interactions entre les différents acteurs pour parvenir à maintenir la QoS tout
au long du cycle de vie.
5.1 Motivations
La conception et la réalisation d’un système informatique nécessitent la mobilisation
d’un ensemble de compétences propres à un domaine particulier [IEEE 2008, Tarr 1999].
Nous nous intéressons dans le cadre de cette thèse à la réalisation d’une évolution et au
maintien de la qualité de service d’un système. Si ces deux compétences peuvent être traitées
indépendamment, leur implication dans la réalisation du système entraine des conflits à
prendre en compte. Typiquement, l’évolution de PicWeb et les mesures de son temps de
réponse peuvent être gérées de manière isolée ; toutefois, en agissant de la sorte, l’application
de l’évolution a eu de fait une influence sur la propriété étudiée, ayant ainsi des conséquences
inattendues.
Pour pouvoir contrôler ces conséquences, il est nécessaire d’identifier les influences entre
les différentes expertises, c’est-à-dire les moments dans le cycle de vie d’un logiciel où les
choix techniques et architecturaux réalisés par une expertise donnée auront un impact sur
une ou plusieurs autres expertises. Il s’agit donc dans un premier temps d’expliciter les
compétences existantes, pour ensuite définir les moments dans le cycle de vie où les choix
d’une expertise ont un impact sur une autre expertise, et où une concertation est nécessaire.
Nous avons décidé dans un premier temps d’identifier les compétences requises et de les5.2. Définition des acteurs
affecter à des entités nommées acteurs [Taskforce 2011]. Un acteur est une, ou plusieurs
personnes, responsable d’un ensemble de tâches propres à une préoccupation. Ainsi, une
tâche commune à deux acteurs implique un échange de connaissances entre les deux acteurs,
que ce soit par le biais d’une rencontre, ou encore par un échange de documents et de
données ; c’est ce que l’on appelle un point d’interaction.
Le défi ici est de définir quelles sont les interactions nécessaires entre les différents
membres de l’équipe de développement. Pour cela, nous proposons Blink, un processus de
développement permettant d’ordonner les tâches en étapes, et de définir le but de chaque
tâche. En identifiant les compétences fournies par les acteurs et les compétences requises
pour chaque étape, nous mettons en évidence les interactions nécessaires. Dans la suite de
ce chapitre, nous présentons quelles sont les acteurs gravitant autour de la réalisation d’un
système. Puis, nous introduisons Blink, et détaillons l’ensemble des étapes nécessaires pour
le développement d’un système avec une préoccupation pour la qualité de service. Enfin,
nous explicitons les différentes interactions au sein de l’équipe de développement.
Pour illustrer nos propos, nous nous appuyons sur le cas de l’évolution de PicWeb.
5.2 Définition des acteurs
Au cours du développement et de l’évolution de l’application, différents acteurs interviennent
pour apporter leur expertise propre. Ces acteurs ont un rôle spécifique, et sont
amenés à prendre des décisions modifiant la structure et le comportement du système réalisé.
Dans le contexte de la réalisation de systèmes orientés services se préoccupant de la
Qualité de Service, nous listons dans la Table 5.1 les différents acteurs identifiés, et décrivons
leur rôle. Ces acteurs ont été identifiés en nous inspirant des travaux de Bejaoui et al.
[Bejaoui 2008], de Kajko-Mattson et al. [Kajko-Mattsson 2007], ou encore de Zimmermann
et al. [Zimmermann 2006]. Nous comptons cinq rôles. Parmi eux, un est extérieur à l’équipe
de développement (l’utilisateur). Le dernier rôle est un acteur non humain : il s’agit de notre
canevas de développement, Smile, dont nous présentons les différentes parties tout au long
du document, et dont l’implémentation est décrite dans le chapitre 9.
Nous cherchons maintenant à déterminer la manière dont les acteurs œuvrent pour
réaliser un système. Pour cela, nous répertorions chacune des étapes de Blink, notre processus
de développement. Nous présentons chacune des étapes en décrivant leur rôle dans
le processus global, et les acteurs amenés à y participer.
5.3 Description du processus de développement
Afin d’éviter les problèmes d’influence entre les expertises et de pouvoir définir un système
dont la qualité de service est maintenue au fil du temps, nous identifions dans cette
section les étapes clés du processus de développement, au cours desquelles une mise en commun
des informations et des choix effectués par les acteurs concernés est nécessaire. Pour
définir notre processus de développement, Blink, nous nous sommes inspirés de processus
de développement existants, tels qu’ils sont présentés dans [Papazoglou 2006] ou encore dans
[Kijas 2013]. De ces processus, nous avons conçu Blink, un processus de développement
pour le maintien de la qualité de service à l’évolution. La Figure 5.1 représente le diagramme
d’activités de ce processus de développement. Chacune des étapes est décrite dans
les Tables 5.2, 5.3 et 5.4, accompagnée d’un diagramme selon la spécification SPEM 1
. Ce
processus a été conçu pour réaliser un système de façon itérative et incrémentale, où chaque
1. http://www.omg.org/spec/SPEM/2.0/
445.4. Coopération entre acteurs
Table 5.1 – Rôles intervenants dans la réalisation d’un système.
Utilisateur du système Représente la communauté utilisant le logiciel. Il est responsable
de faire part auprès de l’équipe de développement des nouveaux
besoins, nécessitant de faire évoluer le logiciel.
Architecte du processus
métier
Réalise la logique métier du système au moyen de processus mé-
tiers et de services. Il a une connaissance approfondie du comportement
du système et de la panoplie de services déjà implémentés
qu’il peut utiliser.
Expert en Qualité de
Service
Définit les propriétés de qualité de service. Il a une connaissance
approfondie des propriétés et des outils pour les observer au sein
de n’importe quel système. Il est en mesure de déterminer en cas
de dégradation des valeurs de propriétés les facteurs d’influence
pouvant en être la cause.
Architecte de l’évolution Décrit les évolutions à produire pour modifier le comportement
de système, en accord avec les nouveaux besoins de l’utilisateur.
Il a une connaissance partielle du comportement du système.
Smile Joue le rôle d’interlocuteur avec les autres acteurs de l’équipe de
développement, en leur communiquant par exemple les informations
nécessaires à leurs prises de décisions. Il contient des informations
sur le système, son implémentation, et les différentes
analyses effectuées. Dans le cadre de Blink, Smile automatise
certaines tâches comme l’application de l’évolution au système,
ou encore son analyse.
incrément est une évolution à considérer. Il implique l’ensemble des acteurs du système et
permet, à partir de l’expression de nouveaux besoins de la part de l’utilisateur, de définir
une évolution qui sera analysée afin de s’assurer du maintien de la qualité de service dans
le système post-évolution.
Au cours des différentes étapes, certains acteurs sont amenés à interagir. Nous définissons
dans la section suivante les points d’interaction du processus, où plusieurs expertises sont
nécessaires pour accomplir des tâches communes.
5.4 Coopération entre acteurs
Le but de cette section est de mettre en évidence les coopérations entre les différents
acteurs. Il s’agit de définir pour un point d’interaction à quel moment celui-ci intervient
dans le processus de développement, quels acteurs sont nécessaires, et quelles informations
ils vont échanger. Nous distinguons trois points d’interaction, indiqué sur la Figure 5.1
par un titre d’étape souligné :
– Évolution des besoins : au cours de cette étape, l’utilisateur et l’architecte du
système collaborent ensemble pour établir le plus précisément possible les nouveaux
besoins. Il en résulte une spécification des besoins.
– Définition de l’évolution : pour pouvoir définir une évolution, l’architecte de cette
évolution a pour tâche de proposer une modification qui satisfera les besoins spécifiés.
Pour cela, la collaboration de l’architecte du système et de l’architecte de l’évolution
consiste à la mise en commun des besoins, une spécification des besoins, guidée par la
455.5. Conclusion du chapitre
0 - Import initial
du système
1 - Évolution
des besoins
2 - Définition
de l'évolution
3 - Analyse
de l'évolution
4 - Vérification des
éléments affectés
6 (b) - Annulation
de l'évolution
6 (a) - Application
de l'évolution
5 - Diagnostic et
prise de décision
décision='ok' décision='¬ ok'
Figure 5.1 – Schéma du processus de développement Blink.
connaissance pointue du système que l’architecte du système a acquis depuis le début
du projet.
– Diagnostic et prise de décision : une fois que l’architecte de l’évolution a conçu une
modification, et que l’expert en qualité de service l’a analysée, il s’agit de mettre en
commun ces deux expertises dans le but de dresser un diagnostic. Pour cela, l’expert en
qualité de service apporte les différentes mesures effectuées : l’architecte de l’évolution
est en mesure de les interpréter, afin de comprendre pourquoi une évolution a violé un
contrat de qualité de service, le cas échéant. Cette coopération a pour but de faciliter
le diagnostic, dans l’optique de l’écriture d’une nouvelle évolution qui ne violera pas
de contrat de qualité de service.
En se basant sur ces différentes coopérations, nous mettons en évidence à quel moment
du cycle de vie il est important d’unir plusieurs expertises, évitant ainsi un cloisonnement
des acteurs de l’équipe de développement.
5.5 Conclusion du chapitre
Nous venons de présenter Blink, un processus de développement pour gérer le maintien
de la qualité de service à l’évolution. Pour atteindre cet objectif, nous avons établi
un ensemble d’acteurs, et défini leur rôle dans la réalisation d’un système logiciel. Notre
processus est constitué d’un ensemble d’étapes, pour lesquelles le ou les acteurs impliqués
sont désignés. De plus, cette répartition des rôles tout au long du processus de développe-
465.5. Conclusion du chapitre
0 - Import initial du système
0 - Import initial
du système
Description
Système
Description
Système SMILE
Architecte
Système
<> <
![[TXT]](http://www.audentia-gestion.fr/icons/text.gif){kind=icon}