Développement d’une application de gestion des licences des contrôleurs aériens

  • Published on
    09-Jan-2017

  • View
    26

  • Download
    3

Transcript

  • Rapport de stage ingnieur

    Spcialit : Tlcommunications

    Elabor par :

    CHAIEB Ghassene

    Dveloppement dune application de gestion

    des licences des contrleurs ariens

    Lieur de stage : Direction de Navigation arienne

    Priode de stage : 1 aot 2015 - 30 aot 2015

    Encadrant : Sofiene Slama

    Anne universitaire : 2015/201

  • Ecole Nationale dIngnieurs de Tunis Stage ingnieur

    2

    Cest avec le plus grand honneur que jai rserv louverture de mon rapport en signe de gratitude et de reconnaissance lgard de tous ceux qui mont aid, de prs ou de loin, la ralisation de ce

    stage.

    Je tiens adresser mes vifs remerciements mon encadrant Mr. Sofiene Slama (Chef de la

    Division Dveloppement et Futurs Systmes de la direction de navigation arienne) pour sa

    prsence, son encadrement, ses conseils fournis de faon efficace Tout au long de la priode de

    ralisation.

    Je veux aussi exprimer mes remerciements sincres Mr. Fredj Chaieb (Chef service commercial

    GAMMA informatique) qui ma soutenu et aid progresser dans mon stage.

    Mes remerciements sadressent galement aux membres du Jury qui nous font l'honneur de participer

    ma soutenance.

  • Ecole Nationale dIngnieurs de Tunis Stage ingnieur

    3

    Introduction gnrale ................................................................................................................... 7

    Chapitre 1 Cadre du projet ............................................................................................................ 8

    1.1 Introduction ........................................................................................................................9

    1.2 Prsentation de la socit ...................................................................................................9

    1.3 Description du projet ..........................................................................................................9

    1.3.1 Mise en situation .................................................................................................................... 9

    1.3.2 Objectifs de lapplication ...................................................................................................... 10

    1.4 Mthodologie et formalismes adopts ............................................................................ 10

    1.5 Conclusion ........................................................................................................................ 11

    Chapitre 2 Analyse et spcification des besoins ........................................................................... 12

    2.1 Introduction ..................................................................................................................... 13

    2.2 Analyse globale de lapplication ....................................................................................... 13

    2.2.1 Description des acteurs ........................................................................................................ 13

    2.2.2 Spcification des besoins fonctionnels :............................................................................... 13

    2.2.3 Spcification des besoins non fonctionnels ......................................................................... 14

    2.3 Diagramme de cas dutilisation ........................................................................................ 14

    2.3.1 Diagramme de cas dutilisation : Gnrale .......................................................................... 14

    2.3.2 Raffinement des cas dutilisation ......................................................................................... 16

    2.3.2.1 Raffinement du cas dutilisation Gestion des utilisateurs ......................................... 16

    2.3.2.2 Raffinement du cas dutilisation Gestion des contrleurs ........................................ 16

    2.3.2.3 Raffinement du cas dutilisation Gestion des tests ................................................... 17

    2.4 Contraintes ............................................................................................................................. 17

    2.5 Conclusion ........................................................................................................................ 17

    Chapitre 3 Conception ................................................................................................................ 18

    3.1 Introduction ..................................................................................................................... 19

    3.2 Dictionnaire des donnes ................................................................................................ 19

    3.3 La base des donnes de lapplication .............................................................................. 21

    3.4 Conclusion ........................................................................................................................ 21

    Chapitre 4 Implmentation ......................................................................................................... 22

    4.1 Introduction ..................................................................................................................... 23

    4.2 Environnement matriel .................................................................................................. 23

    4.3 Environnement logiciel .................................................................................................... 23

  • Ecole Nationale dIngnieurs de Tunis Stage ingnieur

    4

    4.4 Interfaces de lapplication ................................................................................................ 23

    4.4.1 Interface dauthentification : ............................................................................................... 23

    4.4.2 Menu principale ................................................................................................................... 24

    4.4.3 Interface gestion des contrleurs ........................................................................................ 25

    4.4.4 Sous menu gestion des tests ................................................................................................ 26

    4.5 Conclusion ........................................................................................................................ 26

    Conclusion gnral ..................................................................................................................... 27

  • Ecole Nationale dIngnieurs de Tunis Stage ingnieur

    5

    Figure 1.1 Cycle de vie : Modle de chute d'eau ................................................................................... 10

    Figure 2.1 Diagramme de cas d'utilisation ............................................................................................ 15

    Figure 3.1 Schma de la base des donnes ........................................................................................... 21

    Figure 4.1 Interfaces authentification ................................................................................................... 24

    Figure 4.2 Interfaces Menu Principale .................................................................................................. 24

    Figure 4.3 Interface gestion des contrleurs ........................................................................................ 25

    Figure 4.4 Message d'erreur : Le contrleur existe dj ....................................................................... 25

    Figure 4.5 Message d'erreur : Les champs obligatoires ne sont pas remplis ........................................ 25

    Figure 4.6 Message de confirmation : Suppression .............................................................................. 26

    Figure 4.7 Message de confirmation : Quitter ...................................................................................... 26

    Figure 4.8 Sous menu ............................................................................................................................ 26

    file:///C:/Users/Chaib/Desktop/stage%20ingnieur/Rapport%20de%20stage%20ingnieur%20final.docx%23_Toc432351427file:///C:/Users/Chaib/Desktop/stage%20ingnieur/Rapport%20de%20stage%20ingnieur%20final.docx%23_Toc432351428file:///C:/Users/Chaib/Desktop/stage%20ingnieur/Rapport%20de%20stage%20ingnieur%20final.docx%23_Toc432351432file:///C:/Users/Chaib/Desktop/stage%20ingnieur/Rapport%20de%20stage%20ingnieur%20final.docx%23_Toc432351433file:///C:/Users/Chaib/Desktop/stage%20ingnieur/Rapport%20de%20stage%20ingnieur%20final.docx%23_Toc432351435file:///C:/Users/Chaib/Desktop/stage%20ingnieur/Rapport%20de%20stage%20ingnieur%20final.docx%23_Toc432351436

  • Ecole Nationale dIngnieurs de Tunis Stage ingnieur

    6

    Table 2.1 Description du cas dutilisation Gestion des utilisateurs ................................................. 16

    Table 2.2 Description du cas dutilisation Gestion des contrleurs ................................................ 16

    Table 2.3 Description du cas dutilisation Gestion des tests ........................................................... 17

    Table 3.1 Dictionnaire des donnes de la table "Utilisateurs" ............................................................ 19

    Table 3.2 Dictionnaire des donnes de la table " Contrleurs" .......................................................... 19

    Table 3.3 Dictionnaire des donnes de la table " Test_anglais" ......................................................... 20

    Table 3.4 Dictionnaire des donnes de la table " Visite_medicale" .................................................... 20

  • Ecole Nationale dIngnieurs de Tunis Stage ingnieur

    7

    Le changement technologique frquent domin par linformatique, est devenu indispensable

    tous les domaines dactivits humaines, de la production industrielle ou agricole la recherche

    fondamentale en passant par les circuits financiers. Il a ouvert des interactions entre les

    diffrents champs (politique, culturel, conomique, etc.) de la vie humaine.

    De nos jours, les nouvelles technologies de communication et dinformation ont facilit le

    passage du rel peru (redondance des traitements, les erreurs humaines qui sont trs frquentes

    et lourdes) vers le traitement automatique de donnes.

    Cest dans ce contexte que nous allons aborder ce prsent travail dans le cadre du stage

    ingnieur labor la fin de la 2me anne Tlcommunication lEcole Nationale

    dIngnieurs de Tunis.

    L'objet de ce projet sera la conception et la ralisation dune application destine la

    DIRECTION DU CENTRE DE CONTROLE REGIONAL (Office de l'aviation civile

    et des aroports / Direction Centrale du Trafic Arien) dans le but dinformatiser leurs

    systmes de gestion des licences des contrleurs arien. Ceci permettrait lagent administratif

    de vrifier la validit des licences des contrleurs dune manire informatise et de faciliter la

    tche de gestion, ce qui permettrait un gain de temps considrable.

    Ce rapport prsente lensemble des tapes suivies pour dvelopper la solution. Il contient quatre

    chapitres organiss comme suit :

    Le premier chapitre intitul Cadre du projet est consacr la prsentation du contexte du

    travail ainsi que lorganisme daccueil.

    Dans le chapitre Analyse des besoins et spcification , nous dterminons les besoins

    fonctionnels et non fonctionnels de notre application et prsentons les diffrents cas

    dutilisation.

    Le troisime chapitre intitul Conception dtaille les diffrents aspects conceptuels de

    lapplication.

    Le dernier chapitre intitul Implmentation prsente lenvironnement de travail ainsi que

    les outils logiciels que nous avons utiliss pour la ralisation de notre projet. Il illustre aussi le

    travail ralis avec un ensemble dinterfaces graphiques conues pour lapplication.

    En conclusion, nous mentionnons les diffrents atouts de ce projet et les perspectives

    damliorations possibles.

  • 8

    Chapitre 1

    Sommaire

    1.1 Introduction

    1.2 Prsentation de la socit

    1.3 Description du projet

    1.4 Conclusion

  • 9

    1.1 Introduction

    Ce chapitre est consacr pour la prsentation de lentreprise daccueil, la prcision du cadre du

    projet et la problmatique puis lnumration des tapes de travail raliser pour achever ce

    projet.

    1.2 Prsentation de la socit

    L'Office de l'aviation civile et des aroports (OACA) est une socit tunisienne de droit public

    caractre industriel et commercial. Elle remplace, le 30 juin 1998, l'Office des ports ariens

    de Tunisie (OPAT) cr le 3 juillet 1970.

    Sous la tutelle du ministre du Transport, l'OACA est charg de grer l'ensemble des aroports

    du pays, dont Tunis, Djerba, Tozeur, Sfax, Tabarka et Gafsa. Les aroports de Monastir et

    Enfida sont en revanche grs par le consortium turc TAV Airports Holding.

    L'office est charg des missions suivantes :

    Lexploitation, l'amnagement et le dveloppement des aroports ainsi que

    l'accomplissement de toutes les oprations et services ncessaires aux voyageurs, au

    public, aux avions, au fret et au courrier ;

    Le contrle rgional et local de la navigation arienne et la participation l'excution

    des plans de recherches et de sauvegarde ;

    La dlivrance de tous les documents requis pour le personnel aronautique, les avions et la

    navigation arienne conformment la lgislation en vigueur.

    1.3 Description du projet

    1.3.1 Mise en situation

    Un contrleur de la circulation arienne est une personne charge d'assurer le contrle, la

    scurit et la gestion de la circulation arienne.

    La prestation des services de navigation arienne exige un personnel hautement qualifi dont

    les comptences peuvent tre prouves par une licence renouvelable.

    Le renouvellement de la licence de contrle est soumis diverses obligations :

    Avoir un certificat d'aptitude mdicale en tat de validit.

    Avoir un certificat dun niveau adquat de connaissances linguistiques (Anglais).

    Avant lexpiration de lun des certificats, un agent administratif doit informer le contrleur

    arien et prparer un rendez-vous pour passer les tests ncessaires.

    https://fr.wikipedia.org/wiki/Avionhttps://fr.wikipedia.org/wiki/Transport_de_marchandiseshttps://fr.wikipedia.org/wiki/Navigation_a%C3%A9rienne

  • 10

    1.3.2 Objectifs de lapplication

    Lobjectif de lapplication est dinformatiser la tche de gestion des licences des contrleurs.

    En fait elle sera capable de stocker les informations propres aux contrleurs ainsi que les tests

    raliss afin dinformer le contrleur du prochain rendez-vous.

    1.4 Mthodologie et formalismes adopts

    Nous allons adopter le cycle de vie en Cascade, lUML comme langage de modlisation et

    JAVA comme langage dimplmentation.

    Nous avons opt pour ces choix d ces caractristiques :

    Cycle de vie en cascade :

    Le Cycle de vie en cascade est adapt des projets d'une dure infrieure une anne, aussi

    des projets avec une composante rglementaire solide, tels que les projets de back-office.

    Le principe du modle de chute d'eau est de scinder le projet en phases distinctes sur le principe

    de non-retour. Lorsqu'une phase est termine, le rsultat est utilis comme un point d'entre

    pour la phase suivante.

    Spcification des besoins

    Analyse

    Conception

    Implmentation

    Tests

    Figure 1.1 Cycle de vie : Modle de chute d'eau

  • 11

    Description UML :

    UML est utilis pour spcifier, visualiser, modifier et construire les documents ncessaires au

    bon dveloppement d'un logiciel orient objet. UML offre un standard de modlisation, pour

    reprsenter l'architecture logicielle.

    1.5 Conclusion

    Dans ce chapitre introductif, nous avons prsent lorganisme daccueil ainsi que le projet

    raliser. Nous allons entamer maintenant la phase de spcification des besoins des futurs

    utilisateurs du systme.

  • 12

    Chapitre 2

    Sommaire

    2.1 Introduction

    2.2 Spcification des besoins

    2.3 Diagramme de cas dutilisation

    2.5 Conclusion

  • 13

    2.1 Introduction

    La phase danalyse et spcification des besoins prsente une tape primordiale dans le cycle de

    dveloppement dun projet. En effet, elle permet de mieux comprendre le travail demand en

    dgageant les besoins des diffrents utilisateurs que le systme doit accomplir.

    2.2 Analyse globale de lapplication

    2.2.1 Description des acteurs

    Cette section a pour objet de prsenter les acteurs et leurs fonctionnalits auxquelles doit

    rpondre notre application. Nous commenons notre analyse par identifier les acteurs qui

    agissent sur notre systme savoir :

    Ladministrateur : Joue un rle primordial dans lassurance du bon fonctionnement du

    systme. Cest la personne qui prend en charge la gestion des contrleurs ainsi que leurs

    licences. Cette personne bnficie de toutes les fonctionnalits de lapplication.

    Les contrleurs : cest un acteur qui intervient seulement pour grer ces propres

    informations.

    2.2.2 Spcification des besoins fonctionnels :

    Ladministrateur peut : Grer les utilisateurs :

    - Consulter la liste des utilisateurs

    - Ajouter un utilisateur

    - Supprimer un utilisateur

    - Modifier un utilisateur

    - Rechercher un utilisateur

    Grer les contrleurs :

    - Consulter la liste des contrleurs - Ajouter un contrleur - Supprimer un contrleur - Modifier un contrleur - Rechercher un contrleur - Imprimer la liste des contrleurs - Informer un contrleur par E-mail

    Grer les Tests :

    - Consulter la liste des tests

    - Ajouter un test

    - Supprimer un test

    Le contrleur peut : Consulter et grer ses informations

  • 14

    2.2.3 Spcification des besoins non fonctionnels

    Aprs avoir dtermin les besoins fonctionnels, nous prsentons ci-dessous lensemble des

    contraintes respecter pour garantir la performance du systme, donc pour fournir un produit

    performant qui respecte les exigences de lutilisateur et qui peut faire face des risques de

    panne ou de non fonctionnement.

    Performance :

    Afin dtre accepte par le client, notre application doit respecter le critre de performance tout

    en assurant un temps de rponse minimum et des fonctionnalits rpondant aux besoins de

    lutilisateur.

    La simplicit :

    Un visiteur assez modeste pourra utiliser un tel service de faon intuitive.

    Lergonomie de linterface :

    Les interfaces doivent tre simples et conviviales : On doit essayer le maximum dliminer

    lencombrement.

    La modularit de lapplication :

    Avoir un code simple facile maintenir et comprendre en cas de besoin.

    2.3 Diagramme de cas dutilisation

    2.3.1 Diagramme de cas dutilisation : Gnrale

    Un diagramme de cas dutilisation capture le comportement dun systme, dun sous-systme,

    dune classe ou dun composant tel quun utilisateur extrieur le voit.

    Il scinde la fonctionnalit du systme en units cohrentes, les cas dutilisation, ayant un sens

    pour les acteurs. Les cas dutilisation permettent dexprimer le besoin des utilisateurs dun

    systme, ils sont donc une vision oriente utilisateur de ce besoin au contraire dune vision

    informatique.

    Il ne faut pas ngliger cette premire tape pour produire un logiciel conforme aux attentes des

    utilisateurs ; Pour laborer les cas dutilisations, il faut se fonder sur des entretiens avec les

    utilisateurs.

  • 15

    Administrateur

    Dconnexion

    Consulter la l iste des

    util isateurs

    Ajouter un

    util isateur

    Supprimer un

    util isateur

    Modifier un

    util isateur

    Rechercher un

    util isateur

    S'authentifier

    Consulter la l iste des

    contrleurs

    Ajouter un

    contrleur

    Supprimer un

    contrleur

    Modifier un

    contrleur

    Rechercher un

    contrleur

    Imprimer la l iste des

    contrleurs

    Informer un

    contrleur

    Consulter la l iste

    des tests

    Ajouter un test

    Supprimer un

    test

    Grer les util isateurs

    Grer les contrleurs

    Grer les Tests

    ContrleurConsulter ses informations

    S'authentifier

    Figure 2.1 Diagramme de cas d'utilisation

  • 16

    2.3.2 Raffinement des cas dutilisation

    2.3.2.1 Raffinement du cas dutilisation Gestion des utilisateurs

    Table 2.1 Description du cas dutilisation Gestion des utilisateurs

    Nom du cas

    dutilisation

    Gestion des utilisateurs

    Acteurs Administrateur

    Pr condition Le systme fonctionne et lutilisateur est authentifi

    Scnario principal 1. Le systme prsente les diffrents utilisateurs existants. 2. Ladministrateur pourra ajouter soit un autre administrateur

    ou un contrleur. 3. Dans le cas dajout, ladmin doit insrer la matricule de

    lutilisateur, le login, le mot de passe ainsi que le type de lutilisateur.

    4. Ladministrateur pourra modifier ou supprimer les utilisateurs.

    Exceptions Le systme affiche un message derreur dans le cas o : -Les donnes introduites par ladministrateur sont incohrentes. -Ladministrateur ne remplit pas tous les champs obligatoires. -La matricule de lutilisateur ajout existe dans la base des donnes.

    2.3.2.2 Raffinement du cas dutilisation Gestion des contrleurs

    Table 2.2 Description du cas dutilisation Gestion des contrleurs

    Nom du cas

    dutilisation

    Gestion des contrleurs

    Acteurs Administrateur

    Pr condition Le systme fonctionne et lutilisateur est authentifi

    Scnario principal 1. Le systme prsente les diffrents contrleurs existants. 2. Ladministrateur pourra ajouter un contrleur. Dans ce cas

    ladministrateur doit insrer la matricule du contrleur ainsi que ses informations (nom, prnom, date de naissance).

    3. Ladministrateur pourra modifier ou supprimer les contrleurs.

    4. Ladministrateur pourra rechercher une liste des contrleurs par catgorie et limprimer

    5. Ladministrateur pourra informer un contrleur pour passer les tests.

    Exceptions Le systme affiche un message derreur dans le cas o : -Les donnes introduites par ladministrateur sont incohrentes. -Ladministrateur ne remplit pas tous les champs obligatoires. -Le matricule du contrleur ajout existe dans la base des donnes. -Problme de connexion au serveur mail.

  • 17

    2.3.2.3 Raffinement du cas dutilisation Gestion des tests

    Table 2.3 Description du cas dutilisation Gestion des tests

    Nom du cas

    dutilisation

    Gestion des tests

    Acteurs Administrateur

    Pr condition Le systme fonctionne et lutilisateur est authentifi

    Scnario principal 5. Le systme prsente les diffrents tests existants. 6. Ladministrateur pourra ajouter soit un test anglais, soit un

    test d'aptitude mdicale. 7. Dans le cas dajout, ladmin doit insrer la matricule de

    lutilisateur, la date planifie, la date de ralisation et la date de prochain rendez-vous.

    8. Ladministrateur pourra supprimer les tests.

    Exceptions Le systme affiche un message derreur dans le cas o : -Les donnes introduites par ladministrateur sont incohrentes. -Ladministrateur ne remplit pas tous les champs obligatoires. -La date de ralisation est suprieure la date du prochain RDV

    2.4 Contraintes

    Certaines contraintes de temps nous ont t imposes. Tout d'abord, la premire partie du projet

    est consacre la rflexion et la conception de divers documents (cahier des charges, des

    recettes, les diagrammes...). Ensuite, la seconde partie, durant de la 2me la 4me semaine,

    est utilise pour le dveloppement du projet en lui-mme.

    2.5 Conclusion

    Dans ce chapitre, nous avons numr les diffrents besoins fonctionnels et non fonctionnels

    de notre application. Ensuite, nous avons fait une tude des diffrents cas dutilisation de notre

    solution. Ce chapitre a t dune importance cruciale surtout pour la comprhension des besoins

    et attentes de lutilisateur.

  • 18

    Sommaire

    3.1 Introduction

    3.2 Dictionnaire des donnes

    3.3 Diagramme de classe

    3.4 Conclusion

  • 19

    3.1 Introduction

    Dans ce chapitre nous abordons la partie conception du projet, dans laquelle, nous dtaillons

    les diffrents lments de conception. En dautres termes, elle consiste la modlisation de la

    solution.

    3.2 Dictionnaire des donnes

    Table 3.1 Dictionnaire des donnes de la table "Utilisateurs"

    Attribut Type Description

    Matricule Int Le matricule de lutilisateur

    Username String Le login

    Password String Le mot de passe

    Type String Le type de lutilisateur

    Table 3.2 Dictionnaire des donnes de la table " Contrleurs"

    Attribut Type Description

    Matricule Int Le matricule des contrleurs

    Cin String Numro de la carte didentit

    du contrleur

    Nom String Le nom du contrleur

    Prnom String Le prnom du contrleur

    Qualification String La qualification de laroport

    Adresse_mail String Ladresse e-mail du

    contrleur

    Date_naissance Date La date de naissance

    Affectation String Lieu de travail

    Numero_tel Long int Le numro de tlphone

    Prochai_test_anglais Date La prochaine date du test

    anglais

  • 20

    Prochaine_visite_medicale Date La prochaine date de la visite

    mdicale

    Table 3.3 Dictionnaire des donnes de la table " Test_anglais"

    Attribut Type Description

    Matricule Int Le matricule du contrleur

    Date_planifie Date La date planifie par

    AMIDEAST pour passer le

    test

    Date_ralisation Date La date de ralisation du

    test

    Prochain_RDV Date Le prochain rendez-vous

    pour passer le test

    Remarque String Remarque

    Table 3.4 Dictionnaire des donnes de la table " Visite_mdicale"

    Attribut Type Description

    Matricule Int Le matricule du contrleur

    Date_planifie Date La date planifie par centre

    d'expertise de mdecine

    aronautique pour passer le

    test

    Date_ralisation Date La date de ralisation du

    test

    Prochain_RDV Date Le prochain rendez-vous

    pour passer le test

    Remarque String Remarque

  • 21

    3.3 La base des donnes de lapplication

    La Figure 3.1 reprsente les tables utilises dans notre base des donnes

    Figure 3.1 Schma de la base des donnes

    3.4 Conclusion

    Dans ce chapitre nous avons dtaill les diffrentes vues conceptuelles des applications raliser

    travers un modles UML. Cette conception est essentielle pour la phase de ralisation qui constitue

    lobjet du chapitre suivant.

  • 22

    Sommaire

    4.1 Introduction

    4.2 Environnement matriel

    4.3 Environnement logiciel

    4.4 Prsentation de lapplication

    4.5 Conclusion

  • 23

    4.1 Introduction

    Dans ce chapitre, nous prsentons lenvironnement matriel et logiciel du projet. Ensuite,

    nous nous intressons la description de quelques interfaces du systme implment dans le

    cadre de quelques scnarios dutilisation.

    4.2 Environnement matriel

    La ralisation de cette application est ralise par un ordinateur qui possde les

    caractristiques suivantes :

    Marque : HP ProBook 4540s.

    Processeur : Intel Core i3, 2,40Ghz,

    RAM : 8GB

    4.3 Environnement logiciel

    Systme dexploitation : Windows 8.1 Pro.

    SGBD : MySQL v5.

    IDE de dveloppement : NetBeans 8.0.2

    Outil de conception : PowerAMC., MySQL Workbench 6.2.5.

    Traitement et modification des images : Adobe Photoshop CS.

    API: JavaMail, iReport.

    4.4 Interfaces de lapplication

    Nous exposerons quelques interfaces de notre application, en essayant chaque fois de dcrire

    les diffrents objets interactifs mis la disposition de lutilisateur.

    4.4.1 Interface dauthentification :

    Lors de lancement de lapplication, une interface dauthentification apparat mentionnant le

    nom de lapplication et lentreprise. Ensuite le client est invit sauthentifier en saisissant ses

    paramtres daccs (Figure 4.1).

  • 24

    Figure 5.1 : interfaces authentification

    4.4.2 Menu principale

    Cest la fentre principale aprs lauthentification, cette page reprsente tout ce que lutilisateur

    peut faire. Cest une interface de transition o le client doit choisir entre grer les utilisateurs,

    grer les contrleurs ou grer les tests.

    Figure 4.2 interfaces Menu Principale

  • 25

    4.4.3 Interface gestion des contrleurs

    Ici, lutilisateur peut ajouter un autre contrleur, il doit donc saisir les nouvelles informations

    de ce dernier, ces informations doivent tre forcment convenables sinon un message derreur

    de saisie sera apparu.

    A partir de cette fentre, lutilisateur peut aussi basculer vers les autres boutons pour effectuer

    dautres tches, telle que modification, suppression, consultation

    Messages derreurs :

    Figure 4.5 Message d'erreur : Les champs obligatoires ne sont pas remplis

    Figure 4.3

    Figure 4.3

    Figure 4.3 Interface gestion des contrleurs

    Figure 4.4 Message d'erreur : Le contrleur existe dj

  • 26

    Messages de confirmation :

    4.4.4 Sous menu gestion des tests

    Dans ce sous menu, lutilisateur chois de grer soit un test anglais, soit un test daptitude

    mdicale.

    Figure 4.8 Sous menu

    4.5 Conclusion

    Dans ce chapitre nous avons dtaill les technologies utilises pour la ralisation de notre projet

    ainsi que les fonctionnalits de base de lapplication travers un ensemble de captures dcran.

    Figure 4.5 Figure 4.6 Figure 4.6 Message de confirmation : Suppression Figure 4.7 Message de confirmation : Quitter

  • Ecole Nationale dIngnieurs de Tunis Stage ingnieur

    27

    Lobjectif de ce projet tait de concevoir et dvelopper une application de gestion des licences

    des contrleurs ariens.

    Pour la conception de notre application, nous avons eu recours lUML. Cette approche nous

    a permis de bien comprendre la problmatique et de bien modliser les objectifs atteindre. Ce

    qui nous a donn la possibilit de raliser un systme stable et volutif.

    Le projet sest droul selon trois axes principaux afin de passer par les tapes essentielles de

    tout projet : lanalyse, la conception et la ralisation. Pour la ralisation, nous avons utilis Java

    comme langage de programmation et MySQL v5 comme systme de gestion de base de

    donnes.

    Lexprience au sein dun cadre professionnel, nous a t bnfique. Ce stage nous a permis de

    nous familiariser la vie professionnelle, dexploiter des notions fondamentales dans lorient

    objet, et dapprofondir nos connaissances thoriques acquises lEcole Nationale

    dIngnieurs de Tunis.

    Nous envisageons comme perspectives une amlioration de lapplication qui la rendra plus

    accessible. En effet, nous souhaitons la ramener en une application web J2EE et informer les

    contrleurs plutt par SMS.

  • Ecole Nationale dIngnieurs de Tunis Stage ingnieur

    28

    [URL1] http://www.oracle.com : site officiel dORACLE : consult le 05/08/2015

    [URL2] https://netbeans.org/project /fr/ : Guide Pratique EDI NetBeans : consult le 05/08/2015

    [URL3] https://openclassrooms.com/courses/apprenez-a-programmer : consult le 06->30/08/2015

    [URL4] http://www. community.jaspersoft.com/ : consult le 28/08/2015

    [URL5] http://www.oracle.com/technetwork/java/javamail/index.html consult le 29/08/2015

    http://www.oracle.com/https://netbeans.org/project_downloads/fr/Guide%20Pratique%20EDI%20NetBeans/Chapitre2-Essentiels.pdfhttps://openclassrooms.com/courses/apprenez-a-programmerhttp://www.oracle.com/technetwork/java/javamail/index.html

Recommended

View more >