Me Moire

Rf : 2008/II/...
Soutenu la session de Juillet 2009
Universit de la Manouba
ECOLE NATIONALE DES SCIENCES DE LINFORMATIQUE
RAPPORT
DE Mmoire de Fin dEtudes Prsent en vue de lobtention du titre
dINGENIEUR EN INFORMATIQUE
Par
ECHAIB Nidhal
Sujet :
Mise en place dune plateforme de validation distribue dans un contexte embarqu

Encadr par : Mr. SABRI MTIBAA Ingnieur (STMicroelectronics) Rsponsable : Mr. GIUSEPPE DI GIORE CPT manager (STMicroelectronics) Supervis par : Mr. HECHMI ABOUDA Enseignant(ENSI)
Organisme : STMicroelectronics
Cit Technologique La Gazelle 2088 Ariana Tel :(216) 71 857 750 Fax : (216) 71 857 525
Signatures des encadrants

Mr. SABRI MTIBAA (STMicroelectronics)
Mr. HECHMI ABOUDA (ENSI)
ii
iii
Rsum
Ltape de validation est une tape cruciale dans le cycle de dveloppement des produits informatiques. Ce travail, qui sinscrit dans le cadre du projet de n dtudes en vue de lobtention du diplme dingnieur en informatique, consiste mettre en place une plateforme de validation distribue dans un contexte embarqu. Dabord, nous commenons par raliser un tat de lart des solutions existantes. Ensuite, nous dcrivons les tapes de spcication, de conception et de ralisation de la solution que nous avons mise en place. Mots cls : validation, systmes embarqus, Approche Oriente Service.
Abstract
The validation step is crucial in the software product development cycle. This work which is included within the graduations project for obtaining a diploma in computer science engineering consists to analysis and implementation of a distributed validation platform in an embedded context. First, we establish a state of the art of existing solutions. Then we describe the stages of specication, design and implementation of the solution we have put in place. Keywords : validation, embedded system, Service Oriented Approach .
Ddicaces
J A
E
ddie ce modeste travail

Ma
chre mre Chedlia
En tmoignage de ma profonde gratitude et de mon incontestable reconnais-
sance, pour tous les sacrices quelle me contente, toute la conance quelle maccorde et tout lamour dont elle mentoure.
A A A A A
Mon Cher pre Fadhel Qui est le plus bon pre dans ce monde, grce son encouragement, sa conance
et son soutien moral et matriel et pour son amour inni en exprimant mes gratitudes, mon profond amour et ma passion .
M es
chers frre et sur : Nadhem et Nihel
En leurs esprant le plein succs dans leur vie.
Ux
familles CHAIB et BADREDDINE et en particulier mon chr oncle Adel qui
ma initi au monde informatique.
T ous mes amis Khaled,Mounir,Oussema,Sabri,Nadhem,Fayal, Kamel, Houcem,
Youssef, Abir, Maherzia. . .
T ous
ceux qui mont aids et que jai oubli de citer.
iv
Remerciements
Je tiens exprimer ma gratitude M. Sabri MTIBAA ,mon tuteur , pour mavoir intgr rapidement au sein de lentreprise et mavoir accord toute sa conance ; pour le temps quil ma consacr tout au long de cette priode, sachant rpondre toutes mes interrogations ; sans oublier sa participation au cheminement de ce rapport
Je tiens galement remercier M.Hechmi ABOUDA, enseignant lENSI, pour son support pertinent et fort prcieux.
Je tiens remercier tout particulirement et tmoigner toute ma reconnaissance aux personnes suivantes, pour lexprience enrichissante et pleine dintrt quelles mont fait vivre durant ces quatre mois au sein de lentreprise STMicroelectronics :
M. Jean-Marc BOUCHE, ingnieur STMicroelectonics, pour la qualit de son suivi incessant, pour son accueil et pour la conance quil ma accord.
M. Giuseppe DI GIORE, manager de la division STS, pour mavoir si aimablement accueilli chez STMicroelectronics.
Enn, jadresse mes remerciements aux membres du jury pour mavoir honor en acceptant dvaluer ce travail.
Table des matires

Rsum Ddicaces Remerciements Introduction gnrale 1 Prsentation du cadre du projet 1.1 Organisme daccueil et cadre gnral . . . . . . . . . . . . . . . . . . . . . 1.1.1 1.1.2 ST Tunis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Lquipe Compiler Expertise Center : centre dexpertise en compilation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.2 1.3 Cadre gnral du projet . . . . . . . . . . . . . . . . . . . . . . . . . . . . La mthodologie adopte . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.3.1 1.3.2 1.3.3 Les mthodes agiles . . . . . . . . . . . . . . . . . . . . . . . . . . Un comparatif des mthodes agiles . . . . . . . . . . . . . . . . . La mthodologie Scrum . . . . . . . . . . . . . . . . . . . . . . . . 1.3.3.1 1.3.3.2 1.4 Introduction la mthodologie Scrum . . . . . . . . . . Le choix de la mthodologie Scrum . . . . . . . . . . . . 4 5 6 6 7 7 7 8 10 10 11 12 iii iv v 1 3 3 4
Problmatique . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.4.1 1.4.2 1.4.3 Rappel sur le principe de compilation . . . . . . . . . . . . . . . . Le projet GNU : compilateurs et options de compilation . . . . . La compilation dans un environnement embarqu . . . . . . . . . vi
TABLE DES MATIRES
vii
1.4.4 1.5 2
Les modes dexcution et problmatique . . . . . . . . . . . . . .
12 13 15 15 15 15 16 17 17 19 20 20 21 21 24 24 24 25 27 27 28 28 30
Travail demand . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Etude de lexistant 2.1 Etude de lexistant : Analyse et critiques . . . . . . . . . . . . . . . . . . . 2.1.1 Electric Commander . . . . . . . . . . . . . . . . . . . . . . . . . . 2.1.1.1 2.1.1.2 2.1.2 Description . . . . . . . . . . . . . . . . . . . . . . . . . . Critiques . . . . . . . . . . . . . . . . . . . . . . . . . . .
LSF (Load Sharing Facility) . . . . . . . . . . . . . . . . . . . . . . 2.1.2.1 2.1.2.2 Description . . . . . . . . . . . . . . . . . . . . . . . . . . Critiques . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.1.3
DVP (Distributed Validation Platform) . . . . . . . . . . . . . . . 2.1.3.1 2.1.3.2 Description . . . . . . . . . . . . . . . . . . . . . . . . . . Critiques . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.2 3
La solution propose . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Spcications 3.1 Besoins fonctionnels . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.1.1 3.1.2 3.2 3.3 Dnition des acteurs . . . . . . . . . . . . . . . . . . . . . . . . . Liste prliminaire des cas dutilisation . . . . . . . . . . . . . . .
Besoins non fonctionnels . . . . . . . . . . . . . . . . . . . . . . . . . . . . Diagrammes des cas dutilisation . . . . . . . . . . . . . . . . . . . . . . . 3.3.1 3.3.2 Diagramme du cas dutilisation gnral . . . . . . . . . . . . . . . Diagramme du cas dutilisation Grer les jobs . . . . . . . . . . 3.3.2.1 3.3.2.2 Diagramme du cas dutilisation Lancer un job . . . . Diagramme du cas dutilisation Choisir la plateforme dexcution . . . . . . . . . . . . . . . . . . . . . . . . . 3.3.2.3 Diagramme du cas dutilisation Dnir les relations de dpendances . . . . . . . . . . . . . . . . . . . . . . . . 3.3.3 3.3.4 Diagramme du cas dutilisation Grer les ressources . . . . . . Diagramme du cas dutilisation Grer les utilisateurs . . . . .
30
31 31 32
TABLE DES MATIRES
viii
3.4 4
Description dtaille des cas dutilisation . . . . . . . . . . . . . . . . . .
33 42 42 42 44 44 45 46 47 48 48 54 56 56
Conception 4.1 Conception gnrale . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.1.1 4.1.2 4.1.3 Architecture gnrale de la plateforme . . . . . . . . . . . . . . . . Diagramme de composants . . . . . . . . . . . . . . . . . . . . . . Architecture dune application cliente . . . . . . . . . . . . . . . . 4.1.3.1 4.1.3.2 4.2 Architecture de linterface web . . . . . . . . . . . . . . . Architecture dun script DVP . . . . . . . . . . . . . . .
Conception dtaille . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.2.1 Conception des services web . . . . . . . . . . . . . . . . . . . . . 4.2.1.1 4.2.1.2 4.2.2 Monitoring and Discovery Service . . . . . . . . . . . . Job Execution Service . . . . . . . . . . . . . . . . . . . .
Diagrammes de squences . . . . . . . . . . . . . . . . . . . . . . . 4.2.2.1 4.2.2.2 Diagramme de squence de lajout dune carte . . . . . Diagramme de squence de lancement de job depuis un chier script . . . . . . . . . . . . . . . . . . . . . . . . . 4.2.2.3 Diagramme de squence de lancement de job en mode asynchrone . . . . . . . . . . . . . . . . . . . . . . . . . . 4.2.2.4 Diagramme de squence de lancement de job dans un environnement embarqu . . . . . . . . . . . . . . . . .
57
58
59 62 62 62 63 63 63 64 65 66
Ralisation 5.1 Ralisation par rapport au backlog . . . . . . . . . . . . . . . . . . . . . . 5.1.1 5.1.2 5.2 Le droulement des sprints . . . . . . . . . . . . . . . . . . . . . . Facteur de disponibilit . . . . . . . . . . . . . . . . . . . . . . . .
Conguration matrielle et logicielle . . . . . . . . . . . . . . . . . . . . . 5.2.1 5.2.2 5.2.3 Conguration matrielle . . . . . . . . . . . . . . . . . . . . . . . . Choix de la plateforme de dveloppement . . . . . . . . . . . . . Conguration logicielle . . . . . . . . . . . . . . . . . . . . . . . .
5.3
Ralisation par rapport au produit nal . . . . . . . . . . . . . . . . . . .
TABLE DES MATIRES
ix
5.3.1 5.3.2 5.3.3 5.3.4 5.3.5 5.4
Interfaces dajout de ressource . . . . . . . . . . . . . . . . . . . . Interface de gestion de ressources . . . . . . . . . . . . . . . . . . Interface de lancement de job en mode asynchrone . . . . . . . . Interface de lancement dun job vers une carte . . . . . . . . . . . Liste descriptive des scripts DVP . . . . . . . . . . . . . . . . . . .
67 69 70 71 73 73 77 80 81 82
Tests et dploiement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Conclusion gnrale Bibliographie A Annexe A : Les APIs du ST TargetPack B Annexe B : Backlog du produit
Table des gures

1.1 1.2 2.1 2.2 3.1 3.2 3.3 3.4 3.5 3.6 3.7 4.1 4.2 4.3 4.4 4.5 4.6 4.7 4.8 4.9 Schma illustratif de SCRUM . . . . . . . . . . . . . . . . . . . . . . . . . Schma illustratif de la chaine de compilation . . . . . . . . . . . . . . . . Architecture de lElectric Commander . . . . . . . . . . . . . . . . . . . . Modle de distribution des travaux de LSF . . . . . . . . . . . . . . . . . Diagramme du cas dutilisation gnral . . . . . . . . . . . . . . . . . . . Diagramme du cas dutilisation Grer les jobs . . . . . . . . . . . . . . Diagramme du cas dutilisation Lancer un job . . . . . . . . . . . . . . Diagramme du cas dutilisation Choisir la plateforme dexcution . . Diagramme du cas dutilisation Dnir les relations de dpendances Diagramme du cas dutilisation Grer les ressources . . . . . . . . . . Diagramme du cas dutilisationGrer les utilisateurs . . . . . . . . . . Architecture gnrale du Distributed Validation Platform . . . . . . . . . Diagramme de composants de la DVP . . . . . . . . . . . . . . . . . . . . Architecture Model-View-Controller . . . . . . . . . . . . . . . . . . . . . Architecture dun script DVP . . . . . . . . . . . . . . . . . . . . . . . . . Diagramme dtat dun script DVP . . . . . . . . . . . . . . . . . . . . . . Diagramme de classe du Monitoring & Discovery Service . . . . . . . . . Diagramme UML du patron de conception Observator . . . . . . . . . . Diagramme UML du patron de conception Data Access Object . . . . . . Architecture de Hibernate . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 11 17 19 28 29 30 31 32 32 33 43 45 46 47 47 49 50 52 52 53
4.10 Diagramme de classe du package DataBaseManagement. . . . . . . . . . x
TABLE DES FIGURES
xi
4.11 Diagramme de classe du Job Execution Service . . . . . . . . . . . . . . . 4.12 Diagramme de squence de lajout dune carte . . . . . . . . . . . . . . . 4.13 Diagramme de squence du lancement dun job depuis un chier script. 4.14 Diagramme de squence de lancement dun job en mode asynchrone. . . 4.15 Diagramme de squence du lancement dun job dans un environnement embarqu. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5.1 5.2 5.3 5.4 5.5 5.6 5.7 5.8 Interface dajout de ressources . . . . . . . . . . . . . . . . . . . . . . . . . Exemple dajout de cartes . . . . . . . . . . . . . . . . . . . . . . . . . . . Fentre de suivi et de gestion des ressources . . . . . . . . . . . . . . . . Liste des ressources obtenue par un script DVP en ligne de commande . Fentre de lancement de job en mode asynchrone . . . . . . . . . . . . . Paramtrage dun job destin lexcution sur une carte . . . . . . . . . Slection dun chier binaire destin lexcution sur une carte . . . . . Organisation matrielle et logicielle pour la phase de test . . . . . . . . .
54 57 58 60
61 68 68 69 70 71 72 72 74
Liste des tableaux

1.1 3.1 3.2 3.3 3.4 3.5 3.6 Tableau comparatif de quelques mthodes agiles. . . . . . . . . . . . . . Liste prliminaire des cas dutilisation. . . . . . . . . . . . . . . . . . . . . Description dtaille du cas dutilisation Grer les ressources . . . . . Description dtaille du cas dutilisation Grer les utilisateurs . . . .
Description dtaille du cas dutilisation Lancer un job en mode synchrone . Description dtaille du cas dutilisation Lancer un job en mode asynchrone
8 26 34 35 36 37
Description dtaille du cas dutilisation Lancer un job depuis un script shell . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38 39 40 73 75
3.7 3.8 5.1 5.2
Description dtaille du cas dutilisation Interrompre un job . . . . .

Description dtaille du cas dutilisation Choisir la plateforme destination .
Liste non exhaustive des scripts DVP. . . . . . . . . . . . . . . . . . . . . Tests et scnarii de test. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
xii
Introduction gnrale
A ns
leur qute dune meilleure satisfaction de leurs clients, les grandes socits
sorientent de plus en plus vers lamlioration de la qualit de leurs produits.
Ladoption de bonnes pratiques tout au long du cycle de vie du produit an datteindre ce but est aujourdhui un choix stratgique voire invitable. Cest dans ce contexte quon parle de la validation, qui correspond au processus dvaluation du produit du dbut la n de son dveloppement ainsi que lors de sa maintenance. La phase de validation permet de sassurer que le produit satisfait aux normes et aux exigences ncessaires pour une utilisation spcique ou pour une application prvue.Dans le cadre de produits informatiques destins des environnements spciques savoir les environnements embarqus, la validation doit alors valuer les performances et la qualit du produit dans le contexte pour lequel il est destin an dobtenir des rsultats plus ralistes et plus consistants. Mais, derrire ce but se cachent de nombreux problmes et contraintes. En effet, le processus de validation en lui mme ncessite un investissement considrable que ce soit sur le plan budgtaire ou sur le plan de consommation de ressources matrielles et ncessite parfois, lorsque ce processus est faiblement automatis, une bonne gestion des ressources humaines. Cet investissement salourdit quand la quantit dinformations traiter devient norme et que les quipes intervenant dans le processus sont gographiquement disperses.
Les socits ont tendance, surmonter ces problmes en proposant des solutions adaptes leur environnement de travail et leurs produits.
Introduction gnrale
Cest dans ce cadre que se situe le sujet de notre projet de n dtudes effectu STMicroelectronics au sein de lquipe Compiler Expertise Center (CEC). Ce projet vise la dnition dune approche oriente service pour la distribution dun ensemble de tches dune compagne de validation des compilateurs dans un contexte embarqu. A cet effet, il nous a t demand de mettre en place une plateforme base sur larchitecture SOA (Service Oriented Approche) fournissant des services et des outils adapts aux diffrents prols des responsables de validation, visant la bonne gestion des ressources matrielles en faisant abstraction des emplacements et des types de ces dernires et permettant la cration, la distribution, lexcution et enn le suivi et la rcupration des rsultats des tches de validation.
Le prsent document dcrit en dtail la progression du projet stalant sur cinq chapitres :
Le premier chapitre introduit le cadre gnral du travail savoir le contexte, la mthodologie et annonce la n la problmatique que traite ce projet. Le second chapitre est consacr une tude analytique de certaines plateformes de distribution de tches existantes. Description et critiques nous ont permis la n de ce chapitre de proposer une solution de synthse. Dans le troisime chapitre, nous dtaillons les fonctionnalits issues de la proposition effectue dans le chapitre prcdent. Le quatrime chapitre est consacr la conception gnrale et dtaille de notre plateforme. Le cinquime chapitre expose le travail ralis en dcrivant les technologies utilises et en prsentant quelques captures dcran de certaines interfaces de lapplication.
Le rapport se termine par une conclusion qui tablit le bilan du travail et dresse les perspectives concernant les voies damlioration de lapproche adopte.
Chapitre 1 Prsentation du cadre du projet
prsent projet intitul, Mise en place dune plateforme de validation dans un
contexte embarqu, est ralis dans le cadre de la prparation dun mmoire de
n dtudes prsent en vue de lobtention du diplme dingnieur en informatique de lENSI pour lanne universitaire 2008/2009. Dans ce premier chapitre nous prsentons lorganisme daccueil et le cadre gnrale du travail. Puis, nous justions la mthodologie adopte pour enn noncer la problmatique du projet.
1.1
Organisme daccueil et cadre gnral
STMicroelectronics a t cre en 1987 suite la fusion de la socit italienne SGS Microelectronica et de la socit franaise Thomson. Initialement nomme SGS-THOMSON, la socit a t renomme par la suite STMicroelectronics en 1988 suite au retrait de Thomson. Elle est implante dans les quatre rgions principales (Europe, USA, Asie Pacique et Japon) avec une forte prsence en Europe (Grenoble/Crolles et Rousset pour la France, Milan et Catane pour lItalie). Cette socit fait partie des leaders dans la fabrication des semi-conducteurs. Elle comporte prs de 50 000 employs, 16 units de recherche et dveloppement avances, 39 centres de conception et dapplications, 13 principaux sites de production et 78 bureaux de vente dans 36 pays. En 2008, son chiffre daffaire net sest lev 9.84 milliards de dollars, [Net1].
CHAPITRE 1. PRSENTATION DU CADRE DU PROJET
1.1.1
ST Tunis
Le site de ST Tunis a t cr en dcembre 2001. Il dveloppe des logiciels dapplications lectroniques, des microcontrleurs et des microprocesseurs informatiques et automobiles. Il contribue au dveloppement dun grand nombre de circuits intgrs destins aux applications grand public, numrique, tels que les dcodeurs, les lecteurs DVD et les appareils photos numriques. Le site de ST Tunis a commenc avec 9 ingnieurs et continue dafcher une forte croissance avec, en avril 2009, 300 ingnieurs rpartis dans plusieurs quipes collaborant avec des divisions dans des sites en France, en Italie et en Angleterre.
1.1.2
Lquipe Compiler Expertise Center : centre dexpertise en compilation
Implante dans les quatre rgions suivantes : Tunis, Grenoble, Bristol et Crolles, cette quipe dveloppe des compilateurs C et C++ destins la commercialisation et lutilisation par dautres divisions de ST. Lquipe exerce les activits suivantes : La recherche dans le domaine des compilateurs o son expertise est reconnue internationalement. La production et la maintenance des outils industriels destins aux applications embarques au sein de ST : Les compilateurs C et C++. Les assembleurs et les compresseurs de code. Les librairies mathmatiques ainsi que les librairies C et C++. La validation des outils dvelopps. Laudit de technologie de compilation ou de compilateurs internes et externes. Sur le site de ST Tunis, lactivit de lquipe se base essentiellement sur la recherche, le dveloppement et la validation des compilateurs. A ce jour, 6 grandes familles de compilateurs sont en cours de validation.
1.2
Cadre gnral du projet
Bien que les outils mises la disposition des responsables du processus de validation, rpondent plus au moins aux besoins de ces derniers, le processus de validation lui mme fait face une multitude de difcults. Outre les problmes relatifs la gestion dune norme quantit de suites de tests, des tudes faites STMicroelectronics ont prouv un dsquilibrage de charges sur les ressources disponibles aux quipes de validation, en effet, nous avons remarqu que les ressources sont soit surcharges par des tches longues et coteuses soit libres. Une autre difcult est le cot budgtaire lev des composants embarqus tels que les cartes (appeles boards dans le jargon technique) et qui constituent une cible importante du processus de validation cause de limportance des rsultats qui en dcoulent. Les cycles processeurs ne sont pas la seule ressource sous-utilise. Souvent les capacits de stockage le sont aussi. De plus, la validation dploye repose essentiellement sur des commandes en lignes lances sous plusieurs plateformes ; Windows (natif via lenvironnement Mingwin ou Cygwin), Linux, Solaris. Face plusieurs scnarii dexcution, le responsable doit prendre en charge la mission de tirer des conclusions sur lexcution dune tche et de lchec dune autre ainsi que sur le taux dutilisation dune ressources ou dune autre pour pouvoir guider les choix stratgiques dajout ou dorganisation de ces dernires an dviter au maximum les problmes de surcharge et bien rpartir la charge sur les diffrentes ressources disponibles . Ceci ncessite davoir une ide globale sur le droulement des validations ainsi que sur lutilisation des ressources qui en rsulte. Cest dans cette optique que se situe notre projet. Mais avant de se lancer dans ltude du travail lui-mme nous allons prsenter dans ce qui suit la mthodologie de travail.
1.3
1.3.1
La mthodologie adopte
Les mthodes agiles
Les mthodes agiles, peuvent tre dnies comme des procdures de conception de logiciel qui se veulent plus pragmatiques que les mthodes traditionnelles. En impliquant au maximum le demandeur (client), ces mthodes permettent une grande ractivit ses demandes, visent la satisfaction relle du besoin du client, et non des termes du contrat de dveloppement . An de clarier cette notion encore un peu vague, nous allons noncer ses principes, ses fondements ainsi que les diffrences par rapport aux mthodes classiques : mettre en uvre des individualits et des interactions, plutt que des procds et des outils. Cela se manifeste par laccent mis sur les tres humains en tant quindividus et sur lexpertise des quipes de dveloppement, qui communiquent entre elles de faon trs serre et dans un esprit de conance constant. produire un logiciel entirement test et qui fonctionne, plutt quune documentation claire. On rejoint ici les notions de dveloppement itratif (notion de phases) et dintgration continue (notion de builds journaliers), en insistant sur la simplicit et la robustesse du code produit (tests systmatiques). collaborer avec le client, plutt que ngocier un contrat. Le client devient un partenaire part entire, qui participe au dveloppement dans le sens o il dtermine lobjectif atteindre pour obtenir une relle plus-value (qui seule justie les efforts effectus pendant le dveloppement). rpondre aux modications, plutt que suivre un plan. Il est bien vident que personne, pas mme le client, ne peut apprhender avec prcision lensemble des besoins ds le dbut du projet. Le dveloppement agile vise atteindre un compromis entre les spcications initiales prsentes aux dveloppeurs (et sur lequel se fonde le planning) et le rsultat nal qui bien souvent sen loigne un peu voire beaucoup, en absorbant les modications tout au long du cycle de dveloppement. Cela rclame des outils de suivi et une attitude constante de coopration avec le client.
1.3.2
Un comparatif des mthodes agiles
Au cours de cet paragraphe nous allons essayer de dgager les diffrences entre quelques unes des mthodes de dveloppement agiles les plus connues, et ceci en fournissant un tableau comparatif de ces dernires. Le tableau suivant,Tab 1.1, compare sommairement les mthodes courantes suivantes : Extreme Programming (XP). Rational Unied Process (RUP). Feature-Driven Development (FDD). Scrum
1.3.3
1.3.3.1
La mthodologie Scrum
Introduction la mthodologie Scrum
Le terme Scrum(qui signie mle en rugby) se rapproche plus dune gestion de ressources humaines plutt que dune relle mthode de dveloppement. Il sagit ici de ne pas oublier le ct humain du dveloppement. Les principales caractristiques de Scrum sont : Identier les changements trs tt. Donner toute conance aux dveloppeurs et les laisser faire leur travail. Faire des itrations variantes (gnralement de 30 jours), appels aussi sprints pour laisser le temps de coder. Chaque itration a un objectif bien prcis ou backlog et fournit une nouvelle fonctionnalit teste (une dmonstration est faite la n de chaque sprint). Faire des runions tous les jours (daily meeting) et chaque semaine (weekly meeting) pour encadrer les quipes et recaler les objectifs.
Mthode Points cls XP Dveloppement guid par les besoins du client. Equipes rduites, centres
Inconvnients Focalisation sur laspect individuel du dveloppement, au dtriment dune vue globale et des pratiques de management ou de formalisation. Risque de manquer de
sur les dveloppeurs par contrle et de structuration en laissant les binomes. Builds journaliers,amlioration constante, adaptativit aux modications.. dveloppeurs trop libres de driver par rapport aux fonctions de lapplication.
RUP Processus complet assist par des outils. Rles bien dnis.
Lourd, largement tendu, il peut tre difcile mettre en uvre de faon spcique. Convient pour les gros projets qui gnrent beaucoup de documentation.
Scrum
Petites quipes, itrations de 30 La mise en uvre du dveloppement nest jours, runions journalires. pas prcise, seule compte la gestion des ressources humaines.
FDD
Procd bien dni et simple, Uniquement centr sur le dveloppement. orient objet et bas sur le dveloppement. Itrations trs courtes.
TAB . 1.1 Tableau comparatif de quelques mthodes agiles. 1.3.3.2 Le choix de la mthodologie Scrum
Davantage quune mthode formelle, Scrum, illustr par la gure 1.1, peut tre vu comme un framework mthodologique dont limplmentation doit tre ajuste en fonction des caractristiques techniques, organisationnelles et culturelles des projets
qui souhaitent la mettre en uvre (Scrum, au demeurant, ne limite pas son champ dapplication aux seuls projets informatiques : ses principes sont applicables pour toute activit visant produire un rsultat).
F IG . 1.1 Schma illustratif de SCRUM
Dans ses grandes lignes, Scrum dnit un jeu minimal dacteurs, de crmonies et dartefacts qui permettent de relever les ds principaux du dveloppement incrmental : la planication, la gestion du temps et la gestion des obstacles. Scrum est entirement pilot par la Valeur Mtier. La gestion des risques, en particulier, est ralise au travers de ce prisme. Scrum identie trois acteurs : le Product Owner (Directeur de Produit), qui possde lexpertise fonctionnelle et est mme de raliser les arbitrages ncessaires la priorisation des dveloppements. Son rle est absolument essentiel, et son respect des rgles du jeu est la pierre angulaire du succs dun projet agile. le Scrum Master, membre de lEquipe, et dont la tche principale est doptimiser la capacit de production de lEquipe en laidant travailler de faon autonome et samliorer constamment. Il est galement le garant de la bonne implmentation de Scrum. lEquipe, dont la taille doit tre rduite, et qui prend en charge le dveloppement du
10
produit (planication, conception, codage, tests, documentation) sans spcialisation des rles. La particularit dune Equipe Scrum est dtre auto-organise , et donc dpourvue de hirarchie. Cet aspect constitue une rupture radicale avec les approches managriales traditionnelles, qui privilgient un contrle centralis gnralement incarn par le Chef de Projet. Les avantages cits ci-dessus se rvlent particulirement, bien adapts aux projets de n dtude dont les objectifs et la limitation temporelle sont parfaitement dlimits et connus. La pratique de la mthode Scrum dans lquipe CEC nous a donn lopportunit dtre intgr au sein de ce processus et de participer aux cycles de dveloppement. Aprs avoir fait le choix de la mthodologie, qui est une tape primordiale dans le cycle de dveloppement dun produit informatique, nous exposerons dans le paragraphe suivant la problmatique auquel nous sommes amens dvelopper une solution.
1.4
1.4.1
Problmatique
Rappel sur le principe de compilation
Dans le sens le plus usuel du terme, la compilation est une transformation que nous faisons subir un programme crit dans un langage volu pour le rendre excutable. Fondamentalement, cest une traduction dun texte crit en Pascal, C, Java ou tout autre langage de haut niveau exprimant un algorithme vers un autre texte spciant le mme algorithme dans le langage dune machine que nous cherchons programmer. La nature de ce qui sort dun compilateur est trs variable. Cela peut tre un programme excutable pour un processeur physique, ou un chier code pour une machine virtuelle, comme la machine Java, ou un code abstrait destin un outil qui en fera ultrieurement du code excutable, ou encore le codage dun arbre reprsentant la structure logique dun programme. En entre dun compilateur, nous trouvons toujours la mme chose : une suite de caractres appele le texte source. La gure1.2 illustre les phases dans lesquelles se dcompose le travail dun compilateur, du moins dun point de vue logique, [Bib1].
11
F IG . 1.2 Schma illustratif de la chaine de compilation
1.4.2
Le projet GNU : compilateurs et options de compilation
Il existe un compilateur disponible sur un grand nombre de plateformes : le compilateur du projet GNU. Pour le langage C, le compilateur GNU sappelle gcc ; pour le langage C++, il sagit de g++. Les options de compilation permettent de gnrer un code dont les performances seront adaptes aux besoins du dveloppeur. Ces options permettent aussi de gnrer un excutable qui pourra fonctionner avec un dbogueur, outil qui permet une excution conditionnelle du programme dans le sens o nous pouvons linterrompre pour un temps indtermin lexcution dun programme une phase choisie et que lon peut visualiser ltat des variables internes du programme chaque instant. Nous considrons tout dabord les options qui sont identiques pour les deux compilateurs disponibles : Pour permettre lutilisation du dbogueur, il faut utiliser loption de compilation -g. Cette option conduit un excutable de taille plus importante et gnralement
12
une performance moindre. Pour accrotre les performances lexcution, les options doptimisation sont pour les deux compilateurs de -O0 jusqua -O3.
1.4.3
La compilation dans un environnement embarqu
La compilation dans un contexte embarqu prsente quelques particularits. Mais avant de les aborder nous allons commencer par dnir un mot cl qui est la compilation croise(en anglais cross-compiler), en effet, un compilateur crois est un programme capable de traduire un code source en code objet ayant un environnement dexcution (architecture matrielle, systme dexploitation) diffrent de celui o la compilation a t effectue. Ces compilateurs sont principalement utiliss en informatique industrielle. GNU fournit une chane de compilation croise qui a t adapte par STMicroelectronics an de rpondre ses besoins. Lexcution des suites de tests de validation dans un contexte embarqu savre donc trs importante pour valuer les performances des diffrents codes compils dans lenvironnement rel pour lequel ils sont destins. Par consquent, toute plateforme de compilation doit offrir la possibilit de lancer des campagnes de validation sur des architectures matrielles, de pouvoir suivre leur excution et rcuprer les ventuels rsultats [Bib2].
1.4.4
Les modes dexcution et problmatique
Comme il a t dtaill dans le paragraphe 1.4.3, un programme peut tre excut sur une machine autre que celle o il a t compil. En effet, cela seffectue comme suit : La compilation seffectue dans un environnement standard sur une machine hte(host). Le rsultat de la compilation est un code binaire excutable sur la machine cible(target). La machine cible peut tre toute machine munie dun processeur capable dinterprter le code binaire rsultant de la phase de compilation, ainsi on distingue plusieurs modes dexcutions du code compil, qui sont disponibles au sein de lquipe. Lexcution sur une machine (un micro-ordinateur), sur diffrentes plateformes
13
savoir Linux, Windows, Solaris. . . Lexcution dans un environnement embarqu : les cartes. Une plateforme de validation doit alors fournir au responsable de validation la possibilit, via un ensemble vari doutils, de choisir la plateforme sur lequel son code sera excut, aprs avoir t compil. Lorsque les tests sont dploys sur les ressources partages de linfrastructure, le responsable de validation doit avoir une vue globale sur le processus dexcution et doit suivre son droulement (tat instantan, rsultat de lexcution, statistiques sur lutilisation des ressources. . .) avec la possibilit de contrler distance ses tests (lancement, interruption. . .).
1.5
Travail demand
Le travail demand consiste concevoir et implmenter une application base sur des services web permettant la distribution dun ensemble de tches de validation des compilateurs dans un contexte distribu embarqu. Lapplication doit alors offrir un ensemble de tches permettant de : Assurer lintgration de la distribution des tches de validation dun compilateur dans le contexte embarqu et donner lutilisateur le choix de choisir la plateforme de destination de ses tches. Fournir le diagnostic de lusage des ressources intervenantes dans la validation en termes de disponibilit, taux dutilisation . . . Garantir le suivi de lexcution des suites de tests et faciliter la rcupration des rsultats. Fournir lutilisateur une panoplie doutils an dexploiter au mieux les services offerts par lun outil existant et dvelopp au sein de lquipe et appel DVP pour Distributed Validation Platform (une interface graphique ainsi quun ensemble de commandes en ligne). Linterfaage avec dautre application en particulier loutil Cruise Control.
INTRODUCTION GENERALE
14
Conclusion
Aprs avoir prsent le cadre gnral de notre projet, prsenter les tapes mise en uvre lors de la validation et noncer la problmatique ainsi que le travail demand. Nous allons dans ce qui suit entamer une tude de lexistant pour mieux comprendre le cadre et lenvironnement du projet.
Chapitre 2 Etude de lexistant
A
2.1
FIN
datteindre les objectifs de notre projet, ltude des solutions existantes et
des diffrents moyens mis notre disposition est une tape invitable. En fait,
elle permet dabord de dcortiquer les fonctionnalits dj dveloppes et surtout de mettre en relief leurs limites. Ensuite, nous pouvons dgager les solutions envisageables qui peuvent faire face aux problmes lies aux solutions existantes.
Etude de lexistant : Analyse et critiques
Dans cette partie, nous commenons par donner une vue globale sur les solutions existantes, ainsi quune critique qui met laccent sur les points faibles et les dfaillances pour enn conclure avec une solution de synthse.
2.1.1
2.1.1.1
Electric Commander
Description
Electric Commander est une solution destine lautomatisation des processus de production des logiciels des entreprises, propose sa version 2.2 en 2005 par Electric Cloud, [Net2], elle permet au quipe de dveloppement, le suivi des builds, du pakaging, des tests et le dploiement rptitif dune manire plus claire et plus efcace. Larchitecture, hautement paramtrable, de Electrical Commander, 15
CHAPITRE 2. ETUDE DE LEXISTANT
16
dtaille la gure 2.1, permet aux quipes de dveloppement de dnir, modier et rutiliser facilement les processus de production de logiciels travers les diffrents produits, quipes et sites de production. Elle permet, entre autres, de rpondre aux besoins de reporting et de visibilit des processus des quipes, permettant ainsi une meilleur exibilit dans le partage et la circulation des donnes et des connaissances inter et intra quipes ainsi quune acclration, des itrations, exige par les mthodes agiles de dveloppement de logiciels. Les avantages majeurs de cet outil dcoulent essentiellement de son architecture base sur le web, permettant ainsi une meilleure utilisation des ressources disponibles et une exibilit distingue par rapport aux autres solutions existantes. On peut, galement, citer certaines fonctionnalits offertes savoir : Des cycles de dveloppement plus rapides et une utilisation plus efcace du matriel. Une plateforme distribue, plus adapte, au partage des bonnes pratiques et la rutilisation des procdures communes de dveloppement. Une meilleure gestion des quipes gographiquement disperses. Une meilleure qualit des logiciels grce lautomatisation des processus de buildet de test. 2.1.1.2 Critiques
Malgr ses avantages, ElectricCommander prsente quelques imperfections au niveau de son adaptation aux domaines dapplication particuliers de certaines entreprises .En effet, ces dernires, tel est le cas de STMicroelectronics, dveloppent leur propres plateformes de dveloppement et exigent des outils adapts leur besoin et ventuellement leurs matriels. Le Centre dExpertise en Compilation de STMicroelectronics a besoin de lancer les tches de validation sur les plateformes gnriques (Windows, Linux, Unix . . .) en mode de simulation mais galement, davoir la possibilit de lancer ces tches sur un environnement embarqu, pour lequel les applications sont essentiellement destines, et pouvoir ainsi rcuprer des rsultats plus ralistes et plus consistants. Lensemble doit se faire :
17
F IG . 2.1 Architecture de lElectric Commander
En exploitant au maximum les ressources disponibles pour ses quipes, dune manire plus intelligente, dans le sens de la bonne gestion et de lexploitation de ces ressources. En terme de exibilit des outils (une bonne adaptation au dveloppement spcique lentreprise). Ainsi, aprs avoir fait ltude de lElectricCommander, nous pouvons en tirer des avantages et des inconvnients qui seront un point de dpart dans la future spcication de nos propres besoins. Mais avant daller plus loin, tudions, dans le paragraphe suivant, une solution actuellement exploite STMicroelectronics savoir la LSF (Load Sharing Facility).
2.1.2
2.1.2.1
LSF (Load Sharing Facility)

Description
LSF est un systme commercial de distribution de charge et de gestion des les dattentes pour des travaux de type batch dans un environnement Unix htrogne. LSF gre le traitement des tches en offrant aux utilisateurs une seule vue des ressources matrielles et logicielles indpendamment des machines de groupe (grappe ou clus-
18
ter). LSF supporte les tches du type batch, interactif, et parallle, et les gre dans un groupe de machines en exploitant les machines et les serveurs inoccups. Spciquement, LSF offre les services suivants : Ordonnancement et gestion des tches batch dans des les dattente. Distribution des tches travers le rseau. Distribution de la charge sur les machines du rseau. Surveillance de la charge du rseau. LSF comporte un ensemble doutils dont le but est de rpartir la charge CPU sur les machines dun groupe et ceci de manire transparente pour les utilisateurs. Le mme environnement dexcution (ID utilisateur, variables denvironnement, rpertoire de travail, signaux, paramtres du terminal, etc.) est maintenu lorsque les tches sont envoyes pour excution distance. Loutil lsbatch permet la soumission des tches en mode batch sur un groupe de machines via des les dattente. lsbatch choisit la machine la moins charge en possession des ressources demandes. LSF repose sur le standard MPI Message Passing Interface qui est linterface de programmation la plus utilise pour le dveloppement dapplications parallles dans un environnement distribu. Elle est constitue dun ensemble de routines appeles par des programmes C, C++ ou Fortran. MPI est un standard disposant de nombreuses implmentations. Une application MPI est un programme constitu de processus qui communiquent par change de messages. La gure 2.2 schmatise le modle de soumission des travaux batch dans LSF. En rsum, LSF est largement rpandu dans le milieu universitaire et lindustrie et possde lavantage de considrer les machines appartenant lenvironnement distribu comme des ressources informatiques simples. Il est noter que LSF est multiplateformes mais il nest pas gratuit (licence dutilisation payante par processeur intgr dans lenvironnement LSF).
19
F IG . 2.2 Modle de distribution des travaux de LSF
2.1.2.2
Critiques
LSF na pas t conu dans un souci douverture ou de conformit des besoins spciques. En effet, il offre un support statique dans le sens o il est difcile de lenrichir et de ladapter une structure bien dtermine. Dans son implmentation utilise STMicroelectronics, LSF rpartit les tches excuter sur 3 classes en fonction de leur temps dexcution. Chaque classe est caractrise par un TTL (temps limite dexcution dune tache sur une machine). Vu le nombre limit de classes, une mauvaise utilisation des ressources peut se prsenter dans le cas o le temps dexcution dune tche est trs infrieur la TTL de sa classe. Par exemple une tche dont le temps dexcution est de trois jours nest omise de la le de LSF quaprs 20 jours. Au niveau du Centre dExpertise en Compilation, LSF est utilis pour laccomplissement de la tche de validation sur les plateformes Unix. Mais, il sest avr que les contraintes dutilisation de cet outil sur la plateforme Windows taient particulirement fortes avec une absence de support de lquipe IT. Ainsi, en priorit pour les machines Windows, lquipe a dcid de concevoir une nouvelle plateforme distribue de validation nomme Distributed Validation Platform (DVP) et dtendre sa porte pour prendre en compte la validation sur un environnement embarqu.
20
2.1.3
2.1.3.1
DVP (Distributed Validation Platform)

Description
Lide de la DVP est ne suite lapparition dun besoin au sein de lquipe CEC celui davoir une plateforme de validation distribue, performante et efcace mais surtout adapte au contexte gnrale dans lequel travaille lquipe. Elle est suppose, essentiellement, permettre lexcution des tches de la validation (appels jobs dans la terminologie de la DVP) sur les diffrentes ressources disponibles tout en permettant la rpartition de la charge et une gestion des ressources. Cette plateforme doit alors tre conue avec une architecture distribue, ce qui a t fait en premier lieu en sappuyant sur la technologie RMI. cette implmentation a recontr quelques limitations Utilisation des ressources petite chelle : la DVP est base sur la technologie RMI qui consiste manipuler des objets distants. Par contre, pour que ce fonctionnement simple puisse stablir, nous devons rester dans le rseau local de lentreprise (le numro de port de ces services va tre bloqu par le pare-feu) ce qui rend impossible lexploitation de toutes les ressources du groupe de validation disperses sur plusieurs sites. Temps de rponse : bien quelle est simple implmenter, RMI prsente un temps dexcution relativement long surtout lorsque la taille des informations vhiculs devient importante. Lquipe a opt, en 2008, pour une architecture oriente service. En effet, la nouvelle architecture permet de subdiviser les fonctionnalits de base de la plateforme de validation en un ensemble dapplications autonomes qui peuvent tre raliss individuellement ou en groupe sous forme de services web. Ces services web peuvent tre offerts par plusieurs fournisseurs de services et peuvent tre coupls pour effectuer des tches plus complexes, [Bib3] et [Bib4].
21
2.1.3.2
Critiques
Bien quelle ralise les objectifs de base pour lesquels elle a t conue, la nouvelle version de la DVP, comme toute nouvelle application rvle des points rafner ou des nouvelles fonctionnalits ajouter rsultant de lapparition de nouveaux besoins. Parmi les limitations de la DVP nous citerons : La restriction de lusage de la DVP sur un seul site de ST (celui o elle est dploye). La non prise en compte de la validation dans un environnement embarqu. Lindisponibilit dun systme de collecte de statistiques de synthse. Labsence dun systme dinformation statique (exemple : une base de donnes) pour le maintien des traces des oprations effectues ainsi que la gestion des ressources (disponibilit, transparence de laffectation des ressources. . .), et des utilisateurs de la plateforme. Ce qui engendre un risque de perte de ces informations en cas de dfaillance de lun des services web. La gestion de la concurrence aux ressources (le dattente. . .). Labsence dune interface offrant dautres applications la possibilit dexploiter les services offerts par la DVP.
2.2
La solution propose
Pour remdier aux diffrents problmes cits dans ce qui a prcd et proposer une application plus riche et plus robuste nous avons dcid de garder larchitecture web de lancienne plateforme pour diffrents raisons savoir : 1. Utilisation du rseau internet : un avantage signicatif des services web, relativement aux autres solutions darchitecture distribue, est son support des pare-feux (rewalls) : lutilisation du protocole HTTP sur le port 80, gnralement ouvert, leur permet de passer sans encombre les barrires de lentreprise. Cette facilit engendre dautres soucis de scurit, lutilisation par dfaut de ces caractristiques est trop permissive et ncessite une prise en compte de la scurit au niveau des protocoles.
22
Cette gestion est nanmoins ralisable grce un ensemble de librairies en Java an dassurer une transmission des donnes transactionnelles scurise. 2. La disponibilit permanente : la disponibilit permanente correspond aux capacits des web services tre actifs et disponibles partout sur un rseau, ou un groupe de rseaux, sans aucuns impacts sur ses fonctionnalits. 3. Faible couplage : sparation nette entre les interfaces et les implmentations. Une fois quun programme est publi en tant que web service, il est relativement simple de le dplacer grce au fait que ces services constituent une couche dabstraction des fonctionnalits logicielles par rapport linterface. 4. La possibilit de communiquer avec lenvironnement embarqu, prcisment les cartes, qui disposent dinterface sur le rseau (adresse IP. . .). 5. Louverture et linteroprabilit : lutilisation dune technologie base sur des standards ouverts (SOAP, XML). 6. Lvolutivit : permettant aux applications de greffer de nouveaux modules an de rpondre aux nouveaux besoins fonctionnel. Nous avons aussi propos une nouvelle architecture des diffrents modules de la plateforme par rapport la solution actuelle ainsi quun ensemble daddition visant lajout de nouvelles fonctionnalits dont : Proposer et implmenter une refonte du service responsable de la gestion des ressources an de permettre une gestion plus facile et plus performante des ressources. Excuter les tches de validation sur un environnement embarqu (cartes) et intgrer cette fonctionnalit dans la plateforme existante. Concevoir et implmenter un ensemble riche doutils permettant lutilisateur dexploiter au mieux les fonctionnalits de la DVP. La gestion de la distribution des tches de validation (jobs) selon les ressources disponibles. Maintenir une trace de la distribution des jobs ainsi quun ensemble de statistiques concernant lexcution (propritaire de job, statuts instantan, target).
23
Concevoir et implmenter une interface web ainsi quun ensemble de scripts en ligne de commandes permettant un utilisateur dinteragir avec la plateforme de nimporte quelle machine connecte au rseau de STMicroelectronics. Une interface permettant dautres applications, dexploiter les fonctionnalits offertes par la DVP.
Conclusion
Aprs avoir donn une vision globale sur lexistant, nous avons vu la solution propose. Pour le chapitre suivant, nous allons examiner en dtails cette dernire an de spcier les besoins fonctionnels et non fonctionnels de la solution mettre en place.
Chapitre 3 Spcications
PRS
ltude de lexistant et la proposition dune solution thorique ,cette phase
consiste cadrer le projet et dnir ses cas dutilisation an de mieux le situer
dans son contexte gnral, en particulier en identiant toutes les entits externes qui vont interagir avec la plateforme, et en dnissant la nature de cette interaction dune faon gnrale. Pour cela, nous allons commencer par prsenter les besoins fonctionnels, les besoins non fonctionnels pour enn terminer avec la prsentation de quelques cas dutilisation.
3.1
Besoins fonctionnels
Ce paragraphe vise la capture des besoins fonctionnels bauchs durant la proposition de la solution en dnissant les besoins par acteur puis en proposant une liste prliminaires de cas dutilisation.
3.1.1
Dnition des acteurs
Lacteur principal qui interagit avec la plateforme est lutilisateur de la DVP. Certains de ces utilisateurs ont, en plus, un privilge dadministrateur qui leur permet deffectuer des oprations de gestion de ressources et des utilisateurs. Do nous dgageons deux acteurs principaux qui, tous les deux, hritent des fonctionnalits de lacteur principal savoir : 24
CHAPITRE 3. SPCIFICATIONS
25
Ladministrateur de la plateforme Ladministrateur (autorit principale daccs) est un acteur indispensable pour assurer la mise en exploitation du systme. Il joue un rle crucial pour assurer son bon fonctionnement. Cest, en fait, la personne qui a la charge de la gestion de ressources matrielles sur lequel vont se drouler les tests de validation (ajout, suppression, modication . . .) ainsi que la gestion des utilisateurs et de la politique de gestion de la concurrence entre les jobs lance par les utilisateurs. Le responsable de validation Personne responsable de la validation charge de lancer les suites de tests sur des plateformes varies et de poursuivre et surtout de contrler le droulement de tout le processus. Les actions principales qui sont la charge du responsable de validation sont : Paramtrer les suites de tests lancer avec les options adquates, aprs avoir entamer la phase de compilation. Paramtrer la phase de lexcution sur un host distant qui comporte la phase du choix de la plateforme destination ainsi que la dnition de lidentiant unique de son job, nom . . ., et la phase de dnition de dpendances de son job par rapport dautre jobs existants. Le suivi de ses jobs (suivre ltat : en cours dexcution, en attente, interrompue, ni), la possibilit dinterrompre un job, distance, et en dpit de la plateforme destination. Rcuprer les rsultats de ses tests de validation soit en ligne soit sous forme de chiers.
3.1.2
Liste prliminaire des cas dutilisation
Dans ce qui suit nous allons prsenter des cas dutilisation basiques de notre systme :
26
Cas dutilisation
Les acteurs participants
Message(s) mis/reus
Grer les utilisateurs
Administrateur mis : Demande de cration dun prol, mise jour, suppression. . . Reus : Rsultat ou un message derreur.
Grer les ressources
Administrateur mis : Ajout, suppression, obtenir la liste des ressources avec ltat de disponibilit. . . Reus : Le rsultat de lopration o un message derreur.
Grer les jobs Utilisateur Administrateur mis : Les paramtres du job (nom, groupe dappartenance, la com-
mande excuter..) et le mode dexcution (synchrone, asynchrone, depuis un chier. . .), demande
dinterruption. . . Reus : le rsultat retourn suite lexcution de lopration sur la machine destination o un message derreur.
TAB . 3.1 Liste prliminaire des cas dutilisation.
27
3.2
Besoins non fonctionnels
Outre les besoins fonctionnels cits ci-dessus, pour bien rpondre aux exigences des utilisateurs, la DVP doit assurer les besoins non fonctionnels suivants : Facilit La DVP doit tre facile utiliser et ne requiert aucun pr requis, lutilisateur doit disposer dun aide lui permettant dexploiter, aisment, les fonctionnalits de la DVP. Performance La DVP doit tre able par rapport aux outils commerciaux existants. Scurit Les changes entre les diffrentes entits doit se faire dune manire scurise. Tolrance aux pannes La DVP doit prvoir des mcanismes de reprises en cas dventuels pannes dune ou de plusieurs machines. Maintenabilit Larchitecture de la DVP doit permettre lvolution (ajout ou suppression) au niveau de ses diffrents modules dune manire exible.
3.3
Diagrammes des cas dutilisation
Les cas dutilisation permettent de dnir dune manire normalise les relations fonctionnelles entre les acteurs et le systme tudi. Le format de reprsentation dun cas dutilisation est compltement libre mais UML (Unied Modeling Language) propose un formalisme et des concepts issus de bonnes pratiques. Le diagramme de cas dutilisation, quant lui, permet de reprsenter visuellement une squence dactions ralises par lacteur en interaction avec le systme, produisant un rsultat et ceci indpendamment du fonctionnement interne de ce dernier. Ce qui va nous permettre de faire ltude du contexte fonctionnel du systme, en dcrivant les diffrentes faons quauront les acteurs pour utiliser le futur systme.
28
Dans le paragraphe suivant nous allons donner une vue gnrale simplie de lensemble des cas dutilisation, prcdemment dcrits, puis nous allons les dtaill un par un pour enn proposer pour chacun une che descriptive de lintention de lacteur ainsi que des squences dactions principales quil est susceptibles deffectuer.
3.3.1
Diagramme du cas dutilisation gnral
Dans le diagramme du cas dutilisation gnral on regroupe toutes les cas dutilisation de base an davoir une vue globale du fonctionnement de notre systme et an de mettre en vidence les ventuels relations qui peuvent les lier.
F IG . 3.1 Diagramme du cas dutilisation gnral
Aprs avoir expos le diagramme du cas dutilisation gnral nous allons aborder avec plus de dtailles chaque cas dutilisation prcdemment cit.
3.3.2
Diagramme du cas dutilisation Grer les jobs
La gure 3.2 montre les principales actions quun utilisateur quelconque de la DVP peut effectuer pour lancer et par la suite grer ses jobs .En effet, pour lancer un job,
29
lutilisateur doit prciser certains paramtres savoir le choix du mode dexcution, le choix du target (en prcisant la plateforme destination) et enn, dnir si elles existent, les ventuelles relations de dpendances (lexcution du job dpend de ltat dun job ou dun group de jobs). Aprs avoir lanc la phase dexcution lutilisateur peut suivre ltat de son job ( running , waiting , nished, interrupted) et peut ventuellement en cas de besoin linterrompre. Enn, il peut rcuprer le rsultat dexcution de son job .
F IG . 3.2 Diagramme du cas dutilisation Grer les jobs
An de clarier ce cas dutilisation nous allons prciser, dans ce qui suit, certains sous-cas dutilisation savoir Lancer un job , Choisir la plateforme dexcution et Dnir les relations de dpendances .
30
3.3.2.1
Diagramme du cas dutilisation Lancer un job
Lutilisateur, comme dcrit par la gure 3.3, a le choix entre plusieurs modes pour le lancement de son job savoir le lancement en mode synchrone, asynchrone ou depuis un chier script.
F IG . 3.3 Diagramme du cas dutilisation Lancer un job
3.3.2.2
Diagramme du cas dutilisation Choisir la plateforme dexcution
Lutilisateur a la possibilit de choisir la plateforme destination sur laquelle son job sera excut. Ceci permet la DVP, selon son choix, soit de lui affecter une ressource conformment ses prfrences soit de lui ltrer les ressources (ne laisser que celles conformes) et lui laisser le choix den choisir une.
31
La gure 3.4 suivante illustre ce cas dutilisation.
F IG . 3.4 Diagramme du cas dutilisation Choisir la plateforme dexcution
3.3.2.3
Diagramme du cas dutilisation Dnir les relations de dpendances
Dans certains cas de gure le lancement dun job dpend de lexcution dun autre (exemple : un job A utilise le rsultat dun job B) ou bien lexcution de plusieurs jobs doit seffectuer dans un ordre squentiel .Ce cas dutilisation est dcrit par la gure 3.5.
3.3.3
Diagramme du cas dutilisation Grer les ressources
La gestion des ressources est une opration qui ncessite le privilge administrateur, ladministrateur peut ajouter, supprimer ou bien vrier la disponibilit dune ressource. Le cas particulier dajout de carte ncessite lajout de certains paramtres dont ceux du botier de connection (appel micro connect) reliant la carte au rseau informatique, an de permettre par la suite lexcution sur cette carte. La gure 3.6 illustre ce cas dutilisation. De plus, dans chaque site ladministrateur doit lire une machine qui servira de pont entre la DVP et les cartes dans ce site (nomm Master).
32
F IG . 3.5 Diagramme du cas dutilisation Dnir les relations de dpendances
F IG . 3.6 Diagramme du cas dutilisation Grer les ressources
3.3.4
Diagramme du cas dutilisation Grer les utilisateurs
La gestion des utilisateurs, qui regroupe les fonctionnalits dajout de suppression et de mise jour des prols des utilisateurs, ncessite le privilge administrateur. La
33
gure suivante, gure 3.7, illustre ce cas dutilisation.
F IG . 3.7 Diagramme du cas dutilisationGrer les utilisateurs
3.4
Description dtaille des cas dutilisation
Chaque cas dutilisation doit faire lobjet dune dnition priori qui dcrit lintention de lacteur lorsquil utilise le systme et les squences dactions principales quil est susceptible deffectuer. Ces dnitions servent xer les ides lors de lidentication des cas dutilisation. Dans ce paragraphe, nous prsentons, pour chaque cas dutilisation, une che descriptive.
Le tableau suivant prsente une che descriptive du cas dutilisation Grer les ressources
34
Sommaire didentication Titre : Grer les ressources. But : Permettre la gestion des ressources contrles par la DVP. Rsum : Permettre un administrateur de la DVP dajouter, de supprimer ou de mettre jour les coordonnes dune ressource an de la mettre la disposition des utilisateurs pour excuter leurs jobs.
Description des enchanements Enchanement : Lutilisateur fait entrer les paramtres de lopration.
TAB . 3.2 Description dtaille du cas dutilisation Grer les ressources Le tableau suivant prsente une che descriptive du cas dutilisation Grer les utilisateurs Le lancement de jobs sur des machines distantes et la fonctionnalit de base offerte par la DVP, pour bien la dtailler on a clat ce cas dutilisation en trois cas dutilisation selon les modes de lancement de job choisi par lutilisateur et quon va traiter dans ce qui suit.
35
Sommaire didentication Titre : Grer les utilisateurs. But : Permettre la gestion des utilisateurs de la DVP. Rsum : Permettre ladministrateur de consulter, ajouter, mettre jour et de supprimer un utilisateur de la DVP.
Description des enchanements Enchanement Ladministrateur choisit lopration effectuer : Ajout : en prcisant les donnes de lutilisateur avec ses droits daccs. Suppression : slectionner un utilisateur supprimer. Mise jour : slectionner lutilisateur cible et entrer les nouvelles coordonns et/ou droit daccs.
TAB . 3.3 Description dtaille du cas dutilisation Grer les utilisateurs Le tableau suivant prsente une che descriptive du cas dutilisation Lancer un job en mode synchrone :
36
Sommaire didentication Titre : Lancer un job en mode synchrone. But : Lancer un job depuis nimporte quel terminal. Rsum : Permettre aux utilisateurs qui ont le droit dutiliser la DVP de lancer leurs jobs sur toute machine inscrite dans la liste des machines disponibles(en respectant la concurrence dans laccs aux ressources). Lutilisateur est bloqu dans lattente du rsultat de lexcution sur la machine distante.
Description des enchanements Enchanement : Lacteur du systme paramtre son job (nom, groupe dappartenance, com-
mande excuter. . .). Lacteur fait le choix du mode dexcution (en mode embarqu ou en mode simulation) Choisit la ressource adquate par rapport celle disponible ou bien il laisse la main la DVP pour lui affecter une machine selon ses prfrences (en ne prcisant aucune ressource cible).
TAB . 3.4 Description dtaille du cas dutilisation Lancer un job en mode synchrone Le tableau suivant prsente une che descriptive du cas dutilisation du deuxime mode de lancement de job quon a not Lancer un job en mode synchrone :
37
Sommaire didentication Titre : Lancer un job en mode asynchrone. But : Lancer un job depuis tout terminal connect au rseau de ST. Rsum : Permettre aux utilisateurs qui ont le droit dutiliser la DVP de lancer leurs jobs sur toute machine inscrite dans la liste des machines disponibles (en respectant la concurrence aux ressources). Lutilisateur ne se bloque pas en attente du rsultat et il sera noti la n de lexcution de son job en recevant le rsultat de lexcution.
Description des enchanements Enchanement : Lacteur fait le choix du mode dexcution (en mode embarqu ou en mode simulation) Choisit la ressource adquate par rapport celles disponibles ou bien il laisse la main la DVP pour lui affecter une machine selon ses prfrences.
TAB . 3.5 Description dtaille du cas dutilisation Lancer un job en mode asynchrone Le tableau suivant prsente une che descriptive du cas dutilisation du troisime mode de lancement de job quon a not Lancer un job depuis un script shell :
38
Sommaire didentication Titre : Lancer un job depuis un script shell. But : Slectionner un chier script depuis le disque local et lexcuter sur une machine distante. Rsum : Envoyer un chier script vers toute machine inscrite pour y excuter ce dernier (en respectant la concurrence aux ressources). Lutilisateur sera noti la n de lexcution.
Description des enchanements Enchanement : Lacteur du systme paramtre son job (nom, groupe dappartenance, com-
mande excuter. . .). Lacteur fait le choix du mode dexcution (en mode embarqu ou en mode simulation). Choisit la ressource adquate par rapport celles disponibles ou bien il donne la main la DVP pour lui affecter une machine selon ses prfrences.
TAB . 3.6 Description dtaille du cas dutilisation Lancer un job depuis un script shell Le tableau suivant prsente une che descriptive du cas dutilisation Interrompre un job :
39
Sommaire didentication Titre : Interrompre un job . But : Interrompre lexcution distante dun job. Rsum : Permettre un utilisateur ayant lanc un job via la DVP dinterrompre lexcution de son job en dpit de la plateforme destination (PC ou board). Permettre un administrateur dinterrompre un job lanc.
Description des enchanements Enchanement : Lutilisateur rcupre lidentiant unique de son job ou bien celui dune famille de jobs . Lance le script dinterruption avec en paramtre cet identiant. Slectionne, dans linterface web, un job dans la liste des jobs et choisit la commande dinterruption kill.
TAB . 3.7 Description dtaille du cas dutilisation Interrompre un job Le tableau suivant prsente une che descriptive du cas dutilisationChoisir la plateforme destination :
40
Sommaire didentication Titre : Choisir la plateforme destination . But : Orienter le job vers une machine conforme aux prfrences de lutilisateur. Rsum : Lutilisateur, guid par la DVP, choisit la plateforme o son job sera excut :
Mingw ou Cygwin . . .,dans le cas dune machine. OS21 . . .,dans le cas dune (carte).
Description des enchanements Enchanement : Trois cas se prsentent : Lutilisateur choisit un environnement embarqu dexcution : donne une slection de prfrences sur les caractristiques de la carte. Lutilisateur choisit un environnement machine et choisit une machine parmi celles disponibles. Lutilisateur donne ses prfrences en prcisant ( machine ou carte ) et laisse la DVP lui affecter, automatiquement, une ressource disponible (dont le CPU est le moins charg).
TAB . 3.8 Description dtaille du cas dutilisation Choisir la plateforme destination
41
Conclusion
Durant ce chapitre, nous avons expliqu comment utiliser le concept central de cas dutilisation et prparer lanalyse oriente objet. En effet, pour chaque cas dutilisation, nous avons vu comment identier les classes candidates du modle statique danalyse.
Chapitre 4 Conception
chapitre sera consacr la conception du systme. Nous psentons, en premier
lieu, son architecture gnrale an den extraire les diffrents modules qui le
composent. Puis, nous dtaillons chacun de ces modules conformment la notation UML, en prsentant les vues statiques dcrivant ltat physique du systme via le diagramme de composants et des diagrammes de classe, et les vues dynamiques montrant le fonctionnement du systme via des diagrammes de squences.
4.1
Conception gnrale
Nous allons dans ce qui suit prsenter larchitecture gnrale de notre systme et dgager les diffrents modules qui le composent.
4.1.1
Architecture gnrale de la plateforme
Larchitecture gnrale de la plateforme, illustre par la gure 4.1, met laccent sur les diffrentes entits exploites par la DVP et nous permet ainsi davoir une vue globale sur la rpartition des diffrents modules par fonctionnalit et par site.
42
CHAPITRE 4. CONCEPTION
43
F IG . 4.1 Architecture gnrale du Distributed Validation Platform
A partir de larchitecture gnrale de notre plateforme, qui sera bti sur les services web conformment la solution propose au dbut et dtaille, dans le paragraphe 2.2, nous pouvons facilement distinguer trois entits ou modules qui composeront notre plateforme savoir : Le premier module est relatif la gestion des ressources, modlis par une machine o est dploy le Monitoring & Discovery Service qui a pour tche principale la gestion des ressources participantes la phase dexcution des jobs en permettant des oprations de gestion du groupe de machines ,disponibles et prtes recueillir les jobs des utilisateurs, tels que lajout ou la suppression et le suivi de leurs disponibilits. Enn ce service sera le carrefour partir duquel transitent toutes les requtes en provenance ou ayant pour destination les applica-
44
tions clientes de la DVP. Ce module aura aussi pour rle dassurer la communication avec la base de donnes (sauvegarde de lhistorique des jobs, fonction de reprise en cas de panne). Le deuxime module est relatif lexcution des jobs sur les ressources distantes.Il est responsable de recevoir les jobs, de les excuter puis de retourner le rsultat lutilisateur.Il est modlis par une machine o est dploy le Job Execution Service ou une machine qui contrle une carte (faire le lien entre lenvironnement machine et lenvironnement embarqu). Le troisime module est relatif aux clients exploitant les fonctionnalits offertes par la DVP. Il est modlis quant lui et selon les besoins de lutilisateur par une interface web ou des scripts en ligne de commande dont le rle est dinterroger les services cits ci-dessus notamment le lancement et par la suite la gestion des jobs ou dans le cas dun administrateur la gestion des ressources ou la gestion des utilisateurs.
4.1.2
Diagramme de composants
Les diagrammes de composants permettent de dcrire larchitecture physique et statique dune application en termes de modules. Les composants peuvent tre organiss en paquetages, ou en sous-systmes du systme globale, dans le diagramme suivant,4.2, nous dnissons le diagramme de composants de notre systme en regroupant les composants par service web.
4.1.3
Architecture dune application cliente
Une application cliente la DVP permet un utilisateur de requter les services web dploys par la DVP mais vu les diffrents besoins des utilisateurs, explicits dans le paragraphe 3.1, nous avons dcid de concevoir et implmenter deux types de client dont voici les architectures gnrales.
45
F IG . 4.2 Diagramme de composants de la DVP
4.1.3.1
Architecture de linterface web
Pour linterface web nous avons opt pour la technologie JSF (Java Server Faces) en collaboration avec la technologie ExtJS (Extended JavaScript) (bas elle mme sur la technologie Ajax), an davoir une meilleure ergonomie de lapplication et proter des avantages de ces dernires, en particulier la possibilit de recharger chaud les pages web (rpondre au besoin du suivi instantane de ltat de la DVP, en particulier ltat des ressources pour un administrateur et celle des jobs pour les autres utilisateurs). JSF nous a permit dimplmenter larchitecture MVC (Model View Controller), aussi connu par modle-vue-contrleur, qui permet de sparer, lIHM dune application web, en trois modles savoir : modle de donnes, interface utilisateur et un contrleur. La gure 4.3 illustre larchitecture MVC. Ainsi les composants de notre interface web seront rpartis sur trois couches : La couche Vue : elle correspond lIHM. Elle prsente les donnes et interagit
46
F IG . 4.3 Architecture Model-View-Controller
avec lutilisateur. La couche Contrleur : elle se charge dintercepter les requtes de lutilisateur et dappeler le modle puis de rediriger vers la vue adquate. La couche Modle : elle reprsente les donnes et les rgles mtiers. Cette couche implmente les diffrents modules de lapplication en exploitant les diffrents services web disponibles. 4.1.3.2 Architecture dun script DVP
Lavantage des scripts DVP, mise part lusage ordinaire par un simple utilisateur, est de permettre dautres applications dexploiter les services de la DVP simplement en insrant un script DVP dans leurs propres codes. La connexion au service web, tant non possible avec un simple script shell, les scripts DVP doivent utiliser un client capable dinterroger et de requter un service web. Nous avons opt donc pour la conception de clients en Java (vu la richesse et la facilit des outils disponibles) et avons adopt larchitecture suivante, illustre par la gure 4.4, le diagramme dtat,4.5, illustrant quant lui le comportement du script pendant un cas dutilisation ordinaire.
47
F IG . 4.4 Architecture dun script DVP
F IG . 4.5 Diagramme dtat dun script DVP
4.2
Conception dtaille
Dans cette partie nous allons entrer dans les dtails conceptuels de notre plateforme. Nous commencerons par les diagrammes de classes des services web, puis nous modliserons laspect dynamique du systme laide des diagrammes de squences.
48
4.2.1
Conception des services web
Dans cette partie nous allons dtailler la conception des composants dclars dans le diagramme de composants(gure 4.2) 4.2.1.1 Monitoring and Discovery Service
Dans ce qui suit nous allons prsenter le diagramme de classe du service web Monitoring & Discovery Service (gure 4.6), ainsi que les diffrentes entits qui le composent. Nous aborderons en dtail certaines dentre elles. Il est noter que le diagramme de classe du package DataBaseManagement nest pas complet et sera dcrit par la suite. Ce service est responsable de la gestion de la grille des ressources. En effet, il assure : Le maintient de la liste des ressources, classes par type (machine, carte . . .). Chaque ressource est reprsente par une instance de lune des deux classes, hritires, de la classe Host savoir : La classe Machine pour dsigner une machine avec toutes les informations ncessaires sur cette dernire (nom, local, adresse IP. . .). La classe Board pour dsigner une carte avec toutes les informations ncessaires sur cette dernire ainsi que des informations sur le micro connect qui lui est attach (an de permettre, par la suite, lchange des donnes avec la carte).
49
F IG . 4.6 Diagramme de classe du Monitoring & Discovery Service
Le suivi instantan de ltat de dploiement du service Job Execution Servicesur les ressources maintenues par la DVP (autrement dit celles capables de recevoir les jobs des utilisateurs). Cette fonctionnalit est assure par limplmentation du patron de conception Observator, dcrit par la gure 4.7, qui dnit des observateurs en attente de signaux en provenance des observables pour effectuer laction, prdnie, correspondante. Dans notre cas les observables sont les machines o est dploy le Job Execution Serviceet lobservateur est la classe RessourcesPatternObservator.
50
F IG . 4.7 Diagramme UML du patron de conception Observator Lexcution des commandes de gestion de ressources et des utilisateurs tels que lajout, la suppression ou la modication des informations concernant une ressource ou un utilisateur.
La synchronisation des informations maintenues dans le service (dans des structures de donnes dynamiques tels que les conteneurs . . .) avec celles de la base de donnes (ceci est fait chaque nombre N de jour, prdni, pour viter un usage excessif de la base donnes). Cette fonctionnalit est assure par le package DataBaseManagement qui implmente le patron de conception Objet daccs aux donnes ou DAO (Data Access Object), dcrit par la gure 4.8. En effet, les objets en mmoire vive sont souvent lis des donnes persistantes (stockes en base de donnes, dans des chiers, dans des annuaires, etc.). Le DAO propose de dvelopper, dans des modules part, les mthodes daccs la base de donnes, plutt que de les intgrer, au besoin, dans les classes de la couche mtier du modle MVC dj explicit dans le paragraphe 4.1.3.1.
51
Il peut exister autant de types de DAO que de moyens de persistance des donnes, des bibliothques logicielles sont dailleurs conues spciquement pour prendre en charge ces aspects comme Hibernate, dont larchitecture est dcrite par la gure 4.9, et qui donne une solution pour le mapping objet/relationnel et la gestion de la couche de persistance .
Hibernate permet la gestion automatique de la structure de la base de donnes : cration et mise jour .Il utilise un langage simple pour linterrogation de la base de donnes appel HQL (Hibernate Query Language) et fournit une couche dabstraction par rapport SQL (Structured Query Language).
En conclusion,il apporte donc une solution aux problmes dadaptation entre le paradigme objet et les SGBD (Systme de Gestion de Base de Donnes) en remplaant les accs la base de donnes par des appels des mthodes objet de haut niveau, ce qui est parfaitement adapt notre solution.
52
F IG . 4.8 Diagramme UML du patron de conception Data Access Object
F IG . 4.9 Architecture de Hibernate
53
Do enn le diagramme de classe du package DataBaseManagement illustr par la gure 4.10.
F IG . 4.10 Diagramme de classe du package DataBaseManagement.
54
4.2.1.2
Job Execution Service
Dans ce qui suit nous allons prsenter le diagramme de classe du service Job Execution Service et dtailler les diffrentes entits qui le composent.
F IG . 4.11 Diagramme de classe du Job Execution Service
Le rle essentiel de ce service est lexcution des jobs des utilisateurs, en effet il assure :
55
La rception des jobs sous forme de commandes classiques (make, source. . .) et les excute sur la machine o il est dploy. La rception, lanalyse et lexcution de chiers scripts shell en provenance des utilisateurs ( les chiers parviennent sous forme dattachements un message SOAP(Simple Object Access Protocol), lenvoi et la rception des chiers est fait grce lAPI SOAP with Attachement ). Cette fonctionnalit est assure par la classe MessageHandler, qui reste lcoute de larriv dun message SOAP, dtecte un ventuel chier attach et ensuite effectue les oprations adquates. Enn il renvoie, le rsultat de lexcution, lutilisateur. Lorientation des jobs vers la carte sous son contrle. Cette fonctionnalit est assure par la classe BoardConnection, qui permet de : Recevoir les chiers binaires en provenance des utilisateurs (le mcanisme denvoie et de rception de chier et le mme que celui dcrit prcdemment). Formuler la commande adquate pour la connexion la carte (la syntaxe de la commande varie selon le type du micro contrleur rattach la carte ;la procdure de connexion la carte, quant elle, ne dpend que de la conguration de la carte elle mme). Se connecter et envoyer le chier binaire au micro contrleur qui se charge son tour de le transmettre la carte. Rcuprer le rsultat de lexcution et le renvoyer lutilisateur. Interrompre un job dj en excution sur la carte. Le stockage des rsultats de lexcutions des diffrents jobs, sur le disque local de la machine o il est dploy et garder une trace de tout les jobs ayant t excuts sur cette machine an de permettre un utilisateur de rcuprer tout moment le rsultat de lexcution de son job. Aprs avoir abord la partie statique de notre systme en prsentant le diagramme de composants et les diagrammes de classes, nous abordons dans la partie suivante la partie dynamique via les diagrammes de squences.
56
4.2.2
Diagrammes de squences
Un diagramme de squence reprsente, graphiquement, les diffrentes interactions entre lacteur et le systme dans lordre chronologique de leur droulement. Dans ce qui suit nous allons prsenter quatre diagrammes de squences, illustrant quatre scnarios de cas dutilisation diffrentes savoir : Lajout dune carte. Le lancement dun job sur un environnement de simulation depuis un chier script. Le lancement dun job en mode asynchrone. Le lancement dun job sur un environnement embarqu (une carte). 4.2.2.1 Diagramme de squence de lajout dune carte
Le diagramme suivant, gure 4.15, illustre un scnario dajout dune carte effectu par un administrateur de la DVP en interaction avec le Monitoring & Discovery Service. Les paramtres entrs par ladministrateur (nom de la carte, adresse IP, le type du micro contrleur) sont transmis lapplication cliente (client du service web), cette dernire prennant en charge linvocation de la mthode dajout expose par le Monitoring & Discovery Service. La dernire tape avant lexcution de lopration consiste vrier les droits de lutilisateur. Le service ajoute la carte aux structures de donnes quil maintient et passe ces paramtres au DataBaseUpdater qui se charge de crer un objet hritant de la classe Board, formuler la requte HQL, et ouvre enn une session Hibernate, SessionFactory, partir duquel transite la transaction pour enn effectuer la mise jour au niveau de la base de donns. Lutilisateur reoit la n de lopration le rsultat (soit une notication du succs de lopration soit la cause de lchec).
57
F IG . 4.12 Diagramme de squence de lajout dune carte
4.2.2.2
Diagramme de squence de lancement de job depuis un chier script
Le diagramme suivant, gure 4.13, illustre le lancement dun job par un utilisateur en excutant un chier script shell sur une machine distante. Lutilisateur passe la plateforme choisie lapplication cliente via lIHM. Le Monitoring & Discovery Service renvoie lapplication cliente, layant dj invoqu, le nom de la machine disponible, rpondant ses prfrences et la moins charge en CPU (processeur). Dans ce cas de gure nous avons trait le cas particulier daffectation automatique de machine, mais lutilisateur peut galement choisir manuellement la machine sur laquelle son job sera excut. Lutilisateur paramtre, alors son job, en prcisant son identiant, son groupe dappartenance, . . .et prcise enn lemplacement du chier sur son disque. Lapplication cliente construit un message SOAP (entte et corps) contenant
58
les paramtres du job et lui attache le chier script. Enn elle envoie ce message. Le MessageHandler, en coute, dtecte larrive dun message SOAP lanalyse, en extrait le chier attach et alerte le JobExecutionService qui se charge de lexcution du chier et renvoie le rsultat qui sera nalement visualis par lutilisateur.
F IG . 4.13 Diagramme de squence du lancement dun job depuis un chier script.
4.2.2.3
Diagramme de squence de lancement de job en mode asynchrone
Le diagramme de squence illustr par la gure 4.14 dcrit un scnario du cas dutilisation Lancer un job en mode asynchrone .
59
Les prfrences de lutilisateur sont transmises depuis lIHM (script DVP ou interface de lancement de job dans linterface web) vers lapplication cliente qui demande, au Monitoring & Discovery Service, laffectation automatique dune machine. Ceci fait, lutilisateur paramtre son job, lIHM se chargeant de passer ces paramtres lapplication cliente qui invoque la mthode de lancement de job en mode asynchrone expose par le Job Execution Service. Lutilisateur, dans ce cas, ne reste pas bloqu en attente du rsultat mais lapplication cliente reste en attente, en arrire plan, dune notication de la part de la machine distante indiquant la n de lexcution ainsi que le rsultat, qui le transmet lIHM qui, elle mme, notie lutilisateur. 4.2.2.4 Diagramme de squence de lancement de job dans un environnement embarqu Le diagramme de squence suivant, gure 4.15, illustre un scnario du cas dutilisation lancer un job en mode synchrone avec un choix dun environnement embarqu comme environnement dexcution. An de slectionner une carte ayant la conguration requise pour lexcution du job, lutilisateur commence par prciser la main device , lIHM ltre les cartes et ne lui renvoi que celles ayant ce main device ainsi que la liste de leurs core . Lutilisateur en choisi un, ce qui permet lIHM didentier une carte ainsi que le Master qui la dtient. Lutilisateur, enn, passe les paramtres de son job ainsi que la procdure de connexion, via lIHM, lapplication cliente qui se charge de lenvoie des paramtres du job ainsi que le chier binaire excuter au Job Execution Service. La mthode OnBoardJobLaunch() se charge de crer une instance de la classe BoardConnexion et fait appel la mthode JobSubmit() pour la formulation de la commande de connexion, lenvoi du chier vers la carte et la rception, enn, du rsultat de lexcution qui sera vhiculer de bout en bout jusqu lutilisateur.
60
F IG . 4.14 Diagramme de squence de lancement dun job en mode asynchrone.
61
F IG . 4.15 Diagramme de squence du lancement dun job dans un environnement embarqu.
Conclusion
Dans ce chapitre nous avons dtaill la conception de notre application. Nous avons commenc par dnir larchitecture gnrale de notre plateforme que nous avons par la suite abord avec plus de dtail en prsentant les vues statiques via le diagramme de composants et les diagrammes de classes ainsi que la vue dynamique via les diagrammes de squences illustrant quelques cas dutilisation.
Chapitre 5 Ralisation
D
5.1
ANS
ce paragraphe nous allons dcrit sommairement et conformment la m-
thodologie SCRUM, les tapes de ralisation de notre projet, ensuite nous allons
prsenter la ralisation par rapport au produit nal en dcrivant lenvironnement de travail et les technologies utilises pour la mise en place de notre plateforme. Enn, nous prsentons quelques captures dcran de lapplication ralise.
Ralisation par rapport au backlog
La particularit de la mthodologie SCRUM, dj explicit dans la partie 1.3.3, fait que le droulement de la ralisation du projet est plani ds son dbut. Dans ce paragraphe nous allons dcrire brivement le droulement des sprints pour ensuite parler du facteur de disponibilit.
5.1.1
Le droulement des sprints
La dcomposition du projet en des sous tches appels aussi sprint a t faite au dbut de notre projet. Ceci est dcrit par le backlog du produit ( voire annexe B ). Il sagit ensuite, chaque tape, de faire une runion dquipe an de : Enoncer les buts du sprint (le produit du sprint). Proposer des estimations temporelles en nombre de jour. 62
CHAPITRE 5. RALISATION
63
Valider la ralisation la n du sprint en effectuant une dmonstration du travail ralis. Modier ventuellement certains objectifs dnis au dpart en fonction de nouvelles requtes. Il est noter quune dcision a t prise au sein de lquipe, suite une demande de membres dautres quipes qui taient prsents pendant une dmonstration de la DVP, de ne pas limiter lusage de la DVP aux tests de validation et dtendre sa porte pour supporter tous types de jobs et en particulier permettre dautres quipes dutiliser loutil dexcution distante sur les cartes.
5.1.2
Facteur de disponibilit
Le facteur de disponibilit, est le rapport du nombre de jour ddi par le dveloppeur pour la participation un projet et le nombre de jours de disponibilit de ce dernier pendant la priode du sprint. Vu que notre participation aux activits de lquipe est restreinte notre projet de n dtude, notre facteur de disponibilit est lev de lordre de 0.95 .
5.2
Conguration matrielle et logicielle
Dans ce paragraphe, nous prsentons la conguration matrielle et logicielle que nous avons exploit et nous prsentons les choix technologiques en les justiant.
5.2.1
Conguration matrielle
An de mener ce projet et effectuer les tests adquats, il a t mis notre disposition :
Un ensemble de 5 micro-ordinateurs dont les caractristiques sont : Processeur : Pentium IV 3GHZ. RAM : 2 Go.
64
Disque dur : 80 Go. Un ensemble de 2 cartes dont les caractristiques sont : Plateforme : OS21. Compilateur : respectivement ST40 et ST200. Connexion : Ethernet. Type de micro connect : respectivement 1 et 2. La plateforme a t test, avec succs, sur des micro-ordinateurs dots du systme dexploitation Windows XP (32-bits), Linux (RedHat 3.0 32-bits) et les diffrentes cartes disponibles.
5.2.2
Choix de la plateforme de dveloppement
Le bon choix de la plateforme de dveloppement inue imprativement sur les performances des produits dvelopps. Pour cela nous avons limit notre choix aux deux technologies les plus courantes savoir .NET et JEE. Les deux plateformes sont performantes et facilement exploitables. Cependant la premire nous restreint aux produits et aux environnements de dploiement des produits propritaires Microsoft savoir Windows comme systme dexploitation et IIS comme serveur web. Au contraire la deuxime est multi-plateforme , grce la portabilit du langage java, et prsente plusieurs avantages par rapport la premire savoir : Riche : plusieurs API (Application Programming interface) pour lusage des services web savoir JAXP, JAXB, JAX-WS. Innovante : limplmentation est libre ce qui favorise la comptition entre diteurs. Soutenue par plusieurs gants de linformatique (Sun, IBM, BEA. . .). Tous ces avantages, nous ont amenes opter pour JEE comme plateforme de dveloppement.
65
5.2.3
Conguration logicielle
Aprs avoir fait le choix de JEE nous avons utilis les outils suivant pour le dveloppement des diffrentes parties de la plateforme : Langage JAV : pour le dveloppement de la couche mtier des services web ainsi A que les applications clientes. Netbeans : Cest un environnement de dveloppement intgr (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 diffrents autres langages, comme Python, C, C++, XML et HTML. Il comprend toutes les caractristiques dun IDE moderne (diteur en couleur, projets multi-langage, refactoring, diteur graphique dinterfaces et de pages web). Script shell Linux : pour le dveloppement des scripts DVP. GlassFish v2ur2 : Cest le serveur dapplications Open Source Java EE 5 et qui sert de fondation au produit Sun Java System Application Server de Sun Microsystems. GlassFish est certi Java EE 5 et est une implmentation complte de la norme Java EE 5 qui recouvre : EJB 3 (approche POJO, conguration par exception, injection de dpendance). JPA (Java Persistence API) : standard implment par TopLink (par dfaut dans GlassFish), Hibernate ou OpenJPA. JAX-WS 2.x : nouvelle pile pour les services web . JAXB 2.0 : mise en correspondance (mapping) XML/Java utilise par JAX-WS 2.0 . JSF (Java Server Faces) - Framework MVC dont Apache MyFaces et JSF RI sont des implmentations libres . JSP 2.1 & Servlet 2.5 : pour faire de linjection de dpendance dans le conteneur web. ExtJS 2.0 : Extended JavaScript est une bibliothque JavaScript permettant de construire des applications web interactives. Ctait au dpart une extension la bibliothque JavaScript YUI de Yahoo, ExtJs peut maintenant tre utilise avec
66
les bibliothques Prototype, JQuery ou encore toute seule, elle apporte un certain nombre de composants visuels dune grande qualit comme des champs de formulaires avancs, des arbres, des tableaux, menu et barre doutils, onglets, boites de dialogue. La version 2.0 est de sortie le 4 dcembre 2007. Il sagit dune amlioration majeure de la bibliothque. JSON : JavaScript Object Notation, est un format de donnes textuel, gnrique, driv de la notation des objets du langage ECMAScript. Il permet de reprsenter de linformation structure, pour lchange des donnes entre les applications clientes de la DVP et linterface web, [Net3]. Hibernate 3 : cest la version courante dHibernate. Cette version propose de nouvelles fonctionnalits comme larchitecture Interceptor/Callback, les ltres utilisateurs et les annotations introduites par le JDK 5.0. Hibernate 3 est galement trs proche des spcications EJB 3.0 (mme si la bibliothque logicielle a t livre avant les spcications dnitives) et sert de colonne vertbrale limplantation dEJB 3.0 par JBoss. PostgreSQL 8.1.4 : est un systme de gestion de base de donnes relationnelle et objet (SGBDRO). Cest un outil libre disponible selon les termes dune licence de type BSD (Berkeley software distribution license).
5.3
Ralisation par rapport au produit nal
Dans ce paragraphe nous prsentons le travail que nous avons ralis en soulignant que nous sommes parvenus atteindre les objectifs noncs au dbut de notre projet et dcrits dans la deuxime section du deuxime chapitre de ce rapport. Dans ce qui suit nous allons prsenter quelques interfaces de lapplication ralise. Il est noter que les interfaces ralises sont disponibles en ligne de commande et partir de linterface web.
67
5.3.1
Interfaces dajout de ressource
Dans ce qui suit, nous prsentons linterface dajout de ressources puis un exemple dajout de carte. Louverture du menu droulant, libell 1, entraine le droulement de diffrentes fonctionnalits telles que la gestion des ressources ou des jobs. Pour accder linterface dajout de ressources, ladministrateur choisit dabord la gestion des ressources, libell 2, ensuite il choisit douvrir le control panel qui lance une fentre de gestion des ressources, libell 3, et parmi les onglets disponibles il ouvre celle dajout de ressource, libell 4. Enn sil dsire ajouter une machine il suft de remplir les champs du nom et de ladresse IP, de slectionner le type PC du menu droulant type de machineet de slectionner enn la localisation de la machine (Tunis, Grenoble. . .). Pour envoyer la demande dajout au Monitoring and Discovery Service il clique sur le bouton Add . Pour le cas particulier dajout dune carte, lutilisateur a besoin de fournir quelques informations complmentaires. Pour cela il coche la case Board additional information , libell 5, et remplit les champs qui safchent. La gure 5.2 illustre un exemple dajout dune carte.
68
F IG . 5.1 Interface dajout de ressources
F IG . 5.2 Exemple dajout de cartes
69
5.3.2
Interface de gestion de ressources
La fentre suivante , illustr par la gure 5.3, offre ladministrateur une interface qui regroupe des oprations de gestion de ressources savoir la mise jour, lajout et la suppression dune ressource, lactualisation de la liste des ressources et le suivi de la disponibilit de ces dernires. Chacune des fonctionnalits cites ci-dessus, peut tre effectue avec un script DVP. Dans la gure suivante 5.4, nous prsentons un exemple de script DVP pour lobtention de la liste des ressources ainsi que leurs tats.
F IG . 5.3 Fentre de suivi et de gestion des ressources
70
F IG . 5.4 Liste des ressources obtenue par un script DVP en ligne de commande
5.3.3
Interface de lancement de job en mode asynchrone
Dans lexemple illustr par la gure 5.5, lutilisateur a rempli les champs relatifs aux paramtres de son job : Libell 1 : Le mode dexcution (simulation). Libell 2 : Le choix de la machine destination (affectation automatique dune machine par le MDS). Libell 3 : Menu droulant, inaccessible, des informations sur une carte en cas de choix dexcution dans un environnement embarqu. Libell 4 : La commande excuter sur la machine distante. Libell 5 : Le menu donne la liste des jobs dj en cours dexcution, la slection de lun de ces jobs dni une dpendance du job dutilisateur par rapport ce dernier (lexcution ne peut commencer qu la n du job slectionn).
71
F IG . 5.5 Fentre de lancement de job en mode asynchrone
5.3.4
Interface de lancement dun job vers une carte
Les gures, 5.6 et 5.7, reprsentent un exemple denvoi dun chier binaire pour lexcuter sur une carte distante. Aprs la slection du mode board dans le menu Execution mode , libell 1, relatif au choix dun environnement embarqu pour lexcution du job, le menu Execution plateform , libell 2, sactive et liste les plateformes disponibles. Le choix de la plateforme fait, lutilisateur retrouve dans le menu Board name , libell 3, la liste des cartes disponibles et enregistres dans le Monitoring & Discovery Service (le name fait rfrence la main device de la carte). Ensuite, il slectionne dans le menu, libell 4, un core dune carte parmi ceux disponibles la main device dj slectionne.
72
Ceci fait lutilisateur passe au deuxime onglet illustr par la gure,5.7, et donne lemplacement de son chier binaire excuter dans le champ File path , libell 5. Enn, soit il choisit une carte dans le menu host , libell 6, soit il le laisse vide et le Monitoring & Discovery Service se charge de lui affecter la premire carte disponible et rpondant aux prfrences quil a dj mentionn au dbut.
F IG . 5.6 Paramtrage dun job destin lexcution sur une carte
F IG . 5.7 Slection dun chier binaire destin lexcution sur une carte
73
5.3.5
Liste descriptive des scripts DVP
Ce tableau dcrit une liste non exhaustive des scripts DVP raliss, en prsentant le nom et la fonction. Nom du script Manage-hosts-add.sh Manage-hosts-delete.sh Job-submit-synch.sh Job-submit-asynch.sh Job-submit-asynch-attach.sh Job-kill.sh Job-status.sh Job-output.sh Fonction Ajout dune ressource. Suppression dune ressource. Lancement dun job en mode synchrone. Lancement de job en mode asynchrone. Lancement dun job en depuis un chier script. Interrompre un job en cours dexcution. Obtenir la liste des jobs ainsi que leurs tats. Obtenir la rsultat dexcution dun job. TAB . 5.1 Liste non exhaustive des scripts DVP.
5.4
Tests et dploiement
Bien que la mthodologie Scrum, adopte pour la ralisation de ce projet nous impose de valider le travail chaque tape (chaque incrment est valid par des tests unitaires), il est impratif de tester le comportement de la plateforme une fois tous ses composants runis an dviter certaines anomalies qui ne peuvent tre dtectes quen intgrant le produit dans son environnement rel, et suivre son comportement dans des conditions extrmes (forte charge, un nombre leve de client). La gure 5.8 dcrit une organisation matrielle et logicielle que nous avons jug sufsante pour la russite de cette phase et sur lequel nous nous sommes bass pour faire nos tests comportant : 5 clients de la DVP. 7 machines, dotes dun os Windows, o est dploy le Job Execution Service.
74
1 machine, dote dun os Windows, o est dploy le Monitoring & DiscoveryService. 2 cartes. 2 sites de ST : celui de Tunis et celui de Grenoble.
F IG . 5.8 Organisation matrielle et logicielle pour la phase de test
75
Le tableau 5.2 suivant illustre une squence de tests effectus ainsi que les ventuels problmes quon essaye de dtecter. N Test Test 1 But et scnario Sassurer du bon fonctionnement de la plateforme en inter site. Lventuel problme Un problme de communication entre les services dploys dans des sites distants. Rsultat Pas de problmes, abstraction totale de lemplacement des ressources.
Test 2
Tester la rsistance du MDS (lorchestrateur) une forte charge. Pour cela tous les clients essayent de linvoquer simultanment.
Le
MDS
prsente
un
Une lenteur est dtecte au niveau des rponses du MDS, la solution est de minimiser linvocation du MDS.
temps de rponse important en cas de surcharge.
Test 3
Tester la rsistance de la plateforme un usage excessif de la part des clients. clients Pour cela les Le MDS est incapable de grer un grand nombre de jobs en transite.
Les
machines de
ont
un
problme
lenteur
dans le cas de lexcution de nombreux jobs coteux en mmoire, la
commencent
envoyer des jobs, simultanment et une forte frquence.
Les machines sont in- solution est le dveloppecapables dexcuter un grand nombre simultan de jobs. . ment dun client adapt lenvoi dun grand
nombre de jobs simultans (une le dattente par ressource)
TAB . 5.2 Tests et scnarii de test.
76
Conclusion
Nous avons vu dans ce chapitre les environnements logiciel et matriel sur lesquels sest bas notre travail. Nous avons justi les choix considrs pour aboutir la ralisation de la nouvelle plateforme de validation et enn, nous avons prsent quelques captures dcran et dcrit la phase de test et de dploiement. Nous prsentons dans ce qui suit la conclusion gnrale.
77
Conclusion gnrale
A validation correspond au processus dvaluation du produit tout au long de son
dveloppement et au-del au cours de sa maintenance pour sassurer quil satis-
fait aux normes et aux exigences ncessaires pour une utilisation spcique ou pour une application prvue. La tche de validation elle-mme a ses propres exigences et ventuellement ses propres problmes et contraintes. La distribution des tches, quant elle, est aujourdhui un choix stratgique des socits pour une meilleure utilisation de leurs ressources informatiques.
Nous avons fait le lien entre les deux approches en mettant en uvre notre plateforme qui rpond aux problmes les plus persistants du processus de validation savoir la distribution des tches et la validation dans un environnement embarqu, rpondant ainsi aux besoins des responsables de validation et permettant une meilleure gestion des ressources disponibles. Ainsi se termine notre rapport, durant lequel nous avons dabord commenc par introduire notre projet dans son contexte gnral, ensuite fait ltat de lart de quelques solutions existantes et enn concrtis notre travail en illustrant les diffrentes tapes de spcication et de conception.
Nous estimons avoir satisfait les objectifs initialement xs tout en faisant faces aux diverses contraintes et nouvelles requtes qui sont apparues durant ce stage. Nous sommes dautant plus conants dans notre jugement que les tests intensifs qui ont t faits par de nombreux membres que ce soit de notre quipe ou dautres quipes intresses par notre travail ont t russis et que ces derniers ont exprims leur satisfaction
Conclusion gnrale
78
des rsultats atteints.
Nanmoins, ces tmoignages aussi rassurants quencourageants, ne font que nous inciter amliorer davantage notre plateforme et proposer de nouvelles perspectives savoir : Lintgration dun module dcisionel : un systeme daide au responsable pour la prise de mesures ncessaires suite aux statistiques relatives lusages des ressources ( machines + cartes). Llargissement du domaine dutilisation de loutil dvelopp pour dautres targets ( set top box, . . .). et proposer ainsi une solution complte et en totale adquation avec les besoins des quipes de dveloppement de STMicroelectronics.
Bibliographie
1. Ouvrages
et publications
[Bib1] DERUYTER Thomas. Modlisation darchitectures DSP pour le reciblage de compilateurs . Th Doctorat,INP Grenoble,FRANCE ;2007.
[Bib2] BOUTABA Raouf. Une architecture et une plate-forme distribue oriente-objet pour la gestion intgre de rseaux et de systmes . Th Doctorat,Universit de Paris 06,Paris,FRANCE ;1994.
[Bib3] Sabri MTIBAA. Analyse,conception et ralisation dune application distribue pour la gestion et le partage des ressources dans une campagne de validation , Rapport de projet de n dtudes ; Universit de La Manouba ,ENSI ;2006,La Manouba Tunisie ;50 pages.
[Bib4] Haikel THAMRI. Conception et ralisation dune application permettant la distribution dun ensemble de taches de validation de compilateurs base sur une approche oriente service. , Rapport de projet de n dtudes ; Universit de La Manouba ,ENSI ;2008,La Manouba Tunisie ;56 pages.
2. Rfrences
Web
[Net1] STMicroelectronics web site, http ://www.st.com/. [Net2] Electric Cloud web site, http ://www.electric-cloud.com, consult Fvrier 2009.
79
BIBLIOGRAPHIE
80
[Net3] World Wide Web Consortium, Web services activity, http ://www.w3.org/2002/ws/, consult Mars 2009.
Annexe A Annexe A : Les APIs du ST TargetPack
81
Annexe B Annexe B : Backlog du produit
82

Me Moire

Transféré par

Informations du document

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Me Moire

Transféré par

Droits d'auteur :

Formats disponibles

Rf : 2008/II/...

Soutenu la session de Juillet 2009

ECOLE NATIONALE DES SCIENCES DE LINFORMATIQUE

Mise en place dune plateforme de validation distribue dans un contexte embarqu

Signatures des encadrants

Mr. HECHMI ABOUDA (ENSI)

ddie ce modeste travail

chre mre Chedlia

En tmoignage de ma profonde gratitude et de mon incontestable reconnais-

chers frre et sur : Nadhem et Nihel

En leurs esprant le plein succs dans leur vie.

familles CHAIB et BADREDDINE et en particulier mon chr oncle Adel qui

ma initi au monde informatique.

T ous mes amis Khaled,Mounir,Oussema,Sabri,Nadhem,Fayal, Kamel, Houcem,

Youssef, Abir, Maherzia. . .

ceux qui mont aids et que jai oubli de citer.

Table des matires

TABLE DES MATIRES

Les modes dexcution et problmatique . . . . . . . . . . . . . .

LSF (Load Sharing Facility) . . . . . . . . . . . . . . . . . . . . . . 2.1.2.1 2.1.2.2 Description . . . . . . . . . . . . . . . . . . . . . . . . . . Critiques . . . . . . . . . . . . . . . . . . . . . . . . . . .

DVP (Distributed Validation Platform) . . . . . . . . . . . . . . . 2.1.3.1 2.1.3.2 Description . . . . . . . . . . . . . . . . . . . . . . . . . . Critiques . . . . . . . . . . . . . . . . . . . . . . . . . . .

TABLE DES MATIRES

Description dtaille des cas dutilisation . . . . . . . . . . . . . . . . . .

Ralisation par rapport au produit nal . . . . . . . . . . . . . . . . . . .

TABLE DES MATIRES

5.3.1 5.3.2 5.3.3 5.3.4 5.3.5 5.4

Table des gures

4.10 Diagramme de classe du package DataBaseManagement. . . . . . . . . . x

TABLE DES FIGURES

Liste des tableaux

Description dtaille du cas dutilisation Lancer un job depuis un script shell . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38 39 40 73 75

3.7 3.8 5.1 5.2

Description dtaille du cas dutilisation Interrompre un job . . . . .

Liste non exhaustive des scripts DVP. . . . . . . . . . . . . . . . . . . . . Tests et scnarii de test. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

sorientent de plus en plus vers lamlioration de la qualit de leurs produits.

Chapitre 1 Prsentation du cadre du projet

prsent projet intitul, Mise en place dune plateforme de validation dans un

contexte embarqu, est ralis dans le cadre de la prparation dun mmoire de

Organisme daccueil et cadre gnral

CHAPITRE 1. PRSENTATION DU CADRE DU PROJET

Lquipe Compiler Expertise Center : centre dexpertise en compilation

CHAPITRE 1. PRSENTATION DU CADRE DU PROJET

Cadre gnral du projet

CHAPITRE 1. PRSENTATION DU CADRE DU PROJET

CHAPITRE 1. PRSENTATION DU CADRE DU PROJET

Un comparatif des mthodes agiles

CHAPITRE 1. PRSENTATION DU CADRE DU PROJET

CHAPITRE 1. PRSENTATION DU CADRE DU PROJET

F IG . 1.1 Schma illustratif de SCRUM

CHAPITRE 1. PRSENTATION DU CADRE DU PROJET

CHAPITRE 1. PRSENTATION DU CADRE DU PROJET

F IG . 1.2 Schma illustratif de la chaine de compilation

Le projet GNU : compilateurs et options de compilation

CHAPITRE 1. PRSENTATION DU CADRE DU PROJET

La compilation dans un environnement embarqu

Les modes dexcution et problmatique

CHAPITRE 1. PRSENTATION DU CADRE DU PROJET

Chapitre 2 Etude de lexistant

datteindre les objectifs de notre projet, ltude des solutions existantes et

Etude de lexistant : Analyse et critiques

CHAPITRE 2. ETUDE DE LEXISTANT

CHAPITRE 2. ETUDE DE LEXISTANT

F IG . 2.1 Architecture de lElectric Commander

LSF (Load Sharing Facility)