Download (2465Kb)

Click here to load reader

  • date post

    05-Jan-2017
  • Category

    Documents

  • view

    214
  • download

    0

Embed Size (px)

Transcript of Download (2465Kb)

  • MEMOIRE

    DE STAGE DE FIN DETUDE Pour lobtention du

    MASTERE PROFESSIONNEL

    Nouvelles Technologies des Tlcommunications et Rseaux

    Prsent par :

    Walid Trabelsi

    Titre

    Cration dune application web

    KANBAN pour les restaurateurs

    Soutenu le : 08/02/2014

    Devant le jury :

    Mr. Ezeddine Ben Braiek Prsident

    Mr. Hassen Seddik Membre

    Mr. Jalel Khedhiri Membre

  • Ddicaces

    Je tiens remercier monsieur Jameleddine et

    mademoiselle Amira pour leurs prcieuses assistances

    et leurs orientations.

    Je tiens prsenter mes expressions de reconnaissance

    envers tous mes enseignants qui ont contribu ma

    formation en Mastre N2TR et qui ont particip

    lenrichissement de ma carrire universitaire et aux

    membres du jury pour lhonneur quils me feront en

    acceptant de juger ce modeste travail.

    Que tous ceux qui, tant aimablement ont particip de

    prs ou de loin llaboration de ce mmoire, trouvent

    en ces quelques lignes un modeste tmoignage dune

    sincre gratitude.

    Ddicaces

    Je tiens remercier monsieur Jameleddine et monsieur

    Riadh pour leurs prcieuses assistances et leurs

    orientations.

    Je tiens prsenter mes expressions de reconnaissance

    envers tous mes enseignants qui ont contribu ma

    formation en Mastre N2TR et qui ont particip

    lenrichissement de ma carrire universitaire et aux

    membres du jury pour lhonneur quils me feront en

    acceptant de juger ce modeste travail.

    Que tous ceux qui, tant aimablement ont particip de

    prs ou de loin llaboration de ce mmoire, trouvent

    en ces quelques lignes un modeste tmoignage dune

    sincre gratitude.

  • Trabelsi Walid

    1

    TABLE DES MATIERES

    Liste des figures .......................................................................................................................... 4

    Introduction Gnral ................................................................................................................... 5

    Chapitre 1 : Analyse et spcification des besoins ......................................................................... 8

    ................................................................................................................................................ 8

    INTRODUCTION ................................................................................................................... 9

    I. Objectif ............................................................................................................................ 9

    II. Cadre de projet.............................................................................................................. 9

    III. Contexte du systme ................................................................................................... 10

    1. Critiques et insuffisances ............................................................................................ 10

    IV. Cahier des charges ...................................................................................................... 10

    V. Identification des besoins ............................................................................................ 11

    2. Les besoins fonctionnels ............................................................................................. 11

    3. Les besoins NON fonctionnels : .................................................................................. 12

    VI. Recherche des acteurs et des cas dutilisation .............................................................. 12

    1. Les acteurs .................................................................................................................. 12

    2. Les cas dutilisation .................................................................................................... 12

    VII. Raffinement des cas dutilisation................................................................................. 13

    1. Cas dutilisation authentification : ............................................................................... 13

    2. Cas dutilisation affichage de planning du jour ............................................................ 13

  • Trabelsi Walid

    2

    3. Cas dutilisation suivi des rservations ........................................................................ 13

    4. Cas dutilisation gestion de plan des tables .................................................................. 14

    5. Cas dutilisation gestion des contacts .......................................................................... 14

    VIII. Le Plan Qualit Projet (PQP) : ................................................................................. 14

    1. Planification des taches : Diagramme de Gantt : .......................................................... 14

    2. QUALITE : Modle de cycle de vie: ........................................................................... 15

    Conclusion ............................................................................................................................ 18

    Chapitre 2 : Conception ............................................................................................................ 19

    Introduction ........................................................................................................................... 20

    I. Conception gnralE : .................................................................................................... 20

    1. Etude mthodologique ................................................................................................ 20

    2. Le Choix de la mthode .............................................................................................. 21

    3. Architecture modle/vue/contrleur ............................................................................ 22

    II. ConceptioN DETAILLEE ........................................................................................... 23

    1. La modlisation dynamique : ...................................................................................... 23

    2. La modlisation statique : ........................................................................................... 26

    Conclusion ............................................................................................................................ 28

    Chapitre 3 : Dveloppement ...................................................................................................... 29

    Introduction ........................................................................................................................... 29

    I. Environnement de dveloppement : ................................................................................ 30

    1. SGBD: MySQL .......................................................................................................... 30

    2. EDI: Netbeans ............................................................................................................ 30

  • Trabelsi Walid

    3

    3. Le serveur dapplication j2ee : GlassFish .................................................................... 30

    II. Langage & Framework ............................................................................................... 31

    1. Framework JSF ......................................................................................................... 31

    2. API JPA 2.0 EclipseLink ........................................................................................... 32

    3. API de logging : Log4j................................................................................................ 32

    4. PrimeFaces ................................................................................................................. 32

    II. Ergonomie et conception des interfaces graphiques ..................................................... 33

    III. Quelques interfaces de cette application ...................................................................... 34

    Conclusion ............................................................................................................................ 40

    Conclusion General ................................................................................................................... 41

    Glossaire ................................................................................................................................... 42

    Bibliographie ............................................................................................................................ 44

    Netographie .............................................................................................................................. 45

    Annexe ..................................................................................................................................... 46

    Rsum ..................................................................................................................................... 57

    57 .........................................................................................................................................

    Abstract .................................................................................................................................... 57

  • Trabelsi Walid

    4

    LISTE DES FIGURES

    FIGURE 1 - TABLEAU DES ACTEURS............................................................................................ 12

    FIGURE 2 - TABLEAU DES CAS DUTILISATION ............................................................................ 13

    FIGURE 3 - DIAGRAMME DE GANTT .......................................................................................... 14

    FIGURE 4 - CYCLE DE VIE EN SPIRALE ......................................................................................... 15

    FIGURE 5 - CYCLE DE VIE EN CASCADE ....................................................................................... 16

    FIGURE 6 - CYCLE DE VIE EN V ................................................................................................... 17

    FIGURE 7- TABLEAU RECAPITULATIF DES MODELES MERISE ...................................................... 20

    FIGURE 8 - SCHEMA MODELE MVC............................................................................................ 23

    FIGURE 9 - DIAGRAMME DE SEQUENCES AUTHENTIFICATION ............................................. 24

    FIGURE 10 - DIAGRAMMES DE SEQUENCES PLANNING DU JOUR ......................................... 25

    FIGURE 11- DIAGRAMME DES CAS DUTILISATION .................................................................... 26

    FIGURE 12 - DIAGRAMME DE CLASSE ........................................................................................ 27

    FIGURE 13- ARCHITECTURE D'UNE PAGE PRIMEFACES .............................................................. 33

    FIGURE 14 - LA PAGE D'INSCRIPTION......................................................................................... 34

    FIGURE 15 - PAGE AUTHENTIFICATION ...................................................................................... 35

    FIGURE 16- AGENDA DES EVENEMENTS .................................................................................... 35

    FIGURE 17 - PAGE AJOUTER UNE NOTE ..................................................................................... 36

    FIGURE 18 - PAGE LISTE DES TABLES ......................................................................................... 37

    FIGURE 19 - PAGE AJOUTER UNE TABLE .................................................................................... 37

    FIGURE 20- PAGES SUIVIE DES RESERVATIONS .......................................................................... 38

    FIGURE 21 - AJOUTER RESERVATION ......................................................................................... 38

    FIGURE 22 UNE PAGE POUR SUIVRE LA LISTE DE CONTACTS CLIENTELE ................................. 39

    FIGURE 23 UNE INTERFACE POUR AJOUTER UN NOUVEAU CLIENT......................................... 39

    FIGURE 24 LA PAGE DINFO. CLIENT ....................................................................................... 40

    FIGURE 25 - LES PROCESSUS DE DEVELOPPEMENT D'UN LOGICIEL SELON UP ........................... 46

    FIGURE 26 UN TABLEAU KANBAN ........................................................................................... 47

    FIGURE 27 COUCHE DACCES AUX DONNEES ............................................................................. 53

    FIGURE 28 - LES COMPOSANT DE FRAMEWORK LOG4J ............................................................. 56

  • Trabelsi Walid

    5

    INTRODUCTION GENERAL

  • Trabelsi Walid

    6

    urant ces dernires annes l'informatique s'est impose d'une manire trs impressionnante

    dans les entreprises, cela est d son apport extraordinaire dans la gestion de leurs systmes

    dinformations et la mise en application de certaines mthodes de fabrication ou de contrle

    citons titre dexemple la fameuse mthode japonaise kanban .

    Kanban ( ou ) est un terme japonais signifiant regarder le tableau cette

    mthode, dploye la fin des annes 50 dans les usines Toyota, est mise en place entre deux

    postes de travail et limite la production du poste amont aux besoins exacts du poste aval. Cette

    mthode est surtout adapte aux entreprises ayant une production rptitive et relativement

    rgulire.

    Le principe de kanban est bas sur son nombre en circulation qui doit tre limit pour viter la

    constitution d'encours trop importants. La mthode kanban ne dispense pas cependant d'tablir

    des prvisions de vente et un programme de production dtaill moyen terme. C'est en effet une

    technique de gestion de la production court terme et elle peut s'intgrer parfaitement dans la

    gestion non pas seulement industrielle mais aussi la gestion de donnes professionnelles y est

    compris celui de la gestion de donnes restaurateurs auquel nous rattacherons d'ailleurs notre

    tude, et cela pour une meilleure gestion des diffrents traitements exigs selon cette mthode

    des cartes.

    Nous avons constat, en effet, pendant nos recherches que l'ensemble des traitements au sein du

    restaurant se fait manuellement, ce qui engendre un certain nombre de problmes tels que la

    lenteur dans l'accs aux donnes et le risque de perte d'informations ; donc la meilleure solution

    pour pallier aux problmes de gestion de ces activits est l'informatisation afin d'assurer l'accs

    instantan aux donnes et scuriser ces dernires, ce qui simplifie le travail administratif.

    De ce fait, il nous a t sollicit par les restaurateurs afin de leur concevoir un systme

    d'information automatis pour la gestion de donnes et pour raliser cette tche, notre choix s'est

    port sur le Processus Unifi. En effet, le processus unifi est une solution de dveloppement

    logiciel adapte tout type de projet. Ses traits distinctifs tiennent en trois notions : pilot par les

    D

  • Trabelsi Walid

    7

    cas d'utilisation, centr sur l'architecture, itratif et incrmental.

    Pour l'implmentation, le choix du langage de programmation a t dict par le type de

    l'application qui devrait tre ralise d'une part, et tre accessible via le rseau Internet la

    porte de tout le monde, selon la technologie Client/serveur qui est largement utilise de nos

    jours, et qui constitue une volution des systmes classiques et permet par lutilisation de

    nouvelles mthodes et techniques plus flexibles et fiables.

    Notre travail consiste concevoir une application qui permet de grer le systme dinformations

    relative au restaurateur : contact, rservation, tables...et pour atteindre notre objectif nous avons

    partag le travail comme suit :

    Dans le premier chapitre analyse et spcification, on sintressera la capture des besoins qui

    consiste llaboration dun bilan des besoins et lanalyse architecturale du systme concevoir

    ainsi de dterminer les aspects gnraux de lapplication en identifiant les principales

    composantes du systme. La conception est prsente dans le deuxime chapitre elle est axe sur

    les mthodes de conception de lapplication sous forme dun ensemble de diagrammes ainsi que

    la conception de la base de donnes. Le dernier chapitre qui est limplmentation voque les

    diffrentes techniques, outils et environnements de dveloppement ainsi que de reprsenter

    quelques interfaces utilisateurs de lapplication.

  • Trabelsi Walid

    8

    CHAPITRE 1 : ANALYSE ET

    SPECIFICATION DES BESOINS

    Ce n'est pas la conscience des hommes La

    valeur d'un homme tient dans sa capacit

    donner et non dans sa capacit

    recevoir. Albert Einstein

  • Trabelsi Walid

    9

    INTRODUCTION

    Lobjet de ce chapitre est de dvelopper un modle du systme construire, un systme tant un

    tout constitu dlments munis de proprits unis par des relations. Ce modle est labor suite

    des demandes des utilisateurs. ce niveau, le rle du concepteur est restreint la fonction

    danalyste. A ce stade, nous devons recenser les besoins, ventuellement critiquer la dmarche

    dlaboration de statistiques actuelles, comprendre le contexte du systme, formuler les besoins

    fonctionnels et non fonctionnels (autour du systme).

    Il s'agit d'une tape cruciale dans la ralisation d'une application donne. En gnral, lobjectif de

    lanalyse est darriver la comprhension des besoins et des exigences du cahier de charges. Il

    sagit de livrer des spcifications pour permettre de choisir la conception de la solution. Cette

    partie permet donc dexpliciter en clair les grands traits et spcifications des parties

    fondamentales de lapplication dvelopper.

    I. OBJECTIF

    Ce projet consiste dvelopper une application web en J2EE pour la gestion des tches

    quotidiennes personnelles et professionnelles dun restaurateur en utilisant comme langage de

    programmation JSF JAVA SERVER FACES et API JPA comme outil de persistance des

    donnes avec une base de donnes MySQL.

    II. CADRE DE PROJET

    Hra. performance engineering est une entreprise franco-tunisienne ddition de sites web

    thmatiques et de dveloppement dapplications en ligne pour ses clients internationaux. Elle

    mne aussi dautres activits dans le domaine de marketing numrique et le rfrencement web.

    Elle est actuellement une start-up en pleine expansion, gre par des comptences jeunes et sous

    la direction dun promoteur franais.

    Les activits de HRA performance sont trs varies, nous pouvons en mentionner quelques-unes

    Conception et dveloppement des sites web

    Conception, scurisation et audit de rseaux.

  • Trabelsi Walid

    10

    Conception et mise en place des bases de donnes.

    Dveloppement des applications.

    Rdaction des cahiers de charges.

    III. CONTEXTE DU SYSTEME

    Comme nous l'avons cit prcdemment, BNS Engineering n'est pas une socit consommatrice,

    elle est plutt productrice. Toutes les applications dveloppes sont destines alors la vente.

    L'application en question s'agit d'une application de gestion des tches quotidiennes

    personnelles et professionnelles de son utilisateur ddie au restaurateur. Cette solution doit tre

    capable dorganiser et structurer les donnes et les rservations qui sont faites l'heure actuelle

    manuellement.

    1. CRITIQUES ET INSUFFISANCES

    La solution actuelle est manuelle :

    Labsence dun systme pour suivre les services proposs et les rservations en temps

    rel.

    Un besoin dun nombre additionnel d'employs pour grer les diffrentes tches

    administratives.

    Risque de perdre des contacts (fournisseur, client): ce qui peut tre fatal sur le

    droulement du travail au restaurant.

    Le suivi des clients et des fournisseurs peut rencontrer beaucoup de problmes.

    La perte de clientle suite la bureaucratie du systme de rservation par tlphone.

    IV. CAHIER DES CHARGES

    Ce projet de fin dtudes vise mettre le point sur des tches bien prcises relatives la gestion

    des donnes au profit des restaurateurs.

    En effet, les tches sont les suivantes :

  • Trabelsi Walid

    11

    Chaque nouveau utilisateur est appel sinscrire dans cette application et enregistrer les

    donnes relatives son profil.

    Pour chaque utilisateur inscrit, un compte daccs lui sera attribu afin quil puisse

    sauthentifier et utiliser les diffrents services de cette application.

    Suivi du planning de jour : les tches journalires et les notes personnelles dans un

    agenda.

    Ajout des notes de rappel sous forme dtiquettes afficher sur lagenda.

    Cration des cartes de contacts client et fournisseur : ajout et suppression, modification

    des informations.

    Suivi des rservations et envoi des emails automatiques aux clients.

    Gestion du plan de tables tout en donnant la possibilit dajouter et modifier les donnes

    relatives chaque table que ce soit son numro, le nombre de personnes, service, fumeur

    ou non.

    Ajout un menu de jour et le publier en envoyant un email pour les utilisateurs de ce

    systme.

    V. IDENTIFICATION DES BESOINS

    2. LES BESOINS FONCTIONNELS

    Lapplication conue devra fonctionner en mode 3 tiers (client lger, serveur de

    donnes, serveur dapplication).

    Chaque restaurateur possdant un identifiant unique pour accder cette application.

    Le restaurateur peut ajouter, supprimer, modifier ses donnes de profils, grer ses

    contacts client, fournisseurs, les affecter au rpertoire bien dtermin ou un sous-groupe

    de ce rpertoire.

    Afficher au planning rcap. du jour les rservations djeun, dner.

    Crer un ou plusieurs plans de tables de salle de restaurant.

    Gestion du menu du jour : crer un nouveau menu, attribuer une date, adresser les menus

    aux clients.

    Journaliser les avertissements, alertes, erreurs, bugs gnrs et qui peuvent tre utiles au

    dbogage.

  • Trabelsi Walid

    12

    3. LES BESOINS NON FONCTIONNELS :

    Lapplication doit permettre de grer les accs des utilisateurs selon un privilge et un

    tat dactivation de chaque compte.

    Il faut garantir la scurit daccs lespace administrateur afin de protger les donnes

    personnelles des utilisateurs.

    Prvenir contre laccs direct avec les liens URL et dfinir un dlai de temps pour la

    fermeture de session non active.

    Linterface de cette application doit tre ergonome, conviviale et voire mme apte aider

    lutilisateur mieux grer son espace de travail.

    VI. RECHERCHE DES ACTEURS ET DES CAS DUTILISATION

    1. LES ACTEURS

    Les acteurs nappartiennent pas au systme, mais ils interagissent avec celui-ci. Ils fournissent

    de linformation en entre et/ou reoivent de linformation en sortie, ils ne sont pas forcment

    des personnes.

    En UML, il nest pas exclure la possibilit de spcialiser des acteurs partir dautres acteurs.

    En ce qui concerne notre systme, nous avons class les acteurs en deux catgories.

    Acteurs internes Acteurs externes

    Restaurateurs client

    FIGURE 1 - TABLEAU DES ACTEURS

    2. LES CAS DUTILISATION

    Pour cette application, les cas dutilisation les plus pertinents sont les suivants :

    Les cas dutilisation Priorit

  • Trabelsi Walid

    13

    Authentification

    Afficher le planning du jour

    Suivie des rservations

    Grer le plan des tables

    Gestion du contact client

    Gestion du contact fournisseur

    1

    2

    2

    3

    3

    3

    FIGURE 2 - TABLEAU DES CAS DUTILISATION

    VII. RAFFINEMENT DES CAS DUTILISATION

    1. CAS DUTILISATION AUTHENTIFICATION :

    Le restaurateur ou le gestionnaire se connecte au systme et saisit son login et mot de passe. Le

    systme vrifie le mot de passe introduit. Si ce dernier est correct, laccs est autoris et une

    nouvelle session sera tablie.

    2. CAS DUTILISATION AFFICHAGE DE PLANNING DU JOUR

    Il sagit dun agenda rcapitulatif de notes personnelles et professionnelles du restaurateur et de

    lui mettre en place un suivi rgulier de:

    Ses rendez-vous professionnels et personnels

    Notes pense bte

    Rservations clientles,

    Les dates marquantes pour lutilisateur de cette application (fte, date de naissance...)

    Par ailleurs il est possible de modifier lensemble de ces donnes et les supprimer directement

    partir de cet agenda et avoir une alerte automatique sous forme pop-up pour informer

    lutilisateur.

    3. CAS DUTILISATION SUIVI DES RESERVATIONS

    Ce cas dutilisation offre la possibilit de suivre en temps rel les rservations des tables. Aprs

    chaque rservation passe par les clients ou le restaurateur, une note sera affiche dans le tableau

    des tables indiquant le nom du client et lheure de son arrive. Lorsque lheure limite sera

    dpasse, un mot dpass devra safficher automatiquement ct de lheure limite. Comme il

  • Trabelsi Walid

    14

    est possible dannuler ou modifier une ou plusieurs rservations enregistres dans ce tableau de

    suivi.

    4. CAS DUTILISATION GESTION DE PLAN DES TABLES

    Chaque restaurant dispose dune salle de restaurateur ou une terrasse compose de quelques

    tables pour 2, 4,8 personnes disposes selon un plan bien dfini suivant les services offerts et le

    type des clients convoits. Avec ce plan, il est possible de suivre en dtail la disponibilit et les

    dispositions de ces tables. Comme il est possible dajouter ou supprimer une table dun plan

    donn.

    5. CAS DUTILISATION GESTION DES CONTACTS

    Chaque restaurateur dot dun carnet de contacts a la possibilit dajouter, supprimer ou modifier

    des contacts clients ou fournisseur et de mener des recherches sur ces derniers selon un critre

    bien dfini.

    VIII. LE PLAN QUALITE PROJET (PQP) :

    Le Plan Qualit de Projet (ou PQP) a pour objectif la dfinition et le suivi des dispositions

    prendre dans le cadre du projet afin den assurer la qualit et datteindre les rsultats attendus.

    1. PLANIFICATION DES TACHES : DIAGRAMME DE GANTT :

    Le diagramme de GANTT est un outil permettant de modliser la planification de tches

    ncessaires la ralisation d'un projet.

    Pour arriver raliser ce projet, nous avons suivi le planning suivant :

    ID Nom de tche Dbut Terminer Dure

    avr. 2013mars 2013

    24/33/3 31/310/3 17/3

    1 24j04/04/201304/03/2013Mise en place de lenvironnement de

    travail

    2 23j03/06/201302/05/2013Analyse

    3 25j05/07/201303/06/2013conception

    4 77j29/10/201315/07/2013Dveloppent

    5 119j31/10/201320/05/2013Rdaction rapport

    6 11j29/11/201315/11/2013Prparation dune prsentation

    7 22j29/11/201331/10/2013Test

    mai 2013 juin 2013 juil. 2013 aot 2013 sept. 2013 oct. 2013

    7/4 14/4 21/4 28/4 5/5 12/5 19/5 26/5 2/6 9/6 16/6 23/6 30/6 7/7 14/7 21/7 28/7 4/8 11/8 18/8 25/8 1/9 8/9 15/9 22/9 29/9 6/10 13/10 20/10

    FIGURE 3 - DIAGRAMME DE GANTT

  • Trabelsi Walid

    15

    2. QUALITE : MODELE DE CYCLE DE VIE:

    Le cycle de vie d'un logiciel dsigne toutes les tapes du dveloppement d'un logiciel, de sa

    conception sa disparition. L'objectif d'un tel dcoupage est de permettre de dfinir des jalons

    intermdiaires permettant la validation du dveloppement logiciel, c'est--dire la conformit du

    logiciel avec les besoins exprims Il existe une varit de ces modles : en cascade, W,Y.

    A. MODELE DE CYCLE DE VIE EN SPIRALE

    Propos par B. Boehm en 1988, ce modle est beaucoup plus gnral que le prcdent. Il met

    l'accent sur l'activit d'analyse des risques : chaque cycle de la spirale se droule en quatre phases

    :

    dtermination, partir des rsultats des cycles prcdents, ou de l'analyse prliminaire

    des besoins, des objectifs du cycle, des alternatives pour les atteindre et des contraintes.

    Analyse des risques, valuation des alternatives et, ventuellement maquettage.

    Dveloppement et vrification de la solution retenue, un modle classique (Cascade

    ou en V)

    FIGURE 4 - CYCLE DE VIE EN SPIRALE

  • Trabelsi Walid

    16

    B. LE MODELE DE CYCLE DE VIE EN CASCADE

    Le modle de cycle de vie en cascade a t mis au point ds 1966, puis formalis aux alentours

    de 1970. Dans ce modle le principe est trs simple : chaque phase se termine une date prcise

    par la production de certains documents ou logiciels. Les rsultats sont dfinis sur la base des

    interactions entre tapes, ils sont soumis une revue approfondie et on ne passe la phase

    suivante que s'ils sont jugs satisfaisants. Le modle original ne comportait pas de possibilit de

    retour en arrire. Celle-ci a t rajoute ultrieurement sur la base qu'une tape ne remet en cause

    que l'tape prcdente, ce qui est dans la pratique s'avre insuffisant.

    Spcification

    Intgration

    Codage

    Conception dtaill

    Conception gnrale

    Validation

    Mise en production

    Maintenance

    Tests unitaires

    Test dintgration

    Validation

    Vrification

    Vrification

    FIGURE 5 - CYCLE DE VIE EN CASCADE

  • Trabelsi Walid

    17

    C. LE MODELE DE CYCLE DE VIE EN V :

    Le modle en V demeure actuellement le cycle de vie le plus connu et certainement le plus

    utilis. Le principe de ce modle est qu'avec toute dcomposition doit tre dcrite la

    recomposition, et que toute description d'un composant doit tre accompagne de tests qui

    permettront de s'assurer qu'il correspond sa description.

    Ceci rend explicite la prparation des dernires phases (validation-vrification) par les premires

    (construction du logiciel), et permet ainsi d'viter un cueil bien connu de la spcification du

    logiciel : noncer une proprit qu'il est impossible de vrifier objectivement aprs la ralisation.

    D. CHOIX CYCLE DE VIE

    La mthode adquate que nous avons mis en uvre dans ce travail est le modle en V .Ce

    modle est plus rcent et plus proche de la ralit de l'articulation entre les activits de

    spcification et de conception, avec celles de validation et vrification. En effet, contrairement

    au modle de cascade, ce modle fait apparatre le fait que le dbut du processus de

    dveloppement conditionne ses dernires tapes :

    Spcification

    Conception gnral

    Conception dtaill

    Programmation

    Test unitaire

    Intgration

    Qualification

    FIGURE 6 - CYCLE DE VIE EN V

  • Trabelsi Walid

    18

    CONCLUSION

    Nous avons tent dans cette partie danalyser lexistant et dextraire les objectifs attendus. Par la

    suite, nous avons procd lexpression des besoins pour couronner lidentification des

    principaux acteurs de notre systme et les cas dutilisation relatifs chacun dentre eux. Avec ce

    que nous avons pu dgager, lapplication que nous devrions raliser est devenue claire. Par

    consquent, nous essayerons dans les tapes suivantes de rpondre ces besoins en entamant la

    phase de conception dans le chapitre suivant.

  • Trabelsi Walid

    19

    CHAPITRE 2 : CONCEPTION

    C'est la qualit de l'uvre qui doit porter

    et lgitimer la technologie et non

    l'inverse. Jean Zeitoun

  • Trabelsi Walid

    20

    INTRODUCTION

    La conception permet dacqurir une comprhension approfondie des contraintes lies au

    langage de programmation, lutilisation des composants et au systme dexploitation. Elle

    dtermine entre autres les principales interfaces et les transcrit laide dune notation commune

    en donnant un point de dpart limplmentation.

    I. CONCEPTION GENERALE :

    1. ETUDE METHODOLOGIQUE

    La conception d'un systme d'information n'est pas vidente car il faut rflchir l'ensemble de

    l'organisation que l'on doit mettre en place. La phase de conception ncessite des mthodes

    permettant de mettre en place un modle sur lequel on va s'appuyer.

    E. METHODE MERISE

    Merise tant une mthode de conception et de dveloppement de systme dinformation dat de

    1978-1979, il est bas sur la sparation des donnes et des traitements effectuer en plusieurs

    modles conceptuels et organisationnels, physiques.

    Niveau Statique (donnes) Dynamique

    (traitements)

    Conceptuel MCD MCT Indpendant du systme:

    QUOI ?

    Organisationnel

    ou logique

    MLD

    (OU ?)

    MOT

    (QUI ? QUAND ?)

    Choix du SGBD:

    QUI?QUAND? OU ?

    Oprationnel

    ou physique

    MPD MOPT Haute connaissance du

    SGBD:COMMENT ?

    FIGURE 7- TABLEAU RECAPITULATIF DES MODELES MERISE

  • Trabelsi Walid

    21

    F. PROCESSUS UNIFIE(UP) :

    Le processus unifi est un processus de dveloppement dune application itrative, centr sur

    l'architecture, pilot par des cas d'utilisation et orient vers la diminution des risques, il regroupe

    les activits mener pour transformer les besoins dun utilisateur en systme logiciel.

    Cest une mthode de prise en charge du cycle de vie dun logiciel et donc du dveloppement,

    pour les logiciels orients objets. Cest une mthode gnrique, itrative et incrmentale,

    contrairement la mthode squentielle Merise.

    L'objectif d'un processus unifi est de matriser la complexit des projets informatiques en

    diminuant les risques. En rpondant aux proccupations suivantes :

    QUI participe au projet ?

    QUOI, qu'est-ce qui est produit durant le projet ?

    COMMENT doit-il tre ralis ?

    QUAND est ralis chaque livrable ?

    2. LE CHOIX DE LA METHODE

    Pour la ralisation de cette application, notre choix a t port sur le Processus Unifi. En effet,

    le processus unifi est une solution de dveloppement logiciel adapte tout type de projet. Ses

    traits distinctifs tiennent compte de trois notions : pilot par les cas d'utilisation, centr sur

    l'architecture, itratif et incrmental.

    Le langage de modlisation que nous avons utilis est UML (Unifier Modeling Language), qui

    est une partie intgrante de la dmarche UP.

    Ses diagrammes sont largement utiliss dans chaque tape et phase de ce processus de

    dveloppement, il est idal pour :

    Concevoir et dployer une architecture logicielle dveloppe dans un langage objet (Java,

    C++, VB.net). Certes UML, dans sa volont "unificatrice" a propos des formalismes.

    Pour modliser les donnes (le modle de classe rduit sans mthodes et strotyp en

    entits), mais avec des lacunes que ne prsentait pas l'entit relation de Merise.

  • Trabelsi Walid

    22

    Pour modliser le fonctionnement mtier (le diagramme d'activit et de cas d'utilisation)

    qui sont des formalismes trs anciens qu'avait, en son temps, amlior Merise...

    Pour l'implmentation, le choix s'est port sur le langage de programmation JSP/JSF

    implment dans un environnement J2EE avec une base de donnes MySQL.

    3. ARCHITECTURE MODELE/VUE/CONTROLEUR

    L'organisation d'une interface graphique est dlicate. L'architecture MVC ne prtend pas

    liminer tous les problmes, mais fournit une premire approche pour le faire. Offrant un cadre

    normalis pour structurer une application, elle facilite aussi le dialogue entre les concepteurs.

    L'ide est de bien sparer les donnes, la prsentation et les traitements. Il en rsulte les trois

    parties numres plus haut : le modle, la vue et le contrleur.

    Le modle reprsente le cur (algorithmique) de l'application : traitements des donnes,

    interactions avec la base de donnes, etc. Il dcrit les donnes manipules par l'application

    Il est reprsent dans ce projet sous forme des classes de lapi JPA, JDBC.

    La vue, ce avec quoi l'utilisateur interagit. Sa premire tche est de prsenter les rsultats

    renvoys par le modle. Elle se contente d'afficher les rsultats des traitements effectus par le

    modle et d'interagir avec l'utilisateur.

    Elle est reprsente sous forme de pages JSP/XHTML / Primeface.

    Le contrleur prend en charge la gestion des vnements de synchronisation pour mettre jour

    la vue ou le modle et les synchroniser

    Il est reprsent sous forme de classes contrles : servlets

  • Trabelsi Walid

    23

    Vue

    controleur

    Modle

    Servlet

    Html

    Xhtml

    Bean

    Requte

    Man

    ipul

    atio

    n de

    s do

    nne

    s

    Rponse

    Navigateur

    SGBD

    Serveur application

    FIGURE 8 - SCHEMA MODELE MVC

    II. CONCEPTION DETAILLEE

    Aprs la conception et ltude prliminaire des diffrentes fonctionnalits de cette application,

    nous entreprenons la modlisation des diffrentes activits sous forme de diagrammes UML dans

    ses deux aspects dynamique et statique.

    1. LA MODELISATION DYNAMIQUE :

    UML2 possde treize diagrammes. A la catgorie dynamique elle seule sont associs huit

    diagrammes dfinissant le cycle de vie des objets en prcisant : le comportement des objets, les

    diffrents tats par lesquels ils passent et les vnements qui dclenchent ces changements

    d'tats. Dans cette application, nous allons se servir des deux seulement noncs ci-dessus. Nous

    ne pouvons pas aller directement la conception sans faire une petite description du

    fonctionnement de l'application.

    A. DIAGRAMME DE SEQUENCES

    Le diagramme de squence vise essentiellement reprsenter des interactions entre les entits

  • Trabelsi Walid

    24

    dun systme selon un point de vue temporel. Il possde une dimension temporelle mais ne

    reprsente pas explicitement les liens entre les objets. Il permet de visualiser les messages par

    une lecture de haut en bas. Un diagramme de squence possde deux axes : laxe vertical qui

    reprsente le temps, et laxe horizontal qui reprsente les objets qui se collaborent. Dans la partie

    qui suit, nous allons exposer quelques scnarios illustrant des cas dutilisation.

    1. DIAGRAMME DE SEQUENCES AUTHENTIFICATION

    Pour assurer la scurit, une opration dauthentification est obligatoire. Cette opration se

    dclenche une fois que lutilisateur aurait inscrit cette application. Un formulaire lui sera

    envoy, il le remplit en saisissant son login et son mot de passe fournis par ladministrateur, puis

    le systme vrifie la disponibilit des informations. Aprs une vrification et une validation, le

    systme autorise laccs et retourne la page daccueil destine lutilisateur.

    FIGURE 9 - DIAGRAMME DE SEQUENCES AUTHENTIFICATION

    authentification

    rfuser

    valider

    vrification

    saisir (login,mot de passe)

    email (login,mot de passe)

    Saisir profil

    Util isateur Inscription authentifcation

    rfuser

    valider

    vrification

    saisir (login,mot de passe)

    email (login,mot de passe)

    Saisir profil

  • Trabelsi Walid

    25

    2. DIAGRAMME DE SEQUENCES PLANNING DE JOUR

    Aprs la phase dauthentification, une page saffiche contenant un agenda recensant les

    vnements relatifs son utilisateur tout en lui donnant la possibilit de modifier et ajouter

    dautres annotations dans cet agenda .Cet agenda est utilis afin de pouvoir donner son

    utilisateur la possibilit de planifier, de noter son emploi du temps, ses rendez-vous.

    FIGURE 10 - DIAGRAMMES DE SEQUENCES PLANNING DU JOUR

    3. DIAGRAMME DES CAS DUTILISATION

    Le but de ces diagrammes et d'avoir une vision globale sur les interfaces du futur logiciel. Ces

    diagrammes sont constitus d'un ensemble d'acteurs qui agit sur des cas d'utilisation. Il permet

    d'identifier les possibilits d'interaction entre le systme et les acteurs (intervenants extrieurs au

    systme), c'est--dire toutes les fonctionnalits que doit fournir le systme. Il est prsent dans la

    Planning de jour

    Rfuser

    Requte

    Vrification(login,mot de passe)

    Confirmer

    Rsultats

    Connexion

    Modifier evenement

    Ajout evenement

    afficher planning

    Saisir(login,mot de passe)

    Restaurateur page authentification Base de donnesAgenda

    Rfuser

    Requte

    Vrification(login,mot de passe)

    Confirmer

    Rsultats

    Connexion

    Modifier evenement

    Ajout evenement

    afficher planning

    Saisir(login,mot de passe)

  • Trabelsi Walid

    26

    figure ci-dessous :

    FIGURE 11- DIAGRAMME DES CAS DUTILISATION

    2. LA MODELISATION STATIQUE :

    Aprs que nous avons prsent laspect dynamique de cette modlisation, nous allons aborder

    lautre aspect statique, avec lequel on peut identifier les proprits des objets et leurs liaisons

    avec les autres objets. L'un des diagrammes statiques nous intresse beaucoup pour pouvoir

    implmenter le code, il s'agit du diagramme de classes.

    A. DIAGRAMME DE CLASSE

    Le diagramme de classe est un lment important dans une dmarche de conception oriente

    gestion des contacts

    authentification

    suivie planning de

    jour

    fournisseurs

    clients

    gestion des reservation

    restaurateur

    gestion des tables

    gestion menu de jour

    Publier menu

    gestion profil

    inscription

    Supprimer evenement

    Consulter reservation

    Ajouter evenement

    Modifier table

    Ajouter table

    Modifier date

    modifier contactSupprimer contact

    Ajouter contact

    Modifier profil

    Supprimer table

    Ajouter une rservation

    Ajouter menu

    Modifier menu

    Supprimer menu

    Chercher contact

  • Trabelsi Walid

    27

    objet. Il reprsente les diffrentes entits (les classes d'objet) intervenant dans le systme.

    En identifiant les concepts importants de l'application, nous avons ralis un premier diagramme

    de classes pour reprsenter ces concepts et leurs associations.

    FIGURE 12 - DIAGRAMME DE CLASSE

    B. CONCEPTION DE LA BASE :

    Nous tenons souligner que la base de donnes conue est en troisime forme normale tout en

    veillant ce que lintgrit lors des ajouts et des suppressions de donnes soit maintenue dune

    1..1

    0..1

    1..1

    0..*

    0..1

    0..*

    1..1

    0..*

    0..1

    0..*

    1..1

    0..*

    1..1

    0..*

    Clie

    nt

    ------------

    Ide

    ntifia

    nt c

    lien

    t

    No

    m c

    lien

    t

    Pre

    no

    m c

    lien

    t

    Da

    te d

    e n

    aissa

    nce

    Eta

    t civ

    ile

    Lie

    u

    Pro

    fessio

    n

    Ad

    resse

    Nu

    m te

    lep

    ho

    ne

    Na

    tion

    alite

    Fu

    me

    ur

    Em

    ail

    : int

    : Strin

    g

    : Strin

    g

    : Da

    te

    : Strin

    g

    : Strin

    g

    : Strin

    g

    : Strin

    g

    : int

    : Strin

    g

    : int

    : Strin

    g

    ++++

    ajo

    ute

    r ()

    mo

    difie

    r ()

    sup

    prim

    er ()

    ch

    erc

    he

    r ()

    ...

    : vo

    id

    : vo

    id

    : vo

    id

    : Co

    nta

    ct

    Re

    serv

    atio

    n

    ----

    Nu

    m re

    serv

    atio

    n

    Typ

    e

    Da

    te fin

    Da

    te d

    eb

    ut

    : int

    : Strin

    g

    : Da

    te

    : Da

    te

    ++++

    co

    nfirm

    er ()

    an

    nu

    ler ()

    attrib

    ue

    r ()

    pa

    sser u

    ne

    rese

    rva

    tion

    ()

    ...

    : bo

    ole

    an

    : vo

    id

    : vo

    id

    : bo

    ole

    an

    Ta

    ble

    -----

    Nu

    me

    ro ta

    ble

    No

    mb

    re p

    erso

    nn

    e

    Co

    ule

    ur

    Disp

    on

    ible

    Se

    rvic

    e

    : int

    : int

    : Strin

    g

    : int

    : Strin

    g

    +++

    ajo

    ute

    r ()

    attrib

    ue

    r ()

    mo

    difie

    r ()

    ...

    : vo

    id

    : vo

    id

    : vo

    id

    Co

    nta

    ct

    -----------------------

    Id c

    on

    tact

    Civ

    ilit

    Pre

    no

    m

    Mo

    bile

    1

    Mo

    bile

    2

    T

    l. do

    mic

    ile

    Gro

    up

    e

    Em

    ail

    Ville

    Co

    de

    po

    stal

    Pa

    ys

    No

    m e

    ntre

    prise

    Fo

    nctio

    n

    Em

    ail p

    rof

    Mo

    bile

    1 p

    rof

    Mo

    bile

    2 p

    rof

    Fa

    x p

    rof

    Ad

    resse

    en

    trep

    rise 1

    Ad

    resse

    en

    trep

    rise 2

    Ville

    en

    trep

    rise

    Co

    de

    po

    stal e

    ntre

    prise

    Pa

    ys e

    ntre

    prise

    Div

    ers

    : int

    : int

    : Strin

    g

    : int

    : int

    : int

    : Strin

    g

    : Strin

    g

    : Strin

    g

    : int

    : Strin

    g

    : Strin

    g

    : Strin

    g

    : Strin

    g

    : int

    : int

    : int

    : Strin

    g

    : Strin

    g

    : Strin

    g

    : int

    : Strin

    g

    : Strin

    g

    ++++

    ajo

    ute

    r ()

    mo

    difie

    r ()

    sup

    prim

    er ()

    ch

    erc

    he

    r ()

    ...

    : vo

    id

    : vo

    id

    : vo

    id

    : Co

    nta

    ct

    Me

    nu

    de

    jou

    r

    ------

    Re

    fere

    nce

    me

    nu

    Titre

    Lib

    elle

    Da

    te

    Prix

    Offre

    et sp

    ecia

    l

    : int

    : Strin

    g

    : Strin

    g

    : Da

    te

    : floa

    t

    : Strin

    g

    +++

    ajo

    ute

    r ()

    mo

    difie

    r ()

    sup

    prim

    er ()

    ...

    : vo

    id

    : vo

    id

    : vo

    id

    Pro

    fil

    ---------------

    Id u

    tilisate

    ur

    No

    m

    Pre

    no

    m

    Da

    te d

    e n

    aissa

    nce

    Lie

    u d

    e n

    aissa

    nce

    Activ

    ite

    Ad

    resse

    pe

    rson

    ne

    lle

    Ad

    resse

    pro

    fessio

    nn

    elle

    Em

    ail

    Ville

    Co

    de

    po

    stal

    Pa

    ys

    Nu

    m te

    l

    Co

    de

    pa

    rten

    aire

    No

    m e

    ntre

    prise

    : int

    : Strin

    g

    : Strin

    g

    : Da

    te

    : Strin

    g

    : Strin

    g

    : Strin

    g

    : Strin

    g

    : Strin

    g

    : Strin

    g

    : int

    : Strin

    g

    : int

    : int

    : Strin

    g

    +m

    od

    ifier ()

    ...

    : vo

    id

    Fo

    urn

    isseu

    r

    ------

    Id fo

    urn

    isseu

    r

    No

    m

    Ma

    tricu

    le fisc

    ale

    Ad

    resse

    Nu

    m t

    lp

    ho

    ne

    Em

    ail

    : int

    : Strin

    g

    : Strin

    g

    : Strin

    g

    : int

    : Strin

    g

    ++++

    ajo

    ute

    r ()

    sup

    prim

    er ()

    mo

    difie

    r ()

    ch

    erc

    he

    r ()

    ...

    : vo

    id

    : vo

    id

    : vo

    id

    : vo

    id

    Co

    mp

    te

    -----

    Lo

    gin

    Mo

    t de

    pa

    sse

    Priv

    ileg

    e

    Eta

    t

    Da

    te m

    ise jo

    ur

    : Strin

    g

    : Strin

    g

    : int

    : int

    : Da

    te

    ++

    insc

    rire ()

    mo

    difie

    r ()

    ...

    : vo

    id

    : vo

    id

  • Trabelsi Walid

    28

    manire transparente travers un schma de mapping qui permet d'assurer la transformation

    d'objets vers la base de donnes et vice versa que cela soit pour des lectures ou des mises jour

    (cration, modification ou suppression).

    Concernant les cas dhritages, nous avons opt pour un hritage par spcialisation. Nous avons

    galement choisi de gnrer la classe gnrique et la classe spcifique sachant que dans cette

    dernire, seuls les attributs spcifiques figurent.

    Dailleurs, cette dcision est justifie par un fini doptimisation, de sorte que la migration des

    proprits communes ny a pas lieu, bien sr exception faite de la clef primaire. A cette dernire

    correspond une optimisation en espace de stockage par limination de toute forme de redondance

    dattributs.

    Ainsi, le lien interclasses (gnrique et spcifique) est gr laide dune jointure sur la cl

    primaire .Du coups, nous avons veill ce que lintgrit lors des ajouts et des suppressions soit

    maintenue.

    CONCLUSION

    Lobjet de ce chapitre tait laboutissement la conception de la base de donnes. Pour ce faire,

    nous avons d passer par des transformations des modles et des structurations du systme, tout

    en tenant adquatement compte des contraintes techniques existantes pour limplmentation du

    futur systme qui fera lobjet du chapitre suivant.

  • Trabelsi Walid

    29

    CHAPITRE 3 : DEVELOPPEMENT

    INTRODUCTION

    Limplmentation est le rsultat de la conception, son importance est crucial pour le traitement

    S'il ne fallait retenir qu'une vertu des

    Technologies de l'Information et de la

    Communication ce serait celle-ci : la

    possibilit d'offrir chacun une tribune,

    un espace de libert, d'expression.

    Andr Santini

  • Trabelsi Walid

    30

    du systme sous forme de composants pour chaque cas dutilisation, et traduire les mthodes et

    les objets de cette application en des classes et de code source.

    I. ENVIRONNEMENT DE DEVELOPPEMENT :

    Il existe un panorama de technologie et de nombreuses solutions techniques pour mettre en

    uvre une application web dynamique dont voici quelques-unes auxquelles nous avons

    notamment eu recours.

    1. SGBD: MYSQL

    MySQL est un serveur de bases de donnes relationnelles SQL dvelopp dans un souci de

    performances leves en lecture, ce qui signifie qu'il est davantage orient vers le service de

    donnes dj en place que vers celui des mises jour frquentes et fortement scurises. Il est

    multithread et multi-utilisateur.

    C'est un logiciel libre dvelopp sous double licence en fonction de l'utilisation qui en est faite:

    dans un produit libre ou dans un produit propritaire. Dans ce dernier cas, la licence est payante,

    sinon c'est la licence publique gnrale GNU (GPL) qui s'applique.

    2. EDI: NETBEANS

    NetBeans est un environnement de dveloppement intgr (EDI), plac en open source par Sun

    en juin 2000 sous licence CDDL et GPLv2 (Common Development and Distribution License).

    En plus de Java, NetBeans permet galement de supporter diffrents autres langages, comme

    Python, C, C++, JavaScript, XML, Ruby, PHP et HTML. Il comprend toutes les caractristiques

    d'un IDE moderne (diteur en couleur, projets multi-langage, refactoring, diteur graphique

    d'interfaces et de pages Web).

    Conu en Java, NetBeans constitue par ailleurs une plateforme qui permet le dveloppement des

    applications web, il comprend toutes les caractristiques d'un IDE moderne (coloration

    syntaxique, projets multi-langage, refactoring, diteur graphique d'interfaces et de pages web,

    etc.).

    3. LE SERVEUR DAPPLICATION J2EE : GLASSFISH

    GlassFish est le nom du serveur d'applications Open Source Java EE 5 et qui sert de fondation au

  • Trabelsi Walid

    31

    produit Sun Java System Application Server de Sun Microsystems. Sa partie Toplink persistance

    provient d'Oracle. C'est la rponse aux dveloppeurs Java dsireux d'accder aux sources et de

    contribuer au dveloppement des serveurs d'applications de nouvelle gnration de Sun.

    II. LANGAGE & FRAMEWORK

    1. Framework JSF

    JavaServer Faces (abrg en JSF) est un framework Java bas sur la notion de composants et

    destin au dveloppement d'applications Web. JSF est techniquement comparable Swing ou

    SWT sauf qu'ils sont utiliss pour le dveloppement d'application bureau, en JSF et en Swing

    l'tat d'un composant (reprsent par un objet java) est enregistr lors du rendu de la page, pour

    tre ensuite restaur au retour de la requte.

    Une page JSF est une page xhtml (ou jsp) lie aux Managed Bean via le language EL.

    JSF est principalement constitu de :

    Un ensemble d'APIs pour la reprsentation et la gestion des composants, de leur tat, des

    vnements, de la validation des entres et la conversion des sorties, l'internationalisation

    et l'accessibilit ainsi que la navigation inter-vues.

    Deux jeux de composants standards (affichage de texte, saisie de texte, tables, zone

    cocher, etc.): html et core.

    Deux bibliothques de balises JSP (une pour chaque jeu de composants) pour permettre

    l'utilisation de JSP pour la construction de vues JSF.

    Un modle vnementiel ct serveur.

    Les Managed-Beans : qui forment la couche contrle de JSF.

    Unified Expression Language: abrg en EL ou langage d'expressions unifi pour JSF et

    JSP 2.0. Il permet de lier les composants aux managed-beans.

    L'objectif de JSF est de faciliter le dveloppement des interfaces utilisateurs des applications

    web, or les deux de composants standards de JSF (html et core) s'avrent limits et insuffisants

    pour le dveloppement d'applications d'entreprise. Des jeux de composants additionnels qui

    offrent de nouveaux composants plus riches sont indispensables pour le dveloppement en JSF,

    Primefaces en offre un qui a prouv son efficacit.

  • Trabelsi Walid

    32

    C. JUSTIFICATION DE CHOIX DE LA LANGAGE DE PROGRAMMTION

    JSF permet au dveloppeur d'accrotre la productivit du dveloppement d'interfaces client

    lger tout en permettant une maintenance assez facile. JSF est un standard J2EE. JSF permet

    une sparation entre la couche prsentation et les autres couches d'une application web une mise

    en place d'un mapping HTML/OBJET

    la rutilisation de composants graphiques

    une gestion de l'tat de l'interface entre les diffrentes requtes

    une liaison entre les actions cot Client et les actions des objets Java cot Serveur

    cration de composants customs grce une API

    le support de diffrents clients (HTML, WML, XML, ...) grce la sparation des

    problmatiques de construction de l'interface et du rendu de cette interface

    2. API JPA 2.0 ECLIPSELINK

    EclipseLink est un Framework open source de mapping objet-relationnel pour les dveloppeurs

    Java. Il fournit une plateforme puissante et flexible permettant de stocker des objets Java dans

    une base de donnes relationnelle et/ou de les convertir en documents XML. EclipseLink est

    driv du projet TopLink de la socit Oracle. Il supporte un certain nombre d'API relatives la

    persistance des donnes et notamment la JPA.

    3. API DE LOGGING : LOG4J

    Log4j est un projet open source distribu sous la licence Apache Software initialement cr par

    CekiGlc et maintenu par le groupe Jakarta. Cette API permet aux dveloppeurs d'utiliser et de

    paramtrer un systme de gestion de journaux (logs). Il est possible de fournir les paramtres

    dans un fichier de configuration ce qui rend sa configuration facile et souple. Log4j est

    compatible avec le JDK 1.1. et suprieur.

    4. PRIMEFACES

    PrimeFaces est un framework open source, qui peut tre assimil une suite de composants

    d'interfaces riches pour JSF.

    JSF apporte des lments trs basiques d'UI par contre PrimeFaces va plus loin

    et propose plus de 100 composants, plus de 35 thmes, des composants

    mobiles et bien plus encore.

  • Trabelsi Walid

    33

    C'est actuellement de loin la suite pour JSF la plus populaire, ainsi qu'un outil graphique trs

    populaire partout pour le dveloppement de Java Web.

    Ces bibliothques complmentaires :

    PrettyFaces

    OmniFaces (bibliothque utilitaire pour JSF)

    PrimeFaces Extensions

    FIGURE 13- ARCHITECTURE D'UNE PAGE PRIMEFACES

    II. ERGONOMIE ET CONCEPTION DES INTERFACES

    GRAPHIQUES

    La conception dun interface utilisateur doit prendre en compte les besoins du restaurateur et

    rpondre aux exigences ergonomiques standards pour les applications web :

    Organisation visuelle :cest la manire dont votre site est construit : il faut avoir une

    cohrence et clart dans la mise en page et pouvoir identifier en un clin d'oeil les

    diffrents pavs ou blocs qui constituent cette application et leurs fonctionnalits

    Cohrence :cest avoir un espace bien organis et stable qui soit homogne tout au long

    de la visite de lutilisateur.

    Lassistance : cest guider les utilisateurs selon leurs besoins et leur attentes un

  • Trabelsi Walid

    34

    moment prcis.

    III. QUELQUES INTERFACES DE CETTE APPLICATION

    FIGURE 14 - LA PAGE D'INSCRIPTION

    Chaque nouvel utilisateur est appel s'inscrire dans cette application en remplissant ce

    formulaire, aprs la validation de son inscription il recevra un email qui contiendra les

    paramtres de son compte (login , mot de passe).

  • Trabelsi Walid

    35

    FIGURE 15 - PAGE AUTHENTIFICATION

    Cest la premire page qui saffiche lutilisateur, elle lui offre la possibilit de sauthentifier en

    saisissant son login et mot de passe obtenu par son inscription.

    FIGURE 16- AGENDA DES EVENEMENTS

  • Trabelsi Walid

    36

    Par le biais de cet agenda il est possible de suivre les vnements : les Rendez-vous, les

    rservations et les notes importantes associes son utilisateur en temps rel. Comme il est

    possible de changer les dates des vnements en dplaant quelques cartes de notes sur cet

    agenda.

    FIGURE 17 - PAGE AJOUTER UNE NOTE

    Parmi les fonctionnalits offertes par notre application, nous citons lajout des notes avec une

    description et une priode de temps bien dtermine selon les besoins de lutilisateur.

  • Trabelsi Walid

    37

    FIGURE 18 - PAGE LISTE DES TABLES

    Cette interface permet lutilisateur de consulter lensemble de ces tables ainsi que leurs tats de

    disponibilit.

    FIGURE 19 - PAGE AJOUTER UNE TABLE

    Il est possible dajouter une nouvelle table identifie par un numro unique ou de modifier ses

    donnes.

  • Trabelsi Walid

    38

    FIGURE 20- PAGES SUIVIE DES RESERVATIONS

    On peut suivre avec ce tableau toutes les rservations relatives chaque table, classes selon le

    nombre de places disponibles.

    FIGURE 21 - AJOUTER RESERVATION

    On peut rserver une table, une priode bien donne, pour un client avec des dtails sur cette

    rservation.

  • Trabelsi Walid

    39

    FIGURE 22 UNE PAGE POUR SUIVRE LA LISTE DE CONTACTS CLIENTELE

    FIGURE 23UNE INTERFACE POUR AJOUTER UN NOUVEAU CLIENT

    On peut ajouter, via cette page, un nouveau client en fournissant ses diffrents dtails :

    identifiant, nom, prnom

  • Trabelsi Walid

    40

    FIGURE 24LA PAGE DINFO. CLIENT

    Il est possible de suivre, travers cette interface, les diffrents dtails de chaque client part.

    CONCLUSION

    Dans ce chapitre, nous avons labor une tude prliminaire sur larchitecture logicielle et

    physique de notre application tout en se focalisant sur la description de lenvironnement matriel

    et logiciel qui nous a permis dimplmenter notre application.

  • Trabelsi Walid

    41

    CONCLUSION GENERAL

    Au terme de ce rapport, nous pouvons dduire que ce projet de fin dtudes nous a constitu une

    occasion opportune ; Il nous a permis de confronter lacquis thorique lenvironnement

    pratique et nous a mens une recherche sur le plan scientifique. Cest l o notre avis, rside

    la valeur dun tel projet de fin dtudes qui illustre les exigences de la vie professionnelle au ct

    bnfique de lenseignement pratique que nous avons eu LUVT.

    Durant ce projet, nous tions chargs pour la conception et la ralisation dune solution de

    gestion des donnes pour restaurateurs. Comme nous venons de le voir, la mise en place de cette

    application nest pas forcment complexe, mais, elle exige tout de mme quon suit une

    dmarche structure et rigoureuse.

    De ce fait, un travail considrable de recherche sur Internet, une tude minutieuse sur les outils

    de travail et une analyse de lenvironnement o fonctionne notre application, ont t faits afin

    de dgager les diffrents besoins et exigences du public cible et de choisir larchitecture

    informatique la mieux adapte au systme.

    Ainsi, nous sommes passs limplmentation de notre application, ce stade, nous avons

    prouv de grands efforts pour entamer la ralisation dans un dlai plus proche afin de passer

    ltape de validation. Cette validation doit tre interactive et fluide afin de garantir aussi bien la

    facilit dutilisation que lutilit dutilisation.

    Pour conclure, nous confirmons que notre projet nous a permis dune part de mobiliser

    nos diffrentes facults de comprhension et dintelligence, et dautre part de savoir quoi, o

    et quand chercher linformation souhaite. En effet, notre projet qui est polyvalent nous a

    pousss explorer divers domaines qui semblent divergents, mais qui trouvent dans notre

    cas de figure un meilleur champ de convergence. Cette exploration tait structure et

    organise de faon prserver le bon enchanement des travaux.

  • Trabelsi Walid

    42

    GLOSSAIRE

    A

    API: Application Programming Interface

    C

    CGI : Common Gateway Interface

    D

    DAO : Data Access Object

    E

    EJB : Entreprise Java Bean

    EDI: environnement de dveloppement intgr

    H

    Html: Hypertext Markup Language

    J

    JDK : Java Developpement Kit

    J2EE : Java 2 Entreprise Edition

    JSP : Java Server Page

    JVM : Javavirtual Machine

    JPA: Java Persistence API

    JSF : Java Server Faces

  • Trabelsi Walid

    43

    L

    LMD : langage de manipulation de donnes

    M

    MVC : modle-vue-contrleur

    MCT : Modle conceptuel des traitements

    O

    ODBC : Open Database Connectivity

    ORM : Object-relational mapping

    R

    Row : enregistrement

    S

    SGBD : systme de gestion de base de donnes

    SQL : Structured Query Language

    U

    UML : Unified Modeling Language

    UP : Unified Process

    URL : Uniform Resource Locator

    X

    XHTML : Extensible HyperText Markup Language

  • Trabelsi Walid

    44

    BIBLIOGRAPHIE

    Penser en Java par Bruce Eckel.

    Programmer en Java par Claude Delannoy Editions Eyrolles.

    Des articles du site que tous les dveloppeurs dapplications connaissent :

    Developpez.com.

    Java EE 5 :EJB 3.0 - JPA - JSP - JSF - Web services - JMS - GlassFish 3 - Maven 3 de

    Antonio Goncalves

    JSF 2.0 Cook book de Anghel Leonard.

    Java Efficace Guide de Programmation de Joshua Bloch ,dition : Vuibert.

    Bien programmer en Java 7 : Auteur(s) : Emmanuel Puybaret , Editeur(s) : Eyrolles

    Collection : Blanche.

    Programmation Orient Aspect pour Java / J2EEde R.Pawlak, J.Ph.Retaill et

    L.Seinturier dition : Eyrolles.

  • Trabelsi Walid

    45

    NETOGRAPHIE

    http://www.java.com/fr/

    http://www.mysql.fr/

    http://glassfish-samples.java.net/

    http://jawher.net/i-wrote/creation-dune-application-de-type-crud-avec-jsf-et-jpa/

    http://www.tutorialspoint.com/log4j/log4j_quick_guide.htm

    http://fr.wikipedia.org/

    http://java.developpez.com/

    http://codes-sources.commentcamarche.net/s/java

    http://www.oracle.com/fr/technologies/java/overview/index.html

    http://www.pourlesnuls.fr/

    http://fr.openclassrooms.com/informatique/cours/apprenez-a-programmer-en-java

    http://www.java.com/fr/http://www.mysql.fr/http://glassfish-samples.java.net/http://jawher.net/i-wrote/creation-dune-application-de-type-crud-avec-jsf-et-jpa/http://www.tutorialspoint.com/log4j/log4j_quick_guide.htmhttp://fr.wikipedia.org/http://java.developpez.com/http://codes-sources.commentcamarche.net/s/javahttp://www.oracle.com/fr/technologies/java/overview/index.htmlhttp://www.pourlesnuls.fr/http://fr.openclassrooms.com/informatique/cours/apprenez-a-programmer-en-java

  • Trabelsi Walid

    46

    ANNEXE

    JEE : Java Enterprise Edition, ou Java EE (anciennement J2EE), est une spcification pour la

    technique Java de Sun plus particulirement destine aux applications dentreprise. Ces

    applications sont considres dans une approche multi-niveaux1. Dans ce but, toute

    implmentation de cette spcification contient un ensemble dextensions au framework Java

    standard (JSE, Java Standard Edition) afin de faciliter la cration dapplications rparties.

    Pour ce faire, Java EE dfinit les lments suivants :

    Une plate-forme (Java EE Platform), pour hberger et excuter les applications.

    Une suite de tests (Java EE Compatibility Test Suite) pour vrifier la compatibilit.

    Une ralisation de rfrence (Java EE Reference Implementation), qui est GlassFish.

    Un catalogue de bonnes pratiques (Java EE BluePrints).

    UP Le processus unifi est un processus de dveloppement logiciel itratif, centr sur

    l'architecture, pilot par des cas d'utilisation et orient vers la diminution des risques. C'est un

    patron de processus pouvant tre adapte une large classe de systmes logiciels, diffrents

    domaines d'application, diffrents types d'entreprises, diffrents niveaux de comptences et

    diffrentes tailles de l'entreprise. Le document suivant prsente sous la forme d'une note les

    concepts associs ce processus.

    FIGURE 25 - LES PROCESSUS DE DEVELOPPEMENT D'UN LOGICIEL SELON UP

  • Trabelsi Walid

    47

    Le Kanban (kb) est un mode de gestion de flux cr par lindustrie automobile Japonaise

    (Toyota). Kanban signifie "tiquette", et comme cest une mthode asiatique, elle implique deux

    principes:

    - une trs forte connotation visuelle,

    - une recherche de la perfection au moindre cot (Cest un outil des principes PULL ).

    Rappelons tout dabord que le stock est ncessaire pour faire face lirrgularit de la demande,

    mme si la mthode PULL est appele "Mthode zro stock".

    Les tiquettes sont donc le vecteur dinformations et sont ranges sur les emballages et un

    tableau rcapitulatif .

    Lorsque le tableau est vide, ceci signifie que toutes les tiquettes sont accroches aux

    emballages. Le stock est alors son znith.

    Au fur et mesure de la consommation des emballages, les tiquettes reviennent et sont remises

    dans le tableau en commenant toujours par le mme sens et atteignent des zones de couleurs

    diffrentes (Vert, Orange et Rouge, comme pour la circulation, plus le nombre dtiquettes

    atteint le rouge, plus il y a urgence).

    Il est recommand de ne pas toucher la zone orange ni rouge car cela signifie quil ne reste que

    peu demballages entre le fournisseur et son client.

    FIGURE 26UN TABLEAU KANBAN

  • Trabelsi Walid

    48

    UML (sigle dsignant l'Unified Modeling Language ou langage de modlisation unifi ) est

    un langage de modlisation graphique base de pictogrammes. Il est apparu dans le monde du

    gnie logiciel, dans le cadre de la conception oriente objet . UML est couramment utilis

    dans les projets logiciels. UML est l'accomplissement de la fusion de prcdents langages de

    modlisation objet : Booch, OMT, OOSE. Principalement issu des travaux de GradyBooch,

    James Rumbaugh et Ivar Jacobson, UML est prsent un standard dfini par l'Object

    Management Group (OMG). La dernire version diffuse par l'OMG est UML 2.4.1 depuis aot

    20111.

    Le Java Development Kit (JDK) dsigne un ensemble de bibliothques logicielles de base du

    langage de programmation Java, ainsi que l'environnement dans lequel le code Java est compil

    pour tre transform en bytecode afin que la machine virtuelle Java (JVM) puisse l'interprter.

    Il existe en ralit plusieurs JDK, selon la plate-forme Java1 considre (et bien videmment la

    version de Java cible) :

    JSE pour la Java 2 Standard Edition galement dsigne J2SE ;

    JEE, sigle de Java Enterprise Edition galement dsigne J2EE ;

    JME 'Micro Edition', destine au march mobiles ;

    chacune de ces plateformes correspond une base commune de Development Kits, plus des

    bibliothques additionnelles spcifiques selon la plate-forme Java que le JDK cible, mais le

    terme de JDK est appliqu indistinctement n'importe laquelle de ces plates-formes.

    La Java Persistence API (abrge en JPA), est une interface de programmation Java permettant

    aux dveloppeurs d'organiser des donnes relationnelles dans des applications utilisant la

    plateforme Java.La Java Persistence API est l'origine issue du travail du groupe d'experts JSR

    220.La persistance dans ce contexte recouvre 3 zones :l'API elle-mme, dfinie dans le

    paquetage javax.persistence le langage Java Persistence,Query (JPQL),l'objet/les mtadonnes

    relationnelles

    JavaBeans est une technologie de composants logiciels crits en langage Java. La spcification

    JavaBeans de Sun Microsystems dfinit les composants de type JavaBeans comme des

    composants logiciels rutilisables manipulables visuellement dans un outil de conception .Ils

  • Trabelsi Walid

    49

    sont utiliss pour encapsuler plusieurs objets dans un seul objet (= le bean ou haricot en

    franais). Le bean regroupe alors tous les attributs des objets encapsuls, et peut dfinir

    d'autres attributs si besoin. Ainsi, il reprsente une entit plus globale que les objets encapsuls

    de manire rpondre un besoin mtier. En dpit de quelques similarits, les JavaBeans ne

    doivent pas tre confondus avec les Entreprise JavaBeans (EJB), une technologie de composants

    ct serveur faisant partie de J2EE (Java2 Entreprise dition).

    JPA :

    Littralement Java Persistence API , il sagit dun standard faisant partie intgrante de la

    plate-forme Java EE, une spcification qui dfinit un ensemble de rgles permettant la gestion de

    la correspondance entre des objets Java et une base de donnes, ou autrement formul la gestion

    de la persistance.

    Ce mcanisme qui gre la correspondance entre des objets dune application et les tables dune

    base de donnes se nomme ORM, pour Object Relational Mapping . Ainsi dans le sens le plus

    simpliste du terme, ce que nous avons ralis dans les chapitres prcdents travers nos DAO

    nest rien dautre quun ORM manuel !

    Persistance de donnes :

    Au sens gnral, il sagit simplement du terme utilis pour dcrire le fait de stocker des donnes

    dune application de manire persistante ! Autrement dit, de les sauvegarder afin quelles ne

    disparaissent pas lorsque le programme se termine. Rien de bien compliqu, en somme.

    En Java, lorsquon parle dune solution de persistance des donnes , on voque couramment

    un systme permettant la sauvegarde des donnes contenues dans des objets. En ralit, vous

    connaissez donc dj tous un moyen de persistance : le stockage dans une base de donnes

    relationnelle via JDBC !

    Configuration de JSF :

    Cette configuration revient :

    Ajouter une implmentation JSF au classpath . Dans lexemple fourni avec cet article,

    Jutilise la Sun Reference Implementation 1.2.6 tlchargeable ici . Cette version

    supporte JSF 1.2.

  • Trabelsi Walid

    50

    Dclarer la Faces Servlet dans web.xml et lassocier *.jsf . Cette servlet joue le rle de

    la Front Servlet du MVC/Model 2 .

    Ajouter le fichier faces-config.xml qui permet de configurer lapplication JSF

    (dclaration des managed-beans / controllers , dclaration des rgles de navigation, etc.)

    Aprs avoir dclar la Faces Servlet ainsi que son affectation aux urls de type *.jsf , voici ce que

    devient web.xml:

    jsf-crud

    index.jsp

    Faces Servlet

    javax.faces.webapp.FacesServlet

    1

    Faces Servlet

    *.jsf

    Et voici le fichier faces-config.xml (vide pour linstant, mais il sera mis jour au fur et mesure

    de lajout de nouvelles fonctionnalits lapplication):

    http://www.w3.org/2001/XMLSchema-instancehttp://java.sun.com/xml/ns/javaeehttp://java.sun.com/xml/ns/javaee/web-app_2_5.xsdhttp://java.sun.com/xml/ns/javaeehttp://java.sun.com/xml/ns/javaee

  • Trabelsi Walid

    51

    Configuration de JPA

    La configuration de JPA consiste :

    Ajouter une implmentation JPA au classpath. Jutilise Toplink 2.41 comme implmentation.

    Crer le descripteur de persistance qui sert spcifier les paramtres de connexion la base de

    donnes (url de connexion, login, mot de passe, etc.) ainsi qu la dclaration des classes

    persistantes.

    Jutilise Toplink comme implmentation JPA et HSQLDB comme base de donnes. Il faut donc

    mettre toplink.jar et hsqldb.jar dans le classpath de lapplication.

    Il faut ensuite crer un descripteur de persistance JPA (persistence.xml) dans un dossier META-

    INF la racine du dossier source.

    Ce fichier ne contient que le nom de lunit de persistance ( jsf-crud ) ainsi que les paramtres de

    connexion la base de donnes qui sont:

    PiloteJDBC : com.mysql.jdbcDriver

    URL de connexion: jdbc:mysql:file:test qui indique MYSQL de stocker la base de donnes

    dans un fichier nomm test . Il est aussi possible de stocker la base dans la mmoire vive (

  • Trabelsi Walid

    52

    RAM ) en utilisant un chemin du type jdbc:mysql:mem:test . Mais les donnes seraient alors

    perdues larrt de lapplication.

    Login: sa (lquivalent du root dans MYSQL )

    PiloteJDBC : com.mysql.jdbcDriver

    toplink.ddl-generation : create-tables indique Toplink de crer les tables si elles nexistent

    pas.

    Couche mtier DAO

    Un objet d'accs aux donnes (en Anglais Data Access Object ou DAO) est un patron de

    conception (c'est--dire un modle pour concevoir une solution) utilis dans les architectures

    logicielles objet. la partie Model de lapplication devrait tre spare en deux sous parties: DAO

    ( Data Access Object ) pour laccs aux donnes et Service pour faire la logique mtier. Mais

    dans le cadre de cet article, on se limitera la couche DAO sans passer par la couche service vu

    que lon na pas de logique mtier proprement parler.

  • Trabelsi Walid

    53

    FIGURE 27 COUCHE DACCES AUX DONNEES

  • Trabelsi Walid

    54

    package model.dto;

    import javax.persistence.Entity;

    import javax.persistence.GeneratedValue;

    import javax.persistence.Id;

    @Entity

    public class Person {

    private Long id;

    private String firstName;

    private String lastName;

    @Id

    @GeneratedValue

    public Long getId() {

    return id;

    }

    public void setId(Long id) {

    this.id = id;

    }

    public String getFirstName() {

    return firstName;

    }

    public void setFirstName(String firstName) {

    this.firstName = firstName;

    }

    public String getLastName() {

    return lastName;

    }

    public void setLastName(String lastName) {

    this.lastName = lastName;

    }

    }

    Cette classe est annote avec JPA pour pouvoir tre persiste ou retrouv dans la base de

    donnes:

    Lannotation @Entity sur la classe Person pour la dclarer comme classe persistante.

    Cette annotation est obligatoire pour une classe persistante.

    Lannotation @Id sur le getter du champ id pour le dclarer comme lidentifiant. Cette

  • Trabelsi Walid

    55

    annotation est obligatoire pour une classe persistante.

    Lannotation @GeneratedValue sur le getter du champ id pour dclarer qua sa valeur est

    auto gnre.

    Encapsuler les oprations de persistance (cration, modification, suppression et lecture) sur

    lentit Person dans un DAO

    package model.dao;

    import java.util.List;

    import javax.persistence.EntityManager;

    import javax.persistence.Persistence;

    import model.dto.Person;

    public class PersonDao {

    private static final String JPA_UNIT_NAME = "jsf-crud";

    private EntityManagerentityManager;

    protected EntityManagergetEntityManager() {

    if (entityManager == null) {

    entityManager = Persistence.createEntityManagerFactory(

    JPA_UNIT_NAME).createEntityManager();

    }

    return entityManager;

    }

    }

    Le DAO quon va dvelopper va utiliser lAPI de JPA pour raliser les oprations de persistance.

    Pour pouvoir lutiliser, il faut dabord crer une instance de la classe EntityManager . Pour le

    faire, on passe par une fabrique ( Factory ) quon rcupre via la mthode statique

    Persistence.createEntityManagerFactory() (Je sais, encore une autre fabrique :) ) en lui passant

    comme paramtre le nom de lunit de persistance (le mme dclar dans persistence.xml ):

    Log4j est une API de journalisation trs rpandue dans le monde Java. Il s'agit d'un systme

    hautement configurable, que ce soit au niveau de ce qui doit tre enregistr ou de la destination

    des enregistrements (serveur de logging, fichiers tournants, etc.). Pour cet article, je me suis

    appuy sur la version 1.2.11, la version 1.3 devrait voir le jour en octobre 2005, elle introduit

  • Trabelsi Walid

    56

    certains changements au niveau de l'API ; nanmoins, les recommandations concernant la

    compatibilit avec la future API ont t appliques.

    Cette API est frquemment utilise comme systme de journalisation sous-jacent en combinaison

    avec des autres API

    Logger comme son nom l'indique, le Logger est l'entit de base pour effectuer la journalisation,

    il est mis en uvre par le biais de la classe org.apache.log4j.Logger. L'obtention d'une instance

    de Logger se fait en appelant la mthode statique Logger. getLogger: Il est possible de donner un

    nom arbitraire au Logger, cependant, comme nous le verrons lorsque nous parlerons des

    hirarchies de Loggers et de la configuration, il est prfrable d'utiliser le nom de la classe pour

    des raisons de facilit.

    FIGURE 28 - LES COMPOSANT DE FRAMEWORK LOG4J

  • Trabelsi Walid

    57

    RESUME

    Ce projet consiste concevoir et dvelopper une application web darchitecture applicative

    3-tiers pour la gestion des donnes restaurateurs : les contacts, les rservations, les rendez-vous,

    les tables, les notes, les activits planifies avec un agenda lectronique simple et facile

    manipuler, les tableaux pour la suivi des contacts avec les fournisseurs ou les clients ainsi que

    leurs rservations. Ce travail est ralis laide du langage de programmation jsf , en interaction

    avec lAPI JPA selon le modle MVC.

    Mots cls : Kanban , Agenda , Contact , JSF , J2EE , JPA , MYSQL

    : 3 ,

    .

    . MVC API JPA JSF

    JSF, JPA J2EE.MYSQL Kanban :

    ABSTRACT

    Our project can be summarized in designing and developing a web application that matches with

    the Three-tier management architecture, which is dedicated to the restoration of data such as

    booking, appointments, tables, notes. These data types would be planned with a simple electronic

    diary and activities that are easy to handle and track contacts such as suppliers or customers who

    are booking.

    Key words: Kanban , J2EE, JSF, MYSQL, JPA, MVC.