Rapport de Stage

République Tunisienne
Ministère de l’Enseignement
Supérieur et de la Recherche
Scientifique Université
Méditerranéenne Libre Tunis
Ecole Polytechnique Méditerranéenne Privée Tunis
RAPPORT PROJET
Par
Bouraoui Ghayeth
Conception et Réalisation d’une application web de

Reporting & Statistics de Rejets de communication
entre Systèmes d’Information
Encadrant académique et professionnel : Hamadi Naoufel
Réalisé au sein TUNISIE TELECOM
Année Universitaire 2019 – 2020

Table des matières
Introduction générale ..................................................................................................... 1
Contexte général............................................................................................................ 4
Introduction ............................................................................................................... 5
1.1 Organisme d’accueil : TUNISIE TELECOM ................................................. 5
1.1.1 Histoire .......................................................................................................... 5
1.1.2 Activité .......................................................................................................... 6
1.1.1 Organisation structurelle de Tunisie Telecom................................................ 7
1.2 Contexte du projet.......................................................................................... 7
1.3 Etude et critique de l’existant ......................................................................... 8
1.4 Problématique .............................................................................................. 10
1.5 Solution proposée et objectifs globaux du projet .......................................... 10
1.6 Limite exigée de la solution ......................................................................... 10
1.7 Choix méthodologique ................................................................................. 11
1.7.1 Méthodes agiles ........................................................................................... 11
1.7.2 2TUP ........................................................................................................... 11
Conclusion .............................................................................................................. 13
Analyse et spécification des besoins ............................................................................ 14
Introduction ............................................................................................................. 15
2.1 Spécification des besoins ............................................................................. 15
2.1.1 Besoins fonctionnels .................................................................................... 15
2.1.2 Besoins non fonctionnels ............................................................................. 16
2.2 Identification des acteurs.............................................................................. 16
2.3 Diagrammes des cas d’utilisation et identification des scénarios................... 17
2.3.1 Diagramme global des cas d’utilisation ........................................................ 17
2.3.2 Cas d’utilisation « Afficher les statistiques » ................................................ 18
2.3.3 Cas d’utilisation « Générer des rapports » .................................................... 19

2.3.4 Cas d’utilisation « Gérer un profil » ............................................................. 20
2.3.5 Cas d’utilisation « Gérer les rejets » ............................................................. 23
2.3.6 Cas d’utilisation « Gérer les utilisateurs » .................................................... 25
2.3.7 Cas d’utilisation « Injecter les rejets » .......................................................... 28
2.3.8 Cas d’utilisation « Supprimer tous les rejets » .............................................. 29
Conclusion .............................................................................................................. 30
Conception et choix technologiques............................................................................. 31
Introduction ............................................................................................................. 32
3.1 Conception détaillée .......................................................................................... 32
3.1.1 Modélisation statique : diagramme de classes .............................................. 32
3.1.2 Modélisation dynamique .............................................................................. 34
3.2 Conception architecturale............................................................................. 41
3.2.1 Diagramme de déploiement ......................................................................... 41
3.2.2 Architecture logique .................................................................................... 42
3.3 Choix technologiques................................................................................... 44
3.3.1 Côté serveur ................................................................................................. 44
3.3.2 Côté client ................................................................................................... 45
Conclusion .............................................................................................................. 46
Réalisation .................................................................................................................. 47
Introduction ............................................................................................................. 48
4.1 Environnement de travail ............................................................................. 48
4.1.1 Environnement matériel ............................................................................... 48
4.1.2 Environnement logiciel ................................................................................ 48
4.2 Phase d’implémentation ............................................................................... 51
4.2.1 Authentification ........................................................................................... 52
4.2.2 Le menu principal ........................................................................................ 52
4.2.3 L’onglet « Accueil » .................................................................................... 52
4.2.4 L’onglet « Rejets »....................................................................................... 53

4.2.5 L’onglet « Générer Rapport » ...................................................................... 56
4.2.6 L’onglet « Utilisateurs » .............................................................................. 57
4.2.7 L’onglet « Paramètres » ............................................................................... 60
4.2.8 L’option « Déconnexion » ........................................................................... 60
Conclusion .............................................................................................................. 60
Conclusion générale .................................................................................................... 61
Webographie ............................................................................................................... 63
Annexes ...................................................................................................................... 65
Annexe 1. Interfaces finales ..................................................................................... 66
1. Interface d’authentification .............................................................................. 66
2. Interface de modification les paramètres d’un profil ........................................ 67

Table des Figures
Figure 1. Organigramme TUNISIE TELECOM .......................................................... 7

Figure 2. Cycle de développement 2TUP................................................................... 13
Figure 3. Diagramme des cas d’utilisation globale ..................................................... 17
Figure 4. Diagramme de cas d’utilisation « Afficher les statistiques »........................ 18
Figure 5. Diagramme de cas d’utilisation « Générer des rapports » ............................ 19
Figure 6. Diagramme de cas d’utilisation « Gérer un profil » ..................................... 21
Figure 7. Diagramme de cas d’utilisation « Gérer les rejets »..................................... 23
Figure 8. Diagramme de cas d’utilisation « Gérer les utilisateurs » ............................ 25
Figure 9. Diagramme de cas d’utilisation « Injecter les rejets ».................................. 28
Figure 10. Diagramme de cas d’utilisation « Supprimer tous les rejets » .................... 29
Figure 11. Diagramme de Classes.............................................................................. 33
Figure 12. Diagramme de séquence du scénario « S'authentifier » ............................. 35
Figure 13. Diagramme de séquence du scénario « Afficher les statistiques » ............. 36
Figure 14. Diagramme de séquence du scénario « Afficher les rejets » ...................... 36
Figure 15. Diagramme de séquence du scénario « Supprimer un rejet » ..................... 37
Figure 16. Diagramme de séquence du scénario « Injecter les rejets » ....................... 37
Figure 17. Diagramme de séquence du scénario "Générer des rapports" .................... 38
Figure 18. Diagramme de séquence du scénario « Afficher les utilisateurs ».............. 38
Figure 19. Diagramme de séquence du scénario « Ajouter un utilisateur » ................. 39
Figure 20. Diagramme de séquence du scénario « Supprimer un utilisateur » ............ 39
Figure 21. Diagramme de séquence du scénario « Consulter un profil » .................... 40
Figure 22. Diagramme de séquence du scénario "Modifier un profil" ........................ 41
Figure 23. Diagramme de déploiement ...................................................................... 42
Figure 24. Architecture MVC .................................................................................... 43
Figure 25. Interface graphique de Power AMC .......................................................... 49
Figure 26. Interface graphique d'Eclipse .................................................................... 50
Figure 27. Interface graphique de SQL Server ........................................................... 51
Figure 28. Le menu principal de l'application ............................................................ 52
Figure 29. La page d’accueil de l’application............................................................. 53
Figure 30. L'onglet Rejets dans un compte "Admin" .................................................. 54
Figure 31. L'onglet Rejets dans un compte "User" ..................................................... 54
Figure 32. Choisir le fichier CSV .............................................................................. 55
Figure 33. Après la sélection du fichier CSV ............................................................. 55
Figure 34. L'ajout des données dans la base ............................................................... 55
Figure 35. Supprimer un seul rejet ............................................................................. 56
Figure 36. L'onglet "Générer Rapport" ...................................................................... 56
Figure 37. Le message de l’emplacement du rapport ................................................. 56
Figure 38. L'onglet "Utilisateurs" dans un compte Admin ......................................... 57
Figure 39. L'onglet "Utilisateurs" dans un compte User ............................................. 57
Figure 40. Informations d'un utilisateur ..................................................................... 58
Figure 41. Message d'erreur lors d'un utilisateur introuvable ...................................... 58
Figure 42. Un message d'ajout d'un nouvel utilisateur ................................................ 59
Figure 43. Un message d'erreur si l'un ou tous les champs sont vide .......................... 59
Figure 44. Message de déconnexion .......................................................................... 60
Table des Tableaux
Tableau 1. Description du cas d’utilisation "Afficher les statistiques" ........................ 19

Tableau 2. Description du cas d’utilisation "Générer des rapports" ............................ 20
Tableau 3. Description du cas d’utilisation « Consulter un profil » ............................ 22
Tableau 4. Description du cas d’utilisation « Modifier un profil ».............................. 23
Tableau 5. Description du cas d’utilisation « Consulter la liste des rejets » ................ 24
Tableau 6. Description du cas d’utilisation « Supprimer un rejet »............................. 25
Tableau 7. Description du cas d’utilisation « Consulter la liste des utilisateurs »........ 26
Tableau 8. Description du cas d’utilisation « Ajouter un utilisateur »......................... 27
Tableau 9. Description du cas d’utilisation « Supprimer un utilisateur » .................... 27
Tableau 10. Description du cas d’utilisation « Injecter les rejets » ............................. 29
Tableau 11. Description du cas d’utilisation « Supprimer tous les rejets » ................. 30
INTRODUCTION GENERALE
Introduction Générale
Depuis l’antiquité, l’Homme n’a pas cessé de chercher les différents moyens pour faire
véhiculer le message à son correspondant et donc pour communiquer.
Ainsi, l’être humain, à travers ces époques successives, a fourni ses efforts intellectuels
aussi bien que physiques afin de découvrir des méthodes de communications adéquates.
Au début du XXème siècle, une réelle révolution pour les télécommunications s’amorce:
Celle de l’électronique. Cette époque est caractérisée par l’invention des composants et circuits
électroniques de base et de bonne qualité qui ont poussé les télécommunications vers les réseaux
informatiques. Ces évolutions ont donné naissance à d’autres technologies de communications
telles que la radio messagerie, le téléphone mobile et les réseaux de fibre optique et enfin
Internet.
Cependant, l’ensemble de ces réseaux évolués utilise à la base un réseau très important
pour acheminer les données indépendamment du codage et de la nature des signaux : Le réseau
téléphonique commuté ou RTC (réseau d’abonnés) ainsi depuis la création de l’entreprise
Tunisie Télécom, le nombre de demandes d’abonnements téléphoniques ne cesse de sur-croître,
plusieurs cellules de production exercent un travail convenable et spécifique pour accomplir
une tâche bien précise. Cela afin de satisfaire les exigences de sa clientèle.
Tunisie Télécom pour garantir la bonne qualité de service et pour assurer le bon
fonctionnement du travail au sein ses différentes directions et agences utilisent plusieurs
Systèmes d’Informations et chaque système utilise un Système de Gestion de Bases de Données
différent, pour cela ces différents SI rencontrent des problèmes de rejets pendant la
communication entre eux.
Dans le cadre de nos études au sein de l’EPMPT et en vue de l’obtention du diplôme

national d’ingénieur en Informatique Décisionnelle nous avons réalisé notre stage de projet au
sein de TUNISIE TELECOM. Notre objectif est de contribuer pour mettre en place une Solution
BI pour le traitement des rejets de communication entre les différents SI de TUNISIE
TELECOM.
Le présent rapport s’articule autour de quatre chapitres.
Le premier chapitre « Contexte général » consiste à présenter le cadre général du projet.

Ce chapitre contient une présentation de l’organisme d’accueil, une idée globale sur le sujet
avec une étude bibliographique ainsi qu’une étude de l’existant et la solution proposée.
2
Introduction Générale
Le deuxième chapitre « Analyse et spécification des besoins » sera consacré à l’analyse

et aux spécifications des besoins ainsi qu’à la conception de la solution. Pour cela, nous avons
eu recours aux diagrammes de cas d’utilisation UML.
Le troisième chapitre « Conception et choix technologiques » consiste à exposer la

conception du système à travers une présentation de l’architecture utilisée, diagrammes de
classes et des diagrammes de séquences et nous clôturons le chapitre par les choix
technologiques.
Le dernier chapitre « Réalisation » sera dédié à une description des détails de

l’implémentation : nous citerons tout d’abord les outils de développement. Puis nous
exposerons quelques interfaces de l’application.
Le rapport se termine par une conclusion générale qui synthétise le travail réalisé et
présente les perspectives futures à envisager.
3
Chapitre 1
CONTEXTE GENERAL
Plan
1 Organisme d’accueil ................................................................................................... 5
2 Contexte du projet ....................................................................................................... 7
3 Étude et critique de l’existant ...................................................................................... 8
4 Problématique ........................................................................................................... 10
5 Solution proposée et objectifs globaux du projet ......................................................... 10
6 Limite exigée par l’entreprise .................................................................................... 10
7 Choix méthodologique .............................................................................................. 11
Chapitre 1. Contexte général
Introduction
Dans ce chapitre nous allons présenter l’organisme d’accueil et ses principales activités.
Ensuite, nous décrirons le contexte du projet. Nous clôturons par une étude de l’existant menant
à une description, une critique de l’existant et la présentation de la solution proposée.
1.1 Organisme d’accueil : TUNISIE TELECOM
1.1.1 Histoire
La loi portant création de l'Office National des Télécommunications, dont le nom

commercial est Tunisie Télécom, est promulguée le 17 avril 1995 et entre en vigueur le
1er janvier 1996. Devenu société anonyme de droit public fin 2002, il change de statut juridique,
par un décret du 5 avril 2004, pour devenir une société anonyme dénommée « Tunisie Télécom
». Elle connaît une privatisation partielle en juillet 2006 avec l'entrée dans son capital, à hauteur
de 35 %, de consortium émirati ETI (Emirates International Telecommunications).
Tunisie Télécom met en place, exploite et commercialise le premier réseau GSM en

Mauritanie (Mattel) à partir de mai 2000. Elle conclut également une convention de coopération
technique avec Djibouti Télécom pour le développement de ses réseaux de télécommunications.
À partir de 2008, Tunisie Télécom offre la possibilité aux détenteurs de cartes bancaires
nationales d'alimenter le solde de leurs lignes prépayées via les distributeurs automatiques de
billets de l'Arab Tunisian Bank (service Mobilink).
Le 21 mars 2009, Tunisie Télécom lance une nouvelle marque, Elissa, avec des offres
spécifiquement conçues pour les jeunes de moins de 25 ans ; après elle devient accessible à tous
sans limite d'âge dès le 10 mars 2012.
Au printemps 2011, à la suite de la révolution tunisienne, la société est secouée par un
important conflit social entre les représentants de l'Union générale tunisienne du travail et ceux
de son actionnaire émirati au sujet du sort d'une soixantaine de contractuels (sur 8 500
employés) représentant 3,5 % de la masse salariale ; il est marqué par des grèves et sit-in
affectant le bon fonctionnement de l'opérateur. Il s'achève avec la fin de ces contrats de travail,
à l'exception de dix contractuels gardant leurs fonctions. [1]
C’est une société semi-étatique chargée d’assurer les communications en Tunisie. Elle
a pour mission d’assurer les activités relatives au domaine des télécommunications :
5
- La prestation des services fournis par les réseaux publics de télécommunications.

- L’installation, le développement, l’entretien et l’exploitation des réseaux publics de
télécommunications.
- La participation à l’effort national d’enseignement supérieur au niveau du secteur des
télécommunications et des organisations internationales spécialisées dans le domaine
des télécommunications.
- La contribution au développement des études et des richesses scientifiques liées au
secteur des télécommunications.
1.1.2 Activité
Tunisie Télécom propose des services dans le domaine des télécommunications fixes et
mobiles. En juin 2006, il est fort de 1 259 000 abonnés au réseau fixe (RTCP), dont il détient le
monopole, et de 3 265 000 abonnés au réseau GSM, la première ligne ayant été inaugurée le 20
mars 1998. Avec une part de marché de 35,4 % en décembre 2014 sur le marché de la téléphonie
mobile, Tunisie Telecom est le second plus gros opérateur mobile du pays, derrière Ooredoo,
leader avec 45,7 % de part de marché. L’opérateur historique affiche en 2014 un taux de
croissance mensuel moyen de 4,2 %, ce qui lui a permis de franchir la barre des cinq millions
d’abonnements.
Tunisie Télécom est également un fournisseur d'accès à Internet (Frame Relay,
ADSL, X.25, LS, RNIS et WLL pour la téléphonie rurale). [2]
En novembre 2014, Tunisie Télécom signe un partenariat avec le groupe Khechine qui
consiste pour l'entreprise de télécom d'offrir des avantages sur les services du groupe de
tourisme, en échange d'une offre de télécommunication avantageuse pour les établissements
hôteliers et touristiques du groupe Khechine.
6
1.1.1 Organisation structurelle de Tunisie Telecom
PDG
Directeur
Affaires
Regionale
Commerciale Service Reseaux SAAF R.H
Gestion
Assurance Planification &
Ventes Actel Moyens previsionelle
qualite clients Ingenerie du personelle
Support
Vente Deploiement
CSC Achats administratif &
des reseaux
sociale
Distrubution Energie &

ances Formations
indirecte Environment
Marketing Optimisation
& qualite Juridique
support materielle
ROCS
Figure 1. Organigramme TUNISIE TELECOM
1.2 Contexte du projet
Tous les systèmes modernes fournissent les informations sous forme des tableaux de
bord, en anglais « Dashboard », pour aider à gérer des situations anormales et informer
l’utilisateur en temps réel et aussi bien lui donne la possibilité de générer des rapports sous
différents formes.
Le tableau de bord est un outil d’aide à la décision très important et il remplit notamment
les rôles suivants :
 C’est un système d’alerte et également d’actions : il permet de prendre les
mesures nécessaires lorsque des écarts sont détectés entre ce qui est prévu et ce qui se passe
réellement,
7
 C’est un moyen d’apprentissage car nous permet de tirer des conclusions sur les
écarts constatés et les actions mises en place pour corriger le problème,
 Enfin, il nous permet également de se projeter en avant et d’avoir ainsi des
informations pour établir ses prévisions.
Le tableau de bord nous permet donc d’être réactif en cas de problème et de prendre des
décisions en s’appuyant sur des éléments objectifs.
Aussi que la génération des rapports à partir des données d’une base de données
relationnelle nous offre la possibilité d’avoir des documents, sous différentes formes, qui
contiennent les informations nécessaires selon des critères bien précises pour guider l’utilisateur
et lui faciliter son travail sans d’être besoin des méthodes classiques pour extraire les données.
Dans ce contexte s’inscrit notre projet qui consiste à concevoir et développer une application
web de statistiques et de reporting des rejets de communication. Il est réalisé dans le cadre
d’un projet en vue de l’obtention du diplôme national d’ingénieur en
informatique.
1.3 Etude et critique de l’existant :
Comme nous avons dit précédemment que l’entreprise utilise plusieurs SI, chacun d’eux
utilise un SGBD différent, et pour se faire communiquer ensemble ces derniers utilisent des
web services.
Les Systèmes d’Informations de Tunisie Telecom : Chaque SI est implémenté dans

un système d’exploitation et utilise un système de gestion des bases de données.
BSCS : Ce SI est conçu pour la facturation client Grand Public (résidentiel).

 OS : Solaris.
 SGBD : Oracle.
FTD : C’est un SI conçu pour la facturation Grand Compte (professionnel).
 OS : Linux.
 SGBD : Oracle.
Workflow Back Bône : Ce système d’informations est pour la manipulation des
coordonnées techniques des réservations data.
 OS : Windows.
 SGBD : SQL Server.
8
GIS : Est un SI a comme rôle la manipulation des coordonnées techniques du réseau

local d’abonnés.
 OS : AX.
 SGBD : Informix.
HPSM : Un SI conçu pour la manipulation des réclamations et pour l’accès aux données
professionnels.
 OS : Windows.
 SGBD : Oracle.
CRM : Un SI conçu pour la manipulation des réclamations et pour l’accès aux données
résidentiels.
 OS : Linux.
 SGBD : Oracle.
Les différents SI de TUNISIE TELECOM se communiquent entre eux avec des web
services, mais il existe des défaillances lors de la communication pour cela des rejets de
communication se produisent. Ces derniers s’enregistrent dans les fichiers log de chaque SI.
Les fichiers log : Ou encore en français « Les journaux d'évènements » sont des fichiers
textes enregistrant de manière chronologique les évènements exécutés par un serveur ou une
application informatique. Un contenu qu'il faut savoir déchiffrer. Chaque action d'un système
informatique (ouverture d'une session, installation d'un programme, navigation sur Internet...)
produit un fichier log. Ces fichiers textes listent chronologiquement les évènements exécutés.
Ils s'avèrent utiles pour comprendre la provenance d'une erreur en cas de bug.
Ils permettent également d'établir des statistiques de connexions à un site Web ou à un

serveur, grâce à des outils comme WebAlizer ou Webtrends. L'analyse des fichiers logs peut se
faire manuellement, mais les logs ne sont pas aisés à déchiffrer, et les outils d'analyse
fournissent la plupart des informations nécessaires.
S'agissant d'un serveur Web, un fichier log va enregistrer la date et l'heure de la tentative
d'accès, l'adresse IP du client, le fichier cible, le système d'exploitation utilisé, le navigateur, la
réponse du serveur à cette requête, éventuellement le type d'erreur rencontré...
La journalisation applicative consiste à enregistrer les opérations de la logique métier
pendant le fonctionnement d'une application. Un journal applicatif fait partie de la logique
applicative.
9
La journalisation du système enregistre les évènements survenants au niveau des

composants du système. Il est possible de filtrer les évènements par catégories de gravité, en
paramétrant la journalisation (erreurs, débogage, alertes...). Les systèmes Unix utilisent le
protocole Syslog pour mettre en œuvre la journalisation système. Les logs de Windows se
trouvent dans le dossier System32. [3]
Les données extraites des fichiers logs générés lors de la communication interservices
des différents SI de Tunisie Telecom enregistrés dans les fichiers sont récupérés et enregistrés
dans une table d’une base de données SQL Server.
Pour extraire les informations à partir des données enregistrées dans la base de données
et manipuler ces dernières nous avons que les requêtes SQL classiques écrites dans l’interface
de requêtes de SQL Server et les informations seront affichées dans le console de ce dernier.
1.4 Problématique
L’étude et la critique de l’existant nous a mené à la problématique suivante :

 Est-il possible d’avoir un outil ou une solution qui a pour but d’extraire toutes
les informations nécessaires pour faciliter la résolution du problème des rejets de
communication entre les différents SI en un simple clic ?
 Est-il possible d’exploiter les statistiques observées et les rapports générés pour
faire l’analyse afin d’avoir plus d’informations sur les sources des rejets de communication ?
1.5 Solution proposée et objectifs globaux du projet
La solution proposée se base sur la conception et le développement d’une solution pour

classifier et organiser les différents types de rejets de communication, entre les différents SI de
l’entreprise, par la génération des rapports et des statistiques pour ces rejets ; afin de faciliter le
travail de technicien et l’aider à prendre une décision adéquate comment résoudre ces
défaillances.
1.6 Limite exigée de la solution
Afin de développer notre solution nous n’avons pas le droit de communiquer

directement avec la base de données, où se trouve la table des rejets, nous n’avons que de
consulter des fichiers CSV et injecter les données dans la base de notre solution.
10
1.7 Choix méthodologique
1.7.1 Méthodes agiles
Les méthodes agiles sont une approche de gestion de projet. Elles se basent sur un cycle
de développement qui positionne le client au centre et qui génère un produit de haute qualité
tout en prenant en compte le changement et l’évolution de ses besoins.
Afin de bien expliquer cette notion, nous allons énoncer ces principes, ses objectifs et
ses rapports avec les modèles classiques. La méthode agile favorise :
Les individus et les interactions plutôt que les processus et les outils : les personnes sont
les points forts des méthodes agiles en favorisant largement les interactions. En d’autres termes,
cette approche est menée dans un esprit collaboratif avec le nécessaire de formalisme.
Les fonctionnalités opérationnelles plutôt que la documentation exhaustive : cette
approche recommande que la livraison du produit final doive être à des intervalles définis. Dans
ce sens se manifeste la notion de développement itératif et d’intégration continue. Une itération
n’est terminée que lorsqu’elle réussit tous les tests.
La collaboration et la communication avec le client plutôt que la contractualisation des
relations : Cette valeur est favorisée en tenant compte que le client est essentiel à la réussite et
en établissant une collaboration étroite entre lui et l’équipe de développement.
Le changement et l’évolution plutôt que le suivi et la conformité aux plans : Les
méthodologies agiles accordent une grande importance aux changements réguliers en fonction
des commentaires du client. Elles exploitent les évolutions pour donner un avantage compétitif
au client [4].
1.7.2 2TUP
Nous avons choisi d’utiliser la méthodologie agile vue sa compétence de s’adapter

facilement aux changements et vue que les méthodologies classiques sont prédictives. Comme
son nom l’indique, il faut prévoir des phases séquentielles où il faut valider l’étape précédente
pour passer à la deuxième.
Il existe plusieurs méthodes agiles, nous citons SCRUM, Rapid Application
Development (RAD), eXtreme Programming (XP), etc.
Notre choix s’est porté vers la méthode 2TUP vu que notre projet est basé sur un
processus de développement bien défini qui va de la détermination des besoins fonctionnels
attendus du système jusqu’à la conception et le codage final. Ce processus se base sur le
11
Processus Unifié (Unified Process) qui est devenu un standard général réunissant les meilleures
pratiques de développement.
Cette méthode ne se base pas sur un processus linéaire mais bien, sur un développement
itératif et incrémental.
Le processus 2TUP apporte une réponse aux contraintes de changement continuel
imposées aux systèmes d’information de l’entreprise. En ce sens, il renforce le contrôle sur les
capacités d’évolution et de correction de tels systèmes. 2TUP est un processus unifié qui suit
deux chemins.
Il s’agit des « chemins fonctionnels » et « d’architecture technique », qui correspondent
aux deux axes de changement imposés au système d’information. Ces changements peuvent
être traités parallèlement suivant un axe fonctionnel et un axe technique.
 Le premier axe vise à capturer des besoins fonctionnels, durant cette phase nous
avons défini la frontière fonctionnelle entre le système et son environnement et les activités
attendues des différents utilisateurs par rapport au système. Ensuite nous avons étudié
précisément les spécifications fonctionnelles de manière à obtenir une idée de ce que va réaliser
le système en termes de métier.
 Le second axe vise à capturer des besoins techniques, durant cette phase nous
avons validé nos choix technologiques pour la conception du système. Les outils et le matériel
sélectionnés ainsi que la prise en compte des contraintes d’intégration avec l’existant. Ensuite
nous avons défini les composants nécessaires à la construction de l’architecture technique. Cette
conception est complètement indépendante des aspects fonctionnels. Elle permet de générer le
modèle de conception technique qui définit les Frameworks [5].
 Les deux branches se fusionnent ensuite pour obtenir un processus sous forme
Y comme illustré dans la figure 2. [5] :
12
Figure 2. Cycle de développement 2TUP
En effet, une entreprise qui maintiendrait son modèle fonctionnel comme dans notre cas
elle peut le réaliser sous différentes technologies donc il suffit d’ajouter une nouvelle
architecture technique pour mettre à jour un système existant.
Après avoir présenté le choix de méthodologie de développement, il faut répertorier les
tâches à accomplir suivant les dates auxquelles ces tâches doivent être effectuées afin de mener
notre projet à bien.
Conclusion
Dans ce chapitre nous avons décrit l’organisme d’accueil en représentant le contexte,

les différents SI existants, et la problématique du projet. Nous avons par la suite présenté la
solution à mettre en place et limites exigées par l’entreprise.
Une spécification des besoins s’avère indispensable pour dégager les principales
fonctionnalités que nous devons assurer. Ça sera l’objectif du chapitre suivant.
13
Chapitre 2
ANALYSE ET SPECIFICATION DES

BESOINS
Plan
1 Spécification des besoins........................................................................................... 15
2 Identification des acteurs du système ......................................................................... 16
3 Diagrammes des cas d’utilisation et identification des scénarios ................................ 17
Chapitre 2. Analyse et spécification des besoins
Introduction
Après avoir présenté les différentes notions relatives à notre projet, nous passons dans
ce chapitre à la phase de spécification et d’analyse des besoins qui constitue une étape
déterminante dans la réalisation du notre projet. Nous procédons, tout d’abord, à l’identification
des acteurs. Nous passons, ensuite, aux diagrammes des cas d’utilisation. Nous finirons par
l’identification des scénarios.
2.1 Spécification des besoins
La spécification des besoins est nécessaire pour le développement d’une application. La

phase de spécification est la traduction des besoins des utilisateurs en documentations
conceptuelles et techniques. Il s’agit de définir les besoins fonctionnels et non fonctionnels de
l’application ainsi que les cas d’utilisation proposés par le sujet pour mettre le raisonnement
conceptuel en valeur.
2.1.1 Besoins fonctionnels
La définition des besoins fonctionnels consiste à définir les fonctionnalités du système.
Les besoins des utilisateurs sont recueillis et exprimés et seront ensuite regroupés et traduits en
termes de cas d’utilisation. L’ensemble des cas d’utilisation constitue les spécifications du
système.
Ainsi, le système doit permettre de :
 Injecter les données : cette phase sert à charger les données dans une base de données
relationnelle depuis un fichier CSV.
 Gérer les rejets : cette fonctionnalité consiste à
 Consulter la liste des rejets.
 Supprimer des rejets
 Générer les rapports : cette fonctionnalité a pour but de générer des rapports sous deux
formes PDF et HTML pour les rejets de communication entre les SI selon des critères
bien choisis.
 Afficher les statistiques : cette fonctionnalité c’est pour l’affichage des statistiques
pour ces rejets selon des critères. Les résultats seront affichés sous forme des graphes.
 Gérer un profil : cette phase a pour but
 Consulter un profil
 Modifier un profil
15
 Gérer les utilisateurs : cette fonctionnalité sert à

 Ajouter des utilisateurs
 Supprimer un utilisateur
 Consulter la liste des utilisateurs et leurs informations
2.1.2 Besoins non fonctionnels :
Les besoins non fonctionnels caractérisent les propriétés de l’application, les contraintes
d’environnement et d’implémentation, les capacités de maintenance, l’extensibilité et la
fiabilité.
Une première analyse des conditions d’exploitation souhaitées nous a permis
d’identifier les besoins non fonctionnels décrits ci-après :
 Ergonomie : Assurer la discipline de l’adéquation entre l’utilisateur et l’application
pour que cette dernière soit adaptée aux caractéristiques de l’homme en employant des
icones.
 Convivialité : Eliminer la complexité et diminuer le taux d’erreurs afin de faciliter
l’utilisation de l’application en dirigeant l’utilisateur vers l’action qu’il faut faire et les
données qu’il faut fournir à l’application (l’insertion du calendrier des dates, les listes
déroulantes).
 Efficacité : Fournir les résultats les plus performants qui répondent aux besoins de
l’utilisateur.
 Portabilité : La capacité de fonctionner dans différents environnements sans exiger des
contraintes matérielles spécifiques.
 Fiabilité : L’application doit exécuter correctement : toute information qui lui est
retournée doit être certaine (la crédibilité de la source des données).
2.2 Identification des acteurs
Pour illustrer les fonctionnalités offertes par notre système, nous avons opté pour le
diagramme des cas d’utilisation. Ce diagramme donne une vue sur les fonctionnalités de notre
système ainsi que les acteurs qui l’utilisent. Un acteur est l’idéalisation d’un rôle joué par une
personne externe, un processus qui interagit avec un système.
Les acteurs de notre application sont :
 L’utilisateur qui va afficher des statistiques, générer des rapports, supprimer des
rejets et consulter son profil ainsi que modifier les données de son profil.
16
 L’administrateur qui possède les mêmes rôles qu’un simple utilisateur avec la
gestion des utilisateurs et l’injection des données.
2.3 Diagrammes des cas d’utilisation et identification des scénarios
Après avoir identifié les différents besoins de notre projet, Il faut les traduire par des
diagrammes des cas d’utilisation. Ces diagrammes permettent de mettre en évidence les
relations fonctionnelles entre les acteurs et le système étudié. En effet, ils permettent de donner
une vue globale sur les fonctionnalités de notre application.
2.3.1 Diagramme global des cas d’utilisation
Nous commençons par présenter le diagramme des cas d’utilisation global pour avoir
une vue générale sur notre système. Ensuite, nous passons aux détails avec la description des
principaux cas d’utilisation.
La figure 3 montre le diagramme global des cas d’utilisation de notre application :
Figure 3. Diagramme des cas d’utilisation globale
17
Dans ce qui suit, nous allons détailler les différents cas d’utilisation utilisés dans ce
diagramme.
2.3.2 Cas d’utilisation « Afficher les statistiques »
2.3.2.1 Diagramme du cas d’utilisation
La figure suivante présente le diagramme de cas d’utilisation : « Afficher les

statistiques»
Figure 4. Diagramme de cas d’utilisation « Afficher les statistiques »
2.3.2.2 Identification du scénario
Ce cas permet à l’utilisateur d’afficher des courbes et des graphes qui donnent une vision
sur les données enregistrées dans la table « rejet », afin que ce dernier puisse conclure quelle
est la cause de rejet de communication et lui aide à prendre une décision comment résoudre ces
problèmes, selon des critères bien choisis dès le développement de l’application. Une
description détaillée du déroulement de cette opération est répertoriée dans le tableau suivant :
Cas d’utilisation « Afficher les statistiques »

Objectif Permettre à l’utilisateur d’afficher des statistiques sur les rejets.
Description Précondition(s) :
- La machine est connectée au réseau local de TUNISIE TELECOM.
- Lancer l’application.
- S’authentifier.
- Charger les rejets enregistrés dans la base de données.
18
Scénario :
- L’utilisateur s’authentifie.
- Il affiche l’onglet « Accueil ».
- les courbes et les graphes seront affichés automatiquement.
Postcondition(s) :
- Les statistiques sont affichées suivant les critères choisis dès le début.
Exception - Un message d’erreur s’affiche dans le cas où l’utilisateur a saisi des
paramètres d’authentifications incorrectes. Un message s’affiche « Mot
de passe ou login incorrecte ».
Tableau 1. Description du cas d’utilisation "Afficher les statistiques"
2.3.3 Cas d’utilisation « Générer des rapports »
La figure suivante présente le diagramme de cas d’utilisation : « Générer des rapports »
Figure 5. Diagramme de cas d’utilisation « Générer des rapports »
Ce cas permet à l’utilisateur de générer des rapports selon des critères bien choisis et
sous des formes différentes.
Le tableau suivant nous donne une description détaillée du déroulement de cette

opération :
19
Cas d’utilisation « Générer des rapports »

Objectif Permettre à l’utilisateur de générer des rapports sur les rejets.
- S’authentifier.
Scénario :
- Il affiche l’onglet « Générer Rapport ».
- Il clique sur le bouton « Générer Rapport ».
- Il génère le rapport sous la forme PDF ou HTML selon des critères
choisis.
Postcondition(s) :
- Les rapports générés seront enregistrés sur le disque dur sous le
répertoire C:\reports.
- Un message d’erreur s’affiche dans le cas où l’utilisateur génère un
rapport où un rapport similaire déjà généré est ouvert. Un message
s’affiche « Veuillez fermer le fichier sous le nom même nom avant ».
Tableau 2. Description du cas d’utilisation "Générer des rapports"
2.3.4 Cas d’utilisation « Gérer un profil »

La figure suivante présente le diagramme de cas d’utilisation : « Gérer un profil »
20
Figure 6. Diagramme de cas d’utilisation « Gérer un profil »
2.3.4.2 Identification du scénario « Consulter un profil »
Ce cas permet à l’utilisateur de consulter un profil et ses paramètres par la saisie de numéro
CIN de ce compte.
Une description détaillée du déroulement de cette opération est répertoriée dans le tableau
suivant :
Cas d’utilisation « Consulter un profil »

Objectif Permettre à l’utilisateur d’afficher les informations relatives à un profil
- S’authentifier.
- Charger les utilisateurs enregistrés dans la base de données.
Scénario :
- Il affiche l’onglet « Utilisateur ».
- Il saisit le N° CIN d’un utilisateur.
- Il clique sur le bouton « Consulter »
- Il affiche les informations relatives à un profil.
21
Postcondition(s) :
- les informations relatives à un profil seront affichées dans une nouvelle
interface.
- Un message d’erreur s’affiche dans le cas où l’utilisateur a saisi un
N°CIN inexistant. Un message s’affiche « Utilisateur introuvable ».
Tableau 3. Description du cas d’utilisation « Consulter un profil »
2.3.4.3 Identification du scénario « Modifier un profil »
Il permet à l’utilisateur de modifier un profil par la recherche par numéro CIN de ce

compte. Une description détaillée du déroulement de cette opération est répertoriée dans le
tableau suivant :
Cas d’utilisation « Modifier un profil »
Objectif Permettre à l’utilisateur d’afficher les informations relatives à un profil
et les modifier
- S’authentifier.
Scénario :
- Il affiche l’onglet « Paramètres ».
- Il saisit le N° CIN d’un utilisateur.
- Il clique sur le bouton « Valider »
- Il affiche les informations relatives à un profil.
- Il modifie ces informations.
- Il clique sur le bouton « Enregistrer les modifications »
- Il affiche un message « Les paramètres du profil sont modifiés »
Postcondition(s) :
- les informations relatives à un profil seront modifiés.
22

- Un message d’erreur s’affiche dans le cas où l’utilisateur a saisi un
N°CIN inexistant. Un message s’affiche « Utilisateur introuvable ».
Tableau 4. Description du cas d’utilisation « Modifier un profil »
2.3.5 Cas d’utilisation « Gérer les rejets »
La figure suivante présente le diagramme de cas d’utilisation : « Gérer les rejets »
Figure 7. Diagramme de cas d’utilisation « Gérer les rejets »
2.3.5.2 Identification du scénario « Consulter la liste des rejets »
Il permet à l’utilisateur de consulter la liste des rejets enregistrés dans la base de

données.
suivant :
Cas d’utilisation « Consulter la liste des rejets »
Objectif Permettre à l’utilisateur d’afficher la liste des rejets enregistrés dans la
base de données
23
- S’authentifier.
Scénario :
- Il affiche l’onglet « Rejets ».
- Il affiche la liste des rejets.
Postcondition(s) :
- Les utilisateurs sont affichés dans un tableau.
Tableau 5. Description du cas d’utilisation « Consulter la liste des rejets »
2.3.5.3 Cas d’utilisation « Supprimer un rejet »
Il permet à l’utilisateur de supprimer un rejet de la liste des rejets affichés dans la table
des rejets.
suivant :
Cas d’utilisation « Supprimer un rejet »
Objectif Permettre à l’utilisateur de supprimer un rejet de la liste des rejets
- S’authentifier.
Scénario :
- Il affiche la liste des rejets.
- Il choisit le rejet qui va supprimer
- Il clique sur le bouton « Supprimer »
-Il supprime le rejet.
24
Postcondition(s) :
- Le rejet se supprime de la liste des rejets affichés et de la base de
données.
Tableau 6. Description du cas d’utilisation « Supprimer un rejet »
2.3.6 Cas d’utilisation « Gérer les utilisateurs »
La figure suivante présente le diagramme de cas d’utilisation : « Gérer les utilisateurs »
Figure 8. Diagramme de cas d’utilisation « Gérer les utilisateurs »
2.3.6.2 Identification du scénario « Consulter la liste des utilisateurs »
Ce cas permet à l’administrateur d’afficher les informations des utilisateurs dans un

tableau.
Le tableau 7 détaille davantage la logique de cette opération :
Cas d’utilisation « Consulter la liste des utilisateurs »
Objectif Permettre à l’administrateur d’afficher les utilisateurs dans un tableau.
- S’authentifier.
25

Scénario :
- Il affiche l’onglet « Utilisateur ».
- Il affiche la liste des utilisateurs.
Postcondition(s) :
- Les utilisateurs sont affichés dans un tableau.
Tableau 7. Description du cas d’utilisation « Consulter la liste des utilisateurs »
2.3.6.3 Cas d’utilisation « Ajouter un utilisateur »
Ce cas permet à l’administrateur d’ajouter un nouvel utilisateur de l’application.

suivant :
Cas d’utilisation « Ajouter un utilisateur »
Objectif Permettre à l’administrateur d’ajouter, via un formulaire, un nouvel
utilisateur de l’application.
- S’authentifier.
Scénario :
- Il affiche l’onglet « Utilisateurs ».
- Il remplit le formulaire d’ajout.
- Il confirme l’ajout.
Postcondition(s) :
- L’utilisateur sera ajouté à la base.
26

- Un message d’erreur s’affiche en cas où l’administrateur tenté
d’ajouter un utilisateur existe déjà. Un message s’affiche « Utilisateur
existe déjà ».
Tableau 8. Description du cas d’utilisation « Ajouter un utilisateur »
2.3.6.4 Cas d’utilisation « Supprimer un utilisateur »
Ce cas d’utilisation permet l’administrateur de supprimer un utilisateur de la base de

données. Par conséquent, il ne sera plus affiché dans le tableau de l’onglet « Utilisateurs ».
suivant :
Cas d’utilisation « Supprimer un utilisateur »
Objectif Permettre à l’administrateur de supprimer un utilisateur de la liste des
utilisateurs.
- S’authentifier.
Scénario :
- Il affiche l’onglet « Utilisateurs ».
- Il choisit l’utilisateur qu’il veut supprimer.
- Il clique sur le bouton « Supprimer ».
Postcondition(s) :
- Un message de réussite de suppression s’affiche et l’utilisateur sera
supprimé de la liste des utilisateurs affichés dans le tableau.
Tableau 9. Description du cas d’utilisation « Supprimer un utilisateur »
27
2.3.7 Cas d’utilisation « Injecter les rejets »
La figure suivante présente le diagramme de cas d’utilisation : « Injecter les rejets »
Figure 9. Diagramme de cas d’utilisation « Injecter les rejets »
Il permet à l’administrateur d’injecter les rejets à partir un fichier CSV.
suivant :
Cas d’utilisation « Injecter les rejets »

Objectif Permettre à l’administrateur d’injecter les rejets dans la base de
données à partir d’un fichier CSV.
- S’authentifier.
Scénario :
- Il clique sur le bouton « Choisir un fichier ».
- Il parcourt le chemin.
- Il sélectionne le fichier choisi de type CSV.
- Il clique sur le bouton « Ajouter les données ».
28
Postcondition(s) :
- Un message de réussite de chargement des données du fichier dans la
base de données s’affiche et la liste des rejets sera affiché dans le
tableau.
- Un message d’erreur s’affiche dans le cas où l’utilisateur a choisi un
fichier sa taille dépasse 1 Mo « Taille du fichier supérieur à 1 Mo ».
Tableau 10. Description du cas d’utilisation « Injecter les rejets »
2.3.8 Cas d’utilisation « Supprimer tous les rejets »
La figure suivante présente le diagramme de cas d’utilisation : « Supprimer tous les

rejets »
Figure 10. Diagramme de cas d’utilisation « Supprimer tous les rejets »
Il permet à l’administrateur de supprimer tous les rejets enregistrés dans la base de

données en une seule fois.
suivant :
Cas d’utilisation « Supprimer tous les rejets »
Objectif Permettre à l’administrateur de supprimer tous les rejets en une seule
fois.
29
- S’authentifier.
Scénario :
- Il clique sur le bouton « Supprimer tous les rejets ».
Postcondition(s) :
- Un message de réussite de suppression des données s’affiche et la liste
des rejets sera vide.
Tableau 11. Description du cas d’utilisation « Supprimer tous les rejets »
Conclusion
Ce chapitre nous a permis de décerner les différents besoins fonctionnels et non

fonctionnels des acteurs de notre système. Nous avons fourni une analyse plus détaillée de ces
besoins avec les diagrammes de cas d’utilisation et la description de chaque cas.
Dans le chapitre suivant nous abordons la partie conception et nos choix technologiques.
30
Chapitre 3
CONCEPTION ET CHOIX
TECHNOLOGIQUES
Plan
1 Conception Détaillée ................................................................................................. 33
2 Conception architecturale .......................................................................................... 42
3 Choix technologiques ................................................................................................ 45
Chapitre 3. Conception et choix technologiques
Introduction
La conception est une étape décisive dans le cycle de développement de tout logiciel.
Son objectif est de définir l’architecture du système qui répond aux besoins et aux exigences
formulés.
Pour garantir ces objectifs, des diagrammes de classes et de séquence seront utilisés afin
de mieux expliquer les besoins déjà identifiés.
3.1 Conception détaillée
Il est temps d’entrer un peu dans les détails. Cette partie vise à représenter une
modélisation statique et dynamique de notre application.
3.1.1 Modélisation statique : diagramme de classes
Ce diagramme sera souvent utilisé pour présenter le design pattern, car il montre bien la
structure figée de la solution logicielle. Le diagramme de classes est le diagramme le plus
répandu dans les spécifications d’UML et il constitue un élément très important dans la
modélisation puisqu’il permet d’identifier les composants du système final et permet de
structurer le travail de développement d’une manière efficace. Après l’analyse de l’existant,
nous sommes parvenus à déterminer six classes particulières : Administrateur, Technicien,
Utilisateur, Roles, Rejet, Rapport. Nous présentons Ci-après le diagramme de classes :
32
Figure 11. Diagramme de Classes
33
Le diagramme précédent représente les classes que nous avons jugé importantes :
 Classe « Utilisateur » : Contient toutes les informations et les méthodes nécessaires pour
la gestion des utilisateurs.
 Classe « Administrateur » : est une classe fille de la classe « Utilisateur », pour cette
classe nous avons une méthode, qui est l’ajout d’un nouvel administrateur, en plus elle
va hériter tous les attributs et les méthodes de la classe mère.
 Classe « Technicien » : elle est aussi bien une classe fille de la classe « Utilisateur »,
elle a de même une méthode pour l’ajout d’un nouvel technicien plus les méthodes de
la classe mère et les attributs de cette dernière.
 Classe « Roles » : c’est une qui va associer à chaque utilisateur un rôle.
 Classe « Rejet » : cette classe contient tous les attributs d’un rejet et les méthodes
nécessaires pour manipuler les rejets.
 Classe « Rapport » : c’est une classe a comme rôle le contrôle de la phase de
« reporting » de notre application par les utilisateurs par ses attributs et ses méthodes.
3.1.2 Modélisation dynamique :
La modélisation statique permet de définir les attributs et les méthodes qui seront
manipulés au cours du développement de notre outil. Toutefois, elle ne peut pas décrire les
étapes du traitement, ni la logique suivie par chaque action. Dans cet objectif, nous allons
présenter l’aspect dynamique de notre application à travers la description de quelques scénarios.
Nous allons ici nous attarder sur les cas d’utilisation suivants :
 S’authentifier
 Afficher les statistiques
 Gérer les rejets
 Injecter les rejets
 Générer des rapports
 Gérer les utilisateurs
 Gérer un profil
34
3.1.2.1 Diagramme de séquence du scénario « S’authentifier »
Le cas d’utilisation « S’authentifier » est le cas clé de tous les autres cas car c’est le
point d’entrée à notre application. Pour cela nous avons commencé par décrire le scénario de
ce cas d’utilisation avec le diagramme de séquence suivant :
Figure 12. Diagramme de séquence du scénario « S'authentifier »
3.1.2.2 Diagramme de séquence du scénario « Afficher les statistiques »
Le cas d’utilisation « Afficher les statistiques » c’est la première fonctionnalité de notre

application qui s’affiche dans la page d’accueil. Le diagramme de séquence suivant nous décrire
le scénario « Afficher les statistiques ».
35
Figure 13. Diagramme de séquence du scénario « Afficher les statistiques »
3.1.2.3 Diagramme de séquence du scénario « Gérer les rejets »
Les rejets enregistrés dans la base de données dans notre application « Rejets Reporting
& Statistics » sont des informations primordiales pour la résolution du problème de rejet de
communication entre les différents SI de l’entreprise. Par conséquent, il est important d’assurer
une bonne gestion de ces rejets. Il s’agit en quelques sortes d’assurer un meilleur affichage au
superviseur et lui donner la main de supprimer le rejet qu’il a été résolu. Pour aboutir à ce
résultat, un enchainement d’actions et de traitements doit être effectué.
Nous présentons ci-après le premier diagramme de séquence « Afficher les rejets » et le
deuxième « Supprimer un rejet ».
Figure 14. Diagramme de séquence du scénario « Afficher les rejets »

36
Figure 15. Diagramme de séquence du scénario « Supprimer un rejet »
3.1.2.4 Diagramme de séquence du scénario « Injecter les rejets »
Parmi les fonctionnalités de notre application est l’injection des données, c’est une
fonctionnalité qui ne peut le faire qu’un administrateur du système.
La figure suivante c’est la description du scénario « Injecter les données » par le diagramme de
séquence.
Figure 16. Diagramme de séquence du scénario « Injecter les rejets »
37
3.1.2.5 Diagramme de séquence du scénario « Générer des rapports »
La génération des rapports est une fonctionnalité de notre application accessible à tous
les utilisateurs. La figure suivante illustre une description détaillée de ce scénario.
Figure 17. Diagramme de séquence du scénario "Générer des rapports"
3.1.2.6 Diagrammes de séquence du scénario « Gérer les utilisateurs »
Les utilisateurs se sont les acteurs principaux de notre application, nous avons deux
types d’utilisateurs « Administrateur » et « Utilisateur », seule l’administrateur peut gérer ces
utilisateurs. La figure suivante nous décrire le scénario « Afficher les utilisateurs ».
Figure 18. Diagramme de séquence du scénario « Afficher les utilisateurs »

38
Nous présentons ci-après les deux diagrammes de séquence du scénario « Ajouter un

utilisateur » et « Supprimer un utilisateur ».
Figure 19. Diagramme de séquence du scénario « Ajouter un utilisateur »
Figure 20. Diagramme de séquence du scénario « Supprimer un utilisateur »
39
3.1.2.7 Diagrammes de séquence du scénario « Gérer un profil »
Un utilisateur peut consulter un profil et le modifier. Dans les diagrammes suivants

nous allons décrire ces scénarios. Le premier diagramme est le scénario « Consulter un
profil » et le deuxième « Modifier un profil »
Figure 21. Diagramme de séquence du scénario « Consulter un profil »
40
Figure 22. Diagramme de séquence du scénario "Modifier un profil"
3.2 Conception architecturale
L’architecture d’une application est une perspective qui dépend du point de vue de son
développeur, en fonction des éléments qu’il recherche à mettre en évidence. La conception
donne une vue globale sur les principaux intervenants de l’application ainsi que la manière dont
ils sont liés. Nous détaillerons à la suite l’architecture adoptée pour notre application.
3.2.1 Diagramme de déploiement
Un diagramme de déploiement est une vue statique qui sert à représenter l’utilisation de
l’infrastructure physique par le système et la manière dont les composants du système sont
répartis ainsi que les relations entre eux. Pour bien mettre en place notre outil de reporting et
statistics des rejets, nous avons adopté l’architecture représentée dans la figure suivante :
41
Figure 23. Diagramme de déploiement
3.2.2 Architecture logique
Pour la réalisation de notre application « Rejets Reporting & Statistics » nous avons
choisi de suivre le modèle MVC (Model View Controller) vu qu’il répond le plus à nos besoins.
Ce modèle est un Patron de conception, son principe est de séparer la présentation, les
traitements et les données pour une meilleure cohérence de l’application et une plus grande
facilité de maintenance. La figure suivante montre l’architecture MVC :
42
Figure 24. Architecture MVC
 Modèle : Il représente les données et les règles métiers. C’est dans ce composant que
s’effectuent les traitements liés au cœur du métier. Les données peuvent être liées à une
base de données, des services web, etc.
 Vue : correspond à l’IHM. Elle présente les données et interagit avec l’utilisateur.
 Contrôleur : se charge d’intercepter les requêtes de l’utilisateur, d’appeler le modèle
puis de les rediriger vers la vue adéquate. Il ne doit faire aucun traitement. Il ne fait que
de l’interception et de la redirection.
L’approche MVC apporte de réels avantages. En effet, elle permet de transformer une
application en un dossier élaboré maintenable, modulable et rapide. Elaborer les tâches de
l’application en séparant les modèles, les vues et les contrôleurs, ce qui allège notre application.
De nouvelles fonctionnalités sont ajoutées facilement, et les améliorations des anciennes
fonctionnalités se font d’une manière simple et facile. La conception modulable et séparée
permet aussi aux développeurs et designers de travailler simultanément. Les changements
touchent seulement une partie de l’application sans affecter les autres.
Nous avons appliqué le modèle MVC dans notre projet au niveau du « front-end » avec
Bootstrap qui est un framework CSS puisqu’il embarque également des composants HTML et
JavaScript. Ce framework peut communiquer avec le « back-end » en utilisant les points
d’extrémité RESTful implémentés avec le framework Spring MVC.
43
 Modèle : Regroupe les opérations de lecture et d’écriture à partir de la base de données

au niveau du backend.
 Vues : Présente les pages HTML au niveau du frontend pour la représentation des
données.
 Contrôleur : Il invoque les méthodes de service appropriées en fonction de la méthode
GET ou POST utilisée. La méthode de service définira les données du modèle en
fonction de la logique définie. Dans notre projet c’est un « REST controller » réalisé
avec le framework Spring MVC au niveau du backend.
3.3 Choix technologiques

3.3.1 Côté serveur
Dans le coté serveur nous avons développé une application « Spring boot », ce «
framework » est conçu pour simplifier le démarrage et le développement de nouvelles
applications Spring. L’objectif de Spring Boot n’est pas d’apporter de nouvelles solutions pour
les nombreux problèmes qui ont déjà été résolus, mais plus d’influencer la plate-forme en
favorisant une expérience de développement qui simplifie l’utilisation de technologies déjà
existantes. Ceci fait de Spring Boot parmi les choix idéaux pour développer avec l’écosystème
Spring, mais aussi pour les nouveaux développeurs en leur permettant de maîtriser les
technologies de Spring de manière simplifiée. Spring Boot propose un ensemble de "starter"
modules, qui définissent des collections de dépendances qui peuvent être ajoutées au système
de build afin de résoudre les librairies spécifiques nécessaires pour le framework et sa plate-
forme [6].
Les modules utilisés dans notre application Spring Boot sont :
 Spring-security : fournit des services de sécurité complets pour les applications

JavaEE. Spring Security est un « framework » d’authentification et de contrôle d’accès
puissant et hautement personnalisable. La puissance réelle de Spring Security se trouve
dans la facilité avec laquelle il peut être étendu pour répondre aux exigences
personnalisées et il fournit une protection contre les attaques comme « session fixation
», « clickjacking », « cross site request forgery », etc [6].
 SpringWeb MVC : fournit une architecture MVC (Model-View-Controller) et des
composants prêts à utiliser pour développer des applicationsWeb flexibles et faiblement
couplées. Le modèle MVC permet de séparer les différents aspects de l’application, tout
en fournissant un couplage faible entre ces éléments [6].
44
 Spring data jpa : est l’un des framework de Spring reposant sur Spring-Data. Spring-
Data-JPA vise à améliorer la mise en œuvre de la couche d’accès aux données en
réduisant considérablement l’effort d’écriture du code d’implémentation en particulier
pour les méthodes CRUD et de recherche. La notion centrale dans Spring-Data-JPA est
la notion "Repository". Le repository est une interface à écrire par le développeur. Il
déclare, dans cette interface, les méthodes utiles d’accès aux données et Spring-Data-
JPA fournit les implémentations nécessaires [6].
 JasperReports : est un outil de Business Intelligence dédié au Reporting. Développé

en Java, il est 100 % Open Source. Il se présente sous forme d'une bibliothèque qui peut
être embarquée dans tous types d'applications Java. JasperReports se base sur des
fichiers XML pour la présentation des états/rapports. Il peut être couplé à iReport ou
d’autres éditeurs graphiques pour faciliter sa mise en œuvre dans une application Java,
classique ou orientée web [7].
3.3.2 Côté client
 Bootstrap : Il existe des frameworks côté serveur (désignés backend en anglais), et

d'autres côté client (désignés frontend en anglais). Bootstrap fait partie de cette
deuxième catégorie. Les frameworks CSS sont spécialisés, comme leur nom l'indique,
dans les CSS ! C'est-à-dire qu'ils nous aident à mettre en forme les pages web :
organisation, aspect, animation…
Bootstrap est un framework CSS, mais pas seulement, puisqu'il embarque également
des composants HTML et JavaScript. Il comporte un système de grille simple et efficace
pour mettre en ordre l'aspect visuel d'une page web. Il apporte du style pour les boutons,
les formulaires, la navigation… Il permet ainsi de concevoir un site web rapidement et
avec peu de lignes de code ajoutées. Le framework le plus proche de Bootstrap est sans
doute Foundation qui est présenté comme « The most advanced responsive front-end
framework in the world » [8].
 Thymeleaf : est un Java XML/XHTML/HTML5 Template Engine, moteur de template
en français, qui peut travailler à la fois dans des environnements Web (Servlet) et celui
de non Web. Il est mieux adapté pour diffuser XHTML/HTML5 sur View (View Layer)
des applications Web basées sur MVC. Mais il peut traiter n'importe quel fichier
XML même dans des environnements hors ligne (offline). Il fournit une intégration
complète de Spring Framework [9].
45
 Highcharts : Highcharts est une bibliothèque JavaScript qui vous permet de créer des
graphiques interactifs de nature dynamique ou statique. Cette librairie possède des
caractéristiques qui font d’elle un outil indispensable pour la création de graphiques.
Highcharts est simple d’utilisation, compatible tous navigateurs et responsive. C’est un
outil modulable et interactif proposant différents types de graphiques basés sur une
structure en HTML5 [10].
3.3.3 Liaison entre la partie cliente et la partie serveur
Pour la liaison entre la partie cliente et la partie serveur nous avons utilisé deux
framework :
 Spring Data Rest : Il s’appuie sur les référentiels Spring Data, analyse le modèle du
domaine et expose les entités automatiquement en tant que ressources REST via HTTP.
 Spring WebSocket : Spring comprend ce module avec un support WebSocket complet
qui fournit une connexion bidirectionnelle, full-duplex, persistante entre un navigateur
Web et un serveur. Une fois qu’une connexion WebSocket est établie, la connexion reste
ouverte jusqu’à ce que le client ou le serveur décide de fermer cette connexion [6].
Conclusion
Tout au long de ce chapitre nous avons décrit le processus de conception de notre

application. Des diagrammes de séquences sont explicités afin de représenter graphiquement
les interactions entre l’acteur et le système. Nous avons enfin justifié nos choix technologiques
nécessaires pour la réalisation de notre application.
Dans le chapitre suivant, nous allons présenter l’environnement du développement
matériel et logiciel ainsi que la description et la validation du travail réalisé.
46
Chapitre 4
REALISATION
Plan
1 Environnement de travail........................................................................................... 49
2 Phase d’implémentation ............................................................................................ 52
Chapitre 4. Réalisation
Introduction
La réalisation constitue l’aboutissement d’un travail d’analyse et de conception. Il est

question dans ce chapitre de présenter notre application spécifiée dans le chapitre précédent. Il
s’agit d’abord de spécifier l’environnement matériel et logiciel que nous avons utilisé durant la
phase de développement. Ensuite, nous exposons les interfaces et les fonctionnalités de cet
outil.
4.1 Environnement de travail
Nous présentons dans cette section l’environnement matériel et logiciels utilisées pour
le développement de notre application « Rejets Reporting & Statistics ».
4.1.1 Environnement matériel
Ce projet a été réalisé sur notre ordinateur portable personnel. Cet environnement est
constitué principalement de :
 Processeur : Intel Pentium CPU 2020M 2.40 GHZ

 Disque Dur : 500 Go
 Mémoire vive : 8 Go
 Système d’exploitation : Windows 10 Professionnel 64bits
4.1.2 Environnement logiciel

4.1.2.1 Environnement de conception
Le choix de l’environnement de conception utilisé est une décision importante à prendre

puisque cela détermine la rapidité avec laquelle les utilisateurs adopteront et utiliseront l’outil.
Power AMC : est l’un des premiers outils qui permet d’élaborer des modèles de
données que cela soit MERISE, UML ou autre, de manière graphique et de les implémenter
quel que soit le SGBD et ce de manière automatique. De même, l’outil permet de modéliser les
processus métiers. Le lien entre la modélisation des données et la modélisation des processus
peut être effectué, offrant ainsi aux entreprises qui possèdent POWER AMC / AMC Designor
l'opportunité de mettre un œuvre un référentiel unique des développements et des processus que
ceux-ci soient informatisés ou non.
48
Aussi Power AMC est une force dans tout nouveau projet d'entreprise car il permet
d'identifier avec précision quels processus, quelles personnes et/ou quelles données seront
impactés. L'estimation et maitrise des coûts en est grandie [11].
Fonctionnalités principales de Power AMC :
 Modélisation des processus métiers.
 Modélisation des données en MERISE MCD, MLD, MPD ou en UML.
 Reverse Engineering des bases de données.

 Estimation du poids de la base.
 Générateur de documentations.
 Lien entre Données et processus.
 Cartographie des actions et étapes des processus humains et industriels
Figure 25. Interface graphique de Power AMC
4.1.2.2 Environnement de développement
Le choix de l’environnement de développement utilisé est une décision très importante

à prendre puisque c’est l’espace où nous allons implémenter notre application. Nous avons
choisi Eclipse car il est l'IDE le plus complet notamment avec les plugins.
49
Eclipse : Eclipse est un IDE, Integrated Development Environment (EDI environnement

de développement intégré en français), c'est-à-dire un logiciel qui simplifie la programmation
en proposant un certain nombre de raccourcis et d'aide à la programmation. Il est développé par
IBM, est gratuit et disponible pour la plupart des systèmes d'exploitation.
Au fur et à mesure que vous programmez, eclipse compile automatiquement le code que vous
écrivez, en soulignant en rouge ou jaune les problèmes qu'il décèle. Il souligne en rouge les
parties du programme qui ne compilent pas, et en jaune les parties qui compilent mais peuvent
éventuellement poser problème (on dit qu'eclipse lève un avertissement, ou warning en anglais).
Pendant l'écriture du code, cela peut sembler un peu déroutant au début, puisque tant que la
ligne de code n'est pas terminée (en gros jusqu'au point-virgule), eclipse indique une erreur dans
le code.
Il est déconseillé de continuer d'écrire le programme quand il contient des erreurs, car eclipse
est dans ce cas moins performant pour vous aider à écrire le programme [12].
Figure 26. Interface graphique d'Eclipse
4.1.2.3 Environnement de base de données
Le choix de l’environnement de base de données utilisé est basé sur le choix de

l’entreprise, mais nous ne sommes pas dans ce cas car TUNISIE TELECOM utilise plusieurs
50
SGBD. Les rejets de communication sont enregistrés dans une table d’une BD SQL Server c’est
pour cela nous avons choisi d’utiliser le même SGBD.
SQL Server : Microsoft SQL Server (alias MSSQL) est un système de gestion de base
de données développé par la société Microsoft.
Il permet donc par son interface de créer et lister ses tables, en dessiner les diagrammes, y
exécuter du code SQL appelé Transact-SQL, en visualisant son plan d'exécution, et de
sauvegarder et lancer des procédures stockées et triggers.
Ceci en fait une alternative compétitive avec MySQL et Oracle [13].
Figure 27. Interface graphique de SQL Server
4.2 Phase d’implémentation
Les interfaces graphiques sont dotées d’une importance particulière et constituent un

critère déterminant pour la réussite de l’application. L’ergonomie et le design ont aussi pour
objectif d’améliorer l’interaction homme-machine, la facilité d’utilisation et d’apprentissage du
logiciel. Dans ce qui suit nous mettons l’accent sur cet aspect visuel.
51
4.2.1 Authentification
Avant d’utiliser l’application l’utilisateur doit s’authentifier en saisissant son login et

son mot de passe. Quelques interfaces qui reflètent le mécanisme de l’authentification existent
dans l’Annexe 1.
4.2.2 Le menu principal
Après l’authentification la page d’accueil s’affiche où les statistiques seront affichés et

une barre de menu s’affiche dans toutes les interfaces
Les différents onglets que nous avons mis à la disposition de l’utilisateur sont :
A gauche de l’utilisateur nous trouvons les onglets :
 « Accueil » : C’est l’onglet où s’affiche les statistiques comme nous avons indiqué
précédemment.
 « Rejets » : Dans cet onglet nous gérons les rejets.
 « Générer Rapport » : C’est l’onglet où nous générons des rapports selon des critères
bien définis
 « Utilisateurs » : Dans cette interface nous gérons les utilisateurs de l’application.
Et à sa droite nous trouvons l’onglet
 « Paramètres » : Cet onglet nous permettrons de modifier les paramètres du profil d’un
utilisateur.
Et l’option
 « Déconnexion » : Avec cette option l’utilisateur se déconnecte de son compte.
Les figures suivantes sont le menu principal et la page d’accueil de l’application
Figure 28. Le menu principal de l'application
4.2.3 L’onglet « Accueil »
Après l’authentification nous trouvons dans la première interface qui est l’onglet
« Accueil » où s’affiche les statistiques. Ces statistiques sont générés automatiquement selon
52
des critères bien définis dès le début et qui résument la table de rejets pour aider le technicien à
prendre une décision comment résoudre les rejets de communication.
La figure suivante nous montre la première interface.
Figure 29. La page d’accueil de l’application
4.2.4 L’onglet « Rejets »
Le deuxième onglet est l’onglet « Rejets » où nous pouvons gérer les rejets par
l’injection des rejets dans la base de données à partir d’un fichier CSV ou les supprimer tous de
la base de données en un simple clic, ces deux fonctionnalités sont destinées seulement à un
administrateur de l’application, les afficher dans un tableau et supprimer les rejets un à un, ces
deux dernières fonctionnalités sont accessibles à tous les utilisateurs.
53
Dans les deux figures suivantes nous allons remarquer la différence de même onglet dans les
deux comptes Admin et User.
Figure 30. L'onglet Rejets dans un compte "Admin"
Figure 31. L'onglet Rejets dans un compte "User"
Maintenant nous allons montrer comment injecter les rejets à partir d’un fichier CSV par les
figures suivantes. La première figure est de choisir le fichier.
54
Figure 32. Choisir le fichier CSV
La deuxième figure nous montre l’onglet après la sélection d’un fichier CSV, son nom s’affiche
dans l’onglet.
Figure 33. Après la sélection du fichier CSV
La troisième figure nous montre le message qui sera affiché après l’appui sur le bouton
« Ajouter les données », cette action va récupérer les données du fichier CSV et les enregistrer
dans la base de données.
Figure 34. L'ajout des données dans la base
55
Cette dernière figure nous montre le message affiché quand nous supprimons un seul rejet
Figure 35. Supprimer un seul rejet
4.2.5 L’onglet « Générer Rapport »
La génération des rapports est parmi les fonctionnalités nécessaires de notre application.
Nous trouvons dans l’onglet « Générer rapport » quatre zones. Ces zones sont associées pour la
génération des rapports selon des critères bien choisis dès le début et chaque rapport peut être
généré sous deux formes différents PDF et HTML.
Figure 36. L'onglet "Générer Rapport"
Après la génération du rapport un message s’affiche qui précise l’emplacement du fichier. La

figure suivante nous montre le message qui sera affiché.
Figure 37. Le message de l’emplacement du rapport
56
4.2.6 L’onglet « Utilisateurs »
Dans cette interface nous pouvons gérer les utilisateurs, de même pour cet onglet nous
avons deux vues ; une vue qui contient toutes les fonctionnalités de gestion des utilisateurs qui
est accessible seulement pour un Admin, qui sont l’affichage de la liste des utilisateurs, l’ajout
d’un nouvel utilisateur et la consultation d’un profil, et une autre vue qui contient seulement la
consultation d’un profil.
La figure suivante nous présente la première qui est accessible seulement à un Admin
Figure 38. L'onglet "Utilisateurs" dans un compte Admin
Et cette figure nous montre la deuxième vue
Figure 39. L'onglet "Utilisateurs" dans un compte User
57
Lors de saisir le CIN d’un utilisateur la recherche nous redirige vers une nouvelle interface
qui contient toutes les informations correspondantes à un utilisateur. La figure suivante est
l’interface qui contient les informations.
Figure 40. Informations d'un utilisateur
En cas de saisir un numéro CIN qui ne se trouve pas dans un message sera affiché comme
nous montre la figure suivante.
Figure 41. Message d'erreur lors d'un utilisateur introuvable
Lors de l’ajout d’un nouvel utilisateur par le formulaire qui se trouve à droite de l’utilisateur
dans l’interface associée à un Admin,
Un message d’ajout sera affiché si l’opération est réussie comme nous montre la figure
suivante ou un message d’erreur si l’opération est échouée comme nous montre la figure ci-
après.
58
Figure 42. Un message d'ajout d'un nouvel utilisateur
Figure 43. Un message d'erreur si l'un ou tous les champs sont vide
59
4.2.7 L’onglet « Paramètres »
L’utilisateur a la possibilité de modifier quelques paramètres de son profil com son nom,
son prénom, son adresse mail et son mot de passe. Pour accéder à cette opération de
modification il faut aller à l’onglet « Paramètres ». L’interface qui nous montre ça existe dans
l’Annexe 1.
4.2.8 L’option « Déconnexion »
Chaque utilisateur a le droit de se déconnecter de sa session après avoir terminé son

travail. Notre application nous garantir cette option par l’icône « Déconnexion ». Lors de la
déconnexion un message s’affiche dans la première interface d’authentification.
La figure suivante nous montre le message qui sera affiché lors de la déconnexion.
Figure 44. Message de déconnexion
Conclusion
Dans ce chapitre, nous avons présenté l’environnement du travail ainsi que le choix
technique adopté lors de l’implémentation. Et nous avons également exposé le fonctionnement
de notre système avec des imprimes écrans afin de donner une image réelle sur le travail réalisé.
60
CONCLUSION GENERALE
Annexes
Une grande entreprise comme TUNISIE TELECOM nécessite plusieurs SI pour

effectuer ses activités et pour garantir le bon service. Ces SI se communiquent entre eux pour
la cohérence des informations. Donc il ne faut pas avoir des rejets au niveau de la
communication entre ces derniers ou bien résoudre ces rejets le plus tôt possible. La meilleure
solution est d’avoir une solution BI pour le traitement de ces rejets de communication. C’est
dans ce contexte que s’inscrit notre projet. Ce travail a été effectué au sein de Complexe
TUNISIE TELECOM. Il s’agit de contribuer à la mise en place d’une solution BI pour le
traitement des rejets de communication entre les SI.
Malgré les contraintes techniques et temporelles rencontrées, nous avons pu délivrer une
preuve de conception fonctionnelle qui répond bien aux objectifs définis au début de ce stage.
En effet ce stage a commencé par spécifier les besoins attendus de cette application.
Ensuite, nous avons consacré une bonne période de temps à concevoir l’architecture optimale
pour notre application. Puis, nous avons réussi à réaliser le cœur de ce projet qui réside dans
l’action d’afficher des statistiques et de générer des rapports sous différents formes qui résument
les rejets de communication. Au final, nous avons réussi de transformer les besoins spécifiés
dès le début du stage en une application web.
Ce stage nous a été très bénéfique non seulement sur le côté technique mais aussi sur le
côté humain et professionnel. Il nous a ainsi donné l’occasion de concrétiser les notions
théoriques acquises: d’approfondir nos compétences et découvrir le milieu professionnel avec
tout ce qu’il implique comme responsabilité et diligence
62

Rapport de Stage

Transféré par

Informations du document

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Rapport de Stage

Transféré par

Droits d'auteur :

Formats disponibles

République Tunisienne

Conception et Réalisation d’une application web de

Encadrant académique et professionnel : Hamadi Naoufel

Réalisé au sein TUNISIE TELECOM

Année Universitaire 2019 – 2020

Introduction générale ..................................................................................................... 1

1.1 Organisme d’accueil : TUNISIE TELECOM ................................................. 5

1.1.1 Histoire .......................................................................................................... 5

1.1.2 Activité .......................................................................................................... 6

1.1.1 Organisation structurelle de Tunisie Telecom................................................ 7

1.2 Contexte du projet.......................................................................................... 7

1.3 Etude et critique de l’existant ......................................................................... 8

1.4 Problématique .............................................................................................. 10

1.5 Solution proposée et objectifs globaux du projet .......................................... 10

1.6 Limite exigée de la solution ......................................................................... 10

1.7 Choix méthodologique ................................................................................. 11

1.7.1 Méthodes agiles ........................................................................................... 11

1.7.2 2TUP ........................................................................................................... 11

Analyse et spécification des besoins ............................................................................ 14

2.1 Spécification des besoins ............................................................................. 15

2.1.1 Besoins fonctionnels .................................................................................... 15

2.1.2 Besoins non fonctionnels ............................................................................. 16

2.2 Identification des acteurs.............................................................................. 16

2.3 Diagrammes des cas d’utilisation et identification des scénarios................... 17

2.3.1 Diagramme global des cas d’utilisation ........................................................ 17

2.3.2 Cas d’utilisation « Afficher les statistiques » ................................................ 18

2.3.3 Cas d’utilisation « Générer des rapports » .................................................... 19

2.3.5 Cas d’utilisation « Gérer les rejets » ............................................................. 23

2.3.6 Cas d’utilisation « Gérer les utilisateurs » .................................................... 25

2.3.7 Cas d’utilisation « Injecter les rejets » .......................................................... 28

2.3.8 Cas d’utilisation « Supprimer tous les rejets » .............................................. 29

Conception et choix technologiques............................................................................. 31

3.1 Conception détaillée .......................................................................................... 32

3.1.1 Modélisation statique : diagramme de classes .............................................. 32

3.1.2 Modélisation dynamique .............................................................................. 34

3.2 Conception architecturale............................................................................. 41

3.2.1 Diagramme de déploiement ......................................................................... 41

3.2.2 Architecture logique .................................................................................... 42

3.3 Choix technologiques................................................................................... 44

3.3.1 Côté serveur ................................................................................................. 44

3.3.2 Côté client ................................................................................................... 45

4.1 Environnement de travail ............................................................................. 48

4.1.1 Environnement matériel ............................................................................... 48

4.1.2 Environnement logiciel ................................................................................ 48

4.2 Phase d’implémentation ............................................................................... 51

4.2.1 Authentification ........................................................................................... 52

4.2.2 Le menu principal ........................................................................................ 52

4.2.3 L’onglet « Accueil » .................................................................................... 52

4.2.4 L’onglet « Rejets »....................................................................................... 53

4.2.6 L’onglet « Utilisateurs » .............................................................................. 57

4.2.7 L’onglet « Paramètres » ............................................................................... 60

4.2.8 L’option « Déconnexion » ........................................................................... 60

Conclusion générale .................................................................................................... 61

Annexe 1. Interfaces finales ..................................................................................... 66

1. Interface d’authentification .............................................................................. 66

2. Interface de modification les paramètres d’un profil ........................................ 67

Figure 1. Organigramme TUNISIE TELECOM .......................................................... 7

Tableau 1. Description du cas d’utilisation "Afficher les statistiques" ........................ 19

Dans le cadre de nos études au sein de l’EPMPT et en vue de l’obtention du diplôme

Le présent rapport s’articule autour de quatre chapitres.

Le premier chapitre « Contexte général » consiste à présenter le cadre général du projet.

Le deuxième chapitre « Analyse et spécification des besoins » sera consacré à l’analyse

Le troisième chapitre « Conception et choix technologiques » consiste à exposer la

Le dernier chapitre « Réalisation » sera dédié à une description des détails de