SlideShare une entreprise Scribd logo
1  sur  110
Télécharger pour lire hors ligne
Projet de Fin d’Etudes ISIGK 2015/2016
I
Dédicaces
Après avoir rendu grâce â Dieu le tout puissant, je dédis ce travail
À
Mes chers parents
Aucun hommage ne pourrait être à la hauteur de l’amour et de l’affection
dont ils ne cessent de nous combler.
Qu’ils trouvent dans ce travail un témoignage de nos profond amour et
éternelle reconnaissance.
À
Mes chères frères et sœurs
Pour leur soutien, leur patience et leur encouragement.
Et spécialement à Tassnim pour son aide.
À
Ma famille et Mes amis
Pour leur aide et leur soutien moral durant l’élaboration du projet de fin
d’études.
Projet de Fin d’Etudes ISIGK 2015/2016
II
Remerciements
Au terme de ce travail, je tiens à remercier tous ceux qui ont contribué à la
réalisation de ce Projet de Fin d’Etudes, et en particulier :
Mon encadreur à l’ISIGK: Madame Imen Mami,
pour la qualité de son encadrement, sa disponibilité, son aide précieuse et ses
conseils constructif qui m’ont permis de mener à terme ce projet.
Ainsi que mon encadreur a Tunisie Telecom :
Monsieur Mouadh Rameh,
qui a eu la bienveillance de diriger ce travail en me prodiguant conseils,
directives et encouragements.
Mes sincères remerciements à tous les personnels,
les ingénieurs et les techniciens de Tunisie Telecom,
qui n’ont jamais cessé de m’apporter leur aide tout au long de ce travail.
J’ai et le plaisir de témoigner ma reconnaissance à tous mes
enseignants de l’ISIG, pour le savoir et le savoir-faire qu’ils m’ont
généreusement inculqués.
Projet de Fin d’Etudes ISIGK 2015/2016
III
Table des matières
Introduction Générale .....................................................................................................1
Chapitre 1 : Identification des besoins............................................................................2
1.1 Objectifs :..............................................................................................................2
1.2 Présentation de Tunisie télécom : .........................................................................2
1.2.1 Regard historique : .........................................................................................2
1.2.2 L’organisation de TUNISIE TELECOM :.....................................................3
1.3 Présentation de l'unité Radio GSM Kairouan :.....................................................4
1.4 Problématique : .....................................................................................................4
1.5 Solution :...............................................................................................................5
1.6 Méthodologie de travail :......................................................................................5
1.6.1 Démarche de la méthodologie :......................................................................6
Conclusion : ................................................................................................................6
Chapitre 2 : Conception « Phase d’incubation » ............................................................7
2.1 Choix du langage de conception adaptés UML :..................................................7
2.2 Spécification des besoins :....................................................................................7
2.2.1 Description du contexte du système :...........................................................8
2.2.2 Spécification des besoins fonctionnels :.......................................................8
2.2.3 Besoins non fonctionnels : .........................................................................12
2.2.4 Identification des acteurs et des cas d’utilisation et affectation des priorités :
...........................................................................................................................................13
2.2.5 Raffinement des cas d’utilisation prioritaire :............................................14
2.2.6 Prototype des interfaces utilisateurs :...........................................................18
2.3 Analyse des cas d’utilisation prioritaires :..........................................................18
Projet de Fin d’Etudes ISIGK 2015/2016
IV
2.3.1 Traçabilité entre le modèle de cas d’utilisation (MCU) et le modèle
d’analyse (MA) : ...............................................................................................................19
2.3.2 Diagrammes de classes d’analyse :..............................................................24
2.3.3 Diagrammes de collaboration : ....................................................................27
2.4 Conception des cas d’utilisation prioritaires :.....................................................32
2.4.1 Diagrammes des classes de conception :......................................................32
2.4.2 Diagrammes de séquences : .........................................................................39
Conclusion : ..............................................................................................................46
Chapitre 3 : Conception « Phase d’élaboration » .........................................................47
3.1 Capture des besoins : ..........................................................................................47
3.1.1 Raffinement des cas d’utilisations secondaires :..........................................47
3.2 Analyses des cas des utilisations secondaires :...................................................49
3.2.1 Traçabilité entre le modèle de cas d’utilisation (MCU) et le modèle
d’analyse (MA) : ...............................................................................................................49
3.2.2 Diagrammes de classes d’analyse :..............................................................52
3.2.3 Diagrammes de collaboration : ....................................................................54
3.3 Conception des cas d’utilisation secondaire : .....................................................56
3.3.1 Diagrammes de classes de conception :.......................................................56
3.3.2 Diagrammes de séquences :.......................................................................60
Conclusion : ..............................................................................................................67
Chapitre 4 : Conception « Phase de construction »......................................................68
4.1 Capture des besoins : ..........................................................................................68
4.1.1 Raffinement des cas d’utilisation tertiaires :................................................68
4.2 Analyse : .............................................................................................................71
4.2.1 Traçabilité entre le modèle de cas d’utilisation (MCU) et le modèle
d’analyse (MA) : ...............................................................................................................71
4.2.2 Diagrammes de classes d’analyse :..............................................................73
Projet de Fin d’Etudes ISIGK 2015/2016
V
4.2.3 Digrammes de collaboration : ......................................................................75
4.3 Conception :........................................................................................................78
4.3.1 Diagrammes des classes de conception :......................................................78
4.3.2 Diagrammes de séquences : .........................................................................82
4.4 Diagramme de classe des entités :.......................................................................86
Conclusion : ..............................................................................................................87
Chapitre 5 : Conception « Phase de transition »...........................................................89
5.1 Environnement logiciel :.....................................................................................89
5.2 Enchainement des interfaces utilisateur :............................................................90
5.2.1 Interface d’authentification :........................................................................90
5.2.2 Interface d’accueil :......................................................................................91
5.2.3 Interface « Gérer technicien » :....................................................................91
5.2.4 Interface « Ajouter technicien » :.................................................................92
5.2.5 Interface « Administration » : ......................................................................93
5.2.6 Interface « Mission » :..................................................................................94
5.2.7 Interface « Historique des pannes » .............................................................95
Conclusion : ..............................................................................................................96
Conclusion générale......................................................................................................97
Bibliographie ................................................................................................................98
Projet de Fin d’Etudes ISIGK 2015/2016
VI
Liste des figures
Figure 1 : L’organisation de Tunisie télécom.................................................................3
Figure 2.1 : Diagramme de contexte...............................................................................9
Figure 2-2 : Diagramme de cas d’utilisation Global « Gestion des pannes de BTS » .10
Figure 2-3 : Architecture de l’application « Gestion de panne de BTS ».....................13
Figure 2-4 : Cas d'utilisation « S'identifier ». ...............................................................14
Figure 2-5 : Cas d'utilisation « Ajouter technicien ». ...................................................14
Figure 2-6 : Cas d’utilisation « Suivi des pannes ». .....................................................15
Figure 2-7 : Cas d'utilisation « Affecter panne au technicien »....................................15
Figure 2-8 : Cas d’utilisation « Consulter la liste des pannes »....................................16
Figure 2.9 : Cas d’utilisation « Consulter les ordres de mission »...............................16
Figure 2-10 : Cas d'utilisation « Changer l’état de panne »..........................................17
Figure 2.11 : Prototype d’interface « authentification pour technicien ».....................18
Figure 2-12 : le cas d’utilisation « S’identifier »..........................................................19
Figure 2-13 : Cas d’utilisation « Ajouter technicien » .................................................20
Figure 2-14 : Cas d’utilisation « Suivi des pannes »....................................................20
Figure 2.15 : Cas d’utilisation « Affecter panne au technicien » .................................21
Projet de Fin d’Etudes ISIGK 2015/2016
VII
Figure 2.16 : Cas d’utilisation « Consulter les ordres de mission ».............................22
Figure 2.17 : Cas d’utilisation « Consulter la liste des pannes »..................................23
Figure 2.18 : Cas d’utilisation « Changer l’état de panne » .........................................24
Figure 2.19 : Cas d’utilisation « S’identifier ».............................................................24
Figure 2.20 : Cas d’utilisation « Ajouter Technicien » ................................................25
Figure 2.21 : Cas d’utilisation « Suivi des Pannes » ....................................................25
Figure 2.22 : Cas d’utilisation « Affecter panne au technicien » .................................25
Figure 2.23 : Cas d’utilisation « Consulter la liste des pannes »..................................26
Figure 2.24 : Cas d’utilisation « Consulter ordre de mission »....................................26
Figure 2.25 : Cas d’utilisation « Changer l’état des pannes »......................................27
Figure 2.26 : Diagramme de collaboration relatif au Cas d’utilisation « S’identifier »27
Figure 2.27 : Diagramme de collaboration relatif au cas d’utilisation « Administrateur
Ajouter technicien » .................................................................................................................28
Figure 2.28 : Diagramme de collaboration relatif au cas d’utilisation « Suivi des
pannes »....................................................................................................................................29
Figure 2.29 : Diagramme de collaboration relatif au cas d’utilisation « Affecter panne
au technicien »..........................................................................................................................30
Figure 2-30 : Diagramme de collaboration relatif au cas d’utilisation « Consulter les
ordres de mission »...................................................................................................................30
Figure 2-31 : Diagramme de collaboration relatif au cas d’utilisation « Consulter la
liste des pannes »......................................................................................................................31
Figure 2-32 : Diagramme de collaboration relatif au cas d’utilisation « Changer l’état
de panne ».................................................................................................................................32
Figure 2-33 : Diagramme de classe de conception relatif au cas d’utilisation
« S’identifier »..........................................................................................................................33
Figure 2-34 : Diagramme de classe de conception relatif au cas d’utilisation « Ajouter
technicien »...............................................................................................................................34
Projet de Fin d’Etudes ISIGK 2015/2016
VIII
Figure 2-35 : Diagramme de classe de conception relatif au cas d’utilisation « Suivi
des pannes »..............................................................................................................................35
Figure 2.36 : Diagramme de classe de conception relatif au cas d’utilisation « Affecter
panne au technicien » ...............................................................................................................36
Figure 2-37 : Diagramme de classe de conception relatif au cas d’utilisation
« Consulter les ordres de mission »..........................................................................................37
Figure 2-38 : Diagramme de classe de conception relatif au cas d’utilisation
« Consulter la liste des pannes »...............................................................................................38
Figure 2-39 : Diagramme de classe de conception relatif au cas d’utilisation « Changer
l’état de panne »........................................................................................................................39
Figure 2-40 : Diagramme de séquences relatif au cas d’utilisation « S’identifier ».....40
Figure 2-41 : Diagramme de séquences relatif au cas d’utilisation « Ajouter technicien
»................................................................................................................................................41
Figure 2-42 : Diagramme de séquences relatif au cas d’utilisation « Suivi des pannes »
..................................................................................................................................................42
Figure 2.43 : Diagramme de séquences relatif au cas d’utilisation « Affecter panne au
technicien »...............................................................................................................................43
Figure 2-44 : Diagramme de séquences relatif au cas d’utilisation « Technicien
consulter ordre de mission ».....................................................................................................44
Figure 2-45 : Diagramme de séquences relatif au cas d’utilisation « Consulter la liste
des pannes »..............................................................................................................................45
Figure 2.46 : Diagramme de séquences relatif au cas d’utilisation « Changer l’état de
panne »......................................................................................................................................46
Figure 3.1 : cas d’utilisation « Modifier technicien »...................................................47
Figure 3.2 : Cas d’utilisation « Supprimer technicien »...............................................48
Figure 3.3 : Cas d’utilisation « Vérifier la disponibilité des matériaux ».....................48
Figure 3.4 : Diagramme de cas d’utilisation « Consulter historique des pannes ».......49
Figure 3.5 : Traçabilité entre MCU et MA relatif au cas d’utilisation « Modifier
technicien »...............................................................................................................................50
Projet de Fin d’Etudes ISIGK 2015/2016
IX
Figure 3.6 : Traçabilité entre MCU et MA relatif au cas d’utilisation « Supprimer
technicien »...............................................................................................................................50
Figure 3.7 : Traçabilité entre MCU et MA relatif au cas d’utilisation « Vérifier la
disponibilité des matériaux »....................................................................................................51
Figure 3.8 : Traçabilité entre MCU et MA relatif au cas d’utilisation « Consulter
historique des pannes ».............................................................................................................51
Figure 3.9 : Diagramme de classes d’analyse relatif au cas d’utilisation « Modifier
technicien »...............................................................................................................................52
Figure 3.10 : Diagramme de classes d’analyse relatif au cas d’utilisation « Supprimer
technicien »...............................................................................................................................52
Figure 3.11 : Diagramme de classes d’analyse relatif au cas d’utilisation « Vérifier la
disponibilité des matériaux »....................................................................................................53
Figure 3.12 : Diagramme de classes d’analyse relatif au cas d’utilisation « Consulter
historique des pannes ».............................................................................................................53
Figure 3.13 : Diagramme de collaboration relatif au cas d’utilisation « Modifier
technicien »...............................................................................................................................54
Figure 3.14 : Diagramme de collaboration relatif au cas d’utilisation « Supprimer
technicien »...............................................................................................................................55
Figure 3.15 : Diagramme de collaboration relatif au cas d’utilisation « Vérifier la
disponibilité des matériaux »....................................................................................................55
Figure 3.16 : Diagramme de collaboration relatif au cas d’utilisation « Consulter
historique des pannes ».............................................................................................................56
Figure 3.17 : Diagramme de classes de conception relatif au cas d’utilisation
« Modifier technicien » ............................................................................................................57
Figure 3.18 : Diagramme de classes de conception relatif au cas d’utilisation
« Supprimer technicien »..........................................................................................................58
Figure 3.19 : Diagramme de classes de conception relatif au cas d’utilisation « Vérifier
la disponibilité des matériaux »................................................................................................59
Figure 3.20 : Diagramme de classes de conception relatif au cas d’utilisation
« Consulter historique des pannes ».........................................................................................60
Projet de Fin d’Etudes ISIGK 2015/2016
X
Figure 3.21 : Diagramme de séquences relatif au cas d’utilisation « Modifier
technicien »...............................................................................................................................61
Figure 3.22 : Diagramme de séquences relatif au cas d’utilisation « Supprimer
technicien »...............................................................................................................................63
Figure 3.23 : Diagramme de séquences relatif au cas d’utilisation « Vérifier la
disponibilité des matériaux »....................................................................................................65
Figure 3.24 : Diagramme de séquences relatif au cas d’utilisation « Consulter
l’historique des pannes »..........................................................................................................66
Figure 4.1 : Diagramme de cas d’utilisation « Ajouter des matériaux »......................68
Figure 4.2 : Diagramme de cas d’utilisation « Modifier matériaux » ..........................69
Figure 4.3 : Diagramme de cas d’utilisation « Supprimer matériaux »........................69
Figure 4.4 : Diagramme de cas d’utilisation « Contacter administrateur »..................70
Figure 4.5 : Traçabilité entre MCU et MA relatif au cas d’utilisation « Ajouter
matériaux »...............................................................................................................................71
Figure 4.6 : Traçabilité entre MCU et MA relatif au cas d’utilisation « Modifier
matériaux »...............................................................................................................................72
Figure 4.7 : Traçabilité entre MCU et MA relatif au cas d’utilisation « Supprimer
matériaux »...............................................................................................................................72
Figure 4.8 : Traçabilité entre MCU et MA relatif au cas d’utilisation « Contacter
administrateur »........................................................................................................................73
Figure 4.9 : Diagramme de classes d’analyse relatif au cas d’utilisation « Ajouter
matériaux »...............................................................................................................................73
Figure 4.10 : Diagramme de classes d’analyse relatif au cas d’utilisation « Modifier
matériaux »...............................................................................................................................74
Figure 4.11 : Diagramme de classes d’analyse relatif au cas d’utilisation « Supprimer
matériaux »...............................................................................................................................74
Figure 4.12 : Diagramme de classes d’analyse relatif au cas d’utilisation « Contacter
administrateur »........................................................................................................................75
Projet de Fin d’Etudes ISIGK 2015/2016
XI
Figure 4.13 : Diagramme de collaboration relatif au cas d’utilisation « Ajouter
matériaux »...............................................................................................................................75
Figure 4.14 : Diagramme de collaboration relatif au cas d’utilisation « Modifier
matériaux »...............................................................................................................................76
Figure 4.15 : Diagramme de collaboration relatif au cas d’utilisation « Supprimer
matériaux »...............................................................................................................................77
Figure 4.16 : Diagramme de collaboration relatif au cas d’utilisation « Contacter
administrateur »........................................................................................................................77
Figure 4.17 : Diagramme de classes de conception relatif au cas d’utilisation « Ajouter
matériaux »...............................................................................................................................78
Figure 4.18 : Diagramme de classes de conception relatif au cas d’utilisation
« Modifier matériaux ».............................................................................................................79
Figure 4.19 : Diagramme de classes de conception relatif au cas d’utilisation
« Supprimer matériaux »..........................................................................................................80
Figure 4.20 : Diagramme de classes de conception relatif au cas d’utilisation
« Contacter administrateur » ....................................................................................................81
Figure 4.21 : Diagramme de séquences relatif au cas d’utilisation « Ajouter
matériaux »...............................................................................................................................82
Figure 4.22 : Diagramme de séquences relatif au cas d’utilisation « Modifier
matériaux »...............................................................................................................................83
Figure 4.23 : Diagramme de séquences relatif au cas d’utilisation « Supprimer
matériaux »...............................................................................................................................85
Figure 4.24 : Diagramme de séquences relatif au cas d’utilisation « Contacter
administrateur »........................................................................................................................85
Figure 5.1 : Interface « d’authentification ». ................................................................91
Figure 5.2 : Interface « d’accueil »...............................................................................91
Figure 5.3 : Interface « gérer technicien »....................................................................92
Figure 5.4 : Interface « Ajouter technicien »................................................................93
Figure 5.5 : Interface « Administration ». ....................................................................94
Projet de Fin d’Etudes ISIGK 2015/2016
XII
Figure 5.6 : Interface « Mission ».................................................................................95
Figure 5.7 : Interface « Historique des pannes »..........................................................96
Projet de Fin d’Etudes ISIGK 2015/2016
1
Introduction Générale
De nos jours, nous assistons à une apogée des nouvelles technologies et notamment la
téléphonie mobile et le réseau GSM (Global System for Mobile Communication). En effet, le
nombre d’abonnés au réseau GSM a eu une croissance colossale les dernières années et
comme principale conséquence, les exigences des abonnés en matière de qualité de service
sont de plus en plus importantes. En fait, dans un marché des télécommunications mobiles à
forte concurrence, la satisfaction du client passe au premier plan dans les objectifs des
opérateurs du réseau GSM. Pour cela, Tunisie Telecom a donné une grande importance à la
maintenance de son Réseau. C’est, effectivement, ici que se situe notre projet de fin d’études
qui avait pour but de réaliser un outil de gestion de pannes des BTS (Base Transceiver
Station). En fait, il sera utile en proposant une interface conviviale pour enregistrer les
intervenions et les pannes afin de réaliser un historique de l’activité maintenance. Ce mémoire
s’articule autour de quatre chapitres :
 Le premier chapitre, "Identification des besoins", met le projet dans son contexte
par une présentation de l’entreprise, du travail demandé et de la problématique à
résoudre.
 Le deuxième chapitre "Conception phase d’incubation", présente la capture des
besoins fonctionnels et techniques de l’application et l’identification des acteurs
nécessaires pour cette application.
 Le troisième chapitre "Conception « phase d’élaboration »", nous effectuerons
l’analyse et la conception de la majorité des cas d’utilisation.
 Le quatrième chapitre "la phase de construction", nous produirons le modèle
d’analyse et de conception de notre application.
 Le cinquième chapitre " la phase de transition" présente les choix techniques
adaptés, les environnements matériels et logiciel dont nous avons disposé pour la
réalisation de l’application ainsi qu'une description de l’application obtenue.
Projet de Fin d’Etudes ISIGK 2015/2016
2
Chapitre 1 : Identification des besoins
Introduction
Durant ce chapitre, nous présentons le cadre général de notre projet à travers la
présentation de l’organisme d’accueil ainsi que le contexte général de projet. Nous allons
présenter notre projet de fin d’étude réalisé au sein de la société « Tunisie Télécom » qui a
pour but d’appliquer la connaissance que nous avons apprise au sein de l’ISIGK (Institue
Supérieure d’Informatique et de Gestion de Kairouan) pour arriver à aboutir à la réalisation
d’une application Android de gestion de panne de BTS.
1.1 Objectifs :
L’objectif de notre projet est de créer une application Android qui facilite la gestion
des pannes de BTS. Cette application a pour objectif d’aider la société à réaliser les
différentes activités suivantes :
 Détecter et corriger rapidement les pannes
 Gérer les pannes à travers un équipement mobile
 Faciliter la communication entre administrateur et techniciens
 Améliorer la gestion du stock de matériels
 Satisfaire les clients/abonnées par la détection et la correction rapides des pannes
 Procurer un service plus rapide et de qualité et aux techniciens
1.2 Présentation de Tunisie télécom :
Dans cette partie nous présentons la société Tunisie Télécom à travers une
présentation de son histoire et de son organigramme. TUNISIE TELECOM désigne le nom
commercial de La Société National de télécommunication. Son but est de servir tous les
abonnés afin de les rapprocher pour mieux les servir. Tunisie Telecom a pour activité
principale la prestation de service, le développement, l’entretien et l’exploitation des réseaux
publics de téléphone et la transmission des données [1].
1.2.1 Regard historique :
 17 avril 1995 : Promulgation de la loi N° 36 portant la création de l’offre
nationale des télécommunications, dénomme TUNISIE TELECOM.
Projet de Fin d’Etudes ISIGK 2015/2016
3
 1er Janvier 1996 : Mise en place de l‘office nationale de
télécommunication.
 20 mars 1998 : Inauguration de la première ligne GSM.
 Décembre 1999 : Promulgation du décret n 2844 du 27 décembre 1999,
relatif au statut de TUNISIE TELECOM.
 Fin 2002 : Restructuration TUNISIE TELECOM en société anonyme.
 07 juillet 2004 : Signature de la convention d’interconnexion entre
TUNISIE TELECOM et Orascom Telecom TUNISIE.
 09 juillet 2004 : Premier conseil d’Administration de la Société Nationale
des Télécommunications suite à la transformation de TUNISIE TELECOM
en Société anonyme.
1.2.2 L’organisation de TUNISIE TELECOM :
Figure 1 : L’organisation de Tunisie télécom
Projet de Fin d’Etudes ISIGK 2015/2016
4
1.3 Présentation de l'unité Radio GSM Kairouan :
L’unité Radio GSM Kairouan fournit des services d’abonnés ordinaires et d’autres
services se rapportant aux réseaux d’entreprises. Elle offre également un ensemble de service
de transmission de données comme les réseaux de téléphonie fixe et téléphonie mobile GSM
ainsi que les réseaux publinet et publitel. Notre projet de fin d’étude a été réalisé au sein de
cette unité.
Les systèmes des radios communications mobiles, le GSM en particulier, est
aujourd’hui à la tête des systèmes cellulaires numérique et il offre un très grand nombre de
services permettant l’échange d’information entre deux ou plusieurs usagers avec une qualité
raisonnable.
Le BTS (base transeive station), en français station de transissions de base ou station
émettrice-réceptrice de base, est un des éléments de base du system cellulaire de téléphone
mobile GSM appelé plus communément antennes-relais. Elle est composée essentiellement
d’un élément d’interface avec la station de base contrôlant BSC (Base Station Controler),
d’un ou plusieurs émetteur récepteur (Transceiver.TRX) et d’une a trois antennes : elle forme
ainsi une cellule (base du maillage d’un réseau téléphonique mobile).
A Tunisie Télécom Kairouan, il existe deux BSC (Base Station Contrôler) pour
contrôler les stations RBS (Radio Base Station) de Kairouan. En cas de dérangement d’une
station, la RBS est reconfigurée à partir d'un logiciel appelé OMT (Operating and
Maintenance Terminal).
1.4 Problématique :
Dans un marché ouvert à la concurrence, le niveau de services offert aux abonnés est
une préoccupation de plus en plus importante pour l'entreprise. Pour respecter des exigences
clients de plus en plus strictes au niveau qualité et délai, les équipes de Tunisie télécom
doivent pallier les difficultés et les problèmes suivants que rencontrent ses techniciens :
 Difficultés à détecter rapidement les pannes de BTS.
 Dégradation de la qualité de service à cause du délai important entre le déclenchent
de la panne et sa détection.
 Insatisfaction du client en cas de détection tardive da la panne étant donné que le
service est lié directement aux abonnés des réseaux GSM
Projet de Fin d’Etudes ISIGK 2015/2016
5
1.5 Solution :
Pour résoudre ces différents problèmes, nous avons proposé dans le cadre de notre
projet de fin d’étude, une solution simple et efficace intitule « gestion de panne des BTS » qui
permet la recherche des pannes du BTS (Base Transeiver Station) de manière automatisée.
Cette solution est basée sur l’utilisation d’un (timer) pendant lequel il y a un accès aux
fichiers logs, qui regroupent toutes les informations sur les réseaux, et en cas d’une panne
dans ce laps de temps le programme l’indique et l’affiche au technicien.
Cette solution offre la possibilité de réduire les coûts temporels d’exploitation des
logiciels par leur utilisation directement en ligne sans faire chaque fois des saisies des
demandes pour détecter les pannes. De plus, elle permet à l’utilisateur de recevoir
l’information dans un délai de temps faible.
1.6 Méthodologie de travail :
Nous avons choisi la méthode de conception « Processus Unifié » pour la conception
et la mise en place de notre application. C’est un processus de développement logiciel, il
regroupe les activités à mener pour transformer les besoins d’un utilisateur en système
logiciel.
 Les caractéristiques essentielles du processus unifié sont :
 Le processus unifié est à base de composants.
 Le processus unifié est piloté par les cas d’utilisation : Il faut bien comprendre les
désirs et les besoins des futurs utilisateurs, le processus de développement sera
donc centré sur l'utilisateur (Les utilisateurs humains et/ou systèmes).
 Centré sur l’architecture : L’architecture émerge des besoins de l’entreprise, tels
qu’ils sont exprimés par les utilisateurs et autres intervenants et tels qu’ils sont
reflétés par les cas d’utilisation.
 Itératif et incrémental : Le développement d’un produit logiciel peut s’étendre sur
plusieurs mois. Nous n’allons pas tout développer d’un coup. Nous pouvons
découper le travail en plusieurs parties qui sont autant de mini projets. Chacun
d’entre eux représentant une itération qui donne lieu à un incrément.
 Le processus unifié utilise le langage UML : (Unified Modeling Language ou «
langage de modélisation unifié ») C’est un langage de modélisation graphique à
base De pictogrammes. Il est apparu dans le monde du génie logiciel, dans le cadre
Projet de Fin d’Etudes ISIGK 2015/2016
6
de la « Conception orientée objet ». UML est couramment utilisé dans les projets
logiciels.
1.6.1 Démarche de la méthodologie :
Chaque itération du processus unifié est composée de cinq activités : capture des
besoins, analyse, conception, implémentation et test. Les itérations peuvent être regroupées en
4 phases :
 La phase d’incubation qui permet de délimiter la portée du système (identification
des besoins et des acteurs ; analyse, conception, implémentation et test des cas
d’utilisation prioritaires)
 La phase d’élaboration (capture de nouveaux besoins ; analyse, conception
implémentation et test de la majorité des cas d’utilisation formulés)
 La phase de construction (capture des besoins restants ; analyse, conception
implémentation et test de tous les cas d’utilisation)
 La phase de transition qui finalise le produit (validation, mise en place,
installation, guide utilisateurs).
Conclusion :
Durant ce chapitre, nous avons présenté le cadre général de notre projet à travers la
présentation de l’organisme d’accueil ainsi que le contexte général de notre projet de fin
d’étude.
Le chapitre suivant sera consacré à la phase d’incubation du processus unifié.
Projet de Fin d’Etudes ISIGK 2015/2016
7
Chapitre 2 : Conception « Phase d’incubation »
Introduction :
La conception est un processus créatif. C’est la phase la plus importante dans le cycle
de développement d’un projet. C’est pour cela, au niveau de ce chapitre, nous allons
commencer tout d’abord par présenter et expliciter la première phase de la conception « Phase
d’Incubation » qui donne une vue du projet sous forme du produit fini.
L’étape de la spécification constitue la base d’un bon départ de tout travail. En effet,
l’adéquation de toute application à réaliser aux besoins de ses utilisateurs garantira sa réussite.
Pour cela, nous allons étudier dans ce chapitre les besoins fonctionnels et non fonctionnels de
notre client. Nous présentons une spécification semi formelle de ces besoins par les
diagrammes de cas d’utilisation suivant la modélisation UML.
2.1 Choix du langage de conception adaptés UML :
La spécification des besoins sera représentée par les diagrammes de cas d’utilisation
suivant la modélisation UML, l’acronyme de « Unified Modeling Language ». UML est
langage de modélisation unifié. Il est couramment utilisé dans les projets logiciels, il offre un
standard de modélisation pour représenter l’architecture logicielle. Les principaux éléments
représentables à l’aide de l’UML sont : les acteurs, les processus, les activités des objets et les
schémas de la base de données. Le choix d’UML peut être justifié par les raisons suivantes :
 Un langage formel et normalisé par l’OMG (Object Mangement Group)
 Une garantie de stabilité.
 Un langage sans ambigüité.
 Un support de communication performant.
2.2 Spécification des besoins :
La spécification des besoins est une étape essentielle pour la réussite des projets .C’est
dans cet esprit que tout concepteur doit veiller à la conformité de son application aux
spécifications d’utilisateur .C’est à ce stade qu’intervient la spécification des besoins qui est
une sorte de contrat entre le concepteur, le développeur et ses clients, évitant ainsi tout risque
de malentendu et de mauvaises surprises .Dans ce chapitre, nous définissons les besoins
fonctionnels et non fonctionnels de cette solution.
Projet de Fin d’Etudes ISIGK 2015/2016
8
2.2.1 Description du contexte du système :
L’organisme « Tunisie Telecom » souhaite informatiser son système de la gestion des
pannes de son BTS. Nous allons donc étudier les différentes fonctions de cette gestion :
 Détecter la panne dans un BTS en utilisant un équipement de détection appelé
(Timer). Cet équipement permet d’envoyer une signalisation pour toute panne qui
se produit au niveau d’un BTS
 Localiser la panne en identifiant l’adressage IP du système informatique connecté
au BTS.
 Faciliter la communication entre l’administrateur et les techniciens pour la
détection et la correction des pannes
 Améliorer la gestion des pannes et des techniciens qui vont réparer ces pannes.
2.2.2 Spécification des besoins fonctionnels :
Le diagramme de contexte de la figure 2-1 sert à délimiter le contour du système en
cours d’étude, définir clairement ses frontières et les acteurs avec lesquels il communique.
Ces derniers peuvent être soit des acteurs humains, soit d’autres systèmes avec lesquels le
futur système communique.
Projet de Fin d’Etudes ISIGK 2015/2016
9
Figure 2.1 : Diagramme de contexte
La spécification des besoins fonctionnels est également représentée au travers du
diagramme de cas d’utilisation de la figure 2-2, utilisé pour donner une vision globale du
comportement fonctionnel d’un système logiciel. Un cas d’utilisation représente une unité
discrète d’interaction entre un utilisateur (humain ou machine) et un système. C’est est une
unité significative de travail. Dans un diagramme de cas d’utilisation, les utilisateurs sont
appelés acteurs (en anglais "actors "), ils interagissent avec les cas d’utilisations (use cases).
Projet de Fin d’Etudes ISIGK 2015/2016
10
Figure 2-2 : Diagramme de cas d’utilisation Global « Gestion des pannes de BTS »
Projet de Fin d’Etudes ISIGK 2015/2016
11
Le diagramme de cas d’utilisation de la Figure 2-2 décrit les besoins fonctionnels de
notre application, ainsi que leurs acteurs qui sont principalement : l’administrateur et le
technicien.
L'application doit permettre à l’administrateur de
 Gérer les techniciens pour
 L’ajout de techniciens
 Consulter la liste des techniciens afin de
 Modifier des informations relatives aux techniciens
 Supprimer des techniciens
 Gérer pannes pour effectuer le :
 Suivie des pannes
 Affectation des pannes au technicien ce sui comporte
 La vérification de la disponibilité des techniciens
 Gérer matériaux pour
 L’ajout de matériaux
 Consulter la liste des matériaux pour
 La modification de matériaux
 La suppression de matériaux
 Consulter l’historique des pannes
L’acteur Admin doit s’identifier pour effectuer les activités de l’application.
L'application doit permettre au technicien de
 Consulter la liste des pannes
 Consulter les ordres de mission
 Vérifier la disponibilité des matériaux
 Changer l’état des pannes pour indiquer si
 La panne a été réparée ou
 La panne n’a pas été réparée
 Consulter l’historique des pannes
 Contacter administrateur
L’identification est nécessaire pour l’acteur technicien pour réaliser les activités de
l’application.
Projet de Fin d’Etudes ISIGK 2015/2016
12
2.2.3 Besoins non fonctionnels :
Pour réussir notre projet et pour qu'il soit compatible avec ses utilisateurs, il faut bien
vérifier les contraints suivantes de l’application :
 Les contraintes Ergonomiques : Afin d’accéder à l’information d’une manière simple,
les utilisateurs demandent bien d’avoir des interfaces conviviales avec un affichage
rapide, sur lesquelles ils peuvent accéder aux informations et visualiser par la suite les
résultats.
 Les contraintes Esthétiques : Nous utilisons un fond clair et des couleurs foncées pour
le texte. Nous veillerons aussi à ne pas surcharger l’écran s’il ya beaucoup
d’information, il faut les découper selon des menus, sous menus ou des boutons,
limiter La quantité de texte afin de minimiser la charge cognitive : respecter les règles
de lisibilité typographiques : les textes doivent être de taille lisible et la typographie
utilisée doit être visible, bien précise et harmonieuse avec les couleurs. Nous utilisons
des boutons standards communs pour toute l’application.
 Les contraintes Techniques :
 L'application doit garantir la sécurité à travers la gestion des droits d'accès.
 L’accès à la base de données doit être ou plus rapide.
 L’application doit être toujours fonctionnelle.
 L'application doit détecter la présence d'une connexion internet.
 Les contraintes Réseau :
 L'application doit communiquer avec une base de données distante située
sur un serveur, suivant une architecture client/serveur comme elle est
représentée dans la figure 2-3 ci-dessous.
 Les contraintes de sécurité :
 Besoin d’établissement de la connexion au niveau d’accès (Ajouter,
modifier, lire, écrire…).
 Besoin de login et mot de passe.
 Politique de réutilisation.
 Déconnexion après temps mort.
 Les contraintes d’intégrité :
 Capture d'erreur d'entrée/sortie.
 Traitement de mauvaises données.
Projet de Fin d’Etudes ISIGK 2015/2016
13
 Intégrité de données : l'intégrité référentielle dans sa table de base de
données et interface
Figure 2-3 : Architecture de l’application « Gestion de panne de BTS » [2]
2.2.4 Identification des acteurs et des cas d’utilisation et affectation
des priorités :
Dans cette partie nous avons identifié les acteurs nécessaires de notre application, ainsi
que les différents cas d’utilisation relatifs à ces acteurs en affectant leurs priorités.
Acteur Cas d’utilisation Priorité
Administrateur Ajouter technicien 1
Administrateur Modifier technicien 2
Administrateur Supprimer technicien 2
Administrateur Suivi des pannes 1
Administrateur Affecter panne au technicien 1
Administrateur Ajouter matériaux 3
Administrateur Modifier matériaux 3
Administrateur Supprimer matériaux 3
Technicien Consulter la liste des pannes 1
Technicien Consulter les ordres de mission 1
Technicien Vérifier la disponibilité des
matériaux
2
Technicien Changer l’état de panne 1
Technicien Contacter administrateur 3
Administrateur et
Technicien
S’identifier 1
Projet de Fin d’Etudes ISIGK 2015/2016
14
Administrateur et
Technicien
Consulter l’historique des pannes 2
2.2.5 Raffinement des cas d’utilisation prioritaire :
À ce niveau de l’activité « Capture/Spécification des besoins », nous allons raffiner les
cas des utilisations de priorité 1 dont nous allons faire à chacun des cas des utilisations, la
description textuelle de son scénario principal, ainsi que les exceptions qui peuvent se
déroulent pendant l’utilisation de l’application
2.2.5.1 Description textuelle du cas d'utilisation s’identifier :
Figure 2-4 : Cas d'utilisation « S'identifier ».
 Nom du cas : S'identifier.
 Acteur : Administrateur et technicien
 Précondition : Connexion établie.
 Post-condition : Authentification avec sucées.
 Description du scénario principal :
1. Le système affiche l’interface de l’authentification
2. L’utilisateur saisit son login et son mot de passe
3. L’utilisateur survole sur le bouton « Connecter »
4. Le système vérifie le login et le mot de passe
2.2.5.2 Description textuelle du cas d'utilisation « Ajouter technicien » :
Figure 2-5 : Cas d'utilisation « Ajouter technicien ».
Projet de Fin d’Etudes ISIGK 2015/2016
15
 Nom du cas : Ajouter technicien.
 Acteur : Administrateur.
 Précondition : L'administrateur doit s'identifier afin de pouvoir gérer les techniciens.
 Post-condition : Ajout technicien effectué
 Description de scénario principal :
1. Le système affiche l’interface « Ajouter technicien »
2. L’administrateur saisit les informations du nouveau technicien
3. L’administrateur appuie sur le bouton « Ajouter technicien »
4. Le système enregistre les données du nouveau technicien
2.2.5.3 Description textuelle du cas d’utilisation « Suivi des pannes » :
Figure 2-6 : Cas d’utilisation « Suivi des pannes ».
 Nom du cas : Suivi des pannes.
 Acteur : Administrateur.
 Précondition : L'administrateur doit s'identifier afin de pouvoir effectuer le suivi des
pannes.
 Post-condition : Suivie des pannes réalisées
 Description scénario principal :
1. 1-Le système affiche l’interface « gérer panne »
2. 2-l’administrateur survole sur le bouton « Suivi panne »
3. 3-le système traite s’il Ya de panne détecté
2.2.5.4 Description textuelle du cas d’utilisation « Affecter panne au
technicien » :
Figure 2-7 : Cas d'utilisation « Affecter panne au technicien ».
Projet de Fin d’Etudes ISIGK 2015/2016
16
 Nom du cas : Affecter panne au technicien.
 Acteur : Administrateur.
 Précondition : l’administrateur doit s'identifier pour pouvoir affecter les pannes aux
techniciens.
 Post-condition : Affectation de panne au technicien avec succès.
 Description du scénario principal :
1. Le système affiche l’interface « Affecter panne au technicien »
2. L’administrateur choisit le technicien auquel doit être affecté la panne
3. Le système traite l’affectation de panne
2.2.5.5 Description textuelle du cas d’utilisation « Consulter la liste des
pannes » :
Figure 2-8 : Cas d’utilisation « Consulter la liste des pannes ».
 Nom du cas : Consulter la liste des pannes.
 Acteur : Technicien.
 Précondition : Le technicien doit s‘identifier afin de pouvoir consulter la liste des
pannes.
 Post-condition : consultation avec succès.
 Description du scénario principal :
1. Le système affiche l’interface « Liste des pannes »
2. Le technicien sélectionne les pannes qu’il souhaite consulter
3. Le système affiche les pannes sélectionnées
2.2.5.6 description textuelle du cas d’utilisation « Consulter les ordres de
mission » :
Figure 2.9 : Cas d’utilisation « Consulter les ordres de mission »
Projet de Fin d’Etudes ISIGK 2015/2016
17
 Nom du cas : Consulter les ordres de mission
 Acteur : Technicien
 Précondition : Le technicien doit s‘identifier afin de pouvoir consulter les ordres de
mission
 Post-condition : consultation avec succès.
 Description du scénario principal :
1. Le système affiche l’interface « ordre de mission »
2. Le technicien demande à consulter ses ordres de mission
3. Le système affiche les ordres de mission
2.2.5.7 Description textuelle du cas d’utilisation « changé l’état de
panne » :
Figure 2-10 : Cas d'utilisation « Changer l’état de panne ».
 Nom du cas : Changer l’état de panne.
 Acteur : Technicien.
 Précondition : Le technicien doit s’identifier afin de pouvoir changer l’état de panne.
 Post-condition : Etat de panne renseignée.
 Description du scénario principal :
1. Le système affiche l’interface « changer l’état de panne »
2. Le technicien appuie sur le bouton « réparer » si la panne a été réparée. Dans le
cas contraire, il appuie sur le bouton « non réparer »
3. Le système enregistrer l’état de la panne
Projet de Fin d’Etudes ISIGK 2015/2016
18
2.2.6 Prototype des interfaces utilisateurs :
La figure 2.11 illustre un prototype des interfaces utilisateurs : la connexion et le menu
principal.
Tout d’abord, l’utilisateur de l’application saisit son login et son mot de passe, ensuite,
il survole sur le bouton (connecter). Dons ce cas, le système vérifier les donnes de la
connexion : si les donnes sont valides alors le menu principale relatif à l’utilisateur connecté
sera affiché.
Figure 2.11 : Prototype d’interface « authentification pour technicien »
2.3 Analyse des cas d’utilisation prioritaires :
L'objectif de l'analyse est d'accéder à une compréhension des besoins et des exigences
du client. Il s'agit de livrer des spécifications pour permettre de choisir la conception de la
solution.
Projet de Fin d’Etudes ISIGK 2015/2016
19
Un modèle d'analyse livre une spécification complète des besoins issus des cas
d'utilisation et les structures qui facilitent la compréhension des scénarios, la préparation, la
modification et la maintenance du futur système.
2.3.1 Traçabilité entre le modèle de cas d’utilisation (MCU) et le
modèle d’analyse (MA) :
À ce niveau de l’activité « Analyse » de la phase d’incubation, nous avons précis les
classes relatives aux cas d’utilisation ainsi que les interfaces utilisateurs et les contrôles de
chaque cas d’utilisation
2.3.1.1 Traçabilité entre MCU et MA relatif au cas d’utilisation
« S’identifier » :
La figure 2.12 représente la classe qui est utilisée dans le cas d’utilisation
« S’identifier ».
Figure 2-12 : le cas d’utilisation « S’identifier »
Projet de Fin d’Etudes ISIGK 2015/2016
20
2.3.1.2 Traçabilité entre MCU et MA relatif au cas d’utilisation « Ajouter
technicien » :
Figure 2-13 : Cas d’utilisation « Ajouter technicien »
2.3.1.3 Traçabilité entre MCU et MA relatif au cas d’utilisation « Suivi
des panne » :
Figure 2-14 : Cas d’utilisation « Suivi des pannes »
Projet de Fin d’Etudes ISIGK 2015/2016
21
2.3.1.4 Traçabilité entre MCU et MA relatif au cas d’utilisation « Affecter
panne au technicien » :
Figure 2.15 : Cas d’utilisation « Affecter panne au technicien »
Projet de Fin d’Etudes ISIGK 2015/2016
22
2.3.1.5 Traçabilité entre MCU et MA relatif au cas d’utilisation
« Consulter les ordres de mission » :
Figure 2.16 : Cas d’utilisation « Consulter les ordres de mission »
Projet de Fin d’Etudes ISIGK 2015/2016
23
2.3.1.6 Traçabilité entre MCU et MA relatif au cas d’utilisation
« Consulter la liste des pannes » :
Figure 2.17 : Cas d’utilisation « Consulter la liste des pannes »
2.3.1.7 Traçabilité entre MCU et MA relatif au cas d’utilisation « Changer
l’état de panne » :
Projet de Fin d’Etudes ISIGK 2015/2016
24
Figure 2.18 : Cas d’utilisation « Changer l’état de panne »
2.3.2 Diagrammes de classes d’analyse :
À ce niveau de l’activité « Analyse » de la phase d’incubation, nous allons présenter
les relations entre les classes, les acteurs, les contrôles et les interfaces de quelques cas
d‘utilisation
2.3.2.1 Diagramme de classes d’analyse relatif au cas d’utilisation
« S’authentifier » :
Figure 2.19 représente les relations entre les classes utilisées dans le cas d’utilisation
« S’authentifier ».
Figure 2.19 : Cas d’utilisation « S’identifier »
Projet de Fin d’Etudes ISIGK 2015/2016
25
2.3.2.2 Diagramme de classes d’analyse relatif au cas d’utilisation
« Ajouter technicien » :
Figure 2.20 représente les relations entre les classes utilisées dans le cas d’utilisation
« Ajouter technicien ».
Figure 2.20 : Cas d’utilisation « Ajouter Technicien »
2.3.2.3 Diagramme de classes d’analyse relatif au cas d’utilisation « Suivi
des Pannes » :
Figure 2.21 représente les relations entre les classes utilisées dans le cas d’utilisation
« Suivi des pannes ».
Figure 2.21 : Cas d’utilisation « Suivi des Pannes »
2.3.2.4 Diagramme de classes d’analyse relatif au cas d’utilisation
« Affecter panne au technicien » :
Figure 2.22 représente les relations entre les tables utilisées dans le cas d’utilisation
« Affecter panne au technicien ».
Figure 2.22 : Cas d’utilisation « Affecter panne au technicien »
Projet de Fin d’Etudes ISIGK 2015/2016
26
2.3.2.5 Diagramme de classes d’analyse relatif au cas d’utilisation
« Consulter la liste des pannes » :
Figure 2.23 représente les relations entre les tables utilisées dans le cas d’utilisation
« Consulter la liste des pannes ».
Figure 2.23 : Cas d’utilisation « Consulter la liste des pannes »
2.3.2.6 Diagramme de classes d’analyse relatif au cas d’utilisation
« Consulter ordre de mission » :
Figure 2.24 représente les relations entre les tables utilisées dans le cas d’utilisation
« Consulter ordre de mission ».
Figure 2.24 : Cas d’utilisation « Consulter ordre de mission »
2.3.2.7 Diagramme de classes d’analyse relatif au cas d’utilisation
« Changer l’état de panne » :
Figure 2.25 représente les relations entre les classes utilisées dans le cas d’utilisation
« changer l’état de panne ».
Projet de Fin d’Etudes ISIGK 2015/2016
27
Figure 2.25 : Cas d’utilisation « Changer l’état des pannes »
2.3.3 Diagrammes de collaboration :
À ce niveau de l’activité « Analyse » de la phase d’incubation, nous allons élaborer les
diagrammes de collaboration des cas des utilisations prioritaires, qui présentent le scénario en
détail ainsi que l’interaction entre les éléments du système et l’utilisateur.
2.3.3.1 Diagramme de collaboration relatif au cas d’utilisation
« S’authentifier » :
La figure 2.26 représente en détail le scénario principal relatif au cas d’utilisation «
S’authentifier » ainsi que les interactions entre l’administrateur et l’application au niveau de
ce cas d’utilisation.
Figure 2.26 : Diagramme de collaboration relatif au Cas d’utilisation « S’identifier »
Projet de Fin d’Etudes ISIGK 2015/2016
28
2.3.3.2 Diagramme de collaboration relatif au cas d’utilisation « Ajouter
technicien » :
La figure 2-27 représente en détail le scénario principal relatif au cas d’utilisation
« Ajouter technicien » ainsi que les interactions entre l’administrateur et l’application au
niveau de ce cas d’utilisation.
Figure 2.27 : Diagramme de collaboration relatif au cas d’utilisation « Ajouter technicien »
2.3.3.3 Diagramme de collaboration relatif au cas d’utilisation « Suivi des
pannes » :
La figure 2-28 représente en détail le scénario principal relatif au cas d’utilisation
« Suivi des pannes » ainsi que les interactions entre l’administrateur et l’application au niveau
de ce cas d’utilisation.
Projet de Fin d’Etudes ISIGK 2015/2016
29
Figure 2.28 : Diagramme de collaboration relatif au cas d’utilisation « Suivi des pannes »
2.3.3.4 Diagramme de collaboration relatif au cas d’utilisation « Affecter
panne au technicien » :
La figure 2-29 représente en détail le scénario principal relatif au cas d’utilisation
« Affecter panne au technicien » ainsi que les interactions entre l’administrateur et
l’application au niveau de ce cas d’utilisation.
Projet de Fin d’Etudes ISIGK 2015/2016
30
Figure 2.29 : Diagramme de collaboration relatif au cas d’utilisation « Affecter panne au
technicien »
2.3.3.5 Diagramme de collaboration relatif au cas d’utilisation
« Consulter les ordres de mission » :
La figure 2-30 représente en détail le scénario principal relatif au cas d’utilisation
« Consulter les ordres de mission » ainsi que les interactions entre technicien et l’application
au niveau de ce cas d’utilisation.
Figure 2-30 : Diagramme de collaboration relatif au cas d’utilisation « Consulter les
ordres de mission »
Projet de Fin d’Etudes ISIGK 2015/2016
31
2.3.3.6 Diagramme de collaboration relatif au cas d’utilisation « Consulter
la liste des pannes » :
La figure 2-31 représente en détail le scénario principal relatif au cas d’utilisation
« Technicien consulter la liste des pannes » ainsi que les interactions entre technicien et
l’application au niveau de ce cas d’utilisation.
Figure 2-31 : Diagramme de collaboration relatif au cas d’utilisation « Consulter la liste des
pannes »
2.3.3.7 Diagramme de collaboration relatif au cas d’utilisation « Changer
l’état de panne » :
La figure 2-32 représente en détail le scénario principal relatif au cas d’utilisation
« Changer l’état de panne » dans le cas où la panne a été réparée ainsi que les interactions
entre technicien et l’application au niveau de ce cas d’utilisation.
Projet de Fin d’Etudes ISIGK 2015/2016
32
Figure 2-32 : Diagramme de collaboration relatif au cas d’utilisation « Changer l’état de
panne »
2.4 Conception des cas d’utilisation prioritaires :
La conception dans cette phase consiste à concevoir les cas d’utilisations, nous allons
construire alors les diagrammes de classes de conception, ainsi que les interactions entre eux
et les diagrammes de séquence de chaque cas d’utilisation de priorité 1.
2.4.1 Diagrammes des classes de conception :
Les diagrammes de classes expriment de manière générale la structure statique d’un
système, en termes de classes et de relations entre ces classes. Une classe permet de décrire un
ensemble d’objets (attributs et comportement), tandis qu’une relation ou association permet
de faire apparaître des liens entre ces objets.
2.4.1.1 Diagramme de classe de conception relatif au cas d’utilisation
« S’identifier » :
La figure 2-33 représente en détaille scénario principal dons un diagramme de classe
de conception relatif au cas d’utilisation « S’identifier » ainsi que les interactions entre
l’administrateur et l’application au niveau de ce cas d’utilisation.
Projet de Fin d’Etudes ISIGK 2015/2016
33
Figure 2-33 : Diagramme de classe de conception relatif au cas d’utilisation « S’identifier »
2.4.1.2 Diagramme de classe de conception relatif au cas d’utilisation
« Ajouter technicien » :
La figure 2-34 représente en détaille scénario principal dons un diagramme de classe
de conception relatif au cas d’utilisation « Ajouter technicien » ainsi que les interactions entre
l’administrateur et l’application au niveau de ce cas d’utilisation.
Projet de Fin d’Etudes ISIGK 2015/2016
34
Figure 2-34 : Diagramme de classe de conception relatif au cas d’utilisation « Ajouter
technicien »
2.4.1.3 Diagramme de classe de conception relatif au cas d’utilisation
« Suivi des pannes » :
La figure 2-35 représente en détaille scénario principal dons un diagramme de classe
de conception relatif au cas d’utilisation « Suivi des pannes » ainsi que les interactions entre
l’administrateur et l’application au niveau de ce cas d’utilisation.
Projet de Fin d’Etudes ISIGK 2015/2016
35
Figure 2-35 : Diagramme de classe de conception relatif au cas d’utilisation « Suivi des
pannes »
2.4.1.4 Diagramme de classe de conception relatif au cas d’utilisation
« Affecter panne au technicien » :
La figure 2-36 représente en détaille scénario principal dons un diagramme de classe
de conception relatif au cas d’utilisation « Affecter panne au technicien » ainsi que les
interactions entre l’administrateur et l’application au niveau de ce cas d’utilisation
Projet de Fin d’Etudes ISIGK 2015/2016
36
Figure 2.36 : Diagramme de classe de conception relatif au cas d’utilisation « Affecter panne
au technicien »
2.4.1.5 Diagramme de classe de conception relatif au cas d’utilisation
« Consulter les ordres de mission » :
La figure 2-37 représente en détaille scénario principal dons un diagramme de classe
de conception relatif au cas d’utilisation « Consulter les ordres de mission » ainsi que les
interactions entre l’administrateur et le technicien dons l’application au niveau de ce cas
d’utilisation.
Projet de Fin d’Etudes ISIGK 2015/2016
37
Figure 2-37 : Diagramme de classe de conception relatif au cas d’utilisation « Consulter les
ordres de mission »
2.4.1.6 Diagramme de classe de conception relatif au cas d’utilisation
« Consulter la liste des pannes » :
La figure 2-38 représente en détaille scénario principal dons un diagramme de classe
de conception relatif au cas d’utilisation « Consulter la liste des pannes » ainsi que les
interactions entre le technicien et l’application au niveau de ce cas d’utilisation.
Projet de Fin d’Etudes ISIGK 2015/2016
38
Figure 2-38 : Diagramme de classe de conception relatif au cas d’utilisation « Consulter la
liste des pannes »
2.4.1.7 Diagramme de classe de conception relatif au cas d’utilisation
« Changer l’état de panne » :
La figure 2-39 représente en détaille scénario principal dons un diagramme de classe
de conception relatif au cas d’utilisation « Changer l’état de panne » ainsi que les interactions
entre le technicien et l’application au niveau de ce cas d’utilisation.
Projet de Fin d’Etudes ISIGK 2015/2016
39
Figure 2-39 : Diagramme de classe de conception relatif au cas d’utilisation « Changer l’état
de panne »
2.4.2 Diagrammes de séquences :
Les diagrammes de séquences sont la représentation graphique des interfaces entre les
acteurs et le système selon un ordre chronologique. Le but étant de décrire comment se
déroulent les actions entre les acteurs ou objets.
2.4.2.1 Diagramme de séquences relatif au cas d’utilisation « S’identifier
» :
La figure 2.40 illustre une description détaillée du scénario relatif au cas d’utilisation
« S’identifier ».
Projet de Fin d’Etudes ISIGK 2015/2016
40
Figure 2-40 : Diagramme de séquences relatif au cas d’utilisation « S’identifier »
2.4.2.2 Diagramme de séquences relatif au cas d’utilisation « Ajouter
technicien » :
La figure 2.41 illustre une description détaillée du scénario relatif au cas d’utilisation
« Ajouter Technicien »
Projet de Fin d’Etudes ISIGK 2015/2016
41
Figure 2-41 : Diagramme de séquences relatif au cas d’utilisation « Ajouter technicien »
Projet de Fin d’Etudes ISIGK 2015/2016
42
2.4.2.3 Diagramme de séquences relatif au cas d’utilisation « Suivi des
pannes » :
La figure 2.42 illustre une description détaillée du scénario relatif au cas d’utilisation
« Suivi des pannes »
Figure 2-42 : Diagramme de séquences relatif au cas d’utilisation « Suivi des pannes »
Projet de Fin d’Etudes ISIGK 2015/2016
43
2.4.2.4 Diagramme de séquences relatif au cas d’utilisation « Affecter
panne au technicien » :
La figure 2.43 illustre une description détaillée du scénario relatif au cas d’utilisation
« Affecter panne au technicien ».
Figure 2.43 : Diagramme de séquences relatif au cas d’utilisation « Affecter panne au
technicien »
Projet de Fin d’Etudes ISIGK 2015/2016
44
2.4.2.5 Diagramme de séquences relatif au cas d’utilisation « Consulter
les ordres de mission » :
La figure 2.44 illustre une description détaillée du scénario relatif au cas d’utilisation
« consulter ordre de mission »
Figure 2-44 : Diagramme de séquences relatif au cas d’utilisation « Technicien consulter
ordre de mission »
2.4.2.6 Diagramme de séquences relatif au cas d’utilisation « Consulter la
liste des pannes » :
La figure 2.45 illustre une description détaillée du scénario relatif au cas d’utilisation
« Consulter la liste des pannes »
Projet de Fin d’Etudes ISIGK 2015/2016
45
Figure 2-45 : Diagramme de séquences relatif au cas d’utilisation « Consulter la liste des
pannes »
2.4.2.7 Diagramme de séquences relatif au cas d’utilisation « Changer
l’état de panne » :
La figure 2.46 illustre une description détaillée du scénario relatif au cas d’utilisation
« Changer l’état de panne »
Projet de Fin d’Etudes ISIGK 2015/2016
46
Figure 2.46 : Diagramme de séquences relatif au cas d’utilisation « Changer l’état de panne »
Conclusion :
Après avoir spécifié et analysé les différents besoins que nous devons satisfaire, nous
avons procédé à la conception des cas d’utilisation prioritaires de notre application. Dans le
chapitre suivant, nous allons passer à la phase d’élaboration du processus unifié.
Projet de Fin d’Etudes ISIGK 2015/2016
47
Chapitre 3 : Conception « Phase d’élaboration »
Introduction :
Cette phase utilise le modèle des cas d'utilisation comme moyen de compréhension et
de description des besoins, alors nous consistons à compléter l'identification des besoins et à
détailler les cas d'utilisations secondaires trouvés dans la phase d'incubation.
3.1 Capture des besoins :
3.1.1 Raffinement des cas d’utilisations secondaires :
3.1.1.1 Raffinement de cas d’utilisation « Modifier technicien » :
Figure 3.1 : cas d’utilisation « Modifier technicien »
Il s’agit d’un diagramme de cas d’utilisation relatif à l’acteur « Administrateur » qui a
le droit de modifier un technicien
 Cas d’utilisation : Modifier technicien
 Acteur : Administrateur
 Précondition : L’administrateur doit être identifié et autorisé
 Post-condition : Modification effectuée
 Description du scénario principal :
1. Le système affiche l’interface « Modifier technicien »
2. L’administrateur clique sur le bouton « Modifier technicien »
3. L’administrateur saisit les informations à modifier
4. Le système enregistre les modifications
Projet de Fin d’Etudes ISIGK 2015/2016
48
3.1.1.2 Raffinement de cas d’utilisation « Supprimer technicien » :
Figure 3.2 : Cas d’utilisation « Supprimer technicien »
 Cas d’utilisation : Supprimer technicien
 Acteur : Administrateur
 Précondition : L’administrateur doit être identifié et autorisé
 Post-condition : Technicien supprimé
 Description du scénario principal :
1. Le système affiche l’interface « Supprimer technicien »
2. L’administrateur choisit le technicien à supprimer
3. L’administrateur survole sur le bouton « Supprimer technicien »
4. Le système supprime le technicien sélectionné
3.1.1.3 Raffinement de cas d’utilisation « Vérifier la disponibilité des
matériaux » :
Figure 3.3 : Cas d’utilisation « Vérifier la disponibilité des matériaux »
 Cas d’utilisation : Vérifier la disponibilité des matériaux
 Acteur : Technicien
 Précondition : Le technicien doit être identifié et autorisé
 Post-condition : Vérification de la disponibilité des matériaux
 La description du scénario principal :
1. Le système affiche l’interface vérifié disponibilité des matériaux
2. Le technicien survole sur le bouton « vérifier disponibilité des matériaux »
3. Le système affiche la liste des matériaux disponibles
Projet de Fin d’Etudes ISIGK 2015/2016
49
3.1.1.4 Raffinement de cas d’utilisation « Consulter l’historique des
pannes » :
Figure 3.4 : Diagramme de cas d’utilisation « Consulter historique des pannes »
Il s’agit d’un diagramme de cas d’utilisation relatif à l’acteur « Administrateur » et à
l’acteur « Technicien » qui ont le droit de consulter l’historique des pannes.
 Cas d’utilisation : Consulter l’historique des pannes
 Acteur : Administrateur et Technicien
 Précondition : L’administrateur ou le technicien doit être identifié et autorisé
 Post-condition : Consultation effectuée
 Description du scénario principal :
1. L’application affiche l’interface « Administrateur/Technicien »
2. L’administrateur clique sur l’item (historique des pannes)
3. L’application affiche l’interface « historique des pannes »
3.2 Analyses des cas des utilisations secondaires :
3.2.1 Traçabilité entre le modèle de cas d’utilisation (MCU) et le
modèle d’analyse (MA) :
3.2.1.1 Traçabilité entre MCU et MA relatif au cas d’utilisation
« Modifier technicien » :
La figure 3.5 représente les classes qui sont utilisées dans le cas d’utilisation
« Modifier technicien ».
Projet de Fin d’Etudes ISIGK 2015/2016
50
Figure 3.5 : Traçabilité entre MCU et MA relatif au cas d’utilisation « Modifier technicien »
3.2.1.2 Traçabilité entre MCU et MA relatif au cas d’utilisation
« Supprimer technicien » :
La figure 3.6 représente les classes qui sont utilisées dans le cas d’utilisation
« Supprimer technicien ».
Figure 3.6 : Traçabilité entre MCU et MA relatif au cas d’utilisation « Supprimer technicien »
Projet de Fin d’Etudes ISIGK 2015/2016
51
3.2.1.3 Traçabilité entre MCU et MA relatif au cas d’utilisation « Vérifier
la disponibilité des matériaux » :
La figure 3.7 représente les classes qui sont utilisées dans le cas d’utilisation « Vérifier
la disponibilité des matériaux ».
Figure 3.7 : Traçabilité entre MCU et MA relatif au cas d’utilisation « Vérifier la disponibilité
des matériaux »
3.2.1.4 Traçabilité entre MCU et MA relatif au cas d’utilisation
« Consulter historique des pannes » :
La figure 3.8 représente les classes qui sont utilisées dans le cas d’utilisation
« Consulter historique des pannes ».
Figure 3.8 : Traçabilité entre MCU et MA relatif au cas d’utilisation « Consulter historique
des pannes »
Projet de Fin d’Etudes ISIGK 2015/2016
52
3.2.2 Diagrammes de classes d’analyse :
3.2.2.1 Diagramme de classes d’analyse relatif au cas
d’utilisation « Modifier technicien » :
La figure 3.9 représente les relations entre les classes utilisées dans le cas d’utilisation
« Modifier technicien ».
Figure 3.9 : Diagramme de classes d’analyse relatif au cas d’utilisation « Modifier
technicien »
3.2.2.2 Diagramme de classes d’analyse relatif au cas d’utilisation
« Supprimer technicien » :
La figure 3.10 représente les relations entre les classes utilisées dans le cas
d’utilisation « Supprimer technicien ».
Figure 3.10 : Diagramme de classes d’analyse relatif au cas d’utilisation « Supprimer
technicien »
3.2.2.3 Diagramme de classes d’analyse relatif au cas d’utilisation
« Vérifier la disponibilité des matériaux » :
La figure 3.11 représente les relations entre les classes utilisées dans le cas
d’utilisation « Vérifier la disponibilité des matériaux ».
Projet de Fin d’Etudes ISIGK 2015/2016
53
Figure 3.11 : Diagramme de classes d’analyse relatif au cas d’utilisation « Vérifier la
disponibilité des matériaux »
3.2.2.4 Diagramme de classes d’analyse relatif au cas d’utilisation
« Consulter historique des pannes » :
La figure 3.12 représente les relations entre les classes utilisées dans le cas « Consulter
l’historique des pannes ».
Figure 3.12 : Diagramme de classes d’analyse relatif au cas d’utilisation « Consulter
historique des pannes »
Projet de Fin d’Etudes ISIGK 2015/2016
54
3.2.3 Diagrammes de collaboration :
3.2.3.1 Diagramme de collaboration relatif au cas d’utilisation « Modifier
technicien » :
Figure 3.13 : Diagramme de collaboration relatif au cas d’utilisation « Modifier technicien »
3.2.3.2 Diagramme de collaboration relatif au cas d’utilisation
« Supprimer technicien » :
Projet de Fin d’Etudes ISIGK 2015/2016
55
Figure 3.14 : Diagramme de collaboration relatif au cas d’utilisation « Supprimer technicien »
3.2.3.3 Diagramme de collaboration relatif au cas d’utilisation « Vérifier
la disponibilité des matériaux » :
Figure 3.15 : Diagramme de collaboration relatif au cas d’utilisation « Vérifier la disponibilité
des matériaux »
3.2.3.4 Diagramme de collaboration relatif au cas d’utilisation « Consulter
historique des pannes » :
La figure 3.16 représente en détail le scénario principal relatif au cas d’utilisation «
Consulter historique des pannes », ainsi que les interactions entre le responsable «
Administrateur » / « Technicien » et l’application au niveau de ce cas d’utilisation.
Projet de Fin d’Etudes ISIGK 2015/2016
56
Figure 3.16 : Diagramme de collaboration relatif au cas d’utilisation « Consulter historique
des pannes »
3.3 Conception des cas d’utilisation secondaire :
3.3.1 Diagrammes de classes de conception :
3.3.1.1 Diagramme de classes de conception relatif au cas d’utilisation
« Modifier technicien » :
La figure 3.17 représente les classes du cas d’utilisation « Modifier technicien » et les
relations entre elles.
Projet de Fin d’Etudes ISIGK 2015/2016
57
Figure 3.17 : Diagramme de classes de conception relatif au cas d’utilisation « Modifier
technicien »
3.3.1.2 Diagramme de classes de conception relatif au cas d’utilisation
« Supprimer technicien » :
La figure 3.18 représente les classes du cas d’utilisation « Supprimer technicien » et
les relations entre elles.
Projet de Fin d’Etudes ISIGK 2015/2016
58
Figure 3.18 : Diagramme de classes de conception relatif au cas d’utilisation « Supprimer
technicien »
3.3.1.3 Diagramme de classes de conception relatif au cas d’utilisation
« Vérifier la disponibilité des matériaux » :
La figure 3.19 représente les classes du cas d’utilisation « Technicien vérifier
disponibilité des matériaux » et les relations entre elles.
Projet de Fin d’Etudes ISIGK 2015/2016
59
Figure 3.19 : Diagramme de classes de conception relatif au cas d’utilisation « Vérifier la
disponibilité des matériaux »
3.3.1.4 Diagramme de classes de conception relatif au cas
d’utilisation « Consulter historique des pannes » :
La figure 3.20 représente les classes du cas d’utilisation « Technicien vérifier
disponibilité des matériaux » et les relations entre elles.
Projet de Fin d’Etudes ISIGK 2015/2016
60
Figure 3.20 : Diagramme de classes de conception relatif au cas d’utilisation « Consulter
historique des pannes »
3.3.2 Diagrammes de séquences :
3.3.2.1 Diagramme de séquences relatif au cas d’utilisation « Modifier
technicien » :
La figure 3.21 illustre la description détaillée du scénario relatif au cas d’utilisation
« Modifier technicien ».
Projet de Fin d’Etudes ISIGK 2015/2016
61
Figure 3.21 : Diagramme de séquences relatif au cas d’utilisation « Modifier technicien »
Projet de Fin d’Etudes ISIGK 2015/2016
62
3.3.2.2 Diagramme de séquences relatif au cas d’utilisation « Supprimer
technicien » :
La figure 3.22 illustre la description détaillée du scénario relatif au cas d’utilisation
« Supprimer technicien ».
Projet de Fin d’Etudes ISIGK 2015/2016
63
Figure 3.22 : Diagramme de séquences relatif au cas d’utilisation « Supprimer technicien »
Projet de Fin d’Etudes ISIGK 2015/2016
64
3.3.2.3 Diagramme de séquences relatif au cas d’utilisation « Vérifier la
disponibilité des matériaux » :
La figure 3.23 illustre la description détaillée du scénario relatif au cas d’utilisation
« Vérifier la disponibilité des matériaux ».
Projet de Fin d’Etudes ISIGK 2015/2016
65
Figure 3.23 : Diagramme de séquences relatif au cas d’utilisation « Vérifier la disponibilité
des matériaux »
Projet de Fin d’Etudes ISIGK 2015/2016
66
3.3.2.4 Diagramme de séquences relatif au cas d’utilisation « Consulter
l’historique des pannes » :
La figure 3.24 illustre la description détaillée du scénario relatif au cas d’utilisation
« Consulter l’historique des pannes ».
Figure 3.24 : Diagramme de séquences relatif au cas d’utilisation « Consulter l’historique des
pannes »
Projet de Fin d’Etudes ISIGK 2015/2016
67
Conclusion :
Au cours de cette phase, nous avons procédé à la conception des cas d’utilisation
secondaires de notre application. Dans le chapitre suivant, nous allons passer à la phase de la
« construction » du processus unifié
Projet de Fin d’Etudes ISIGK 2015/2016
68
Chapitre 4 : Conception « Phase de construction »
Introduction :
La phase de construction est la troisième phase du processus unifié. Au cours de ce
chapitre, nous allons concevoir les cas d’utilisations tertiaires de notre application.
4.1 Capture des besoins :
4.1.1 Raffinement des cas d’utilisation tertiaires :
4.1.1.1 Raffinement de cas d’utilisation « Ajouter des matériaux » :
Figure 4.1 : Diagramme de cas d’utilisation « Ajouter des matériaux »
Il s’agit d’un diagramme de cas d’utilisation relatif à l’acteur « Administrateur » qui a
le droit d’ajouter des matériaux.
 Cas d’utilisation : Ajouter des matériaux
 Acteur : Administrateur
 Précondition : L’administrateur doit être identifié et autorisé
 Post-condition : Matériaux ajoutés.
 Description du scénario principal :
1- L’application affiche l’interface « Ajouter matériaux »
2- L’administrateur saisit les données relatives aux matériaux à ajouter
3- L’administrateur clique sur le bouton (Ajouter matériaux)
4- L’application enregistrer les nouveaux matériaux
Projet de Fin d’Etudes ISIGK 2015/2016
69
4.1.1.2 Raffinement de cas d’utilisation « Modifier matériaux » :
Figure 4.2 : Diagramme de cas d’utilisation « Modifier matériaux »
Il s’agit d’un diagramme de cas d’utilisation relatif à l’acteur « Administrateur » qui a
le droit de modifier des matériaux.
 Cas d’utilisation : Modifier matériaux
 Acteur : Administrateur
 Précondition : L’administrateur doit être identifié et autorisé
 Post-condition : Modifier des matériaux.
 Description du scenario principal :
1- L’application affiche l’interface « Consulter liste des matériaux »
2- L’administrateur survole sur l’item (Modifier matériaux)
3- L’application affiche l’interface « Modifier matériaux »
4- L’administrateur saisit les nouvelles informations des matériaux à
modifier
5- L’application enregistrer ces modifications.
4.1.1.3 Raffinement de cas d’utilisation « Supprimer matériaux » :
Figure 4.3 : Diagramme de cas d’utilisation « Supprimer matériaux »
Il s’agit d’un diagramme de cas d’utilisation relatif à l’acteur « Administrateur » qui a
le droit de supprimer des matériaux.
 Cas d’utilisation : Supprimer matériaux
 Acteur : Administrateur
 Précondition : L’administrateur doit être identifié et autorisé
 Post-condition : Matériaux supprimés.
Projet de Fin d’Etudes ISIGK 2015/2016
70
 Description du scénario principal :
1. L’application affiche l’interface « Consulter liste des matériaux »
2. L’administrateur clique sur l’item (Supprimer matériaux)
3. L’application affiche l’interface « Supprimer matériaux »
4. L’administrateur sélectionne les matériaux à supprimer
5. L’application supprime les matériaux.
4.1.1.4 Raffinement de cas d’utilisation « Contacter administrateur » :
Figure 4.4 : Diagramme de cas d’utilisation « Contacter administrateur »
Il s’agit d’un diagramme de cas d’utilisation relatif à l’acteur « Technicien » qui a le
droit de contacter l’administrateur.
 Cas d’utilisation : Contacter administrateur
 Acteur : Technicien
 Précondition : Le technicien doit être identifié et autorisé
 Post-condition : Administrateur contacté.
 Description du scénario principal :
1. L’application affiche l’interface « Contacter l’administrateur »
2. Le technicien rédige son message
3. Le technicien survole sur le bouton (envoyer)
4. L’application envoie le message à l’administrateur
Projet de Fin d’Etudes ISIGK 2015/2016
71
4.2 Analyse :
4.2.1 Traçabilité entre le modèle de cas d’utilisation (MCU) et le
modèle d’analyse (MA) :
4.2.1.1 Traçabilité entre MCU et MA relatif au cas d’utilisation « Ajouter
matériaux » :
La figure 4.5 représente les classes qui sont utilisées dans le cas d’utilisation « Ajouter
matériaux ».
Figure 4.5 : Traçabilité entre MCU et MA relatif au cas d’utilisation « Ajouter matériaux »
4.2.1.2 Traçabilité entre MCU et MA relatif au cas d’utilisation
« Modifier matériaux » :
La figure 4.6 représente les classes qui sont utilisées dans le cas d’utilisation
« Modifier matériaux ».
Projet de Fin d’Etudes ISIGK 2015/2016
72
Figure 4.6 : Traçabilité entre MCU et MA relatif au cas d’utilisation « Modifier matériaux »
4.2.1.3 Traçabilité entre MCU et MA relatif au cas d’utilisation
« Supprimer matériaux » :
La figure 4.7 représente les classes qui sont utilisées dans le cas d’utilisation
« Supprimer matériaux ».
Figure 4.7 : Traçabilité entre MCU et MA relatif au cas d’utilisation « Supprimer matériaux »
Projet de Fin d’Etudes ISIGK 2015/2016
73
4.2.1.4 Traçabilité entre MCU et MA relatif au cas d’utilisation
« Contacter administrateur » :
La figure 4.8 représente les classes qui sont utilisées dans le cas d’utilisation
« Contacter administrateur ».
Figure 4.8 : Traçabilité entre MCU et MA relatif au cas d’utilisation « Contacter
administrateur »
4.2.2 Diagrammes de classes d’analyse :
4.2.2.1 Diagramme de classes d’analyse relatif au cas d’utilisation «
Ajouter matériaux » :
La figure 4.9 représente les classes qui sont utilisées dans le cas d’utilisation « Ajouter
matériaux ».
Figure 4.9 : Diagramme de classes d’analyse relatif au cas d’utilisation « Ajouter matériaux »
Projet de Fin d’Etudes ISIGK 2015/2016
74
4.2.2.2 Diagramme de classes d’analyse relatif au cas d’utilisation
« Modifier matériaux » :
La figure 4.10 représente les classes qui sont utilisées dans le cas d’utilisation «
modifier matériaux ».
Figure 4.10 : Diagramme de classes d’analyse relatif au cas d’utilisation « Modifier
matériaux »
4.2.2.3 Diagramme de classes d’analyse relatif au cas d’utilisation
« Supprimer matériaux » :
La figure 4.11 représente les classes qui sont utilisées dans le cas d’utilisation «
Supprimer matériaux ».
Figure 4.11 : Diagramme de classes d’analyse relatif au cas d’utilisation « Supprimer
matériaux »
4.2.2.4 Diagramme de classes d’analyse relatif au cas d’utilisation
« Contacter administrateur » :
La figure 4.12 représente les classes qui sont utilisées dans le cas d’utilisation «
Contacter administrateur ».
Projet de Fin d’Etudes ISIGK 2015/2016
75
Figure 4.12 : Diagramme de classes d’analyse relatif au cas d’utilisation « Contacter
administrateur »
4.2.3 Digrammes de collaboration :
4.2.3.1 Diagramme de collaboration relatif au cas d’utilisation « Ajouter
matériaux » :
La figure 4.13 représente en détail le scénario principal relatif au cas d’utilisation «
Ajouter matériaux », ainsi que les interactions entre le responsable « Administrateur » et
l’application au niveau de ce cas d’utilisation.
Figure 4.13 : Diagramme de collaboration relatif au cas d’utilisation « Ajouter matériaux »
Projet de Fin d’Etudes ISIGK 2015/2016
76
4.2.3.2 Diagramme de collaboration relatif au cas d’utilisation « Modifier
matériaux » :
La figure 4.14 représente en détail le scénario principal relatif au cas d’utilisation «
Modifier matériaux », ainsi que les interactions entre le responsable « Administrateur » et
l’application au niveau de ce cas d’utilisation.
Figure 4.14 : Diagramme de collaboration relatif au cas d’utilisation « Modifier matériaux »
4.2.3.3 Diagramme de collaboration relatif au cas d’utilisation
« Supprimer matériaux » :
La figure 4.15 représente en détail le scénario principal relatif au cas d’utilisation «
Supprimer matériaux », ainsi que les interactions entre le responsable « Administrateur » et
l’application au niveau de ce cas d’utilisation.
Projet de Fin d’Etudes ISIGK 2015/2016
77
Figure 4.15 : Diagramme de collaboration relatif au cas d’utilisation « Supprimer matériaux »
4.2.3.4 Diagramme de collaboration relatif au cas d’utilisation « Contacter
administrateur » :
La figure 4.16 représente en détail le scénario principal relatif au cas d’utilisation «
Contacter administrateur », ainsi que les interactions entre le responsable « Technicien » et
l’application au niveau de ce cas d’utilisation.
Figure 4.16 : Diagramme de collaboration relatif au cas d’utilisation « Contacter
administrateur »
Projet de Fin d’Etudes ISIGK 2015/2016
78
4.3 Conception :
4.3.1 Diagrammes des classes de conception :
4.3.1.1 Diagramme de classes de conception relatif au cas d’utilisation
« Ajouter matériaux » :
La figure 4.17 représente les classes relatives au cas d’utilisation « Ajouter matériaux
» et les relations entre elles. Utilisateur « Administrateur ».
Figure 4.17 : Diagramme de classes de conception relatif au cas d’utilisation « Ajouter
matériaux »
4.3.1.2 Diagramme de classes de conception relatif au cas d’utilisation
« Modifier matériaux » :
La figure 4.18 représente les classes relatives au cas d’utilisation « modifier matériaux
» et les relations entre elles. Utilisateur « Administrateur ».
Projet de Fin d’Etudes ISIGK 2015/2016
79
Figure 4.18 : Diagramme de classes de conception relatif au cas d’utilisation « Modifier
matériaux »
4.3.1.3 Diagramme de classes de conception relatif au cas d’utilisation
« Supprimer matériaux » :
La figure 4.19 représente les classes relatives au cas d’utilisation « Supprimer
matériaux » et les relations entre elles. Utilisateur « Administrateur ».
Projet de Fin d’Etudes ISIGK 2015/2016
80
Figure 4.19 : Diagramme de classes de conception relatif au cas d’utilisation « Supprimer
matériaux »
4.3.1.4 Diagramme de classes de conception relatif au cas d’utilisation
« Contacter administrateur » :
La figure 4.20 représente les classes relatives au cas d’utilisation « Contacter
administrateur » et les relations entre elles. Utilisateur « Technicien ».
Projet de Fin d’Etudes ISIGK 2015/2016
81
Figure 4.20 : Diagramme de classes de conception relatif au cas d’utilisation « Contacter
administrateur »
Projet de Fin d’Etudes ISIGK 2015/2016
82
4.3.2 Diagrammes de séquences :
4.3.2.1 Diagramme de séquences relatif au cas d’utilisation « Ajouter
matériaux » :
La figure 4.21 illustre une description détaillée du scénario relatif au cas d’utilisation «
Ajouter matériaux ». Utilisateur « Administrateur ».
Figure 4.21 : Diagramme de séquences relatif au cas d’utilisation « Ajouter matériaux »
Projet de Fin d’Etudes ISIGK 2015/2016
83
4.3.2.2 Diagramme de séquences relatif au cas d’utilisation « Modifier
matériaux » :
La figure 4.22 illustre une description détaillée du scénario relatif au cas d’utilisation «
Modifier matériaux ». Utilisateur « Administrateur ».
Figure 4.22 : Diagramme de séquences relatif au cas d’utilisation « Modifier matériaux »
Projet de Fin d’Etudes ISIGK 2015/2016
84
4.3.2.3 Diagramme de séquences relatif au cas d’utilisation « Supprimer
matériaux » :
La figure 4.23 illustre une description détaillée du scénario relatif au cas d’utilisation «
Supprimer matériaux ». Utilisateur « Administrateur ».
Projet de Fin d’Etudes ISIGK 2015/2016
85
Figure 4.23 : Diagramme de séquences relatif au cas d’utilisation « Supprimer matériaux »
4.3.2.4 Diagramme de séquences relatif au cas d’utilisation « Contacter
administrateur » :
La figure 4.24 illustre une description détaillée du scénario relatif au cas d’utilisation «
Contacter administrateur ». Utilisateur « Technicien ».
Figure 4.24 : Diagramme de séquences relatif au cas d’utilisation « Contacter administrateur »
Projet de Fin d’Etudes ISIGK 2015/2016
86
4.4 Diagramme de classe des entités :
La classe est un concept abstrait qui permet de représenter toutes les entités d'un
système. La classe est définie par son nom, ses attributs et ses opérations.
La figure 4.25 illustre le schéma de la base de données « Administrateur » et
« Technicien »et les relations entre les tables (les tables mères et les tables filles).
Projet de Fin d’Etudes ISIGK 2015/2016
87
Figure 4.25 : Diagramme de classes d’entité globale
Conclusion :
Dans ce chapitre, nous avons présenté le raffinement, l’analyse et la conception des
cas d’utilisations tertiaires, ainsi que le schéma de la base de données « Administrateur » et
Projet de Fin d’Etudes ISIGK 2015/2016
88
« Technicien » de notre application. Nous passons à la prochaine phase qui consiste à
l’intégration de notre application dans l’environnement de l’utilisateur.
Projet de Fin d’Etudes ISIGK 2015/2016
89
Chapitre 5 : Conception « Phase de transition »
Introduction :
Cette phase suppose des activités comme la formation des utilisateurs clients, la mise
en œuvre d'un service d'assistance et la correction des anomalies constatées. Un groupe
d'utilisateurs essaye le produit et détecte les anomalies et défauts.
Au cours de ce chapitre, nous allons présenter notre environnement matériel et
logiciel, ensuite, nous allons mettre en place l’application et l’intégrer dans l’environnement
de l’utilisateur.
5.1 Environnement logiciel :
Dans cette partie, nous présentons les outils de modélisation et de développement de
notre application.
 Pacestar UML Diagramme permet de générer des diagrammes UML 2.0
rapidement et facilement. Il permet de créer des diagrammes d'activité,
diagrammes de classes et objets, diagrammes de communication, diagrammes
de cas, diagrammes de séquence, diagrammes d'états, diagrammes de package,
schémas de composants, diagrammes de déploiement, diagrammes de structure
composite et donne une vue d'ensemble de l'interaction des diagrammes [3].
 Android, prononcé androïde, est un système d’exploitation mobile open source
basée sur le noyau Linux et développé actuellement par google. Le système a
d'abord été conçu pour les smartphones et tablette tactile, puis s'est diversifié
dans les objets connectés et ordinateurs comme les télévisions les voitures, les
ordinateurs et les smartwath. Le système a été lancé en juin 2007 à la suite du
rachat par google en 2005 de la startup du même nom. En 2015, Android est le
système d'exploitation le plus utilisé dans le monde avec plus de 80 % de parts
de marché dans les smartphones [4].
 Android Studio permet principalement d'éditer les fichiers Java et les fichiers
de configuration d'une application Android. Il propose entre autres des outils
pour gérer le développement d'applications multilingues et permet de visualiser
Projet de Fin d’Etudes ISIGK 2015/2016
90
la mise en page des écrans sur des écrans de résolutions variées simultanément
[5].
 Genymotion : le nouvel émulateur Android offre un support de Jelly Bean. Il
supporte la souris, l’Ethernet, le RTC, l’audio, la gestion de l’alimentation, le
partage de fichier avec l’OS hôte, l’USB, le WiFi et l’OpenGL [6].
 Mobogenie est un gestionnaire de fichiers pour smartphone Android. Ce
logiciel permet de gérer, sauvegarder et restaurer les données (contacts, SMS,
photos, musique, vidéos, applications) de votre téléphone à partir de votre
ordinateur [7].
5.2 Enchainement des interfaces utilisateur :
Durant cette activité, nous présentons quelques interfaces de notre application réalisée.
5.2.1 Interface d’authentification :
La figure 5.1 représente l’interface d’authentification pour l’administrateur et le
technicien. Ils doivent saisir le login et mot de passe pour pouvoir accéder à l’application.
Projet de Fin d’Etudes ISIGK 2015/2016
91
Figure 5.1 : Interface « d’authentification ».
5.2.2 Interface d’accueil :
La figure 5.2 représente l’interface accueil de l’application.
Figure 5.2 : Interface « d’accueil ».
5.2.3 Interface « Gérer technicien » :
La figure 5.3 représente l’interface « Gérer technicien » de l’application.
L’Administrateur peut gérer les techniciens à travers cette interface.
Projet de Fin d’Etudes ISIGK 2015/2016
92
Figure 5.3 : Interface « gérer technicien »
5.2.4 Interface « Ajouter technicien » :
La figure 5.4 représente l’interface « Ajouter technicien ». Par cette interface
l’administrateur peut ajouter des techniciens.
Projet de Fin d’Etudes ISIGK 2015/2016
93
Figure 5.4 : Interface « Ajouter technicien »
5.2.5 Interface « Administration » :
La figure 5.5 représente l’interface « Administration ».
Projet de Fin d’Etudes ISIGK 2015/2016
94
Figure 5.5 : Interface « Administration ».
5.2.6 Interface « Mission » :
La figure 5.6 représente l’interface « Mission ». Elle permet au technicien de connaitre
les missions à réaliser.
Projet de Fin d’Etudes ISIGK 2015/2016
95
Figure 5.6 : Interface « Mission ».
5.2.7 Interface « Historique des pannes »
La figure 5.7 représente l’interface « Historique des pannes ». Elle permet au
Technicien et à l’Administrateur de consulter l’historique des pannes réparées.
Projet de Fin d’Etudes ISIGK 2015/2016
96
Figure 5.7 : Interface « Historique des pannes »
Conclusion :
À travers ce dernier chapitre, nous avons présenté l’environnement logiciel et quelques
interfaces réalisées dans notre application.
Projet de Fin d’Etudes ISIGK 2015/2016
97
Conclusion générale
Notre projet de fin d’étude consiste à concevoir et développer une application de
gestion des pannes de BTS pour la société Tunisie Télécom.
La réalisation de cette application a permis à Tunisie Télécom de gérer ses pannes de
manière automatisée, continue et en temps réel à travers des équipements mobiles et a été
pour nous une occasion pour développer nos savoirs et notre savoir-faire.
Elle nous a permis d’acquérir de nouvelles connaissances pour nous enrichir et pour
exercer nos capacités d’observations, d’analyse, de créativité, de rédaction et de
programmation. Elle nous a permis également de confronter l’acquis théorique à
l’environnement pratique toute en nous Initiant à la vie professionnelle.
application mobile de gestion de panne de BTS

Contenu connexe

Tendances

Rappport PFE 2012 Ghodhbane Hani - OpenSNC
Rappport PFE 2012 Ghodhbane Hani - OpenSNCRappport PFE 2012 Ghodhbane Hani - OpenSNC
Rappport PFE 2012 Ghodhbane Hani - OpenSNCGhodbane Heni
 
réalisation une application web de gestion des informations météorologiques
réalisation une application web de gestion des informations météorologiquesréalisation une application web de gestion des informations météorologiques
réalisation une application web de gestion des informations météorologiquesMedk Salhi
 
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_webSalma Gouia
 
Rapport PFE BIAT Conception et mise en place d’une plate-forme de gestion des...
Rapport PFE BIAT Conception et mise en place d’une plate-forme de gestion des...Rapport PFE BIAT Conception et mise en place d’une plate-forme de gestion des...
Rapport PFE BIAT Conception et mise en place d’une plate-forme de gestion des...Yasmine Lachheb
 
Rapport Projet De Fin D'étude de Conception et développement d’une applicatio...
Rapport Projet De Fin D'étude de Conception et développement d’une applicatio...Rapport Projet De Fin D'étude de Conception et développement d’une applicatio...
Rapport Projet De Fin D'étude de Conception et développement d’une applicatio...mouafekmazia
 
Rapport du Projet de Fin d'année Génie informatique
Rapport du Projet de Fin d'année Génie informatique Rapport du Projet de Fin d'année Génie informatique
Rapport du Projet de Fin d'année Génie informatique ayoub daoudi
 
Conception et developpement d'une application mobile Android e-location
Conception et developpement d'une application mobile Android e-locationConception et developpement d'une application mobile Android e-location
Conception et developpement d'une application mobile Android e-locationALALSYSE
 
Projet de fin d'etude gestion informatique
Projet de fin d'etude gestion informatiqueProjet de fin d'etude gestion informatique
Projet de fin d'etude gestion informatiquejihene Ab
 
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 2015Anouar Kacem
 
Rapport de projet de fin d'année
Rapport de projet de fin d'année Rapport de projet de fin d'année
Rapport de projet de fin d'année kaies Labiedh
 
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'enseignementNassim Bahri
 
RapportPFE_IngenieurInformatique_ESPRIT
RapportPFE_IngenieurInformatique_ESPRITRapportPFE_IngenieurInformatique_ESPRIT
RapportPFE_IngenieurInformatique_ESPRITLina Meddeb
 
Rapport Projet de Fin d'Etudes
Rapport Projet de Fin d'EtudesRapport Projet de Fin d'Etudes
Rapport Projet de Fin d'EtudesHosni Mansour
 
Conception et Réalisation Application Web Laravel PFE BTS
Conception et Réalisation Application Web Laravel PFE BTSConception et Réalisation Application Web Laravel PFE BTS
Conception et Réalisation Application Web Laravel PFE BTSFaissoilMkavavo
 
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éveloppementDonia Hammami
 
Rapport PFE Ilef Ben Slima
Rapport PFE Ilef Ben SlimaRapport PFE Ilef Ben Slima
Rapport PFE Ilef Ben SlimaIlef Ben Slima
 
Rapport (Mémoire de Master) de stage PFE pour l’obtention du Diplôme Nationa...
Rapport (Mémoire de Master) de stage PFE pour  l’obtention du Diplôme Nationa...Rapport (Mémoire de Master) de stage PFE pour  l’obtention du Diplôme Nationa...
Rapport (Mémoire de Master) de stage PFE pour l’obtention du Diplôme Nationa...Mohamed Amine Mahmoudi
 
Conception et développement d'une application Android pour TUNISAIR
Conception et développement d'une application Android pour TUNISAIRConception et développement d'une application Android pour TUNISAIR
Conception et développement d'une application Android pour TUNISAIRSkander Driss
 
rapport PFE ingénieur génie logiciel INSAT
rapport PFE ingénieur génie logiciel INSATrapport PFE ingénieur génie logiciel INSAT
rapport PFE ingénieur génie logiciel INSATSiwar GUEMRI
 

Tendances (20)

Rappport PFE 2012 Ghodhbane Hani - OpenSNC
Rappport PFE 2012 Ghodhbane Hani - OpenSNCRappport PFE 2012 Ghodhbane Hani - OpenSNC
Rappport PFE 2012 Ghodhbane Hani - OpenSNC
 
Modele rapport pfe esprit
Modele rapport pfe  espritModele rapport pfe  esprit
Modele rapport pfe esprit
 
réalisation une application web de gestion des informations météorologiques
réalisation une application web de gestion des informations météorologiquesréalisation une application web de gestion des informations météorologiques
réalisation une application web de gestion des informations météorologiques
 
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 PFE BIAT Conception et mise en place d’une plate-forme de gestion des...
Rapport PFE BIAT Conception et mise en place d’une plate-forme de gestion des...Rapport PFE BIAT Conception et mise en place d’une plate-forme de gestion des...
Rapport PFE BIAT Conception et mise en place d’une plate-forme de gestion des...
 
Rapport Projet De Fin D'étude de Conception et développement d’une applicatio...
Rapport Projet De Fin D'étude de Conception et développement d’une applicatio...Rapport Projet De Fin D'étude de Conception et développement d’une applicatio...
Rapport Projet De Fin D'étude de Conception et développement d’une applicatio...
 
Rapport du Projet de Fin d'année Génie informatique
Rapport du Projet de Fin d'année Génie informatique Rapport du Projet de Fin d'année Génie informatique
Rapport du Projet de Fin d'année Génie informatique
 
Conception et developpement d'une application mobile Android e-location
Conception et developpement d'une application mobile Android e-locationConception et developpement d'une application mobile Android e-location
Conception et developpement d'une application mobile Android e-location
 
Projet de fin d'etude gestion informatique
Projet de fin d'etude gestion informatiqueProjet de fin d'etude gestion informatique
Projet de fin d'etude gestion informatique
 
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
 
Rapport de projet de fin d'année
Rapport de projet de fin d'année Rapport de projet de fin d'année
Rapport de projet de fin d'année
 
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
 
RapportPFE_IngenieurInformatique_ESPRIT
RapportPFE_IngenieurInformatique_ESPRITRapportPFE_IngenieurInformatique_ESPRIT
RapportPFE_IngenieurInformatique_ESPRIT
 
Rapport Projet de Fin d'Etudes
Rapport Projet de Fin d'EtudesRapport Projet de Fin d'Etudes
Rapport Projet de Fin d'Etudes
 
Conception et Réalisation Application Web Laravel PFE BTS
Conception et Réalisation Application Web Laravel PFE BTSConception et Réalisation Application Web Laravel PFE BTS
Conception et Réalisation Application Web Laravel PFE BTS
 
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 PFE Ilef Ben Slima
Rapport PFE Ilef Ben SlimaRapport PFE Ilef Ben Slima
Rapport PFE Ilef Ben Slima
 
Rapport (Mémoire de Master) de stage PFE pour l’obtention du Diplôme Nationa...
Rapport (Mémoire de Master) de stage PFE pour  l’obtention du Diplôme Nationa...Rapport (Mémoire de Master) de stage PFE pour  l’obtention du Diplôme Nationa...
Rapport (Mémoire de Master) de stage PFE pour l’obtention du Diplôme Nationa...
 
Conception et développement d'une application Android pour TUNISAIR
Conception et développement d'une application Android pour TUNISAIRConception et développement d'une application Android pour TUNISAIR
Conception et développement d'une application Android pour TUNISAIR
 
rapport PFE ingénieur génie logiciel INSAT
rapport PFE ingénieur génie logiciel INSATrapport PFE ingénieur génie logiciel INSAT
rapport PFE ingénieur génie logiciel INSAT
 

En vedette

Conociendo las escrituras el reino de los cielos
Conociendo las escrituras   el reino de los cielosConociendo las escrituras   el reino de los cielos
Conociendo las escrituras el reino de los cielosMisterio Escondido
 
Conociendo las escrituras el reino de los cielos - parte 2
Conociendo las escrituras   el reino de los cielos - parte 2Conociendo las escrituras   el reino de los cielos - parte 2
Conociendo las escrituras el reino de los cielos - parte 2Misterio Escondido
 
Norman gonzalez actividad1_2mapac.pdf
Norman gonzalez actividad1_2mapac.pdfNorman gonzalez actividad1_2mapac.pdf
Norman gonzalez actividad1_2mapac.pdfng3847786
 
La administracion como un arte empírico
La administracion como un arte empíricoLa administracion como un arte empírico
La administracion como un arte empíricoRochy Montenegro
 
Guia para elaboração de plano de negócios
Guia para elaboração de plano de negóciosGuia para elaboração de plano de negócios
Guia para elaboração de plano de negóciosEduardo Santana
 
Опыт развития исследовательских способностей учащихся сельской малокомплектн...
Опыт развития  исследовательских способностей учащихся сельской малокомплектн...Опыт развития  исследовательских способностей учащихся сельской малокомплектн...
Опыт развития исследовательских способностей учащихся сельской малокомплектн...Василиса Закревская
 
GEC 2017: Igor Oliveira
GEC 2017: Igor OliveiraGEC 2017: Igor Oliveira
GEC 2017: Igor OliveiraMark Marich
 
欧洲隐私与数据保护(EU privacy and data protection)
欧洲隐私与数据保护(EU privacy and data protection)欧洲隐私与数据保护(EU privacy and data protection)
欧洲隐私与数据保护(EU privacy and data protection)Aron Shannon
 
A Multidimensional Approach to Definitions, Applied to e-Learning in Language...
A Multidimensional Approach to Definitions, Applied to e-Learning in Language...A Multidimensional Approach to Definitions, Applied to e-Learning in Language...
A Multidimensional Approach to Definitions, Applied to e-Learning in Language...Steve McCarty
 
Manual de politicas de seguridad informatica
Manual de politicas de seguridad informaticaManual de politicas de seguridad informatica
Manual de politicas de seguridad informaticaLecy Sarahi Ramirez Reyes
 

En vedette (15)

Conociendo las escrituras el reino de los cielos
Conociendo las escrituras   el reino de los cielosConociendo las escrituras   el reino de los cielos
Conociendo las escrituras el reino de los cielos
 
Conociendo las escrituras el reino de los cielos - parte 2
Conociendo las escrituras   el reino de los cielos - parte 2Conociendo las escrituras   el reino de los cielos - parte 2
Conociendo las escrituras el reino de los cielos - parte 2
 
Norman gonzalez actividad1_2mapac.pdf
Norman gonzalez actividad1_2mapac.pdfNorman gonzalez actividad1_2mapac.pdf
Norman gonzalez actividad1_2mapac.pdf
 
La administracion como un arte empírico
La administracion como un arte empíricoLa administracion como un arte empírico
La administracion como un arte empírico
 
Guia para elaboração de plano de negócios
Guia para elaboração de plano de negóciosGuia para elaboração de plano de negócios
Guia para elaboração de plano de negócios
 
Intalacion de joomla
Intalacion de joomlaIntalacion de joomla
Intalacion de joomla
 
Ceyx andalcyone
Ceyx andalcyoneCeyx andalcyone
Ceyx andalcyone
 
Опыт развития исследовательских способностей учащихся сельской малокомплектн...
Опыт развития  исследовательских способностей учащихся сельской малокомплектн...Опыт развития  исследовательских способностей учащихся сельской малокомплектн...
Опыт развития исследовательских способностей учащихся сельской малокомплектн...
 
Research methods
Research methodsResearch methods
Research methods
 
GEC 2017: Igor Oliveira
GEC 2017: Igor OliveiraGEC 2017: Igor Oliveira
GEC 2017: Igor Oliveira
 
欧洲隐私与数据保护(EU privacy and data protection)
欧洲隐私与数据保护(EU privacy and data protection)欧洲隐私与数据保护(EU privacy and data protection)
欧洲隐私与数据保护(EU privacy and data protection)
 
A Multidimensional Approach to Definitions, Applied to e-Learning in Language...
A Multidimensional Approach to Definitions, Applied to e-Learning in Language...A Multidimensional Approach to Definitions, Applied to e-Learning in Language...
A Multidimensional Approach to Definitions, Applied to e-Learning in Language...
 
Manual de politicas de seguridad informatica
Manual de politicas de seguridad informaticaManual de politicas de seguridad informatica
Manual de politicas de seguridad informatica
 
Spraakets
SpraaketsSpraakets
Spraakets
 
Necesidades para introducir las tic
Necesidades para introducir las ticNecesidades para introducir las tic
Necesidades para introducir las tic
 

Similaire à application mobile de gestion de panne de BTS

Rapport pfe 2017 Système de gestion des rendez-vous médicaux
Rapport pfe 2017 Système de gestion des rendez-vous médicaux Rapport pfe 2017 Système de gestion des rendez-vous médicaux
Rapport pfe 2017 Système de gestion des rendez-vous médicaux fehmi arbi
 
Rapport pfe isi_Big data Analytique
Rapport pfe isi_Big data AnalytiqueRapport pfe isi_Big data Analytique
Rapport pfe isi_Big data AnalytiqueYosra ADDALI
 
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
 
Rapport_pfe_application_mobile.pdf
Rapport_pfe_application_mobile.pdfRapport_pfe_application_mobile.pdf
Rapport_pfe_application_mobile.pdfNadaHammami5
 
dimensionnement et conception d'un convoyeur à bande
dimensionnement et conception d'un convoyeur à bandedimensionnement et conception d'un convoyeur à bande
dimensionnement et conception d'un convoyeur à bandeHasni Zied
 
Outpatient Department System (OPD)
Outpatient Department System (OPD) Outpatient Department System (OPD)
Outpatient Department System (OPD) Ben Ahmed Zohra
 
pfe_rapport_poste_licence_LFIG.pdf
pfe_rapport_poste_licence_LFIG.pdfpfe_rapport_poste_licence_LFIG.pdf
pfe_rapport_poste_licence_LFIG.pdfnesrine haloui
 
Implémentation et mise en place d’un système décisionnel pour la solution Meg...
Implémentation et mise en place d’un système décisionnel pour la solution Meg...Implémentation et mise en place d’un système décisionnel pour la solution Meg...
Implémentation et mise en place d’un système décisionnel pour la solution Meg...Houssem Eddine Jebri
 
Rapport PFE: PIM (Product Information Management) - A graduation project repo...
Rapport PFE: PIM (Product Information Management) - A graduation project repo...Rapport PFE: PIM (Product Information Management) - A graduation project repo...
Rapport PFE: PIM (Product Information Management) - A graduation project repo...younes elmorabit
 
rapport de stage de boufakri abdelmounaim.pdf
rapport de stage de boufakri abdelmounaim.pdfrapport de stage de boufakri abdelmounaim.pdf
rapport de stage de boufakri abdelmounaim.pdfOussamawahmane
 
Mémoire fin d'étude gestion des interventions
Mémoire fin d'étude gestion des interventionsMémoire fin d'étude gestion des interventions
Mémoire fin d'étude gestion des interventionsMohamed Arar
 
Etude de la mise en place et de la stratégie de lancement d’une plateforme so...
Etude de la mise en place et de la stratégie de lancement d’une plateforme so...Etude de la mise en place et de la stratégie de lancement d’une plateforme so...
Etude de la mise en place et de la stratégie de lancement d’une plateforme so...Houssem Eddine Jebri
 
Rapport de Stage Licence 3
Rapport de Stage Licence 3Rapport de Stage Licence 3
Rapport de Stage Licence 3Dylan Manceau
 
Guide de gestion des ressources hmaines
Guide de gestion des ressources hmainesGuide de gestion des ressources hmaines
Guide de gestion des ressources hmainesOULAAJEB YOUSSEF
 
Ap French Description
Ap French DescriptionAp French Description
Ap French Descriptionjjneill
 
Marché du trail en France : quels sont les impacts de l'essor de cette pratiq...
Marché du trail en France : quels sont les impacts de l'essor de cette pratiq...Marché du trail en France : quels sont les impacts de l'essor de cette pratiq...
Marché du trail en France : quels sont les impacts de l'essor de cette pratiq...Maïlys Meysselle
 
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’étudeOumaimaOuedherfi
 
GRH_guide_francais IMPORTANT.pdf
GRH_guide_francais IMPORTANT.pdfGRH_guide_francais IMPORTANT.pdf
GRH_guide_francais IMPORTANT.pdfJaddaini
 
Rapport de Projet de Fin d'étude .
Rapport de Projet de Fin d'étude .Rapport de Projet de Fin d'étude .
Rapport de Projet de Fin d'étude .Oussama Ben Sghaier
 
Rapport de stage PFE ( DUT) chez Synthèse Conseil - Jaiti Mohammed
Rapport de stage PFE ( DUT) chez Synthèse Conseil  - Jaiti MohammedRapport de stage PFE ( DUT) chez Synthèse Conseil  - Jaiti Mohammed
Rapport de stage PFE ( DUT) chez Synthèse Conseil - Jaiti MohammedMohammed JAITI
 

Similaire à application mobile de gestion de panne de BTS (20)

Rapport pfe 2017 Système de gestion des rendez-vous médicaux
Rapport pfe 2017 Système de gestion des rendez-vous médicaux Rapport pfe 2017 Système de gestion des rendez-vous médicaux
Rapport pfe 2017 Système de gestion des rendez-vous médicaux
 
Rapport pfe isi_Big data Analytique
Rapport pfe isi_Big data AnalytiqueRapport pfe isi_Big data Analytique
Rapport pfe isi_Big data Analytique
 
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 ...
 
Rapport_pfe_application_mobile.pdf
Rapport_pfe_application_mobile.pdfRapport_pfe_application_mobile.pdf
Rapport_pfe_application_mobile.pdf
 
dimensionnement et conception d'un convoyeur à bande
dimensionnement et conception d'un convoyeur à bandedimensionnement et conception d'un convoyeur à bande
dimensionnement et conception d'un convoyeur à bande
 
Outpatient Department System (OPD)
Outpatient Department System (OPD) Outpatient Department System (OPD)
Outpatient Department System (OPD)
 
pfe_rapport_poste_licence_LFIG.pdf
pfe_rapport_poste_licence_LFIG.pdfpfe_rapport_poste_licence_LFIG.pdf
pfe_rapport_poste_licence_LFIG.pdf
 
Implémentation et mise en place d’un système décisionnel pour la solution Meg...
Implémentation et mise en place d’un système décisionnel pour la solution Meg...Implémentation et mise en place d’un système décisionnel pour la solution Meg...
Implémentation et mise en place d’un système décisionnel pour la solution Meg...
 
Rapport PFE: PIM (Product Information Management) - A graduation project repo...
Rapport PFE: PIM (Product Information Management) - A graduation project repo...Rapport PFE: PIM (Product Information Management) - A graduation project repo...
Rapport PFE: PIM (Product Information Management) - A graduation project repo...
 
rapport de stage de boufakri abdelmounaim.pdf
rapport de stage de boufakri abdelmounaim.pdfrapport de stage de boufakri abdelmounaim.pdf
rapport de stage de boufakri abdelmounaim.pdf
 
Mémoire fin d'étude gestion des interventions
Mémoire fin d'étude gestion des interventionsMémoire fin d'étude gestion des interventions
Mémoire fin d'étude gestion des interventions
 
Etude de la mise en place et de la stratégie de lancement d’une plateforme so...
Etude de la mise en place et de la stratégie de lancement d’une plateforme so...Etude de la mise en place et de la stratégie de lancement d’une plateforme so...
Etude de la mise en place et de la stratégie de lancement d’une plateforme so...
 
Rapport de Stage Licence 3
Rapport de Stage Licence 3Rapport de Stage Licence 3
Rapport de Stage Licence 3
 
Guide de gestion des ressources hmaines
Guide de gestion des ressources hmainesGuide de gestion des ressources hmaines
Guide de gestion des ressources hmaines
 
Ap French Description
Ap French DescriptionAp French Description
Ap French Description
 
Marché du trail en France : quels sont les impacts de l'essor de cette pratiq...
Marché du trail en France : quels sont les impacts de l'essor de cette pratiq...Marché du trail en France : quels sont les impacts de l'essor de cette pratiq...
Marché du trail en France : quels sont les impacts de l'essor de cette pratiq...
 
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
 
GRH_guide_francais IMPORTANT.pdf
GRH_guide_francais IMPORTANT.pdfGRH_guide_francais IMPORTANT.pdf
GRH_guide_francais IMPORTANT.pdf
 
Rapport de Projet de Fin d'étude .
Rapport de Projet de Fin d'étude .Rapport de Projet de Fin d'étude .
Rapport de Projet de Fin d'étude .
 
Rapport de stage PFE ( DUT) chez Synthèse Conseil - Jaiti Mohammed
Rapport de stage PFE ( DUT) chez Synthèse Conseil  - Jaiti MohammedRapport de stage PFE ( DUT) chez Synthèse Conseil  - Jaiti Mohammed
Rapport de stage PFE ( DUT) chez Synthèse Conseil - Jaiti Mohammed
 

application mobile de gestion de panne de BTS

  • 1. Projet de Fin d’Etudes ISIGK 2015/2016 I Dédicaces Après avoir rendu grâce â Dieu le tout puissant, je dédis ce travail À Mes chers parents Aucun hommage ne pourrait être à la hauteur de l’amour et de l’affection dont ils ne cessent de nous combler. Qu’ils trouvent dans ce travail un témoignage de nos profond amour et éternelle reconnaissance. À Mes chères frères et sœurs Pour leur soutien, leur patience et leur encouragement. Et spécialement à Tassnim pour son aide. À Ma famille et Mes amis Pour leur aide et leur soutien moral durant l’élaboration du projet de fin d’études.
  • 2. Projet de Fin d’Etudes ISIGK 2015/2016 II Remerciements Au terme de ce travail, je tiens à remercier tous ceux qui ont contribué à la réalisation de ce Projet de Fin d’Etudes, et en particulier : Mon encadreur à l’ISIGK: Madame Imen Mami, pour la qualité de son encadrement, sa disponibilité, son aide précieuse et ses conseils constructif qui m’ont permis de mener à terme ce projet. Ainsi que mon encadreur a Tunisie Telecom : Monsieur Mouadh Rameh, qui a eu la bienveillance de diriger ce travail en me prodiguant conseils, directives et encouragements. Mes sincères remerciements à tous les personnels, les ingénieurs et les techniciens de Tunisie Telecom, qui n’ont jamais cessé de m’apporter leur aide tout au long de ce travail. J’ai et le plaisir de témoigner ma reconnaissance à tous mes enseignants de l’ISIG, pour le savoir et le savoir-faire qu’ils m’ont généreusement inculqués.
  • 3. Projet de Fin d’Etudes ISIGK 2015/2016 III Table des matières Introduction Générale .....................................................................................................1 Chapitre 1 : Identification des besoins............................................................................2 1.1 Objectifs :..............................................................................................................2 1.2 Présentation de Tunisie télécom : .........................................................................2 1.2.1 Regard historique : .........................................................................................2 1.2.2 L’organisation de TUNISIE TELECOM :.....................................................3 1.3 Présentation de l'unité Radio GSM Kairouan :.....................................................4 1.4 Problématique : .....................................................................................................4 1.5 Solution :...............................................................................................................5 1.6 Méthodologie de travail :......................................................................................5 1.6.1 Démarche de la méthodologie :......................................................................6 Conclusion : ................................................................................................................6 Chapitre 2 : Conception « Phase d’incubation » ............................................................7 2.1 Choix du langage de conception adaptés UML :..................................................7 2.2 Spécification des besoins :....................................................................................7 2.2.1 Description du contexte du système :...........................................................8 2.2.2 Spécification des besoins fonctionnels :.......................................................8 2.2.3 Besoins non fonctionnels : .........................................................................12 2.2.4 Identification des acteurs et des cas d’utilisation et affectation des priorités : ...........................................................................................................................................13 2.2.5 Raffinement des cas d’utilisation prioritaire :............................................14 2.2.6 Prototype des interfaces utilisateurs :...........................................................18 2.3 Analyse des cas d’utilisation prioritaires :..........................................................18
  • 4. Projet de Fin d’Etudes ISIGK 2015/2016 IV 2.3.1 Traçabilité entre le modèle de cas d’utilisation (MCU) et le modèle d’analyse (MA) : ...............................................................................................................19 2.3.2 Diagrammes de classes d’analyse :..............................................................24 2.3.3 Diagrammes de collaboration : ....................................................................27 2.4 Conception des cas d’utilisation prioritaires :.....................................................32 2.4.1 Diagrammes des classes de conception :......................................................32 2.4.2 Diagrammes de séquences : .........................................................................39 Conclusion : ..............................................................................................................46 Chapitre 3 : Conception « Phase d’élaboration » .........................................................47 3.1 Capture des besoins : ..........................................................................................47 3.1.1 Raffinement des cas d’utilisations secondaires :..........................................47 3.2 Analyses des cas des utilisations secondaires :...................................................49 3.2.1 Traçabilité entre le modèle de cas d’utilisation (MCU) et le modèle d’analyse (MA) : ...............................................................................................................49 3.2.2 Diagrammes de classes d’analyse :..............................................................52 3.2.3 Diagrammes de collaboration : ....................................................................54 3.3 Conception des cas d’utilisation secondaire : .....................................................56 3.3.1 Diagrammes de classes de conception :.......................................................56 3.3.2 Diagrammes de séquences :.......................................................................60 Conclusion : ..............................................................................................................67 Chapitre 4 : Conception « Phase de construction »......................................................68 4.1 Capture des besoins : ..........................................................................................68 4.1.1 Raffinement des cas d’utilisation tertiaires :................................................68 4.2 Analyse : .............................................................................................................71 4.2.1 Traçabilité entre le modèle de cas d’utilisation (MCU) et le modèle d’analyse (MA) : ...............................................................................................................71 4.2.2 Diagrammes de classes d’analyse :..............................................................73
  • 5. Projet de Fin d’Etudes ISIGK 2015/2016 V 4.2.3 Digrammes de collaboration : ......................................................................75 4.3 Conception :........................................................................................................78 4.3.1 Diagrammes des classes de conception :......................................................78 4.3.2 Diagrammes de séquences : .........................................................................82 4.4 Diagramme de classe des entités :.......................................................................86 Conclusion : ..............................................................................................................87 Chapitre 5 : Conception « Phase de transition »...........................................................89 5.1 Environnement logiciel :.....................................................................................89 5.2 Enchainement des interfaces utilisateur :............................................................90 5.2.1 Interface d’authentification :........................................................................90 5.2.2 Interface d’accueil :......................................................................................91 5.2.3 Interface « Gérer technicien » :....................................................................91 5.2.4 Interface « Ajouter technicien » :.................................................................92 5.2.5 Interface « Administration » : ......................................................................93 5.2.6 Interface « Mission » :..................................................................................94 5.2.7 Interface « Historique des pannes » .............................................................95 Conclusion : ..............................................................................................................96 Conclusion générale......................................................................................................97 Bibliographie ................................................................................................................98
  • 6. Projet de Fin d’Etudes ISIGK 2015/2016 VI Liste des figures Figure 1 : L’organisation de Tunisie télécom.................................................................3 Figure 2.1 : Diagramme de contexte...............................................................................9 Figure 2-2 : Diagramme de cas d’utilisation Global « Gestion des pannes de BTS » .10 Figure 2-3 : Architecture de l’application « Gestion de panne de BTS ».....................13 Figure 2-4 : Cas d'utilisation « S'identifier ». ...............................................................14 Figure 2-5 : Cas d'utilisation « Ajouter technicien ». ...................................................14 Figure 2-6 : Cas d’utilisation « Suivi des pannes ». .....................................................15 Figure 2-7 : Cas d'utilisation « Affecter panne au technicien »....................................15 Figure 2-8 : Cas d’utilisation « Consulter la liste des pannes »....................................16 Figure 2.9 : Cas d’utilisation « Consulter les ordres de mission »...............................16 Figure 2-10 : Cas d'utilisation « Changer l’état de panne »..........................................17 Figure 2.11 : Prototype d’interface « authentification pour technicien ».....................18 Figure 2-12 : le cas d’utilisation « S’identifier »..........................................................19 Figure 2-13 : Cas d’utilisation « Ajouter technicien » .................................................20 Figure 2-14 : Cas d’utilisation « Suivi des pannes »....................................................20 Figure 2.15 : Cas d’utilisation « Affecter panne au technicien » .................................21
  • 7. Projet de Fin d’Etudes ISIGK 2015/2016 VII Figure 2.16 : Cas d’utilisation « Consulter les ordres de mission ».............................22 Figure 2.17 : Cas d’utilisation « Consulter la liste des pannes »..................................23 Figure 2.18 : Cas d’utilisation « Changer l’état de panne » .........................................24 Figure 2.19 : Cas d’utilisation « S’identifier ».............................................................24 Figure 2.20 : Cas d’utilisation « Ajouter Technicien » ................................................25 Figure 2.21 : Cas d’utilisation « Suivi des Pannes » ....................................................25 Figure 2.22 : Cas d’utilisation « Affecter panne au technicien » .................................25 Figure 2.23 : Cas d’utilisation « Consulter la liste des pannes »..................................26 Figure 2.24 : Cas d’utilisation « Consulter ordre de mission »....................................26 Figure 2.25 : Cas d’utilisation « Changer l’état des pannes »......................................27 Figure 2.26 : Diagramme de collaboration relatif au Cas d’utilisation « S’identifier »27 Figure 2.27 : Diagramme de collaboration relatif au cas d’utilisation « Administrateur Ajouter technicien » .................................................................................................................28 Figure 2.28 : Diagramme de collaboration relatif au cas d’utilisation « Suivi des pannes »....................................................................................................................................29 Figure 2.29 : Diagramme de collaboration relatif au cas d’utilisation « Affecter panne au technicien »..........................................................................................................................30 Figure 2-30 : Diagramme de collaboration relatif au cas d’utilisation « Consulter les ordres de mission »...................................................................................................................30 Figure 2-31 : Diagramme de collaboration relatif au cas d’utilisation « Consulter la liste des pannes »......................................................................................................................31 Figure 2-32 : Diagramme de collaboration relatif au cas d’utilisation « Changer l’état de panne ».................................................................................................................................32 Figure 2-33 : Diagramme de classe de conception relatif au cas d’utilisation « S’identifier »..........................................................................................................................33 Figure 2-34 : Diagramme de classe de conception relatif au cas d’utilisation « Ajouter technicien »...............................................................................................................................34
  • 8. Projet de Fin d’Etudes ISIGK 2015/2016 VIII Figure 2-35 : Diagramme de classe de conception relatif au cas d’utilisation « Suivi des pannes »..............................................................................................................................35 Figure 2.36 : Diagramme de classe de conception relatif au cas d’utilisation « Affecter panne au technicien » ...............................................................................................................36 Figure 2-37 : Diagramme de classe de conception relatif au cas d’utilisation « Consulter les ordres de mission »..........................................................................................37 Figure 2-38 : Diagramme de classe de conception relatif au cas d’utilisation « Consulter la liste des pannes »...............................................................................................38 Figure 2-39 : Diagramme de classe de conception relatif au cas d’utilisation « Changer l’état de panne »........................................................................................................................39 Figure 2-40 : Diagramme de séquences relatif au cas d’utilisation « S’identifier ».....40 Figure 2-41 : Diagramme de séquences relatif au cas d’utilisation « Ajouter technicien »................................................................................................................................................41 Figure 2-42 : Diagramme de séquences relatif au cas d’utilisation « Suivi des pannes » ..................................................................................................................................................42 Figure 2.43 : Diagramme de séquences relatif au cas d’utilisation « Affecter panne au technicien »...............................................................................................................................43 Figure 2-44 : Diagramme de séquences relatif au cas d’utilisation « Technicien consulter ordre de mission ».....................................................................................................44 Figure 2-45 : Diagramme de séquences relatif au cas d’utilisation « Consulter la liste des pannes »..............................................................................................................................45 Figure 2.46 : Diagramme de séquences relatif au cas d’utilisation « Changer l’état de panne »......................................................................................................................................46 Figure 3.1 : cas d’utilisation « Modifier technicien »...................................................47 Figure 3.2 : Cas d’utilisation « Supprimer technicien »...............................................48 Figure 3.3 : Cas d’utilisation « Vérifier la disponibilité des matériaux ».....................48 Figure 3.4 : Diagramme de cas d’utilisation « Consulter historique des pannes ».......49 Figure 3.5 : Traçabilité entre MCU et MA relatif au cas d’utilisation « Modifier technicien »...............................................................................................................................50
  • 9. Projet de Fin d’Etudes ISIGK 2015/2016 IX Figure 3.6 : Traçabilité entre MCU et MA relatif au cas d’utilisation « Supprimer technicien »...............................................................................................................................50 Figure 3.7 : Traçabilité entre MCU et MA relatif au cas d’utilisation « Vérifier la disponibilité des matériaux »....................................................................................................51 Figure 3.8 : Traçabilité entre MCU et MA relatif au cas d’utilisation « Consulter historique des pannes ».............................................................................................................51 Figure 3.9 : Diagramme de classes d’analyse relatif au cas d’utilisation « Modifier technicien »...............................................................................................................................52 Figure 3.10 : Diagramme de classes d’analyse relatif au cas d’utilisation « Supprimer technicien »...............................................................................................................................52 Figure 3.11 : Diagramme de classes d’analyse relatif au cas d’utilisation « Vérifier la disponibilité des matériaux »....................................................................................................53 Figure 3.12 : Diagramme de classes d’analyse relatif au cas d’utilisation « Consulter historique des pannes ».............................................................................................................53 Figure 3.13 : Diagramme de collaboration relatif au cas d’utilisation « Modifier technicien »...............................................................................................................................54 Figure 3.14 : Diagramme de collaboration relatif au cas d’utilisation « Supprimer technicien »...............................................................................................................................55 Figure 3.15 : Diagramme de collaboration relatif au cas d’utilisation « Vérifier la disponibilité des matériaux »....................................................................................................55 Figure 3.16 : Diagramme de collaboration relatif au cas d’utilisation « Consulter historique des pannes ».............................................................................................................56 Figure 3.17 : Diagramme de classes de conception relatif au cas d’utilisation « Modifier technicien » ............................................................................................................57 Figure 3.18 : Diagramme de classes de conception relatif au cas d’utilisation « Supprimer technicien »..........................................................................................................58 Figure 3.19 : Diagramme de classes de conception relatif au cas d’utilisation « Vérifier la disponibilité des matériaux »................................................................................................59 Figure 3.20 : Diagramme de classes de conception relatif au cas d’utilisation « Consulter historique des pannes ».........................................................................................60
  • 10. Projet de Fin d’Etudes ISIGK 2015/2016 X Figure 3.21 : Diagramme de séquences relatif au cas d’utilisation « Modifier technicien »...............................................................................................................................61 Figure 3.22 : Diagramme de séquences relatif au cas d’utilisation « Supprimer technicien »...............................................................................................................................63 Figure 3.23 : Diagramme de séquences relatif au cas d’utilisation « Vérifier la disponibilité des matériaux »....................................................................................................65 Figure 3.24 : Diagramme de séquences relatif au cas d’utilisation « Consulter l’historique des pannes »..........................................................................................................66 Figure 4.1 : Diagramme de cas d’utilisation « Ajouter des matériaux »......................68 Figure 4.2 : Diagramme de cas d’utilisation « Modifier matériaux » ..........................69 Figure 4.3 : Diagramme de cas d’utilisation « Supprimer matériaux »........................69 Figure 4.4 : Diagramme de cas d’utilisation « Contacter administrateur »..................70 Figure 4.5 : Traçabilité entre MCU et MA relatif au cas d’utilisation « Ajouter matériaux »...............................................................................................................................71 Figure 4.6 : Traçabilité entre MCU et MA relatif au cas d’utilisation « Modifier matériaux »...............................................................................................................................72 Figure 4.7 : Traçabilité entre MCU et MA relatif au cas d’utilisation « Supprimer matériaux »...............................................................................................................................72 Figure 4.8 : Traçabilité entre MCU et MA relatif au cas d’utilisation « Contacter administrateur »........................................................................................................................73 Figure 4.9 : Diagramme de classes d’analyse relatif au cas d’utilisation « Ajouter matériaux »...............................................................................................................................73 Figure 4.10 : Diagramme de classes d’analyse relatif au cas d’utilisation « Modifier matériaux »...............................................................................................................................74 Figure 4.11 : Diagramme de classes d’analyse relatif au cas d’utilisation « Supprimer matériaux »...............................................................................................................................74 Figure 4.12 : Diagramme de classes d’analyse relatif au cas d’utilisation « Contacter administrateur »........................................................................................................................75
  • 11. Projet de Fin d’Etudes ISIGK 2015/2016 XI Figure 4.13 : Diagramme de collaboration relatif au cas d’utilisation « Ajouter matériaux »...............................................................................................................................75 Figure 4.14 : Diagramme de collaboration relatif au cas d’utilisation « Modifier matériaux »...............................................................................................................................76 Figure 4.15 : Diagramme de collaboration relatif au cas d’utilisation « Supprimer matériaux »...............................................................................................................................77 Figure 4.16 : Diagramme de collaboration relatif au cas d’utilisation « Contacter administrateur »........................................................................................................................77 Figure 4.17 : Diagramme de classes de conception relatif au cas d’utilisation « Ajouter matériaux »...............................................................................................................................78 Figure 4.18 : Diagramme de classes de conception relatif au cas d’utilisation « Modifier matériaux ».............................................................................................................79 Figure 4.19 : Diagramme de classes de conception relatif au cas d’utilisation « Supprimer matériaux »..........................................................................................................80 Figure 4.20 : Diagramme de classes de conception relatif au cas d’utilisation « Contacter administrateur » ....................................................................................................81 Figure 4.21 : Diagramme de séquences relatif au cas d’utilisation « Ajouter matériaux »...............................................................................................................................82 Figure 4.22 : Diagramme de séquences relatif au cas d’utilisation « Modifier matériaux »...............................................................................................................................83 Figure 4.23 : Diagramme de séquences relatif au cas d’utilisation « Supprimer matériaux »...............................................................................................................................85 Figure 4.24 : Diagramme de séquences relatif au cas d’utilisation « Contacter administrateur »........................................................................................................................85 Figure 5.1 : Interface « d’authentification ». ................................................................91 Figure 5.2 : Interface « d’accueil »...............................................................................91 Figure 5.3 : Interface « gérer technicien »....................................................................92 Figure 5.4 : Interface « Ajouter technicien »................................................................93 Figure 5.5 : Interface « Administration ». ....................................................................94
  • 12. Projet de Fin d’Etudes ISIGK 2015/2016 XII Figure 5.6 : Interface « Mission ».................................................................................95 Figure 5.7 : Interface « Historique des pannes »..........................................................96
  • 13. Projet de Fin d’Etudes ISIGK 2015/2016 1 Introduction Générale De nos jours, nous assistons à une apogée des nouvelles technologies et notamment la téléphonie mobile et le réseau GSM (Global System for Mobile Communication). En effet, le nombre d’abonnés au réseau GSM a eu une croissance colossale les dernières années et comme principale conséquence, les exigences des abonnés en matière de qualité de service sont de plus en plus importantes. En fait, dans un marché des télécommunications mobiles à forte concurrence, la satisfaction du client passe au premier plan dans les objectifs des opérateurs du réseau GSM. Pour cela, Tunisie Telecom a donné une grande importance à la maintenance de son Réseau. C’est, effectivement, ici que se situe notre projet de fin d’études qui avait pour but de réaliser un outil de gestion de pannes des BTS (Base Transceiver Station). En fait, il sera utile en proposant une interface conviviale pour enregistrer les intervenions et les pannes afin de réaliser un historique de l’activité maintenance. Ce mémoire s’articule autour de quatre chapitres :  Le premier chapitre, "Identification des besoins", met le projet dans son contexte par une présentation de l’entreprise, du travail demandé et de la problématique à résoudre.  Le deuxième chapitre "Conception phase d’incubation", présente la capture des besoins fonctionnels et techniques de l’application et l’identification des acteurs nécessaires pour cette application.  Le troisième chapitre "Conception « phase d’élaboration »", nous effectuerons l’analyse et la conception de la majorité des cas d’utilisation.  Le quatrième chapitre "la phase de construction", nous produirons le modèle d’analyse et de conception de notre application.  Le cinquième chapitre " la phase de transition" présente les choix techniques adaptés, les environnements matériels et logiciel dont nous avons disposé pour la réalisation de l’application ainsi qu'une description de l’application obtenue.
  • 14. Projet de Fin d’Etudes ISIGK 2015/2016 2 Chapitre 1 : Identification des besoins Introduction Durant ce chapitre, nous présentons le cadre général de notre projet à travers la présentation de l’organisme d’accueil ainsi que le contexte général de projet. Nous allons présenter notre projet de fin d’étude réalisé au sein de la société « Tunisie Télécom » qui a pour but d’appliquer la connaissance que nous avons apprise au sein de l’ISIGK (Institue Supérieure d’Informatique et de Gestion de Kairouan) pour arriver à aboutir à la réalisation d’une application Android de gestion de panne de BTS. 1.1 Objectifs : L’objectif de notre projet est de créer une application Android qui facilite la gestion des pannes de BTS. Cette application a pour objectif d’aider la société à réaliser les différentes activités suivantes :  Détecter et corriger rapidement les pannes  Gérer les pannes à travers un équipement mobile  Faciliter la communication entre administrateur et techniciens  Améliorer la gestion du stock de matériels  Satisfaire les clients/abonnées par la détection et la correction rapides des pannes  Procurer un service plus rapide et de qualité et aux techniciens 1.2 Présentation de Tunisie télécom : Dans cette partie nous présentons la société Tunisie Télécom à travers une présentation de son histoire et de son organigramme. TUNISIE TELECOM désigne le nom commercial de La Société National de télécommunication. Son but est de servir tous les abonnés afin de les rapprocher pour mieux les servir. Tunisie Telecom a pour activité principale la prestation de service, le développement, l’entretien et l’exploitation des réseaux publics de téléphone et la transmission des données [1]. 1.2.1 Regard historique :  17 avril 1995 : Promulgation de la loi N° 36 portant la création de l’offre nationale des télécommunications, dénomme TUNISIE TELECOM.
  • 15. Projet de Fin d’Etudes ISIGK 2015/2016 3  1er Janvier 1996 : Mise en place de l‘office nationale de télécommunication.  20 mars 1998 : Inauguration de la première ligne GSM.  Décembre 1999 : Promulgation du décret n 2844 du 27 décembre 1999, relatif au statut de TUNISIE TELECOM.  Fin 2002 : Restructuration TUNISIE TELECOM en société anonyme.  07 juillet 2004 : Signature de la convention d’interconnexion entre TUNISIE TELECOM et Orascom Telecom TUNISIE.  09 juillet 2004 : Premier conseil d’Administration de la Société Nationale des Télécommunications suite à la transformation de TUNISIE TELECOM en Société anonyme. 1.2.2 L’organisation de TUNISIE TELECOM : Figure 1 : L’organisation de Tunisie télécom
  • 16. Projet de Fin d’Etudes ISIGK 2015/2016 4 1.3 Présentation de l'unité Radio GSM Kairouan : L’unité Radio GSM Kairouan fournit des services d’abonnés ordinaires et d’autres services se rapportant aux réseaux d’entreprises. Elle offre également un ensemble de service de transmission de données comme les réseaux de téléphonie fixe et téléphonie mobile GSM ainsi que les réseaux publinet et publitel. Notre projet de fin d’étude a été réalisé au sein de cette unité. Les systèmes des radios communications mobiles, le GSM en particulier, est aujourd’hui à la tête des systèmes cellulaires numérique et il offre un très grand nombre de services permettant l’échange d’information entre deux ou plusieurs usagers avec une qualité raisonnable. Le BTS (base transeive station), en français station de transissions de base ou station émettrice-réceptrice de base, est un des éléments de base du system cellulaire de téléphone mobile GSM appelé plus communément antennes-relais. Elle est composée essentiellement d’un élément d’interface avec la station de base contrôlant BSC (Base Station Controler), d’un ou plusieurs émetteur récepteur (Transceiver.TRX) et d’une a trois antennes : elle forme ainsi une cellule (base du maillage d’un réseau téléphonique mobile). A Tunisie Télécom Kairouan, il existe deux BSC (Base Station Contrôler) pour contrôler les stations RBS (Radio Base Station) de Kairouan. En cas de dérangement d’une station, la RBS est reconfigurée à partir d'un logiciel appelé OMT (Operating and Maintenance Terminal). 1.4 Problématique : Dans un marché ouvert à la concurrence, le niveau de services offert aux abonnés est une préoccupation de plus en plus importante pour l'entreprise. Pour respecter des exigences clients de plus en plus strictes au niveau qualité et délai, les équipes de Tunisie télécom doivent pallier les difficultés et les problèmes suivants que rencontrent ses techniciens :  Difficultés à détecter rapidement les pannes de BTS.  Dégradation de la qualité de service à cause du délai important entre le déclenchent de la panne et sa détection.  Insatisfaction du client en cas de détection tardive da la panne étant donné que le service est lié directement aux abonnés des réseaux GSM
  • 17. Projet de Fin d’Etudes ISIGK 2015/2016 5 1.5 Solution : Pour résoudre ces différents problèmes, nous avons proposé dans le cadre de notre projet de fin d’étude, une solution simple et efficace intitule « gestion de panne des BTS » qui permet la recherche des pannes du BTS (Base Transeiver Station) de manière automatisée. Cette solution est basée sur l’utilisation d’un (timer) pendant lequel il y a un accès aux fichiers logs, qui regroupent toutes les informations sur les réseaux, et en cas d’une panne dans ce laps de temps le programme l’indique et l’affiche au technicien. Cette solution offre la possibilité de réduire les coûts temporels d’exploitation des logiciels par leur utilisation directement en ligne sans faire chaque fois des saisies des demandes pour détecter les pannes. De plus, elle permet à l’utilisateur de recevoir l’information dans un délai de temps faible. 1.6 Méthodologie de travail : Nous avons choisi la méthode de conception « Processus Unifié » pour la conception et la mise en place de notre application. C’est un processus de développement logiciel, il regroupe les activités à mener pour transformer les besoins d’un utilisateur en système logiciel.  Les caractéristiques essentielles du processus unifié sont :  Le processus unifié est à base de composants.  Le processus unifié est piloté par les cas d’utilisation : Il faut bien comprendre les désirs et les besoins des futurs utilisateurs, le processus de développement sera donc centré sur l'utilisateur (Les utilisateurs humains et/ou systèmes).  Centré sur l’architecture : L’architecture émerge des besoins de l’entreprise, tels qu’ils sont exprimés par les utilisateurs et autres intervenants et tels qu’ils sont reflétés par les cas d’utilisation.  Itératif et incrémental : Le développement d’un produit logiciel peut s’étendre sur plusieurs mois. Nous n’allons pas tout développer d’un coup. Nous pouvons découper le travail en plusieurs parties qui sont autant de mini projets. Chacun d’entre eux représentant une itération qui donne lieu à un incrément.  Le processus unifié utilise le langage UML : (Unified Modeling Language ou « langage de modélisation unifié ») C’est un langage de modélisation graphique à base De pictogrammes. Il est apparu dans le monde du génie logiciel, dans le cadre
  • 18. Projet de Fin d’Etudes ISIGK 2015/2016 6 de la « Conception orientée objet ». UML est couramment utilisé dans les projets logiciels. 1.6.1 Démarche de la méthodologie : Chaque itération du processus unifié est composée de cinq activités : capture des besoins, analyse, conception, implémentation et test. Les itérations peuvent être regroupées en 4 phases :  La phase d’incubation qui permet de délimiter la portée du système (identification des besoins et des acteurs ; analyse, conception, implémentation et test des cas d’utilisation prioritaires)  La phase d’élaboration (capture de nouveaux besoins ; analyse, conception implémentation et test de la majorité des cas d’utilisation formulés)  La phase de construction (capture des besoins restants ; analyse, conception implémentation et test de tous les cas d’utilisation)  La phase de transition qui finalise le produit (validation, mise en place, installation, guide utilisateurs). Conclusion : Durant ce chapitre, nous avons présenté le cadre général de notre projet à travers la présentation de l’organisme d’accueil ainsi que le contexte général de notre projet de fin d’étude. Le chapitre suivant sera consacré à la phase d’incubation du processus unifié.
  • 19. Projet de Fin d’Etudes ISIGK 2015/2016 7 Chapitre 2 : Conception « Phase d’incubation » Introduction : La conception est un processus créatif. C’est la phase la plus importante dans le cycle de développement d’un projet. C’est pour cela, au niveau de ce chapitre, nous allons commencer tout d’abord par présenter et expliciter la première phase de la conception « Phase d’Incubation » qui donne une vue du projet sous forme du produit fini. L’étape de la spécification constitue la base d’un bon départ de tout travail. En effet, l’adéquation de toute application à réaliser aux besoins de ses utilisateurs garantira sa réussite. Pour cela, nous allons étudier dans ce chapitre les besoins fonctionnels et non fonctionnels de notre client. Nous présentons une spécification semi formelle de ces besoins par les diagrammes de cas d’utilisation suivant la modélisation UML. 2.1 Choix du langage de conception adaptés UML : La spécification des besoins sera représentée par les diagrammes de cas d’utilisation suivant la modélisation UML, l’acronyme de « Unified Modeling Language ». UML est langage de modélisation unifié. Il est couramment utilisé dans les projets logiciels, il offre un standard de modélisation pour représenter l’architecture logicielle. Les principaux éléments représentables à l’aide de l’UML sont : les acteurs, les processus, les activités des objets et les schémas de la base de données. Le choix d’UML peut être justifié par les raisons suivantes :  Un langage formel et normalisé par l’OMG (Object Mangement Group)  Une garantie de stabilité.  Un langage sans ambigüité.  Un support de communication performant. 2.2 Spécification des besoins : La spécification des besoins est une étape essentielle pour la réussite des projets .C’est dans cet esprit que tout concepteur doit veiller à la conformité de son application aux spécifications d’utilisateur .C’est à ce stade qu’intervient la spécification des besoins qui est une sorte de contrat entre le concepteur, le développeur et ses clients, évitant ainsi tout risque de malentendu et de mauvaises surprises .Dans ce chapitre, nous définissons les besoins fonctionnels et non fonctionnels de cette solution.
  • 20. Projet de Fin d’Etudes ISIGK 2015/2016 8 2.2.1 Description du contexte du système : L’organisme « Tunisie Telecom » souhaite informatiser son système de la gestion des pannes de son BTS. Nous allons donc étudier les différentes fonctions de cette gestion :  Détecter la panne dans un BTS en utilisant un équipement de détection appelé (Timer). Cet équipement permet d’envoyer une signalisation pour toute panne qui se produit au niveau d’un BTS  Localiser la panne en identifiant l’adressage IP du système informatique connecté au BTS.  Faciliter la communication entre l’administrateur et les techniciens pour la détection et la correction des pannes  Améliorer la gestion des pannes et des techniciens qui vont réparer ces pannes. 2.2.2 Spécification des besoins fonctionnels : Le diagramme de contexte de la figure 2-1 sert à délimiter le contour du système en cours d’étude, définir clairement ses frontières et les acteurs avec lesquels il communique. Ces derniers peuvent être soit des acteurs humains, soit d’autres systèmes avec lesquels le futur système communique.
  • 21. Projet de Fin d’Etudes ISIGK 2015/2016 9 Figure 2.1 : Diagramme de contexte La spécification des besoins fonctionnels est également représentée au travers du diagramme de cas d’utilisation de la figure 2-2, utilisé pour donner une vision globale du comportement fonctionnel d’un système logiciel. Un cas d’utilisation représente une unité discrète d’interaction entre un utilisateur (humain ou machine) et un système. C’est est une unité significative de travail. Dans un diagramme de cas d’utilisation, les utilisateurs sont appelés acteurs (en anglais "actors "), ils interagissent avec les cas d’utilisations (use cases).
  • 22. Projet de Fin d’Etudes ISIGK 2015/2016 10 Figure 2-2 : Diagramme de cas d’utilisation Global « Gestion des pannes de BTS »
  • 23. Projet de Fin d’Etudes ISIGK 2015/2016 11 Le diagramme de cas d’utilisation de la Figure 2-2 décrit les besoins fonctionnels de notre application, ainsi que leurs acteurs qui sont principalement : l’administrateur et le technicien. L'application doit permettre à l’administrateur de  Gérer les techniciens pour  L’ajout de techniciens  Consulter la liste des techniciens afin de  Modifier des informations relatives aux techniciens  Supprimer des techniciens  Gérer pannes pour effectuer le :  Suivie des pannes  Affectation des pannes au technicien ce sui comporte  La vérification de la disponibilité des techniciens  Gérer matériaux pour  L’ajout de matériaux  Consulter la liste des matériaux pour  La modification de matériaux  La suppression de matériaux  Consulter l’historique des pannes L’acteur Admin doit s’identifier pour effectuer les activités de l’application. L'application doit permettre au technicien de  Consulter la liste des pannes  Consulter les ordres de mission  Vérifier la disponibilité des matériaux  Changer l’état des pannes pour indiquer si  La panne a été réparée ou  La panne n’a pas été réparée  Consulter l’historique des pannes  Contacter administrateur L’identification est nécessaire pour l’acteur technicien pour réaliser les activités de l’application.
  • 24. Projet de Fin d’Etudes ISIGK 2015/2016 12 2.2.3 Besoins non fonctionnels : Pour réussir notre projet et pour qu'il soit compatible avec ses utilisateurs, il faut bien vérifier les contraints suivantes de l’application :  Les contraintes Ergonomiques : Afin d’accéder à l’information d’une manière simple, les utilisateurs demandent bien d’avoir des interfaces conviviales avec un affichage rapide, sur lesquelles ils peuvent accéder aux informations et visualiser par la suite les résultats.  Les contraintes Esthétiques : Nous utilisons un fond clair et des couleurs foncées pour le texte. Nous veillerons aussi à ne pas surcharger l’écran s’il ya beaucoup d’information, il faut les découper selon des menus, sous menus ou des boutons, limiter La quantité de texte afin de minimiser la charge cognitive : respecter les règles de lisibilité typographiques : les textes doivent être de taille lisible et la typographie utilisée doit être visible, bien précise et harmonieuse avec les couleurs. Nous utilisons des boutons standards communs pour toute l’application.  Les contraintes Techniques :  L'application doit garantir la sécurité à travers la gestion des droits d'accès.  L’accès à la base de données doit être ou plus rapide.  L’application doit être toujours fonctionnelle.  L'application doit détecter la présence d'une connexion internet.  Les contraintes Réseau :  L'application doit communiquer avec une base de données distante située sur un serveur, suivant une architecture client/serveur comme elle est représentée dans la figure 2-3 ci-dessous.  Les contraintes de sécurité :  Besoin d’établissement de la connexion au niveau d’accès (Ajouter, modifier, lire, écrire…).  Besoin de login et mot de passe.  Politique de réutilisation.  Déconnexion après temps mort.  Les contraintes d’intégrité :  Capture d'erreur d'entrée/sortie.  Traitement de mauvaises données.
  • 25. Projet de Fin d’Etudes ISIGK 2015/2016 13  Intégrité de données : l'intégrité référentielle dans sa table de base de données et interface Figure 2-3 : Architecture de l’application « Gestion de panne de BTS » [2] 2.2.4 Identification des acteurs et des cas d’utilisation et affectation des priorités : Dans cette partie nous avons identifié les acteurs nécessaires de notre application, ainsi que les différents cas d’utilisation relatifs à ces acteurs en affectant leurs priorités. Acteur Cas d’utilisation Priorité Administrateur Ajouter technicien 1 Administrateur Modifier technicien 2 Administrateur Supprimer technicien 2 Administrateur Suivi des pannes 1 Administrateur Affecter panne au technicien 1 Administrateur Ajouter matériaux 3 Administrateur Modifier matériaux 3 Administrateur Supprimer matériaux 3 Technicien Consulter la liste des pannes 1 Technicien Consulter les ordres de mission 1 Technicien Vérifier la disponibilité des matériaux 2 Technicien Changer l’état de panne 1 Technicien Contacter administrateur 3 Administrateur et Technicien S’identifier 1
  • 26. Projet de Fin d’Etudes ISIGK 2015/2016 14 Administrateur et Technicien Consulter l’historique des pannes 2 2.2.5 Raffinement des cas d’utilisation prioritaire : À ce niveau de l’activité « Capture/Spécification des besoins », nous allons raffiner les cas des utilisations de priorité 1 dont nous allons faire à chacun des cas des utilisations, la description textuelle de son scénario principal, ainsi que les exceptions qui peuvent se déroulent pendant l’utilisation de l’application 2.2.5.1 Description textuelle du cas d'utilisation s’identifier : Figure 2-4 : Cas d'utilisation « S'identifier ».  Nom du cas : S'identifier.  Acteur : Administrateur et technicien  Précondition : Connexion établie.  Post-condition : Authentification avec sucées.  Description du scénario principal : 1. Le système affiche l’interface de l’authentification 2. L’utilisateur saisit son login et son mot de passe 3. L’utilisateur survole sur le bouton « Connecter » 4. Le système vérifie le login et le mot de passe 2.2.5.2 Description textuelle du cas d'utilisation « Ajouter technicien » : Figure 2-5 : Cas d'utilisation « Ajouter technicien ».
  • 27. Projet de Fin d’Etudes ISIGK 2015/2016 15  Nom du cas : Ajouter technicien.  Acteur : Administrateur.  Précondition : L'administrateur doit s'identifier afin de pouvoir gérer les techniciens.  Post-condition : Ajout technicien effectué  Description de scénario principal : 1. Le système affiche l’interface « Ajouter technicien » 2. L’administrateur saisit les informations du nouveau technicien 3. L’administrateur appuie sur le bouton « Ajouter technicien » 4. Le système enregistre les données du nouveau technicien 2.2.5.3 Description textuelle du cas d’utilisation « Suivi des pannes » : Figure 2-6 : Cas d’utilisation « Suivi des pannes ».  Nom du cas : Suivi des pannes.  Acteur : Administrateur.  Précondition : L'administrateur doit s'identifier afin de pouvoir effectuer le suivi des pannes.  Post-condition : Suivie des pannes réalisées  Description scénario principal : 1. 1-Le système affiche l’interface « gérer panne » 2. 2-l’administrateur survole sur le bouton « Suivi panne » 3. 3-le système traite s’il Ya de panne détecté 2.2.5.4 Description textuelle du cas d’utilisation « Affecter panne au technicien » : Figure 2-7 : Cas d'utilisation « Affecter panne au technicien ».
  • 28. Projet de Fin d’Etudes ISIGK 2015/2016 16  Nom du cas : Affecter panne au technicien.  Acteur : Administrateur.  Précondition : l’administrateur doit s'identifier pour pouvoir affecter les pannes aux techniciens.  Post-condition : Affectation de panne au technicien avec succès.  Description du scénario principal : 1. Le système affiche l’interface « Affecter panne au technicien » 2. L’administrateur choisit le technicien auquel doit être affecté la panne 3. Le système traite l’affectation de panne 2.2.5.5 Description textuelle du cas d’utilisation « Consulter la liste des pannes » : Figure 2-8 : Cas d’utilisation « Consulter la liste des pannes ».  Nom du cas : Consulter la liste des pannes.  Acteur : Technicien.  Précondition : Le technicien doit s‘identifier afin de pouvoir consulter la liste des pannes.  Post-condition : consultation avec succès.  Description du scénario principal : 1. Le système affiche l’interface « Liste des pannes » 2. Le technicien sélectionne les pannes qu’il souhaite consulter 3. Le système affiche les pannes sélectionnées 2.2.5.6 description textuelle du cas d’utilisation « Consulter les ordres de mission » : Figure 2.9 : Cas d’utilisation « Consulter les ordres de mission »
  • 29. Projet de Fin d’Etudes ISIGK 2015/2016 17  Nom du cas : Consulter les ordres de mission  Acteur : Technicien  Précondition : Le technicien doit s‘identifier afin de pouvoir consulter les ordres de mission  Post-condition : consultation avec succès.  Description du scénario principal : 1. Le système affiche l’interface « ordre de mission » 2. Le technicien demande à consulter ses ordres de mission 3. Le système affiche les ordres de mission 2.2.5.7 Description textuelle du cas d’utilisation « changé l’état de panne » : Figure 2-10 : Cas d'utilisation « Changer l’état de panne ».  Nom du cas : Changer l’état de panne.  Acteur : Technicien.  Précondition : Le technicien doit s’identifier afin de pouvoir changer l’état de panne.  Post-condition : Etat de panne renseignée.  Description du scénario principal : 1. Le système affiche l’interface « changer l’état de panne » 2. Le technicien appuie sur le bouton « réparer » si la panne a été réparée. Dans le cas contraire, il appuie sur le bouton « non réparer » 3. Le système enregistrer l’état de la panne
  • 30. Projet de Fin d’Etudes ISIGK 2015/2016 18 2.2.6 Prototype des interfaces utilisateurs : La figure 2.11 illustre un prototype des interfaces utilisateurs : la connexion et le menu principal. Tout d’abord, l’utilisateur de l’application saisit son login et son mot de passe, ensuite, il survole sur le bouton (connecter). Dons ce cas, le système vérifier les donnes de la connexion : si les donnes sont valides alors le menu principale relatif à l’utilisateur connecté sera affiché. Figure 2.11 : Prototype d’interface « authentification pour technicien » 2.3 Analyse des cas d’utilisation prioritaires : L'objectif de l'analyse est d'accéder à une compréhension des besoins et des exigences du client. Il s'agit de livrer des spécifications pour permettre de choisir la conception de la solution.
  • 31. Projet de Fin d’Etudes ISIGK 2015/2016 19 Un modèle d'analyse livre une spécification complète des besoins issus des cas d'utilisation et les structures qui facilitent la compréhension des scénarios, la préparation, la modification et la maintenance du futur système. 2.3.1 Traçabilité entre le modèle de cas d’utilisation (MCU) et le modèle d’analyse (MA) : À ce niveau de l’activité « Analyse » de la phase d’incubation, nous avons précis les classes relatives aux cas d’utilisation ainsi que les interfaces utilisateurs et les contrôles de chaque cas d’utilisation 2.3.1.1 Traçabilité entre MCU et MA relatif au cas d’utilisation « S’identifier » : La figure 2.12 représente la classe qui est utilisée dans le cas d’utilisation « S’identifier ». Figure 2-12 : le cas d’utilisation « S’identifier »
  • 32. Projet de Fin d’Etudes ISIGK 2015/2016 20 2.3.1.2 Traçabilité entre MCU et MA relatif au cas d’utilisation « Ajouter technicien » : Figure 2-13 : Cas d’utilisation « Ajouter technicien » 2.3.1.3 Traçabilité entre MCU et MA relatif au cas d’utilisation « Suivi des panne » : Figure 2-14 : Cas d’utilisation « Suivi des pannes »
  • 33. Projet de Fin d’Etudes ISIGK 2015/2016 21 2.3.1.4 Traçabilité entre MCU et MA relatif au cas d’utilisation « Affecter panne au technicien » : Figure 2.15 : Cas d’utilisation « Affecter panne au technicien »
  • 34. Projet de Fin d’Etudes ISIGK 2015/2016 22 2.3.1.5 Traçabilité entre MCU et MA relatif au cas d’utilisation « Consulter les ordres de mission » : Figure 2.16 : Cas d’utilisation « Consulter les ordres de mission »
  • 35. Projet de Fin d’Etudes ISIGK 2015/2016 23 2.3.1.6 Traçabilité entre MCU et MA relatif au cas d’utilisation « Consulter la liste des pannes » : Figure 2.17 : Cas d’utilisation « Consulter la liste des pannes » 2.3.1.7 Traçabilité entre MCU et MA relatif au cas d’utilisation « Changer l’état de panne » :
  • 36. Projet de Fin d’Etudes ISIGK 2015/2016 24 Figure 2.18 : Cas d’utilisation « Changer l’état de panne » 2.3.2 Diagrammes de classes d’analyse : À ce niveau de l’activité « Analyse » de la phase d’incubation, nous allons présenter les relations entre les classes, les acteurs, les contrôles et les interfaces de quelques cas d‘utilisation 2.3.2.1 Diagramme de classes d’analyse relatif au cas d’utilisation « S’authentifier » : Figure 2.19 représente les relations entre les classes utilisées dans le cas d’utilisation « S’authentifier ». Figure 2.19 : Cas d’utilisation « S’identifier »
  • 37. Projet de Fin d’Etudes ISIGK 2015/2016 25 2.3.2.2 Diagramme de classes d’analyse relatif au cas d’utilisation « Ajouter technicien » : Figure 2.20 représente les relations entre les classes utilisées dans le cas d’utilisation « Ajouter technicien ». Figure 2.20 : Cas d’utilisation « Ajouter Technicien » 2.3.2.3 Diagramme de classes d’analyse relatif au cas d’utilisation « Suivi des Pannes » : Figure 2.21 représente les relations entre les classes utilisées dans le cas d’utilisation « Suivi des pannes ». Figure 2.21 : Cas d’utilisation « Suivi des Pannes » 2.3.2.4 Diagramme de classes d’analyse relatif au cas d’utilisation « Affecter panne au technicien » : Figure 2.22 représente les relations entre les tables utilisées dans le cas d’utilisation « Affecter panne au technicien ». Figure 2.22 : Cas d’utilisation « Affecter panne au technicien »
  • 38. Projet de Fin d’Etudes ISIGK 2015/2016 26 2.3.2.5 Diagramme de classes d’analyse relatif au cas d’utilisation « Consulter la liste des pannes » : Figure 2.23 représente les relations entre les tables utilisées dans le cas d’utilisation « Consulter la liste des pannes ». Figure 2.23 : Cas d’utilisation « Consulter la liste des pannes » 2.3.2.6 Diagramme de classes d’analyse relatif au cas d’utilisation « Consulter ordre de mission » : Figure 2.24 représente les relations entre les tables utilisées dans le cas d’utilisation « Consulter ordre de mission ». Figure 2.24 : Cas d’utilisation « Consulter ordre de mission » 2.3.2.7 Diagramme de classes d’analyse relatif au cas d’utilisation « Changer l’état de panne » : Figure 2.25 représente les relations entre les classes utilisées dans le cas d’utilisation « changer l’état de panne ».
  • 39. Projet de Fin d’Etudes ISIGK 2015/2016 27 Figure 2.25 : Cas d’utilisation « Changer l’état des pannes » 2.3.3 Diagrammes de collaboration : À ce niveau de l’activité « Analyse » de la phase d’incubation, nous allons élaborer les diagrammes de collaboration des cas des utilisations prioritaires, qui présentent le scénario en détail ainsi que l’interaction entre les éléments du système et l’utilisateur. 2.3.3.1 Diagramme de collaboration relatif au cas d’utilisation « S’authentifier » : La figure 2.26 représente en détail le scénario principal relatif au cas d’utilisation « S’authentifier » ainsi que les interactions entre l’administrateur et l’application au niveau de ce cas d’utilisation. Figure 2.26 : Diagramme de collaboration relatif au Cas d’utilisation « S’identifier »
  • 40. Projet de Fin d’Etudes ISIGK 2015/2016 28 2.3.3.2 Diagramme de collaboration relatif au cas d’utilisation « Ajouter technicien » : La figure 2-27 représente en détail le scénario principal relatif au cas d’utilisation « Ajouter technicien » ainsi que les interactions entre l’administrateur et l’application au niveau de ce cas d’utilisation. Figure 2.27 : Diagramme de collaboration relatif au cas d’utilisation « Ajouter technicien » 2.3.3.3 Diagramme de collaboration relatif au cas d’utilisation « Suivi des pannes » : La figure 2-28 représente en détail le scénario principal relatif au cas d’utilisation « Suivi des pannes » ainsi que les interactions entre l’administrateur et l’application au niveau de ce cas d’utilisation.
  • 41. Projet de Fin d’Etudes ISIGK 2015/2016 29 Figure 2.28 : Diagramme de collaboration relatif au cas d’utilisation « Suivi des pannes » 2.3.3.4 Diagramme de collaboration relatif au cas d’utilisation « Affecter panne au technicien » : La figure 2-29 représente en détail le scénario principal relatif au cas d’utilisation « Affecter panne au technicien » ainsi que les interactions entre l’administrateur et l’application au niveau de ce cas d’utilisation.
  • 42. Projet de Fin d’Etudes ISIGK 2015/2016 30 Figure 2.29 : Diagramme de collaboration relatif au cas d’utilisation « Affecter panne au technicien » 2.3.3.5 Diagramme de collaboration relatif au cas d’utilisation « Consulter les ordres de mission » : La figure 2-30 représente en détail le scénario principal relatif au cas d’utilisation « Consulter les ordres de mission » ainsi que les interactions entre technicien et l’application au niveau de ce cas d’utilisation. Figure 2-30 : Diagramme de collaboration relatif au cas d’utilisation « Consulter les ordres de mission »
  • 43. Projet de Fin d’Etudes ISIGK 2015/2016 31 2.3.3.6 Diagramme de collaboration relatif au cas d’utilisation « Consulter la liste des pannes » : La figure 2-31 représente en détail le scénario principal relatif au cas d’utilisation « Technicien consulter la liste des pannes » ainsi que les interactions entre technicien et l’application au niveau de ce cas d’utilisation. Figure 2-31 : Diagramme de collaboration relatif au cas d’utilisation « Consulter la liste des pannes » 2.3.3.7 Diagramme de collaboration relatif au cas d’utilisation « Changer l’état de panne » : La figure 2-32 représente en détail le scénario principal relatif au cas d’utilisation « Changer l’état de panne » dans le cas où la panne a été réparée ainsi que les interactions entre technicien et l’application au niveau de ce cas d’utilisation.
  • 44. Projet de Fin d’Etudes ISIGK 2015/2016 32 Figure 2-32 : Diagramme de collaboration relatif au cas d’utilisation « Changer l’état de panne » 2.4 Conception des cas d’utilisation prioritaires : La conception dans cette phase consiste à concevoir les cas d’utilisations, nous allons construire alors les diagrammes de classes de conception, ainsi que les interactions entre eux et les diagrammes de séquence de chaque cas d’utilisation de priorité 1. 2.4.1 Diagrammes des classes de conception : Les diagrammes de classes expriment de manière générale la structure statique d’un système, en termes de classes et de relations entre ces classes. Une classe permet de décrire un ensemble d’objets (attributs et comportement), tandis qu’une relation ou association permet de faire apparaître des liens entre ces objets. 2.4.1.1 Diagramme de classe de conception relatif au cas d’utilisation « S’identifier » : La figure 2-33 représente en détaille scénario principal dons un diagramme de classe de conception relatif au cas d’utilisation « S’identifier » ainsi que les interactions entre l’administrateur et l’application au niveau de ce cas d’utilisation.
  • 45. Projet de Fin d’Etudes ISIGK 2015/2016 33 Figure 2-33 : Diagramme de classe de conception relatif au cas d’utilisation « S’identifier » 2.4.1.2 Diagramme de classe de conception relatif au cas d’utilisation « Ajouter technicien » : La figure 2-34 représente en détaille scénario principal dons un diagramme de classe de conception relatif au cas d’utilisation « Ajouter technicien » ainsi que les interactions entre l’administrateur et l’application au niveau de ce cas d’utilisation.
  • 46. Projet de Fin d’Etudes ISIGK 2015/2016 34 Figure 2-34 : Diagramme de classe de conception relatif au cas d’utilisation « Ajouter technicien » 2.4.1.3 Diagramme de classe de conception relatif au cas d’utilisation « Suivi des pannes » : La figure 2-35 représente en détaille scénario principal dons un diagramme de classe de conception relatif au cas d’utilisation « Suivi des pannes » ainsi que les interactions entre l’administrateur et l’application au niveau de ce cas d’utilisation.
  • 47. Projet de Fin d’Etudes ISIGK 2015/2016 35 Figure 2-35 : Diagramme de classe de conception relatif au cas d’utilisation « Suivi des pannes » 2.4.1.4 Diagramme de classe de conception relatif au cas d’utilisation « Affecter panne au technicien » : La figure 2-36 représente en détaille scénario principal dons un diagramme de classe de conception relatif au cas d’utilisation « Affecter panne au technicien » ainsi que les interactions entre l’administrateur et l’application au niveau de ce cas d’utilisation
  • 48. Projet de Fin d’Etudes ISIGK 2015/2016 36 Figure 2.36 : Diagramme de classe de conception relatif au cas d’utilisation « Affecter panne au technicien » 2.4.1.5 Diagramme de classe de conception relatif au cas d’utilisation « Consulter les ordres de mission » : La figure 2-37 représente en détaille scénario principal dons un diagramme de classe de conception relatif au cas d’utilisation « Consulter les ordres de mission » ainsi que les interactions entre l’administrateur et le technicien dons l’application au niveau de ce cas d’utilisation.
  • 49. Projet de Fin d’Etudes ISIGK 2015/2016 37 Figure 2-37 : Diagramme de classe de conception relatif au cas d’utilisation « Consulter les ordres de mission » 2.4.1.6 Diagramme de classe de conception relatif au cas d’utilisation « Consulter la liste des pannes » : La figure 2-38 représente en détaille scénario principal dons un diagramme de classe de conception relatif au cas d’utilisation « Consulter la liste des pannes » ainsi que les interactions entre le technicien et l’application au niveau de ce cas d’utilisation.
  • 50. Projet de Fin d’Etudes ISIGK 2015/2016 38 Figure 2-38 : Diagramme de classe de conception relatif au cas d’utilisation « Consulter la liste des pannes » 2.4.1.7 Diagramme de classe de conception relatif au cas d’utilisation « Changer l’état de panne » : La figure 2-39 représente en détaille scénario principal dons un diagramme de classe de conception relatif au cas d’utilisation « Changer l’état de panne » ainsi que les interactions entre le technicien et l’application au niveau de ce cas d’utilisation.
  • 51. Projet de Fin d’Etudes ISIGK 2015/2016 39 Figure 2-39 : Diagramme de classe de conception relatif au cas d’utilisation « Changer l’état de panne » 2.4.2 Diagrammes de séquences : Les diagrammes de séquences sont la représentation graphique des interfaces entre les acteurs et le système selon un ordre chronologique. Le but étant de décrire comment se déroulent les actions entre les acteurs ou objets. 2.4.2.1 Diagramme de séquences relatif au cas d’utilisation « S’identifier » : La figure 2.40 illustre une description détaillée du scénario relatif au cas d’utilisation « S’identifier ».
  • 52. Projet de Fin d’Etudes ISIGK 2015/2016 40 Figure 2-40 : Diagramme de séquences relatif au cas d’utilisation « S’identifier » 2.4.2.2 Diagramme de séquences relatif au cas d’utilisation « Ajouter technicien » : La figure 2.41 illustre une description détaillée du scénario relatif au cas d’utilisation « Ajouter Technicien »
  • 53. Projet de Fin d’Etudes ISIGK 2015/2016 41 Figure 2-41 : Diagramme de séquences relatif au cas d’utilisation « Ajouter technicien »
  • 54. Projet de Fin d’Etudes ISIGK 2015/2016 42 2.4.2.3 Diagramme de séquences relatif au cas d’utilisation « Suivi des pannes » : La figure 2.42 illustre une description détaillée du scénario relatif au cas d’utilisation « Suivi des pannes » Figure 2-42 : Diagramme de séquences relatif au cas d’utilisation « Suivi des pannes »
  • 55. Projet de Fin d’Etudes ISIGK 2015/2016 43 2.4.2.4 Diagramme de séquences relatif au cas d’utilisation « Affecter panne au technicien » : La figure 2.43 illustre une description détaillée du scénario relatif au cas d’utilisation « Affecter panne au technicien ». Figure 2.43 : Diagramme de séquences relatif au cas d’utilisation « Affecter panne au technicien »
  • 56. Projet de Fin d’Etudes ISIGK 2015/2016 44 2.4.2.5 Diagramme de séquences relatif au cas d’utilisation « Consulter les ordres de mission » : La figure 2.44 illustre une description détaillée du scénario relatif au cas d’utilisation « consulter ordre de mission » Figure 2-44 : Diagramme de séquences relatif au cas d’utilisation « Technicien consulter ordre de mission » 2.4.2.6 Diagramme de séquences relatif au cas d’utilisation « Consulter la liste des pannes » : La figure 2.45 illustre une description détaillée du scénario relatif au cas d’utilisation « Consulter la liste des pannes »
  • 57. Projet de Fin d’Etudes ISIGK 2015/2016 45 Figure 2-45 : Diagramme de séquences relatif au cas d’utilisation « Consulter la liste des pannes » 2.4.2.7 Diagramme de séquences relatif au cas d’utilisation « Changer l’état de panne » : La figure 2.46 illustre une description détaillée du scénario relatif au cas d’utilisation « Changer l’état de panne »
  • 58. Projet de Fin d’Etudes ISIGK 2015/2016 46 Figure 2.46 : Diagramme de séquences relatif au cas d’utilisation « Changer l’état de panne » Conclusion : Après avoir spécifié et analysé les différents besoins que nous devons satisfaire, nous avons procédé à la conception des cas d’utilisation prioritaires de notre application. Dans le chapitre suivant, nous allons passer à la phase d’élaboration du processus unifié.
  • 59. Projet de Fin d’Etudes ISIGK 2015/2016 47 Chapitre 3 : Conception « Phase d’élaboration » Introduction : Cette phase utilise le modèle des cas d'utilisation comme moyen de compréhension et de description des besoins, alors nous consistons à compléter l'identification des besoins et à détailler les cas d'utilisations secondaires trouvés dans la phase d'incubation. 3.1 Capture des besoins : 3.1.1 Raffinement des cas d’utilisations secondaires : 3.1.1.1 Raffinement de cas d’utilisation « Modifier technicien » : Figure 3.1 : cas d’utilisation « Modifier technicien » Il s’agit d’un diagramme de cas d’utilisation relatif à l’acteur « Administrateur » qui a le droit de modifier un technicien  Cas d’utilisation : Modifier technicien  Acteur : Administrateur  Précondition : L’administrateur doit être identifié et autorisé  Post-condition : Modification effectuée  Description du scénario principal : 1. Le système affiche l’interface « Modifier technicien » 2. L’administrateur clique sur le bouton « Modifier technicien » 3. L’administrateur saisit les informations à modifier 4. Le système enregistre les modifications
  • 60. Projet de Fin d’Etudes ISIGK 2015/2016 48 3.1.1.2 Raffinement de cas d’utilisation « Supprimer technicien » : Figure 3.2 : Cas d’utilisation « Supprimer technicien »  Cas d’utilisation : Supprimer technicien  Acteur : Administrateur  Précondition : L’administrateur doit être identifié et autorisé  Post-condition : Technicien supprimé  Description du scénario principal : 1. Le système affiche l’interface « Supprimer technicien » 2. L’administrateur choisit le technicien à supprimer 3. L’administrateur survole sur le bouton « Supprimer technicien » 4. Le système supprime le technicien sélectionné 3.1.1.3 Raffinement de cas d’utilisation « Vérifier la disponibilité des matériaux » : Figure 3.3 : Cas d’utilisation « Vérifier la disponibilité des matériaux »  Cas d’utilisation : Vérifier la disponibilité des matériaux  Acteur : Technicien  Précondition : Le technicien doit être identifié et autorisé  Post-condition : Vérification de la disponibilité des matériaux  La description du scénario principal : 1. Le système affiche l’interface vérifié disponibilité des matériaux 2. Le technicien survole sur le bouton « vérifier disponibilité des matériaux » 3. Le système affiche la liste des matériaux disponibles
  • 61. Projet de Fin d’Etudes ISIGK 2015/2016 49 3.1.1.4 Raffinement de cas d’utilisation « Consulter l’historique des pannes » : Figure 3.4 : Diagramme de cas d’utilisation « Consulter historique des pannes » Il s’agit d’un diagramme de cas d’utilisation relatif à l’acteur « Administrateur » et à l’acteur « Technicien » qui ont le droit de consulter l’historique des pannes.  Cas d’utilisation : Consulter l’historique des pannes  Acteur : Administrateur et Technicien  Précondition : L’administrateur ou le technicien doit être identifié et autorisé  Post-condition : Consultation effectuée  Description du scénario principal : 1. L’application affiche l’interface « Administrateur/Technicien » 2. L’administrateur clique sur l’item (historique des pannes) 3. L’application affiche l’interface « historique des pannes » 3.2 Analyses des cas des utilisations secondaires : 3.2.1 Traçabilité entre le modèle de cas d’utilisation (MCU) et le modèle d’analyse (MA) : 3.2.1.1 Traçabilité entre MCU et MA relatif au cas d’utilisation « Modifier technicien » : La figure 3.5 représente les classes qui sont utilisées dans le cas d’utilisation « Modifier technicien ».
  • 62. Projet de Fin d’Etudes ISIGK 2015/2016 50 Figure 3.5 : Traçabilité entre MCU et MA relatif au cas d’utilisation « Modifier technicien » 3.2.1.2 Traçabilité entre MCU et MA relatif au cas d’utilisation « Supprimer technicien » : La figure 3.6 représente les classes qui sont utilisées dans le cas d’utilisation « Supprimer technicien ». Figure 3.6 : Traçabilité entre MCU et MA relatif au cas d’utilisation « Supprimer technicien »
  • 63. Projet de Fin d’Etudes ISIGK 2015/2016 51 3.2.1.3 Traçabilité entre MCU et MA relatif au cas d’utilisation « Vérifier la disponibilité des matériaux » : La figure 3.7 représente les classes qui sont utilisées dans le cas d’utilisation « Vérifier la disponibilité des matériaux ». Figure 3.7 : Traçabilité entre MCU et MA relatif au cas d’utilisation « Vérifier la disponibilité des matériaux » 3.2.1.4 Traçabilité entre MCU et MA relatif au cas d’utilisation « Consulter historique des pannes » : La figure 3.8 représente les classes qui sont utilisées dans le cas d’utilisation « Consulter historique des pannes ». Figure 3.8 : Traçabilité entre MCU et MA relatif au cas d’utilisation « Consulter historique des pannes »
  • 64. Projet de Fin d’Etudes ISIGK 2015/2016 52 3.2.2 Diagrammes de classes d’analyse : 3.2.2.1 Diagramme de classes d’analyse relatif au cas d’utilisation « Modifier technicien » : La figure 3.9 représente les relations entre les classes utilisées dans le cas d’utilisation « Modifier technicien ». Figure 3.9 : Diagramme de classes d’analyse relatif au cas d’utilisation « Modifier technicien » 3.2.2.2 Diagramme de classes d’analyse relatif au cas d’utilisation « Supprimer technicien » : La figure 3.10 représente les relations entre les classes utilisées dans le cas d’utilisation « Supprimer technicien ». Figure 3.10 : Diagramme de classes d’analyse relatif au cas d’utilisation « Supprimer technicien » 3.2.2.3 Diagramme de classes d’analyse relatif au cas d’utilisation « Vérifier la disponibilité des matériaux » : La figure 3.11 représente les relations entre les classes utilisées dans le cas d’utilisation « Vérifier la disponibilité des matériaux ».
  • 65. Projet de Fin d’Etudes ISIGK 2015/2016 53 Figure 3.11 : Diagramme de classes d’analyse relatif au cas d’utilisation « Vérifier la disponibilité des matériaux » 3.2.2.4 Diagramme de classes d’analyse relatif au cas d’utilisation « Consulter historique des pannes » : La figure 3.12 représente les relations entre les classes utilisées dans le cas « Consulter l’historique des pannes ». Figure 3.12 : Diagramme de classes d’analyse relatif au cas d’utilisation « Consulter historique des pannes »
  • 66. Projet de Fin d’Etudes ISIGK 2015/2016 54 3.2.3 Diagrammes de collaboration : 3.2.3.1 Diagramme de collaboration relatif au cas d’utilisation « Modifier technicien » : Figure 3.13 : Diagramme de collaboration relatif au cas d’utilisation « Modifier technicien » 3.2.3.2 Diagramme de collaboration relatif au cas d’utilisation « Supprimer technicien » :
  • 67. Projet de Fin d’Etudes ISIGK 2015/2016 55 Figure 3.14 : Diagramme de collaboration relatif au cas d’utilisation « Supprimer technicien » 3.2.3.3 Diagramme de collaboration relatif au cas d’utilisation « Vérifier la disponibilité des matériaux » : Figure 3.15 : Diagramme de collaboration relatif au cas d’utilisation « Vérifier la disponibilité des matériaux » 3.2.3.4 Diagramme de collaboration relatif au cas d’utilisation « Consulter historique des pannes » : La figure 3.16 représente en détail le scénario principal relatif au cas d’utilisation « Consulter historique des pannes », ainsi que les interactions entre le responsable « Administrateur » / « Technicien » et l’application au niveau de ce cas d’utilisation.
  • 68. Projet de Fin d’Etudes ISIGK 2015/2016 56 Figure 3.16 : Diagramme de collaboration relatif au cas d’utilisation « Consulter historique des pannes » 3.3 Conception des cas d’utilisation secondaire : 3.3.1 Diagrammes de classes de conception : 3.3.1.1 Diagramme de classes de conception relatif au cas d’utilisation « Modifier technicien » : La figure 3.17 représente les classes du cas d’utilisation « Modifier technicien » et les relations entre elles.
  • 69. Projet de Fin d’Etudes ISIGK 2015/2016 57 Figure 3.17 : Diagramme de classes de conception relatif au cas d’utilisation « Modifier technicien » 3.3.1.2 Diagramme de classes de conception relatif au cas d’utilisation « Supprimer technicien » : La figure 3.18 représente les classes du cas d’utilisation « Supprimer technicien » et les relations entre elles.
  • 70. Projet de Fin d’Etudes ISIGK 2015/2016 58 Figure 3.18 : Diagramme de classes de conception relatif au cas d’utilisation « Supprimer technicien » 3.3.1.3 Diagramme de classes de conception relatif au cas d’utilisation « Vérifier la disponibilité des matériaux » : La figure 3.19 représente les classes du cas d’utilisation « Technicien vérifier disponibilité des matériaux » et les relations entre elles.
  • 71. Projet de Fin d’Etudes ISIGK 2015/2016 59 Figure 3.19 : Diagramme de classes de conception relatif au cas d’utilisation « Vérifier la disponibilité des matériaux » 3.3.1.4 Diagramme de classes de conception relatif au cas d’utilisation « Consulter historique des pannes » : La figure 3.20 représente les classes du cas d’utilisation « Technicien vérifier disponibilité des matériaux » et les relations entre elles.
  • 72. Projet de Fin d’Etudes ISIGK 2015/2016 60 Figure 3.20 : Diagramme de classes de conception relatif au cas d’utilisation « Consulter historique des pannes » 3.3.2 Diagrammes de séquences : 3.3.2.1 Diagramme de séquences relatif au cas d’utilisation « Modifier technicien » : La figure 3.21 illustre la description détaillée du scénario relatif au cas d’utilisation « Modifier technicien ».
  • 73. Projet de Fin d’Etudes ISIGK 2015/2016 61 Figure 3.21 : Diagramme de séquences relatif au cas d’utilisation « Modifier technicien »
  • 74. Projet de Fin d’Etudes ISIGK 2015/2016 62 3.3.2.2 Diagramme de séquences relatif au cas d’utilisation « Supprimer technicien » : La figure 3.22 illustre la description détaillée du scénario relatif au cas d’utilisation « Supprimer technicien ».
  • 75. Projet de Fin d’Etudes ISIGK 2015/2016 63 Figure 3.22 : Diagramme de séquences relatif au cas d’utilisation « Supprimer technicien »
  • 76. Projet de Fin d’Etudes ISIGK 2015/2016 64 3.3.2.3 Diagramme de séquences relatif au cas d’utilisation « Vérifier la disponibilité des matériaux » : La figure 3.23 illustre la description détaillée du scénario relatif au cas d’utilisation « Vérifier la disponibilité des matériaux ».
  • 77. Projet de Fin d’Etudes ISIGK 2015/2016 65 Figure 3.23 : Diagramme de séquences relatif au cas d’utilisation « Vérifier la disponibilité des matériaux »
  • 78. Projet de Fin d’Etudes ISIGK 2015/2016 66 3.3.2.4 Diagramme de séquences relatif au cas d’utilisation « Consulter l’historique des pannes » : La figure 3.24 illustre la description détaillée du scénario relatif au cas d’utilisation « Consulter l’historique des pannes ». Figure 3.24 : Diagramme de séquences relatif au cas d’utilisation « Consulter l’historique des pannes »
  • 79. Projet de Fin d’Etudes ISIGK 2015/2016 67 Conclusion : Au cours de cette phase, nous avons procédé à la conception des cas d’utilisation secondaires de notre application. Dans le chapitre suivant, nous allons passer à la phase de la « construction » du processus unifié
  • 80. Projet de Fin d’Etudes ISIGK 2015/2016 68 Chapitre 4 : Conception « Phase de construction » Introduction : La phase de construction est la troisième phase du processus unifié. Au cours de ce chapitre, nous allons concevoir les cas d’utilisations tertiaires de notre application. 4.1 Capture des besoins : 4.1.1 Raffinement des cas d’utilisation tertiaires : 4.1.1.1 Raffinement de cas d’utilisation « Ajouter des matériaux » : Figure 4.1 : Diagramme de cas d’utilisation « Ajouter des matériaux » Il s’agit d’un diagramme de cas d’utilisation relatif à l’acteur « Administrateur » qui a le droit d’ajouter des matériaux.  Cas d’utilisation : Ajouter des matériaux  Acteur : Administrateur  Précondition : L’administrateur doit être identifié et autorisé  Post-condition : Matériaux ajoutés.  Description du scénario principal : 1- L’application affiche l’interface « Ajouter matériaux » 2- L’administrateur saisit les données relatives aux matériaux à ajouter 3- L’administrateur clique sur le bouton (Ajouter matériaux) 4- L’application enregistrer les nouveaux matériaux
  • 81. Projet de Fin d’Etudes ISIGK 2015/2016 69 4.1.1.2 Raffinement de cas d’utilisation « Modifier matériaux » : Figure 4.2 : Diagramme de cas d’utilisation « Modifier matériaux » Il s’agit d’un diagramme de cas d’utilisation relatif à l’acteur « Administrateur » qui a le droit de modifier des matériaux.  Cas d’utilisation : Modifier matériaux  Acteur : Administrateur  Précondition : L’administrateur doit être identifié et autorisé  Post-condition : Modifier des matériaux.  Description du scenario principal : 1- L’application affiche l’interface « Consulter liste des matériaux » 2- L’administrateur survole sur l’item (Modifier matériaux) 3- L’application affiche l’interface « Modifier matériaux » 4- L’administrateur saisit les nouvelles informations des matériaux à modifier 5- L’application enregistrer ces modifications. 4.1.1.3 Raffinement de cas d’utilisation « Supprimer matériaux » : Figure 4.3 : Diagramme de cas d’utilisation « Supprimer matériaux » Il s’agit d’un diagramme de cas d’utilisation relatif à l’acteur « Administrateur » qui a le droit de supprimer des matériaux.  Cas d’utilisation : Supprimer matériaux  Acteur : Administrateur  Précondition : L’administrateur doit être identifié et autorisé  Post-condition : Matériaux supprimés.
  • 82. Projet de Fin d’Etudes ISIGK 2015/2016 70  Description du scénario principal : 1. L’application affiche l’interface « Consulter liste des matériaux » 2. L’administrateur clique sur l’item (Supprimer matériaux) 3. L’application affiche l’interface « Supprimer matériaux » 4. L’administrateur sélectionne les matériaux à supprimer 5. L’application supprime les matériaux. 4.1.1.4 Raffinement de cas d’utilisation « Contacter administrateur » : Figure 4.4 : Diagramme de cas d’utilisation « Contacter administrateur » Il s’agit d’un diagramme de cas d’utilisation relatif à l’acteur « Technicien » qui a le droit de contacter l’administrateur.  Cas d’utilisation : Contacter administrateur  Acteur : Technicien  Précondition : Le technicien doit être identifié et autorisé  Post-condition : Administrateur contacté.  Description du scénario principal : 1. L’application affiche l’interface « Contacter l’administrateur » 2. Le technicien rédige son message 3. Le technicien survole sur le bouton (envoyer) 4. L’application envoie le message à l’administrateur
  • 83. Projet de Fin d’Etudes ISIGK 2015/2016 71 4.2 Analyse : 4.2.1 Traçabilité entre le modèle de cas d’utilisation (MCU) et le modèle d’analyse (MA) : 4.2.1.1 Traçabilité entre MCU et MA relatif au cas d’utilisation « Ajouter matériaux » : La figure 4.5 représente les classes qui sont utilisées dans le cas d’utilisation « Ajouter matériaux ». Figure 4.5 : Traçabilité entre MCU et MA relatif au cas d’utilisation « Ajouter matériaux » 4.2.1.2 Traçabilité entre MCU et MA relatif au cas d’utilisation « Modifier matériaux » : La figure 4.6 représente les classes qui sont utilisées dans le cas d’utilisation « Modifier matériaux ».
  • 84. Projet de Fin d’Etudes ISIGK 2015/2016 72 Figure 4.6 : Traçabilité entre MCU et MA relatif au cas d’utilisation « Modifier matériaux » 4.2.1.3 Traçabilité entre MCU et MA relatif au cas d’utilisation « Supprimer matériaux » : La figure 4.7 représente les classes qui sont utilisées dans le cas d’utilisation « Supprimer matériaux ». Figure 4.7 : Traçabilité entre MCU et MA relatif au cas d’utilisation « Supprimer matériaux »
  • 85. Projet de Fin d’Etudes ISIGK 2015/2016 73 4.2.1.4 Traçabilité entre MCU et MA relatif au cas d’utilisation « Contacter administrateur » : La figure 4.8 représente les classes qui sont utilisées dans le cas d’utilisation « Contacter administrateur ». Figure 4.8 : Traçabilité entre MCU et MA relatif au cas d’utilisation « Contacter administrateur » 4.2.2 Diagrammes de classes d’analyse : 4.2.2.1 Diagramme de classes d’analyse relatif au cas d’utilisation « Ajouter matériaux » : La figure 4.9 représente les classes qui sont utilisées dans le cas d’utilisation « Ajouter matériaux ». Figure 4.9 : Diagramme de classes d’analyse relatif au cas d’utilisation « Ajouter matériaux »
  • 86. Projet de Fin d’Etudes ISIGK 2015/2016 74 4.2.2.2 Diagramme de classes d’analyse relatif au cas d’utilisation « Modifier matériaux » : La figure 4.10 représente les classes qui sont utilisées dans le cas d’utilisation « modifier matériaux ». Figure 4.10 : Diagramme de classes d’analyse relatif au cas d’utilisation « Modifier matériaux » 4.2.2.3 Diagramme de classes d’analyse relatif au cas d’utilisation « Supprimer matériaux » : La figure 4.11 représente les classes qui sont utilisées dans le cas d’utilisation « Supprimer matériaux ». Figure 4.11 : Diagramme de classes d’analyse relatif au cas d’utilisation « Supprimer matériaux » 4.2.2.4 Diagramme de classes d’analyse relatif au cas d’utilisation « Contacter administrateur » : La figure 4.12 représente les classes qui sont utilisées dans le cas d’utilisation « Contacter administrateur ».
  • 87. Projet de Fin d’Etudes ISIGK 2015/2016 75 Figure 4.12 : Diagramme de classes d’analyse relatif au cas d’utilisation « Contacter administrateur » 4.2.3 Digrammes de collaboration : 4.2.3.1 Diagramme de collaboration relatif au cas d’utilisation « Ajouter matériaux » : La figure 4.13 représente en détail le scénario principal relatif au cas d’utilisation « Ajouter matériaux », ainsi que les interactions entre le responsable « Administrateur » et l’application au niveau de ce cas d’utilisation. Figure 4.13 : Diagramme de collaboration relatif au cas d’utilisation « Ajouter matériaux »
  • 88. Projet de Fin d’Etudes ISIGK 2015/2016 76 4.2.3.2 Diagramme de collaboration relatif au cas d’utilisation « Modifier matériaux » : La figure 4.14 représente en détail le scénario principal relatif au cas d’utilisation « Modifier matériaux », ainsi que les interactions entre le responsable « Administrateur » et l’application au niveau de ce cas d’utilisation. Figure 4.14 : Diagramme de collaboration relatif au cas d’utilisation « Modifier matériaux » 4.2.3.3 Diagramme de collaboration relatif au cas d’utilisation « Supprimer matériaux » : La figure 4.15 représente en détail le scénario principal relatif au cas d’utilisation « Supprimer matériaux », ainsi que les interactions entre le responsable « Administrateur » et l’application au niveau de ce cas d’utilisation.
  • 89. Projet de Fin d’Etudes ISIGK 2015/2016 77 Figure 4.15 : Diagramme de collaboration relatif au cas d’utilisation « Supprimer matériaux » 4.2.3.4 Diagramme de collaboration relatif au cas d’utilisation « Contacter administrateur » : La figure 4.16 représente en détail le scénario principal relatif au cas d’utilisation « Contacter administrateur », ainsi que les interactions entre le responsable « Technicien » et l’application au niveau de ce cas d’utilisation. Figure 4.16 : Diagramme de collaboration relatif au cas d’utilisation « Contacter administrateur »
  • 90. Projet de Fin d’Etudes ISIGK 2015/2016 78 4.3 Conception : 4.3.1 Diagrammes des classes de conception : 4.3.1.1 Diagramme de classes de conception relatif au cas d’utilisation « Ajouter matériaux » : La figure 4.17 représente les classes relatives au cas d’utilisation « Ajouter matériaux » et les relations entre elles. Utilisateur « Administrateur ». Figure 4.17 : Diagramme de classes de conception relatif au cas d’utilisation « Ajouter matériaux » 4.3.1.2 Diagramme de classes de conception relatif au cas d’utilisation « Modifier matériaux » : La figure 4.18 représente les classes relatives au cas d’utilisation « modifier matériaux » et les relations entre elles. Utilisateur « Administrateur ».
  • 91. Projet de Fin d’Etudes ISIGK 2015/2016 79 Figure 4.18 : Diagramme de classes de conception relatif au cas d’utilisation « Modifier matériaux » 4.3.1.3 Diagramme de classes de conception relatif au cas d’utilisation « Supprimer matériaux » : La figure 4.19 représente les classes relatives au cas d’utilisation « Supprimer matériaux » et les relations entre elles. Utilisateur « Administrateur ».
  • 92. Projet de Fin d’Etudes ISIGK 2015/2016 80 Figure 4.19 : Diagramme de classes de conception relatif au cas d’utilisation « Supprimer matériaux » 4.3.1.4 Diagramme de classes de conception relatif au cas d’utilisation « Contacter administrateur » : La figure 4.20 représente les classes relatives au cas d’utilisation « Contacter administrateur » et les relations entre elles. Utilisateur « Technicien ».
  • 93. Projet de Fin d’Etudes ISIGK 2015/2016 81 Figure 4.20 : Diagramme de classes de conception relatif au cas d’utilisation « Contacter administrateur »
  • 94. Projet de Fin d’Etudes ISIGK 2015/2016 82 4.3.2 Diagrammes de séquences : 4.3.2.1 Diagramme de séquences relatif au cas d’utilisation « Ajouter matériaux » : La figure 4.21 illustre une description détaillée du scénario relatif au cas d’utilisation « Ajouter matériaux ». Utilisateur « Administrateur ». Figure 4.21 : Diagramme de séquences relatif au cas d’utilisation « Ajouter matériaux »
  • 95. Projet de Fin d’Etudes ISIGK 2015/2016 83 4.3.2.2 Diagramme de séquences relatif au cas d’utilisation « Modifier matériaux » : La figure 4.22 illustre une description détaillée du scénario relatif au cas d’utilisation « Modifier matériaux ». Utilisateur « Administrateur ». Figure 4.22 : Diagramme de séquences relatif au cas d’utilisation « Modifier matériaux »
  • 96. Projet de Fin d’Etudes ISIGK 2015/2016 84 4.3.2.3 Diagramme de séquences relatif au cas d’utilisation « Supprimer matériaux » : La figure 4.23 illustre une description détaillée du scénario relatif au cas d’utilisation « Supprimer matériaux ». Utilisateur « Administrateur ».
  • 97. Projet de Fin d’Etudes ISIGK 2015/2016 85 Figure 4.23 : Diagramme de séquences relatif au cas d’utilisation « Supprimer matériaux » 4.3.2.4 Diagramme de séquences relatif au cas d’utilisation « Contacter administrateur » : La figure 4.24 illustre une description détaillée du scénario relatif au cas d’utilisation « Contacter administrateur ». Utilisateur « Technicien ». Figure 4.24 : Diagramme de séquences relatif au cas d’utilisation « Contacter administrateur »
  • 98. Projet de Fin d’Etudes ISIGK 2015/2016 86 4.4 Diagramme de classe des entités : La classe est un concept abstrait qui permet de représenter toutes les entités d'un système. La classe est définie par son nom, ses attributs et ses opérations. La figure 4.25 illustre le schéma de la base de données « Administrateur » et « Technicien »et les relations entre les tables (les tables mères et les tables filles).
  • 99. Projet de Fin d’Etudes ISIGK 2015/2016 87 Figure 4.25 : Diagramme de classes d’entité globale Conclusion : Dans ce chapitre, nous avons présenté le raffinement, l’analyse et la conception des cas d’utilisations tertiaires, ainsi que le schéma de la base de données « Administrateur » et
  • 100. Projet de Fin d’Etudes ISIGK 2015/2016 88 « Technicien » de notre application. Nous passons à la prochaine phase qui consiste à l’intégration de notre application dans l’environnement de l’utilisateur.
  • 101. Projet de Fin d’Etudes ISIGK 2015/2016 89 Chapitre 5 : Conception « Phase de transition » Introduction : Cette phase suppose des activités comme la formation des utilisateurs clients, la mise en œuvre d'un service d'assistance et la correction des anomalies constatées. Un groupe d'utilisateurs essaye le produit et détecte les anomalies et défauts. Au cours de ce chapitre, nous allons présenter notre environnement matériel et logiciel, ensuite, nous allons mettre en place l’application et l’intégrer dans l’environnement de l’utilisateur. 5.1 Environnement logiciel : Dans cette partie, nous présentons les outils de modélisation et de développement de notre application.  Pacestar UML Diagramme permet de générer des diagrammes UML 2.0 rapidement et facilement. Il permet de créer des diagrammes d'activité, diagrammes de classes et objets, diagrammes de communication, diagrammes de cas, diagrammes de séquence, diagrammes d'états, diagrammes de package, schémas de composants, diagrammes de déploiement, diagrammes de structure composite et donne une vue d'ensemble de l'interaction des diagrammes [3].  Android, prononcé androïde, est un système d’exploitation mobile open source basée sur le noyau Linux et développé actuellement par google. Le système a d'abord été conçu pour les smartphones et tablette tactile, puis s'est diversifié dans les objets connectés et ordinateurs comme les télévisions les voitures, les ordinateurs et les smartwath. Le système a été lancé en juin 2007 à la suite du rachat par google en 2005 de la startup du même nom. En 2015, Android est le système d'exploitation le plus utilisé dans le monde avec plus de 80 % de parts de marché dans les smartphones [4].  Android Studio permet principalement d'éditer les fichiers Java et les fichiers de configuration d'une application Android. Il propose entre autres des outils pour gérer le développement d'applications multilingues et permet de visualiser
  • 102. Projet de Fin d’Etudes ISIGK 2015/2016 90 la mise en page des écrans sur des écrans de résolutions variées simultanément [5].  Genymotion : le nouvel émulateur Android offre un support de Jelly Bean. Il supporte la souris, l’Ethernet, le RTC, l’audio, la gestion de l’alimentation, le partage de fichier avec l’OS hôte, l’USB, le WiFi et l’OpenGL [6].  Mobogenie est un gestionnaire de fichiers pour smartphone Android. Ce logiciel permet de gérer, sauvegarder et restaurer les données (contacts, SMS, photos, musique, vidéos, applications) de votre téléphone à partir de votre ordinateur [7]. 5.2 Enchainement des interfaces utilisateur : Durant cette activité, nous présentons quelques interfaces de notre application réalisée. 5.2.1 Interface d’authentification : La figure 5.1 représente l’interface d’authentification pour l’administrateur et le technicien. Ils doivent saisir le login et mot de passe pour pouvoir accéder à l’application.
  • 103. Projet de Fin d’Etudes ISIGK 2015/2016 91 Figure 5.1 : Interface « d’authentification ». 5.2.2 Interface d’accueil : La figure 5.2 représente l’interface accueil de l’application. Figure 5.2 : Interface « d’accueil ». 5.2.3 Interface « Gérer technicien » : La figure 5.3 représente l’interface « Gérer technicien » de l’application. L’Administrateur peut gérer les techniciens à travers cette interface.
  • 104. Projet de Fin d’Etudes ISIGK 2015/2016 92 Figure 5.3 : Interface « gérer technicien » 5.2.4 Interface « Ajouter technicien » : La figure 5.4 représente l’interface « Ajouter technicien ». Par cette interface l’administrateur peut ajouter des techniciens.
  • 105. Projet de Fin d’Etudes ISIGK 2015/2016 93 Figure 5.4 : Interface « Ajouter technicien » 5.2.5 Interface « Administration » : La figure 5.5 représente l’interface « Administration ».
  • 106. Projet de Fin d’Etudes ISIGK 2015/2016 94 Figure 5.5 : Interface « Administration ». 5.2.6 Interface « Mission » : La figure 5.6 représente l’interface « Mission ». Elle permet au technicien de connaitre les missions à réaliser.
  • 107. Projet de Fin d’Etudes ISIGK 2015/2016 95 Figure 5.6 : Interface « Mission ». 5.2.7 Interface « Historique des pannes » La figure 5.7 représente l’interface « Historique des pannes ». Elle permet au Technicien et à l’Administrateur de consulter l’historique des pannes réparées.
  • 108. Projet de Fin d’Etudes ISIGK 2015/2016 96 Figure 5.7 : Interface « Historique des pannes » Conclusion : À travers ce dernier chapitre, nous avons présenté l’environnement logiciel et quelques interfaces réalisées dans notre application.
  • 109. Projet de Fin d’Etudes ISIGK 2015/2016 97 Conclusion générale Notre projet de fin d’étude consiste à concevoir et développer une application de gestion des pannes de BTS pour la société Tunisie Télécom. La réalisation de cette application a permis à Tunisie Télécom de gérer ses pannes de manière automatisée, continue et en temps réel à travers des équipements mobiles et a été pour nous une occasion pour développer nos savoirs et notre savoir-faire. Elle nous a permis d’acquérir de nouvelles connaissances pour nous enrichir et pour exercer nos capacités d’observations, d’analyse, de créativité, de rédaction et de programmation. Elle nous a permis également de confronter l’acquis théorique à l’environnement pratique toute en nous Initiant à la vie professionnelle.