SlideShare une entreprise Scribd logo
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 DE FIN D’ETUDES
Présenté en vue de l’obtention du
Diplôme National d’Ingénieur en Informatique
Spécialité : Informatique Décisionnelle
Par
Tahani RIAHI
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 : Monsieur Nizar ELHAJ FERJANI
Réalisé au sein de Complexe ElKasbah
TUNISIE TELECOM
Soutenu le 21 Juin 2018 devant la commission composée de :
Président : Mme Aicha GUERFACHI
Rapporteur : Mme Wiem TRABELSI
Membre : Mme Afef SELMI
Année Universitaire 2017 – 2018
AVANT PROPOS
Ce document entre dans le cadre de la préparation d’un rapport de projet de fin d’études
en vue de l’obtention du diplôme d’Ingénieur en Informatique Décisionnelle au sein de l’Ecole
Polytechnique Méditerranéenne Privée de Tunis EPMPT.
C’est ainsi que nous avons eu l’occasion de préparer notre projet de fin d’étude intitulé
« Conception et Réalisation d’une application web de Reporting et Statistics des rejets de
communication entre les différents Systèmes d’Information de Tunisie Télécom » proposé
par Tunisie Télécom, la Direction Centrale des Systèmes d’Information.
Ce projet est un apport très bénéfique quant au perfectionnement des connaissances de
l’étudiant dans le domaine informatique et pour avoir l’opportunité d’appliquer ses
connaissances théoriques acquises tout au long de son cursus universitaire dans le cadre
professionnel.
Dédicaces
De mon profond amour, de ma reconnaissance infinie, pour tous leurs sacrifices
qu’ils n’ont jamais cessé de me fournir, je dédie ce travail aux plus chers du monde :
À Mes parents pour tout l’amour, pour toute la tendresse, la gentillesse, les
sacrifices et les prières ferventes qui m’ont accompagnée durant mes études.
À Ma sœur Malek qui m’a inculquée un esprit de combativité et de persévérance et
qui m’a toujours motivée dans mes études.
À Mes frères Anis et Achref, Ma sœur Amani, Mon fiancé Hosni et toute ma famille
qui m’ont toujours encouragée et qui sont toujours à côté de moi.
À mes amis, et tous ceux qui me sont chers et qui m’ont toujours encouragée dans
les moments de délicat, Je vous souhaite une vie pleine de joie et de bonheur.
Je vous aime
Tahani RIAHI
Remerciements
Je tiens à remercier toutes les personnes qui ont contribué à la réussite de mon
stage de près ou de loin à la rédaction de mon rapport.
Tout d’abord, je tiens à commencer par M. Nizar ELHAJ FERJANI mon encadrant à
TUNISIE TELECOM pour son accueil, le temps qu’il a consacré pour moi et son partage de
connaissances.
Jeremercieaussi vivement mon enseignante MmeWiem TRABELSI pourses conseils
académiques et sa disponibilité pour répondre à mes questions tout au long de mon stage.
Pour finir, je remercierai toute personne m’ayant fourni de l’aide durant, avant et
après ce stage.
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
Figure annexe 1. Interface d’authentification.............................................................. 66
Figure annexe 2. Message d’erreur lors d’une authentification incorrecte ................. 66
Figure annexe 3. Première interface de l’onglet « Paramètres ».................................. 67
Figure annexe 4. Message d'erreur ............................................................................... 67
Figure annexe 5. Récupération des informations du compte ....................................... 68
Figure annexe 6. Formulaire de modification .............................................................. 68
Figure annexe 7. Message de modification .................................................................. 69
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
2
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 de
fin d’études 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.
Introduction Générale
3
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.
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
5
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 :
Chapitre 1. Contexte général
6
- 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.
Chapitre 1. Contexte général
7
1.1.1 Organisation structurelle de 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,
PDG
Commerciale
Ventes Actel
Vente
Entreprise
Distrubution
indirecte
Marketing
regionale
support
Service
Assurance
qualite clients
CSC
Reseaux
Planification &
Ingenerie
Deploiement
des reseaux
Energie &
Environment
Optimisation
& qualite
materielle
ROCS
SAAF
Moyens
Achats
Finances
Juridique
R.H
Gestion
previsionelle
du personelle
Support
administratif &
sociale
Formations
Directeur
Regionale
Affaires
Regionale
Figure 1. Organigramme TUNISIE TELECOM
Chapitre 1. Contexte général
8
• 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 de fin d’études 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.
Chapitre 1. Contexte général
9
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.
Chapitre 1. Contexte général
10
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.
Chapitre 1. Contexte général
11
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
Chapitre 1. Contexte général
12
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] :
Chapitre 1. Contexte général
13
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.
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
15
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
Chapitre 2. Analyse et spécification des besoins
16
➢ 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.
Chapitre 2. Analyse et spécification des besoins
17
• 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
Chapitre 2. Analyse et spécification des besoins
18
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.
Chapitre 2. Analyse et spécification des besoins
19
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 »
2.3.3.1 Diagramme du cas d’utilisation
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 »
2.3.3.2 Identification du scénario
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 :
Chapitre 2. Analyse et spécification des besoins
20
Cas d’utilisation « Générer des rapports »
Objectif Permettre à l’utilisateur de générer des rapports 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.
Scénario :
- L’utilisateur s’authentifie.
- 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.
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 ».
- 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 »
2.3.4.1 Diagramme du cas d’utilisation
La figure suivante présente le diagramme de cas d’utilisation : « Gérer un profil »
Chapitre 2. Analyse et spécification des besoins
21
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
Description Précondition(s) :
- La machine est connectée au réseau local de TUNISIE TELECOM.
- Lancer l’application.
- S’authentifier.
- Charger les utilisateurs enregistrés dans la base de données.
Scénario :
- L’utilisateur s’authentifie.
- 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.
Chapitre 2. Analyse et spécification des besoins
22
Postcondition(s) :
- les informations relatives à un profil seront affichées dans une nouvelle
interface.
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 ».
- 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
Description Précondition(s) :
- La machine est connectée au réseau local de TUNISIE TELECOM.
- Lancer l’application.
- S’authentifier.
- Charger les utilisateurs enregistrés dans la base de données.
Scénario :
- L’utilisateur s’authentifie.
- 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.
Chapitre 2. Analyse et spécification des besoins
23
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 ».
- 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 »
2.3.5.1 Diagramme du cas d’utilisation
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.
Une description détaillée du déroulement de cette opération est répertoriée dans le tableau
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
Description Précondition(s) :
- La machine est connectée au réseau local de TUNISIE TELECOM.
Chapitre 2. Analyse et spécification des besoins
24
- Lancer l’application.
- S’authentifier.
- Charger les rejets enregistrés dans la base de données.
Scénario :
- L’utilisateur s’authentifie.
- Il affiche l’onglet « Rejets ».
- Il affiche la liste des rejets.
Postcondition(s) :
- Les utilisateurs sont affichés dans un tableau.
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 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.
Une description détaillée du déroulement de cette opération est répertoriée dans le tableau
suivant :
Cas d’utilisation « Supprimer un rejet »
Objectif Permettre à l’utilisateur de supprimer un rejet de la liste des 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.
Scénario :
- L’utilisateur s’authentifie.
- Il affiche l’onglet « Rejets ».
- Il affiche la liste des rejets.
- Il choisit le rejet qui va supprimer
- Il clique sur le bouton « Supprimer »
-Il supprime le rejet.
Chapitre 2. Analyse et spécification des besoins
25
Postcondition(s) :
- Le rejet se supprime de la liste des rejets affichés et de la base de
données.
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 6. Description du cas d’utilisation « Supprimer un rejet »
2.3.6 Cas d’utilisation « Gérer les utilisateurs »
2.3.6.1 Diagramme du cas d’utilisation
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.
Description Précondition(s) :
- La machine est connectée au réseau local de TUNISIE TELECOM.
- Lancer l’application.
- S’authentifier.
Chapitre 2. Analyse et spécification des besoins
26
- Charger les utilisateurs enregistrés dans la base de données.
Scénario :
- L’utilisateur s’authentifie.
- Il affiche l’onglet « Utilisateur ».
- Il affiche la liste des utilisateurs.
Postcondition(s) :
- Les utilisateurs sont affichés dans un tableau.
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 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.
Une description détaillée du déroulement de cette opération est répertoriée dans le tableau
suivant :
Cas d’utilisation « Ajouter un utilisateur »
Objectif Permettre à l’administrateur d’ajouter, via un formulaire, un nouvel
utilisateur de l’application.
Description Précondition(s) :
- La machine est connectée au réseau local de TUNISIE TELECOM.
- Lancer l’application.
- S’authentifier.
- Charger les utilisateurs enregistrés dans la base de données.
Scénario :
- L’utilisateur s’authentifie.
- Il affiche l’onglet « Utilisateurs ».
- Il remplit le formulaire d’ajout.
- Il confirme l’ajout.
Postcondition(s) :
- L’utilisateur sera ajouté à la base.
Chapitre 2. Analyse et spécification des besoins
27
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 ».
- 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 ».
Une description détaillée du déroulement de cette opération est répertoriée dans le tableau
suivant :
Cas d’utilisation « Supprimer un utilisateur »
Objectif Permettre à l’administrateur de supprimer un utilisateur de la liste des
utilisateurs.
Description Précondition(s) :
- La machine est connectée au réseau local de TUNISIE TELECOM.
- Lancer l’application.
- S’authentifier.
- Charger les utilisateurs enregistrés dans la base de données.
Scénario :
- L’utilisateur s’authentifie.
- 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.
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 9. Description du cas d’utilisation « Supprimer un utilisateur »
Chapitre 2. Analyse et spécification des besoins
28
2.3.7 Cas d’utilisation « Injecter les rejets »
2.3.7.1 Diagramme du cas d’utilisation
La figure suivante présente le diagramme de cas d’utilisation : « Injecter les rejets »
Figure 9. Diagramme de cas d’utilisation « Injecter les rejets »
2.3.7.2 Identification du scénario
Il permet à l’administrateur d’injecter les rejets à partir un fichier CSV.
Une description détaillée du déroulement de cette opération est répertoriée dans le tableau
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.
Description Précondition(s) :
- La machine est connectée au réseau local de TUNISIE TELECOM.
- Lancer l’application.
- S’authentifier.
Scénario :
- L’utilisateur s’authentifie.
- Il affiche l’onglet « Rejets ».
- 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 ».
Chapitre 2. Analyse et spécification des besoins
29
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.
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 ».
- 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 »
2.3.8.1 Diagramme du cas d’utilisation
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 »
2.3.8.2 Identification du scénario
Il permet à l’administrateur de supprimer tous les rejets enregistrés dans la base de
données en une seule fois.
Une description détaillée du déroulement de cette opération est répertoriée dans le tableau
suivant :
Cas d’utilisation « Supprimer tous les rejets »
Objectif Permettre à l’administrateur de supprimer tous les rejets en une seule
fois.
Description Précondition(s) :
- La machine est connectée au réseau local de TUNISIE TELECOM.
- Lancer l’application.
Chapitre 2. Analyse et spécification des besoins
30
- S’authentifier.
- Charger les rejets enregistrés dans la base de données.
Scénario :
- L’utilisateur s’authentifie.
- Il affiche l’onglet « Rejets ».
- 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.
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 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.
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
32
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 :
Chapitre 3. Conception et choix technologiques
33
Figure 11. Diagramme de Classes
Chapitre 3. Conception et choix technologiques
34
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
Chapitre 3. Conception et choix technologiques
35
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 ».
Chapitre 3. Conception et choix technologiques
36
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 »
Chapitre 3. Conception et choix technologiques
37
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 »
Chapitre 3. Conception et choix technologiques
38
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 »
Chapitre 3. Conception et choix technologiques
39
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 »
Chapitre 3. Conception et choix technologiques
40
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 »
Chapitre 3. Conception et choix technologiques
41
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 :
Chapitre 3. Conception et choix technologiques
42
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 :
Chapitre 3. Conception et choix technologiques
43
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.
Chapitre 3. Conception et choix technologiques
44
• 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].
Chapitre 3. Conception et choix technologiques
45
• 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].
Chapitre 3. Conception et choix technologiques
46
• 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é.
Chapitre 4
REALISATION
Plan
1 Environnement de travail ……………………………………………………………. 49
2 Phase d’implémentation ……………………………………………………………... 52
Chapitre 4. Réalisation
48
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.
Chapitre 4. Réalisation
49
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.
Chapitre 4. Réalisation
50
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
Chapitre 4. Réalisation
51
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.
Chapitre 4. Réalisation
52
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
Chapitre 4. Réalisation
53
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.
Chapitre 4. Réalisation
54
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.
Chapitre 4. Réalisation
55
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
Chapitre 4. Réalisation
56
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
Chapitre 4. Réalisation
57
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
Chapitre 4. Réalisation
58
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.
Chapitre 4. Réalisation
59
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
Chapitre 4. Réalisation
60
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é.
CONCLUSION GENERALE
Conclusion générale
62
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 de fin d’études. Ce travail a été effectué au sein de
Complexe ElKasbah 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 de fin d’étude 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 durant notre parcours académique à l’EPMPT : d’approfondir
nos compétences et découvrir le milieu professionnel avec tout ce qu’il implique comme
responsabilité et diligence.
WEBOGRAPHIE
Webographie
64
[1] : Tunisie Telecom : définition de Tunisie Telecom et synonymes de Tunisie
Telecom. Adresse : http://dictionnaire.sensagent.leparisien.fr/Tunisie%20Telecom/fr-fr/
[2] : tunisie telecom. Adresse : http://tunisie-telecom.e-monsite.com/
[3] : Les fichiers log, des indicateurs utiles. Adresse :
https://www.journaldunet.com/developpeur/algo-methodes/tutoriel-pratique/les-
fichiers-log-des-indicateurs-utiles.shtml
[4] : E. de access-dev. (2010). La Gestion de projet. Adresse : http://www.access-
dev.com/access-dev/la-gestion-de-projet-methodes-classiques-vsmethodes-agiles/
[5] : E. de uml-sysml. (2006). Processus de modélisation. Adresse : http://www.uml-
sysml.org/modelisation-objet/processus-de-modelisation
[6] : E. de Spring. (2016). Spring Docs.Adresse : https://spring.io/docs/reference
[7] : Jasper Reports Reporting Open Source. Adresse : https://www.next-
decision.fr/editeurs/restitution/jasper-reports
[8] : Prenez e main Bootstrap (Mise à jour le 04/05/2018). Mise en route. Adresse :
https://openclassrooms.com/courses/prenez-en-main-bootstrap/mise-en-route-8
[9] : Le Tutoriel de Spring Boot et Thymeleaf. Adresse :
https://o7planning.org/fr/11545/le-tutoriel-de-spring-boot-et-thymeleaf
[10] : Highcharts : des graphiques animés et dynamiques (30 / 07 / 2015). Adresse :
https://www.oboqo.com/blog/highcharts-graphiques-animes-dynamiques/
[11] : Power AMC, modélisation de données – Next Decision. Adresse :
https://www.next-decision.fr/editeurs/autres/sap-power-amc
[12] : Introduction à l’utilisation d’eclipse. Adresse :
http://www.enseignement.polytechnique.fr/informatique/profs/Julien.Cervelle/eclipse/
[13] : Microsoft SQL Server – Wikilivres. Adresse :
https://fr.wikibooks.org/wiki/Microsoft_SQL_Server
ANNEXES
Annexes
66
Annexe 1. Interfaces finales
1. Interface d’authentification :
Pour limiter l’accès seulement aux utilisateurs autorisés et selon leurs droits d’accès,
chacun d’entre eux doit saisir un login et mot de passe pour s’authentifier.
La figure annexe 1 montre l’interface d’authentification de notre application.
Figure annexe 1. Interface d’authentification
Après avoir rempli ces champs, l’application consulte la base de données et vérifie la
saisie de l’utilisateur. En cas d’échec d’authentification, elle lui affiche le message « Nom
d'utilisateur ou mot de passe incorrecte »
Figure annexe 2. Message d’erreur lors d’une authentification incorrecte
Annexes
67
2. Interface de modification les paramètres d’un profil
La modification des paramètres d’un profil est nécessaire pour garantir la
confidentialité. Pour modifier ces paramètres nous avons implémenté une interface pour la
modification dans l’onglet « Paramètres »
La figure annexe 3 nous montre la première vue de l’interface.
Figure annexe 3. Première interface de l’onglet « Paramètres »
Si nous avons saisi un login ou un mot de passe incorrecte ou tous les deux nous allons avoir
un message d’erreur.
La figure annexe suivante nous montre ceci.
Figure annexe 4. Message d'erreur
Annexes
68
Après la saisie des paramètres du compte, le login et le mot de passe, nous allons obtenir une
amélioration dans la vue de l’interface. Nous récupérer les informations du profil comme nous
montre la figure annexe 5.
Figure annexe 5. Récupération des informations du compte
Pour modifier les paramètres du profil affichés dans la dernière figure l’utilisateur clique
sur le bouton « Modifier les paramètres du compte », par la suite un formulaire de modification
du profil va s’afficher à droite de l’utilisateur.
La figure annexe suivante nous montre le formulaire.
Figure annexe 6. Formulaire de modification
Annexes
69
Après la saisie des nouveaux paramètres l’utilisateur clique sur le bouton « Enregistrer les
modifications ». Un message de modification va s’afficher.
Figure annexe 7. Message de modification

Contenu connexe

Tendances

Presentation de soutenance du Projet Fin d'Etudes
Presentation de soutenance du Projet Fin d'EtudesPresentation de soutenance du Projet Fin d'Etudes
Presentation de soutenance du Projet Fin d'Etudes
Tahani RIAHI
 
Rapport projet fin d'étude
Rapport projet fin d'étudeRapport projet fin d'étude
Rapport projet fin d'étude
HibaFarhat3
 
Rapport de projet de fin d’étude
Rapport  de projet de fin d’étudeRapport  de projet de fin d’étude
Rapport de projet de fin d’étude
OumaimaOuedherfi
 
Rapport de projet de conception et de développement
Rapport de projet de conception et de développementRapport de projet de conception et de développement
Rapport de projet de conception et de développement
Donia Hammami
 
Rapport de stage de fin d'études ISI 2015
Rapport de stage de fin d'études ISI 2015Rapport de stage de fin d'études ISI 2015
Rapport de stage de fin d'études ISI 2015
Anouar Kacem
 
RapportPFE_IngenieurInformatique_ESPRIT
RapportPFE_IngenieurInformatique_ESPRITRapportPFE_IngenieurInformatique_ESPRIT
RapportPFE_IngenieurInformatique_ESPRIT
Lina Meddeb
 
Rapport PFE ingénieur réseaux marwen SAADAOUI ( Juin 2018 )
Rapport PFE ingénieur réseaux marwen SAADAOUI ( Juin 2018 )Rapport PFE ingénieur réseaux marwen SAADAOUI ( Juin 2018 )
Rapport PFE ingénieur réseaux marwen SAADAOUI ( Juin 2018 )
Saadaoui Marwen
 
Rapport final pfe_systeme_de_gestion _de_cabinet_de_formation_mobile_web
Rapport final pfe_systeme_de_gestion _de_cabinet_de_formation_mobile_webRapport final pfe_systeme_de_gestion _de_cabinet_de_formation_mobile_web
Rapport final pfe_systeme_de_gestion _de_cabinet_de_formation_mobile_web
Salma Gouia
 
RAPPORT DE PROJET DE FIN D’ETUDES
RAPPORT DE PROJET DE FIN D’ETUDESRAPPORT DE PROJET DE FIN D’ETUDES
RAPPORT DE PROJET DE FIN D’ETUDES
TombariAhmed
 
Rapport de stage PFE - Mémoire master: Développement d'une application Android
Rapport de stage PFE - Mémoire master: Développement d'une application AndroidRapport de stage PFE - Mémoire master: Développement d'une application Android
Rapport de stage PFE - Mémoire master: Développement d'une application Android
BadrElattaoui
 
Rapport pfe licence
Rapport pfe licenceRapport pfe licence
Rapport pfe licence
Fatima Zahra Fagroud
 
Rapport Projet de fin d'etude sur le parc informatique
Rapport Projet  de fin d'etude sur le parc informatiqueRapport Projet  de fin d'etude sur le parc informatique
Rapport Projet de fin d'etude sur le parc informatique
Hicham Ben
 
Conception et développement d'une application de gestion de production et de ...
Conception et développement d'une application de gestion de production et de ...Conception et développement d'une application de gestion de production et de ...
Conception et développement d'une application de gestion de production et de ...
Mohamed Aziz Chetoui
 
Présentation projet de fin d'étude
Présentation projet de fin d'étudePrésentation projet de fin d'étude
Présentation projet de fin d'étude
Donia Hammami
 
Présentation de mon PFE
Présentation de mon PFEPrésentation de mon PFE
Présentation de mon PFE
Nadir Haouari
 
Rapport Mini Projet : élaborer un moteur de Recherche spécialisé en Education
Rapport Mini Projet : élaborer un moteur de Recherche spécialisé en EducationRapport Mini Projet : élaborer un moteur de Recherche spécialisé en Education
Rapport Mini Projet : élaborer un moteur de Recherche spécialisé en Education
Mohamed Amine Mahmoudi
 
Rapport PFE : Développement D'une application de gestion des cartes de fidéli...
Rapport PFE : Développement D'une application de gestion des cartes de fidéli...Rapport PFE : Développement D'une application de gestion des cartes de fidéli...
Rapport PFE : Développement D'une application de gestion des cartes de fidéli...
Riadh K.
 
Rapport De PFE
Rapport De PFERapport De PFE
Rapport De PFE
Nadir Haouari
 
PFE :: Application de gestion des dus d'enseignement
PFE :: Application de gestion des dus d'enseignementPFE :: Application de gestion des dus d'enseignement
PFE :: Application de gestion des dus d'enseignement
Nassim Bahri
 
Soutenance PFE ingénieur génie logiciel
Soutenance PFE ingénieur génie logicielSoutenance PFE ingénieur génie logiciel
Soutenance PFE ingénieur génie logicielSiwar GUEMRI
 

Tendances (20)

Presentation de soutenance du Projet Fin d'Etudes
Presentation de soutenance du Projet Fin d'EtudesPresentation de soutenance du Projet Fin d'Etudes
Presentation de soutenance du Projet Fin d'Etudes
 
Rapport projet fin d'étude
Rapport projet fin d'étudeRapport projet fin d'étude
Rapport projet fin d'étude
 
Rapport de projet de fin d’étude
Rapport  de projet de fin d’étudeRapport  de projet de fin d’étude
Rapport de projet de fin d’étude
 
Rapport de projet de conception et de développement
Rapport de projet de conception et de développementRapport de projet de conception et de développement
Rapport de projet de conception et de développement
 
Rapport de stage de fin d'études ISI 2015
Rapport de stage de fin d'études ISI 2015Rapport de stage de fin d'études ISI 2015
Rapport de stage de fin d'études ISI 2015
 
RapportPFE_IngenieurInformatique_ESPRIT
RapportPFE_IngenieurInformatique_ESPRITRapportPFE_IngenieurInformatique_ESPRIT
RapportPFE_IngenieurInformatique_ESPRIT
 
Rapport PFE ingénieur réseaux marwen SAADAOUI ( Juin 2018 )
Rapport PFE ingénieur réseaux marwen SAADAOUI ( Juin 2018 )Rapport PFE ingénieur réseaux marwen SAADAOUI ( Juin 2018 )
Rapport PFE ingénieur réseaux marwen SAADAOUI ( Juin 2018 )
 
Rapport final pfe_systeme_de_gestion _de_cabinet_de_formation_mobile_web
Rapport final pfe_systeme_de_gestion _de_cabinet_de_formation_mobile_webRapport final pfe_systeme_de_gestion _de_cabinet_de_formation_mobile_web
Rapport final pfe_systeme_de_gestion _de_cabinet_de_formation_mobile_web
 
RAPPORT DE PROJET DE FIN D’ETUDES
RAPPORT DE PROJET DE FIN D’ETUDESRAPPORT DE PROJET DE FIN D’ETUDES
RAPPORT DE PROJET DE FIN D’ETUDES
 
Rapport de stage PFE - Mémoire master: Développement d'une application Android
Rapport de stage PFE - Mémoire master: Développement d'une application AndroidRapport de stage PFE - Mémoire master: Développement d'une application Android
Rapport de stage PFE - Mémoire master: Développement d'une application Android
 
Rapport pfe licence
Rapport pfe licenceRapport pfe licence
Rapport pfe licence
 
Rapport Projet de fin d'etude sur le parc informatique
Rapport Projet  de fin d'etude sur le parc informatiqueRapport Projet  de fin d'etude sur le parc informatique
Rapport Projet de fin d'etude sur le parc informatique
 
Conception et développement d'une application de gestion de production et de ...
Conception et développement d'une application de gestion de production et de ...Conception et développement d'une application de gestion de production et de ...
Conception et développement d'une application de gestion de production et de ...
 
Présentation projet de fin d'étude
Présentation projet de fin d'étudePrésentation projet de fin d'étude
Présentation projet de fin d'étude
 
Présentation de mon PFE
Présentation de mon PFEPrésentation de mon PFE
Présentation de mon PFE
 
Rapport Mini Projet : élaborer un moteur de Recherche spécialisé en Education
Rapport Mini Projet : élaborer un moteur de Recherche spécialisé en EducationRapport Mini Projet : élaborer un moteur de Recherche spécialisé en Education
Rapport Mini Projet : élaborer un moteur de Recherche spécialisé en Education
 
Rapport PFE : Développement D'une application de gestion des cartes de fidéli...
Rapport PFE : Développement D'une application de gestion des cartes de fidéli...Rapport PFE : Développement D'une application de gestion des cartes de fidéli...
Rapport PFE : Développement D'une application de gestion des cartes de fidéli...
 
Rapport De PFE
Rapport De PFERapport De PFE
Rapport De PFE
 
PFE :: Application de gestion des dus d'enseignement
PFE :: Application de gestion des dus d'enseignementPFE :: Application de gestion des dus d'enseignement
PFE :: Application de gestion des dus d'enseignement
 
Soutenance PFE ingénieur génie logiciel
Soutenance PFE ingénieur génie logicielSoutenance PFE ingénieur génie logiciel
Soutenance PFE ingénieur génie logiciel
 

Similaire à Rapport du projet fin d'etudes

Torkhanikarima-MémoireMastereProRx&telecom-FST2015-, Supervision et Monitorin...
Torkhanikarima-MémoireMastereProRx&telecom-FST2015-, Supervision et Monitorin...Torkhanikarima-MémoireMastereProRx&telecom-FST2015-, Supervision et Monitorin...
Torkhanikarima-MémoireMastereProRx&telecom-FST2015-, Supervision et Monitorin...
Karima Torkhani
 
Torkhani karima-MémoireMastereProRx&telecom-FST2015-, Supervision et Monitori...
Torkhani karima-MémoireMastereProRx&telecom-FST2015-, Supervision et Monitori...Torkhani karima-MémoireMastereProRx&telecom-FST2015-, Supervision et Monitori...
Torkhani karima-MémoireMastereProRx&telecom-FST2015-, Supervision et Monitori...
karimatorkhani
 
orkhanikarima-MémoireMastereProRx&telecom-FST2015-, Supervision et Monitoring...
orkhanikarima-MémoireMastereProRx&telecom-FST2015-, Supervision et Monitoring...orkhanikarima-MémoireMastereProRx&telecom-FST2015-, Supervision et Monitoring...
orkhanikarima-MémoireMastereProRx&telecom-FST2015-, Supervision et Monitoring...
Karima Torkhani
 
Pfe master fst_final_decembre2015
Pfe master fst_final_decembre2015Pfe master fst_final_decembre2015
Pfe master fst_final_decembre2015
Ghali Rahma
 
rapport fin d'etude
rapport fin d'etuderapport fin d'etude
rapport fin d'etude
sihem-med
 
Rapport final
Rapport finalRapport final
Rapport final
YosraJerbi1
 
392327755-Conception-Et-Realisation-d-Un-Site-Web-Et-Une-Application-Mobile-d...
392327755-Conception-Et-Realisation-d-Un-Site-Web-Et-Une-Application-Mobile-d...392327755-Conception-Et-Realisation-d-Un-Site-Web-Et-Une-Application-Mobile-d...
392327755-Conception-Et-Realisation-d-Un-Site-Web-Et-Une-Application-Mobile-d...
ElAzzabAbdeSsamad
 
Rapport-PFE2013-RahmaGhali-Gestion des Candidatures(Jaas,Primefaces,JFS2,JPA)
Rapport-PFE2013-RahmaGhali-Gestion des Candidatures(Jaas,Primefaces,JFS2,JPA)Rapport-PFE2013-RahmaGhali-Gestion des Candidatures(Jaas,Primefaces,JFS2,JPA)
Rapport-PFE2013-RahmaGhali-Gestion des Candidatures(Jaas,Primefaces,JFS2,JPA)Ghali Rahma
 
YouTaQA : Système de Questions-Réponses Intelligent basé sur le Deep Learning...
YouTaQA : Système de Questions-Réponses Intelligent basé sur le Deep Learning...YouTaQA : Système de Questions-Réponses Intelligent basé sur le Deep Learning...
YouTaQA : Système de Questions-Réponses Intelligent basé sur le Deep Learning...
YounesAGABI
 
Rapport PFE réalisation d’un Framework Kinect
Rapport PFE réalisation d’un Framework KinectRapport PFE réalisation d’un Framework Kinect
Rapport PFE réalisation d’un Framework Kinect
Amine MEGDICHE
 
Rapport finiale
Rapport finialeRapport finiale
Rapport finiale
marwenbencheikhali
 
Thèse+Kawtar+RETMI.pdf
Thèse+Kawtar+RETMI.pdfThèse+Kawtar+RETMI.pdf
Thèse+Kawtar+RETMI.pdf
HajarEttahiri1
 
Rapport Projet ERP - Plateforme Odoo 12 (PFE Licence)
Rapport Projet ERP - Plateforme Odoo 12 (PFE Licence)Rapport Projet ERP - Plateforme Odoo 12 (PFE Licence)
Rapport Projet ERP - Plateforme Odoo 12 (PFE Licence)
Yasmine Tounsi
 
Rapport de stage communication visuelle, événementiel et site WordPress à ISAMM
Rapport de stage communication visuelle, événementiel  et site WordPress à ISAMMRapport de stage communication visuelle, événementiel  et site WordPress à ISAMM
Rapport de stage communication visuelle, événementiel et site WordPress à ISAMM
Nidhal Trabelssi
 
Rapport stage onee-be_2
Rapport stage onee-be_2Rapport stage onee-be_2
Rapport stage onee-be_2
Mounir Kaali
 
Mémoire : Cloud iaas Slim Hannachi
Mémoire :  Cloud iaas Slim HannachiMémoire :  Cloud iaas Slim Hannachi
Mémoire : Cloud iaas Slim Hannachi
slim Hannachi
 
Plateforme d'enseignement à distance : efront
Plateforme d'enseignement à distance : efrontPlateforme d'enseignement à distance : efront
Plateforme d'enseignement à distance : efront
Khaled Fayala
 
Système de supervision des réseaux de capteurs sans fil
Système de supervision des réseaux de capteurs sans filSystème de supervision des réseaux de capteurs sans fil
Système de supervision des réseaux de capteurs sans fil
Samia HJ
 
Rapport- Conception et réalisation d'une plateforme social learning
Rapport- Conception et réalisation d'une plateforme social learningRapport- Conception et réalisation d'une plateforme social learning
Rapport- Conception et réalisation d'une plateforme social learning
Rouâa Ben Hammouda
 
Rapport PFE Ingénieurs - ULT-2016 - Hamza Mefteh fini
Rapport PFE Ingénieurs - ULT-2016 - Hamza Mefteh finiRapport PFE Ingénieurs - ULT-2016 - Hamza Mefteh fini
Rapport PFE Ingénieurs - ULT-2016 - Hamza Mefteh finiHamza Mefteh
 

Similaire à Rapport du projet fin d'etudes (20)

Torkhanikarima-MémoireMastereProRx&telecom-FST2015-, Supervision et Monitorin...
Torkhanikarima-MémoireMastereProRx&telecom-FST2015-, Supervision et Monitorin...Torkhanikarima-MémoireMastereProRx&telecom-FST2015-, Supervision et Monitorin...
Torkhanikarima-MémoireMastereProRx&telecom-FST2015-, Supervision et Monitorin...
 
Torkhani karima-MémoireMastereProRx&telecom-FST2015-, Supervision et Monitori...
Torkhani karima-MémoireMastereProRx&telecom-FST2015-, Supervision et Monitori...Torkhani karima-MémoireMastereProRx&telecom-FST2015-, Supervision et Monitori...
Torkhani karima-MémoireMastereProRx&telecom-FST2015-, Supervision et Monitori...
 
orkhanikarima-MémoireMastereProRx&telecom-FST2015-, Supervision et Monitoring...
orkhanikarima-MémoireMastereProRx&telecom-FST2015-, Supervision et Monitoring...orkhanikarima-MémoireMastereProRx&telecom-FST2015-, Supervision et Monitoring...
orkhanikarima-MémoireMastereProRx&telecom-FST2015-, Supervision et Monitoring...
 
Pfe master fst_final_decembre2015
Pfe master fst_final_decembre2015Pfe master fst_final_decembre2015
Pfe master fst_final_decembre2015
 
rapport fin d'etude
rapport fin d'etuderapport fin d'etude
rapport fin d'etude
 
Rapport final
Rapport finalRapport final
Rapport final
 
392327755-Conception-Et-Realisation-d-Un-Site-Web-Et-Une-Application-Mobile-d...
392327755-Conception-Et-Realisation-d-Un-Site-Web-Et-Une-Application-Mobile-d...392327755-Conception-Et-Realisation-d-Un-Site-Web-Et-Une-Application-Mobile-d...
392327755-Conception-Et-Realisation-d-Un-Site-Web-Et-Une-Application-Mobile-d...
 
Rapport-PFE2013-RahmaGhali-Gestion des Candidatures(Jaas,Primefaces,JFS2,JPA)
Rapport-PFE2013-RahmaGhali-Gestion des Candidatures(Jaas,Primefaces,JFS2,JPA)Rapport-PFE2013-RahmaGhali-Gestion des Candidatures(Jaas,Primefaces,JFS2,JPA)
Rapport-PFE2013-RahmaGhali-Gestion des Candidatures(Jaas,Primefaces,JFS2,JPA)
 
YouTaQA : Système de Questions-Réponses Intelligent basé sur le Deep Learning...
YouTaQA : Système de Questions-Réponses Intelligent basé sur le Deep Learning...YouTaQA : Système de Questions-Réponses Intelligent basé sur le Deep Learning...
YouTaQA : Système de Questions-Réponses Intelligent basé sur le Deep Learning...
 
Rapport PFE réalisation d’un Framework Kinect
Rapport PFE réalisation d’un Framework KinectRapport PFE réalisation d’un Framework Kinect
Rapport PFE réalisation d’un Framework Kinect
 
Rapport finiale
Rapport finialeRapport finiale
Rapport finiale
 
Thèse+Kawtar+RETMI.pdf
Thèse+Kawtar+RETMI.pdfThèse+Kawtar+RETMI.pdf
Thèse+Kawtar+RETMI.pdf
 
Rapport Projet ERP - Plateforme Odoo 12 (PFE Licence)
Rapport Projet ERP - Plateforme Odoo 12 (PFE Licence)Rapport Projet ERP - Plateforme Odoo 12 (PFE Licence)
Rapport Projet ERP - Plateforme Odoo 12 (PFE Licence)
 
Rapport de stage communication visuelle, événementiel et site WordPress à ISAMM
Rapport de stage communication visuelle, événementiel  et site WordPress à ISAMMRapport de stage communication visuelle, événementiel  et site WordPress à ISAMM
Rapport de stage communication visuelle, événementiel et site WordPress à ISAMM
 
Rapport stage onee-be_2
Rapport stage onee-be_2Rapport stage onee-be_2
Rapport stage onee-be_2
 
Mémoire : Cloud iaas Slim Hannachi
Mémoire :  Cloud iaas Slim HannachiMémoire :  Cloud iaas Slim Hannachi
Mémoire : Cloud iaas Slim Hannachi
 
Plateforme d'enseignement à distance : efront
Plateforme d'enseignement à distance : efrontPlateforme d'enseignement à distance : efront
Plateforme d'enseignement à distance : efront
 
Système de supervision des réseaux de capteurs sans fil
Système de supervision des réseaux de capteurs sans filSystème de supervision des réseaux de capteurs sans fil
Système de supervision des réseaux de capteurs sans fil
 
Rapport- Conception et réalisation d'une plateforme social learning
Rapport- Conception et réalisation d'une plateforme social learningRapport- Conception et réalisation d'une plateforme social learning
Rapport- Conception et réalisation d'une plateforme social learning
 
Rapport PFE Ingénieurs - ULT-2016 - Hamza Mefteh fini
Rapport PFE Ingénieurs - ULT-2016 - Hamza Mefteh finiRapport PFE Ingénieurs - ULT-2016 - Hamza Mefteh fini
Rapport PFE Ingénieurs - ULT-2016 - Hamza Mefteh fini
 

Dernier

Alternative au 3eme lien et complement au Tramway de la ville de Quebec Rev 1...
Alternative au 3eme lien et complement au Tramway de la ville de Quebec Rev 1...Alternative au 3eme lien et complement au Tramway de la ville de Quebec Rev 1...
Alternative au 3eme lien et complement au Tramway de la ville de Quebec Rev 1...
Daniel Bedard
 
PFE MASTER en Développement d’une Application E-commerce avec la Technologie ...
PFE MASTER en Développement d’une Application E-commerce avec la Technologie ...PFE MASTER en Développement d’une Application E-commerce avec la Technologie ...
PFE MASTER en Développement d’une Application E-commerce avec la Technologie ...
ayoub_anbara96
 
S210-S-27.04-chaudiere-à-vapeur bilan thermique
S210-S-27.04-chaudiere-à-vapeur bilan thermiqueS210-S-27.04-chaudiere-à-vapeur bilan thermique
S210-S-27.04-chaudiere-à-vapeur bilan thermique
ALIIAE
 
Rénovation des prairies sans labour est-ce possible en bio.pdf
Rénovation des prairies sans labour est-ce possible en bio.pdfRénovation des prairies sans labour est-ce possible en bio.pdf
Rénovation des prairies sans labour est-ce possible en bio.pdf
idelewebmestre
 
PFE ABDOUS BERRI 2024, RAPPORT COMPLET RETA FINAL.pdf
PFE ABDOUS BERRI 2024, RAPPORT COMPLET RETA FINAL.pdfPFE ABDOUS BERRI 2024, RAPPORT COMPLET RETA FINAL.pdf
PFE ABDOUS BERRI 2024, RAPPORT COMPLET RETA FINAL.pdf
iheberry
 
Alternative - Complément au Tramway et 3 ème lien de la ville de Quebec (PDF)
Alternative - Complément au Tramway  et 3 ème lien de la ville de Quebec (PDF)Alternative - Complément au Tramway  et 3 ème lien de la ville de Quebec (PDF)
Alternative - Complément au Tramway et 3 ème lien de la ville de Quebec (PDF)
Daniel Bedard
 
SRE - Mythes et Réalités - Voxxed 2024.pdf
SRE - Mythes et Réalités - Voxxed 2024.pdfSRE - Mythes et Réalités - Voxxed 2024.pdf
SRE - Mythes et Réalités - Voxxed 2024.pdf
Henri Gomez
 
Note Agro-climatique et prairies n°4 - Juin 2024
Note Agro-climatique et prairies n°4 - Juin 2024Note Agro-climatique et prairies n°4 - Juin 2024
Note Agro-climatique et prairies n°4 - Juin 2024
idelewebmestre
 

Dernier (8)

Alternative au 3eme lien et complement au Tramway de la ville de Quebec Rev 1...
Alternative au 3eme lien et complement au Tramway de la ville de Quebec Rev 1...Alternative au 3eme lien et complement au Tramway de la ville de Quebec Rev 1...
Alternative au 3eme lien et complement au Tramway de la ville de Quebec Rev 1...
 
PFE MASTER en Développement d’une Application E-commerce avec la Technologie ...
PFE MASTER en Développement d’une Application E-commerce avec la Technologie ...PFE MASTER en Développement d’une Application E-commerce avec la Technologie ...
PFE MASTER en Développement d’une Application E-commerce avec la Technologie ...
 
S210-S-27.04-chaudiere-à-vapeur bilan thermique
S210-S-27.04-chaudiere-à-vapeur bilan thermiqueS210-S-27.04-chaudiere-à-vapeur bilan thermique
S210-S-27.04-chaudiere-à-vapeur bilan thermique
 
Rénovation des prairies sans labour est-ce possible en bio.pdf
Rénovation des prairies sans labour est-ce possible en bio.pdfRénovation des prairies sans labour est-ce possible en bio.pdf
Rénovation des prairies sans labour est-ce possible en bio.pdf
 
PFE ABDOUS BERRI 2024, RAPPORT COMPLET RETA FINAL.pdf
PFE ABDOUS BERRI 2024, RAPPORT COMPLET RETA FINAL.pdfPFE ABDOUS BERRI 2024, RAPPORT COMPLET RETA FINAL.pdf
PFE ABDOUS BERRI 2024, RAPPORT COMPLET RETA FINAL.pdf
 
Alternative - Complément au Tramway et 3 ème lien de la ville de Quebec (PDF)
Alternative - Complément au Tramway  et 3 ème lien de la ville de Quebec (PDF)Alternative - Complément au Tramway  et 3 ème lien de la ville de Quebec (PDF)
Alternative - Complément au Tramway et 3 ème lien de la ville de Quebec (PDF)
 
SRE - Mythes et Réalités - Voxxed 2024.pdf
SRE - Mythes et Réalités - Voxxed 2024.pdfSRE - Mythes et Réalités - Voxxed 2024.pdf
SRE - Mythes et Réalités - Voxxed 2024.pdf
 
Note Agro-climatique et prairies n°4 - Juin 2024
Note Agro-climatique et prairies n°4 - Juin 2024Note Agro-climatique et prairies n°4 - Juin 2024
Note Agro-climatique et prairies n°4 - Juin 2024
 

Rapport du projet fin d'etudes

  • 1. 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 DE FIN D’ETUDES Présenté en vue de l’obtention du Diplôme National d’Ingénieur en Informatique Spécialité : Informatique Décisionnelle Par Tahani RIAHI 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 : Monsieur Nizar ELHAJ FERJANI Réalisé au sein de Complexe ElKasbah TUNISIE TELECOM Soutenu le 21 Juin 2018 devant la commission composée de : Président : Mme Aicha GUERFACHI Rapporteur : Mme Wiem TRABELSI Membre : Mme Afef SELMI Année Universitaire 2017 – 2018
  • 2.
  • 3. AVANT PROPOS Ce document entre dans le cadre de la préparation d’un rapport de projet de fin d’études en vue de l’obtention du diplôme d’Ingénieur en Informatique Décisionnelle au sein de l’Ecole Polytechnique Méditerranéenne Privée de Tunis EPMPT. C’est ainsi que nous avons eu l’occasion de préparer notre projet de fin d’étude intitulé « Conception et Réalisation d’une application web de Reporting et Statistics des rejets de communication entre les différents Systèmes d’Information de Tunisie Télécom » proposé par Tunisie Télécom, la Direction Centrale des Systèmes d’Information. Ce projet est un apport très bénéfique quant au perfectionnement des connaissances de l’étudiant dans le domaine informatique et pour avoir l’opportunité d’appliquer ses connaissances théoriques acquises tout au long de son cursus universitaire dans le cadre professionnel.
  • 4. Dédicaces De mon profond amour, de ma reconnaissance infinie, pour tous leurs sacrifices qu’ils n’ont jamais cessé de me fournir, je dédie ce travail aux plus chers du monde : À Mes parents pour tout l’amour, pour toute la tendresse, la gentillesse, les sacrifices et les prières ferventes qui m’ont accompagnée durant mes études. À Ma sœur Malek qui m’a inculquée un esprit de combativité et de persévérance et qui m’a toujours motivée dans mes études. À Mes frères Anis et Achref, Ma sœur Amani, Mon fiancé Hosni et toute ma famille qui m’ont toujours encouragée et qui sont toujours à côté de moi. À mes amis, et tous ceux qui me sont chers et qui m’ont toujours encouragée dans les moments de délicat, Je vous souhaite une vie pleine de joie et de bonheur. Je vous aime Tahani RIAHI
  • 5. Remerciements Je tiens à remercier toutes les personnes qui ont contribué à la réussite de mon stage de près ou de loin à la rédaction de mon rapport. Tout d’abord, je tiens à commencer par M. Nizar ELHAJ FERJANI mon encadrant à TUNISIE TELECOM pour son accueil, le temps qu’il a consacré pour moi et son partage de connaissances. Jeremercieaussi vivement mon enseignante MmeWiem TRABELSI pourses conseils académiques et sa disponibilité pour répondre à mes questions tout au long de mon stage. Pour finir, je remercierai toute personne m’ayant fourni de l’aide durant, avant et après ce stage.
  • 6. 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
  • 7. 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
  • 8. 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
  • 9. 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
  • 10. 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 Figure annexe 1. Interface d’authentification.............................................................. 66 Figure annexe 2. Message d’erreur lors d’une authentification incorrecte ................. 66 Figure annexe 3. Première interface de l’onglet « Paramètres ».................................. 67 Figure annexe 4. Message d'erreur ............................................................................... 67 Figure annexe 5. Récupération des informations du compte ....................................... 68 Figure annexe 6. Formulaire de modification .............................................................. 68 Figure annexe 7. Message de modification .................................................................. 69
  • 11. 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
  • 13. Introduction Générale 2 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 de fin d’études 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.
  • 14. Introduction Générale 3 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.
  • 15. 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
  • 16. Chapitre 1. Contexte général 5 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 :
  • 17. Chapitre 1. Contexte général 6 - 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.
  • 18. Chapitre 1. Contexte général 7 1.1.1 Organisation structurelle de 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, PDG Commerciale Ventes Actel Vente Entreprise Distrubution indirecte Marketing regionale support Service Assurance qualite clients CSC Reseaux Planification & Ingenerie Deploiement des reseaux Energie & Environment Optimisation & qualite materielle ROCS SAAF Moyens Achats Finances Juridique R.H Gestion previsionelle du personelle Support administratif & sociale Formations Directeur Regionale Affaires Regionale Figure 1. Organigramme TUNISIE TELECOM
  • 19. Chapitre 1. Contexte général 8 • 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 de fin d’études 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.
  • 20. Chapitre 1. Contexte général 9 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.
  • 21. Chapitre 1. Contexte général 10 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.
  • 22. Chapitre 1. Contexte général 11 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
  • 23. Chapitre 1. Contexte général 12 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] :
  • 24. Chapitre 1. Contexte général 13 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.
  • 25. 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
  • 26. Chapitre 2. Analyse et spécification des besoins 15 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
  • 27. Chapitre 2. Analyse et spécification des besoins 16 ➢ 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.
  • 28. Chapitre 2. Analyse et spécification des besoins 17 • 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
  • 29. Chapitre 2. Analyse et spécification des besoins 18 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.
  • 30. Chapitre 2. Analyse et spécification des besoins 19 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 » 2.3.3.1 Diagramme du cas d’utilisation 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 » 2.3.3.2 Identification du scénario 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 :
  • 31. Chapitre 2. Analyse et spécification des besoins 20 Cas d’utilisation « Générer des rapports » Objectif Permettre à l’utilisateur de générer des rapports 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. Scénario : - L’utilisateur s’authentifie. - 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. 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 ». - 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 » 2.3.4.1 Diagramme du cas d’utilisation La figure suivante présente le diagramme de cas d’utilisation : « Gérer un profil »
  • 32. Chapitre 2. Analyse et spécification des besoins 21 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 Description Précondition(s) : - La machine est connectée au réseau local de TUNISIE TELECOM. - Lancer l’application. - S’authentifier. - Charger les utilisateurs enregistrés dans la base de données. Scénario : - L’utilisateur s’authentifie. - 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.
  • 33. Chapitre 2. Analyse et spécification des besoins 22 Postcondition(s) : - les informations relatives à un profil seront affichées dans une nouvelle interface. 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 ». - 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 Description Précondition(s) : - La machine est connectée au réseau local de TUNISIE TELECOM. - Lancer l’application. - S’authentifier. - Charger les utilisateurs enregistrés dans la base de données. Scénario : - L’utilisateur s’authentifie. - 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.
  • 34. Chapitre 2. Analyse et spécification des besoins 23 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 ». - 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 » 2.3.5.1 Diagramme du cas d’utilisation 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. Une description détaillée du déroulement de cette opération est répertoriée dans le tableau 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 Description Précondition(s) : - La machine est connectée au réseau local de TUNISIE TELECOM.
  • 35. Chapitre 2. Analyse et spécification des besoins 24 - Lancer l’application. - S’authentifier. - Charger les rejets enregistrés dans la base de données. Scénario : - L’utilisateur s’authentifie. - Il affiche l’onglet « Rejets ». - Il affiche la liste des rejets. Postcondition(s) : - Les utilisateurs sont affichés dans un tableau. 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 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. Une description détaillée du déroulement de cette opération est répertoriée dans le tableau suivant : Cas d’utilisation « Supprimer un rejet » Objectif Permettre à l’utilisateur de supprimer un rejet de la liste des 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. Scénario : - L’utilisateur s’authentifie. - Il affiche l’onglet « Rejets ». - Il affiche la liste des rejets. - Il choisit le rejet qui va supprimer - Il clique sur le bouton « Supprimer » -Il supprime le rejet.
  • 36. Chapitre 2. Analyse et spécification des besoins 25 Postcondition(s) : - Le rejet se supprime de la liste des rejets affichés et de la base de données. 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 6. Description du cas d’utilisation « Supprimer un rejet » 2.3.6 Cas d’utilisation « Gérer les utilisateurs » 2.3.6.1 Diagramme du cas d’utilisation 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. Description Précondition(s) : - La machine est connectée au réseau local de TUNISIE TELECOM. - Lancer l’application. - S’authentifier.
  • 37. Chapitre 2. Analyse et spécification des besoins 26 - Charger les utilisateurs enregistrés dans la base de données. Scénario : - L’utilisateur s’authentifie. - Il affiche l’onglet « Utilisateur ». - Il affiche la liste des utilisateurs. Postcondition(s) : - Les utilisateurs sont affichés dans un tableau. 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 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. Une description détaillée du déroulement de cette opération est répertoriée dans le tableau suivant : Cas d’utilisation « Ajouter un utilisateur » Objectif Permettre à l’administrateur d’ajouter, via un formulaire, un nouvel utilisateur de l’application. Description Précondition(s) : - La machine est connectée au réseau local de TUNISIE TELECOM. - Lancer l’application. - S’authentifier. - Charger les utilisateurs enregistrés dans la base de données. Scénario : - L’utilisateur s’authentifie. - Il affiche l’onglet « Utilisateurs ». - Il remplit le formulaire d’ajout. - Il confirme l’ajout. Postcondition(s) : - L’utilisateur sera ajouté à la base.
  • 38. Chapitre 2. Analyse et spécification des besoins 27 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 ». - 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 ». Une description détaillée du déroulement de cette opération est répertoriée dans le tableau suivant : Cas d’utilisation « Supprimer un utilisateur » Objectif Permettre à l’administrateur de supprimer un utilisateur de la liste des utilisateurs. Description Précondition(s) : - La machine est connectée au réseau local de TUNISIE TELECOM. - Lancer l’application. - S’authentifier. - Charger les utilisateurs enregistrés dans la base de données. Scénario : - L’utilisateur s’authentifie. - 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. 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 9. Description du cas d’utilisation « Supprimer un utilisateur »
  • 39. Chapitre 2. Analyse et spécification des besoins 28 2.3.7 Cas d’utilisation « Injecter les rejets » 2.3.7.1 Diagramme du cas d’utilisation La figure suivante présente le diagramme de cas d’utilisation : « Injecter les rejets » Figure 9. Diagramme de cas d’utilisation « Injecter les rejets » 2.3.7.2 Identification du scénario Il permet à l’administrateur d’injecter les rejets à partir un fichier CSV. Une description détaillée du déroulement de cette opération est répertoriée dans le tableau 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. Description Précondition(s) : - La machine est connectée au réseau local de TUNISIE TELECOM. - Lancer l’application. - S’authentifier. Scénario : - L’utilisateur s’authentifie. - Il affiche l’onglet « Rejets ». - 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 ».
  • 40. Chapitre 2. Analyse et spécification des besoins 29 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. 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 ». - 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 » 2.3.8.1 Diagramme du cas d’utilisation 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 » 2.3.8.2 Identification du scénario Il permet à l’administrateur de supprimer tous les rejets enregistrés dans la base de données en une seule fois. Une description détaillée du déroulement de cette opération est répertoriée dans le tableau suivant : Cas d’utilisation « Supprimer tous les rejets » Objectif Permettre à l’administrateur de supprimer tous les rejets en une seule fois. Description Précondition(s) : - La machine est connectée au réseau local de TUNISIE TELECOM. - Lancer l’application.
  • 41. Chapitre 2. Analyse et spécification des besoins 30 - S’authentifier. - Charger les rejets enregistrés dans la base de données. Scénario : - L’utilisateur s’authentifie. - Il affiche l’onglet « Rejets ». - 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. 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 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.
  • 42. Chapitre 3 CONCEPTION ET CHOIX TECHNOLOGIQUES Plan 1 Conception Détaillée ………………………………………………………………… 33 2 Conception architecturale …………………………………………………………… 42 3 Choix technologiques ……………………………………………………………….. 45
  • 43. Chapitre 3. Conception et choix technologiques 32 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 :
  • 44. Chapitre 3. Conception et choix technologiques 33 Figure 11. Diagramme de Classes
  • 45. Chapitre 3. Conception et choix technologiques 34 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
  • 46. Chapitre 3. Conception et choix technologiques 35 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 ».
  • 47. Chapitre 3. Conception et choix technologiques 36 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 »
  • 48. Chapitre 3. Conception et choix technologiques 37 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 »
  • 49. Chapitre 3. Conception et choix technologiques 38 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 »
  • 50. Chapitre 3. Conception et choix technologiques 39 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 »
  • 51. Chapitre 3. Conception et choix technologiques 40 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 »
  • 52. Chapitre 3. Conception et choix technologiques 41 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 :
  • 53. Chapitre 3. Conception et choix technologiques 42 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 :
  • 54. Chapitre 3. Conception et choix technologiques 43 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.
  • 55. Chapitre 3. Conception et choix technologiques 44 • 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].
  • 56. Chapitre 3. Conception et choix technologiques 45 • 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].
  • 57. Chapitre 3. Conception et choix technologiques 46 • 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é.
  • 58. Chapitre 4 REALISATION Plan 1 Environnement de travail ……………………………………………………………. 49 2 Phase d’implémentation ……………………………………………………………... 52
  • 59. Chapitre 4. Réalisation 48 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.
  • 60. Chapitre 4. Réalisation 49 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.
  • 61. Chapitre 4. Réalisation 50 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
  • 62. Chapitre 4. Réalisation 51 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.
  • 63. Chapitre 4. Réalisation 52 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
  • 64. Chapitre 4. Réalisation 53 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.
  • 65. Chapitre 4. Réalisation 54 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.
  • 66. Chapitre 4. Réalisation 55 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
  • 67. Chapitre 4. Réalisation 56 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
  • 68. Chapitre 4. Réalisation 57 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
  • 69. Chapitre 4. Réalisation 58 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.
  • 70. Chapitre 4. Réalisation 59 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
  • 71. Chapitre 4. Réalisation 60 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é.
  • 73. Conclusion générale 62 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 de fin d’études. Ce travail a été effectué au sein de Complexe ElKasbah 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 de fin d’étude 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 durant notre parcours académique à l’EPMPT : d’approfondir nos compétences et découvrir le milieu professionnel avec tout ce qu’il implique comme responsabilité et diligence.
  • 75. Webographie 64 [1] : Tunisie Telecom : définition de Tunisie Telecom et synonymes de Tunisie Telecom. Adresse : http://dictionnaire.sensagent.leparisien.fr/Tunisie%20Telecom/fr-fr/ [2] : tunisie telecom. Adresse : http://tunisie-telecom.e-monsite.com/ [3] : Les fichiers log, des indicateurs utiles. Adresse : https://www.journaldunet.com/developpeur/algo-methodes/tutoriel-pratique/les- fichiers-log-des-indicateurs-utiles.shtml [4] : E. de access-dev. (2010). La Gestion de projet. Adresse : http://www.access- dev.com/access-dev/la-gestion-de-projet-methodes-classiques-vsmethodes-agiles/ [5] : E. de uml-sysml. (2006). Processus de modélisation. Adresse : http://www.uml- sysml.org/modelisation-objet/processus-de-modelisation [6] : E. de Spring. (2016). Spring Docs.Adresse : https://spring.io/docs/reference [7] : Jasper Reports Reporting Open Source. Adresse : https://www.next- decision.fr/editeurs/restitution/jasper-reports [8] : Prenez e main Bootstrap (Mise à jour le 04/05/2018). Mise en route. Adresse : https://openclassrooms.com/courses/prenez-en-main-bootstrap/mise-en-route-8 [9] : Le Tutoriel de Spring Boot et Thymeleaf. Adresse : https://o7planning.org/fr/11545/le-tutoriel-de-spring-boot-et-thymeleaf [10] : Highcharts : des graphiques animés et dynamiques (30 / 07 / 2015). Adresse : https://www.oboqo.com/blog/highcharts-graphiques-animes-dynamiques/ [11] : Power AMC, modélisation de données – Next Decision. Adresse : https://www.next-decision.fr/editeurs/autres/sap-power-amc [12] : Introduction à l’utilisation d’eclipse. Adresse : http://www.enseignement.polytechnique.fr/informatique/profs/Julien.Cervelle/eclipse/ [13] : Microsoft SQL Server – Wikilivres. Adresse : https://fr.wikibooks.org/wiki/Microsoft_SQL_Server
  • 77. Annexes 66 Annexe 1. Interfaces finales 1. Interface d’authentification : Pour limiter l’accès seulement aux utilisateurs autorisés et selon leurs droits d’accès, chacun d’entre eux doit saisir un login et mot de passe pour s’authentifier. La figure annexe 1 montre l’interface d’authentification de notre application. Figure annexe 1. Interface d’authentification Après avoir rempli ces champs, l’application consulte la base de données et vérifie la saisie de l’utilisateur. En cas d’échec d’authentification, elle lui affiche le message « Nom d'utilisateur ou mot de passe incorrecte » Figure annexe 2. Message d’erreur lors d’une authentification incorrecte
  • 78. Annexes 67 2. Interface de modification les paramètres d’un profil La modification des paramètres d’un profil est nécessaire pour garantir la confidentialité. Pour modifier ces paramètres nous avons implémenté une interface pour la modification dans l’onglet « Paramètres » La figure annexe 3 nous montre la première vue de l’interface. Figure annexe 3. Première interface de l’onglet « Paramètres » Si nous avons saisi un login ou un mot de passe incorrecte ou tous les deux nous allons avoir un message d’erreur. La figure annexe suivante nous montre ceci. Figure annexe 4. Message d'erreur
  • 79. Annexes 68 Après la saisie des paramètres du compte, le login et le mot de passe, nous allons obtenir une amélioration dans la vue de l’interface. Nous récupérer les informations du profil comme nous montre la figure annexe 5. Figure annexe 5. Récupération des informations du compte Pour modifier les paramètres du profil affichés dans la dernière figure l’utilisateur clique sur le bouton « Modifier les paramètres du compte », par la suite un formulaire de modification du profil va s’afficher à droite de l’utilisateur. La figure annexe suivante nous montre le formulaire. Figure annexe 6. Formulaire de modification
  • 80. Annexes 69 Après la saisie des nouveaux paramètres l’utilisateur clique sur le bouton « Enregistrer les modifications ». Un message de modification va s’afficher. Figure annexe 7. Message de modification