Ministre de lEnseignement Suprieur, de la Recherche Scientique et de la Technologie Universit de la Manouba Ecole Nationale de Sciences de lInformatique

RAPPORT du Mmoire de Fin dEtudes

Prsent en vu de lobtention du titre dINGENIEUR EN INFORMATIQUE Par: CHETTEOUI Mohamed

Sujet : Ralisation dun outil de gestionnaire de taches sous forme dextension au portail eXoPlatfom 3.5

Organisme : eXoPlatfom Responsable : M ME . F IDA ALJOUNAIDI Encadrant : M. N JAH H OUSSEM Adresse : Ici adresse de ma socit Tlphone : 000000000000 Fax : 000000000000000

Anne Universitaire 2011 2012

Signature de lencadrant

Remerciements
Merci a .......

et a ....

Noublion pas ....

Et aussi ....

Je remercie, enn, .....

Rsum
ici jecris un rsum de mon travail

Abstract
I will write the same thing... but in english :(

Table des mati` res e

Remerciement Rsum Table des gures Introduction 1 Cadre General du projet 1.1 1.1.1 1.1.2 1.2 1.2.1 1.2.2 1.3 1.3.1 1.3.2 1.4 2

I II VI 10 12

Prsentation de lorganisme daccueil . . . . . . . . . . . . . . . . . . . . . . 12 Prsentation deXoPlatform . . . . . . . . . . . . . . . . . . . . . . . 12 Prsentation de la socit Exo Middle East and Africa . . . . . . . . . 13 Etude des services proposs par eXoPlatform 3.5 . . . . . . . . . . . . 14 Etude des solutions existantes sur le march . . . . . . . . . . . . . . . 15 Critique des solutions disponibles au march . . . . . . . . . . . . . . 18 Critique deXoPlatform 3.5 . . . . . . . . . . . . . . . . . . . . . . . 18

Etude de lexistant . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

Critique de lexistant . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

Solutions envisages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 20 Les mthodes AGILES . . . . . . . . . . . . . . . . . . . . . . . . . . 20 La mthode Scrum . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 La mthode eXtrem Programming (XP) . . . . . . . . . . . . . . . . . 22 Notion de projet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23 Notion de gestion de projets . . . . . . . . . . . . . . . . . . . . . . . 23 Les portails web . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24 Les workows . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

Etat de lart 2.1 2.1.1 2.1.2 2.1.3 2.2 2.2.1 2.2.2 2.2.3 2.2.4

Les mthodologies utilises . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

Etudes thoriques . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

TABLE DES MATIRES 3 Spcications des besoins 3.1 Capture des besoins 3.1.1 3.1.2 3.1.3 3.2 3.2.1 3.2.2 4 Conception 4.1 4.2 4.1.1 4.2.1 4.2.2 4.2.3 4.2.4 5 Ralisation 5.1 5.2 5.3 5.4 6

Page IV 27 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

Besoins fonctionnels . . . . . . . . . . . . . . . . . . . . . . . . . . . 27 Les Besoins Non Fonctionnels . . . . . . . . . . . . . . . . . . . . . . 28 Les Besoins Du Domaine . . . . . . . . . . . . . . . . . . . . . . . . . 29 Diagramme gnral . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

Diagramme des cas dutilisation . . . . . . . . . . . . . . . . . . . . . . . . . 29 Diagrammes des cas dutilisations dtaills . . . . . . . . . . . . . . . 30 35 Architecture n-tiers . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35 Conception de la base de donnes . . . . . . . . . . . . . . . . . . . . 38 Diagramme de paquetage . . . . . . . . . . . . . . . . . . . . . . . . 42 Diagramme des classes . . . . . . . . . . . . . . . . . . . . . . . . . . 42 Les diagrammes de squences . . . . . . . . . . . . . . . . . . . . . . 43 49

Conception globale . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35 Conception dtaille . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38

Environnement matrielle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49 Choix techniques et logicielles . . . . . . . . . . . . . . . . . . . . . . . . . . 49 5.2.1 Architecture logicielle de lapplication . . . . . . . . . . . . . . . . . . 49 Aperu du travail ralis : . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51 Chronogramme : . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51 52 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52 . . . . . . . . . . . . . . . . . . . . . . . . . 52

Tests et Validation : 6.1 Tests fonctionnels 6.1.1 6.1.2 6.2 6.2.1 6.2.2 6.2.3 Outil utilis (Qmetry) :

Rsultats et interprtations . . . . . . . . . . . . . . . . . . . . . . . . 53 . . . . . . . . . . . . . . . . . . . . . . . . . . . 53 Outil utilis (JMeter) . . . . . . . . . . . . . . . . . . . . . . . . . . . 53 Rsultats : . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53 Interprtations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54 56 57 Mmoire de Fin dEtudes ENSI 2011

Test Qualit et performance

Conclusion gnrale Bibliographie Moi MEME

TABLE DES MATIRES Nethographie Annexe A Annexe B

Page V 58 59 60

Moi MEME

Mmoire de Fin dEtudes ENSI 2011

Table des gures

1.1 1.2 1.3 2.1 2.2 2.3 3.1 3.2 3.3 3.4 3.5 3.6 4.1 4.2 4.3 4.4 4.5 4.6 4.7 4.8 4.9 5.1 6.1 6.2 6.3 Organisation de la socit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 Gantt Project . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 Visual Project . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 Le processus de dveloppement Scrum . . . . . . . . . . . . . . . . . . . . . . 21 Les rles du Scrum . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22 Les Workow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26 Diagramme de cas dutilisation gnral . . . . . . . . . . . . . . . . . . . . . 29 Gestion des projets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30 Gestion des taches . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31 Gestion des ressources . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32 Suivi des taches . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33 Suivi des ressource . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33 Architecture globale . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36 Les objets JSON . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37 Relations pre-ls entre les differents types de noeuds . . . . . . . . . . . . 40 Relations REFERENCE entre les diffrents types de noeuds . . . . . . . . . 41 Diagramme de paquetage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42 Diagramme des classes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43 Diagramme de squence dajout dun nouveau projet . . . . . . . . . . . . . . 45 Diagramme dajout dune nouvelle tche . . . . . . . . . . . . . . . . . . . . 46 Diagramme dajout dune nouvelle ressource une tche . . . . . . . . . . . . 47 Architecture logicielle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50 Capture decran de QMetry . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53 Temps de rponse du serveur . . . . . . . . . . . . . . . . . . . . . . . . . . . 54 Nombre de transactions par seconde . . . . . . . . . . . . . . . . . . . . . . . 54 VI

Introduction G n rale e e
La dynamique dun nouveau projet nous oblige tout naturellement foncer. Bien que notre enthousiasme, notre imagination et notre savoir-faire soient essentiels la ralisation des objectifs des projets, ils ne sufsent pas eux seuls. La russite dun projet est aussi fonction dune gestion efcace des taches qui le constituent. Depuis dj plusieurs dcennies, la gestion de projets a contribu de faon trs signicative la nouvelle pratique de la gestion. Grce cette approche, les organisations peuvent planier, coordonner, diriger et surtout contrler les ressources et ce, de faon structure et optimale. En effet, la gestion informatise de projets procure un outil trs puissant aux gestionnaires daujourdhui par sa exibilit et sa polyvalence. De plus, elle doit permettre de rsoudre les problmes les plus complexes comme la planication et le suivi des projets, laffectation des ressources et la gnration des rapports. La philosophie de la gestion de projets permet donc de faire face des ds jadis insurmontables pour les administrations traditionnelles. Il sagit dune mthodologie avant-gardiste rpondant un monde de plus en plus complexes et dynamique. Elle gnre la crativit et linitiative vis--vis des membres de lquipe du projet. Quant la base de connaissance enregistre, elle est dune importance majeur puisquelle sert amliorer la productivit de lentreprise.En effet, la disponibilit dune information concise rpondant des astuces critiques est un moyen de gain de temps. Cest dans ce cadre que sinscrit ce projet de n dtude qui a pour nalit la conception, la spcication et la mise en uvre de larchitecture dune application de gestion de projets permettant de planier les taches dun projet an de contrler au mieux lchance prcise de chaque projet. Lide de base consiste donc la cration dun systme able permettant dallier performance et convivialit aux choix des actions entreprendre par le systme. Autour de cette ide sarticule linterface web de cette application, une ergonomie bien tudie et une architecture convenable qui vont permettre la ralisation dun travail conforme aux objectifs voulus. Aprs avoir donn un aperu sur le projet, nous allons prsenter le plan de ce document. Dans un premier chapitre, nous allons prsenter le cadre du projet ainsi quune prsentation de ltude thorique qui a eu lieu avant la ralisation du projet an de faire une collecte de donnes qui a facilit le droulement du stage. Entre autre et dans ce mme chapitre une introduction de lorganisme daccueil a t voque. Le second chapitre a pour objectif de spcier les besoins auxquels nous devons rpondre en prsentant les diffrents acteurs susceptibles de faire partie de lutilisation de notre application et leurs besoins respectifs, ceci grce a des diagrammes de cas dutilisation. La conception avec ses deux volets dtaille et globale est lobjet dun troisime chapitre. noter que tout au long de ce dernier des explications et des dnitions purement thoriques sur des notions de base seront voqus ds lapparition dun nouveau concept.

TABLE DES FIGURES

Page 11

Pour la ralisation, les outils adopts et le rsultat du travail obtenu aprs ce stage, un quatrime chapitre a t rserv pour prsenter tous ceci. Enn un petit aperu sur les tests raliss avant la validation du produit nal fera lobjet dun cinquime et dernier chapitre.

Moi MEME

Mmoire de Fin dEtudes ENSI 2011

Chapitre 1

Cadre General du projet

Dans ce premier chapitre, on vise tout dabord a mettre notre projet et notre stage dans son cadre en prsentant en premier lieu lorganisme qui a accueilli le droulement des diffrents phases de ce stage puis en mettant en vidence lexistant de point de vue produit initial et solutions dj existantes , enn nous donnerons la solution quon envisage de raliser suite aux manques retrouv grce aux critiques de lexistant.

1.1

Prsentation de lorganisme daccueil

Comme dj prvu, nous allons prsenter notre entreprise accueillante avec une prsentation de lentreprise dans son volet international puis une autre prsentation sera rserve sa lire Exo Middle East and Africa.

1.1.1

Prsentation deXoPlatform

date 1 : 04/21/11 An de bien initier ce document, une prsentation assez large de lorganisme qui a accueilli ce stage de n dtude se prsente primordiale. Exo Platform, une entreprise qui propose comme produit principale un portail comportant de nombreuses applications web sous forme dune suite de logiciels et de services visant satisfaire les clients qui choisissent cette solution pour informatiser leurs systmes dinformations. Ce portail, de point de vue purement technologique sappuie sur les dernires technologies prsentes dans la plateforme Java EE et essaye ainsi dinnover dans ce domaine sur une chelle nationale et mme internationale grce aux diffrentes quipes de cette entreprise voluant dans divers pays du monde qui ont conu une architecture logiciel assez moderne permettant de garantir des critres de performances et de diversits simultanment. Ces quipes cooprent alors an de proposer cette solution dans un ensemble assez homogne ainsi que des services de maintenances, de support, de tests et de personnalisation suivant les demandes et les besoins des entreprises clientes. Notons aussi que le portail prsent par eXoPlatform se distingue par une caractristique assez importante dans le domaine du dveloppement des logiciels informatiques , il sagit dun code source accessible par tout le monde an de participer au mouvement de lopen source et faire partie de cette vague qui vise
1. note de date

12

CHAPITRE 1. CADRE GENERAL DU PROJET

Page 13

partager les connaissances an de faire dvelopper les technologies prsentes et viter les systmes de monopolisations qui se propagent de plus en plus dans ce domaine.

1.1.2

Prsentation de la socit Exo Middle East and Africa

La socit eXo MEA est lune des quatre lires de la socit mre eXo internationale. Elle se concentre sur la clientle situe dans le Moyen Orient et lAfrique. Son organigramme illustr dans la gure ci-dessous indique les diffrentes quipes et dcrit bien larchitecture de la socit.

F IGURE 1.1 Organisation de la socit Les diffrentes quipes sont : Vente & ventes intrieures (Sales & Inner sales) : Cest lquipe qui communique avec les intresss des produits eXo et rpond leurs questions. Son intrt primordial est la prvente. Finance & Administration (Fin & Admin) : Son rle se concentre autour des relations nancires de la socit et la gestion administrative. Equipe de dveloppement produit (eXo Product Dev) : Cette quipe sintresse au dveloppement et la mise jour de la plateforme eXo et ne cesse pas de la faire voluer chaque jour. Expertise technique & Architecture (Technical Expertise & Architecture Team) :

Moi MEME

Mmoire de Fin dEtudes ENSI 2011

CHAPITRE 1. CADRE GENERAL DU PROJET

Page 14

Le rle de ses membres est dapporter leurs expertises aux autres quipes pour bien se bncier des apports de la plateforme. Equipe dAssurance Qualit et de livraison (QA & Delivery) : Son rle est lapplication des tests ncessaires pour sassurer de la qualit des projets. Infrastructure (Infrastructure) : Cest lquipe qui sintresse de tout ce qui est dploiement et maintenance des outils ncessaires pour le bon droulement du travail au sein de la socit. Equipe de Soutien (Support) : Lquipe de Soutien est responsable de : - La livraison des binaires aux clients. - Service dassistance. - La conduite de la gestion de correction des erreurs. - La collection et la surveillance des demandes de fonctionnalits des clients. Equipe de Clientle des produits & des conseils (CP & Consulting) : Cette quipe se charge des fonctions suivantes : - La consultation pour un client. - La formation des stagiaires. - La livraison du produit - Le dveloppement sur mesure en estimant les travaux faire. Notons que notre projet nous a t propos par le chef dquipe CP & Consulting laquelle jai fait partie tout au long de ce stage. Il est noter galement que notre travail devrait tre men en se concentrant sur la plateforme eXo de la socit que nous prsenterons avec plus de dtails dans la section suivante.

1.2
1.2.1

Etude de lexistant
Etude des services proposs par eXoPlatform 3.5

Dans ce paragraphe nous allons citer les services proposs par la dernire version du portail deXoPlatform an de bien connaitre lenvironnement dans lequel notre projet sera intgr. Il sagit de la version 3.5.2 deXoPlatform qui propose en premier lieu une plateforme dexprience utilisateur (UXP, pour "User eXperience Platform") optimise pour le Cloud, elle est conue pour dvelopper et dployer des sites web transactionnels, grer des contenus web, crer des sites intranet, des gadgets et des tableaux de bord. EXo Platform permet aux entreprises doptimiser leurs infrastructures Java existantes travers des outils familiers et adapts aux nouvelles technologies telles que les rseaux sociaux dentreprise, les wikis ou les forums. En utilisant eXo Platform, vous bnciez dun portail dentreprise permettant de dployer et dorganiser des applications sous la forme de Portlet ou de gadgets. La scurit des donnes est garantie au travers de fonctionnalits telles que le contrle daccs et le Single Sign-On (SSO). Moi MEME Mmoire de Fin dEtudes ENSI 2011

CHAPITRE 1. CADRE GENERAL DU PROJET

Page 15

EXo Platform vous permet de dvelopper des intranets sociaux et des sites internet contenant de la gestion de contenus, des workows, des espaces de travail, des wikis, des forums, des ux dactivits et autres. Lavantage comptitif deXo Platform 3.5 repose sur deux caractristiques qui la rendent unique parmi les offres de portails et de gestion de contenu : la forte intgration du portail avec les fonctionnalits sociales, collaboratives et de gestion de contenu, et un environnement de dveloppement en ligne intgr la plateforme.

1.2.2

Etude des solutions existantes sur le march

La gestion de projet et le suivi des projets grce aux illustrations par diffrents diagrammes nest pas un domaine rcent, il existe dj plusieurs applications qui ont fait leurs preuves. Parmi ces applications on distingue principalement deux types : - Les applications ordinaires (Desktop) : Cest--dire bas sur un simple excutable quon excute sur sa propre machine. Ce type dapplication peut dpendre dautre programme ou autre composant qui doivent tre prsent sur la machine en question, ce qui ne facilite pas son dploiement, mais a lavantage dtre assez rapide dans le chargement et lexcution. - Les applications web (SaaS) : Ce sont des applications bases sur le protocole http, qui est lui-mme bas sur larchitecture client-serveur, ce qui rend ce type dapplication facilement dployable sur un rseau local, mais peuvent tre assez lente pendant lexcution et au lancement. Application Ordinaire : Dans ce cadre on peut citer quelques exemples auxquels on a pu sessayer :

Moi MEME

Mmoire de Fin dEtudes ENSI 2011

CHAPITRE 1. CADRE GENERAL DU PROJET

Page 16

F IGURE 1.2 Gantt Project - Gantt Project : Cette application a lavantage dtre assez simple et assez intuitive, en effet on peut facilement crer un projet, grer les tches et affecter des ressources chaque tche, on peut aussi gnrer le diagramme PERT de chaque projet. Cette application, tant dveloppe en java, ncessite la prsence de la JVM sinon elle ne risque pas de se lancer.

Moi MEME

Mmoire de Fin dEtudes ENSI 2011

CHAPITRE 1. CADRE GENERAL DU PROJET

Page 17

F IGURE 1.3 Visual Project - Visual Project : Bien quassez complet, ce programme ncessite quelque temps dadaptation pour quon puisse maitriser tout ce dont il est capable. Il permet en plus de la gestion des tches, la gestion de ressources humaines et matrielles et la vue du projet du point de vue des ressources, cest--dire lensemble des tches affect une ressource. Il fonctionne en client-serveur avec accs par IP, et permet aussi limportation et lexportation vers Microsoft Excel de lensemble de donnes du projet. Application Web : Le grand intrt davoir une application web pour la gestion des projets cest la possibilit de bncier de la puissance du web, pas besoin dinstaller un logiciel bien dnie sur toute les machines des utilisateurs concerns par ce projet, ainsi tout ce dont on a besoin cest dune connexion internet. SAM Project : SamProject est une application dveloppe par la socit SAMBOX. Le principal critre de dveloppement de SamProject est de facilit la communication, puisquelle est la principale raison pour laquelle les projets peuvent chouer. SamProject essaye de dmocratiser la gestion de projet et de la transformer en un effort collectif en laissant tous Moi MEME Mmoire de Fin dEtudes ENSI 2011

CHAPITRE 1. CADRE GENERAL DU PROJET

Page 18

les acteurs du projet accder linformation : les clients, les dveloppeurs, les gestionnaires, les commerciaux, le marketing, la direction, ...

1.3
1.3.1

Critique de lexistant
Critique des solutions disponibles au march

On voit bien que le domaine de gestion de projet est dj bien tabli et il existe encore plus dapplications que ce quon a cit. Pour cela ci-dessous un tableau illustrant une comparaison assez dtaille des diffrents solutions disponibles
Solution 5pm 24sevenOfce dot Project Gantt Project Open Workbench Logiciel collaboratif Oui Oui Oui Non Non Gestion des ressources Non Non Non Oui Oui Dnition des rgles de scurit Oui Non Oui Non Non

1.3.2

Critique deXoPlatform 3.5

Bien que les services proposs par le portail eXoPlatform 3.5.2 soit assez riches, ceci nempche pas quelques critiques et dfauts qui peuvent tre constats si on sapprofondit plus et si on consulte les demandes assez constantes des diffrents clients pour intgrer de nouveaux services. Dans ce cadre, une demande assez importante dun outil de gestion de taches au sein dun projet savre de plus en plus importante par les clients deXoPlatform. Pour notre projet le choix a t port pour en faire une Application qui doit tre intgre ensuite dans la plateforme dExo Platform, pour quelle puisse tre bnque lchelle dune PME, et que son excution ne soit pas dpendant dun quelconque environnement dexcution. Nous avons aussi remarqu de nombreuses failles au sein de ces solutions quon a tudies prcdemment : Les solutions noffrent pas dans leur majorit des solutions de partages et des solutions de scurit, on peut aussi noter que la modlisation des contraintes temporelles sous forme de diagrammes nest pas toujours garantie. On ne peut pas ngliger aussi la difcult de manipulation et dadaptation des utilisateurs de ces applications.

1.4

Solutions envisages

Aprs avoir fait une tude de lart et une critique de lexistant on envisage comme solution notre besoin la mise en place dune Application de gestion de projets (suivi dactivits et des taches) intgrable dans le portail Exo Platform 3.5. Cela pour rpondre aux objectifs suivants : - Faire bncier les clients dExo Platform dune solution permettant la gestion automatise de diffrentes tches et phases qui caractrisent leurs projets. - Assurer une bonne collaboration entre les diffrents membres dun projet. Moi MEME Mmoire de Fin dEtudes ENSI 2011

CHAPITRE 1. CADRE GENERAL DU PROJET - Rpondre aux besoins dj exprims par les clients dExo Platform. - Jouir lentreprise dune supervision de ltat de ses projets.

Page 19

- Bncier lentreprise cliente dune solution gnrant des diagrammes qui illustre lordonnancement des taches an dviter un dpassement des dlais temporelles des projets. - Raliser une application qui sadapte nimporte quel emplacement du portail dans lequel elle sera intgre.

Conclusion
Dans ce chapitre nous avons prsent au dbut lentreprise dans laquelle ce stage a t effectu puis on a critiqu ce qui existe dans le produit principal de notre entreprise ainsi que les solutions de gestions de projets disponibles aprs avoir bien tudier ce qui existe dj .

Moi MEME

Mmoire de Fin dEtudes ENSI 2011

Chapitre 2

Etat de lart

Introduction
Dans ce second chapitre, deux volets seront dtaills. Au dbut on voquera toutes les mthodologies quon a adopt pour la ralisation de notre projet ensuite on donnera quelques aspects thoriques sur quelques notions primordiale dans notre stage.

2.1
2.1.1

Les mthodologies utilises

Les mthodes AGILES

Les mthodes Agiles sont des procdures de conception de logiciel qui se veulent plus pratiques que les mthodes traditionnelles. Elles impliquent au maximum le client visent la satisfaction relle de ses besoins et permettent une grande ractivit ses demandes. Lquipe : lquipe est plus importante que les moyens matriels ou les procdures. La communication entre les membres de lquipe est une notion fondamentale. Lapplication : Il est fondamental que lapplication fonctionne. Mme si la documentation technique est importante comme un moyen de communication, elle est considre comme tant secondaire. La collaboration : le client doit tre impliqu dans le dveloppement. Il doit collaborer avec lquipe et offrir un feed-back continu sur ladquation du logiciel ses attentes. Lacceptation du changement : La planication initiale et la structure du logiciel doivent tre exibles an de permettre lvolution de la demande du client tout au long du projet.

2.1.2

La mthode Scrum

Scrum est une mthodologie de dveloppement drive des mthodes agiles pour la gestion de projets. Le terme " SCRUM " est emprunt au rugby et signie " mle ". Ce processus sarticule en effet autour dune quipe soude, qui cherche atteindre un but. Cette mthode se fonde sur un document trs important : les backlogs. Le produit backlog est en fait la liste des fonctionnalits hirarchises et estimes avec le client au dbut du projet. Il sert de rfrentiel pour lensemble du projet. A chaque dbut ditration dune dure de quatre semaines ltat des lieux du projet est fait avec le client et un sprint backlog est dni. Ce backlog-ci correspond toutes les tches effectuer lors de litration. En interne, chaque jour une runion a eu lieu

20

CHAPITRE 2. ETAT DE LART

Page 21

avec toute lquipe de dveloppement an de faire ltat des lieux de ce quil reste faire pour litration actuelle aussi nomm le sprint.

F IGURE 2.1 Le processus de dveloppement Scrum Scrum dnit les rles suivants : Directeur de produit : cest le reprsentant des clients et utilisateurs. Cest lui qui dnit lordre dans lequel les fonctionnalits seront dveloppes, et qui prend les dcisions importantes concernant lorientation du projet. Scrum Master : cest lui qui est charg de protger lquipe de tous les lments perturbateurs extrieurs lquipe et de rsoudre ses problmes non techniques (administratifs par exemple). Il doit aussi veiller ce que les valeurs de Scrum soient appliques, mais il nest ni un chef de projet ni un intermdiaire de communication avec les clients. Lquipe : ne comporte pas de rles prdnis, elle est autogre. Toutes les dcisions sont prises ensemble ; nous navons pas de notion dhirarchie interne. Intervenants : Les Intervenants (Stakeholders) sont les personnes qui souhaitent avoir une vue sur le projet sans rellement sinvestir dedans. Il peut sagir par exemple dexperts techniques, dagents de direction qui souhaitent avoir une vue trs loigne de lavancement du projet.

Moi MEME

Mmoire de Fin dEtudes ENSI 2011

CHAPITRE 2. ETAT DE LART

Page 22

F IGURE 2.2 Les rles du Scrum Les fonctionnalits exiges par le client sont listes dans un document appel " Backlog de Produit ". Le directeur du produit dnit les fonctionnalits les plus prioritaires dvelopper dans chaque " Sprint " suivant les besoins du client. Un " Sprint " est une itration du processus Scrum qui dure en thorie 30 jours et en pratique dure entre 2 et 4 semaines. Chaque Sprint possde un but bien dtermin et doit aboutir la livraison dun produit partiel susceptible dtre mis en exploitation. Les tches lmentaires raliser dans chaque Sprint sont dcomposes par lquipe, ce sont les items du Backlog du Sprint. Au quotidien, une runion permet lquipe et au Scrum Master de faire un point davancement sur les tches et sur les difcults rencontres. Scrum utilise une planication trois niveaux : release/projet, Sprint, et quotidien.

2.1.3

La mthode eXtrem Programming (XP)

LeXtrem Programming (XP) est une mthode de dveloppement logiciel qui cherche lefcacit maximale en concentrant leffort de travail sur lobjectif de dvelopper vite et juste. Donc il sagit de bien dvelopper le bon logiciel. La dmarche est lgre, pragmatique, discipline et adaptative. Loriginalit rside dans le fait de tout combiner et pousser lextrme. Aussi, la mthode privilgie un dveloppement en parfait accord avec les besoins du client. An dtre constamment en communication avec ce dernier, il est directement intgr lquipe de dveloppement. Ainsi les itrations peuvent tre trs courtes et par ce biais lquipe est trs ractive aux attentes du client. XP afrme que lefcacit maximale peut tre atteinte si le dveloppement respecte cinq valeurs : communication, retour dinformation, simplicit, courage et respect. Moi MEME Mmoire de Fin dEtudes ENSI 2011

CHAPITRE 2. ETAT DE LART

Page 23

La communication est ce qui importe le plus au sein dune quipe de dveloppement. Les problmes rencontrs lors dun projet sont souvent dus des manques dchange. Alors, la mthode prconise une communication intense et en continue au sein de lquipe y compris avec le client. La simplicit permet dviter les gaspillages et de rendre le logiciel souple, tolrant aux modications. Ainsi, XP prconise de toujours choisir la solution la plus simple qui soit viable. Le changement est invitable et continu lors dun dveloppement logiciel. Plutt que de gaspiller de lnergie contenir le changement, XP prconise de sy adapter. Un retour dinformation rapide et en continue sur le dveloppement permet alors de piloter le travail de manire ractive et de ladapter au changement. Il faut du courage pour surmonter la peur de dvelopper, changer sa manire de travailler, communiquer de manire transparente et confronter ses points de vue au retour dinformation. Enn, le courage de lquipe de dveloppement mrite le respect de tous les intervenants du projet. De plus, un travail dquipe efcace ncessite le respect mutuel des membres. Les valeurs sont universelles et donc difciles traduire en pratiques. Par contre, les principes sont spciques au domaine. Ils aident dterminer les pratiques concrtes appliquer en regard des valeurs. Dans le but de trouver une mthode agile qui rpond la gestion du dveloppement informatique, ce contexte on va intgrer Scrum avec XP. En effet, Scrum se concentre sur le management et les pratiques dorganisation tandis que XP se concentre surtout sur les pratiques de programmation concrtes. Cest pour a quils fonctionnent bien ensemble. Ils concernent diffrentes zones et sont complmentaires .

2.2

Etudes thoriques

On commence ltude thorique par la prsentation des dnitions de concepts projet et gestion de projets pour mettre notre application dans son cadre littraire.

2.2.1

Notion de projet

On appelle projet lensemble des actions entreprendre an de rpondre un besoin dni dans des dlais xs. Ainsi un projet tant une action temporaire avec un dbut et une n, mobilisant des ressources humaines et matrielles. Durant sa ralisation, le projet possde un cot et fait donc lobjet dun bilan budgtaire. La difcult dans la conduite du projet rside en grande partie dans la multiplicit des acteurs quil mobilise. En effet, contrairement aux projets personnels ou aux projets internes faible envergure, pour lesquels le besoin et la rponse ce besoin peuvent tre raliss par la mme personne ou par un nombre limit dintervenants, dans un projet au sens professionnel du terme, lexpression du besoin et la satisfaction de ce besoin sont ports par des acteurs gnralement distincts.

2.2.2

Notion de gestion de projets

On appelle gestion de projet lorganisation mthodologique mise en uvre pour faire en sorte que louvrage ralis par le matre duvre rpond aux attentes du matre douvrage et quil soit livr dans les conditions de cot et dlai prvus initialement. Pour ce faire, la gestion de projet Moi MEME Mmoire de Fin dEtudes ENSI 2011

CHAPITRE 2. ETAT DE LART

Page 24

a pour objectif dassurer la coordination des acteurs et des tches dans un souci defcacit et de rentabilit. Cest la raison pour laquelle, le chef de projet est nomm au niveau de la matrise douvrage an de veiller ce but nal. La gestion de projets repose sur la mise en uvre dune dmarche qui sappuie sur un dcoupage du cycle de vie dun projet en grandes phases comme suit : Lidentication du projet : qui ncessite le recours des mthodes danalyse de situation, danalyse et de rsolution de problmes, dlaboration dune structure dobjectif, didentication des enjeux stratgiques relis au projet et une tude de faisabilit. La dnition du projet : qui a recours lanalyse de lenvironnement du projet, de faon laborer une stratgie de gestion des parties prenantes du projet, une mthode de formulation du projet permettant dintgrer dans la conception du projet des proccupations dvaluation et des tudes spciques permettant de statuer sur la faisabilit du projet. La planication : ayant recours aux outils les plus connus de la gestion de projets, llaboration de la structure de fractionnement du travail, lidentication des biens livrables, la ralisation dun calendrier de ralisation en mettant contribution les techniques dordonnancement, laffectation des ressources et la budgtisation. Lexcution : qui ncessite, en plus de la mise en place dun systme dinformation aux ns de suivi, la mise en uvre de diffrentes habilits de la part du gestionnaire de projet appel aussi chef de projet : mobilisation des ressources, conduite de runions, gestion des conits, coordination, communication avec le client, etc.. Lvaluation : qui devient de plus en plus centrale dans les proccupations de gestion des organisations. Le cycle de vie de certains projets intgre une phase dvaluation rtrospective dont lobjectif est dapprcier limpact du projet. Lactivit du management peut tre regroupe en deux phases incontournables qui sont la planication oprationnelle et le suivi et qui assurent une bonne n du projet. LA PLANIFICATION OPRATIONNELLE La planication du projet est initialise au dbut dun projet et mise jour pendant toute sa dure de vie. Elle consiste en la dcomposition de chaque phase du projet en tapes puis chaque tape en actions qui sont en gnralement des tches de courtes dures. Elle inclut aussi laffectation des quipes et des ressources matrielles au projet. La planication stend aussi lestimation de la dure de ralisation du projet ainsi que cot. LE SUIVI DU PROJET Permet davoir une vue globale voir dtaille de ltat davancement du projet dune part et le rendement de chaque membre de lquipe projet, dune autre part. Dans cette phase, le chef de projet peut constater si le projet se droule dont les temps et cots qui lui ont t accords an dviter les risques de dpassement et prendre continuellement les bonnes mesures et dcisions. Le choix dune mthodologie pour conduire un projet est un atout permettant tous les acteurs de projet de mener conjointement une action organise selon des rgles clairement exprim.

2.2.3

Les portails web

Un portail est un outil qui centralise linformation en vue del mettre disposition dun plus grand nombre dindividus. On distingue deux grandes familles de portails : Moi MEME Mmoire de Fin dEtudes ENSI 2011

CHAPITRE 2. ETAT DE LART Les portails gnralistes, dont lillustration la plus vidente est Yahoo ! .

Page 25

Les portails dinformation dentreprise (EIP) qui sont des interfaces web scurises offrant un point dentre unique un ensemble de contenus et dapplications caractre analytique ou collaboratif. Les EIP sont les portails qui nous intressent ici. Les EIP peuvent tre classs dans les cinq catgories suivantes : documentaires, gestion de contenu, collaboratif, dcisionnel et applicatif. 1. Un portail documentaire est un logiciel qui fournit usuellement, en plus dune gestion documentaire, un ensemble de fonctionnalits comme un moteur de recherche plus au moins labor, un outil de catgorisation, une personnalisation de laccs, une possibilit de dnir des alertes en cration ou actualisation de documents dans un espace dni a priori. 2. Le portail de gestion de contenu, pour ce qui le concerne, assure lensemble du cycle de publication de contenu web et garantit leur adaptation personnalise. 3. Les portails collaboratifs ajoutant aux fonctionnalits usuelles des portails documentaires des fonctions de travail en groupe dans des espaces ddis. 4. Un portail dcisionnel offre laccs personnalis et la navigation aise dans une base de donnes dcisionnelle. 5. Le portail applicatif, quant lui, ajoute principalement aux fonctions assures par un portail collaboratif, un accs aux applications avec une connexion unique (Single Sign ON), un change avec des applications structures en utilisant une bibliothque de connecteurs ddis. Cest parce que ces portails fournissent une infrastructure pour lensemble des applications dentreprise, quils sont couramment appels Corporates Portals . Le concept du portail est gnralement li la notion de prol dutilisateur. En effet, idalement chaque utilisateur a accs aux ressources du systme en fonction de son prol, selon la politique de scurit dnie par lentreprise. Dautre part le prol dutilisateur peut galement servir la personnalisation visuelle (look feel), on parle alors denvironnement de travail en ligne ou bureau virtuel.

2.2.4

Les workows

Avec lexpansion du travail collaboratif, le concept de workow fait son apparition en 1990. An damliorer la productivit et la qualit au sein de lorganisation, cette notion pour dessein de structurer les processus rptitifs qui sollicitent les acteurs de lentreprise an de limiter leffet nfaste des les dattente que connaissent certains postes de travail, dacclrer la vitesse de transmission des dossiers, de coordonner les collaborateurs sur des secteurs gographiques divers, et doptimiser tout autre processus de transit des donnes. Selon la singularit du contexte, on donne diffrentes dnitions au workow. Le workow est premirement dni comme tant un processus sollicitant un nombre identi dindividus supposs accomplir des devoirs qui enrichissent un dessein commun dans un espace temporel limit. Le workow est ensuite dni en tant quautomatisation dun processus mtier. Durant lexcution de ce processus, un ensemble de rgles prcises tablissent lordre de transmission des informations dun acteur lautre, lacteur tant considr ici comme tant un programme ou un tre humain.

Moi MEME

Mmoire de Fin dEtudes ENSI 2011

CHAPITRE 2. ETAT DE LART

Page 26

F IGURE 2.3 Les Workow

Conclusion

Moi MEME

Mmoire de Fin dEtudes ENSI 2011

Chapitre 3

Sp cications des besoins e

Introduction
Dans le cadre de ce chapitre, nous entamons la premire phase de ralisation de notre projet. Tout dabord, nous allons identier les besoins fonctionnels et les besoins non fonctionnels. Ensuite, nous allons distinguer les principaux cas dutilisation et les acteurs pour dlimiter la porte du systme et nous allons affecter un niveau de priorit pour chaque cas dutilisation. Enn nous allons construire un prototype dinterface.

3.1
3.1.1

Capture des besoins

Besoins fonctionnels

Notre Application sadresse essentiellement deux types dutilisateurs, savoir les chefs de projets et les membres du projet. Ainsi il savre primordiale de dnir les fonctionnalits de chacun de ces acteurs. Les besoins des chefs de projets - Crer un projet. - Modier lensemble des projets crs (modication des diffrentes phases, ajout et suppression des phases ainsi que la modication des contraintes relatives au projet). - Modier et ajouter les diffrentes sous taches qui constituent les diffrentes phases dun projet bien dtermin. - Assigner les taches aux diffrents membres. - Affecter les diffrentes tches dans un diagramme de Gantt, soit automatiquement ou bien manuellement par la technique du drag and drop . - Visualiser les diffrents projets et taches grce lillustration dans un diagramme de Gantt. - Visualiser un diagramme de ressources an de mettre en vidence ltat actuel des ressources humaines disponibles

27

CHAPITRE 3. SPCIFICATIONS DES BESOINS

Page 28

- Recevoir des alertes sous forme de mail ou notication sur Social Intranet en cas de non-respect des contraintes temporelles. - Recevoir des alertes sous les mmes formes en cas daffectation dans une nouvelle tche. - Importer et exporter des projets partir des chiers externes de format Gantt Project et MS Project et les enregistrer dans la base de donnes local. - Faire des recherches avances sur lensemble des projets et des taches disponibles - Consulter larchive des transactions (Cration, Modication, Annulation, Affectation..) sous forme dun rapport. - Filtrer les rapports disponibles an de trouver une information assez prcise. - Dnir les droits daccs des membres dune faon assez dtaill. - Valider ou Refuser les taches qui ont t nalis par les membres des projets - Dnir les charges de travail de chaque membre dans chaque tache dans laquelle il a t affect. Les besoins des membres des projets - Modier la progression dans une de ses taches - Recevoir des alertes sous forme de mail ou notication sur Social Intranet en cas daffectation dans une nouvelle tche. - Finaliser une tache. - Crer, modier, annuler des taches suivant les droits daccs dni par le chef du projet parent. - Consulter les diffrents projets et taches ou il est affect en visualisant les diagrammes de Gantt illustrant les phases de ces derniers.

3.1.2

Les Besoins Non Fonctionnels

Avec les besoins fonctionnels cits ci-dessus, lapplication doit galement rpondre quelques aspects classiques dune telle Application tels que : - Il est important de soigner lergonomie de la Application an dattirer les utilisateurs en respectant la charte graphique du portail deXoPlatform. - Cette Application doit fournir une interface conviviale qui facilite aussi bien la saisie des tches et des phases que lillustration des diagrammes associs. - Assurer la scurit des donnes traites dans lApplication. - Garantir latomicit et la cohrence des donnes aprs les transactions effectues par les utilisateurs. - Lapplication doit coordonner avec les fonctionnalits dinternationalisation proposes par le portail. - Lapplication doit sadapter avec le contexte dans laquelle elle est intgre dans le portail (Avoir un comportement diffrent si elle est intgre dans un espace de lintranet). - Le systme doit rpondre tous les besoins fonctionnels prcdemment spcis. Moi MEME Mmoire de Fin dEtudes ENSI 2011

CHAPITRE 3. SPCIFICATIONS DES BESOINS

Page 29

3.1.3

Les Besoins Du Domaine

La gestion dun projet ncessite une organisation cohrente et prcise des tches raliser, pour cela il est important de dnir et de respecter les diffrentes contraintes temporelles entre ces tches.

3.2

Diagramme des cas dutilisation

Dans cette section, nous allons prsenter lensemble des diagrammes des cas dutilisation quon a conu, pour cela on dbutera par un diagramme assez gnral puis on rafnera chaque cas dutilisation gnral par un diagramme a part.

3.2.1

Diagramme gnral

Comme dj cit, les deux acteurs quon a dnis pour notre application sont le chef de projet et le membre de projet. A noter quun chef de projet nest quune spcication dun membre de projet do on peut conclure une relation dhritage entre les deux acteurs .Ceci revient dire que tous les cas dutilisation dun membre de projet sont en mme temps des cas dutilisation pour le chef de projet alors que le contraire est absolument faux puisque un chef de projet possde une liste de fonctionnalits de faon exclusive, il sagit de la gestion de projets , la gestion et le suivi des ressources . Pour tous les autres cas dutilisations, tous les utilisateurs de lapplication peuvent y bncier.

F IGURE 3.1 Diagramme de cas dutilisation gnral

Moi MEME

Mmoire de Fin dEtudes ENSI 2011

CHAPITRE 3. SPCIFICATIONS DES BESOINS

Page 30

3.2.2

Diagrammes des cas dutilisations dtaills

Gestion des projets Pour la gestion des projets un chef de projet peut crer, modier, supprimer, activer, dsactiver, importer et exporter des projets partir des chiers gnrs par les logiciels similaires MS Project et Gantt Project. Lors de la cration dun nouveau projet le chef de projet doit affecter ce dernier a un groupe dutilisateur ou une liste de membre du portail.

F IGURE 3.2 Gestion des projets Gestion des taches Concernant le cas dutilisation de la gestion des taches, le chef de projet bncie de certaines fonctionnalits en exclusivit par rapport aux autres utilisateurs : la suppression dune tache, le refus et la validation dune nalisation. Dautre part, pour certaines transactions, un commentaire est demand par celui qui effectuera cette transaction an de stocker les vnements produits comments, ceci a pour objet la journalisation et la ralisation dun rapport volutif. On notera aussi que certains cas dutilisation rserv pour les membres de projet sont fonctionnels quau cas o les droits daccs dni par le chef de projet le permettent.

Moi MEME

Mmoire de Fin dEtudes ENSI 2011

CHAPITRE 3. SPCIFICATIONS DES BESOINS

Page 31

F IGURE 3.3 Gestion des taches Gestion des ressources Lors de lajout dune nouvelle ressource, certaines donnes doivent tre spcies : le role de cette dernire, la charge de travail ainsi que les droits et les autorisations qui inuenceront la gestion des taches pour les membres de projets. Noublions pas linteraction de notre application avec le portail et surtout avec le produit deXoPlatform Social Intranet , lors de laffectation dune tache, une notication peut apparaitre dans la liste dactivits du membre concern ainsi quune lettre lectronique envoy son adresse mail, tous cela doit tre propos comme un service optionnel au moment de laffectation. Rappelons que la gestion des ressources est exclusivement consacr au crateur du projet parent qui doit tre obligatoirement un chef de projet.

Moi MEME

Mmoire de Fin dEtudes ENSI 2011

CHAPITRE 3. SPCIFICATIONS DES BESOINS

Page 32

F IGURE 3.4 Gestion des ressources Suivi des taches Le suivi des taches est un cas dutilisation accessible pour nimporte quel membre de la plateforme quel que soit le groupe dans lequel il appartient, ceci est lexception de la consultation des rapports qui est rserv seulement aux chefs de projets. Dautre part, lapplication assure la possibilit de modication des taches lors de la consultation des diagrammes de Gantt grce des techniques de drag and drop.

Moi MEME

Mmoire de Fin dEtudes ENSI 2011

CHAPITRE 3. SPCIFICATIONS DES BESOINS

Page 33

F IGURE 3.5 Suivi des taches Suivi des ressources Ce diagramme ci-dessous permet de montrer que le suivi de ressources comporte la consultation de diagrammes, de rapports et mme la possibilit deffectuer des recherches avancs.

F IGURE 3.6 Suivi des ressource

Moi MEME

Mmoire de Fin dEtudes ENSI 2011

CHAPITRE 3. SPCIFICATIONS DES BESOINS

Page 34

Conclusion
Dans ce chapitre, et comme dj dit dans la prsentation, on a mis a la disposition du lecteur de ce document le rsultat du capture des besoins en les numrant ainsi quun ensemble de diagrammes de cas dutilisation pour rendre les spcications assez claires.

Moi MEME

Mmoire de Fin dEtudes ENSI 2011

Chapitre 4

Conception

Introduction
Le prsent chapitre est consacr la phase de conception, une phase cruciale dans le cycle de dveloppement dun projet. Nous prsentons dabord larchitecture gnrale de lapplication en voquant quelques aspects techniques auxquels on a eu recours pour raliser cette architecture. Nous dtaillons, ensuite, les vues statiques de notre application travers le schma de dpendances entre les paquetages et le diagramme de classes, ainsi que les vues dynamiques dcrivant le fonctionnement de lapplication travers les diagrammes de squences.

4.1

Conception globale

Dans cette section, nous prsentons larchitecture n-tiers et celle de notre systme.

4.1.1

Architecture n-tiers

Notre application web repose sur une architecture n-tiers. Cest un modle logique darchitecture applicative qui vise sparer nettement n couches logicielles au sein dun mme systme (gnralement 3 ou 4 couches). Elle sert modliser et prsenter cette application comme un empilement de n couches (appeles aussi tages, niveaux ou strates) dont le rle est clairement dni comme suit : - La reprsentation des donnes : contient les utilisateurs (navigateurs web). - La couche de contrle : contient les traitements (Contrleurs de Use case UML) reprsentant les rgles mtiers. - Le traitement mtier des donnes : correspondant la mise en uvre de lensemble des rgles de gestion de la logique applicative. - Laccs aux donnes persistantes : correspondant aux donnes qui sont destines tre gardes sur une longue dure, voir de manire persistante. Dans cette approche, les couches communiquent entre elles au travers dun modle dchange et chacune dentre elles propose un ensemble de services rendus. Les services dune couche sont mis la disposition de la couche suprieure. On sinterdit par consquent quune couche invoque les services dune couche plus basse que la couche immdiatement infrieure ou plus haute que la couche immdiatement 35

CHAPITRE 4. CONCEPTION

Page 36

suprieure (chaque niveau ne communique quavec ses voisins immdiats). Le rle de chacune des couches et leur interface de communication tant bien dni, les fonctionnalits de chacune dentre elles peuvent voluer sans induire de changements dans les autres. Ce modle darchitecture n-tiers a pour objectif de rpondre aux proccupations suivantes : - La exibilit : Les applications sont sujettes des changements structurels frquents cause de la mutation rapide des technologies cest pourquoi lajout de nouveaux modules est primordiale pour la prennit de lapplication. - La scalabilit : est la capacit qua larchitecture pour voluer en cas de monte en charge si ncessaire. En effet, chaque module peut tre dploy indpendamment des autres sur une machine, ou un cluster de machines. Ce qui permet dajouter des ressources si besoin. - La modularit : est une approche structurante qui spare un logiciel en petites units qui rassembles composeront lensemble dun logiciel. Cette approche permet non seulement une certaine rutilisation de certaines units de traitements mais aussi une trs grande souplesse dans la modication puisque le changement dun module nimplique pas le changement de tous les autres. Maintenant aprs avoir fait une explication assez claire de larchitecture adopte ce diagramme ci-dessous prsente une illustration de cette architecture en donnant un aspect plus technique de la conception architecturale de notre application.

F IGURE 4.1 Architecture globale Couche prsentation Comme dj cit , larchitecture n-tiers se repose sur la dcomposition en couches, dans notre cas : quatre couche, la premire est responsable de la prsentation des donnes dans les navigateurs utiliss , celle-ci , sera assur grce aux outils de Google Web ToolKit , un outil prsentant un ensemble de composants graphiques , le fonctionnement de Google Web ToolKit Moi MEME Mmoire de Fin dEtudes ENSI 2011

CHAPITRE 4. CONCEPTION

Page 37

ainsi que tous ses avantages seront reprsents de faon plus dtaill dans les chapitres qui succdent le chapitre courant. Donc le fonctionnement de la couche prsentation sera assur grce des invocations de service Web Rest qui assure un ux de donnes avec la couche service via des objets JSON, ce mcanisme est assez expliqu dans le diagramme ci-dessus. F IGURE 4.2 Les objets JSON Interface Prsentation/Service JSON JSON (JavaScript Object Notation) est un format lger dchange de donnes. Il est indpendant de tout langage. JSON est reconnu nativement par JavaScript. Cest une alternative XML. Les principaux avantages de JSON sont quil est peu verbeux et facile apprendre. Une chane ou un document JSON reprsente un objet JavaScript. Un objet est un ensemble de couples nom/valeur. Les objets sont dclars entre accolades et les couples nom/valeur sont spars par une virgule. Voici un exemple dobjet : { "nom" : "Touili","prenom" :"Khadija","email" :"khadija.touili@exoplatform.com" } Un tableau est un ensemble de valeurs ordonnes. Les valeurs des tableaux sont entre crochets et spars par une virgule. Voici un exemple dobjet qui a pour valeur un tableau dobjets. { "personne" : [ { "nom" : "Touili", "prenom" :"Khadija", "email" :"khadija.touili@exoplatform.com" }, { "nom" : "Chetteoui", "prenom" :"Mohamed", "email" : "chetteoui.mohamed@exoplatform.com" }, { "nom" : "Chetteoui", "prenom" :"Maram", "email" : "chetteoui.maram@exoplatform.com" } ]} . Couche Service Le contrle des donnes est le mcanisme assur par cette couche, dun point de vue technique pur, ceci est assur grce a des services web qui sont dploys dans le serveur de lapplication grce au conteneur du portail deXoPlatform ces service la sont de type Restful invocable par des requtes URL. On peut citer deux services qui sont trs utiles lors du dmarrage de notre application. http://[AdresseIPserveur]:8080/usermanagement/myprojects : cette mthode est responsable de charger la liste des projets de lutilisateur connect dans la plateforme. http://[AdresseIPserveur]:8080/usermanagement/ismember/manager : cette mthode est responsable de dterminer au dmarrage de lapplication si lutilisateur connect appartient au groupe manager ou au groupe member an dafcher linterface correspondant. Nous invoquons avec plus de dtails les services Web Rest dans le paragraphe suivant. Les valeurs peuvent tre des objets, des tableaux, des chanes de caractres ou des nombres.

Moi MEME

Mmoire de Fin dEtudes ENSI 2011

CHAPITRE 4. CONCEPTION Interface Service/Mtier & Mtier/Accs base de donnes PortalContainer Couche Mtier

Page 38

Quant la couche mtier, elle est assur grce des services Web eXoPlatform qui sont dploys dans le serveur suivant des normes et des congurations qui suivent les spcications deXoPlatform, Ces derniers sont relis entre elles et reli aux services Rest grce ce quon appelle le Portal Container, un conteneur deXo dans lequel on dploie les services et les applications web . Comme pour les services Web Rest nous donnons ici deux exemples de services qui ont t utilis de manire assez importante dans notre application : - TaskStorage : un service responsable du stockage, mise jour suppression des taches. - ProjectStorage : un service responsable du stockage, mise jour suppression des projets. Linvocation de ces services et le dploiement dans le serveur est assur par le conteneur deXoPlatform Portal Container , une notion qui sera dveloppe dans le paragraphe qui succde le paragraphe courante vu son importance dans notre application. Couche Accs bas de donnes Java Content Repository API

4.2
4.2.1

Conception dtaille
Conception de la base de donnes

Vu que le contexte de cette conception est trs diffrent par rapport aux autres conceptions des bases de donnes des applications Web qui sont souvent des bases relationnelles. On va dtailler plus cette section an dexpliquer la structure de notre base. Rappelons aussi que la modlisation de cette conception nous a pos certains problmes tant quil nexiste pas un standard pour lillustration des conceptions de base de donnes similaires la ntre. Ceci nous a conduits essayer de trouver une mthode de modlisation assez claire pour rendre la structure conue clair par le lecteur de ce document. Types de nuds Comme cit dans des paragraphes prcdents, le Java Content Repository repose sur le principe des nuds qui possdent des proprits et des nuds ls et voici maintenant les nouveaux types de nuds quon a conu spcialement pour notre application et les diffrents proprits pour chacun , A noter quon a choisi un namespace qui uni tous nouveau type ajout par le namespace mgr :

Moi MEME

Mmoire de Fin dEtudes ENSI 2011

CHAPITRE 4. CONCEPTION

Page 39

Relations pre-ls Comme dj voque, une notion assez essentielle se prsente pour les bases de donnes de ce type, cest celle des relations pre ls entre les diffrents types de nuds. Dans notre conception, chaque nud de type mgr : Project possde deux catgories de nuds ls : - Des nuds de type mgr : task qui reprsente les sous taches du projet pre. - Des nuds de type mgr : resource qui sont responsable de stocker la liste des utilisateurs de la plateforme permis de faire partie de lquipe de ce projet ainsi que de tous les taches et les sous tache de son arborescence. Entre autre, les nuds de type mgr : task ont aussi deux types de nuds ls : - Des nuds de type mgr : task pour reprsenter les sous taches de la tache parente Moi MEME Mmoire de Fin dEtudes ENSI 2011

CHAPITRE 4. CONCEPTION

Page 40

- Des nuds de type mgr : resource pour stocker les ressources disponible pour cette tche. Apres avoir dni les nuds, leurs types, les relations entre eux et leurs proprits voici ci-dessous une gure assez intuitive permettant de modliser nos donnes et de mettre en vidence les relations entre les diffrents types de nuds. Ensuite on prsentera une instance de la conception dni an de mettre en vidence les diffrents concepts du Java Content Repository dj voqus. Modlisation Voici ci-dessous, un diagramme qui essaye de modliser les relations pre-ls entre les diffrents types de nuds, a noter quil existe des types de nuds prdnis dans la plateforme et quils sont reprsents ici par la couleur rouge pour les diffrencier par rapport aux types de nuds quon a dni dans notre conception.

F IGURE 4.3 Relations pre-ls entre les differents types de noeuds

Moi MEME

Mmoire de Fin dEtudes ENSI 2011

CHAPITRE 4. CONCEPTION

Page 41

F IGURE 4.4 Relations REFERENCE entre les diffrents types de noeuds

Moi MEME

Mmoire de Fin dEtudes ENSI 2011

CHAPITRE 4. CONCEPTION

Page 42

4.2.2

Diagramme de paquetage

F IGURE 4.5 Diagramme de paquetage

4.2.3

Diagramme des classes

Le diagramme de classes constitue un lment trs important de la modlisation. Il permet de dnir quelles seront les composantes du systme nal. On constate souvent quun diagramme de classes proprement ralis permet de structurer le travail de dveloppement de manire trs efcace. Il permet aussi, dans le cas de travaux raliss en groupe de sparer les composantes

Moi MEME

Mmoire de Fin dEtudes ENSI 2011

CHAPITRE 4. CONCEPTION

Page 43

de manire pouvoir rpartir le travail de dveloppement entre les membres du groupe. Enn, il permet de construire le systme de manire correcte.

F IGURE 4.6 Diagramme des classes

4.2.4

Les diagrammes de squences

Les diagrammes de squence peuvent servir illustrer un cas dutilisation dcrit dans le chapitre spcications des besoins. Ils permettent de reprsenter des interactions entre objets selon un point de vue temporel.

Moi MEME

Mmoire de Fin dEtudes ENSI 2011

CHAPITRE 4. CONCEPTION Diagramme de squence dajout dun nouveau projet

Page 44

Dans le diagramme ci-dessous, le processus de la cration dun nouveau projet est assez dtaill mais ne comporte pas tous le cycle. Dautres contrles, dautres services et dautres objets interviennent pour la cration du projet mais an de minimiser notre illustration, nous nous sommes contents des principaux tapes que suivent le processus de cration. A noter que PersoForm est une classe dinterface graphique or que tous les autres sont des services web qui assure en premier lieu grer les exceptions et les erreurs puis donne la possibilit de stockage des donnes de faon persistante dans la base de donne. On doit ajouter aussi que les services web utiliss dans ce cycle sont des services qui doivent tre dvelopps et ne sont pas disponible par dfaut dans la plateforme, ils sont spciques et propres a notre projet.

Moi MEME

Mmoire de Fin dEtudes ENSI 2011

CHAPITRE 4. CONCEPTION

Page 45

F IGURE 4.7 Diagramme de squence dajout dun nouveau projet

Moi MEME

Mmoire de Fin dEtudes ENSI 2011

CHAPITRE 4. CONCEPTION Diagramme dajout dune nouvelle tche

Page 46

F IGURE 4.8 Diagramme dajout dune nouvelle tche

Moi MEME

Mmoire de Fin dEtudes ENSI 2011

CHAPITRE 4. CONCEPTION Diagramme dajout dune nouvelle ressource une tche

Page 47

F IGURE 4.9 Diagramme dajout dune nouvelle ressource une tche

Moi MEME

Mmoire de Fin dEtudes ENSI 2011

CHAPITRE 4. CONCEPTION

Page 48

Conclusion
Tout au long de ce chapitre nous avons trait la phase de conception. Ceci est travers des diagrammes de squences et de classes. Une fois la conception est faite, nous arrivons la phase de dveloppement et de ralisation qui doit respecter les directives de la conception.

Moi MEME

Mmoire de Fin dEtudes ENSI 2011

Chapitre 5

R alisation e

Introduction
Dans ce chapitre nous commenons par prsenter lenvironnement matriel du projet ainsi que les outils utiliss. Ensuite, nous passerons la description du travail ralis tout au long de ce stage. Nous clturons par le chronogramme davancement de notre travail. 1) Environnement matrielle et logicielle : Dans ce paragraphe, nous prsentons la conguration matrielle et logicielle que nous avons exploit et nous prsentons les choix technologiques.

5.1

Environnement matrielle

An de mener ce projet et effectuer les tests adquats, il a t mis notre disposition un ensemble de 3 micro-ordinateurs dont les caractristiques sont : Processeur : Intel Core i3 Mmoire : 6 Go Lun de ces trois machines est quip par un Windows Seven pour tester lapplication en local.

5.2

Choix techniques et logicielles

Nous avons utilis pour la ralisation du projet la technologie J2EE. Nous exposerons dans ce qui suit une brve prsentation de cette plateforme ainsi que dautres outils utiliss lors de la ralisation de notre application autre que les outils qui ont t dj prsents dans ce qui prcde tout au long de ce rapport. Nous commenons, tout dabord, par prsenter larchitecture logicielle de notre application.

5.2.1

Architecture logicielle de lapplication

La gure ci-dessous illustre larchitecture logicielle de notre application :

49

CHAPITRE 5. RALISATION

Page 50

F IGURE 5.1 Architecture logicielle Choix de la plateforme JavaEE Bien que lemploi de cette technologie ntait pas un choix mais une obligation mais cela nempche de citer quelques avantages de lutilisation de la plateforme JavaEE : Serveur dapplication Tomcat Apache Tomcat est un conteneur libre de servlets et JSP Java EE. Issu du projet Jakarta, Tomcat est un projet principal de la fondation Apache. Tomcat implmente les spcications des servlets et des JSP du Java Community Process1. Il est paramtrable par des chiers XML et de proprits, et inclut des outils pour la conguration et la gestion. Il comporte galement un serveur HTTP. Sans tre un serveur dapplication complet, Tomcat 7 implmente les fonctionnalits dcrites dans les spcications du Java Enterprise Edition Web. Plus particulirement, il supporte la version 3.0 de lAPI (interface de programmation dapplication) Servlet et la version 2.2 de Java Server Pages, toutes deux rcemment valides Java EE 6. C.

Moi MEME

Mmoire de Fin dEtudes ENSI 2011

CHAPITRE 5. RALISATION Choix de Google Web ToolKit

Page 51

5.3 5.4

Aperu du travail ralis : Chronogramme :

Voici une ide approximative sur le droulement de projet rsum par le chronogramme ci-dessous : FIGURE Chronogramme Conclusion : Dans ce chapitre, il nous tait permis de permis de prsenter lenvironnement matriel et logiciel de notre projet. Cet environnement est caractris par lutilisation de la technologie JAVA EE. Nous avons donn, par la suite, quelques aperu sur le fruit de notre travail travers les imprimes dcran tmoignant des diffrents facettes de notre application.

Moi MEME

Mmoire de Fin dEtudes ENSI 2011

Chapitre 6

Tests et Validation :

Introduction : Apres avoir jeter un coup dil sur le rsultat du travail ,on tait oblig deffectuer une srie de test an de valider notre application , cette srie de tests peut tre divis en deux catgories essentiels : - Tests Fonctionnels : Elle consiste faire un bilan des cas dutilisations tests avec succs et celles chous avec dtermination exacte des bugs ainsi retrouvs. - Tests de Qualit : Elle concerne les tests des performances du serveur (temps de rponse, nombre de transactions...).

6.1
6.1.1

Tests fonctionnels
Outil utilis (Qmetry) :

Comme premire phase de test, on a essay de faire enregistrer les rsultats de test de chaque cas dutilisation. Et pour assurer ceci de faon assez efcace, on a eu recours loutil utilis dans eXoPlatform au sein de lquipe, il sagit de Qmetry, un outil qui enregistre les cas dutilisation et permet de mettre un statut pour chacun (passed, blocked, failed, N/A) et enn raliser quelque diagrammes de statistiques illustrant les tats des tests fonctionnels raliss, et voici une capture dcran de notre outil lors de la dernire phase des tests fonctionnels effectus.

52

CHAPITRE 6. TESTS ET VALIDATION :

Page 53

F IGURE 6.1 Capture decran de QMetry

6.1.2

Rsultats et interprtations

On remarque ici deux illustrations, la premire consiste reprsenter lhistorique des tats de tests effectus pour tous le projet alors que la deuxime est celle de la dernire phase courante effectue. En conclusion et comme rsultat nal, on a quarante-deux tests fonctionnels effectus avec succs sur un ensemble de cinquante tests raliss. Un rsultat quon peut qualier de satisfaisant en attendant la correction des bugs qui ont apparus lors des tests chous.

6.2
6.2.1

Test Qualit et performance

Outil utilis (JMeter)

An de sassurer de la qualit et des performances de lapplication dveloppe, et grce la coopration avec les quipes deXoPlatform, on a russi faire quelques tests de qualit en sappuyant sur des outils spcialistes dans cette catgorie de tests. A laide de loutil JMeter , qui permet de paramtrer nimporte quel scenario et de lexcuter de faon itrative , squentiel ou mme parallle an de faire stresser le serveur et tester sa capacit de rpondre aux requtes, on a construit nos scenarios et on les a excuter an de retrouver quelque constatations et quelques failles via des graphes et des courbes gnrs par cet outil.

6.2.2

Rsultats :

En effectuant dix itrations squentielles dun scenario dajout dune centaine de projets et dune tache pour chaque projet de faon simultan en Thread, on a obtenu les diagrammes suivants. Moi MEME Mmoire de Fin dEtudes ENSI 2011

CHAPITRE 6. TESTS ET VALIDATION :

Page 54

F IGURE 6.2 Temps de rponse du serveur

F IGURE 6.3 Nombre de transactions par seconde

6.2.3

Interprtations

Apres avoir examin ces graphes et plein dautres quon a gnr suite au travail ralis avec la coopration de lquipe TQA de lentreprise, on a constat quelques failles dans notre application quon citera dans la suite, mais rappelons que la comparaison des rsultats par rapport aux autres applications dploys dans le mme portail. Ceci ne nous permet pas de ngliger les problmes quon a dcouverts suite aux scenarios de tests excuts. Le diagramme qui illustre les temps de rponse du serveur suite aux requtes excutes nous montre quil y a un pic au dbut du droulement du scenario qui dmontre que le temps de rponse diminue quand la quantit de donnes et le nombre de requtes voluent. Moi MEME Mmoire de Fin dEtudes ENSI 2011

CHAPITRE 6. TESTS ET VALIDATION :

Page 55

Quant au diagramme illustrant le nombre de transactions par seconde montre que le nombre est assez satisfaisant en se mettant dans le repre des autres applications du portail ,mais , pour amliorer les performances on essayera de modier les services dvelopps pour augmenter le nombre de transactions par secondes en essayant de faire les traitements de faon parallle et viter les traitements squentiels.

Conclusion
Dans ce chapitre , on a prsent un aperu assez bref des tests qui ont t effectus sur lapplication quon a ralis et comme conclusion on peut dire que les rsultats tait de faon gnral assez satisfaisante en tenant compte de trois facteurs essentiels , les rsultats sont trs bonnes en les comparant aux autres applications dvelopps dans le portail, le droulement du travail a t effectu dans une priode assez rduite et la maitrise trop diminu de lenvironnement du travail (les outils utiliss, les langages de dveloppement et la plateforme elle-mme) .

Moi MEME

Mmoire de Fin dEtudes ENSI 2011

Conclusion g n rale e e

Bibliographie
[1] bla bla bla [2] Un titre de livre [3] bla bla bla

57

Nethographie
[N1] www.google.com [N2] www.facebook.com

58

Annexe A
bla bla bla

59

Annexe B
bla bla bla

60