Ministère de l’Enseignement Supérieur

et de la Recherche Scientifique
  
Université de Carthage
  
Institut National des Sciences
Appliquées et de Technologie

Projet de Fin d’Etudes

Pour l’obtention du

Diplôme National de Licences Appliquées

Filière : Réseaux Informatiques

Sujet :

Conception et développement d’une plateforme

« HEALTH CHECK » pour les services de
TUNISIANA

Réalisé par : Asma TOUNSI

Entreprise d’accueil :

TUNISIANA

Soutenu le 13/06/2012

Président de jury : Mr Noureddine HAMDI

Examinateur : Mr Sofien OUNI
Responsable entreprise : Mr Sami BENZID
Responsable INSAT: Mr Imad ICHABANI

Année Universitaire : 2011/2012

Ministère de l’Enseignement Supérieur
et de la Recherche Scientifique
  
Université de Carthage
  
Institut National des Sciences
Appliquées et de Technologie

Projet de Fin d’Etudes

Pour l’obtention du

Diplôme National de Licences Appliquées

Filière : Réseaux Informatiques

Sujet :

Conception et développement d’une

plateforme « HEALTH CHECK » pour les services
de TUNISIANA

Réalisé par : Asma TOUNSI

Entreprise d’accueil :

TUNISIANA

Soutenu le 13/06/2012

Responsable à l’entreprise: Responsable à l’INSAT:

Monsieur Sami BENZID Monsieur Imed ICHAABANI

Année Universitaire : 2011/2012

Dédicaces  2011/2012 
 

Dédicaces
De plus profond de mon cœur je dédie ce travail

A ma chère mère que nulle dédicace ne puisse exprimer ce que je lui dois, pour sa
bienveillance de plus jeune enfance, son affection et son soutien. Trésors de bonté, de
générosité et de tendresse, en témoignage de mon profond amour et ma grande
reconnaissance. ”Que Dieu vous garde”,

A mon cher père pour son amour et tous ses sacrifices. Papa à qui je dois ma réussite,
aucun mot ne saurait témoigner de l’étendue des sentiments que j’éprouve à son égard,

A ma chère sœur, Amani, pour sa patience et son encouragement,

A ma chère sœur Nada et mon cher frère Mohamed Aziz qui ont été toujours à mes

côtés,

A Mohamed Anis qui m’aide et m’inspire au quotidien par de petits riens qui font un

grand tout,

A ma grand-mère pour ses prières pour moi,

A mes amis, Rania, Héjar, Wafa, Maryem, Asma, Marwa, Ibtissem, Sabrine, Rami, Wael,

Dorra, Oussema, Amira, Mohamed Taher, Fida, Hédi, Salma et Emira qui m’ont toujours

soutenue et qui ont réussi à apporter de la gaieté dans une ambiance parfois très moros,

A tous mes ami(e)s, que je ne peux tous citer,

Que Dieu les bénisse tous et leurs préserve la santé et le bonheur.

Asma TOUNSI

Asma TOUNSI  Page i 
 
Remerciements  2011/2012 
 

                                                       Remerciements
 

C’est avec plaisir que je réserve ces quelques lignes en signe de gratitude et de
profonde reconnaissance à tous ceux qui, de prés ou de loin, ont contribué à l’aboutissement
de ce travail.

Je tiens à exprimer ma profonde gratitude à Monsieur Sami BENZID, ingénieur

Support ”IP/MPLS ”, mon tuteur de stage pour m’avoir bien accueilli au sein de l’entreprise
« TUNISIANA ». Je le remercie également pour les précieux conseils qu’il m’a prodigués tout
au long de la période du stage, conseils qui m’ont permis d’approfondir mes connaissances
techniques et de maîtriser les bonnes pratiques du développement.

J’adresse mes remerciements aux ingénieurs de ce service, Monsieur Ahmed KRICHEN

et Monsieur Abdel Majid AJAJ, pour leurs remarques pertinentes et pour les conseils et les
explications qu’ils m’ont accordés.

Je remercie également Monsieur Aymen FADHEL ingénieur du service IP/MPLS et

Monsieur Anis GAIED ingénieur du service Support FH & Systèmes Optiques qui m’ont aidé
dans les manipulations des outils ainsi que tout le personnel de la société. Je remercie aussi
l’administration de la société qui m’a donné l’occasion d’effectuer un stage qui m’a permis
d’améliorer mes connaissances.

Un spécial remerciement à mon encadrant à l’INSAT, Monsieur Imed ICHAABANI,

consultant expert, pour ses efforts d’encadrement, sa patience, sa disponibilité, ses critiques
et ses conseils judicieux durant la réalisation de ce projet et pour ses encouragements.

Je voudrais exprimer ma gratitude infinie aux personnes qui me sont les plus proches ;
ma famille qui m’était d’un grand apport moral lors des moments de doute et de
découragement traversés tout au long de mon parcours dans la vie, ainsi que mes ami(e)s.

Asma TOUNSI  Page ii 
 
Table des matières  2011/2012 
 

Table des matières

Introduction générale………….………………………………………………………….……1
Chapitre1 Mise en contexte………………………………...………………………………….2
1.1. Introduction ..................................................................................................................... 3
1.2. Présentation de l’organisme d’accueil............................................................................. 3
1.2.1. Présentation générale de TUNISIANA .................................................................... 3
1.2.2. Organisation de TUNISIANA ................................................................................. 4
1.3. Objectifs du projet ........................................................................................................... 5
1.4. Conclusion ....................................................................................................................... 6
Chapitre2 Généralités sur l'évolution des réseaux mobiles…………………………...……….7
2.1. Introduction ..................................................................................................................... 8
2.2. Le réseau GSM ................................................................................................................ 8
2.2.1. Le sous système radio (BSS) ................................................................................... 9
2.2.2. Le sous-système réseau (NSS) ................................................................................. 9
2.2.3. Le sous-système opérationnel OSS ...................................................................... ..11
2.3. Le réseau GPRS ........................................................................................................... .11
2.4. EDGE (Enhanced Data rate for GSM Evolution) ........................................................ .12
2.5. UMTS ........................................................................................................................... .13
2.6. Conclusion ..................................................................................................................... 13
Chapitre3 Etude de l'existant et spécification des besoins…………………..…………….…14
3.1. Introduction ................................................................................................................... 15
3.2. Etude de l’existant ......................................................................................................... 15
3.2.1. Architecture du Backbone IP/MPLS de TUNISIANA ......................................... 15
3.2.2. Etude d’un exemple de « check service » .............................................................. 17
3.3. Capture des besoins fonctionnels ................................................................................. 20
3.3.1. Identification des acteurs ....................................................................................... 20
3.3.2. Identification des cas d’utilisation ......................................................................... 20
3.3.3. Diagrammes des cas d’utilisation .......................................................................... 22
3.3.4. Identification des classes candidates ...................................................................... 27
Asma TOUNSI  Page iii 
 
Table des matières  2011/2012 
 

3.4. Capture des besoins non fonctionnels ........................................................................... 28

3.5. Conclusion ..................................................................................................................... 29
Chapitre4 Conception de l'application……………………………………………………….30
4.1. Introduction ................................................................................................................... 31
4.2 Conception générale ...................................................................................................... 31
4.2.1. Choix de la méthodologie de conception ............................................................... 31
4.2.2. Choix de l’outil de conception ............................................................................... 31
4.2.3. Conception des interfaces ...................................................................................... 32
4.2.4. Architecture de l’application.................................................................................. 32
4.2.5. Modèle de conception ............................................................................................ 33
4.3. Conception détaillée ...................................................................................................... 34
4.3.1. Développement du modèle statique ....................................................................... 34
4.3.2. Développement du modèle dynamique .................................................................. 35
4.3. Conception de la base de données ................................................................................. 40
4.4. Conclusion ..................................................................................................................... 43
Chapitre5 réalisation de la plateforme "HEALTH CKECK"………………..………………44
5.1. Introduction ................................................................................................................... 45
5.2. Aspect technique de l’application ................................................................................. 45
5.2.1. Choix de la plateforme Java EE ............................................................................. 45
5.2.2. Choix de l’architecture J2EE ................................................................................. 46
5.2.3. Frameworks de développement ............................................................................. 47
[Link]. JSF .................................................................................................................. 47
[Link]. Hibernate ........................................................................................................ 47
5.2.4. Système de gestion de base de données ................................................................. 48
5.3. Environnement de travail .............................................................................................. 48
5.3.1. Environnement matériel ......................................................................................... 48
5.3.2. Environnement logiciel .......................................................................................... 48
[Link]. Serveur d’application : Tomcat ...................................................................... 48
[Link]. Environnement de développement intégré : Netbeans 7.0.1 .......................... 48
[Link]. Système de gestion de base de données : MySQL Workbench 5.2 ................ 48
5.4. Travail réalisé ................................................................................................................ 49
5.4.1. Interface d’authentification des utilisateurs ........................................................... 49
5.4.2. Interface d’accueil .................................................................................................. 50

Asma TOUNSI  Page iv 
 
Table des matières  2011/2012 
 

5.4.3. Géo localisation des switchs d’accès CE ............................................................... 51

5.4.4. La liste des switchs ................................................................................................ 54
5.4.5. Ajout d’un switch ................................................................................................... 55
5.4.6. Modifier un service ................................................................................................ 56
5.4.7. Consultation Backup .............................................................................................. 57
5.4.8. Liste des services ................................................................................................... 59
5.5. Exemple de test d’un service ......................................................................................... 60
5.6. Conclusion ..................................................................................................................... 62
Conclusion générale…………………………………………………………………………..63
Netographie……………………………………………………………………………...……64

Bibliographie………………………………………………………………………………….65

Chronogramme………………………………………………………………………………..66

 
 

   

Asma TOUNSI  Page v 
 
Table des figures  2011/2012 
 

Table des figures

Figure 1. 1 Organigramme de TUNISIANA .............................................................................. 4
Figure 2.1 Architecture du réseau GSM1 ................................................................................... 8
Figure 2.2 Architecture du réseau GPRS2 ................................................................................ 11
Fiqure2.3 Architecture du réseau 3G ....................................................................................... 13
Figure3. 1 Architecture du Backbone IP/MPLS de TUNISIANA ........................................... 15
Figure3. 2 Architecture du service CRBT ................................................................................ 18
Figure3. 3 Les interfaces du service CRBT ............................................................................. 19
Figure 3.4 Diagramme de cas d’utilisation générale ................................................................ 22
Figure 3.5 Diagramme de cas d’utilisation «gérer les services » ............................................. 25
Figure 3.6 Diagramme de cas d’utilisation «gérer les Utilisateurs» ...................................... 26
Figure 4. 1 Architecture des interfaces de l'application ........................................................... 32
Figure 4. 2 Modèle MVC ......................................................................................................... 33
Figure 4.3 Diagramme de classe .............................................................................................. 34
Figure 4. 4 Diagramme de séquences « Authentification » ..................................................... 36
Figure 4. 5 Diagramme de séquences « Ajout service » .......................................................... 37
Figure 4. 6 Diagramme de séquences « Modifier switch » ...................................................... 38
Figure 4. 7 Diagramme de séquences « Suppression Utilisateur » .......................................... 39
Figure 4.8 Diagramme de séquences « Test d’un service » ................................................... 39
Figure 4. 9 Diagramme de séquences « Backup config» ......................................................... 40
Figure 4.10 Modélisation de la base des données .................................................................... 42
Figure 5. 2 Architecture 3 tiers J2EE et Framework associés .................................................. 47
Figure 5. 3 Interface « Authentification » de l'application ....................................................... 49
Figure 5. 4 Interface « Accueil » de l'application .................................................................... 50
Figure 5. 5 Accéder à la carte géographique ............................................................................ 51
Figure 5. 6 Géo localisation des switchs .................................................................................. 52
Figure 5. 7 Accéder aux caractéristiques du switch à partir de la carte ................................... 53
Figure 5.8 Liste des switchs avec les différentes opérations (Modifier, Afficher, Supprimer,
Tester)....................................................................................................................................... 54
Figure 5.9 Accéder à l’interface «Ajouter un switch » ........................................................... 55
Figure 5.10 Interface « Ajout d'un switch » ............................................................................ 56
Figure 5.11 Interface « Modification d'un service » ................................................................ 57
Figure 5.12 Interface consultation du « Backup » .................................................................. 58
Figure 5. 13 Interface « Liste des services » ............................................................................ 59
Figure 5. 14 Architecture du service CRBT ............................................................................. 60
Figure 5. 15 Interface du résultat du test du service CRBT ..................................................... 61
 

Asma TOUNSI  Page vi 
 
Liste des tableaux  2011/2012 
 

Liste des tableaux

Table 3.1 Liste de commande pour chaque VLAN…………………………………………………………………….…..20 

Table 3.2 Identification des cas d’utilisation du système…………………………………………………………...…21 

Table 3.3 Description de cas d’utilisation « s’authentifier »............................................................. 23

 

Table 3.4 Description de cas d’utilisation « gérer les services »……………………………………………….…..24 

Table 3.5 Description de cas d’utilisation « gérer les Utilisateurs »……………………………………………...25

 

Table 3.6 Description de cas d’utilisation  «consulter Backup »…………………………………………………….27

Table 3.7 Identification des classes candidates………………………………………………………………………….….28 

Table 4.1 Description de la base de données…………………………………………………………………………….....41 

   

Asma TOUNSI  Page vii 
 
Liste des acronymes 2011/2012 
 

Liste des acronymes

A
AuC              Authentication Center

B
BSC Base Station controller
BSS Base Sub-System
BTS Base Tranciever Station
C
CE Custumer Edge
CSS Cascading Style Sheets
E
EDGE Enhanced Data for GSM Evolution
G
GPRS General Packet Radio Service
GSM Global System for Mobile communication
H
HSRP Hot Standby Router Protocol
I
IDE Integrated Developpement Environment
IP Internet Protocol
J
JDBC Java DataBase Connectivity
JEE Java Entreprise Edition
JSF Java Server Faces
JSP Java Server Pages
M
MGW Media Gateway
MSS Mobile Switching Center Server (MSC Server)
MVC Model Viewer Controller

Asma TOUNSI  Page viii 
 
Liste des acronymes 2011/2012 
 

O
O&M Operation & Maintenance
P
P Provider
PE Provider Edge
SGBD Système de gestion de base de données
STP Signaling Transfer Point
T
TELNET Terminal Network
U
UML Unified Modeling Language
V
VAS Value Added Service
VRF Virtual Routing Forwarding 

Asma TOUNSI  Page ix 
 
Introduction générale 2011/2012

Introduction générale
Le contexte concurrentiel auquel les différents opérateurs de télécommunication font
aujourd’hui face, impose à ces derniers de fournir des services de qualité. Ceci peut être
effectivement réalisé à travers la mise en place de services de maintenance performants
minimisant le plus possible les périodes de pannes et de non disponibilité de ces services. En
effet la disponibilité et la pérennité des services pour les opérateurs de télécommunication
sont devenues, de nos jours, un souci majeur et un grand défi à soulever.

Pour atteindre ces nouveaux objectifs, les opérateurs doivent mettre en œuvre de nouvelles
stratégies de tests des services et des équipements réseaux sous-jacents.

Le fait d’entreprendre des tests manuels peut se répercuter négativement sur la qualité des
services fournis par l’opérateur. En effet la maintenance et/ou la réparation d’un ou plusieurs
Switchs amène l’opérateur à effectuer des tests de connectivité. Ces derniers sont menés avec
des pings ou des commandes trace-route entre les switchs.

Afin d’améliorer les services de tests fournis, TUNISIANA à travers son département
IP/MPLS, se propose dans le cadre de ce projet de fin d’études d’automatiser ces différentes
tâches à travers l’informatisation de tout le système. Nous serons ainsi amenés dans ce projet
à développer une application intitulée « HEALTH CHECK » qui a pour objectif le test des
switchs (donnant accès via le réseau IP/MPLS aux services de TUNISIANA) et
l’administration et la gestion des utilisateurs de l’application, des switchs ainsi que des
services.

Afin de bien présenter ce mémoire nous allons le découper en cinq chapitres :

Dans le premier chapitre, nous parlerons du cadre de travail et du sujet, nous présenterons
l’environnement du stage ainsi que le sujet à traiter. Le second chapitre sera consacré pour
étudier généralement l’évolution des réseaux mobiles. Dans le troisième chapitre nous
présentons l’étude de l’existant et nous évoquerons les spécifications des besoins fonctionnels
et non fonctionnels. Le quatrième chapitre sera réservé pour la conception détaillée de
l’application. Enfin, le dernier chapitre concerne la réalisation de l’application.

Asma TOUNSI Page 1

Chapitre 1 : Mise en contexte 2011/2012

Chapitre1 : Mise en contexte

Asma TOUNSI Page 2

Chapitre 1 : Mise en contexte 2011/2012

1.1. Introduction
Dans le présent chapitre, nous allons essayer de décrire le cadre notre stage. Pour ce
faire, nous procéderons à une présentation de l’organisme d’accueil, à savoir TUNISIANA.
Par la suite, nous dégagerons la problématique pour aboutir aux objectifs spécifiques de notre
projet.

1.2. Présentation de l’organisme d’accueil

Le cadre de notre projet a été la société TUNISIANA, où nous avons passé quelques
mois dans la direction Technologie et plus particulièrement l’équipe IP/MPLS du service
Transmission. Notre tâche consistait à développer une plateforme de « HEALTH CHECK »
pour gérer les services de TUNISIANA.

1.2.1. Présentation générale de TUNISIANA

TUNISIANA SA (Société Anonyme) : est le premier opérateur privé de

Télécommunications en Tunisie, créé le 11 mai 2002 et fondé le 17 mai 2002.
C’est une entreprise publique à caractère industriel et commercial. Son objectif principal est
de moderniser son infrastructure et d’améliorer les services offerts aux abonnés. Ces objectifs
entrent dans le cadre du renforcement de la position de l’entreprise et de sa compétitivité.
Le 16 décembre 2004, TUNISIANA a passé le cap du million d'abonnés. La couverture s'est
étendue à 99% de la population dans le courant de l'année 2005.
Vers la fin de 2006, TUNISIANA comptait à son actif près de 3 millions d’abonnés et avait
raflé près de 46% de la part du marché [1].
Créer des services innovants, satisfaire l’ensemble de leurs abonnés et instaurer une relation
de confiance avec leurs partenaires, tels sont les objectifs que s’est assignés la société.

Et pour les atteindre, cinq valeurs orientent toutes leurs actions et accompagnent la totalité de
leurs engagements :

 Satisfaire le client.
 Professionnalisme.

Asma TOUNSI Page 3

Chapitre 1 : Mise en contexte 2011/2012

 Transparence envers ses clients.

 Innovation en utilisant des nouvelles technologies.
 Une vision stratégique.

1.2.2. Organisation de TUNISIANA

Pour assurer une bonne présentation de services et un bon fonctionnement de son

réseau de transmission, TUNISIANA est basée sur l’interaction de plusieurs directions et
départements complémentaires comme le monte la figure 1.1

Figure 1. 1 Organigramme de TUNISIANA

Toutes ces directions ont des fonctions différentes et complémentaires entre elle afin d’assurer
le bon déroulement du travail au sein de l’entreprise.

La direction technique :

Ce projet s’est déroulé à la direction technique qui est composée de plusieurs départements.
La structure Hiérarchique de la Direction Technologie est la suivante :
 Direction Ingénierie Réseau
 Direction BSS & VAS
 Département Performance Réseaux et Gestion de projet
 Direction Système d’Informations Enterprise

Asma TOUNSI Page 4

Chapitre 1 : Mise en contexte 2011/2012

 Département Des Operations:

 Département SI Opération
 Service Supervision et Administration
 Département Maintenance
 Département Support Billing& VAS
 Département Support Réseau:
 Service Logique
 Service BSS
 Service Support CORE NETWORK
 Service transmission

Nous avons réalisé notre projet au sein du service transmission et exactement auprès de
l’équipe Support IP/MPLS.

1.3. Objectifs du projet

TUNISIANA a proposé ce projet de fin d’étude pour atteindre un certain nombre

d’objectifs :

 Automatiser les tests entrepris par l’équipe IP/MPLS de TUNISIANA concernant la

disponibilité des services.
 Développer une application en réseau permettant :
 La gestion des :
- Switchs d’accès aux services
- Paramètres des services de TUNISIANA
- Utilisateurs de l’application
 Tester des switchs et des services.
 Assurer un service de Backup des configurations et des outputs de commandes
utiles.
 Gérer la localisation des switchs en fournissant les paramètres des switchs.
 Afficher graphiquement la topologie du réseau IP/MPLS de TUNISIANA pour
l’exploiter ultérieurement comme carte interactive.
 Ecourter le temps, relativement long, du processus de test manuel d’un service.
 Convivialiser les tests.
 Ecourter le temps de détection de la nature de la panne et de la localisation de
l’équipement et des vlan causant la panne.

Asma TOUNSI Page 5

Chapitre 1 : Mise en contexte 2011/2012

 Améliorer la maintenance des services.

 Tests de maintenance périodique.

1.4. Conclusion

Après avoir présenté le cadre général et les objectifs de notre projet, nous entamons
dans le chapitre suivant une partie indispensable pour le bon déroulement du stage et
l’assimilation de concepts récents pour nous à savoir le chapitre de l’étude théorique.

Nous y ferons un tour panoramique du jargon utilisé par l’équipe IP/MPLS ainsi que les
termes relatifs aux réseaux de télécommunication mobile et aux équipements réseaux.

Pour ce faire, nous avons opté pour la démarche chronologique dans laquelle nous étudierons
l’évolution des réseaux mobiles depuis leur création.

Asma TOUNSI Page 6

Chapitre2 : Généralités sur l’’évolution des réseaux mobiles 2011/2012

Chapitre2 :
Généralités sur l’’évolution des
réseaux mobiles

Asma TOUNSI Page 7

Chapitre2 : Généralités sur l’’évolution des réseaux mobiles 2011/2012

2.1. Introduction
Le monde des télécommunications mobiles a connu une révolution depuis l’apparition
des réseaux cellulaires. Dans ce contexte, la réalisation de ce projet a nécessité une étude
approfondie sur certaines notions qui touchent non seulement au cadre général du projet, mais
aussi à sa réalisation. Pour bien assimiler ces différentes notions, cette section sera consacrée
à une brève présentation des réseaux GSM, GPRS, EDGE et UMTS.

2.2. Le réseau GSM

Le GSM, (Global System for Mobile communications), est un système cellulaire et
numérique de télécommunication mobile. Il est composé, comme décrit dans la Figure 2.1, de
huit éléments distincts jouant chacun un rôle bien défini lors de la transmission des
informations (voix ou données).

Figure 2.1 Architecture du réseau GSM1

1
ESSABRI Achraf, ISTIA, DESS QUASSI, Novembre 2004, « Téléphonie et mobilité »

Asma TOUNSI Page 8

Chapitre2 : Généralités sur l’’évolution des réseaux mobiles 2011/2012

Un réseau GSM, comme cela est décrit dans la figure ci-dessus, peut être divisé en trois
éléments :

1. Le sous-système radio contenant la station mobile, la station de base et son contrôleur.

2. Le sous-système réseau ou d’acheminement.

3. Le réseau de gestion de télécommunications.

Nous allons dans ce qui suit expliciter les trois sous-systèmes afin d’avoir une idée générale
sur la manière dont l’information est véhiculée dans les réseaux mobiles de deuxième
génération.

2.2.1. Le sous système radio (BSS)

Le sous système radio, appelé « Base Station Sub-system» (BSS) dirige la
transmission radio. Il est constitué des sous équipements suivants :

 Station mobile MS (Mobile Station)

La station mobile MS est un équipement terminal muni d'une carte SIM, qui permet
d'accéder aux services de télécommunication d’un GSM à travers un système cellulaire.

 La station de base BTS (Base Tranciever Station)

La station de base est l’élément central, qui peu être définie comme un
ensemble émetteur/récepteur gérant une ou plusieurs cellules. La station de base fait le lien
entre le mobile et le sous-système réseau et peut gérer au plus huit connections simultanées
par cellule [3].
 Le contrôleur de station de base BSC (Base Station controller)
Cet équipement gère une ou plusieurs stations et remplit différentes missions pour les
fonctions de communication. Pour le trafic abonné venant des stations de base, c’est un
concentrateur, pour le trafic issu du commutateur, c’est un commutateur vers la station du
bon destinataire [3].

2.2.2. Le sous-système réseau (NSS)

Le sous système réseau, appelé « Network Sub System » (NSS), joue un rôle essentiel
dans un réseau mobile. Alors que le sous-système radio gère l’accès radio, les composants du
NSS prennent en charge toutes les fonctions de contrôle et d’analyse d’informations
contenues dans des bases de données nécessaires à l’établissement de connexions [3].
Asma TOUNSI Page 9
Chapitre2 : Généralités sur l’’évolution des réseaux mobiles 2011/2012

Le NSS est constitué des éléments suivants :

 Le commutateur de service mobile MSC (Mobile switching Center)

Le rôle majeur du centre de commutation mobile est d’assurer la commutation entre les
abonnés du réseau mobile et ceux du réseau commuté public (RTC) ou de son équivalent
numérique, le réseau RNIS. De plus, il participe à la fourniture des différents services aux
abonnés tels que la téléphonie, les services supplémentaires et les services de messagerie. Il
permet également de mettre à jour les différentes bases de données (HLR et VLR) [4].
Le MSC gère l'établissement des communications entre un mobile et un autre MSC, la
transmission des messages courts SMS (Short Message Service) et l'exécution des ‘handover’
entre deux BSC différentes. Il dialogue avec le VLR pour gérer la mobilité des usagers.

 Le registre d’abonnées locaux HLR ( Home Location Register)

Il s’agit d’une base de données contenant les informations sur les abonnés appartenant à
la région desservie par le MSC. Cette base de données contient également la position courante
de ces abonnés.

 Le registre d’abonnées visiteurs VLR(Visitor Location Register)

Cette base de données contient temporairement des informations sur les

abonnés qui visitent une région desservie par un MSC autre que celui auquel ils sont abonnés.
Ces informations proviennent du HLR auquel l’abonné est rattaché et indiquent les services
auxquels l’abonné a droit.
 Le centre d’authentification AuC (Authentication Center)
Le AuC est une base de données protégée qui contient une copie de la clé secrète
inscrite sur la SIM de chaque abonné. Cette clé est utilisée pour vérifier l’authenticité de
l’abonné et pour l’encryptage des données envoyées [2].

 L’enregistreur des identités des équipements (EIR)

Chaque terminal mobile est identifié par un code unique (International Mobile station
Equipment Identity) IMEI. Le registre EIR contient la liste de tous les terminaux valides. Une
consultation de ce registre permet de refuser l’accès au réseau à un terminal qui a été déclaré
perdu ou volé [2].

Asma TOUNSI Page 10

Chapitre2 : Généralités sur l’’évolution des réseaux mobiles 2011/2012

2.2.3. Le sous-système opérationnel OSS

Ce sous-système, appelé « Operating Sub-System » (OSS), est branché aux différents
éléments du sous-système réseau de même qu’au contrôleur de station de base BSC. Par une
vue d’ensemble du réseau, le OSS contrôle et gère le trafic au niveau du BSS.

2.3. Le réseau GPRS

Le succès des réseaux GSM a montré également ses limitations pour faire face à la
demande, sans cesse croissante, d'échange de données. La norme GPRS (General Packet
Radio Service) spécifie un nouveau service support de transmission de données (bearer) en
mode paquets basée notamment sur la technologie GSM. Le GPRS permet de transporter des
données utilisateur et des données de signalisation en optimisant l'utilisation des ressources du
sous système radio et du sous système réseau fixe [5].
Le GPRS constitue un élément de réponse par un réseau en "overlay" du réseau GSM
existant. Il impacte directement les sous-systèmes radio, réseau et la supervision du sous-
système réseau. Le sous-système réseau voit l'introduction de passerelles IP (Internet
Protocol) : GGSN (Gateway GPRS Support Node), et de routeur de paquets : SGSN (Serving
GPRS Support Node) vers les réseaux paquets publics comme c’est illustré dans la figure 2.2.

Figure 2.2 Architecture du réseau GPRS2

2
ESSABRI Achraf, ISTIA, DESS QUASSI, Novembre 2004, « Téléphonie et mobilité »

Asma TOUNSI Page 11

Chapitre2 : Généralités sur l’’évolution des réseaux mobiles 2011/2012

 SGSN (Serving GPRS Support Node) : C’est un nœud de service GPRS qui joue le
rôle d’un commutateur GPRS et qui est équivalent au MSC. Il gère donc les terminaux
présents dans une zone donnée, vérifie l'enregistrement des abonnés, les authentifie et
autorise les communications.
 GGSN (Gateway GPRS Support Node) : C’est un nœud de passerelle qui est relié à
un ou plusieurs réseaux de données (IP (Internet Protocol), X25) et qui joue le rôle
d’interface entre ces réseaux de données et le SGSN auquel est rattaché l’abonné en
accès.

2.4. EDGE (Enhanced Data rate for GSM Evolution)

Le réseau EDGE s'inscrit dans l'évolution du GSM vers la future troisième génération
que représente l'UMTS. Il s’agit d’un nouveau standard en matière de téléphonie mobile
cellulaire, basé sur une technologie de modulation des données permettant ainsi d'augmenter
le débit de chaque canal GSM.
L’EDGE se base sur une nouvelle modulation mais utilise les mêmes infrastructures que le
GSM. Il permet, pour une même bande de fréquence, d'augmenter le débit. L’EDGE peut
donc être défini comme l'apogée du GSM.

Pour résumer la situation, on s'aperçoit qu'il y a plusieurs perspectives envisageables :

1) Le cas où on emploie d'abord l'UMTS, suivie par la coexistence d’UMTS et EDGE.

2) On adopte le passage direct de GPRS à UMTS, sans employer l’EDGE.

3) L’EDGE s'inscrit dans une évolution vers le futur standard UMTS et est donc un
passage nécessaire entre le système actuel et la troisième génération.

Cependant l’EDGE a des limitations: il n’est pas aussi performant que l'UMTS car les débits
ne sont que 2 à 3 fois supérieurs à ceux du GPRS, et ne fonctionnent qu'à très faible mobilité.
Même si d'autres utiliseront le EDGE en complément, pour couvrir des zones peu
intéressantes pour l'UMTS, le EDGE devrait être disponible début 2002.

Asma TOUNSI Page 12

Chapitre2 : Généralités sur l’’évolution des réseaux mobiles 2011/2012

2.5. UMTS
L’UMTS est un système cellulaire de troisième génération qui fait partie de la famille
IMT 2000. L’architecture de ce système est composée essentiellement d’un réseau terrestre
d’accès radio, l’UTRAN (Universal terrestrial Radion Access Network) et d’un réseau cœur
dérivé de celui spécifié pour la phase 2+ du GSM.

L’UTRAN utilise deux modes d’accès fondés sur la technologie CDMA large bande :
- L’UTRA/FDD (Universal terrestrial Radion Access/Frequency Duplex Division).
- L’UTRA/TDD (Universal terrestrial Radion Access/Time Duplex Division).

Fiqure2.3 Architecture du réseau 3G

2.6. Conclusion
Après avoir vu en détails les caractéristiques des réseaux mobiles lors de ses différents
générations (2, 2.5, 2,75 et 3), nous nous intéresserons dans les parties suivantes sur une
technologie innovatrice pour les réseaux 3G à savoir le concept IP/MPLS.

Le chapitre suivant sera consacré à l’analyse de l’environnement existant en prenant comme

exemple un service du réseau de TUNISIANA à savoir le CRBT (Call Ring BackTone) avec
toutes les actions sensées se faire manuellement pour effectuer à sa vérification. Aussi, nous
procéderons à la capture des besoins fonctionnels et non fonctionnels de l’application.

Asma TOUNSI Page 13

Chapitre3 : Etude de l’existant & spécification des besoins 2011/2012

Chapitre3 :
Etude de l’existant
& spécification des besoins

Asma TOUNSI Page 14

Chapitre3 : Etude de l’existant & spécification des besoins 2011/2012

3.1. Introduction

Préalablement à toute élaboration d’un projet, il est nécessaire d’analyser

l’environnement
existant en termes de configuration technique, de système de traitement et de plateforme de
mesure afin de mieux comprendre les besoins de l’entreprise et de pouvoir par la suite choisir
les démarches les plus appropriées à la réalisation de ce travail.
Dans ce chapitre, nous allons expliquer tout d’abord l’architecture IP/MPLS de TUNISIANA.
Ensuite, nous allons mener une étude détaillée à propos méthodes existantes adoptées au sein
de TUNISIANA pour effectuer l’administration, la maintenance et le contrôle des services de
télécommunication. Nous expliciterons enfin les besoins fonctionnels et non fonctionnels de
notre application et nous identifierons les différents acteurs et les classes candidates.

3.2. Etude de l’existant

La description du Backbone IP/MPLS dans notre cas d’étude, va nous permettre de bien
comprendre l’architecture du service que nous nous proposons d’exploiter afin de développer
une application de contrôle des services.

3.2.1. Architecture du Backbone IP/MPLS de TUNISIANA

La figure 3.1 représente l’architecture du Backbone IP/MPLS de TUNISIANA.

Figure3. 1 Architecture du Backbone IP/MPLS de TUNISIANA

Asma TOUNSI Page 15

Chapitre3 : Etude de l’existant & spécification des besoins 2011/2012

Le Backbone MPLS est constitué de routeurs Cores (P : Provider) et de routeurs Edges (PE :
Provider Edge). Les routeurs Edges, se situant à l’extrémité du Backbone, donnent accès
direct aux services de TUNISIANA via des switchs d’accès (CE). Les routeurs Cores (P), se
situant au cœur du Backbone, ont la charge seulement d’assurer l’acheminement des données
sur le réseau de transmission via des fibres optiques.
Ainsi, nous pouvons citer dans ce qui suit les principales fonctions des différents équipemets
vu précédemment :
 P (Provider Router) :C’est un équipement de type routeur, ou commutateur qui
appartient à un domaine MPLS.
 PE (Provider Edge Router) : fait l’interface entre un domaine MPLS et le monde
extérieur. Ils possèdent des interfaces supportent le protocole MPLS coté Backbone et
des interfaces supportant le protocole IP coté accès.
 CE (Customer Edge Equipement) :C’est un routeur client connecté au Backbone IP
via un service d’accès. Il route en IP le trafic entre le site hébergeant les services et le
Backbone IP.

Le Backbone de TUNISIANA est constitué principalement de 18 routeurs et 28 switchs

centraux ou principaux déployés sur la totalité du territoire tunisien.

Pour assurer une haute disponibilité des services, les sites utilisent des architectures
redondantes reposant sur des switchs data et voix dupliqués (chaque équipement a son clone
avec la même configuration et les mêmes services connectés pour prendre la relève en cas de
pépin). Cette architecture particulière est dictée par des besoins pour assurer d’une part la
continuité du service en cas de pannes imprévus et de permettre d’autre part d’établir un
équilibrage de charge en cas de congestion.

Le réseau de TUNISIANA se compose de 7 sites reliés entre eux via le Backbone. Chaque
site est composé d’une interconnexion de réseaux locaux physique utilisant des switchs
(quatre switchs dont « deux data» et « deux voix » identifiés par des adresses IP) pour
délivrer des services de niveau deux (se basant sur la notion de vlans) et de niveau trois (se
basant sur un adressage IP spécifique). Chaque service utilise un des deux types cités
précédemment selon le design choisi et le besoin requis par l’opérateur.

Dans le paragraphe suivant, nous allons détailler le processus de contrôle et de maintenance

d’un service. Nous allons mettre en évidence en particulier les difficultés rencontrées par les
ingénieurs de TUNISIANA auxquels est affectée la tâche de contrôle et de maintenance.

Asma TOUNSI Page 16

Chapitre3 : Etude de l’existant & spécification des besoins 2011/2012

Ceci nous sera très utile dans la description de la nature fastidieuse des tâches effectuées
manuellement spécialement celle de l’investigation et l’éventuelle contribution que nous nous
proposons d’apporter en automatisant ces tâches à travers une application ergonomique,
conviviale et intuitive.

3.2.2. Etude d’un exemple de « check service »

En fait TUNISIANA dispose de plusieurs types de services qu’il est nécessaire
d’entretenir, de maintenir, de contrôler et d’effectuer les réparations nécessaires en cas de
pannes, de proposer une batterie de tests structurés au niveau des switchs, des Vlans et des
serveurs.
Afin de bien illustrer le processus de test, nous nous focalisons sur les étapes de test manuel
d’un service particulier. Nous avons choisi parmi les services de TUNISIANA le service
CRBT (Call Ring Back Tone).

 Définition du service CRBT :

C’est un service téléphonique. Le service CRBT « Call Ring Back Tone » (Service
« Samma3ni » de TUNISIANA) consiste à déclencher automatiquement une chanson au
niveau d’un terminal téléphonique aussitôt qu’une signalisation d’appel est détectée par un
autre terminal téléphonique distant (littéralement « sonnerie de retour »).

 Architecture du service CRBT :

Le service CRBT est hébergé dans le site TUNISIANA de SIDI-RZIG. Il est
accessible directement à partir de deux switchs voix (SW9148_VA(CE) et SW9148_VB(CE))
reliés directement aux routeurs d’accès PE du Backbone IP/MPLS de TUNIS.

Asma TOUNSI Page 17

Chapitre3 : Etude de l’existant & spécification des besoins 2011/2012

Figure3. 2 Architecture du service CRBT

Nous avons étudié, dans le deuxième chapitre, les fonctionnalités de quelques composants de
cette dernière architecture comme « MS », « BSS », « BSC » et« BTS », les restes seront
définis dans ce qui suit.

- STP (Signal Transfer Points) : Ce sont les commutateurs de paquets du réseau SS7. Ils
reçoivent et routent les signaux de signalisation entrant vers la destination appropriée.
Ils assurent également des fonctions de routage spécialisées.
- MSC est divisé en deux parties: MGW (Media Gateway) et le serveur MSC (Mobile
Switching Centre Server (MSS)). Ce dernier est le noyau de l'ensemble du réseau et

fournit une connexion d'appel et de contrôle.

Un serveur MSC contrôle un MGW ou plusieurs.

 Processus de test du service CRBT :

En fait, les tests existants relatifs à un service sont entrepris manuellement par un
groupe d’ingénieurs de l’équipe IP/MPLS de TUNISIANA.
Le service CRBT est composé d’un ensemble de sous services accessibles à partir d’un
ensemble d’interfaces.

Asma TOUNSI Page 18

Chapitre3 : Etude de l’existant & spécification des besoins 2011/2012

Les étapes de test de la disponibilité et l’accessibilité d’un tel service, se résument dans les
points suivants :

 1ère étape :

Vérifier la connectivité de tous les serveurs (identifiés par des adresses IP) hébergeant le
service CRBT à partir des deux switchs voix de SIDI-RZIG (SW_VA et SW_VB) via la
commande Ping.

 2ème étape :

Il est indispensable de savoir ces différentes interfaces qu’il possède à travers une commande
appliquée depuis les deux switchs voix d’agrégation de SIDI-RZIG « show interface
description | inc CRBT »

Figure3. 3 Les interfaces du service CRBT

Le résultat de l’exécution de la commande montre que le service CRBT véhicule le trafic sur
2 interfaces Gi 1/13 et Gi 1/14. L’interface Gi 1/13 possède 3 sous-interfaces (relatives aux
services SERVICE, O&M, BACKUP) et l’interface Gi 1/14 possède 2 sous-interfaces
(relatives aux services VoIP, Sig).
Après avoir identifié les Vlan du service CRBT par leurs adresses IP, il sera possible de tester
la connectivité de chaque Vlan en lançant des commandes Ping.

Asma TOUNSI Page 19

Chapitre3 : Etude de l’existant & spécification des besoins 2011/2012

Table 3.1 Liste de commande pour chaque VLAN

VLAN Commande
VLAN O&M Ping vrf OM @ip
VLAN SERVICE ping @ip
VLAN Backup Ping vrf OM @ip
VLAN Sigtran (1&2) Ping vrf Signaling @ip
VLAN Voice Ping vrf Voice @ip

L’étude détaillée de l’ensemble structuré de tests manuels divers effectués au sein du

département IP/MPLS de TUNISIANA d’une part et les exigences d’automatiser ces tests
d’autre part nous ont amené à dégager les spécifications des besoins aussi bien fonctionnels
que non fonctionnels.

3.3. Capture des besoins fonctionnels

L’étape de capture des besoins fonctionnels est la première étape du processus de
développement orienté objet. Elle permet d’identifier les différents cas d’utilisation et ceci en
les décrivant et organisant en blocs fonctionnels. Cette étape permet aussi de préparer
l’analyse orientée objet en identifiant les classes candidates de notre application.

3.3.1. Identification des acteurs

Notre application fait intervenir principalement les acteurs suivants :

 Agents : Ils sont tous les membres de toutes les équipes de TUNISIANA. Ils peuvent
consulter notre application web, visualiser les informations qui concernent les services
et les switchs.
 Administrateurs : Ils sont tous les membres de l’équipe IP /MPLS et ils présentent
l’acteur qui est chargé de toutes tâches apportées par notre application.

3.3.2. Identification des cas d’utilisation

Les cas d’utilisation définissent l’ensemble des fonctions offertes par le système afin de
répondre aux besoins de ses acteurs. Pour pouvoir dégager les besoins fonctionnels, il faut
maîtriser les objectifs que notre projet vise à satisfaire à savoir :

 Informatisation et automatisation du processus de test.

 Identification des problèmes physiques.

Asma TOUNSI Page 20

Chapitre3 : Etude de l’existant & spécification des besoins 2011/2012

 Centralisation des données de configuration des différents services, switchs et

routeurs.
 Diminution du temps de vérification de la disponibilité des services.

Le tableau 3.2 décrit les différents cas d’utilisation de notre système.

Table 3.2 Identification des cas d’utilisation du système

Cas d’utilisation Acteurs Description

Consulter les états des Agent &Administrateur Affiche des informations
services concernant les services et
vérifie leurs états
Consulter les états des Agent & Administrateur Affiche des informations
switchs concernant les switchs et
vérifie leurs états
S’authentifier Agent & Administrateur Fournit les paramètres de
connexion (login et mot de
passe) pour se connecté au
système
Gérer les switchs Administrateur Test, ajout, consultation,
suppression et modification
des switchs
Gérer les services Administrateur Test, ajout, suppression,
consultation et modification
des services
Consulter backup Agent & Administrateur Consulter résultats du backup
et leur sauvegarde dans des
fichiers
Gérer les utilisateurs Administrateur Consultation, ajout,
suppression et modification
des informations concernant
les utilisateurs

Asma TOUNSI Page 21

Chapitre3 : Etude de l’existant & spécification des besoins 2011/2012

3.3.3. Diagrammes des cas d’utilisation

Après avoir identifié les cas d’utilisation et leurs acteurs, nous pouvons les représenter
graphiquement sur un diagramme de cas d’utilisation.

Vu le nombre important des actions du modèle des cas d’utilisation du système et pour des
raisons de simplification de la représentation, le modèle va être divisé en diagrammes
présentant quelques-unes des diverses fonctionnalités offertes par notre outil.

La figure 3.4 présente le diagramme cas d’utilisation de notre système.

Figure 3.4 Diagramme de cas d’utilisation générale

Nous allons présenter dans ce qui suit une description des sous cas d’utilisation pour les
opérations qui possèdent les fonctionnalités principales que l’application doit offrir :

<<s’authentifier>>, << gérer les services>>, << gérer les utilisateurs>>, et

<< consulter Backup>>.

Asma TOUNSI Page 22

Chapitre3 : Etude de l’existant & spécification des besoins 2011/2012

 S’authentifier :
Table 3.3 Description de cas d’utilisation « s’authentifier »

SOMMAIRE D'IDENTIFICATION
Titre : Exprimer une authentification
Se permettre un accès à l’application « Health Check » via un login et un mot
But :
de passe.
Après authentification réussie, l’utilisateur selon son profil (Agent ou
Résumé : Administrateur accède à une interface appropriée.

Acteur : Utilisateur
DESCRIPTION DES ENCHAINEMENTS
Pré conditions Post conditions

 La page principale de
 Accès aux pages dont l’utilisateur a le droit
l’application
Scénario nominal

1. L’utilisateur s’authentifie.

2. Si les données sont correctes, le contenu de la plateforme s’affiche.

3. L’utilisateur choisit une tâche (à partir du menu).

Enchaînement alternatif
E1 : Champ login ou mot de passe est vide ou erroné
1. Le système affiche un message d’erreur
2. Le système demande à l’utilisateur d’entrer un nouveau login et mot de passe et
boucle 3 fois tant que les paramètres d’authentification sont erronés.

Asma TOUNSI Page 23

Chapitre3 : Etude de l’existant & spécification des besoins 2011/2012

 Gérer les services :

Table 3.4 Description de cas d’utilisation « gérer les services »

SOMMAIRE DE GESTION DE SERVICES

Titre : Gérer les services
But : Test du service et manipulation de ses informations.
Après avoir accédé à son interface, l’utilisateur a le droit de manipuler
Résumé :
(modifier, ajouter, supprimer), de consulter ou de tester les services.
Acteur : Administrateur
DESCRIPTION DES ENCHAINEMENTS
Pré conditions Post conditions
 Afficher le menu
 Login
 Choisir le menu Tester Service (respectivement
 Mot de passe
ajouter, modifier, supprimer ou consulter) et valider

Scénario nominal
L’utilisateur s’authentifie.
1. Une interface appropriée sera affichée.
2. L’administrateur choisit le menu « Tester Service » (respectivement « Modifier
Service », « Ajouter Service», « Supprimer service» ou « Consulter Service»)
3. L’administrateur valide par appuyer sur un bouton.
4. Le système fait les opérations nécessaires pour tester services c'est-à-dire tester
les Vlans et les Serveurs.

5. Le système affiche les résultats de ces opérations.

Asma TOUNSI Page 24

Chapitre3 : Etude de l’existant & spécification des besoins 2011/2012

Figure 3.5 Diagramme de cas d’utilisation «gérer les services »

 Gérer les Utilisateurs :

Table 3.5 Description de cas d’utilisation « gérer les Utilisateurs »
SOMMAIRE D'IDENTIFICATION
Titre : Gérer les Utilisateurs
Ajouter, modifier, supprimer et consulter des informations concernant les
But :
utilisateurs
Après avoir accédé à son interface, l’administrateur a le droit de gérer (modifier,
ajouter, supprimer) ou de consulter les informations relatives aux utilisateurs
Résumé :
(Administrateurs et Agents), une fenêtre s’affiche pour enregistrer les
informations à propos de l’utilisateur.
Acteurs : Administrateur
DESCRIPTION DES ENCHAINEMENTS
Pré conditions Post conditions
 Afficher le menu
 Login  Choisir le menu Ajouter Utilisateur (respectivement
 Mot de passe modifier, supprimer ou consulter) et valider
 Remplir le formulaire et valider

Asma TOUNSI Page 25

Chapitre3 : Etude de l’existant & spécification des besoins 2011/2012

Scénario nominal
1. L’administrateur s’authentifie.
2. Une interface administrateur sera affichée.
3. L’administrateur choisit le menu « Ajouter Utilisateur » (respectivement « Supprimer
Utilisateur », « Modifier Utilisateur » ou « Consulter Utilisateur »)
4. L’administrateur remplit le formulaire et valide
5. Le système vérifie si tous les champs sont remplis
6. Le système met à jour la table Utilisateur

7. Le système affiche un message « Agent ajouté avec succès »

Enchaînement alternatif
E1 : Champ non rempli
1. Le système affiche le message « Veuillez introduire les données agent »
2. La demande d’introduire les données agents continue jusqu’au remplissage de tous les
champs.
E2 : Ajout non réussi
1. Le système bouclera sur la fonction Ajouter_Utilisateur() jusqu’à ce que l’ajout soi
réussi.

Figure 3.6 Diagramme de cas d’utilisation «gérer les Utilisateurs»

Asma TOUNSI Page 26

Chapitre3 : Etude de l’existant & spécification des besoins 2011/2012

 consulter Backup :

Table 3.6 Description de cas d’utilisation «consulter Backup »

SOMMAIRE D'IDENTIFICATION
Titre : Consulter Backup
But : Visualiser les fichiers de Backup
Après avoir accédé à son interface, l’utilisateur (Administrateur ou Agent) a le

Résumé : droit de consulter les résultats des commandes sur les switchs qui sont
enregistrés dans des fichiers de Backup .

Acteur : Utilisateur
DESCRIPTION DES ENCHAINEMENTS
Pré conditions Post conditions
 Login  Afficher le menu
 Mot de passe  Choisir le menu Backup et valider
Scénario nominal
1. L’utilisateur s’authentifie.
2. Une interface utilisateur sera affichée.
3. L’utilisateur choisit le menu « Backup » (respectivement l’opération à réaliser)
4. Le système lance la commande.
5. Le système enregistre le résultat de l’opération dans son fichier Backup qui lui
correspond. Il affiche le résultat de la commande

3.3.4. Identification des classes candidates

Suite à l’identification des cas d’utilisation, nous pouvons identifier les classes
candidates du système, opération nécessaire pour pouvoir passer à l’analyse fonctionnelle. Les
premières classes candidates identifiées dans cette phase sont des concepts connus des
utilisateurs du système appelés objets métier. Selon notre application, nous pouvons dégager
les classes participantes suivantes :

Asma TOUNSI Page 27

Chapitre3 : Etude de l’existant & spécification des besoins 2011/2012

Table 3.7 Identification des classes candidates

Nom de la classe Description
Classe Utilisateur Définit l’ensemble des utilisateurs de
TUNISIANA qui ont accès à notre
application.
Classe Equipe - Représente les équipes des utilisateurs avec
leurs droits d’accès (Administrateurs ou
Agent)
Classe Switch - Contient tous les switchs appartenant au
réseau de transmission de TUNISIANA.
Classe Service - Contient tous les services offerts par
TUNISIANA.
Classe Routeur - Contient tous les routeurs appartenant au
réseau de transmission de TUNISIANA.

3.4. Capture des besoins non fonctionnels

Ce sont des exigences qui ne concernent pas spécifiquement le comportement du système

mais plutôt identifient des contraintes internes et externes du système.
Les principaux besoins non fonctionnels de notre application se résument dans les points
suivants :

 Modularité et flexibilité : L’implémentation doit être modulaire pour permettre par la

suite l’extensibilité, l’amélioration de l’application et l’adaptation aux besoins futurs.
 Ergonomie : Une interface conviviale et facile à manipuler par les utilisateurs
(ingénieurs et managers).
 Sécurité : L’application doit réserver l’accès aux données aux utilisateurs les plus
appropriés à travers une authentification.

Asma TOUNSI Page 28

Chapitre3 : Etude de l’existant & spécification des besoins 2011/2012

3.5. Conclusion
Nous venons, au niveau de cette partie, de présenter l’architecture du Backbone IP/MPLS
de TUNISIANA ainsi qu’une description détaillée d’un exemple de test d’un service. Aussi,
nous avons réalisé la capture des besoins fonctionnels et non fonctionnels. Cette capture des
besoins a permis de préparer les phases d’analyse et de conception qui
forment l’objet du quatrième chapitre.

Asma TOUNSI Page 29

Chapitre 4 : Conception de l’application 2011/2012

Chapitre 4 :
Conception de l’application

Asma TOUNSI Page 30

Chapitre 4 : Conception de l’application 2011/2012

4.1. Introduction

Après l’étape d’étude de l’existant et de spécification des besoins, nous arrivons à un

autre stade primordial dans le cycle de vie d’un projet qui est la conception. Nous
commencerons ce chapitre par établir le choix de la méthodologie de conception et nous
décrirons ensuite la conception générale avant d’expliciter la conception détaillée.

La phase d’analyse nous permettra de dégager un premier modèle statique et dynamique du

système.

4.2 Conception générale

La conception représente le lien sémantique indispensable entre l’analyse préalable d’un
projet et la phase d’implémentation. Puis, nous étudierons, dans la partie suivante,
l’environnement de la conception.

4.2.1. Choix de la méthodologie de conception

La méthodologie de conception nous permettra de formaliser les étapes préliminaires du
développement d'un système. Il existe plusieurs méthodologies dont les plus répandues sont
Merise et UML (Unified Modeling Language). Pour la réalisation de notre projet nous avons
opté pour l’UML.

L’UML est un langage de modélisation objet qui permet de cadrer l’analyse et de représenter
le système selon différentes vues complémentaires par les divers diagrammes qu’il offre.
C’est un support de communication performant, qui facilite la représentation et la
compréhension des solutions objet [7] à travers les points suivants :

- sa notation graphique permet d’exprimer visuellement une solution objet, ce qui

facilite la comparaison et l’évaluation des solutions ;
- l’aspect formel de sa notation, limite les ambiguïtés et les incompréhensions ;
- son indépendance par rapport aux langages de programmation, aux domaines
d’application et aux processus, en fait un langage universel.

4.2.2. Choix de l’outil de conception

Suite au choix de la méthodologie de conception de l’application, l’outil choisi pour la
modélisation sera Rational Rose Entreprise Edition 2003 pour le raisons suivantes : il est le
leader du marché, assez souple dans la gestion des projets et offre une panoplie de services

Asma TOUNSI Page 31

Chapitre 4 : Conception de l’application 2011/2012

qui facilitent la conception. Cet outil sera utilisé pour modéliser les différentes fonctions
métiers de notre application à travers différents diagrammes (diagramme de cas d’utilisation,
de classes, de séquences...).

4.2.3. Conception des interfaces

Il est nécessaire pour chaque application web, comme dans notre cas d’étude, de
réaliser une charte graphique qui se base sur la notion de Template et utilisent les feuilles de
style CSS, ce qui nous permet d’assurer une interface homme machine ergonomique et facile
à utiliser et à modifier.

4.2.4. Architecture de l’application

La navigation entre les différentes parties de notre application que nous nous
proposons de réaliser est présentée par la figure ci-dessous.

Figure 4. 1 Architecture des interfaces de l'application

: Nécessite une connexion à distance au switch avec le service Telnet.

Asma TOUNSI Page 32

Chapitre 4 : Conception de l’application 2011/2012

4.2.5. Modèle de conception

L'organisation globale d'une interface graphique est souvent délicate. L'architecture MVC
(Le modèle-vue-contrôleur est un patron d'architecture et une méthode de conception qui
organise l'interface homme-machine (IHM) d'une application logicielle) ne résout pas tous les
problèmes. Elle fournit souvent une première approche qui peut ensuite être adaptée. Elle
offre aussi un cadre pour structurer une application. Ce modèle d'architecture impose la
séparation entre les données, la présentation et les traitements, ce qui donne trois parties
fondamentales dans l'application finale : le modèle, la vue et le contrôleur [6].

 Modèle: représente les données et les règles métiers. C’est dans ce composant que
s’effectuent les traitements liés au cœur du métier.
 Vue : représente l’interface utilisateur. Elle n’effectue aucun traitement, elle se
contente simplement d’afficher les données que lui fournit le modèle. Il peut tout à fait
y avoir plusieurs vues qui présentent les données d’un même modèle.
 Contrôleur : Le contrôleur se charge d’intercepter les requêtes de l’utilisateur,
d’appeler le modèle puis de rediriger vers la vue adéquate. Il ne fait qu’intercepter et
rediriger les requêtes.

Figure 4. 2 Modèle MVC

Asma TOUNSI Page 33

Chapitre 4 : Conception de l’application 2011/2012

Avantage du modèle MVC :

Le modèle MVC dispose de points forts indéniables qui permettent une meilleure approche de
la conception des interfaces graphiques à savoir :
- La séparation des compétences (design, base de données, application).
- La simplicité de mise à jour.
- La vitesse de création de pages.

4.3. Conception détaillée

Cette étape se compose de deux sous étapes : le développement du modèle statique et

le développement du modèle dynamique.

4.3.1. Développement du modèle statique

Les classes participantes, dégagées lors du chapitre précédent, sont détaillées et affinées
par l’ajout des attributs et des opérations, complétées par la création de nouvelles classes et
optimisées par les relations de généralisation.
La figure 4. 3 Ci-dessous représente le diagramme de classe de notre application.

Figure 4.3 Diagramme de classe

Asma TOUNSI Page 34

Chapitre 4 : Conception de l’application 2011/2012

Les tables présentes dans la figure 4.3 seront étudiées lors de la conception de la base de
données.

Chaque membre de TUNISIANA appartient à une équipe qui définit les droits d’accès des
utilisateurs. Dans notre cas, l’équipe IP/MPLS est l’administrateur de l’application.

Et suivant ces privilèges l’utilisateur peut accéder et gérer les services, switchs et routeurs.

4.3.2. Développement du modèle dynamique

Cette activité consiste à ajouter des diagrammes de séquences pour différents scénarios
afin de mieux les comprendre. Un scénario décrit une exécution particulière d’un cas
d’utilisation du début à la fin. Il correspond une suite d’enchaînements du cas d’utilisation [7].
Afin de clarifier notre modélisation, nous proposons dans cette section de développer nos
modèles dynamiques (diagrammes de séquences) à l’aide des classes d’analyse.
Par définition, une classe d’analyse est une abstraction d’une ou plusieurs classes lors de la
conception de l’application.
Pour notre application nous identifierons les classes d’analyse suivantes :
- Interface : représente la classe frontière. Elle regroupe toutes les interfaces
de l’application.
- Switch, Utilisateur, Service, Routeur, Equipe: représentent les classes
entités.

Dans ce qui suit nous représenterons les scénarios les plus importants à savoir
« Authentification», « Ajout d’un service », « Modification d’un switch», « Suppression d’un
utilisateur», « Test d’un service» et « Backup config» sachant que les opérations de l’ajout, la
modification et la suppression ont le même principe pour les switchs, les services et les
utilisateurs.

 Scénario « Authentification » :
Pour accéder à l’application, l’utilisateur doit disposer d’un mot de passe et d’un login.
Qu’il soit un Agent ou un administrateur, l’application l’acheminera vers une interface
appropriée à ses fonctionnalités.
Ce scénario est illustré par le diagramme de séquences de la figure 4.4.

Asma TOUNSI Page 35

Chapitre 4 : Conception de l’application 2011/2012

Figure 4. 3 Diagramme de séquences « Authentification »

Il est à noter que la fonction verifier_utilisteur() permet d’effectuer une recherche dans la
table des utilisateurs à partir du mot de passe et du login saisis par l’utilisateur. En effet, elle
assure deux fonctionnalités :

- identifier l’utilisateur en tant qu’Agent ou Administrateur

- indique le succès ou l’échec de l’authentification.

Dans ce cas où verifier_utilisteur()=false, c'est-à-dire si l’utilisateur n’a pas été trouvé, le

système demande à l’utilisateur d’entrer un nouveau login et mot de passe et boucle 3 fois tant que
l’utilisateur demande l’accès à l’application et entre un login et /ou un mot de passe erroné(s).

Asma TOUNSI Page 36

Chapitre 4 : Conception de l’application 2011/2012

 Scénario « Ajout service »

Pour ajouter un service, l’administrateur doit tout d’abord accéder à la rubrique « Gestion
des services », puis à la rubrique « Ajouter un service ». Une fois à ce stade, l’administrateur
doit remplir les différents champs (id_service, hostname, localisation), puis confirmer cette
action. Après la mise à jour du service, un message va s’afficher pour confirmer l’ajout du
service ou non.

Figure 4. 5 Diagramme de séquences « Ajout service »

Notons que la fonction ajouter_service() se chargera de créer une instance de la classe service,
la remplit avec les données entrées par l’administrateur et informe le système du succès ou de
l’échec de l’ajout.

Dans cas où les champs sont non remplis, le système demandera d’introduire les données
jusqu’à ce que l’administrateur remplisse tous les champs concernant le service.

Asma TOUNSI Page 37

Chapitre 4 : Conception de l’application 2011/2012

Dans le cas où l’ajout est non réussi, l’application bouclera 3 fois sur la fonction
ajouter_service () jusqu’à ce que l’ajout soit effectué convenablement.

 Scénario « Modifier switch » :

Pour modifier les attributs d’un switch (hostname, adresse IP, site, login, mot de passe),
l’administrateur doit tout d’abord accéder à la rubrique « Gestion des switchs », puis à la
rubrique « Modifier un switch ». Ensuite, l’administrateur doit modifier les différentes
informations, puis confirmer cette action. Enfin, après la mise à jour du switch, un message va
s’afficher confirmant la modification des attributs du switch.

Figure 4. 6 Diagramme de séquences « Modifier switch »

La fonction modifier_paramétres_switch () a pour rôle de modifier le(s)paramètre(s) choisi(s)

de la base de données, la table des switchs, qui sera par la suite mise à jour.

Asma TOUNSI Page 38

Chapitre 4 : Conception de l’application 2011/2012

 Scénario « Suppression Utilisateur » :

Figure 4. 7 Diagramme de séquences « Suppression Utilisateur »

Après que l’administrateur confirme sa demande, la fonction supprimer_utilisteur() va

supprimer l’utilisateur choisi de la base de données et le système affichera le résultat de cette
opération.

 Scénario « Test d’un service » :

Figure 4.8 Diagramme de séquences « Test d’un service »

Asma TOUNSI Page 39

Chapitre 4 : Conception de l’application 2011/2012

L’opération de tester un service revient à tester les Vlans et les Serveurs appropriés à ce
service. Après que l’administrateur soit arrivé à l’interface de check service, il sélectionne le
service qu’il veut tester. Le système lance la commande ping puis récupère son résultat dans
un fichier pour le parcer (décomposer). Suivant ce parcing, le résultat de l’opération sera
affiché à l’administrateur.

 Scénario « Backup Config » :

Figure 4. 9 Diagramme de séquences « Backup config»

L’utilisateur peut visualiser les Backups des opérations par un simple clic sur le
menu « Backup» puis choisit la commande. Ce scénario est identique pour l’opération de
Backup des états des interfaces, état spanning-tree, état HSRP et messages log.

4.3. Conception de la base de données

Le modèle relationnel de données est un modèle de données comme d’autres existants
ayant pour but de décrire le monde réel à partir des informations. A ce niveau de cette
application et tout en considérant les besoins déjà spécifiés, nous avons envisagé un certain
nombre de tables pour enregistrer les données nécessaires pour la gestion des switchs, des
services et des utilisateurs.

Asma TOUNSI Page 40

Chapitre 4 : Conception de l’application 2011/2012

Notre application fait intervenir les tables suivantes :

Table 4.1 Description de la base de données

Nom de la table Description

Equipe Cette table contient les noms de toutes les
équipes de TUNISIANA et leurs droits d’accès
(« Administrateur » ou « Agent »).
En effet, le système et avant de faire n’importe
qu’elle opération, consulte cette table pour
savoir les droits d’accès des utilisateurs.
Utilisateur Cette table contient les noms des utilisateurs de
l´application. Chaque utilisateur est identifié
par un login et un mot de passe.
Switch Cette table contient les données qui sont
relatives aux équipements de type switch. En
effet, cette table contient les champs suivants :
 hostname: le nom du switch ;
 adrIP : l’adresse IP du switch;
 site : le site où est localisé ce switch ;
 login ;
 mot de passe ;
Il est à noter que cette table est dynamique car
elle supporte l´ajout, la suppression et la
modification des switchs.
Service Cette table contient les données qui sont
relatives aux services de TUNISIANA.
En effet, cette table contient les champs
suivants :
 hostname: le nom du service ;
 localisation : les switchs qui
contiennent ce service;
 type_trafic : le type de trafic du service
Il est à noter que cette table est dynamique car

Asma TOUNSI Page 41

Chapitre 4 : Conception de l’application 2011/2012

elle supporte l´ajout, la suppression et la

modification des services.
Routeurs Cette table contient les données qui sont
relatives aux équipements de type routeur. En
effet, cette table contient les champs suivants :
 hostname: le nom du routeur ;
 adrIP : l’adresse IP du routeur;
 localisation : le site où est localisé ce
routeur.

Les tables utilisées et les relations qui les inter-relient sont données par la figure 4.10.

Figure 4.10 Modélisation de la base des données

Asma TOUNSI Page 42

Chapitre 4 : Conception de l’application 2011/2012

4.4. Conclusion
Ce chapitre a été consacré à la présentation de l’étude conceptuelle élaborée. En effet,
nous avons opté pour le choix d’UML (UnifiedModelingLanguage) comme méthodologie de
conception. Cette dernière est caractérisée par plusieurs diagrammes dont nous avons choisi
d’élaborer le diagramme de cas d’utilisation, de classe et de séquences classés entre la vue
statique et celle dynamique.

Après cette étude conceptuelle nous dédierons le chapitre cinq à la

présentation de l’environnement de travail et les principales composantes
de l’application réalisée au cours de ce projet.

Asma TOUNSI Page 43

Chapitre 5 : Réalisation de la plateforme « HEALTH CHECK » 2011/2012

Chapitre 5 : Réalisation de la
plateforme « HEALTH CHECK »

Asma TOUNSI Page 44

Chapitre 5 : Réalisation de la plateforme « HEALTH CHECK » 2011/2012

5.1. Introduction

L’étape réalisation constitue la phase d’achèvement et de concrétisation du projet. Il

s’agit de la traduction de la conception dans un langage de programmation. Ce chapitre vise à
présenter les différentes phases de réalisation du projet. Pour accomplir cette étape avec
succès il faut savoir utiliser les outils adéquats et nécessaires.

Nous commencerons par décrire les aspects techniques de l’application, en particulier le choix
de l’architecture, ensuite nous présenterons l’environnement de travail.

Nous donnerons enfin une description des résultats aboutis décrits par quelques imprimes
écrans.

5.2. Aspect technique de l’application

Pour la réalisation de ce projet nous avons choisi de travailler avec :

 J2EEcomme plateforme de réalisation.

 NetBeans comme IDE.
 MySQL Workbench comme SGBD.
 Hibernate comme Framework côté base de données et JSF comme Framework côté
présentation.

5.2.1. Choix de la plateforme Java EE

Une plate-forme applicative se présente sous la forme d’une suite logicielle comprenant
l’ensemble des briques nécessaires au déploiement d’une application client/serveur de haut
niveau, à savoir une application ou plusieurs applications serveur accessibles, généralement
en mode Web, depuis des postes de travail ou des terminaux Internet .
Notre choix de l’architecture J2EE comme plateforme pour développer notre application se
justifie par plusieurs raisons, pour n’en citer que l’essentiel :
 Plateforme totalement gratuite.
 Garantie des services nécessaires pour toute application d’entreprise moderne.
 La disponibilité d’une multitude d’outils open source.
 La portabilité.
 La liberté de choix des différents outils.

Asma TOUNSI Page 45

Chapitre 5 : Réalisation de la plateforme « HEALTH CHECK » 2011/2012

5.2.2. Choix de l’architecture J2EE

Dans une architecture 3-tiers, une même application est séparée en trois couches
logicielles. Le modèle 3 tiers vise à atteindre les objectifs suivants :

 Centraliser les données dans un serveur de données, et exécuter l’application

sur un serveur d’application ceci à pour conséquence de simplifier les contrôle
de sécurité et de convivialiser des mises à jour des données et des SGBD.
 Améliorer la sécurité contre les attaques.
 La séparation des couches qui a pour avantage de minimiser les pannes.

Figure 5. 1 Architecture 3-tiers

Dans ce type d’architecture, le programme client réalise les fonctions des couches logiques de
présentation, et contrôle le domaine d’application .Il fait appel au serveur de bases de données
pour réaliser le service de persistance des données. (Figure 5.1)
Nous distinguons ainsi :
 Presentation Layer (couche présentation) : C’est la partie dans laquelle le client fait ses
demandes (requêtes) et où le résultat s’affiche.
 Business Layer (couche métier) : C’est la partie où l’exécution des demandes du client
sera traitée.
 Data Access Layer (couche données) : elle gère l’accès, le stockage et persistance des
données.
L’architecture 3 tiers présente plusieurs avantages dans le sens où elle offre :
 Une facilité de déploiement de flexibilité et de maintenances.
 Une sécurité propre à chaque service, et à chaque niveau
 Une meilleure performance, étant donné le partage des tâches entre les différents
serveurs.
 Un accès à distance de l’application.

Asma TOUNSI Page 46

Chapitre 5 : Réalisation de la plateforme « HEALTH CHECK » 2011/2012

5.2.3. Frameworks de développement

Bien que l’utilisation des Frameworks dans l’architecture J2EE nécessite un certain
temps pour maitriser ces outils, il est intéressant de les utiliser dans la mesure où ils
permettent de faciliter l’interfaçage entre les différentes entités (voir figure ci-dessous 5.2).

Figure 5. 2 Architecture 3 tiers J2EE et Framework associés

L’architecture 3-tiers adoptée respecte est implémente le modèle MVC qui parmi ces
avantages on distingue la modularité et l’indépendance entre les couches (couche
présentation, couche serveur d’application, couche base de données).

[Link]. JSF

L’environnement J2EE fournit des Frameworks assez intéressants qui facilitent

l’interfaçage entre les différentes entités. Ainsi, le Framework JSF (Java Server Faces) joue le
rôle d’une interface entre l’application et l’interface graphique.

Le JSF se base sur les technologies JSP (Java Server Pages) et servlets et a pour finalité
l’amélioration de la productivité du développement des interfaces utilisateur tout en facilitant
leur maintenance [8].

[Link]. Hibernate

Le Framework Hibernate permet de gérer la persistance des objets pour les bases de
données relationnels. L’API JDBC permet par exemple de manipuler SQL dans le langage de
programmation JAVA.

Asma TOUNSI Page 47

Chapitre 5 : Réalisation de la plateforme « HEALTH CHECK » 2011/2012

5.2.4. Système de gestion de base de données

Pour le choix de la base de données, nous avons choisi le SGBD MySQL. En effet
notre choix est justifié par le fait que SQL est libre, gratuit et très utilisé aussi bien dans les
projets libres que dans le milieu industriel.

5.3. Environnement de travail

Dans ce paragraphe nous décrirons l’environnement matériel utilisé dans ce projet ainsi
que l’environnement logiciel qui a permis la mise en place de notre application « Health
Check ».

5.3.1. Environnement matériel

Ce travail a été réalisé dans les locaux de TUNISIANA avec un environnement de

Windows XP. Nous avons utilisé un micro-ordinateur muni d’une connexion au réseau
d’entreprise de TUNISIANA et un accès internet.

5.3.2. Environnement logiciel

[Link].Serveur d’application : Tomcat

Tomcat est un serveur d’application totalement écrit en java. Il a été développé en

open source au sein du projet Apache Jakarta, dont le but est de fournir des solutions serveur
basées sur la plate-forme Java, de qualité identique aux applications commerciales. Tomcat
est un moteur d’exécution pour les servlets et les pages JSP. Il prend en charge la partie
dynamique du site et laisse la partie statique au serveur web.

[Link]. Environnement de développement intégré : Netbeans 7.0.1

Netbeans propose les outils nécessaires à la création d'applications professionnelles

pour les particuliers, les entreprises, le web et les applications mobiles avec plusieurs langages
en particulier Java [9].

[Link]. Système de gestion de base de données : MySQL Workbench 5.2

MySQL est un système de gestion de base de données relationnelle et objet. Il

convivialise la manipulation graphique des tables et peut être facilement intégré à Netbeans à
travers l’appel d’une bibliothèque (MySQL [Link])

Asma TOUNSI Page 48

Chapitre 5 : Réalisation de la plateforme « HEALTH CHECK » 2011/2012

5.4. Travail réalisé

A cette étape du rapport, nous donnerons les captures d’écran relatives aux principales
interfaces de l’application.

5.4.1. Interface d’authentification des utilisateurs

Chaque utilisateur doit s’authentifier avant de pouvoir accéder à l’application avec ces
différentes fonctionnalités. La figure 5.3 illustre les champs nécessaires à remplir pour
accéder à l’application.

Figure 5. 3 Interface « Authentification » de l'application

En cas de succès de l’authentification, L’application va nous permettre à travers son interface

principale de consulter et contrôler les différents switchs et services du réseau IP/MPLS ainsi
que de lancer des tests (de maintenances ou pour réparation de panne) sur les switchs ou les
services de TUNISIANA.

Asma TOUNSI Page 49

Chapitre 5 : Réalisation de la plateforme « HEALTH CHECK » 2011/2012

5.4.2. Interface d’accueil

A travers l’interface d’accueil, l’utilisateur de l’application « Health Check » peut

accéder à partir d’un menu déroulant en haut de la page aux différentes fonctionnalités de
l’application :
« Gestion des switchs », « Gestion des services », « Gestion des utilisateurs », Consultation
du l’historique de l’état des switchs « Backup ». « Inventaire ».

Figure 5. 4 Interface « Accueil » de l'application

Asma TOUNSI Page 50

Chapitre 5 : Réalisation de la plateforme « HEALTH CHECK » 2011/2012

5.4.3. Géo localisation des switchs d’accès CE

Nous pouvons accéder à la carte géographique de localisation des switchs (« Map ») à

partir du menu «Présentation »

Figure 5. 5 Accéder à la carte géographique

Asma TOUNSI Page 51

Chapitre 5 : Réalisation de la plateforme « HEALTH CHECK » 2011/2012

Figure 5. 6 Géo localisation des switchs

Il est possible de localiser les switchs d’accès CE sur une carte géographique.

Asma TOUNSI Page 52

Chapitre 5 : Réalisation de la plateforme « HEALTH CHECK » 2011/2012

Figure 5. 7 Accéder aux caractéristiques du switch à partir de la carte

Aussi, on peut découvrir les caractéristiques des switchs et accéder à l’interface « check
switch » par un clic.

Asma TOUNSI Page 53

Chapitre 5 : Réalisation de la plateforme « HEALTH CHECK » 2011/2012

5.4.4. La liste des switchs

L’utilisateur pourra accéder à la liste des switchs à partir du menu « Gestion des
switchs »,
Une liste des switchs sera affichée avec leurs adresses IP ainsi que les différentes opérations
qu’on peut appliquer (« Show »: pour afficher les infos sur le switch, « Edit » : pour modifier
les caractéristiques du switch et « Delete » : pour supprimer le switch de la base de données).
Tous les utilisateurs peuvent tester l’état d’un switch avec un simple clic mais seuls les
utilisateurs connectés avec un compte administrateur peuvent
Afficher(Show)/Modifier(Edit)/Supprimer(Delete) les données d’un switch.

La figure 5.8 présente l’interface de la liste des switchs.

Figure 5.8 Liste des switchs avec les différentes opérations (Modifier, Afficher, Supprimer,
Tester)

Asma TOUNSI Page 54

Chapitre 5 : Réalisation de la plateforme « HEALTH CHECK » 2011/2012

5.4.5. Ajout d’un switch

Nous pouvons accéder à l’interface d’ajout d’un switch à partir du menu « Gestion des
switchs »

Figure 5.9 Accéder à l’interface «Ajouter un switch »

L’administrateur de l’application a la possibilité d’ajouter un switch à la liste existante, il

suffit de remplir un formulaire concernant les données du nouveau switch. Dans ce cas
l’application commence à télécharger les données concernées et les ajouter dans la base de
données. (Figure 5.10)

Asma TOUNSI Page 55

Chapitre 5 : Réalisation de la plateforme « HEALTH CHECK » 2011/2012

Figure 5.10 Interface « Ajout d'un switch »

5.4.6. Modifier un service

L’utilisateur connecté avec un compte administrateur a l’accès de modifier les données

d’un service. Il suffit de sélectionner le service à modifier et remplir ensuite les champs
correspondants avant d’enregistrer. (Figure 5.11)

Asma TOUNSI Page 56

Chapitre 5 : Réalisation de la plateforme « HEALTH CHECK » 2011/2012

Figure 5.11 Interface « Modification d'un service »

5.4.7. Consultation Backup

Parmi les plus importantes fonctionnalités que l’application offre aux ingénieurs de
TUNISIANA est la fonction Backup qui donne la possibilité de sauvegarder les différentes
informations et configurations des switchs dans des fichiers texte afin de les utiliser en cas de
panne ou de perte de configurations.

Asma TOUNSI Page 57

Chapitre 5 : Réalisation de la plateforme « HEALTH CHECK » 2011/2012

Figure 5.12 Interface consultation du « Backup »

 Config : l’option config dans notre application permet de copier dans un fichier texte
la configuration en cours d’exécution du switch sélectionné (suite à la
commande « Show running config »).
 Etat interface : Tester les états des interfaces du switch à travers la commande « show
ip interface brief », les informations seront sauvegardées dans un fichier texte afin de
pouvoir les exploiter ultérieurement.
 Etat spanningTree: Permet de récupérer dans un fichier texte les états du Spanning-
Tree d’un switch (qui est un protocole qui permet d’avoir une topologie de réseau
sans boucles) à travers la commande «show spanning-tree» afin que les ingénieurs de
l’équipe IP/MPLS puissent avoir une référence sur l’état du spanning-tree en cas de
problème.

Asma TOUNSI Page 58

Chapitre 5 : Réalisation de la plateforme « HEALTH CHECK » 2011/2012

 Log : Permet d’enregistrer les logs dans un fichier texte périodiquement ou su

demande à travers la commande « show logging ».
 Etat HSRP (Hot Standby Redunduncy Protocol): Tester l’état du HSRP à travers la
commande « show standby brief ».

5.4.8. Liste des services

Figure 5. 13 Interface « Liste des services »

l’utilisateur peut accèder à la liste des services à partir du menu « Gestion des services ». Il
peut à travers cette liste afficher, modifier, ou supprimer service ainsi que tester un service.

Asma TOUNSI Page 59

Chapitre 5 : Réalisation de la plateforme « HEALTH CHECK » 2011/2012

5.5. Exemple de test d’un service

La sélection du service CRBT (parmi les services affichés dans la liste des services)
nous permet d’afficher l’interface Figure 5.14.

Cette dernière, permet à partir d’un simple clic sur le bouton « Check service CRBT »
d’afficher le test des VLANs, des serveurs et des switchs correspondants.

Figure 5. 14 Architecture du service CRBT

Asma TOUNSI Page 60

Chapitre 5 : Réalisation de la plateforme « HEALTH CHECK » 2011/2012

Figure 5. 15 Interface du résultat du test du service CRBT

L’interface Figure 5.15 présente le résultat du test du service CRBT qui sera composés de
deux types de tests :

 Test des VLANs : le résultat sera affiché par type de VLAN et selon un plan bien
déterminé (PLAN A ou PLAN B) pour pouvoir localiser les pannes en cas d’un
problème. Le résultat est « OK » en cas d’un Ping réussi et affiche « Not OK » en cas
d’un Ping erroné.
 Test des serveurs : Il s’agit du test des serveurs hébergeant le service CRBT.

Asma TOUNSI Page 61

Chapitre 5 : Réalisation de la plateforme « HEALTH CHECK » 2011/2012

Chaque service possède des types de trafics qui lui sont spécifiques, nous nous sommes
contentés à titre illustratif d’expliciter en détail les différentes interfaces correspondantes.

5.6. Conclusion

L’intérêt de cette l’application se réside dans l’accès direct au switch et d’appliquer

n’importe quelle commande et de tester le fonctionnement d’un tel service ce qui permet à
l’utilisateur de mieux gérer la situation et de gagner surtout en terme de temps.

Asma TOUNSI Page 62

Conclusion générale 2011/2012

Conclusion générale

Le présent projet de fin d’études a porté sur la modernisation des services d’exploitation et de
maintenance des services de TUNISIANA à travers le développement d’une application
informatique reposant sur une architecture J2EE intitulé « Health Check »

Cette application nous a permis d’automatiser les tests manuels existants des services ce qui
nous a amené à implémenter un ensemble de tests relatifs aux switchs d’accès et aux VLANs
correspondants à chaque service et à disposer d’un outil informatique pour la gestion des
switchs, des utilisateurs et des services.

Nous avons eu l’occasion à travers notre application d’implémenter un service de Backup et

un service de géo-localisation des switchs.

Au terme de ce projet de fin d’études, et afin de valider notre application nous avons établi un
ensemble de tests permettant de vérifier le bon fonctionnement des différentes interfaces.

Notre contribution à travers l’application que nous avons développée se manifeste

principalement à travers les retombées positives sur la qualité de la maintenance et la
réparation des services TUNISIANA. On distingue entre autres, un écroutement très
significatif du processus de test des services, une plus grande convivialité dans la
manipulation et le lancement des tests ce qui a pour conséquence directe d’améliorer la
réactivité de l’opérateur vis-à-vis des réclamations relatives aux alarmes et aux pannes
survenant à différents niveaux (switchs d’accès, Vlans). Ceci qui engendrera une réduction
significative des temps des pannes et par suite une amélioration significative de la
disponibilité des services qui un atout incontournable pour l’image de marque de l’entreprise.

Sur le plan personnel, j’ai eu l’occasion d’acquérir un certain nombre de compétences

techniques au niveau du langage J2EE et du réseau de transmission IP/MPLS.

Le contexte professionnel et le fait de côtoyer des ingénieurs de métier m’a permis d’exercer
et exploiter les compétences acquises à l’INSAT pour mener à mon projet de fin d’études.

Asma TOUNSI Page 63

Netographie 2011/2012

Netographie
[1].[Link]
_de_tunisiana/historique

[6].[Link]
controller

[8].[Link]
[Link]/Documents/ProjetJEE/LMNTF_Hibernate_JSF/fichiers/tutoriel_jsf.pdf

[9].[Link]

Asma TOUNSI Page 64

Bibliographie 2011/2012

Bibliographie
[2] Heine, G. (1999). GSM networks: Protocols, terminology, andimplementation. Artech
House.

[3] Lagrange, X., Godlewski, P., and Tabbane, S. (1997). Réseaux GSM-DCS. Hermes.

[4] Demoulin, C. and Droogenbroeck, M. V. (2004). Principe de base du fonctionnement du

réseau GSM. Revue de l’AIM,pages 10–13.

[5] Deseine Alain (1999). GPRS

[7] Roques, P. and Vallée, F. (2003). UML en action de l’analyse des besoins à la conception

en Java. Eyrolles.

Asma TOUNSI Page 65

Chronogramme 2011/2012

Chronogramme

Etapes du projet:

1. Etape 1: Bibliographie.
2. Etape 2: Conception de l’application.
3. Etape 3: Conception de la base de données
4. Etape 4: Développement de l’application.
5. Etape 5 : Test de l’application.

Premier mois Deuxième Troisième Quatrième

mois mois mois
S1 S2 S3 S4 S1 S2 S3 S4 S1 S2 S3 S4 S1 S2 S3 S4
Etape 1
Etape 2
Etape 3
Etape 4
Etape 5

Asma TOUNSI Page 66

 "‫تصَيٌ وتطىيش اىْظبً األسبسي "هييث تشبك" ىخذٍبث "تىّيزيبّب‬

ٍِ ‫أٍبيأالس" و رىل ىيتّحقّق‬/‫يتضَِّ هزا اىَششوع تطىيش تطبيق ىحىسبت االختببساث اىيذويّت اىتي يقىً بهب فشيق "إيبي‬
."‫تىفّش خذٍبث "تىّيزيبّب‬
."‫حزف) ٍحىّالث اىىصىه إىى اىخذٍبث و ضىابط خذٍبث "تىّيزيبّب‬,‫تؼذيو‬,‫و هزا اىتّطبيق سيَنِّ ٍِ إداسة (إضبفت‬
.‫إّّه يهذف أيضب إلختببس اىخذٍبث و هزا ٍب يؼبده إخببس اإلتّصبه ببىَحىّالث و اىشّبنبث اىَحييت اىظبهشيّت اىَُطببقت‬
.‫أخيشا فإُّ هزا اىتّطبيق يَنِّ ٍِ ضَبُ خذٍت اىّْسخ اإلحتيبطي ػِ طشيق حفظ ٍيفبث اىتّهيئت ىَختيف ٍحىّالث اىىصىه‬
.‫مَب سيتٌّ تىفيش خذٍت تحذيذ اىَىقغ اىجغشافي ىيَحىّالث‬

‫اىّْسخ االحتيبطي‬,‫اىتشغيو اآلىي‬,‫حىّالث‬

ِ ٍ,‫خذٍبث‬,‫تفحّص‬

Conception et développement d’une plateforme « HEATH CHECK » pour les services

de TUNISIANA

Résumé :
Ce projet consiste à développer une application informatique permettant d’informatiser et
d’automatiser les tests manuels entrepris par l’équipe IP/MPLS pour vérifier la disponibilité
des services de TUNISIANA. Cette application permettra de gérer (ajouter, modifier,
supprimer) les switchs d’accès aux services ainsi que les paramètres des services de
TUNISIANA. Elle a aussi pour vocation, de tester les services ce qui revient à tester la
connectivité des switchs et des VLANs correspondants. Enfin cette application permettra
d’assurer un service de Backup en sauvegardant les fichiers de configuration des différents
switchs d’accès. Un service de géo-localisation des switchs est prévu aussi.

Mots-clés : Check, Services, Switch, Automatisation, Backup

Design and development of a platform "HEATH CHECK" for services of TUNISIANA

Abstract:
This project consists of developing an informatics application used to computerize and
automate manual testing undertaken by the team IP / MPLS to check availability of services
of TUNISIANA.
This application will manage (add, edit, delete) the switches of access to services and
parameters of services of TUNISIANA. It also aims to test services which amount to test the
connectivity of switches and VLANs corresponding. Finally, this application will ensure a
service of Backup by saving the configuration files for different access switches. A service of
geolocation of switches is also provided.

Key Word: Check, Services, Switchs, Automation, Backup

Intitule et adresse complète de l’entreprise :

Entreprise : TUNISIANA
Adresse : Les Jardins du Lac 1053, Les Berges du Lac, Tunis
Tél. : (+216) 22 12 00 00
Fax : (+216) 22 12 17 09
Email : [Link]