application mobile de gestion de panne de BTS

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.

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.

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

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
d’analyse (MA) : ...............................................................................................................49
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
d’analyse (MA) : ...............................................................................................................71

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

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

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

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
« Consulter les ordres de mission »..........................................................................................37
« 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

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
Figure 3.12 : Diagramme de classes d’analyse relatif au cas d’utilisation « Consulter
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
Figure 3.16 : Diagramme de collaboration relatif au cas d’utilisation « Consulter
Figure 3.17 : Diagramme de classes de conception relatif au cas d’utilisation
« Modifier technicien » ............................................................................................................57
« Supprimer technicien »..........................................................................................................58
Figure 3.19 : Diagramme de classes de conception relatif au cas d’utilisation « Vérifier
la disponibilité des matériaux »................................................................................................59
« Consulter historique des pannes ».........................................................................................60

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
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
matériaux »...............................................................................................................................74
matériaux »...............................................................................................................................74
Figure 4.12 : Diagramme de classes d’analyse relatif au cas d’utilisation « Contacter
administrateur »........................................................................................................................75

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
« Modifier matériaux ».............................................................................................................79
« Supprimer matériaux »..........................................................................................................80
« 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

XII
Figure 5.6 : Interface « Mission ».................................................................................95
Figure 5.7 : Interface « Historique des pannes »..........................................................96

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.

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.

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

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

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

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é.

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.

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.

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).

10
Figure 2-2 : Diagramme de cas d’utilisation Global « Gestion des pannes de BTS »

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.

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.

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

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 ».

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.
 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 ».

16
 Nom du cas : Affecter panne au technicien.
 Précondition : l’administrateur doit s'identifier pour pouvoir affecter les pannes aux
techniciens.
 Post-condition : Affectation de panne au technicien avec succès.
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.
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 »

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.
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.
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

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.

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 »

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 »

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 »

22
« Consulter les ordres de mission » :
Figure 2.16 : Cas d’utilisation « Consulter les ordres de mission »

23
« 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 » :

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 »

25
« Ajouter technicien » :
« 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 » :
« Suivi des pannes ».
Figure 2.21 : Cas d’utilisation « Suivi des Pannes »
« 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 »

26
« Consulter la liste des pannes ».
Figure 2.23 : Cas d’utilisation « Consulter la liste des pannes »
« Consulter ordre de mission » :
« Consulter ordre de mission ».
Figure 2.24 : Cas d’utilisation « Consulter ordre de mission »
« Changer l’état de panne » :
« changer l’état de panne ».

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 »

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 » :
« Suivi des pannes » ainsi que les interactions entre l’administrateur et l’application au niveau
de ce cas d’utilisation.

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
« Affecter panne au technicien » ainsi que les interactions entre l’administrateur et
l’application au niveau de ce cas d’utilisation.

30
Figure 2.29 : Diagramme de collaboration relatif au cas d’utilisation « Affecter panne au
technicien »
« 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 »

31
2.3.3.6 Diagramme de collaboration relatif au cas d’utilisation « Consulter
la liste des pannes » :
« Technicien consulter la liste des pannes » ainsi que les interactions entre technicien et
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
« 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.

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.

33
Figure 2-33 : Diagramme de classe de conception relatif au cas d’utilisation « S’identifier »
« Ajouter technicien » :
de conception relatif au cas d’utilisation « Ajouter technicien » ainsi que les interactions entre

34
Figure 2-34 : Diagramme de classe de conception relatif au cas d’utilisation « Ajouter
technicien »
« Suivi des pannes » :
de conception relatif au cas d’utilisation « Suivi des pannes » ainsi que les interactions entre

35
Figure 2-35 : Diagramme de classe de conception relatif au cas d’utilisation « Suivi des
pannes »
« Affecter panne au technicien » :
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

36
Figure 2.36 : Diagramme de classe de conception relatif au cas d’utilisation « Affecter panne
au technicien »
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.

37
Figure 2-37 : Diagramme de classe de conception relatif au cas d’utilisation « Consulter les
ordres de mission »
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.

38
Figure 2-38 : Diagramme de classe de conception relatif au cas d’utilisation « Consulter la
liste des pannes »
« Changer l’état de panne » :
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.

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 ».

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 » :
« Ajouter Technicien »

41
Figure 2-41 : Diagramme de séquences relatif au cas d’utilisation « Ajouter technicien »

42
2.4.2.3 Diagramme de séquences relatif au cas d’utilisation « Suivi des
pannes » :
« Suivi des pannes »
Figure 2-42 : Diagramme de séquences relatif au cas d’utilisation « Suivi des pannes »

43
2.4.2.4 Diagramme de séquences relatif au cas d’utilisation « Affecter
« Affecter panne au technicien ».
Figure 2.43 : Diagramme de séquences relatif au cas d’utilisation « Affecter panne au
technicien »

44
2.4.2.5 Diagramme de séquences relatif au cas d’utilisation « Consulter
les ordres de mission » :
« 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 » :
« Consulter la liste des pannes »

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
« Changer l’état de panne »

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é.

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
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

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
 Post-condition : Technicien supprimé
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
 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

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
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 :
« Modifier technicien » :
La figure 3.5 représente les classes qui sont utilisées dans le cas d’utilisation
« Modifier technicien ».

50
Figure 3.5 : Traçabilité entre MCU et MA relatif au cas d’utilisation « Modifier technicien »
« Supprimer technicien » :
« Supprimer technicien ».
Figure 3.6 : Traçabilité entre MCU et MA relatif au cas d’utilisation « Supprimer technicien »

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 »
« Consulter historique des pannes » :
« Consulter historique des pannes ».
Figure 3.8 : Traçabilité entre MCU et MA relatif au cas d’utilisation « Consulter historique
des pannes »

52
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
technicien »
La figure 3.10 représente les relations entre les classes utilisées dans le cas
d’utilisation « Supprimer technicien ».
technicien »
« 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 ».

53
Figure 3.11 : Diagramme de classes d’analyse relatif au cas d’utilisation « Vérifier la
disponibilité des matériaux »
« 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 »

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 »

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 » :
Consulter historique des pannes », ainsi que les interactions entre le responsable «
Administrateur » / « Technicien » et l’application au niveau de ce cas d’utilisation.

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.

57
Figure 3.17 : Diagramme de classes de conception relatif au cas d’utilisation « Modifier
technicien »
La figure 3.18 représente les classes du cas d’utilisation « Supprimer technicien » et
les relations entre elles.

58
Figure 3.18 : Diagramme de classes de conception relatif au cas d’utilisation « Supprimer
technicien »
« 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.

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.

60
Figure 3.20 : Diagramme de classes de conception relatif au cas d’utilisation « Consulter
historique des pannes »
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

61
Figure 3.21 : Diagramme de séquences relatif au cas d’utilisation « Modifier technicien »

62
3.3.2.2 Diagramme de séquences relatif au cas d’utilisation « Supprimer
technicien » :
« Supprimer technicien ».

63
Figure 3.22 : Diagramme de séquences relatif au cas d’utilisation « Supprimer technicien »

64
3.3.2.3 Diagramme de séquences relatif au cas d’utilisation « Vérifier la
disponibilité des matériaux » :
« Vérifier la disponibilité des matériaux ».

65
Figure 3.23 : Diagramme de séquences relatif au cas d’utilisation « Vérifier la disponibilité
des matériaux »

66
3.3.2.4 Diagramme de séquences relatif au cas d’utilisation « Consulter
l’historique des pannes » :
« Consulter l’historique des pannes ».
Figure 3.24 : Diagramme de séquences relatif au cas d’utilisation « Consulter l’historique des
pannes »

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é

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 »
le droit d’ajouter des matériaux.
 Cas d’utilisation : Ajouter des matériaux
 Post-condition : Matériaux ajoutés.
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

69
4.1.1.2 Raffinement de cas d’utilisation « Modifier matériaux » :
Figure 4.2 : Diagramme de cas d’utilisation « Modifier matériaux »
le droit de modifier des matériaux.
 Cas d’utilisation : Modifier matériaux
 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 »
le droit de supprimer des matériaux.
 Cas d’utilisation : Supprimer matériaux
 Post-condition : Matériaux supprimés.

70
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
 Précondition : Le technicien doit être identifié et autorisé
 Post-condition : Administrateur contacté.
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

71
4.2 Analyse :
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 »
« Modifier matériaux » :
« Modifier matériaux ».

72
Figure 4.6 : Traçabilité entre MCU et MA relatif au cas d’utilisation « Modifier matériaux »
« Supprimer matériaux » :
« Supprimer matériaux ».
Figure 4.7 : Traçabilité entre MCU et MA relatif au cas d’utilisation « Supprimer matériaux »

73
« Contacter administrateur » :
« Contacter administrateur ».
Figure 4.8 : Traçabilité entre MCU et MA relatif au cas d’utilisation « Contacter
administrateur »
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 »

74
La figure 4.10 représente les classes qui sont utilisées dans le cas d’utilisation «
modifier matériaux ».
matériaux »
Supprimer matériaux ».
matériaux »
Contacter administrateur ».

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 » :
Ajouter matériaux », ainsi que les interactions entre le responsable « Administrateur » et
Figure 4.13 : Diagramme de collaboration relatif au cas d’utilisation « Ajouter matériaux »

76
4.2.3.2 Diagramme de collaboration relatif au cas d’utilisation « Modifier
matériaux » :
Modifier matériaux », ainsi que les interactions entre le responsable « Administrateur » et
Figure 4.14 : Diagramme de collaboration relatif au cas d’utilisation « Modifier matériaux »
Supprimer matériaux », ainsi que les interactions entre le responsable « Administrateur » et

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 » :
Contacter administrateur », ainsi que les interactions entre le responsable « Technicien » et
Figure 4.16 : Diagramme de collaboration relatif au cas d’utilisation « Contacter
administrateur »

78
4.3 Conception :
4.3.1 Diagrammes des classes de conception :
« 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 »
La figure 4.18 représente les classes relatives au cas d’utilisation « modifier matériaux
» et les relations entre elles. Utilisateur « Administrateur ».

79
Figure 4.18 : Diagramme de classes de conception relatif au cas d’utilisation « Modifier
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 ».

80
Figure 4.19 : Diagramme de classes de conception relatif au cas d’utilisation « Supprimer
matériaux »
La figure 4.20 représente les classes relatives au cas d’utilisation « Contacter
administrateur » et les relations entre elles. Utilisateur « Technicien ».

81
Figure 4.20 : Diagramme de classes de conception relatif au cas d’utilisation « Contacter
administrateur »

82
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 »

83
4.3.2.2 Diagramme de séquences relatif au cas d’utilisation « Modifier
matériaux » :
Modifier matériaux ». Utilisateur « Administrateur ».
Figure 4.22 : Diagramme de séquences relatif au cas d’utilisation « Modifier matériaux »

84
4.3.2.3 Diagramme de séquences relatif au cas d’utilisation « Supprimer
matériaux » :
Supprimer matériaux ». Utilisateur « Administrateur ».

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 » :
Contacter administrateur ». Utilisateur « Technicien ».
Figure 4.24 : Diagramme de séquences relatif au cas d’utilisation « Contacter administrateur »

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).

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

88
« Technicien » de notre application. Nous passons à la prochaine phase qui consiste à
l’intégration de notre application dans l’environnement de l’utilisateur.

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

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.

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.

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.

93
Figure 5.4 : Interface « Ajouter technicien »
5.2.5 Interface « Administration » :
La figure 5.5 représente l’interface « Administration ».

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.

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.

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.

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

application mobile de gestion de panne de BTS

Recommandé

Recommandé

Contenu connexe

Tendances

Tendances (20)

En vedette

En vedette (15)

Similaire à application mobile de gestion de panne de BTS

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

application mobile de gestion de panne de BTS