Pfe2015 150523115205 Lva1 App6891

Facult des sciences juridiques conomiques et de gestion Jendouba
TABLE DES MATIERES

INTRODUCTION GENERALE....................................................................................
CHAPITRE 1 : ETUDE PRELIMINAIRE.......................................................................
I.
INTRODUCTION............................................................................................
II.
CADRE ET CONTEXTE DE PROJET................................................................

1.
PRESENTATION DE LORGANISME DACCEUIL.............................................
1.1
CRATION...............................................................................................
1.2
DOMAINE DACTIVIT DE TUNISIE TLCOM...........................................
1.3
HISTORIQUE............................................................................................
1.4
ORGANISATION.......................................................................................
2.
III.
ARCHITECTURE RSEAU DE TUNISIE TELECOM...........................................

ETUDE ET CRETIQUE DE LEXISTANT..........................................................
1.
TUDE DE LEXISTANT...............................................................................
2.
CRITIQUE DE LEXISTANT...........................................................................
3.
SOLUTION PROPOSEE.................................................................................
IV.
CHOIX METHODOLOGIQUE.........................................................................
1.
LE MODELE EN CASCADE...........................................................................
2.
LE MODELE EN V........................................................................................
Page 1
Fsjegj Tunisie Telecom
Anne universitaire 20142015
3.
LE MODELE PAR INCREMENT......................................................................
4.
LE PROCESSUS UNIFIE UP...........................................................................
5.
MODELE EN SPIRALE................................................................................
6.
DECISION DE CHOIX DE METHODOLOGIE..................................................
V.
CONCLUSION...........................................................................................
CHAPITRE 2 : SPCIFICATION DES BESOINS...........................................................

I.
INTRODUCTION..........................................................................................
II.
ADMINISTRATION ET ARCHETECTURE......................................................
1.
PRINCIPE DADMINISTRATION..................................................................
2.
ARCHITECTURE DADMINISTRATION........................................................
III.
IDENTIFICATION DES BESOINS..................................................................
1.
LES BESOINS FONCTIONNELS...................................................................
2.
LES BESOINS NON FONCTIONNEL.............................................................
IV.
LANGUAGE DE MODELISATION................................................................
V.
CONCLUSION...........................................................................................
CHAPITRE 3 : ETUDE CONCEPTUELLE...................................................................

I.
INTRODUCTION..........................................................................................
II.
IDENTIFICATION DES CAS DUTILISATION.................................................

1.
IDENTIFICATION DES ACTEURS.................................................................
Page 2
2.
CAS D'UTILISATION GESTION DES COMPTES .........................................
3.
CAS D'UTILISATION GESTION DU SYSTME ...........................................
III.
DIAGRAMME DE SEQUENCE.....................................................................
1.
DEFINITIONS............................................................................................
2.
DIAGRAMME DE SQUENCE AUTHENTIFICATION ..................................
3.
DIAGRAMME DE SEQUENCE GESTION DU COMPTES...............................
4.
DIAGRAMME DE SEQUENCE GESTION DE PANNES ................................
5.
DIAGRAMME DE SEQUENCE GESTION DE PERFERMANCE .....................
IV.
DIAGRAMME DE CLASSE..........................................................................
1.
DFINITIONS............................................................................................
2.
DIAGRAMME DE CLASSE GLOBALE..........................................................
3.
EXPLICATION DU DIAGRAMME DE CLASSE...............................................
V.
CONCLUSION...........................................................................................
CHAPITRE 4 : REALISATION..................................................................................
I.
INTRODUCTION..........................................................................................
II.
ENVIRONNEMENT DE DEVELOPPEMENT...................................................
1.
PRSENTATION........................................................................................
2.
BRVE PRSENTATION DU PROTOCOLE SNMP...........................................
3.
CHOIX DU LANGAGE DE PROGRAMMATION JAVA :.....................................
Page 3
III.
IMPLEMENTATION....................................................................................
IV.
CONCLUSION...........................................................................................
CONCLUSION GNRALE.....................................................................................
BIBLIOGRAPHIE...................................................................................................
LISTE DES FIGURES

FIGURE 1 : ORGANIGRAMME DE L'AGENCE TUNISIE TELECOM
JENDOUBA............................................................................................................
FIGURE 2: ARCHITECTURE RSEAU DE TUNISIE TELECOM.......................................
FIGURE 3: LE MODLE EN CASCADE....................................................................
FIGURE 4: LE MODLE EN V....................................................................................
FIGURE 5: LE MODLE PAR INCRMENT..................................................................
FIGURE 6: LE CYCLE DE VIE D'UN PROCESSUS.......................................................
FIGURE 7: MODLE EN SPIRALE............................................................................
Page 4
FIGURE 8: PROCESSUS AGENT/GRANT.................................................................

FIGURE 9: GESTION DES PANNES.......................................................................
FIGURE 10: GESTION DE PERFORMANCE...............................................................
FIGURE 11: DIAGRAMME DE CAS D'UTILISATION GESTION DES
COMPTES ..........................................................................................................
FIGURE 12: DIAGRAMME DE CAS D'UTILISATION GESTION DU SYSTME
.........................................................................................................................
FIGURE 13: DIAGRAMME DE SQUENCE AUTHENTIFICATION ............................
FIGURE 14: DIAGRAMME DE SQUENCE GESTION DES COMPTES .......................
FIGURE 15: DIAGRAMME DE SQUENCE CAS DES PANNES .................................
FIGURE 16: DIAGRAMME DE SQUENCE GESTION DE PERFORMANCE
...........................................................................................................................
FIGURE 17: DIAGRAMME DE CLASSE PRINCIPALE..................................................
FIGURE 18: LES MESAGES SNMP...........................................................................
FIGURE 19: SEIGLE DE LANGUAGE DE PROGRAMMATION JAVA..............................
FIGURE 20 BIBLIOTHQUES UTILISS JAVA (.JAR)..................................................
FIGURE 21: FENTRE D'AUTHENTIFICATION..........................................................
Page 5
FIGURE 22: FENTRE PRINCIPALE AVANT LE BALAYAGE........................................

FIGURE 23: FENTRE PRINCIPALE APRS LE BALAYAGE.........................................
FIGURE 24: FENTRE DE LISTE DE ROUTEURS.......................................................
FIGURE 25 : LISTE DES COMMUTATEURS...............................................................
FIGURE 26: LISTE DES SERVEURS..........................................................................
FIGURE 27: FENTRE DE LISTE DES PANNES AVANT LE BALAYAGE.........................
FIGURE 28: FENTRE LISTE DES PANNES APRS LE BALAYAGE..............................
FIGURE 29: FENTRE DE MESURE DE PERFORMANCE DES ROUTEURS....................
FIGURE 30: FENTRE DE MESURE DE PERFORMANCE DES SERVEURS.....................
FIGURE 31: RAPPORT DES ROUTEURS....................................................................
FIGURE 32: RAPPORT DES COMMUTATEURS..........................................................
FIGURE 33: RAPPORT DES SERVEURS....................................................................
FIGURE 34: FENTRE DE GESTION DES QUIPEMENTS...........................................
FIGURE 35: FENTRE GESTION DE COMPTES.........................................................
FIGURE 36: FENTRE DE GESTION DE NOTIFICATION.............................................
FIGURE 37: NOTIFICATION APRS LE BALAYAGE...................................................
Page 6
FIGURE 38: FENTRE DE SCAN DE PORT................................................................
Page 7
LISTE DES ABREVIATIONS
Dans cette page on va citer tous les abrviations dans notre rapport avec leurs significations :
SNMP : Simple Network Management Protocol

MIB
: Management Information Base
IP
: Information Protocol
TCP
: Transmission Control Protocol
UDP
: User Data gram Protocol

Page 8
ICMP : Internet Control Message Protocol

PDU
: Protocol Data Unit
OID
: Object Identifier
ISO
: International Standard Organization
RFC
: Request for Comment
UML
: Unified Modeling Language
CCA
: Centre de Communication Automatique
LGD
: Ligne Grande Distance
Page 9
INTRODUCTION GENERALE
Les rseaux informatiques, sont des lments essentiels des technologies actuelles des
transmissions des donnes entre sites loigns, leur traitement et leur restitution, touchent de
plus en plus notre vie courant. On compte sur les services offerts par les rseaux pour
transactions bancaire, les recherches web, la tlconfrence, etc. ces services sont de ce fait
devenus indispensable. Pour s'assurer que les services rendus par les rseaux soient
convenable, il est ncessaire de surveiller et d'agir quand une erreur se produit. Pour ce faire,
il faut obtenir les donnes de gestion des quipements des rseaux et, si ncessaire, contrler
ces quipements d'o l'utilit de recourir aux outils de supervision des rseaux.
Ce projet a t ralis dans le cadre de la mise en place d'un outil d'administration rseau de
Groupe Tunisie Telecom de Jendouba. Il consiste concevoir et mise en place un systme de
supervision rseaux qui permettent la fois de collecter des donnes sur les routeurs, les
serveurs et les commutateurs, afficher une cartographie de rseaux, et notifier en cas de
panne d'un quipement.
Il existe dj un grand nombre d'outil et des plates-formes sur le march conus pour
l'administration de grands rseaux locaux et distants. Ils sont prvus pour grer un grand
nombre d'quipement et supportent le protocole standard d'administration rseau SNMP
Cependant la majorit des outils d'administration existant sont des systmes propritaires
limites du point de vue portabilit sans oublier aussi leurs couts trs lves.
Pour remdier ces problmes, les responsables informatiques de lagence de Jendouba
m'ont propos de raliser un outil d'observation et de contrle rseau qui s'adapte avec la
topologie a du rseau existant et avec les applications qui tournent sur ce rseau.
Le prsent document est structure en quatre chapitres.
Dans le premier chapitre nous avons fait une tude prliminaire. Tout dabord nous
prsentons lorganisme daccueil avec leur Larchitecture rseau de lentreprise.
Dans le deuxime chapitre nous avons prcis une spcification des besoins.
Le troisime chapitre est consacr ltude conceptuelle de notre application
Le quatrime chapitre dcrit limplmentation et les tests de notre outil.
Page 1
Nous conclusions ce document en prsentant les avantages apporte par notre application
ralis
Le protocole SNMP est dcrit dans l'annexe de ce document.
ETUDE PRELIMINAIRE
Objectif de chapitre : ce chapitre consacre ltude prliminaire. Tout dabord nous prsentons
lorganisme daccueil avec leur Larchitecture rseau de lentreprise
Page 2
CHAPITRE 1 : ETUDE PRELIMINAIRE
I. INTRODUCTION
Ce chapitre dcrit le projet de fin dtude intitule conception et Implmentation d'une
application dadministration de rseau bas sur le protocole SNMP [1].il est divise en deux
parties. La premire est consacre la mise en cadre de notre projet. Dans la deuxime
partie, on va parler sur les diffrentes mthodes de conception aussi le choix de
mthodologie utilis pour dvelopper ce projet.
II. CADRE ET CONTEXTE DE PROJET

1. PRESENTATION DE LORGANISME DACCEUIL
1.1 CRATION
La Socit Nationale des Tlcommunications, socit anonyme dont le capital est de mille
quatre cent millions de dinars, inscrite au registre de commerce sous le numro B646-1995
ayant le matricule fiscal N 425665 XAM000, ayant son sige social la rue du japon
Montplaisir , 1073 Tunis, au nom de son reprsentant lgal. Ci-aprs dnommer Tunisie
Telecom
Page 3
1.2 DOMAINE DACTIVIT DE TUNISIE TLCOM

Depuis sa cration, Tunisie Telecom uvre consolider linfrastructure des tlcoms en
Tunisie, amliorer le taux de couverture et renforcer sa comptitivit. Elle contribue
galement activement la promotion de lusage des TIC et au dveloppement des socits
innovantes dans le domaine des tlcoms. Tunisie Telecom compte dans ses rangs plus de 6
millions abonns dans la tlphonie fixe et mobile, en Tunisie et ltranger. Elle joue en
outre un rle important dans lamlioration du taux de pntration de lInternet en Tunisie, ce
qui lui a permis datteindre le nombre 140 mille abonns la toile la fin du mois davril
2008 [Tunisie Tlcom, 2008]. Au niveau du march local, Tunisie Tlcom a su tirer profit
de la concurrence accrue aprs lentre en service du premier oprateur GSM priv, pour
dvelopper davantage ses services et ses produits.
Il importe de souligner que lactivit de Tunisie Tlcom ne se limite pas uniquement aux
services de la tlphonie fixe et mobile. Elle englobe, galement, linstallation, lentretien et
lexploitation des rseaux publics de tlcommunications, la contribution au dveloppement
des tudes et recherches scientifiques lies au secteur, et la promotion de la coopration
tous les niveaux dans tous les branches du secteur.
Outre que son activit lchelle nationale ,Tunisie Tlcom sest oriente vers lexportation
de son savoir pour le dveloppement des rseaux et de nouveaux services dans certains
marchs mergents, notamment, celui de la Mauritanie o mis en place, exploit et
commercialis le premier rseau GSM aprs la cration de loprateur Mattel en
collaboration avec le secteur priv mauritanien. La socit a conclu, ces dernires annes,
une convention de coopration technique avec Djibouti Tlcom pour le dveloppement de
ses rseaux de tlcommunications, et dispose aussi de certains accords de partenariat avec
des oprateurs de renomme internationale linstar de Thuraya.
Page 4
1.3 HISTORIQUE
Loffice national des tlcommunications est cr suite la promulgation de la loi N36 du
17 avril 1995. Loffice a ensuite chang de statut juridique, en vertu du dcret N30 du 5
avril 2004, pour devenir une socit anonyme dnomme Tunisie Telecom .
En juillet 2006, il a t procd louverture du capital de Tunisie Telecom hauteur de 35%
en faveur du consortium mirati TeCom-DIG. Cette opration vise amliorer les 4
rentabilits de Tunisie Telecom et lui permettre de se hisser parmi les grands oprateurs
internationaux.
Les tapes cls de lvolution de la socit :

17 Avril 1995 : Promulgation de la loi N36 portant cration de l'Office National des
Tlcommunications, dnomm Tunisie Tlcom.
1er Janvier 1996 : Mise en place de lOffice National des Tlcommunications.
20 Mars 1998 : Inauguration de la premire ligne GSM par Monsieur le Prsident de la
Rpublique.
Dcembre 1999 : Promulgation du dcret N2844 du 27 dcembre 1999, relatif au statut de
Tunisie Tlcom.
17 Mai 2000 : Attribution de la premire licence de tlphonie mobile en Mauritanie au
consortium Mattel (dtenue 51% par Tunisie Tlcom).
Fin 2002 : Restructuration de Tunisie Tlcom en Socit Anonyme.
07 Juillet 2004 : Signature de la convention d'interconnexion entre Tunisie Tlcom et
Orascom Tlcom Tunisie
09 Juillet 2004 : Premier Conseil d'Administration de la Socit Nationale des
tlcommunications suite la transformation de Tunisie Tlcom en Socit
Anonyme.
27 Avril 2006 Telecom Duba partenaire stratgique de Tunisie Tlcom
Page 5
1.4 ORGANISATION
Tunisie Telecom se compose de 24 directions rgionales, de 80 Actels et points de vente et
de plus de 13 mille points de vente privs. Elle emploie plus de 8000 agents. Loprateur
historique dispose, galement, de six centres dassistance la clientle de la tlphonie fixe,
mobile et data. Tunisie Tlcom a une direction nomme Direction centrale des oprations
des rseaux NOC qui est li directement au PDG de la socit linverse dautres
directions. Cette direction a pour rle de grer tous types doprations directes effectues sur
les rseaux. La sous-direction dans laquelle nous faisons notre projet est intitule
subdivision de programmation . Cette subdivision sintresse la gestion des plateformes
de rseau et de contrle.
Page 6
FIGURE 1 : ORGANIGRAMME DE L'AGENCE TUNISIE TELECOM JENDOUBA
En interprtant cet organigramme, nous constatons que quatre subdivisions sont supervises
hirarchiquement par le Directeur Gnral. Parmi ces quatre on cite la subdivision des
rseaux qui drive en deux autres subdivisions : subdivision des projets, commutation
transmission.
1.5 DONNES FINANCIERE
Selon les nouvelles statistiques de lanne 2015 la socit Tunisie Telecom a comme capital
875 millions d'euros et son chiffre d'affaires, en 2004, de 750 millions d'euros. Son chiffre
d'affaires en 2008 est de 884 millions de dinars.
Page 7
2. ARCHITECTURE RSEAU DE TUNISIE TELECOM
FIGURE 2: ARCHITECTURE RSEAU DE TUNISIE TELECOM
III.
ETUDE ET CRETIQUE DE LEXISTANT
1. TUDE DE LEXISTANT
La socit Tunisie Telecom pour grer le rseau, les administrateurs rseau utilisent quelques
applications comme netsight et Nagios quelles permet la surveillance systme et rseau.
Elles surveillent les htes et service spcifis, alertant lorsque les systmes ont des
dysfonctionnements et quand ils repassent en fonctionnement normale.
2. CRITIQUE DE LEXISTANT
Ce type des applications ont des soucis fatale et des point ngatives comme :
Linterface complexe et pas trs intuitive.

Page 8
Trs Cher.
Une difficult de dtecter ou se localise lerreur.
Intervention long tend vers la panne.
Le cout lev de ces types des outils.
Une difficult de consulter ltat des quipements.
La mesure de performance est nglige.
3. SOLUTION PROPOSEE
En se basant sur le prcdent Critique, nous avons lenvie de proposer notre solution optimal
et facile utiliser spcialement, pour la gestion des serveurs, routeurs, commutateurs, et
monitoring de a ces quipements, En premier lieu
Et doffrir la possibilit de devenir proactif face aux problmes rencontrs en second lieu.
Finalement et le plus important, de pouvoir dtecter et dinterprter en un simple coup dil
les cause et origines des problmes rencontres afin de les fixer le plus rapidement possible.
Pour cela on va concevoir et mettre en place un outil dadministration et supervision
rseau.
Se souciant de sa rputation et concern par la satisfaction et le confort de ses clients la
socit veut tout prix viter la confrontation des clients mcontents. Notre plateforme
nous permet danticiper les pannes et viter les arrts de longue dure cest la raction bref
tend vers les soucis.
IV.CHOIX METHODOLOGIQUE
Nous prsentons, dans cette les mthodes de conception les plus cites dans la littrature de
plus on va choisir une qui sera suivi tout au long de notre projet.
Page 9
1. LE MODELE EN CASCADE
Le modle de cycle de vie en cascade a t mis au point ds 1966, puis formalis aux
alentours de 1970.
Il dfinit des phases squentielles l'issue de chacune desquelles des documents sont
Produits pour en vrifier la conformit avant de passer la suivante (symbolises dans le
schma par des flches vers le haut) :
FIGURE 3: LE MODLE EN
du cycle de vie en cascade :

Linaire, flot descendant
Retour limit une phase en amont
Validation des phases par des revues
Enchanement depuis le cahier des charges jusqu la ralisation
Bien adapt lorsque les besoins sont clairement identifis et stables
Page 10
Caractristiques
2. LE MODELE EN V
Le modle du cycle en V a t imagin pour pallier le problme de ractivit du modle en
cascade.
Ce modle est une amlioration du modle en cascade qui permet en cas d'anomalie, de
limiter un retour aux tapes prcdentes.
Les phases de la partie montante doivent renvoyer de l'information sur les phases en vis-vis lorsque des dfauts sont dtects afin d'amliorer le logiciel.
De plus le cycle en V met en vidence la ncessit d'anticiper et de prparer dans les tapes
descendantes les attendus des futures tapes montantes : ainsi les attendus des tests de
validation sont dfinis lors des spcifications, les attendus des tests unitaires sont dfinis lors
de la conception, etc.
Page 11
FIGURE 4: LE MODLE EN V
3. LE MODELE PAR INCREMENT

Limage n'affiche que deux incrmentation, mais il peut y en avoir plusieurs.
Le dveloppement est ainsi moins complexe, l'intgration est moins brutale et le client a plus
rapidement un systme mme s'il n'est pas complet. Par contre, le cur du systme peut tre
revoir lorsque on passe une autre incrmentation du systme .il peut aussi s'avrer
complexe d'ajouter certaines fonctionnalits.
Page 12
FIGURE 5: LE MODLE PAR INCRMENT
4. LE PROCESSUS UNIFIE UP
Le processus unifi est un processus de dveloppement logiciel itratif, centr sur
l'architecture, pilote par des cas d'utilisation et orient vers la diminution des risques.
Cest un patron de processus pouvant tre adapt une large classe de systme logiciels,
diffrent domaines dapplication, diffrent types d'entreprises, diffrent niveaux de
comptences et diffrent tailles de l'entreprise.
UP permet de grer le processus de dveloppement par deux axes :
- Laxe vertical : Reprsente les principaux enchainements d'activits, qui regroupent les
activits, selon leur nature. Cette dimension rend compte l'aspect statique du processus qui
s'exprime en termes de composant, de processus, dactivits, denchainements, d'artefacts et
de travailleurs.
Page 13
- Laxe horizontal : reprsente le temps et montre le droulement du cycle de vie du

processus ; cette dimension rend compte de l'aspect dynamique du processus qui s'exprime
en terme de cycles, de phases, d'itration et de jalons.
FIGURE 6: LE CYCLE DE VIE D'UN PROCESSUS
5. MODELE EN SPIRALE
Le modle en spirale (spiral model) est un modle de cycle de dveloppement logiciel qui
reprend les diffrentes tapes du cycle en V. Par l'implmentation de versions successives, le
cycle recommence, En proposant un produit de plus en plus complet et dur.
Le cycle en spirale met cependant plus, laccent sur la gestion des risques que le cycle en V.
Le modle en spirale a t dfini par Barry Boehm en 1988 dans son article "A Spiral Model
of Software Development and Enchantement"
Principe de Cycle en spirale
Page 14
On distingue quatre phases dans le droulement du cycle en spirale
Dtermination des objectifs, des alternatives et des contraintes

Analyse se des risques, valuation des alternatives
Dveloppement et vrification de la solution retenue
Revue des rsultats et vrification du cycle suivant.
FIGURE 7: MODLE EN SPIRALE
Page 15
6. DECISION DE CHOIX DE METHODOLOGIE

Jai choisi comme mthodologie le modle en cascade car c'est le modle le plus pratique et
le plus utilis dans le domaine de dveloppement logiciel.
Ce modle a comme avantages :
Le montant des processus ncessaire pour mettre en uvre les modles est minime.
Inutile de mentionner : il s'agit d'un modle linaire et bien sur les modles linaires sont les
plus simple mettre en uvre.
V. CONCLUSION
Ce chapitre nous permet de comprendre les notions lies notre travail pour passer en
dlicatesse au deuxime chapitre pour dterminer les besoins fonctionnels et non
fonctionnels de notre plateforme.
Page 16
Spcification des
besoins
Objectif de chapitre : Dans ce chapitre, nous allons prsenter les spcifications de notre
solution
d'administration
rseau.
Nous
commencerons
par
le
principe
d'administration en suite et nous terminerons par l'identification des besoins
Page 17
gnral
CHAPITRE 2 : SPCIFICATION DES BESOINS
I INTRODUCTION
Dans ce chapitre, nous allons prsenter les spcifications de notre solution d'administration
rseau. Nous commencerons par le principe gnral d'administration en suite et nous
terminerons par l'identification des besoins.
VI.
ADMINISTRATION ET ARCHETECTURE
1. PRINCIPE DADMINISTRATION
Sur le point de ladministration
[2]
, un systme de rseau informatique se compose d'un
ensemble d'objets qu'un systme d'administration surveille et contrle. Chaque objet est gr
localement par un processus appel agent qui transmet rgulirement ou sur sollicitation les
informations de gestion relatives son tat et aux vnements qui le concernent au systme
dadministration.
Page 18
Le systme d'administration comprend un processus (manager ou grant) qui peut accder

aux informations de gestion de la MIB [3] locale via un protocole d'administration qui le met
en relation avec les divers agents.
Le principe se repose donc sur les changes :
D'une part, entre une base d'informations appele MIB (Management Information Base) et
l'ensemble des lments administrs (objets) ;

D'autre part, entre les lments administrs et le systme d'administration.
FIGURE 8: PROCESSUS AGENT/GRANT
2. ARCHITECTURE DADMINISTRATION
L'architecture classique d'administration la plus utilise est le modle Grant/ Agent
(Manager/Agent).comme nous l'avons montr dans le principe d'administration.
Le systme est Compos d'une entit d'administration et des entits de gestion (NME) qui
sont gr par cette entit et un protocole pour la gestion
Page 19
Chaque entit dans le rseau a un Agent pour l'opration de gestion, une base de donnes
stockes dans MIB et assume les travaux ci-dessous :
- Collecter des informations statistiques concernant la communication, les oprations de
rseau.
- Stocker les informations localement dans les MIBs.
- Rpondre les commandes de l'entit de contrle de rseau, inclus : Transmet des
informations statistiques l'entit d'administration de rseau, modifie les paramtres, donne
des informations d'tat...
VII. IDENTIFICATION DES BESOINS

Les besoins d'utilisation de l'application sont repartis en besoins fonctionnels et en besoins
non fonctionnels.
1. LES BESOINS FONCTIONNELS

Les besoins fonctionnels incluent le module gestion de l'application, module de supervision
des quipements, module de gestion des faute, module de gestion de la performance et en fin
module de gnrations des rapports et journalisations (historique).
1.1. MODULE DE GESTION DAPPLICATION

Le module de gestion d'application est forme par deux sous modules principaux qui sont :
- Authentification auprs de l'interface : ce module permet l'administrateur de scurit
de ce connect l'interface en introduisant le login et son mot de passe. Ce module va
Page 20
chercher dans la base des donnes le login et le mot de passe entres, s'il y a correspondance
alors ouverture de session de sinon un message d'erreur afficher.
- Gestion d'utilisateurs : Ce module permet d'ajouter, modifier et supprimer d'un autre
administrateur.
Remarque : Impossible de supprimer un administrateur si le seul qui existe dans la base.
1.2. MODULE DE SUPERVISION DES EQUIPEMENTS
Ce module est form par trois sous modules principaux qui sont :
- Gestions des quipements : Ce module permet d'ajouter ou supprimer un quipement
(routeur, serveur ou commutateur) pour superviser l'ajout se fait simplement d'ajout l'adresse
de l'quipement dans la base des donnes et la mme pour la suppression.
- Contrle des quipements : Ce module permet de contrler si les quipements sont en
marche ou non (UP, DOWN) et collecter les informations de chaque quipement en utilisant
le protocole SNMP.
- Scanner les ports d'quipements : Ce module permet de scanner les ports de chaque
quipement en entrant son adresse. Il y a deux choix de scan d'un seul port prcis ou d'une
plage des ports.
1.3. MODULE DE GESTION DES PANNES
Ce domaine recouvre la dtection, l'isolement et la correction des pannes survenant sur un
quipement. L'action curative qui en dcoule peut tre faite distance (si l'quipement
rpond) ou par un contact humain qui agira sur l'quipement. Un historique des vnements
est galement disponible
Page 21
Type de panne : Les pannes peuvent tre d'origine interne, caractre permanent
(composant en pannes) ou externes (goulets d'tranglement, trafic intense, etc.), Cette
FIGURE 9: GESTION DES PANNES
dernire est plus difficile dtecter, car elle est caractre alatoire.
La gestion de faute couvre l'ensemble des fonctionnalits suivantes :
La dtection des fautes : elle comprend la prparation de rapports d'incidents de

fonctionnement, la gestion de compteurs ou des seuils d'alarme, le filtrage d'vnements par
filtrage en amont des informations, l'affichage des dysfonctionnements.

La localisation : on y procde au moyen de rapports d'alarme, de mesures et de tests.
La rparation : elle consiste prendre les mesures correctives (raffectation de ressources,
routages, limitation du trafic par filtrage, maintenance), ou encore rtablir le service (tests
de fonctionnement, gestion de systmes de secours, etc.).

L'enregistrement des historiques d'incidents et statistiques : la gestion des fautes ne peut se
limiter ces actions ponctuelles, ncessaires mais insuffisantes pour donner le service
attendu. C'est la raison pour laquelle elle comporte aussi, d'une part, l'enregistrement
d'historiques d'incidents et la compilation de statistiques qui peuvent porter sur la probabilit
des pannes, leur dure, les dlais de rparation et, d'autre part, un rle d'interface avec les
usagers qui consiste les informer des problmes rseau et leur donner la possibilit de
signaler eux-mmes des incidents telle que :

La dconnexion d'un cble ;
Page 22
Une mauvaise configuration d'un quipement ;

Une interface dfectueuse d'un routeur.
La rinitialisation accidentelle.
1.4. MODULE DE GESTION DE PERFERMANCE

Ce domaine comprend la collecte des donnes et l'analyse statistique permettant la cration
de tableaux de bord. Ce domaine est essentiellement li l'volution du rseau (permet de
planifier les changements apporter afin d'amliorer les performances du rseau).
FIGURE 10: GESTION DE PERFORMANCE
L'objectif est d'tablir des statistiques partir des paramtres du rseau.
Dbit
Temps de rponse
Taux d'erreur
Temps d'tablissement des connexions
Page 23
Elle fournit des fonctions qui permettent des fins de planification des ressources du rseau :
De recueillir des donnes statistiques (taux d'erreurs, temps de transit, dbit, etc.),
De maintenir et analyser des journaux sur l'historique de l'tat du systme (vnements). Les
informations obtenues serviront l'analyse et la planification du rseau. On peut diviser
cette partie en deux : l'une traitant de la gestion de la performance en temps rel et l'autre en
temps diffr. Pour grer la performance d'un rseau en temps rel, il faut mettre en place la
fonction suivante :
Enregistrements des mesures de performance : cela passe par l'tablissement et la mise jour
des critres et des conditions de mesure, la gestion de la collecte d'informations, le filtrage,
la compilation de statistiques, l'adoption de mesures la demande ou encore la gestion des
fichiers de collecte.
1.5. MODULE DE GENERATIONS DES RAPPORTS

Notre application permet de gnrer des rapports de chaque quipement qui dcrit tous ses
informations et aussi gnre des rapports des pannes.
Et permet d'enregistrer chaque trace d'administrateur dans un historique.
2. LES BESOINS NON FONCTIONNEL

Ce sont des exigences qui ne concernent pas spcifiquement le comportement du systme
mais plutt identifient des contraintes internes et externes du systme.
Les principaux besoins non fonctionnels de notre application ce rsument dans les points
suivants :
Le code doit tre clair pour permettre des futures volutions ou amliorations
Page 24
L'ergonomie : l'application offre une interface conviviale et facile utiliser
La scurit : l'application doit respecter la confidentialit des donnes
Garantir l'intgrit et la cohrence des donnes chaque mise jour et chaque insertion.
II LANGUAGE DE MODELISATION
UML (Unified Modeling Language), se dfinit comme un langage de modlisation graphique
et textuel destin comprendre et dfinir des besoins, spcifier et documenter des
systmes, esquisser des architectures logicielles, concevoir des solutions et communiquer des
points de vue. UML modlise l'ensemble des donnes et des traitements en laborant des
diffrents diagrammes. En clair, il ne faut pas designer UML en tant que mthode mais plutt
comme une boite d'outils qui sert amliorer les mthodes de travail.
VIII. CONCLUSION
Ce chapitre nous a permis de prsenter le principe gnral d'administration rseau
et d'identifier les besoins fonctionnels et non fonctionnels de notre systme. Le chapitre
suivant sera consacr spcification et la conception de l'outil d'administration rseau.
Page 25
Page 26
tude Conceptuelle
Objectif de chapitre : Dans ce chapitre, nous allons modliser notre application en utilisant
un langage de modlisation objet qui est UML. La conception de notre application se base
sur les diagrammes des cas d'utilisation(les acteurs, procdures d'administrateur), les
diagrammes de classes et les diagrammes de squences
Page 27
CHAPITRE 3 : ETUDE CONCEPTUELLE
I INTRODUCTION
Dans ce chapitre, nous allons modliser notre application en utilisant un langage de
modlisation objet qui est lUML. La conception de notre application se base sur les
diagrammes des cas d'utilisation(les acteurs, procdures d'administrateur), les diagrammes de
classes et les diagrammes de squences
II IDENTIFICATION DES CAS DUTILISATION

Le travail effectu au sein de cette partie permet d'identifier les acteurs mis en jeu et de
visualiser les scnarios de cas d'utilisation de notre application qui permettent de bien
superviser une machine.
Ce diagramme est destin reprsenter les besoins des utilisateurs par rapport au systme. Il
constitue un des diagrammes les plus structurants dans l'analyse d'un systme.
1. IDENTIFICATION DES ACTEURS

-
Acteur : Reprsente un rle jou par une entit externe (utilisateur humain, dispositif
matriel ou autre systme) qui interagit directement avec le systme tudi.
Les acteurs qui interagissent avec cette application sont les suivants :
Administrateur : dsigne la personne responsable de la politique de scurit et de son

application par la surveillance et l'administration.
Page 28
Le systme (Superviseur) : dsigne l'entit qui s'occupe du contrle d'une entit, de la

dtection des pannes et de l'envoi des notifications et l'administrateur.
Scnario des cas d'utilisation :
Reprsente un ensemble des squences d'actions qui sont ralises par les acteurs et qui
produisent un rsultat observable intressant pour un acteur particulier.
2. CAS D'UTILISATION GESTION DES COMPTES
Page 29
FIGURE 11: DIAGRAMME DE CAS D'UTILISATION GESTION DES COMPTES
Seul l'administrateur rseau (super administrateur) peut crer, modifier, ajouter, et supprimer
un compte et un mot de passe. Les comptes et les mots passe valides sont initialises et
enregistres par l'administrateur rseau (super administrateur).
Page 30
3. CAS D'UTILISATION GESTION DU SYSTME
Page 31
Page 32
FIGURE 12: DIAGRAMME DE CAS D'UTILISATION GESTION DU SYSTME
La figure 12 nous permet de savoir les diffrents droit de l'administrateur rseau :

l'administrateur rseau doit s'authentifier pour qu'il puisse consulter la liste des
routeurs (ouvert ou ferme) ,des serveurs (ouvert ou ferme) et des commutateurs (ouvert ou
ferme) disponible dans l'architecture rseau il peut aussi scanner les diffrents ports (ouvert
ou ferme) et de consulter la performance du rseau (dbit, vitesse ...)
La gestion des alertes et des notifications, et la production des rapports sont prsent par
notre moniteur rseau.
IX.
DIAGRAMME DE SEQUENCE
1. DEFINITIONS
Les diagrammes des squences documentent les interactions mettre en uvre entre les
classes pour raliser un rsultat, tel qu'un cas d'utilisation. UML tant conu pour la
programmation oriente objet, ces communications entre les classes sont reconnues comme
des messages. Le diagramme des squences numre des objets horizontalement, et le temps
verticalement. Il modlise l'excution des diffrents messages en fonction du temps.
Chaque diagramme de squence doit comprendre :
Les acteurs intervenants dans la squence de messages
Une note contenant la description de la squence reprsente (idalement le cas d'utilisation
reprsente)
Les messages envoys entre les entits (ou sur eux-mmes) avec les paramtres pertinents
Les lignes de vie des entits doivent montrer la cration et la destruction lorsque pertinent.
Page 33
Les entits logicielles doivent avoir la bonne reprsentation UML : instance, instance
nomme ou classe.
Le diagramme de squences se base sur les concepts suivants :
Objet : description d'un objet du monde rel (instance de classe). Il peut tre une personne
ou une chose.
Message : Les messages indiquent les communications entre les objets.
Message rflexif : un objet peut envoyer lui-mme : c'est un message rflexif.
Priode d'activit d'objet : Dans certains cas, il reprsent par la priode pendant laquelle
un objet est actif.
Acquittement : En informatique, l'acquittement d'une donne ou d'une information

consiste informer son metteur de sa bonne rception. On utilise souvent le terme ack pour
un acquittement, ce terme correspond l'quivalent anglais du terme : acknowledgement.
2. DIAGRAMME DE SQUENCE AUTHENTIFICATION
Description du scnario
Le systme affiche l'interface d'authentification.

L'utilisateur introduit un login et un mot de passe.
Le system vrifie le login et le mot de passe.
Si les donnes saisies sont correct le systme affiche l'interface de l'application, sinon le
systme demande de rpter la saisie de login et mot de passe
Page 34
FIGURE 13: DIAGRAMME DE SQUENCE AUTHENTIFICATION
3. DIAGRAMME DE SEQUENCE GESTION DU COMPTES
Aprs l'authentification de l'utilisateur le systme affiche l'interface pour l'ajout, suppression

ou la modification des coordonnes d'un utilisateur
L'utilisateur
introduit
les
nouvelles
notifications
(les
coordonnes
d'un
utilisateur ou la modification des coordonnes ou la suppression d'un utilisateur)

- Tout les modifications sont enregistrs dans la base de donn
Page 35
nouvel
FIGURE 14: DIAGRAMME DE SQUENCE GESTION DES COMPTES
4. DIAGRAMME DE SEQUENCE GESTION DE PANNES
Description du scnario :
Page 36
- L'utilisateur demande au systme l'tat de chaque quipement (routeur serveur et

commutateur)
- Le systme scanne le rseau
- En cas de panne le systme produit un rapport d'erreur et envoi ses erreurs l'utilisateur via
des mails ou des SMS.
- Si pas d'erreur il affiche l'tat des quipements.
Page 37
FIGURE 15: DIAGRAMME DE SQUENCE CAS DES PANNES
5. DIAGRAMME DE SEQUENCE GESTION DE PERFERMANCE
- L'utilisateur demande au systme l'tat de chaque quipement (routeur, serveur et

commutateur)

Page 38
- L'utilisateur peut avoir l'tat de chaque quipement

- L'utilisateur demande au systme l'tat des ports
- L'utilisateur peut avoir l'tat de chaque port
- L'utilisateur demande au systme l'tat de performance des quipements
Le systme scanne le rseau pour avoir ltat de performance des quipements
FIGURE 16: DIAGRAMME DE SQUENCE GESTION DE PERFORMANCE
Page 39
X. DIAGRAMME DE CLASSE
1. DFINITIONS
Un diagramme de classes est une collections de modlisations statiques (classes, Package..),
qui montre dun modle.
Association entre classes
Une association exprime une connexion smantique bidirectionnelle entre deux classes.
Lassociation est distanciable dans un diagramme dobjets ou de collaboration, sous forme de
liens entre objets issus de classe associes
Cardinalit
Prcise le nombre dinstance qui participent une relation.
Relation de dpendance
Relation dutilisation unidirectionnelle et dobsolescence (une modification de llment

dont on dpend, peut ncessiter une mise jour de llment dpendant)
Association n-aire
Il sagit dune association qui relie plus de deux classes.

NB : De telles associations sont difficiles dchiffrer et peuvent induire une erreur.
Il vaut mieux limiter leur utilisation, en dfinissant de nouvelles catgories dassociations.
Classe dassociation
Page 40
Il sagit dune classe qui ralise la navigation entre les instances dautres classes.
Page 41
2. DIAGRAMME DE CLASSE GLOBALE
Page 42
Page 43
FIGURE 17: DIAGRAMME DE CLASSE PRINCIPALE
3. EXPLICATION DU DIAGRAMME DE CLASSE
Attribut
Type
Signification
Login
String
Login de ladministrateur
Mot de passe
String
Mot de passe de ladministrateur
Administrateur
Mthode
Grer les comptes ()
Signification
Ajouter, supprimer ou modifier des comptes

administrateurs
Grer les quipements ()
Ajouter ou supprimer un quipement
Grer les notifications ()
Ajouter ladresse mail de Facult pour recevoir les

notifications
Scanner les ports ()
Faire un balayage sur les ports dquipements
Page 44
Config le service SNMP ()
Modifier la communaut et le port de service SNMP
Systme
Attribut
Type
Signification
Nom
String
Nom du systme
Version
String
Version du systme
Mthode
Signification
Superviser les quipements ()
Controller les quipements
Afficher la cartographie ()
Dessiner la cartographie du rseau (UP, DOWN)
Collecter les informations ()
Collecter les informations de chaque quipement
Gnrer des rapports ()
Gnrer des rapports de chaque quipement

Page 45
Envoyer des alertes ()
Envoie des alertes (mail) en cas de panne
quipements
Attribut
Type
Signification
Adresse IP
String
Adresse IP de lquipement
Nom
String
Nom de lquipement
Cartographie
Attribut
Type
Signification
Routeur
Routeurs
Reprsente le routeur sur la carte
Serveur
Serveur
Reprsente le serveur sur la carte
Commutateur
Commutateur
Reprsente le commutateur sur la carte

Page 46

Mail
Attribut
Type
Signification
Adresse mail
String
Correspond le mail de la facult
Mot de passe
String
Correspond le mot de passe du compte
Mthode
Recevoir des notifications
Signification
Enregistrer tous les notifications reus
Page 47
Rapport
Attribut
Type
Signification
Nom
String
Nom du rapport gnrer
Date
Date
Date du rapport publie
Historique
Attribut
Date
Type
Date
Signification
Date de lhistorique
Page 48
Les fonctions SNMP utilises sont :
FIGURE 18: LES MESAGES SNMP
XI.
CONCLUSION
Dans ce chapitre nous avons dcrit les principaux diagrammes, considres les plus
importants et les plus adquats a notre projet. Ces diagrammes sont choisis parmi les neuf
diagrammes de conception UML.
Le chapitre suivant dcrit les deux principales tapes de la ralisation, savoir codage et les
tests.
Page 49
Page 50
Page 51
Ralisatio
Objectif de chapitre : la fin de la construction du systme que nous avons ralis, nous
dans le stade oprationnel. Nous tablissions le modle de test.
Page 52
CHAPITRE 4 : REALISATION
I INTRODUCTION
Lenchainement des activits de test sattache la vrification des rsultats de
limplmentation en testant chaque instruction, aussi bien les constructions internes et
intermdiaires que les versions finales du lapplication. Deux activits peuvent tre
effectues aux niveaux dun test : la vrification. La premire consiste vrifier que rsultat
correspond la spcification et la deuxime consiste vrifier que le rsultat correspond
vraiment ce que voulait lutilisateur.
II ENVIRONNEMENT DE DEVELOPPEMENT
1. PRSENTATION
Nous dcrivons dans ce chapitre l'environnement de travail requis qui est le dveloppement
d'une application rseau utilisant le protocole SNMP.
Pour qu'une application rseau puisse tre mise en uvre, il est ncessaire que les
composants rseaux qui interagissent avec l'application soient bien installes et bien
configures.
En particulier le protocole SNMP qui doit tre installe sur tous les postes clients. Les
composants de l'environnement du travail sont :
- systme d'exploitation : Windows 7 SP 1 Professionnel.
Page 53
- Netbeans 8.0.2, Microsoft office 2013, kit Java runtime 8 Update 40

- Protocoles : SNMP.
- Langage de programmation : JAVA.
2. BRVE PRSENTATION DU PROTOCOLE SNMP

Le protocole SNMP (Simple Network Mangement Protocol) est un protocole, comme son
nom l'indique, qui permet d'assurer la gestion du rseau. Il permet galement de contrler un
rseau distance en interrogeant les stations qui en font partie sur leur tat et configurer leur
configuration, de faire des tests de scurit et observer les diffrentes informations lies
lmission de donnes. Il peut mme tre utilise pour grer les logiciels et bases de donnes
lies distance.
Le protocole SNMP est le protocole le plus adquat notre application, et le plus simple
utiliser.
3. CHOIX DU LANGAGE DE PROGRAMMATION JAVA :
FIGURE 19: SEIGLE DE LANGUAGE DE PROGRAMMATION JAVA
Java est un langage de programmation informatique orient objet cr par James Gosling et
Patrick Naughton de Sun Microsystems. Mais c'est galement un environnement d'excution.
Page 54
Java peut tre spare en deux parties. D'une part, votre programme crit en langage Java et
d'autre part, une machine virtuelle (JVM) qui va se charger de l'excution de votre
programme Java.
C'est cette plateforme qui garantit la portabilit de Java. Il suffit qu'un systme ait une
machine virtuelle Java pour que tout programme crit en Java puisse fonctionner.
Avec le langage Java, vous pouvez dvelopper, des applications Desktop, dvelopper des
applets pour vos sites web, dvelopper des sites en JSP, des applications pour tlphone
mobile. La premire chose faire est bien videmment d'apprendre faire des applications
stadalones simples.
XII. IMPLEMENTATION
Initialement nous avons utilis Netbeans 8.0.2 (Environnement de dveloppement intgr
pour Java, Java EE, Java FX et d'autres langages) pour simplifier de dvelopper les interfaces
de notre application.
Notre application fait appel seize bibliothques .jar et contient galement treize interfaces
graphiques.
Page 55
FIGURE 20 BIBLIOTHQUES UTILISS JAVA (.JAR)
LES TESTS
Fentre principale Network Manager 1.0.1
Page 56
FIGURE 21: FENTRE D'AUTHENTIFICATION
Fentre principale Network Manager 1.0.1
Cest une fentre qui affiche la cartographie du rseau aprs un balayage complet il y a aussi
une barre de progression qui permet de visualiser le pourcentage de balayage de rseau
depuis le lancement de lapplication
Page 57
FIGURE 22: FENTRE PRINCIPALE AVANT LE BALAYAGE
Page 58
FIGURE 23: FENTRE PRINCIPALE APRS LE BALAYAGE
Explication
Dans notre application le balayage du rseau se fait automatiquement chaque 5 minutes

en interrogeant chaque quipement sur le rseau si lagent SNMP installe il envoie une
requte (get_request) au client suivant lOID donn, le client de son tour envoie une
rponse (get_response).
Cest la fentre la plus importante dans notre projet puisquelle visualise
ladministrateur la cartographie des rseaux et toutes les options et les choix quil peut les
faire. Cette fentre contient une partie fixe compose dun menu, dun entte et des
boutons.
Contient aussi une partie dynamique compose dune cartographie.
Page 59
Fentre de liste des routeurs
Cette fentre affiche dans un tableau les listes des routeurs existant dans larchitecture de
rseau en affichant leur statut, nom, adresse IP, nombre dinterface et la temprature.
FIGURE 24: FENTRE DE LISTE DE ROUTEURS
Page 60
Fentre de liste des commutateurs
Cette fentre affiche dans un tableau les listes des routeurs existant dans larchitecture de
rseau en affichant leur statut, nom, adresse IP, nombre dinterface et leur description.
FIGURE 25 : LISTE DES COMMUTATEURS
Fentre de liste des serveurs
Cette fentre affiche dans un tableau les listes desserveurs existant dans larchitecture de
rseau en affichant leur statut, nom, adresse IP, nombre dinterface, leur description et leur
espace mmoire RAM.
Page 61
FIGURE 26: LISTE DES SERVEURS
Fentre de liste des pannes
Cette fentre affiche dans un tableau la liste des pannes au niveau des routeurs, serveur,
commutateur existant dans larchitecture de rseau en affichant type dquipement, leurs
adresse IP et leur nom.
Page 62
FIGURE 27: FENTRE DE LISTE DES PANNES AVANT LE BALAYAGE
Page 63
FIGURE 28: FENTRE LISTE DES PANNES APRS LE BALAYAGE
Fentre de mesure de performance
Cette fentre affiche la mesure de performance pour chaque quipement comme le montre
dans la figure suivante :
Page 64
FIGURE 29: FENTRE DE MESURE DE PERFORMANCE DES ROUTEURS
Page 65
FIGURE 30: FENTRE DE MESURE DE PERFORMANCE DES SERVEURS
Les rapports qui sont gnr par notre lapplication : Notre application gnre trois rapports :
Rapport des routeurs.
Rapport des commutateurs.
Rapport des serveurs.
Rapport des routeurs. Ce rapport contient tous les informations des routeurs existant dans
larchitecture rseau.
Page 66
FIGURE 31: RAPPORT DES ROUTEURS
Page 67
Rapport des commutateurs : Ce rapport contient toutes les informations des

commutateurs existant dans larchitecture rseau :
Page 68
Page 69
FIGURE 32: RAPPORT DES COMMUTATEURS
Rapport des Serveurs : Ce rapport contient toutes les informations des serveurs existant
dans larchitecture rseau.
Page 70
Page 71
FIGURE 33: RAPPORT DES SERVEURS
Fentre Gestion dquipements
FIGURE 34: FENTRE DE GESTION DES QUIPEMENTS
Fentre de gestion des comptes
Cette fentre permet de grer (ajouter, supprimer et modifier) les comptes administrateurs et
permet aussi dafficher la liste dadministrateur.
Page 72
FIGURE 35: FENTRE GESTION DE COMPTES
Page 73
Fentre de configuration des notifications
Cette fentre permet de changer ladresse mail que lapplication va envoyer des notifications
FIGURE 36: FENTRE DE GESTION DE NOTIFICATION
Page 74
FIGURE 37: NOTIFICATION APRS LE BALAYAGE
Fentre de scan des ports
Cette fentre permet de scanner les ports des quipements en entrant les adresse IP, il ya deux
cas de scan :
Scan par un seul port prcis.

Scan la plage des ports
Page 75
FIGURE 38: FENTRE DE SCAN DE PORT
XIII. CONCLUSION
Dans ce chapitre nous avons dcrit les principales images crans de notre application. Ces
images contiennent des tests rels effectues au sein de L'agence de Tunisie Telecom
Jendouba.
Page 76
Nous avons essay de rendre nos programmes les plus claires possibles, pour permettre aux
autres dveloppeurs la mise jour de cette application.
CONCLUSION GNRALE
Il est largement reconnu que l'informatique support et vecteur des transmissions des
connaissances joue un rle trs important dans le secteur de l'information.
A l'instar des autres facteurs de production, l'informatique est un variable facteur de progrs
socio-conomique au service de dveloppement de toute notion. C'est pourquoi il est devenu
impratif majeur pour les pays en dveloppement de maitriser cet outil de savoir en grant de
faon optimale la production, la distribution et la consommation des connaissances pour ne
pas parler du processus habituel de collecte, diffusion et traitement de l'information.
Le rseaux informatique se situe dans cette optique et se veut tre l'outil cohrent
d'intgration et d'exploitation du patrimoine informationnel. Il devra ainsi transcender le
cloisonnement entre administration publique, entreprises prives, universits, laboratoires de
recherche, bibliothques nationales, ... pour devenir un rseau automatise de coordination et
d'changes entre les diverses afin d'tablir des complmentaires et de meilleurs synergies.
Le travail que nous avons ralis la compagnie de Ciment de Bizerte, prsent dans ce
rapport, consiste dvelopper un outil d'administration rseaux, et effectue les objectifs,
proposes par les spcialits rseaux, qui sont les suivants :
Exploitation du rseau (afficher la cartographie du rseau).
Page 77
Mesurer les performances et superviser les changements d'architecture du rseau.
Dtection des pannes.
Notification (mail).
Pour concrtiser ces objectifs nous avons adopt une dmarche simple et claire.
Nous avons suivi les tapes de cette dmarche en dcrivant dans un premier lieu les besoins
satisfaire.
Pour la conception, nous avons la mthode UML. Nous avons construit les trois principaux
diagrammes savoir : le diagramme de cas d'utilisation. Celui de classe, qui permet la fois
de mettre en vidence les besoins spcifies et nous faciliter les taches de programmation.
A la dernier tape du projet, nous avons ralis la majorit des objectifs souhaites en utilisant
un langage puissant de programmation savoir JAVA.
Enfin, nous avons ralis une application (Client-serveur) permettant de superviser et
contrler le rseau de compagnie, mais ce dernier trs couteux de point de vue temps de
processeur, ce qui est une solution non optimale.
Page 78
Page 79
BIBLIOGRAPHIE
LIENS INTERNET
SNMP
[1] http://ram-0000.developpez.com/tutoriels/reseau/SNMP/
Administration Rseau
Page 80
[2] http://www.babafou.eu.org/ensta/b1-4/b1-4.pdf
Les MIBs
[3] http://irp.nain-t.net/doku.php/215snmp:40_les_mibs
HELP
J'ai utilis les MSDN de Netbeans 8.0.2, qui m'ont aid la programmation en
JEE.
Page 81
ANNEXE :
LE PROTOCOLE SNMP
Page 82
Objectif de document : Dans cette annexe on va prsenter le protocole SNMP, le principe de

fonctionnement et les diffrents messages entre les diffrents agents pour bien claircir notre
ide.
Page 83

Pfe2015 150523115205 Lva1 App6891

Încărcat de

Informații document

Titlu original

Drepturi de autor

Formate disponibile

Partajați acest document

Partajați sau inserați document

Opțiuni de partajare

Vi se pare util acest document?

Este necorespunzător acest conținut?

Drepturi de autor:

Formate disponibile

Pfe2015 150523115205 Lva1 App6891

Încărcat de

Drepturi de autor:

Formate disponibile

Facult des sciences juridiques conomiques et de gestion Jendouba

TABLE DES MATIERES

CADRE ET CONTEXTE DE PROJET................................................................

PRESENTATION DE LORGANISME DACCEUIL.............................................

DOMAINE DACTIVIT DE TUNISIE TLCOM...........................................

ARCHITECTURE RSEAU DE TUNISIE TELECOM...........................................

Facult des sciences juridiques conomiques et de gestion Jendouba

LE MODELE PAR INCREMENT......................................................................

LE PROCESSUS UNIFIE UP...........................................................................

DECISION DE CHOIX DE METHODOLOGIE..................................................

CHAPITRE 2 : SPCIFICATION DES BESOINS...........................................................

IDENTIFICATION DES BESOINS..................................................................

LES BESOINS FONCTIONNELS...................................................................

LES BESOINS NON FONCTIONNEL.............................................................

CHAPITRE 3 : ETUDE CONCEPTUELLE...................................................................

IDENTIFICATION DES CAS DUTILISATION.................................................

IDENTIFICATION DES ACTEURS.................................................................

Facult des sciences juridiques conomiques et de gestion Jendouba

CAS D'UTILISATION GESTION DES COMPTES .........................................

CAS D'UTILISATION GESTION DU SYSTME ...........................................

DIAGRAMME DE SQUENCE AUTHENTIFICATION ..................................

DIAGRAMME DE SEQUENCE GESTION DU COMPTES...............................

DIAGRAMME DE SEQUENCE GESTION DE PANNES ................................

DIAGRAMME DE SEQUENCE GESTION DE PERFERMANCE .....................

DIAGRAMME DE CLASSE GLOBALE..........................................................

EXPLICATION DU DIAGRAMME DE CLASSE...............................................

BRVE PRSENTATION DU PROTOCOLE SNMP...........................................

CHOIX DU LANGAGE DE PROGRAMMATION JAVA :.....................................

Facult des sciences juridiques conomiques et de gestion Jendouba

LISTE DES FIGURES

Facult des sciences juridiques conomiques et de gestion Jendouba

FIGURE 8: PROCESSUS AGENT/GRANT.................................................................

Facult des sciences juridiques conomiques et de gestion Jendouba

FIGURE 22: FENTRE PRINCIPALE AVANT LE BALAYAGE........................................

Facult des sciences juridiques conomiques et de gestion Jendouba

FIGURE 38: FENTRE DE SCAN DE PORT................................................................

Facult des sciences juridiques conomiques et de gestion Jendouba

LISTE DES ABREVIATIONS

SNMP : Simple Network Management Protocol

: Management Information Base

: Transmission Control Protocol

: User Data gram Protocol

Facult des sciences juridiques conomiques et de gestion Jendouba

ICMP : Internet Control Message Protocol

: Protocol Data Unit

: International Standard Organization

: Request for Comment

: Unified Modeling Language

: Centre de Communication Automatique

: Ligne Grande Distance

Facult des sciences juridiques conomiques et de gestion Jendouba

Facult des sciences juridiques conomiques et de gestion Jendouba

Facult des sciences juridiques conomiques et de gestion Jendouba

CHAPITRE 1 : ETUDE PRELIMINAIRE

II. CADRE ET CONTEXTE DE PROJET

Facult des sciences juridiques conomiques et de gestion Jendouba

1.2 DOMAINE DACTIVIT DE TUNISIE TLCOM

Facult des sciences juridiques conomiques et de gestion Jendouba

Les tapes cls de lvolution de la socit :

Facult des sciences juridiques conomiques et de gestion Jendouba

Facult des sciences juridiques conomiques et de gestion Jendouba

FIGURE 1 : ORGANIGRAMME DE L'AGENCE TUNISIE TELECOM JENDOUBA

Facult des sciences juridiques conomiques et de gestion Jendouba