Réf : 2009/II/...

Soutenu à la session de Juin 2009

Université de la Manouba
ECOLE NATIONALE DES SCIENCES DE L’INFORMATIQUE

RAPPORT
De Mémoire de Fin d’Etudes

Présenté en vue de l’obtention du titre

d’INGENIEUR EN INFORMATIQUE

Par

SABRI Boubaker

Sujet :
Développement d’une plateforme d’intégration continue évolutive

Encadré par :
M. Sabri MTIBAA
Ingénieur d’application

Responsable : Supervisé par :

M. Giuseppe di GIORE M. Hechmi Abouda
CPT Manager Enseignant (ENSI)

Organisme :
STMicroelectronics
Cité Technologique La Gazelle 2088 Ariana
Tel :(216) 71 857 750 Fax : (216) 71 857 525
 Remerciements

Je tiens à exprimer ma gratitude à M. Sabri MTIBAA, ingénieur à STMicroelectronics, pour

la qualité de son encadrement , pour l’expérience enrichissante et pleine d’intérêt qu’il m’a fait
vivre durant ces quatre mois au sein de STMicroelectronics et pour ses conseils précieux.

Je remercie encore M. ABOUDA Hechmi, enseignant à l’ ENSI, pour son support pertinent
et fort précieux.

J’adresse mes sincères remerciements à M. Jean-Marc BOUCHE, chef d’équipe à STMi-

croelectonics, pour la qualité de son suivi, pour son accueil sympathique et sa coopération
professionnelle tout au long de ces quatre mois.

Et finalement, j’adresse mes remerciements aux membres du jury pour m’avoir honoré en
acceptant d’évaluer ce travail.
 Table des matières

Introduction générale 1

1 Cadre du projet 3

1.1 Présentation de l’organisme d’accueil . . . . . . . . . . . . . . . . . . . . . . 3

1.2 Présentation du sujet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

1.2.1 Problématique . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

1.2.2 La plateforme d’intégration continue . . . . . . . . . . . . . . . . . . . 7

1.2.3 Les objectifs de l’intégration continue . . . . . . . . . . . . . . . . . . 8

1.2.4 Travail demandé . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

1.3 La méthodologie adoptée . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

1.3.1 Les méthodes agiles . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

1.3.2 Pratiques différenciatrices des méthodes agiles . . . . . . . . . . . . . 10

1.3.3 Le choix de la méthodologie SCRUM . . . . . . . . . . . . . . . . . . 11

2 Etude de l’existant 13

2.1 Etude de l’existant : analyse et critiques . . . . . . . . . . . . . . . . . . . . . 13

2.2 Serveur d’intégration continue . . . . . . . . . . . . . . . . . . . . . . . . . . 13

2.2.1 Hudson . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

2.2.2 CruiseControl . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
TABLE DES MATIÈRES iv

2.2.3 Rational Build Forge . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

2.3 La Solution proposée . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

2.3.1 Tableaux comparatif . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

2.3.2 Synthèse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

3 Spécification et analyse des besoins 21

3.1 Besoins fonctionnels . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

3.1.1 Les fonctionnalités du point de vue administrateur . . . . . . . . . . . 21

3.1.2 Les fonctionnalités du point de vue utilisateur . . . . . . . . . . . . . . 22

3.2 Besoins non fonctionnels . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

3.3 Diagramme des cas d’utilisation . . . . . . . . . . . . . . . . . . . . . . . . . 24

3.3.1 Diagramme de cas d’utilisation de la configuration de CruiseControl . . 24

3.3.2 Diagramme de cas d’utilisation de management de CruiseControl à dis-

tance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

3.3.3 Diagramme de cas d’utilisation du dashboard : cas d’un simple utilisateur 27

4 Conception 29

4.1 Conception générale . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

4.1.1 Architecture générale . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

4.1.2 Diagramme de composants . . . . . . . . . . . . . . . . . . . . . . . . 32

4.2 Conception détaillée . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33

4.2.1 Conception des composants de la plateforme . . . . . . . . . . . . . . 33

4.2.2 Les diagrammes de séquences . . . . . . . . . . . . . . . . . . . . . . 41

5 Réalisation 45

5.1 Environnement de travail . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45

5.1.1 Configuration matériel . . . . . . . . . . . . . . . . . . . . . . . . . . 45

TABLE DES MATIÈRES v

5.1.2 Choix de la plateforme Java Entreprise Edition (JEE) . . . . . . . . . . 45

5.1.3 Configuration logicielle . . . . . . . . . . . . . . . . . . . . . . . . . 46

5.2 Travail réalisé . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47

5.2.1 Le point d’entrée . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48

5.2.2 Consultation des statuts . . . . . . . . . . . . . . . . . . . . . . . . . 50

5.2.3 Les graphes des résultats . . . . . . . . . . . . . . . . . . . . . . . . . 51

5.2.4 L’interface d’administration . . . . . . . . . . . . . . . . . . . . . . . 53

5.3 Tests et intégration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55

5.3.1 Déploiement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55

5.3.2 Test . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55

5.3.3 Résultats . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55

5.4 Chronogramme . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56

Conclusion générale 58

Netographie 62

A Subversion 64

A.1 Définition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64

A.2 Installation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64

A.3 Utilisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65

B Web services 66

B.1 Définition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66

B.2 Avantages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67

B.3 Inconvénients . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
 Liste des figures

1.1 Structure d’un compilateur . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

1.2 Plateforme d’intégration continue . . . . . . . . . . . . . . . . . . . . . . . . 8

3.1 Diagramme de cas d’utilisation de la configuration de CruiseControl . . . . . . 24

3.2 Diagramme de cas d’utilisation de management de CruiseControl à distance . . 25

3.3 Diagramme de cas d’utilisation du dashboard : cas d’un simple utilisateur . . . 27

4.1 Architecture de la plateforme d’intégration continue évolutive . . . . . . . . . 30

4.2 Diagramme des composants de la plateforme . . . . . . . . . . . . . . . . . . 32

4.3 Diagramme de classe Cruise Control . . . . . . . . . . . . . . . . . . . . . . . 34

4.4 Dependencies.xml . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36

4.5 Diagramme de navigation du dashboard . . . . . . . . . . . . . . . . . . . . . 37

4.6 Diagramme de classe du contrôleur . . . . . . . . . . . . . . . . . . . . . . . . 38

4.7 Illustration de la DVP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40

4.8 Diagramme de séquence pour un simple utilisateur . . . . . . . . . . . . . . . 41

4.9 Diagramme de séquence pour la configuration . . . . . . . . . . . . . . . . . . 42

4.10 Diagramme de séquence pour l’invocation à distant . . . . . . . . . . . . . . . 43

5.1 Page d’accueil du dashboard . . . . . . . . . . . . . . . . . . . . . . . . . . . 48

5.2 Page des résultats de la validation . . . . . . . . . . . . . . . . . . . . . . . . 50

LISTE DES FIGURES vii

5.3 Graphe des résultats des tests . . . . . . . . . . . . . . . . . . . . . . . . . . . 51

5.4 Graphe d’évolution de la validation d’un composant . . . . . . . . . . . . . . . 52

5.5 Tableau de résultats des tests . . . . . . . . . . . . . . . . . . . . . . . . . . . 53

5.6 Interface de la configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . 54

 Liste des tableaux

2.1 Tableau comparatif : informations générales . . . . . . . . . . . . . . . . . . . 16

2.2 Tableau comparatif : outils de controle compatibles . . . . . . . . . . . . . . . 16

2.3 Tableau comparatif : gestion de la compilation . . . . . . . . . . . . . . . . . 17

2.4 Tableau comparatif : sécurité . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

2.5 Tableau comparatif : interface web . . . . . . . . . . . . . . . . . . . . . . . . 18

2.6 Tableau comparatif : installation et configuration . . . . . . . . . . . . . . . . 18

2.7 Tableau comparatif : outils de la compilation . . . . . . . . . . . . . . . . . . . 19

5.1 Chronogramme . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
Signatures des encadrants

M. SABRI Mtibaa
STMicroelectronics

M. HECHMI Abouda
ENSI
 Introduction générale

Améliorer la qualité des logiciels est le désir légitime de toute personne s’intéressant à la pro-
grammation informatique en général et au génie logiciel en particulier. L’adoption de bonnes
pratiques tout au long du développement contribue à la pertinence du produit final. En outre,
l’intégration continue permet de mettre en évidence les anomalies existantes dans un produit
d’une façon continue ou quotidienne afin accélérer le développement en ignorant la phase
d’intégration final classique.

L’intégration continue permet de réduire les coûts liés à la résolution des anomalies, sous
réserve de réaliser des tests. Les changements susceptibles d’avoir apporté une erreur étant
limités, les corrections sont largement facilitées .Il s’ensuit un gain de temps au niveau du
développement par élimination des sessions intensives de déboguage, les problèmes étant
résolus le jour même de leur détection.

C’est dans ce cadre que se situe le sujet de notre projet de fin d’études effectué à STMi-
croelectronics au sein de l’équipe ’Compiler Expertise Center’ (CEC) qui vise à concevoir une
plateforme d’intégration continue évolutive gérant les dépendances entre différents composants
des projets développés dans l’équipe.

A cet effet, il nous a été demandé d’étudier, de modifier et de concevoir les différents com-
posants de cette plateforme en assurant le maintien du contrôle et de la supervision. Le présent
document décrit en détails la progression du projet s’étalant sur cinq chapitres.Le premier cha-
pitre présente le cadre général à savoir le contexte du travail et la problématique du projet. Le
INTRODUCTION GÉNÉRALE 2

second chapitre sera consacré à l’étude de quelques solutions et des outils existants assurant
l’intégration aussi bien que l’évaluation de leur efficacité et conformité à nos besoins.
Le chapitre suivant aborde les spécifications de notre approche dans l’intégration en décelant
ses fonctionnalités. La description des étapes de la conception générale et détaillée relatives à la
nouvelle plateforme d’intégration continue est présentée dans le quatrième chapitre. La partie
réalisation est abordée dans le cinquième chapitre. Le rapport se termine par une conclusion
qui établit le bilan du travail et dresse les perspectives concernant les voies d’amélioration de
l’approche adoptée.
 1
CHAPITRE

Cadre du projet

Dans ce chapitre, nous mettons notre projet dans son contexte le plus général. Nous
commençons par présenter l’organisme d’accueil, ensuite nous décrivons brièvement le projet.
Enfin, nous présentons les méthodologies et les technologies suivies.

1.1 Présentation de l’organisme d’accueil

STMicroelectronics (souvent appelée simplement ST) est une société internationale de droit
hollandais mais d’origine franco-italienne, qui développe, fabrique et commercialise des puces
électroniques (semi-conducteurs). Elle est un des tout premiers acteurs mondiaux du secteur
économique de la production de semi-conducteurs.

La société est née de la fusion en 1987 de la société italienne SGS (Società Generale Se-
miconduttori), alors dirigée par Pasquale Pistorio, et de la société française Thomson Semi-
conducteurs, filiale de Thomson.
Initialement nommée SGS-Thomson, elle a ensuite été renommée STMicroelectronics en 1998
suite au retrait de Thomson du capital.

La société mère STMicroelectronics N.V. est de droit hollandais (enregistrée à Amsterdam),

la direction administrative est regroupée en grande partie sur le site de Genève en Suisse, mais
la direction opérationnelle du groupe est toujours italienne, implantée sur le principal site du
groupe à Agrate à coté de Milan. En dehors des sites franco-italiens d’origines, ST possède aussi
de nombreux sites partout dans le monde : Singapour, Delhi, Arizona et aussi Tunisie. Le site de
CHAPITRE 1. CADRE DU PROJET 4

ST Tunis a été créé en décembre 2001. Il développe des logiciels d’applications électroniques,
des microcontrôleurs et des microprocesseurs informatiques et automobiles. Il contribue au
développement d’un grand nombre de circuits intégrés destinés aux applications grand public,
numérique, tels que les décodeurs, les lecteurs DVD et les appareils photos numériques.
Le site de ST Tunis a commencé avec 9 ingénieurs et continue d’afficher une forte croissance
avec, en avril 2008, 300 ingénieurs répartis dans plusieurs équipes collaborant avec des divisions
dans des sites en France, en Italie et en Angleterre.[4]

L’équipe qui nous a recueilli toute au long la durée de stage est l’équipe de Centre d’Expertise
en Compilation (CEC) qui est implémenté à : Tunis, Grenoble, Bristol et Crolles. Les projets
développés au sein de l’équipe CEC sont des compilateurs C et C++ destinés à la commercia-
lisation et l’utilisation par d’autres divisions de la société, la production et la maintenance des
outils industriels destinés aux applications embarquées au sein de STMicroelectronics :
• Les compilateurs C et C++.
• Les assembleurs et les compresseurs de code.
• Les librairies mathématiques ainsi que les librairies C et C++.
Deux technologies open-source sont utilisées pour développer les compilateurs des projets prin-
cipaux de l’équipe :
• Open64 (http ://www.open64.net) pour les processeurs de la famille ST200 et STxP70.
• GNU gcc (http ://gcc.gnu.org) pour les processeurs de la famille ST40.
D’autres technologies propriétaires sont également utilisées pour le développement des compi-
lateurs de projets de moindre envergure.

Les compilateurs nécessitent l’alliance des plusieurs composants dont :

• Le Front-end. Il produit une représentation intermédiaire du programme source. Typique-
ment, un front-end se compose de trois outils :
- un analyseur lexical qui transforme les chaı̂nes de caractères du fichier source en une
séquence de mots du langage compilé.
- un analyseur syntaxique qui vérifie que les séquences de mots sont correctes vis-à-vis
de la syntaxe du langage. Le programme est alors transformé en une représentation in-
termédiaire à laquelle est associée une table des symboles qui mémorise les identifiants
CHAPITRE 1. CADRE DU PROJET 5

du programme ainsi que leurs attributs.

- un analyseur sémantique qui détermine si le code intermédiaire vérifie les règles sous
contexte du langage (identification des noms, typage, ...).
• L’optimiseur de haut niveau. Les optimisations de haut niveau sont effectuées sur la
représentation intermédiaire. Le but est de minimiser les actions à réaliser tout en
préservant la sémantique. .
• Le générateur de code. Le code intermédiaire optimise est traduit en langage de bas ni-
veau, le langage assembleur. En général cette traduction se compose de deux étapes plus
ou moins couplées : la sélection d’instructions et l’allocation des ressources..
• L’optimiseur de bas niveau. Le code assembleur (ou pseudo assembleur) obtenu est en-
suite optimisé. C’est ce que l’on appelle la phase d’optimisation de bas niveau qui ap-
plique les optimisations dites tardives ou optimisations à la lucarne, généralement liées
au flot de contrôle ainsi qu’au langage assembleur. [AR1]

Figure 1.1 — Structure d’un compilateur

1.2 Présentation du sujet

Avant de détailler le sujet, une vision générale sur l’intégration continue nous parait indis-
pensable afin de mieux comprendre le cadre général de projet.
CHAPITRE 1. CADRE DU PROJET 6

1.2.1 Problématique

Le développement logiciel au sein d’une équipe composée de plusieurs développeurs est une
tâche qui devient de plus en plus complexe au fur et à mesure de l’importance des projets gérés,
lesquels sont eux-mêmes constitués de composants interdépendants.
Lorsqu’un développeur décide d’appliquer un changement à l’un des composants d’un pro-
jet, il part d’une copie du code de référence. Comme les modifications sont progressivement
ajoutées, cette copie devient de plus en plus incompatible avec les composantes de projet. Le
développeur a alors la responsabilité de synchroniser son travail avec les derniers changements
avant de pouvoir délivrer ses ajouts. Plus il y a de changements, plus le travail d’intégration des
propres changements du développeur sera long et compliqué et susceptible d’entrer en conflit
avec les modifications d’autres développeurs.
Dans la pire des situations, l’intégration devient tellement complexe que sa durée excède le
temps de développement lui-même . D’où le besoin d’un procédé qui gère l’intégration des
différentes composants du projet pour remédier à ces deux problèmes : la complexité et le long
temps d’intégration. Ce procédé est le système d’intégration continue.
L’intégration continue est un principe qui consiste à réaliser le mécanisme d’intégration des
différents composants d’un logiciel aussi souvent que possible c’est-à-dire dès qu’un chan-
gement est validé par un développeur sur l’ensemble des projets gérés par une ou plusieurs
équipes. [RM3]
L’intégration nécessite l’utilisation :
• d’un système de contrôle de version qui centralise toutes les sources des différents pro-
jets et gère les notions liées à l’attribution des versions (branches, différences entre deux
versions d’un même fichier, ...) avec surveillance des changements apportés par chaque
développeur.
• d’un mécanisme de construction des logiciels qui permet de construire le logiciel dans sa
globalité à l’aide d’une simple commande (ant, maven).
• d’un système de tests auto-validants qui s’assure du bon développement de l’application
par rapport à ses besoins.
• d’un système de reporting publiant les résultats de la construction et de l’intégration des
CHAPITRE 1. CADRE DU PROJET 7

différentes composants.

1.2.2 La plateforme d’intégration continue

La plateforme se compose de quatre unités :

• les postes des développeurs, avec les différents outils traditionnels de développement
(IDE, outils de modélisation de base de données...).
• l’environnement de test à destination du client .Ce dernier valide le bon développement
de l’application par rapport à ses besoins.
• l’environnement de pré-production (déploiement) pour tester la version finale de l’appli-
cation. Il reproduit à l’identique l’environnement de production (nombre de machines,
processeurs, mémoires, versions des applications, ...). Il permet de réaliser les tests de
charge et de valider la bonne exécution de l’application lors du passage en production.
• le serveur SCM (Source Control Management) comme ClearCase ou Subversion. Il cen-
tralise toutes les sources des différents projets et gère les notions liées au versionning
(branches, différences entre deux versions d’un même fichier, ...).
En fait, l’intégration continue est un processus d’automatisation de tâches récurrentes liées à
ces environnements de développement. Les plus connues sont :
• construction (”build”) de l’application à partir des données contenues dans le SCM. Cela
comprend la compilation des sources et la construction des releases (JAR, WAR, EAR,
.Out ...).
• déploiement de l’application sur l’environnement de développement (copie des librairies,
configuration et redémarrage).
• exécution des tests unitaires et d’intégration.
• génération de rapports et envoi des mails aux différents membres du projet.
CHAPITRE 1. CADRE DU PROJET 8

Figure 1.2 — Plateforme d’intégration continue

1.2.3 Les objectifs de l’intégration continue

L’un des principaux avantages de l’intégration continue est qu’elle permet de déterminer
l’ensemble des anomalies dans un projet d’une manière continue et à la volée. Sans intégration
continue, les bugs d’intégration sont très difficiles à localiser car le problème ne vient pas d’une
personne en particulier mais de l’interaction du travail de plusieurs personnes provenant par-
fois d’equipes différentes ce qui fait de l’intégration une étape un peu délicate. Les anoma-
lies peuvent souvent avoir été intégrées des semaines, voire des mois, avant d’être détectées
et localisées : ils en deviennent d’autant plus difficiles à retracer et à corriger sans déstabiliser
CHAPITRE 1. CADRE DU PROJET 9

l’ensemble de l’application.

Grâce à l’intégration continue, une grande majorité des anomalies dues à des problèmes d’in-
teraction est résolue le jour même. En outre, nous repérons immédiatement dans la majorité des
cas où l’interaction a eu lieu. Cela réduit considérablement le champ de recherche du bug.
Il nous parait indisponsable de citer d’autres objectifs de l’intégration continue nous paraissent
indispensables de les citer comme :
• La mise à jour permanente, au minimum quotidienne, de l’environnement. De fait, une
version fonctionelle est toujours disponible pour un test, une démonstration ou une distri-
bution.
• La connaissance en temps réel de l’avancement du projet par le responsable du projet.
• La réactivité des équipes de développement en cas de code incompatible ou manquant.
• La réduction des coûts liés à la résolution des bugs, sous réserves de réaliser des tests.
Les changements susceptibles d’avoir apporté une erreur étant limités, les corrections
sont largement facilitées.
• Le gain de temps au niveau du déploiement du développement. Nous éliminons les ses-
sions intensives de débogage, les problèmes étant résolus le jour même.
• La connaissance plus concrète de l’état d’avancement du développement par les membres
de projet.

1.2.4 Travail demandé

Le travail demandé consiste à concevoir et implémenter une plateforme d’intégration conti-

nue évolutive gérant les dépendances entre projets pour l’équipe CEC basée sur l’outil open
source CruiseControl et utilisant un outil de distribution des tâches permettant la distribution de
l’ensemble de tâches de l’intégration.
Ceci suppose le passage par différentes étapes :
• La première étape consiste à étudier l’architecture de la plateforme.
• La deuxième étape consiste à modifier code du projet open source CruiseControl pour
qu’il supporte la gestion des dépendances entre les différents composants d’un projet.
CHAPITRE 1. CADRE DU PROJET 10

Dans notre cas, il s’agira de projets de développement de compilateur.

• La troisième étape consiste à raffiner l’interface de reporting et de monitoring des
différentes tâches gérer par CruiseControl.
Une fois la plate-forme réalisée, elle doit être déployée pour faciliter le déroulement du proces-
sus de l’assurance de la qualité dans les logiciels/composants développés.

1.3 La méthodologie adoptée

1.3.1 Les méthodes agiles

Les méthodes Agiles sont des procédures de conception de logiciel qui se veulent plus prag-
matiques que les méthodes traditionnelles. En impliquant au maximum le demandeur (client),
ces méthodes permettent une grande réactivité à ses demandes, visent la satisfaction réelle du
besoin du client et non des termes du contrat de développement. La notion de méthode agile a
été officialisée en 2001 par un document Manifeste Agile (Agile Manifesto) signé par 17 per-
sonnalités impliquées dans l’évolution du génie logiciel et généralement auteurs de leur propre
méthode. Parmi les différentes méthodes agiles on peut citer :[6]

• Rapid Application Développment (RAD)

• Dynamic systems development method (DSDM)
• Extreme programming (XP)
• Adaptive software development (ASD)
• Feature Driven Development (FDD)
• Scrum

1.3.2 Pratiques différenciatrices des méthodes agiles

La différence entre les méthodes agiles se manifeste juste dans un nombre limité des tech-
niques complémentaires.
Les techniques différenciatrices les plus marquantes sont :
• RAD : recommande la variabilité de la taille et de la maturité des groupes de travail en
CHAPITRE 1. CADRE DU PROJET 11

fonction des phases du projet afin d’optimiser l’engagement des ressources et de préserver
leur intérêt par un travail adapté à leurs préoccupations. L’organisation performante des
réunions est basée sur un mode opératoire des entretiens et sur des techniques de valida-
tion permanente.
• DSDM : la méthode DSDM se particularise par la spécialisation des acteurs du projet
dans une notion de ” rôles ”. Ainsi, l’on trouvera dans les réunions DSDM des sponsors
exécutifs, des ambassadeurs, des utilisateurs visionnaires, des utilisateurs conseillers, sans
oublier l’animateur-facilitateur et des rapporteurs.
• XP : (extrême programming) est très axé sur la partie Construction de l’application.
Une de ses originalités réside dans l’approche de planification qui se matérialise sous
la forme d’un jeu intitulé Planning game et qui implique simultanément les utilisateurs
et les développeurs. On notera aussi des techniques particulières liées à la production du
code comme la programmation en binôme (Pair programming), l’appropriation collective
du code, la refactorisation (refactoring) et l’intégration continue. [7]
• FDD : pour FDD, la particularité nommée Mission Focused réside dans une forte orien-
tation vers un but immédiat mesurable guidé par la notion de valeur métier. C’est en fait
l’ambition globale d’une itération qui se trouve ainsi renforcée. Cet aspect se retrouve
aussi dans la méthode RAD sous la forme des objectifs de Focus ou dans Scrum dans la
notion de Sprint. FDD préconise aussi le Features Driven Development. Cette technique
se caractérise par des notions de Feature et de Features set (fonctionnalités et groupes de
fonctionnalités).[8]
• Scrum : La méthode Scrum affirme sa différence dans des pratiques de courtes réunions
quotidiennes (Stand-Up ou Scrum daily meeting). Ces temps de travail commun ont
pour objectifs d’améliorer la motivation des participants, de synchroniser les tâches, de
débloquer les situations difficiles et d’accroı̂tre le partage de la connaissance.[9]

1.3.3 Le choix de la méthodologie SCRUM

Le principe de base de Scrum est de focaliser l’équipe de façon itérative sur un ensemble de
fonctionnalités à réaliser, dans des itérations de durée fixe de une à quatre semaines, appelées
CHAPITRE 1. CADRE DU PROJET 12

Sprints. Chaque Sprint possède un but à atteindre, défini par le directeur de produit, à partir
duquel sont choisies les fonctionnalités à implémenter dans ce sprint. Ce que nous a poussé à
choisir cette méthode durant notre stage est le fait qu’un sprint aboutit toujours sur la livraison
d’un produit partiel mais fonctionnel. Cela nous a beaucoup aidé à tester au fur et à mesure la
qualité de nos produits. De plus, cette méthode nécessite une communication permanente avec
le client d’où la livraison des produits valides par rapport aux besoins du client et vérifiés en
terme de qualité à cause du concept de démonstration défini dans Scrum.

Conclusion

Après avoir présenté le cadre général de notre projet, et introduit à notre plateforme
d’intégration continue. Nous allons dans ce qui suit entamer une étude de l’existant pour mieux
comprendre le cadre et l’environnement du projet.
 2
CHAPITRE

Etude de l’existant

Afin d’atteindre les objectifs de notre projet, l’étude des solutions existantes et des différents
moyens mis à notre disposition est une étape inévitable. En fait, elle permet d’abord de
décortiquer les fonctionnalités déjà développées et surtout de mettre en relief leurs limites.
Ensuite nous pouvons dégager les solutions envisageables qui peuvent faire face aux problèmes
liées aux solutions existantes.

2.1 Etude de l’existant : analyse et critiques

Au début de notre stage, les développeurs de l’équipe CEC utilisent déjà l’intégration conti-
nue par le biais de l’outil Cruise Control. Le principal inconvénient de cet outil, outre son
affichage lent lors de la présence de nombreux projets, est l’absence de la prise en compte des
dépendances entre composants d’un compilateur. Cette prise en compte est l’objet de ce stage.

Cependant, avant de développer un tel module de dépendances, il nous a semblé intéressant

d’évaluer les principales solutions disponibles sur le marché afin, éventuellement, de proposer
une migration à l’équipe CEC vers un outil plus pratique.

2.2 Serveur d’intégration continue

Un serveur d’intégration continue permet d’automatiser la reconstruction régulière d’une

application afin de détecter le plus régulièrement possible des régressions potentielles. Le ser-
veur d’intégration continue va régulièrement récupérer la dernière version du code source et
CHAPITRE 2. ETUDE DE L’EXISTANT 14

exécuter des scripts de construction, plus potentiellement des jeux de tests automatisés, voire
même déployer l’application. L’équipe projet est alors notifiée automatiquement par mail des
problèmes détectés. Il existe un grand nombre d’outils d’intégration continue, avec des fonc-
tionnalités plus ou moins larges. Certains sont payants et un bon nombre est gratuit et/ou open-
source.[5]

2.2.1 Hudson

Hudson est un outil open source d’intégration continue écrit en Java, fonctionnant dans un
conteneur de servlets tels qu’Apache Tomcat, ou en mode autonome avec son propre serveur
Web embarqué.
Il s’interface avec des systèmes de gestion de versions tels que CVS et Subversion, et exécute
des projets basés sur Apache Ant et Apache Maven aussi bien que des scripts arbitraire en shell
unix ou batch Windows.
Les générations de projets peuvent être initiées par différents moyens, tels que des mécanismes
de planification similaires au cron, des systèmes de dépendances entre générations, ou par des
requêtes sur certaines URL spécifiques. L’interface web est simple à utiliser et assez intuitive,
la prise en main est très rapide. On peut réellement configurer l’intégration continue d’un projet
existant en quelques minutes sans connaı̂tre l’outil. [10]

2.2.2 CruiseControl

CruiseControl est un projet open-source et gratuit offrant de multiples fonctionnalités pour

l’intégration, que ce soit pour des développements Java ou .Net. CruiseControl se place comme
client d’un outil de gestion de versioning tel que SVN ou CVS.
Lorsqu’un développeur valide les modifications effectuées sur un fichier, une nouvelle version
est créée sur le serveur de sources. CruiseControl met ainsi à jour régulièrement une copie locale
des sources, puis automatise régulièrement la compilation de l’application via un script Nant ou
MsBuild.
Une fois la compilation effectuée, un message est envoyé aux personnes ayant effectuées des
commits depuis la dernière build. En pratique, cela permet de disposer d’une version binaire du
CHAPITRE 2. ETUDE DE L’EXISTANT 15

programme au fil des modifications.

CruiseControl s’installe également avec tableau de bord (dashboard). Un dashboard est une
sorte de rapport sur l’ensemble des actions relevées par l’atelier d’intégration continue. Son
rôle consiste à afficher le journal des évènements de l’usine de build pour produire un résultat
compréhensible par les développeurs. Dans sa version Web (Web Dashboard), CruiseControl
produit un site Web en récupérant les informations provenant des différents plug-ins utilisés
(test unitaires, contrôle qualité, couverture des exigences, etc. ). A noter qu’il est aisément
possible de personnaliser ce dashboard pour l’intégrer dans un site ” Unifié ” à l’échelle du
projet.[11]

2.2.3 Rational Build Forge

IBM Rational Build Forge Enterprise Edition est serveur d’intégration continue qui auto-
matise les processus de livraison de logiciels grâce à une structure adaptable de gestion des
générations d’exécutables qui permet aux équipes de développement de normaliser les tâches
répétitives, de gérer la conformité aux réglementations officielles et de partager l’information.
Il s’intègre facilement dans un environnement de travail et appuie les principaux langages de
développement, les scripts et sur différentes plateformes La solution prend en charge les équipes
de développement distribuées via une interface Web centralisée, accessible quasiment partout
et à tout moment.[12]

2.3 La Solution proposée

2.3.1 Tableaux comparatif

Pour mieux choisir entre les différents outils d’intégration continue, nous allons présenter
des tableaux des comparaisons dont chacun porte sur un aspect qui nous parait important.
CHAPITRE 2. ETUDE DE L’EXISTANT 16

Informations générales :

Info BuildForge CruiseControl Hudson

Origine IBM ThoughtWorks java.net
open source non oui oui
langage d’implémentation ? java java
gratuit non oui oui

Tableau 2.1 — Tableau comparatif : informations générales

Les outils de controle compatibles :

Scm Support BuildForge CruiseControl Hudson

bitKeeper non non oui
ClearCase oui oui oui
CVS oui oui oui
Dimensions oui non non
FileSystem oui oui non
Git non oui oui
HttpFiel oui oui oui
StarTeam oui oui oui
Svn oui oui oui
TeamfoundationSever oui oui oui

Tableau 2.2 — Tableau comparatif : outils de controle compatibles

CHAPITRE 2. ETUDE DE L’EXISTANT 17

La gestion de la compilation :

Gestion de la compilation BuildForge CruiseControl Hudson

compilation paralelle oui oui oui
compilation distrubuée non non non
compilation forcée oui oui oui
compilation declenchée par SCM oui oui oui
compilation temporelle oui oui oui
gestion de dependances non non non
compilation stoppée non non oui
historique de la compilation oui non non
Proactif non non ?

Tableau 2.3 — Tableau comparatif : gestion de la compilation

La sécurité :

Security BuildForge CruiseControl Hudson

authentification oui oui oui
régime d’authorisation oui non oui
LDAP Integration oui non oui
Single Sign On oui ? ?
JAAS oui ? ?

Tableau 2.4 — Tableau comparatif : sécurité

CHAPITRE 2. ETUDE DE L’EXISTANT 18

L’interface web :

Web interface BuildForge CruiseControl Hudson

View changesets oui oui oui
Add new projects oui non oui
Clone projects oui non oui
Delete projects oui non oui
Modify projects oui oui oui
Kill builds no oui oui

Tableau 2.5 — Tableau comparatif : interface web

Installation et configuration :

Installation and Configuration BuildForge CruiseControl Hudson

Windows installer oui oui oui
Self contained distribution oui oui oui
platforme d’execution Win32 JVM JVM
Project platform Java Java+Ant/Maven/NAnt Any language
outil prèferé Any Ant,Maven Any
modification de script de build oui oui oui
multiple projects oui oui oui
configuration automatique non non oui

Tableau 2.6 — Tableau comparatif : installation et configuration

CHAPITRE 2. ETUDE DE L’EXISTANT 19

Les outils de la compilation :

Directly supported build tools BuildForge CruiseControl Hudson

Shell / command script yes yes yes
Ant oui oui oui
Groovy oui non oui
maven oui oui oui
maven2 oui oui oui
make oui non non
msbuild oui ? oui
nant oui oui oui
rake oui ? oui
Visual Studio (’devenv’) non non non
FinalBuilder non non non

Tableau 2.7 — Tableau comparatif : outils de la compilation

2.3.2 Synthèse

Après une étude fine et prolongée des ces différentes outils d’intégration continue, nous avons
conclu que :
-Pour Rational Build Forge. Le fait qu’il soit payant, qu’il ne gère pas les dépendances inter
projets et même qu’il ne soit pas open source pour que nous puissions le modifier et ajouter
notre propre module de gestion des dépendances nous incite à éliminer cet outil bien qu’il
dispose de nombreuses fonctionnalités dont avons besoin.
-Pour Hudson. Hudson est encore un produit jeune. D’autre part, il ne s’intègre qu’avec CVS
ou Subversion (facteur très limitant car l’outil de controle des versions ClearCase est aussi
utilisé au sein de STMicroelectronics. Ceci fait que nous ne retenons pas cet outil malgré toutes
CHAPITRE 2. ETUDE DE L’EXISTANT 20

ses facilités d’installation et d’emploi. Il apparaı̂t donc que l’outil Cruise Control reste un bon
compromis entre facilité d’utilisation, configuration et évolutivité grâce à :
• sa gestion de nombreux outils de contrôle des versions dont ceux utilisés à STMicroelec-
tronics comme CVS, Subersion ou ClearCase.
• la possibilité de gérer plus types de projets tels que Ant, Maven, C/C++, Shell.
• son support actif (documentation, mailing list).

Nous choisissons CruiseControl pour être un cur de toute une plateforme écrite en java utili-
sant des technologies dérivées du Java comme les services web, la programmation avec l’RMI
(Remote Method Invocation), les technologies du standard MVC (Model, View, Controler)
voire JSF (Java Server Faces) et le traitement des données écrites sous format XML.

Conclusion

Après avoir donné une vision globale sur l’existant et choisi la solution proposée, dans le
chapitre suivant nous allons analyser notre plateforme et détailler les différentes spécifications.
 3
CHAPITRE

Spécification et analyse des

besoins

La réussite d’un projet dépend du soin avec lequel nous avons effectué les phases d’analyse
et de spécification. C’est pourquoi il est fondamental, au cours de ces phases, de déterminer
l’adéquation entre les besoins exprimés des utilisateurs et les traitements envisagés.
Plus l’analyse de cette détermination sera fine, plus grande sera la réussite de l’application et
son utilité future.
Pour assurer cet objectif, il est donc essentiel que nous parvenions à une vue claire des différents
besoins escomptés de notre projet.

3.1 Besoins fonctionnels

3.1.1 Les fonctionnalités du point de vue administrateur

L’administrateur de CruiseControl est l’acteur principal de notre système d’intégration

continue . Il est responsable de l’ajout d’un projet au système d’intégration ainsi que le sui-
vie des différentes étapes de validation et d’exécution depuis l’ajout jusqu’à l’obtention d’une
version finale ou release.
La mission du responsable d’intégration se résume aux tâches suivantes :
• La création d’un script qui permet de lancer la validation dans sa globalité par une simple
commande.
• - L’ajout du projet au fichier de configuration de CruiseControl :
CHAPITRE 3. SPÉCIFICATION ET ANALYSE DES BESOINS 22

Définition de l’emplacement du projet dans les systèmes de controle des versions.

Fixer la période d’attente avant la vérification des modifications au sein d’un projet.
Définition du fichier contenant l’information sur le statut de validation du projet.
Définition de l’emplacement des fichiers logs contenant les résultats de la validation.
Définition de l’emplacement des artefacts ou des releases après la phase de la validation
• La définition des dépendances du projet avec d’autres projets s’il y en a.
• La configuration du dashboard (interface web de publication des résultats) avec Cruise-
Control pour qu’il pointe sur les derniers fichiers logs.
• La maintenance du système d’intégration continue en cas de défaillance.
• La suppression d’un projet du système dans le cas de sa terminaison.
Chaque projet ajouté au système d’intégration continue et pendant sa durée de vie peut avoir
plusieurs statuts :
• Stopped : le projet est exclu de la boucle de validation.
• Pending : le projet est en attente pour entrer dans la boucle de validation.
• Building : le projet est encours de compilation (validation).
Pour faciliter la gestion de ces différents statuts, nous avons choisi de construire un outil en ligne
de commande qui permet l’administration de CruiseControl d’une manière élégante, facile et à
distance .Cet outil écrit en Java est basé sur la technologie RMI (Remote Method Invocation).
Il permet également de :
• sortir un projet de la boucle de validation (stop Project).
• activer un projet et l’ajouter à la boucle (run Project).
• compiler ou valider un projet en attente (build Project).
• obtenir la status d’un projet (status Project).

3.1.2 Les fonctionnalités du point de vue utilisateur

Notre système d’intégration permet à un simple utilisateur, qui peut être un chef de projet ou
bien un membre de l’équipe, la possibilité de découvrir l’avancement d’un tel projet et d’obtenir
une vision sur l’impact de ses modifications tout au long du cycle de validation.
Les fonctionnalités permises à un utilisateur par notre système et à travers le dashboard sont :
CHAPITRE 3. SPÉCIFICATION ET ANALYSE DES BESOINS 23

• Consulter le statut d’un projet.

• Visualiser les différents fichiers logs contenant les résultats des validations.
• Accéder aux artefacts générés par le cycle de validation : compilation, intégration,
déploiement et test.
• Visualiser des métriques reflétant l’avancement d’un projet : taille de code, temps
d’exécution
• La possibilité d’utiliser à partir dashboard, l’outil mentionné dans le paragraphe 1.2 pour
gérer un projet à distant.

3.2 Besoins non fonctionnels

Outre les besoins fonctionnels déjà explicités, la plateforme d’intégration continue doit as-
surer les besoins non fonctionnels suivants :

• Facilité : une interface d’administration de CruiseControl simple et facile à l’utiliser pour

l’ajout et la suppression de projets.
• Ergonomie : l’interface graphique doit être pratique et claire : les utilisateurs doivent
trouver les informations désirées et si possible à portée de la souris.
• Performance : elle devra être fiable par rapport aux outils commerciaux ou prototypes de
recherches existantes.
• Tolérance des pannes : le déroulement de la validation ne doit pas être interrompu suite
à la défaillance d’une machine. Puisqu’il s’agit de plusieurs machines, il faut prévoir des
mécanismes de reprise permettant d’assurer le bon déroulement du processus de valida-
tion même dans des cas extrêmes.
• Disponibilité : c’est la probabilité pour que la plateforme soit en fonctionnement à un
instant donné.
• Maintenance : désigne la capacité d’ajouter ou de supprimer certaines fonctionnalités de
la plateforme.
CHAPITRE 3. SPÉCIFICATION ET ANALYSE DES BESOINS 24

3.3 Diagramme des cas d’utilisation

Dans cette section, nous présenterons les différents cas d’utilisation en détaillant au fur et à
mesure les actions de l’utilisateur de notre plateforme d’intégration continue.

3.3.1 Diagramme de cas d’utilisation de la configuration de CruiseCon-

trol

Figure 3.1 — Diagramme de cas d’utilisation de la configuration de CruiseControl

La figure 3.1 montre les différentes tâches que l’administrateur de CruiseControl peut sol-
liciter avant de démarrer la boucle de validation. En effet, il est capable d’ajouter un nouveau
CHAPITRE 3. SPÉCIFICATION ET ANALYSE DES BESOINS 25

composant au système d’intégration continue, le configurer en déterminant son emplacement

dans le système de management des sources, l’emplacement des fichiers logs résultats de la
validation ainsi que les artefacts.

3.3.2 Diagramme de cas d’utilisation de management de CruiseControl à

distance

Figure 3.2 — Diagramme de cas d’utilisation de management de CruiseControl à distance

CHAPITRE 3. SPÉCIFICATION ET ANALYSE DES BESOINS 26

La figure 3.2 montre les actions que l’outil RMI (Remonte Méthode Invocation) peut effec-
tuer. En effet, l’administrateur est capable d’invoquer CruiseControl à distance et de manipuler
l’ensemble de tous les composants existants dans la boucle de validation.
Il est capable également de :

• Stopper un projet et le faire exclure de la boucle de la validation.

• Mettre en pause un projet pendant le cycle de la validation pour des raisons de mainte-
nance ou pour des modifications dans sa configuration.
• Activer un projet déjà mise en pause.
• Visualiser le statut d’un projet dans la boucle de la validation.
CHAPITRE 3. SPÉCIFICATION ET ANALYSE DES BESOINS 27

3.3.3 Diagramme de cas d’utilisation du dashboard : cas d’un simple uti-

lisateur

Figure 3.3 — Diagramme de cas d’utilisation du dashboard : cas d’un simple utilisateur

D’après le diagramme de la figure 3.3, l’utilisateur du dashboard peut consulter les statuts de
chaque composant existant dans la boucle de la validation et les différents fichiers logs générés
après chaque modification d’un tel projet. Ainsi, l’utilisateur peut avoir les différents artefacts
résultats de la validation et enfin manipuler un projet à travers une interface élégante et facile à
utiliser.
CHAPITRE 3. SPÉCIFICATION ET ANALYSE DES BESOINS 28

Conclusion

Nous avons procédé dans ce chapitre à une analyse des détails relatifs à notre plateforme
d’intégration continue dont la conception des différentes composantes sera présentée dans le
prochain chapitre.
 4
CHAPITRE

Conception

Le présent chapitre sera consacré à la présentation de l’étape de conception de notre système.

Nous exposons, dans un premier temps, le choix de l’architecture de notre plateforme, puis nous
présentons sa conception générale. Nous détaillons, ensuite, cette phase du projet en établissant,
conformément à la notation UML, aussi bien des vues statiques décrivant l’état physique du
système via le diagramme de l’architecture générale, que des vues dynamiques montrant le
fonctionnement du système via des diagrammes des séquences.

4.1 Conception générale

4.1.1 Architecture générale

Nous allons, dans ce qui suit, présenter l’architecture de notre plateforme et sa

décomposition en sous-systèmes.
CHAPITRE 4. CONCEPTION 30

Figure 4.1 — Architecture de la plateforme d’intégration continue évolutive

Tenant compte des divers besoins fonctionnels déjà explicités dans le chapitre précédant
et comme illustré dans la figure 4.1, nous allons dans ce qui suit présenter l’architecture
générale de notre plateforme d’intégration continue en mettant l’accent sur les relations entre
les différents composants de cette architecture. Nous pouvons distinguer trois tiers qui consti-
tuent notre plateforme.
Le premier tiers désigné par ”Svn Server” est un logiciel de gestion de configuration permet-
tant de stocker des informations pour une ou plusieurs ressources informatiques permettant de
CHAPITRE 4. CONCEPTION 31

récupérer toutes les versions intermédiaires des ressources, ainsi que les différences entre les
versions.Il s’agit du logiciel Subversion.
Le deuxième tiers constitué par le serveur de build (CruiseControl Server) et l’ensemble des
machines d’exécution est le tiers le plus important de notre plateforme. Il est responsable de
l’intégration des différents composants développés par les membres de l’équipe. En effet, le ser-
veur d’intégration continue CruiseControl qui a pour rôle d’automatiser les tâches d’intégration
qui sont : la compilation, le lancement des tests, le déploiement et la génération des artefacts
et des fichiers des résultats (logs) et la distribution de ces tâches sur des machines d’exécution
bien déterminées.
Le troisième tiers est le dashboard (interface de reporting) relatif à la publication des résultats
de l’intégration entre les différents composants développés par les membres de l’équipe. Ces
résultats se trouvent dans le serveur de configuration et sont indexés par le serveur de build.
CHAPITRE 4. CONCEPTION 32

4.1.2 Diagramme de composants

Figure 4.2 — Diagramme des composants de la plateforme

Nous allons dans ce qui suit décrire la répartition logicielle de notre plateforme à l’aide du
diagramme des composants qui permettra de mieux comprendre l’organisation du système (voir
figure 4.2).
Trois principaux composants construisent notre plateforme à savoir :

• CruiseControl : le composant responsable de l’intégration des différents modules après

avoir résolu les dépendances entre eux à l’aide d’un module de gestion des dépendances. Il
comporte aussi un sous-composant responsable de vérifier s’il y a des modifications dans
le serveur de controle des versions, un générateur des fichiers logs résultats des différents
CHAPITRE 4. CONCEPTION 33

builds effectués par le ” Build module ” et enfin un moniteur des actions responsable de
la notification de module de build des actions transmises à travers le Dashboard.
• dashboard : une interface web qui respect le patron de conception ” MVC ” responsable de
la visualisation de l’ensemble des fichiers logs, des statistiques sur un projet donné (temps
de build, nombre des tests passés) et qui est également capable d’invoquer CruiseControl
pour compiler, mettre en pause ou stopper un projet. Une interface de configuration de
CruiseControl qui permet l’ajout ou la suppression d’un projet de CruiseControl est aussi
incluse dans ce dashboard.
• DVP : ” Distributed Validation Plateform ” désigne une couche logicielle distribuée qui
permet l’exécution de la tâche de build d’une façon distribuée. Cette couche est com-
posée de deux principaux composants : MDS ” Monitoring and Discovery Service ” est
un service web qui gère et affecte les tâches entre l’ensemble des machines dédiées à
l’intégration ou il est déployé le deuxième composant JES ” Job Execution Service ”
responsable de l’exécution d’une tâche de la compilation.

4.2 Conception détaillée

Cette section sera consacrée à la conception détaillée de notre plateforme. Nous débutons
avec la conception des différents composants vus précédemment (voir paragraphe 4.1). Puis
nous modélisons l’aspect dynamique du système à l’aide des diagrammes des séquence.

4.2.1 Conception des composants de la plateforme

Dans cette partie, nous allons détailler la conception du CruiseControl puis du dashboard et
enfin du DVP.

Conception de CruiseControl
CHAPITRE 4. CONCEPTION 34

Module de la compilation

Figure 4.3 — Diagramme de classe Cruise Control

Cette figure représente une ébauche du diagramme de classe de CruiseControl qui contient
les classes indispensables pour le build d’un projet. La classe ” main ” est un point d’entrée au
CruiseControl. Elle crée une instance de CruiseControlController qui gère le processus de build
dans sa globalité ; ainsi elle fait référence au deux classes ProjectDependencies et ProjectsDe-
pendencies pour gèrer les dépendances entre les différents projets.
Le ProjectControllerMBean avec son implémentation le ProjectController désigne le moniteur
des actions qui transmet les requêtes provenant du dashboard au module de build constitué par
ExecBuilder.
CHAPITRE 4. CONCEPTION 35

Module de gestion des dépendances

Principalement, le module de gestion des dépendances est intégré au Cruise Control à travers
un ensemble de classes qui gère les dépendances entre les composants. Les plus importants
sont :
• ProjectDependencies : Cette classe a comme attributs un nom d’un composant et une
structure de données de type List¡String¿ contenant la liste de tous les fournisseurs de ce
composant. Également, elle contient des méthodes pour l’ajout et le retrait d’un fournis-
seur et des méthodes pour la vérification des résultats des builds de ces fournisseurs.
• ProjectsDependencies : Cette Classe contient la liste des composants qui ont chacun des
dépendances avec la liste de ses fournisseurs. Alors, elle contient une structure de données
de type List¡ProjectDependencies¿ et un ensemble de méthodes qui gère cette structure
(ajout/retrait/vérification...).
• DependenciesLoader : Classe responsable du parsing du fichier de définition des
dépendances ”dependencies.xml” pour en extraire les dépendances et charger une ins-
tance de ”ProjectsDependencies”.
Processus de chargement des dépendances :
• Le ”Main” de CruiseControl crée une instance de ”CruiseControlController”.
• A cette instanciation, une instance de ”ProjectsDependencies” va être créé et chargée par
une instance de ”DependenciesLoader”.
• Cette instance est transmise alors a tout les instants qui représentent les composants ou
les projets.
• Ensuite à chaque vérification de la modification et si CruiseControl a trouvé des nouvel-
leaux changements (commits) il va lancer le build de l’instance qui représente le projet
modifié .
• Au début de cette opération (build), une synchronisation de l’instance de ”ProjectsDepen-
dencies” est faite à travers une instance de ”DependenciesLoader” pour vérifier s’il y a
des nouvelles dépendances qui ont été ajoutées pendant le temps d’attente du projet.
• Apres chaque build, l’instance de ”ProjectsDependencies” est mise à jour par les résultats
des builds.
CHAPITRE 4. CONCEPTION 36

Figure 4.4 — Dependencies.xml

Conception du dashboard

Le dashboard est une interface web qui respecte l’architecture ” MVC ” (Model, View,
Contrôler). La partie ” View ” (présentation) est composée d’un ensemble des pages ” JSF
” (Java Server Face) responsable de la présentation des résultats des builds et qui donnent
la possibilité d’invoquer le serveur CruiseControl à distance. La partie ” Contrôler ”
(contrôleur) est celle responsable des différents traitements effectués pour extraire les
informations des fichiers logs .Enfin, la partie ” Model ” (Modèle) est constituée par l’en-
semble des fichiers logs et les artefacts de CruiseControl.
CHAPITRE 4. CONCEPTION 37

La partie présentation

Figure 4.5 — Diagramme de navigation du dashboard

La figure 4.5 représente les différents cas de navigation entre les vues du dashboard.
L’utilisateur choisit un projet dans la liste affichée au niveau de l’index pour qu’il puisse
consulter les résultats de ses derniers builds, voir des graphes illustrant les résultats des
tests unitaires, les résultats des builds supplémentaires et le logfile généré par CruiseCon-
trol. Également, l’utilisateur peut choisir en restant dans le même projet de consulter les
résultats des autres builds en choisissant un autre log.
Si l’utilisateur est un administrateur qui veut configurer un nouveau projet, il doit pas-
ser par la vue login et après une authentification réussite, il peut choisir de l’interface
administration soit de modifier un projet existant soit d’ajouter un nouveau projet.
CHAPITRE 4. CONCEPTION 38

La partie contrôleur

Figure 4.6 — Diagramme de classe du contrôleur

La figure 4.6 présente une ébauche du diagramme de classes du contrôleur du dashboard.

Les principales classes sont :
CHAPITRE 4. CONCEPTION 39

• LogFile : abstraction d’un fichier log de CruiseControl. Elle est constituée d’un en-
semble de méthodes responsables de l’extraction des informations à partir d’un log
XML.
• BuildInfo : elle est responsable de l’extraction des informations depuis le nom d’un
fichier log (date de build, succès/échec).
• Info : c’est la classe la plus importante. Elle est responsable des traitements des infor-
mations qui parviennent à partir de deux autres classes (LogFile et BuildInfo) concer-
nant un build (modifications effectuées, résultats des tests unitaires, information liés au
build).
La partie modèle
La partie modèle de notre dashboard est désigné par l’ensemble des fichiers logs et les ar-
tefacts généré par Cruise Control qui forment au sens large du mot notre base de données
ainsi que l’ensemble des classes responsables aux traitements de ces données (parseur
XML et Servlet pour la lecture des artefacts).

Conception de la DVP

La DVP est une plateforme de validation distribuée. Elle permet l’exécution des tâches de
la validation (appelés ”jobs” dans la terminologie de la DVP) sur les différentes ressources
disponibles tout en permettant la répartition de la charge et une gestion des ressources.
Cette plateforme est conçue avec une architecture distribuée en utilisant la technologie
des web services. Elle est principalement constituée de deux web services [XF2] :
Monitoring and Discovery Service le monitoring and discovery service est un service
web responsable à la découverte, la gestion et la distribution des tâches de build entre des
machines spécifiques à l’exécution où un autre service est déployé : le JobExecutionSer-
vice.
Job Execution Service Ce service assure l’exécution d’une tâche de build et la génération
des rapports d’exécution pour faciliter le suivi.
CHAPITRE 4. CONCEPTION 40

Figure 4.7 — Illustration de la DVP

• MDS : Monitoring and Discovery Service.

• JES : Job Execution Service.
• Job-submit-synch : client de la DVP qui permet l’envoie d’un Job au MDS afin de
l’exécuter à distance et de récupérer les résultats d’exécution d’une manière synchrone.
• Job-submit-asynch : même chose que le Job-submit-synch mais la récupération des
résultats se fait d’une façon asynchrone.
• Job-status :script DVP qui affiche la liste des jobs lancés ainsi que leurs états et les
machines d’exécutions correspondantes.
CHAPITRE 4. CONCEPTION 41

4.2.2 Les diagrammes de séquences

Pour modéliser l’aspect dynamique du système, nous présentons dans ce paragraphe

quelques diagrammes de séquences. Un diagramme de séquences a pour but de montrer
les relations entre objets d’un point de vue temporel en mettant l’accent sur la chronologie
des envois de messages.

Diagramme de séquence pour la consultation des résultats

Figure 4.8 — Diagramme de séquence pour un simple utilisateur

Ce diagramme montre comment un utilisateur peut à travers du dashboard consulter les

CHAPITRE 4. CONCEPTION 42

états des composants dans CruiseControl et les résultats des builds pour chaque compo-
sant. Il introduit le nom d’un composants, la classe ” Resultats ” demande les informations
disponibles pour ce composant pendant que la classe Info demande le log file correspon-
dant à ce composant, les traite et les affiche dans la vue correspondant à la classe ” Resultat
”.

Diagramme de séquence pour la configuration

Figure 4.9 — Diagramme de séquence pour la configuration

CHAPITRE 4. CONCEPTION 43

Le dashboard contient une interface web de login à partir de laquelle l’administrateur

peut configurer CruiseControl par la modification de ses fichiers de configurations. Ainsi,
il peut ajouter, modifier et supprimer des projets de CruiseControl et enfin se déconnecter.

Diagramme de séquence pour l’invocation de CruiseControl à distance

Figure 4.10 — Diagramme de séquence pour l’invocation à distant

Le diagramme de séquence illustré par la figure 4.10 nous montre le processus d’invo-
cation ou de pilotage de CruiseControl à distance. Un simple utilisateur peut lancer un
build automatique pour ce composant pour vérifier le bon déroulement du travail pour un
composant. Cet utilisateur peut également mettre en pause un projet ou le faire sortir de
la boucle de validation.
CHAPITRE 4. CONCEPTION 44

Conclusion
Nous avons décortiqué, dans le présent chapitre, l’application à réaliser progressivement.
Nous avons commencé par décrire la conception générale du système, dévoilée grâce à
un diagramme organisationnel et pour terminer avec la conception détaillée explicitée
à l’aide des diagrammes de classes et des diagrammes de séquences. Dans le chapitre
suivant, nous exposons la réalisation de notre travail ainsi que les résultats obtenus.
 5
CHAPITRE

Réalisation

Ce chapitre constitue le dernier volet du rapport ayant pour objectif d’exposer le travail
achevé. Pour ce faire, nous faisons, dans un premier temps, le tour des différents outils et
bibliothèques utilisés pour la mise en place de notre plateforme. Ensuite, nous présentons
quelques captures d’écran de l’application réalisée.

5.1 Environnement de travail

Dans cette section, nous présentons les configurations matérielle et logicielles mises à
notre disposition en justifiant le choix de la plateforme de développement.

5.1.1 Configuration matériel

Afin de mener à bien ce projet, il a été mis à notre disposition un micro-ordinateur dont
les caractéristiques sont les suivantes :
• Processeur : Pentium 4 à 3 Ghz.
• RAM : 1Go.
• Disque dur : 80 Go. La plateforme a été testée sur des machines dotées du système
d’exploitation Windows (XP 32-bits) et Linux (RedHat 2.4.21 et 64-bits).

5.1.2 Choix de la plateforme Java Entreprise Edition (JEE)

Pour le développement du dashboard, nous avions le choix entre la solution .Net de Mi-
crosoft et celle JEE. Cette dernière est adoptée par plusieurs éditeurs informatiques dont
Sun, BEA et IBM. La première solution offre certes des performances optimales et une
CHAPITRE 5. RÉALISATION 46

facilité dans le développement mais son inconvénient majeur est qu’elle nous oblige à
utiliser la gamme de produits Microsoft à savoir Windows comme système d’exploi-
tation et IIS comme serveur web. Ce choix est donc à éliminer pour la cause d’in-
teropérabilité car notre application d’intégration continue doit être multiplateforme.
Nous opterons donc pour la solution JEE. cette solution a le mérite d’être :
• Riche : plusieurs API (Application Programming interface) qui implémentent le pa-
tron de conception le MVC ainsi que de nombreuses autres API que nous avons
utilisée au cours de développement de la couche représentation.
• Indépendante par rapport à la plateforme utilisée, d’où une meilleure intégration.
• Innovante : l’implémentation est libre ce qui favorise la compétition entre éditeurs.
• Soutenue par plusieurs géants de l’informatique (Sun, IBM, BEA...). Concernant les
modifications apportées au CruiseControl qui est un outil écrit en Java, nous n’avons
que Java à utiliser.

5.1.3 Configuration logicielle

Nous avons développé le noyau de notre plateforme sous un environnement de

développement J2EE (Java 2 Entreprise Edition). Nous avons utilisé les outils suivants :
• JAVA : Nous avons opté Java comme langage pour développer le dashboard et ap-
porter des modifications au code sources de Cruise Control.
• Netbeans : C’est un environnement de développement intégré (IDE) pour Java, placé
en open source par Sun en juin 2000 sous licence CDDL (Common Development
and Distribution License). En plus de Java, Netbeans permet également de supporter
différents autres langages, comme Perl, C, C++, XML et Python. Il comprend toutes
les caractéristiques d’un IDE moderne (éditeur en couleurs, projets multi-langages,
refactoring, éditeur graphique d’interfaces et de pages web).
• GlassFish : GlassFish est le serveur d’applications Open Source Java EE 5 et qui sert
de fondation au produit Sun Java System Application Server de Sun Microsystems.
GlassFish recouvre également :
- EJB 3 (approche POJO, configuration par exception, injection de dépendance).
L’occasion de se refaire une idée sur les EJB.
CHAPITRE 5. RÉALISATION 47

- JPA (Java Persistence API) : standard implémenté par TopLink (par défaut dans
GlassFish), Hibernate ou OpenJPA.
- JAX-WS 2.x : nouvelle pile pour les services web .
- JAXB 2.0 : mise en correspondance (mapping) XML/Java utilisée par JAX-WS 2.0.
- JSF (Java Server Faces)
- Framework MVC dont Apache MyFaces et JSF RI sont des implémentations libres.
- JSP 2.1 Servlet 2.5 : pour faire de l’injection de dépendance dans le conteneur web.
- Ajax4Jsf : Ajax4JSF est une librairie open source qui permet de transformer des
composants JSF existants en composants compatibles AJAX. Ainsi nous pouvons
accéder aux objets du serveur sans devoir recharger toute la page web. C’est sur
ce point qu’AJAX (Asynchronous JavaScript And XML) intervient permettant le
rechargement à chaud de la page web.

5.2 Travail réalisé

Dans cette section, nous présentons le travail que nous avons réalisé. En fait, nous avons
pu réaliser les objectifs relatifs à la réalisation de la plateforme d’intégration continue
que nous avons tracés depuis le début du projet en couvrant les besoins explicités dans
le chapitre des spécifications. Ces objectifs sont exprimés à travers les interfaces per-
mettant d’exploiter facilement les fonctionnalités développées.
CHAPITRE 5. RÉALISATION 48

5.2.1 Le point d’entrée

Figure 5.1 — Page d’accueil du dashboard

La page d’accueil représente le point d’entre au dashboard. Elle contient la liste de com-
posants configurés pour être validés automatiquement par CruiseControl ainsi qu’un
certain nombre de caractéristiques indispensables pour avoir une vue globale sur l’état
d’un composant :
• Last user : qui est le dernier modificateur du composant.
CHAPITRE 5. RÉALISATION 49

• Status : l’état de validation d’un projet.

• Last Successful : date du dernier build réussi.
• Last failure : date du dernier build échoué.
• Label : Indice ou nombre des builds effectués depuis la mise sous CruiseControl
• Des bouttons pour stopper, mettre en ou lancer un build pour un composant.
CHAPITRE 5. RÉALISATION 50

5.2.2 Consultation des statuts

Figure 5.2 — Page des résultats de la validation

Cette vue présente la visualisation des différentes informations liées au build d’un com-
posant. Elle contient également des informations générales (nom du composant, date et
temps de build et l’index build) et un tableau des derniers modifications ont contribué
au lancement de ce build, un tableau des résultats des tests unitaires et enfin une vue
CHAPITRE 5. RÉALISATION 51

sur l’état des composants dont il dépend ce composant.

5.2.3 Les graphes des résultats

La page ” Metrics ” présente un ensemble de graphes qui illustrent l’état d’avance-

ment du développement d’un composant. Ces graphes sont développés à l’aide d’un
API (Application Programming Interface) libre le ” JFreeChatrs ” capable de présenter
plusieurs types des graphes.

Figure 5.3 — Graphe des résultats des tests

Un graphe de type ” Pie Chart ” qui représente les nombres des tests réussis et des tests
échoués depuis l’ajout du composant dans notre plateforme.
CHAPITRE 5. RÉALISATION 52

Figure 5.4 — Graphe d’évolution de la validation d’un composant

CHAPITRE 5. RÉALISATION 53

Ces graphes de type ” Scatter Chart ” représentent l’évolution en terme de temps de

la validation, nombre des tests échoués et des tests réussis en fonction des révisions.
Ainsi, l’utilisateur peut avoir idée si un composant a bien évolué ou non.

Figure 5.5 — Tableau de résultats des tests

La figure 5.5 est une ébauche du tableau des métriques correspondantes à un compo-
sant. Le tableau récapitule tous les résultats des tests unitaires effectués sur un compo-
sant depuis son ajout au processus d’intégration continue.

5.2.4 L’interface d’administration

Après authentification, l’administrateur peut soit configurer un nouveau composant

pour l’introduire dans la plateforme d’intégration soit modifier une configuration exis-
tante en utilisant une simple interface de configuration.
CHAPITRE 5. RÉALISATION 54

Figure 5.6 — Interface de la configuration

CHAPITRE 5. RÉALISATION 55

5.3 Tests et intégration

Dans ce qui suit nous allons présenter les étapes de déploiement de notre solution au
sein de l’équipe CEC à la fin du notre stage.

5.3.1 Déploiement

Dans ce qui suit nous allons présenter les étapes de déploiement de notre solution au
sien de l’équipe CEC à la fin du notre stage. Pour déployer notre solution nous avons
utilisé :
• Un serveur Subversion fonctionnel implémenté sur le ST Grenoble. Ce serveur
héberge les différents composants des compilateurs : nous avons relevé 120 com-
posants.
• Notre serveur CruiseControl implémenté sur le site ST de Tunis et configuré pour
maintenir l’intégration entre ces 120 composants.
• Une machine qui fait partie de la DVP ou il est déployé le MonitoringAndDiscovery
Service se situe dans le site de Tunis.

5.3.2 Test

Afin de vérifier et de valider notre plateforme d’intégration continue , nous avons confi-
guré CruiseControl d’avoir la capacité de lancer la validation, automatique de 50 com-
posant au même temps. Egalement, nous avons construire un script pour lancer des
commandes en utilisant la DVP dans le but de créer un trafic supplémentaire aux ma-
chines d’exécutions et également au monitoringAnd DiscoveryService machine.

5.3.3 Résultats

Apres lancement, nous avons pu dégager deux familles des résultats en fonction de la
localisations des machines d’exécutions :
• Pour les machines situées à ST Tunis, puisque le trafic est dans le même sous-réseau
de STMicroelectronics et parce que les machines sont géographiquement dans la
CHAPITRE 5. RÉALISATION 56

même zone le temps de transfert entre le serveur de CruiseControl et le monito-

ring Service et le temps de transfert entre le monitoring Service et les machines
d’exécutions sont tous les deux acceptable d’un point de vue temps de validation.
• Pour les machines déployées à ST Grenoble le temps de transfert entre les entités in-
diqués précédemment est encore plus important, ce que résulte en une augmentation
du temps nécessaire pour une session de validation.
Dans le cas, le temps de communication entre CruiseControl et le serveur de gestion
de control SVN est important. C’est pourquoi nous avons décidé d’implémenter notre
serveur CruiseControl sur le site ST Grenoble.

5.4 Chronogramme
Il est nécessaire de dresser un tableau qui décrit la répartition des taches du projet tout
au long des quatre mois du stage, afin de donner une vue globale de la répartition du
temps par rapport au travail demandé. Ainsi, le tableau 5.1 explicite le déroulement.
CHAPITRE 5. RÉALISATION 57

Semaine Piste Tache

1 Documentation
2 Documentation
3 Documentation Installation et configuration de CruiseControl
4 Conception mettre à jour tous les filtres de l’utilisateur
5 Réalisation Développement de l’interface web
6 Réalisation Développement de l’interface web
7 Réalisation Raffiner la refeshe des données
8 Réalisation Intégration du module de dépendances
9 Réalisation Intégration du module de dépendances
10 Réalisation Generateur des rapports des échecs et des artefacts
11 Réalisation Expérimentation du fait de construire distribué ACI serveur
12 Réalisation Intégration de graphe des dépendances
13 Rapport Générateur de l’état du trafic de développement
14 Rapport Evaluation de l’interface de CruiseControl
15 Rapport
16 Rapport

Tableau 5.1 — Chronogramme

Conclusion
Nous avons vu dans ce chapitre les environnements logiciel et matériel sur lesquels
s’est basé notre travail. Nous avons justifié les choix considérés pour aboutir à la
réalisation de la nouvelle plateforme d’intégration évolutive. Nous présentons dans ce
qui suit la conclusion générale.
 Conclusion générale

L’intégration continue est un ensemble de bonnes pratiques utilisées en génie logi-

ciel. Ces pratiques consistent à vérifier à chaque modification de code source que le
résultat des modifications ne produit pas de régression de l’application en cours de
développement dans le but de accroı̂tre le temps de développement et d’avoir a tout
moment une version stable de l’application.

Nous avons concrétisé notre approche concernant la plateforme d’intégration conti-

nue en mettant l’accent sur le concept d’intégration distribué dans le but d’atteindre
un certain niveau d’efficacité dans l’utilisation des ressources de l’infrastructure.
Ceci nous permet d’apporter une réponse aux deux points dont souffre le processus
d’intégration continue : l’absence de prise en compte des dépendances entre projet et
la sous-utilisation des ressources disponibles.

Ainsi se termine donc ce rapport au long duquel nous avons cherché à présenter le
projet et à illustrer les différentes étapes de conception et de mise en oeuvre. Nous es-
timons avoir satisfait les objectifs initialement fixés tout en faisant face aux diverses
contraintes et nouvelles requêtes qui se sont révélées durant ce stage. Nous sommes
d’autant plus confiants dans notre jugement que de nombreux utilisateurs de la plate-
forme nous ont exprimé leur satisfaction autant sur le fond que sur la forme de l’outil
final.

Par ailleurs, ces témoignages ne peuvent que nous inciter à penser aux évolutions
qu’ils seraient souhaitables d’apporter à notre plateforme. En particulier, nous pour-
rions définir un ” plugin ” (Module supplémentaire) pour les environnements de
CONCLUSION GÉNÉRALE 59

développement des membres liés à CruiseControl qui permet une auto configuration
d’un composant dès sa création dans l’environnement.
Bibliographie
 Bibliographie

[1] A. V. Ahlo, R. Sethi et J. D.Ullman, Compilers principles, techniques and tools.

[2] Xavier Fournier-Morel, SOA, le guide de l’architecture du SI.

[3] R. Mulye, Metero-s process design and development tool, Master of Science, Uni-
versity of Georgia-USA.
 Netographie

[4] http ://www.webmanagercenter.org/STMicroelectronics consulté le 3

Février 2009.
[5] http ://www.labo-sun.com consulté le 10 Février 2009.
[6] http ://www.mariosalexandrou.com/methodologies consulté le 1 Mars
2009.
[7] http ://www.extremeprogramming.org consulté le 1 Mars 2009.
[8] http ://www.nebulon.com/fdd consulté le 1 Mars 2009.
[9] http ://www.valtech.fr/fr/index/hot/scrum consulté le 1 Mars 2009.
[10] http ://www.hudson.com consulté le 20 Avril 2009.
[11] http ://www.cruisecontrol.com consulté le le 20 Avril 2009.
[12] http ://www.ibm.com consulté le le 20 Avril 2009.
Annexes
 A
ANNEXE

Subversion

A.1 Définition

Subversion est un logiciel de gestion de sources et de contrôle de versions. Ce type de

programmes a plusieurs fonctions, notamment :
• garder un historique des différentes versions des fichiers d’un projet.
• permettre le retour à une version antérieure quelconque.
• garder un historique des modifications avec leur nature, leur date, leur auteur...
• permettre un accès souple à ces fichiers, en local ou via un réseau
• permettre à des utilisateurs distincts et souvent distants de travailler ensemble sur les
mêmes fichiers.

A.2 Installation

Installation
L’installation de Subversion sur Debian se fait simplement par la commande :

aptitude install subversion

Cette commande installe le client Subversion, différentes commandes de gestion de
dépôt ainsi qu’un exécutable serveur sur une distribution Debian Etch.
Gestion d’un dépôt
Cela fait, il est nécessaire de créer un premier dépôt. Dans le cadre de cette annexe, le
répertoire de base des dépôts sera /var/subversion/depot/
La création d’un dépôt pour un projet nomdemonprojet se fait via la commande :
ANNEXE A. SUBVERSION 65

svnadmin create /var/subversion/depot/nomdenotreprojet

Le résultat devrait être un répertoire nomdemonprojet crée dans /var/subversion/depot/ .

A.3 Utilisation
La première étape dans l’utilisation de Subversion est de récupérer une copie locale du
dépôt :
svn co file :///var/subversion/depot/nomdemonprojet Si tout c’est
bien déroulé, un répertoire nomdemonprojet a du être créé dans le répertoire courant.
Ce répertoire doit contenir les fichiers de la dernière révision disponible sur le dépôt.
Dans ce répertoire, vous êtes libre de travailler normalement : création de répertoire,
ajout de fichier. L’ajout un nouveau fichier nécessite d’informer Subversion que ce
fichier doit être pris en compte lors de la prochaine publication des modifications sur
le dépôt :
svn add src
La dernière commande n’a fait que mettre une ”étiquette” sur le fichier, mais il n’est
pas encore été envoyé vers le dépôt. Cette action est réalisée via la commande :
svn commit src -m ”Message expliquant le modification effectuées”
 B
ANNEXE

Web services

B.1 Définition

Un service web est un programme informatique permettant la communication et

l’échange de données entre applications et systèmes hétérogènes dans des environne-
ments distribués. Il s’agit donc d’un ensemble de fonctionnalités exposées sur internet
ou sur un intranet, par et pour des applications ou machines, sans intervention humaine,
et en temps réel.[2]
Il existe plusieurs technologies derrière le terme services web :
• Les services web de type Representational state transfer (REST) exposent
entièrement ces fonctionnalités comme un ensemble de ressources (URI) identi-
fiables et accessibles par la syntaxe et la sémantique du protocole HTTP. Les Ser-
vices Web de type REST sont donc basés sur l’architecture du web et ses standards
de base : HTTP et URI.
• Les Services Web WS-* exposent ces mêmes fonctionnalités sous la forme de ser-
vices exécutables à distance. Leurs spécifications reposent sur les standards SOAP et
WSDL pour transformer les problématiques d’intégration héritées du monde Middle-
ware en objectif d’interopérabilité. Les standards WS-* sont souvent décriés comme
l’étaient leurs ancêtres CORBA, RMI ou DCOM : des technologies complexes
héritées du vieux principe RPC, fortement couplées et difficilement interopérables
dans des environnements hétérogènes. A contrario, le Web est par nature une plate-
forme interopérable.
ANNEXE B. WEB SERVICES 67

B.2 Avantages
• Les services Web fournissent l’interopérabilité entre divers logiciels fonctionnant sur
diverses plates-formes
• Les services Web utilisent des standards et protocoles ouverts.
• Les protocoles et les formats de données sont au format texte dans la mesure du
possible, facilitant ainsi la compréhension du fonctionnement global des échanges.
• Basés sur le protocole HTTP, les services Web peuvent fonctionner au travers de
nombreux pare-feux sans nécessiter des changements sur les règles de filtrage.
• Les outils de développement, s’appuyant sur ces standards, permettent la création
automatique de programmes utilisant les services Web existants.

B.3 Inconvénients
• Les normes de services Web dans certains domaines sont actuellement récentes.
• Les services Web souffrent de performances faibles comparées à d’autres approches
de l’informatique répartie telles que le RMI, CORBA, ou DCOM.
• Par l’utilisation du protocole HTTP, les services Web peuvent contourner les mesures
de sécurité mises en place au travers des pare-feux.