application mobile de gestion de panne de BTS

Projet de Fin d’Etudes ISIGK 2015/2016

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.

I


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.

II


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

III


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


IV


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

V


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

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

VI


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

VII


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

VIII


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

IX


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

X


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

Figure 5.3 : Interface « gérer technicien »....................................................................93

Figure 5.4 : Interface « Ajouter technicien »................................................................94

Figure 5.5 : Interface « Administration »......................................................................95

XI


Figure 5.6 : Interface « Mission ».................................................................................96

Figure 5.7 : Interface « Historique des pannes »...........................................................97

XII


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.

1


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.

2


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

3


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

4


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

5


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

6


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.

7


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.

8


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

9


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

10


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.

11


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.

12


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 1Administrateur Modifier technicien 2Administrateur Supprimer technicien 2Administrateur Suivi des pannes 1Administrateur Affecter panne au technicien 1Administrateur Ajouter matériaux 3Administrateur Modifier matériaux 3Administrateur Supprimer matériaux 3Technicien Consulter la liste des pannes 1Technicien Consulter les ordres de mission 1Technicien Vérifier la disponibilité des

matériaux2

Technicien Changer l’état de panne 1Technicien Contacter administrateur 3Administrateur et Technicien

S’identifier 1

13


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

14


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

15


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 »

16


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

17


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.

18


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 »

19


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 »

20


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 »

21



« Consulter les ordres de mission » :

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

22



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

23


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 »

24



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

25





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

26


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 »

27


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.

28


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.

29


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 »

30


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.

31


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.

32


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


33


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


34


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

35


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.

36


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.

37


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.

38


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

39


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 »

40


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

41


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 »

42


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 »

43


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 »

44


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 »

45


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

46


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

47


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

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

48


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

49


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 »

50


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 »

51



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

52


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 »

53


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 »



54


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.

55


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.

56


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.

57


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.

58


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.

59


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


60


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

61


3.3.2.2 Diagramme de séquences relatif au cas d’utilisation « Supprimer

technicien » :


« Supprimer technicien ».

62


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

63


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

64


Figure 3.23 : Diagramme de séquences relatif au cas d’utilisation « Vérifier la disponibilité

des matériaux »

65


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 »

66


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é

67


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

68


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.

69



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


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

70


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

71


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 »

72



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

73




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

74


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 »

75


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


76


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 »

77


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

78


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

79


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

80


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

administrateur »

81



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 »

82


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 »

83


4.3.2.3 Diagramme de séquences relatif au cas d’utilisation « Supprimer

matériaux » :


Supprimer matériaux ». Utilisateur « Administrateur ».

84


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 »

85


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

86


Figure 4.25 : Diagramme de classes d’entité globale

87


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

« Technicien » de notre application. Nous passons à la prochaine phase qui consiste à

l’intégration de notre application dans l’environnement de l’utilisateur.

88


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

89


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.

90


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.

91


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.

92


Figure 5.4 : Interface « Ajouter technicien »

5.2.5 Interface « Administration » :

La figure 5.5 représente l’interface « Administration ».

93


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.

94


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.

95


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.

96


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.

97


Bibliographie

[1] http://www.tunisietelecom.tn/

[2] http://searchsoftwarequality.techtarget.com/definition/3-tier-application

[3] http://www.pacestar.com/uml/

[4] https://www.android.com/

[5] http://www.tutos-android.com/introduction-a-android-studio

[6] https://www.genymotion.com/

[7] http://www.mobogenie.com/fr/

98

http://www.mobogenie.com/fr/

https://www.genymotion.com/

http://www.tutos-android.com/introduction-a-android-studio

https://www.android.com/

http://www.pacestar.com/uml/

http://searchsoftwarequality.techtarget.com/definition/3-tier-application

http://www.tunisietelecom.tn/

application mobile de gestion de panne de BTS

Self Improvement

Transcript of application mobile de gestion de panne de BTS