Rapport de stage ingénieur

1. Rapport de stage ingénieur
Spécialité : Télécommunications
Elaboré par :
CHAIEB Ghassene
Développement d’une application de gestion
des licences des contrôleurs aériens
Lieur de stage : Direction de Navigation aérienne
Période de stage : 1 août 2015 - 30 août 2015
Encadrant : Sofiene Slama
Année universitaire : 2015/201

2. Ecole Nationale d’Ingénieurs de Tunis Stage ingénieur
2
C’est avec le plus grand honneur que j’ai réservé l’ouverture de mon rapport en signe de gratitude
et de reconnaissance à l’égard de tous ceux qui m’ont aidé, de près ou de loin, à la réalisation de ce
stage.
Je tiens à adresser mes vifs remerciements à mon encadrant Mr. Sofiene Slama (Chef de la
Division Développement et Futurs Systèmes de la direction de navigation aérienne) pour sa
présence, son encadrement, ses conseils fournis de façon efficace Tout au long de la période de
réalisation.
Je veux aussi exprimer mes remerciements sincères à Mr. Fredj Chaieb (Chef service commercial
à GAMMA informatique) qui m’a soutenu et aidé à progresser dans mon stage.
Mes remerciements s’adressent également aux membres du Jury qui nous font l'honneur de participer à
ma soutenance.

3. Ecole Nationale d’Ingénieurs de Tunis Stage ingénieur
3
Introduction générale................................................................................................................... 7
Chapitre 1 Cadre du projet............................................................................................................ 8
1.1 Introduction ........................................................................................................................9
1.2 Présentation de la société...................................................................................................9
1.3 Description du projet ..........................................................................................................9
1.3.1 Mise en situation.................................................................................................................... 9
1.3.2 Objectifs de l’application...................................................................................................... 10
1.4 Méthodologie et formalismes adoptés............................................................................ 10
1.5 Conclusion........................................................................................................................ 11
Chapitre 2 Analyse et spécification des besoins........................................................................... 12
2.1 Introduction ..................................................................................................................... 13
2.2 Analyse globale de l’application....................................................................................... 13
2.2.1 Description des acteurs........................................................................................................ 13
2.2.2 Spécification des besoins fonctionnels :............................................................................... 13
2.2.3 Spécification des besoins non fonctionnels ......................................................................... 14
2.3 Diagramme de cas d’utilisation........................................................................................ 14
2.3.1 Diagramme de cas d’utilisation : Générale .......................................................................... 14
2.3.2 Raffinement des cas d’utilisation ......................................................................................... 16
2.3.2.1 Raffinement du cas d’utilisation «Gestion des utilisateurs»......................................... 16
2.3.2.2 Raffinement du cas d’utilisation «Gestion des contrôleurs»........................................ 16
2.3.2.3 Raffinement du cas d’utilisation «Gestion des tests»................................................... 17
2.4 Contraintes............................................................................................................................. 17
2.5 Conclusion........................................................................................................................ 17
Chapitre 3 Conception................................................................................................................ 18
3.1 Introduction ..................................................................................................................... 19
3.2 Dictionnaire des données ................................................................................................ 19
3.3 La base des données de l’application .............................................................................. 21
3.4 Conclusion........................................................................................................................ 21
Chapitre 4 Implémentation......................................................................................................... 22
4.1 Introduction ..................................................................................................................... 23
4.2 Environnement matériel.................................................................................................. 23
4.3 Environnement logiciel .................................................................................................... 23

4. Ecole Nationale d’Ingénieurs de Tunis Stage ingénieur
4
4.4 Interfaces de l’application................................................................................................ 23
4.4.1 Interface d’authentification : ............................................................................................... 23
4.4.2 Menu principale ................................................................................................................... 24
4.4.3 Interface gestion des contrôleurs ........................................................................................ 25
4.4.4 Sous menu gestion des tests ................................................................................................ 26
4.5 Conclusion........................................................................................................................ 26
Conclusion général..................................................................................................................... 27

5. Ecole Nationale d’Ingénieurs de Tunis Stage ingénieur
5
Figure 1.1 Cycle de vie : Modèle de chute d'eau................................................................................... 10
Figure 2.1 Diagramme de cas d'utilisation............................................................................................ 15
Figure 3.1 Schéma de la base des données........................................................................................... 21
Figure 4.1 Interfaces authentification................................................................................................... 24
Figure 4.2 Interfaces Menu Principale .................................................................................................. 24
Figure 4.3 Interface gestion des contrôleurs ........................................................................................ 25
Figure 4.4 Message d'erreur : Le contrôleur existe déjà....................................................................... 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

6. Ecole Nationale d’Ingénieurs de Tunis Stage ingénieur
6
Table 2.1 Description du cas d’utilisation «Gestion des utilisateurs»................................................. 16
Table 2.2 Description du cas d’utilisation «Gestion des contrôleurs»................................................ 16
Table 2.3 Description du cas d’utilisation «Gestion des tests»........................................................... 17
Table 3.1 Dictionnaire des données de la table "Utilisateurs"............................................................ 19
Table 3.2 Dictionnaire des données de la table " Contrôleurs" .......................................................... 19
Table 3.3 Dictionnaire des données de la table " Test_anglais" ......................................................... 20
Table 3.4 Dictionnaire des données de la table " Visite_medicale".................................................... 20

7. Ecole Nationale d’Ingénieurs de Tunis Stage ingénieur
7
Le changement technologique fréquent dominé par l’informatique, est devenu indispensable à
tous les domaines d’activités humaines, de la production industrielle ou agricole à la recherche
fondamentale en passant par les circuits financiers. Il a ouvert des interactions entre les
différents champs (politique, culturel, économique, etc.) de la vie humaine.
De nos jours, les nouvelles technologies de communication et d’information ont facilité le
passage du réel perçu (redondance des traitements, les erreurs humaines qui sont très fréquentes
et lourdes) vers le traitement automatique de données.
C’est dans ce contexte que nous allons aborder ce présent travail dans le cadre du stage
ingénieur élaboré à la fin de la 2ème année Télécommunication à l’Ecole Nationale
d’Ingénieurs de Tunis.
L'objet de ce projet sera la conception et la réalisation d’une application destinée à la
DIRECTION DU CENTRE DE CONTROLE REGIONAL (Office de l'aviation civile
et des aéroports / Direction Centrale du Trafic Aérien) dans le but d’informatiser leurs
systèmes de gestion des licences des contrôleurs aérien. Ceci permettrait à l’agent administratif
de vérifier la validité des licences des contrôleurs d’une manière informatisée et de faciliter la
tâche de gestion, ce qui permettrait un gain de temps considérable.
Ce rapport présente l’ensemble des étapes suivies pour développer la solution. Il contient quatre
chapitres organisés comme suit :
Le premier chapitre intitulé « Cadre du projet » est consacré à la présentation du contexte du
travail ainsi que l’organisme d’accueil.
Dans le chapitre « Analyse des besoins et spécification », nous déterminons les besoins
fonctionnels et non fonctionnels de notre application et présentons les différents cas
d’utilisation.
Le troisième chapitre intitulé « Conception » détaille les différents aspects conceptuels de
l’application.
Le dernier chapitre intitulé « Implémentation » présente l’environnement de travail ainsi que
les outils logiciels que nous avons utilisés pour la réalisation de notre projet. Il illustre aussi le
travail réalisé avec un ensemble d’interfaces graphiques conçues pour l’application.
En conclusion, nous mentionnons les différents atouts de ce projet et les perspectives
d’améliorations possibles.

8. 8
Chapitre 1
Sommaire
1.1 Introduction
1.2 Présentation de la société
1.3 Description du projet
1.4 Conclusion

9. 9
1.1 Introduction
Ce chapitre est consacré pour la présentation de l’entreprise d’accueil, la précision du cadre du
projet et la problématique puis l’énumération des étapes de travail à réaliser pour achever ce
projet.
1.2 Présentation de la société
L'Office de l'aviation civile et des aéroports (OACA) est une société tunisienne de droit public
à caractère industriel et commercial. Elle remplace, le 30 juin 1998, l'Office des ports aériens
de Tunisie (OPAT) créé le 3 juillet 1970.
Sous la tutelle du ministère du Transport, l'OACA est chargé de gérer l'ensemble des aéroports
du pays, dont Tunis, Djerba, Tozeur, Sfax, Tabarka et Gafsa. Les aéroports de Monastir et
Enfida sont en revanche gérés par le consortium turc TAV Airports Holding.
L'office est chargé des missions suivantes :
 L’exploitation, l'aménagement et le développement des aéroports ainsi que
l'accomplissement de toutes les opérations et services nécessaires aux voyageurs, au
public, aux avions, au fret et au courrier ;
 Le contrôle régional et local de la navigation aérienne et la participation à l'exécution
des plans de recherches et de sauvegarde ;
La délivrance de tous les documents requis pour le personnel aéronautique, les avions et la
navigation aérienne conformément à la législation en vigueur.
1.3 Description du projet
1.3.1 Mise en situation
Un contrôleur de la circulation aérienne est une personne chargée d'assurer le contrôle, la
sécurité et la gestion de la circulation aérienne.
La prestation des services de navigation aérienne exige un personnel hautement qualifié dont
les compétences peuvent être prouvées par une licence renouvelable.
Le renouvellement de la licence de contrôle est soumis à diverses obligations :
 Avoir un certificat d'aptitude médicale en état de validité.
 Avoir un certificat d’un niveau adéquat de connaissances linguistiques (Anglais).
Avant l’expiration de l’un des certificats, un agent administratif doit informer le contrôleur
aérien et préparer un rendez-vous pour passer les tests nécessaires.

10. 10
1.3.2 Objectifs de l’application
L’objectif de l’application est d’informatiser la tâche de gestion des licences des contrôleurs.
En fait elle sera capable de stocker les informations propres aux contrôleurs ainsi que les tests
réalisés afin d’informer le contrôleur du prochain rendez-vous.
1.4 Méthodologie et formalismes adoptés
Nous allons adopter le cycle de vie en Cascade, l’UML comme langage de modélisation et
JAVA comme langage d’implémentation.
Nous avons opté pour ces choix dû à ces caractéristiques :
 Cycle de vie en cascade :
Le Cycle de vie en cascade est adapté à des projets d'une durée inférieure à une année, aussi à
des projets avec une composante réglementaire solide, tels que les projets de back-office.
Le principe du modèle de chute d'eau est de scinder le projet en phases distinctes sur le principe
de non-retour. Lorsqu'une phase est terminée, le résultat est utilisé comme un point d'entrée
pour la phase suivante.
Spécification des besoins
Analyse
Conception
Implémentation
Tests
Figure 1.1 Cycle de vie : Modèle de chute d'eau

11. 11
 Description UML :
UML est utilisé pour spécifier, visualiser, modifier et construire les documents nécessaires au
bon développement d'un logiciel orienté objet. UML offre un standard de modélisation, pour
représenter l'architecture logicielle.
1.5 Conclusion
Dans ce chapitre introductif, nous avons présenté l’organisme d’accueil ainsi que le projet à
réaliser. Nous allons entamer maintenant la phase de spécification des besoins des futurs
utilisateurs du système.

12. 12
Chapitre 2
Sommaire
2.1 Introduction
2.2 Spécification des besoins
2.3 Diagramme de cas d’utilisation
2.5 Conclusion

13. 13
2.1 Introduction
La phase d’analyse et spécification des besoins présente une étape primordiale dans le cycle de
développement d’un projet. En effet, elle permet de mieux comprendre le travail demandé en
dégageant les besoins des différents utilisateurs que le système doit accomplir.
2.2 Analyse globale de l’application
2.2.1 Description des acteurs
Cette section a pour objet de présenter les acteurs et leurs fonctionnalités auxquelles doit
répondre notre application. Nous commençons notre analyse par identifier les acteurs qui
agissent sur notre système à savoir :
 L’administrateur : Joue un rôle primordial dans l’assurance du bon fonctionnement du
système. C’est la personne qui prend en charge la gestion des contrôleurs ainsi que leurs
licences. Cette personne bénéficie de toutes les fonctionnalités de l’application.
 Les contrôleurs : c’est un acteur qui intervient seulement pour gérer ces propres
informations.
2.2.2 Spécification des besoins fonctionnels :
 L’administrateur peut :
 Gérer les utilisateurs :
- Consulter la liste des utilisateurs
- Ajouter un utilisateur
- Supprimer un utilisateur
- Modifier un utilisateur
- Rechercher un utilisateur
 Gérer les contrôleurs :
- Consulter la liste des contrôleurs
- Ajouter un contrôleur
- Supprimer un contrôleur
- Modifier un contrôleur
- Rechercher un contrôleur
- Imprimer la liste des contrôleurs
- Informer un contrôleur par E-mail
 Gérer les Tests :
- Consulter la liste des tests
- Ajouter un test
- Supprimer un test
 Le contrôleur peut :
 Consulter et gérer ses informations

14. 14
2.2.3 Spécification des besoins non fonctionnels
Après avoir déterminé les besoins fonctionnels, nous présentons ci-dessous l’ensemble des
contraintes à respecter pour garantir la performance du système, donc pour fournir un produit
performant qui respecte les exigences de l’utilisateur et qui peut faire face à des risques de
panne ou de non fonctionnement.
 Performance :
Afin d’être acceptée par le client, notre application doit respecter le critère de performance tout
en assurant un temps de réponse minimum et des fonctionnalités répondant aux besoins de
l’utilisateur.
 La simplicité :
Un visiteur assez modeste pourra utiliser un tel service de façon intuitive.
 L’ergonomie de l’interface :
Les interfaces doivent être simples et conviviales : On doit essayer le maximum d’éliminer
l’encombrement.
 La modularité de l’application :
Avoir un code simple facile à maintenir et à comprendre en cas de besoin.
2.3 Diagramme de cas d’utilisation
2.3.1 Diagramme de cas d’utilisation : Générale
Un diagramme de cas d’utilisation capture le comportement d’un système, d’un sous-système,
d’une classe ou d’un composant tel qu’un utilisateur extérieur le voit.
Il scinde la fonctionnalité du système en unités cohérentes, les cas d’utilisation, ayant un sens
pour les acteurs. Les cas d’utilisation permettent d’exprimer le besoin des utilisateurs d’un
système, ils sont donc une vision orientée utilisateur de ce besoin au contraire d’une vision
informatique.
Il ne faut pas négliger cette première étape pour produire un logiciel conforme aux attentes des
utilisateurs ; Pour élaborer les cas d’utilisations, il faut se fonder sur des entretiens avec les
utilisateurs.

15. 15
<<extend>>
<<extend>>
<<extend>>
<<extend>>
<<extend>>
<<extend>>
<<extend>>
<<extend>>
<<extend>>
<<extend>>
<<extend>>
<<extend>>
<<include>>
<<include>>
<<include>>
<<extend>>
<<extend>>
<<extend>>
Administrateur
Déconnexion
Consulter la liste des
utilisateurs
Ajouter un
utilisateur
Supprimer un
utilisateur
Modifier un
utilisateur
Rechercher un
utilisateur
S'authentifier
Consulter la liste des
contrôleurs
Ajouter un
contrôleur
Supprimer un
contrôleur
Modifier un
contrôleur
Rechercher un
contrôleur
Imprimer la liste des
contrôleurs
Informer un
contrôleur
Consulter la liste
des tests
Ajouter un test
Supprimer un
test
Gérer les utilisateurs
Gérer les contrôleurs
Gérer les Tests
<<include>>Contrôleur Consulter ses informations
S'authentifier
Figure 2.1 Diagramme de cas d'utilisation

16. 16
2.3.2 Raffinement des cas d’utilisation
2.3.2.1 Raffinement du cas d’utilisation «Gestion des utilisateurs»
Table 2.1 Description du cas d’utilisation «Gestion des utilisateurs»
Nom du cas
d’utilisation
Gestion des utilisateurs
Acteurs Administrateur
Pré condition Le système fonctionne et l’utilisateur est authentifié
Scénario principal 1. Le système présente les différents utilisateurs existants.
2. L’administrateur pourra ajouter soit un autre administrateur
ou un contrôleur.
3. Dans le cas d’ajout, l’admin doit insérer la matricule de
l’utilisateur, le login, le mot de passe ainsi que le type de
l’utilisateur.
4. L’administrateur pourra modifier ou supprimer les
utilisateurs.
Exceptions Le système affiche un message d’erreur dans le cas où :
-Les données introduites par l’administrateur sont incohérentes.
-L’administrateur ne remplit pas tous les champs obligatoires.
-La matricule de l’utilisateur ajouté existe dans la base des
données.
2.3.2.2 Raffinement du cas d’utilisation «Gestion des contrôleurs»
Table 2.2 Description du cas d’utilisation «Gestion des contrôleurs»
Nom du cas
d’utilisation
Gestion des contrôleurs
Acteurs Administrateur
Pré condition Le système fonctionne et l’utilisateur est authentifié
Scénario principal 1. Le système présente les différents contrôleurs existants.
2. L’administrateur pourra ajouter un contrôleur. Dans ce cas
l’administrateur doit insérer la matricule du contrôleur ainsi
que ses informations (nom, prénom, date de naissance…).
3. L’administrateur pourra modifier ou supprimer les
contrôleurs.
4. L’administrateur pourra rechercher une liste des contrôleurs
par catégorie et l’imprimer
5. L’administrateur pourra informer un contrôleur pour passer
les tests.
Exceptions Le système affiche un message d’erreur dans le cas où :
-Les données introduites par l’administrateur sont incohérentes.
-L’administrateur ne remplit pas tous les champs obligatoires.
-Le matricule du contrôleur ajouté existe dans la base des
données.
-Problème de connexion au serveur mail.

17. 17
2.3.2.3 Raffinement du cas d’utilisation «Gestion des tests»
Table 2.3 Description du cas d’utilisation «Gestion des tests»
Nom du cas
d’utilisation
Gestion des tests
Acteurs Administrateur
Pré condition Le système fonctionne et l’utilisateur est authentifié
Scénario principal 5. Le système présente les différents tests existants.
6. L’administrateur pourra ajouter soit un test anglais, soit un
test d'aptitude médicale.
7. Dans le cas d’ajout, l’admin doit insérer la matricule de
l’utilisateur, la date planifiée, la date de réalisation et la date
de prochain rendez-vous.
8. L’administrateur pourra supprimer les tests.
Exceptions Le système affiche un message d’erreur dans le cas où :
-Les données introduites par l’administrateur sont incohérentes.
-L’administrateur ne remplit pas tous les champs obligatoires.
-La date de réalisation est supérieure à la date du prochain RDV
2.4 Contraintes
Certaines contraintes de temps nous ont été imposées. Tout d'abord, la première partie du projet
est consacrée à la réflexion et à la conception de divers documents (cahier des charges, des
recettes, les diagrammes...). Ensuite, la seconde partie, durant de la 2ème à la 4ème semaine,
est utilisée pour le développement du projet en lui-même.
2.5 Conclusion
Dans ce chapitre, nous avons énuméré les différents besoins fonctionnels et non fonctionnels
de notre application. Ensuite, nous avons fait une étude des différents cas d’utilisation de notre
solution. Ce chapitre a été d’une importance cruciale surtout pour la compréhension des besoins
et attentes de l’utilisateur.

18. 18
Sommaire
3.1 Introduction
3.2 Dictionnaire des données
3.3 Diagramme de classe
3.4 Conclusion

19. 19
3.1 Introduction
Dans ce chapitre nous abordons la partie conception du projet, dans laquelle, nous détaillons
les différents éléments de conception. En d’autres termes, elle consiste à la modélisation de la
solution.
3.2 Dictionnaire des données
Table 3.1 Dictionnaire des données de la table "Utilisateurs"
Attribut Type Description
Matricule Int Le matricule de l’utilisateur
Username String Le login
Password String Le mot de passe
Type String Le type de l’utilisateur
Table 3.2 Dictionnaire des données de la table " Contrôleurs"
Attribut Type Description
Matricule Int Le matricule des contrôleurs
Cin String Numéro de la carte d’identité
du contrôleur
Nom String Le nom du contrôleur
Prénom String Le prénom du contrôleur
Qualification String La qualification de l’aéroport
Adresse_mail String L’adresse e-mail du
contrôleur
Date_naissance Date La date de naissance
Affectation String Lieu de travail
Numero_tel Long int Le numéro de téléphone
Prochai_test_anglais Date La prochaine date du test
anglais

20. 20
Prochaine_visite_medicale Date La prochaine date de la visite
médicale
Table 3.3 Dictionnaire des données de la table " Test_anglais"
Attribut Type Description
Matricule Int Le matricule du contrôleur
Date_planifiée Date La date planifiée par
AMIDEAST pour passer le
test
Date_réalisation Date La date de réalisation du
test
Prochain_RDV Date Le prochain rendez-vous
pour passer le test
Remarque String Remarque
Table 3.4 Dictionnaire des données de la table " Visite_médicale"
Attribut Type Description
Matricule Int Le matricule du contrôleur
Date_planifiée Date La date planifiée par centre
d'expertise de médecine
aéronautique pour passer le
test
Date_réalisation Date La date de réalisation du
test
Prochain_RDV Date Le prochain rendez-vous
pour passer le test
Remarque String Remarque

21. 21
3.3 La base des données de l’application
La Figure 3.1 représente les tables utilisées dans notre base des données
Figure 3.1 Schéma de la base des données
3.4 Conclusion
Dans ce chapitre nous avons détaillé les différentes vues conceptuelles des applications à réaliser à
travers un modèles UML. Cette conception est essentielle pour la phase de réalisation qui constitue
l’objet du chapitre suivant.

22. 22
Sommaire
4.1 Introduction
4.2 Environnement matériel
4.3 Environnement logiciel
4.4 Présentation de l’application
4.5 Conclusion

23. 23
4.1 Introduction
Dans ce chapitre, nous présentons l’environnement matériel et logiciel du projet. Ensuite,
nous nous intéressons à la description de quelques interfaces du système implémenté dans le
cadre de quelques scénarios d’utilisation.
4.2 Environnement matériel
La réalisation de cette application est réalisée par un ordinateur qui possède les
caractéristiques suivantes :
 Marque : HP ProBook 4540s.
 Processeur : Intel Core i3, 2,40Ghz,
 RAM : 8GB
4.3 Environnement logiciel
 Système d’exploitation : Windows 8.1 Pro.
 SGBD : MySQL v5.
 IDE de développement : 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 l’application
Nous exposerons quelques interfaces de notre application, en essayant à chaque fois de décrire
les différents objets interactifs mis à la disposition de l’utilisateur.
4.4.1 Interface d’authentification :
Lors de lancement de l’application, une interface d’authentification apparaît mentionnant le
nom de l’application et l’entreprise. Ensuite le client est invité à s’authentifier en saisissant ses
paramètres d’accès (Figure 4.1).

24. 24
Figure 5.1 : interfaces authentification
4.4.2 Menu principale
C’est la fenêtre principale après l’authentification, cette page représente tout ce que l’utilisateur
peut faire. C’est une interface de transition où le client doit choisir entre gérer les utilisateurs,
gérer les contrôleurs ou gérer les tests.
Figure 4.2 interfaces Menu Principale

25. 25
4.4.3 Interface gestion des contrôleurs
Ici, l’utilisateur peut ajouter un autre contrôleur, il doit donc saisir les nouvelles informations
de ce dernier, ces informations doivent être forcément convenables sinon un message d’erreur
de saisie sera apparu.
A partir de cette fenêtre, l’utilisateur peut aussi basculer vers les autres boutons pour effectuer
d’autres tâches, telle que modification, suppression, consultation…
 Messages d’erreurs :
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 contrôleurs
Figure 4.4 Message d'erreur : Le contrôleur existe déjà

26. 26
 Messages de confirmation :
4.4.4 Sous menu gestion des tests
Dans ce sous menu, l’utilisateur chois de gérer soit un test anglais, soit un test d’aptitude
médicale.
Figure 4.8 Sous menu
4.5 Conclusion
Dans ce chapitre nous avons détaillé les technologies utilisées pour la réalisation de notre projet
ainsi que les fonctionnalités de base de l’application à travers un ensemble de captures d’écran.
Figure 4.5 Figure 4.6Figure 4.6 Message de confirmation : Suppression Figure 4.7 Message de confirmation : Quitter

27. Ecole Nationale d’Ingénieurs de Tunis Stage ingénieur
27
L’objectif de ce projet était de concevoir et développer une application de gestion des licences
des contrôleurs aériens.
Pour la conception de notre application, nous avons eu recours à l’UML. Cette approche nous
a permis de bien comprendre la problématique et de bien modéliser les objectifs à atteindre. Ce
qui nous a donné la possibilité de réaliser un système stable et évolutif.
Le projet s’est déroulé selon trois axes principaux afin de passer par les étapes essentielles de
tout projet : l’analyse, la conception et la réalisation. Pour la réalisation, nous avons utilisé Java
comme langage de programmation et MySQL v5 comme système de gestion de base de
données.
L’expérience au sein d’un cadre professionnel, nous a été bénéfique. Ce stage nous a permis de
nous familiariser à la vie professionnelle, d’exploiter des notions fondamentales dans l’orienté
objet, et d’approfondir nos connaissances théoriques acquises à l’Ecole Nationale
d’Ingénieurs de Tunis.
Nous envisageons comme perspectives une amélioration de l’application qui la rendra plus
accessible. En effet, nous souhaitons la ramener en une application web J2EE et informer les
contrôleurs plutôt par SMS.

28. Ecole Nationale d’Ingénieurs de Tunis Stage ingénieur
28
[URL1] http://www.oracle.com : site officiel d’ORACLE : 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