Pfe 2015

Faculté des sciences juridiques économiques et de gestion Jendouba
Page i
Fsjegj — Tunisie Telecom Année universitaire 2014—2015
TABLE DES MATIERES
INTRODUCTION GENERALE...........................................................................................................1
CHAPITRE 1 : ETUDE PRELIMINAIRE...........................................................................................3
I. INTRODUCTION......................................................................................................................3
II. CADRE ET CONTEXTE DE PROJET.................................................................................3
1. PRESENTATION DE L’ORGANISME D’ACCEUIL.........................................................3
1.1 CRÉATION ........................................................................................................................3
1.2 DOMAINE D’ACTIVITÉ DE TUNISIE TÉLÉCOM .......................................................3
1.3 HISTORIQUE.....................................................................................................................4
1.4 ORGANISATION ..............................................................................................................5
2. ARCHITECTURE RÉSEAU DE TUNISIE TELECOM ......................................................6
III. ETUDE ET CRETIQUE DE L’EXISTANT..........................................................................6
1. ÉTUDE DE L’EXISTANT ....................................................................................................6
2. CRITIQUE DE L’EXISTANT...............................................................................................6
3. SOLUTION PROPOSEE .......................................................................................................7
IV. CHOIX METHODOLOGIQUE.............................................................................................7
1. LE MODELE EN CASCADE................................................................................................7
2. LE MODELE EN V ...............................................................................................................8
3. LE MODELE PAR INCREMENT ........................................................................................9
4. LE PROCESSUS UNIFIE UP................................................................................................9
5. MODELE EN SPIRALE......................................................................................................10
6. DECISION DE CHOIX DE METHODOLOGIE ................................................................11
V. CONCLUSION ....................................................................................................................11
CHAPITRE 2 : SPÉCIFICATION DES BESOINS ...........................................................................13
I. INTRODUCTION....................................................................................................................13
II. ADMINISTRATION ET ARCHETECTURE.....................................................................13
1. PRINCIPE D’ADMINISTRATION ....................................................................................13
2. ARCHITECTURE D’ADMINISTRATION........................................................................14
III. IDENTIFICATION DES BESOINS....................................................................................14
1. LES BESOINS FONCTIONNELS ......................................................................................14
2. LES BESOINS NON FONCTIONNEL...............................................................................17

Page ii
IV. LANGUAGE DE MODELISATION ..................................................................................18
V. CONCLUSION ....................................................................................................................18
CHAPITRE 3 : ETUDE CONCEPTUELLE ......................................................................................20
I. INTRODUCTION....................................................................................................................20
II. IDENTIFICATION DES CAS D’UTILISATION ..............................................................20
1. IDENTIFICATION DES ACTEURS ..................................................................................20
2. CAS D'UTILISATION « GESTION DES COMPTES » ....................................................21
3. CAS D'UTILISATION « GESTION DU SYSTÈME » ......................................................22
III. DIAGRAMME DE SEQUENCE.........................................................................................23
1. DEFINITIONS.....................................................................................................................23
2. DIAGRAMME DE SÉQUENCE « AUTHENTIFICATION »...........................................24
3. DIAGRAMME DE SEQUENCE «GESTION DU COMPTES» ........................................25
4. DIAGRAMME DE SEQUENCE « GESTION DE PANNES »..........................................26
5. DIAGRAMME DE SEQUENCE « GESTION DE PERFERMANCE »............................27
IV. DIAGRAMME DE CLASSE...............................................................................................28
1. DÉFINITIONS.....................................................................................................................28
2. DIAGRAMME DE CLASSE GLOBALE ...........................................................................29
3. EXPLICATION DU DIAGRAMME DE CLASSE.............................................................30
V. CONCLUSION ....................................................................................................................33
CHAPITRE 4 : REALISATION.........................................................................................................35
I. INTRODUCTION....................................................................................................................35
II. ENVIRONNEMENT DE DEVELOPPEMENT..................................................................35
1. PRÉSENTATION ................................................................................................................35
2. BRÈVE PRÉSENTATION DU PROTOCOLE SNMP.......................................................35
3. CHOIX DU LANGAGE DE PROGRAMMATION JAVA :..............................................36
III. IMPLEMENTATION ..........................................................................................................36
IV. CONCLUSION ....................................................................................................................48
CONCLUSION GÉNÉRALE.............................................................................................................49
BIBLIOGRAPHIE ..............................................................................................................................51

Page iii
LISTE DES FIGURES
FIGURE 1 : ORGANIGRAMME DE L'AGENCE TUNISIE TELECOM JENDOUBA ...................5
FIGURE 2: ARCHITECTURE RÉSEAU DE TUNISIE TELECOM .................................................6
FIGURE 3: LE MODÈLE EN CASCADE...........................................................................................7
FIGURE 4: LE MODÈLE EN V...........................................................................................................8
FIGURE 5: LE MODÈLE PAR INCRÉMENT....................................................................................9
FIGURE 6: LE CYCLE DE VIE D'UN PROCESSUS ......................................................................10
FIGURE 7: MODÈLE EN SPIRALE .................................................................................................11
FIGURE 8: PROCESSUS AGENT/GÉRANT...................................................................................13
FIGURE 9: GESTION DES PANNES ...............................................................................................15
FIGURE 10: GESTION DE PERFORMANCE .................................................................................16
FIGURE 11: DIAGRAMME DE CAS D'UTILISATION « GESTION DES COMPTES » .............21
FIGURE 12: DIAGRAMME DE CAS D'UTILISATION « GESTION DU SYSTÈME » ...............22
FIGURE 13: DIAGRAMME DE SÉQUENCE « AUTHENTIFICATION » ....................................24
FIGURE 14: DIAGRAMME DE SÉQUENCE « GESTION DES COMPTES »..............................25
FIGURE 15: DIAGRAMME DE SÉQUENCE «CAS DES PANNES » ...........................................26
FIGURE 16: DIAGRAMME DE SÉQUENCE « GESTION DE PERFORMANCE ».....................27
FIGURE 17: DIAGRAMME DE CLASSE PRINCIPALE................................................................29
FIGURE 18: LES MESAGES SNMP.................................................................................................32
FIGURE 19: SEIGLE DE LANGUAGE DE PROGRAMMATION JAVA......................................36
FIGURE 20 BIBLIOTHÈQUES UTILISÉS JAVA (.JAR) ...............................................................37
FIGURE 21: FENÊTRE D'AUTHENTIFICATION ..........................................................................37
FIGURE 22: FENÊTRE PRINCIPALE AVANT LE BALAYAGE..................................................38
FIGURE 23: FENÊTRE PRINCIPALE APRÈS LE BALAYAGE ...................................................38
FIGURE 24: FENÊTRE DE LISTE DE ROUTEURS .......................................................................39
FIGURE 25 : LISTE DES COMMUTATEURS ................................................................................40
FIGURE 26: LISTE DES SERVEURS ..............................................................................................40
FIGURE 27: FENÊTRE DE LISTE DES PANNES AVANT LE BALAYAGE ..............................41
FIGURE 28: FENÊTRE LISTE DES PANNES APRÈS LE BALAYAGE ......................................41
FIGURE 29: FENÊTRE DE MESURE DE PERFORMANCE DES ROUTEURS...........................42
FIGURE 30: FENÊTRE DE MESURE DE PERFORMANCE DES SERVEURS ...........................42

Page iv
FIGURE 31: RAPPORT DES ROUTEURS.......................................................................................43
FIGURE 32: RAPPORT DES COMMUTATEURS ..........................................................................44
FIGURE 33: RAPPORT DES SERVEURS .......................................................................................45
FIGURE 34: FENÊTRE DE GESTION DES ÉQUIPEMENTS ........................................................46
FIGURE 35: FENÊTRE GESTION DE COMPTES ..........................................................................46
FIGURE 36: FENÊTRE DE GESTION DE NOTIFICATION..........................................................47
FIGURE 37: NOTIFICATION APRÈS LE BALAYAGE.................................................................47
FIGURE 38: FENÊTRE DE SCAN DE PORT ..................................................................................48

Page v
LISTE DES ABREVIATIONS
Dans cette page on va citer tous les abréviations 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
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 1
INTRODUCTION GENERALE
Les réseaux informatiques, sont des éléments essentiels des technologies actuelles des
transmissions des données entre sites éloignés, leur traitement et leur restitution, touchent de
plus en plus notre vie courant. On compte sur les services offerts par les réseaux pour
transactions bancaire, les recherches web, la téléconférence, etc. ces services sont de ce fait
devenus indispensable. Pour s'assurer que les services rendus par les réseaux soient
convenable, il est nécessaire de surveiller et d'agir quand une erreur se produit. Pour ce faire,
il faut obtenir les données de gestion des équipements des réseaux et, si nécessaire, contrôler
ces équipements d'où l'utilité de recourir aux outils de supervision des réseaux.
Ce projet a été réalisé dans le cadre de la mise en place d'un outil d'administration réseau de
Groupe Tunisie Telecom de Jendouba. Il consiste à concevoir et mise en place un système de
supervision réseaux qui permettent à la fois de collecter des données sur les routeurs, les
serveurs et les commutateurs, afficher une cartographie de réseaux, et notifier en cas de
panne d'un équipement.
Il existe déjà un grand nombre d'outil et des plates-formes sur le marché conçus pour
l'administration de grands réseaux locaux et distants. Ils sont prévus pour gérer un grand
nombre d'équipement et supportent le protocole standard d'administration réseau SNMP
Cependant la majorité des outils d'administration existant sont des systèmes propriétaires
limites du point de vue portabilité sans oublier aussi leurs couts très élèves.
Pour remédier à ces problèmes, les responsables informatiques de l’agence de Jendouba
m'ont proposé de réaliser un outil d'observation et de contrôle réseau qui s'adapte avec la
topologie a du réseau existant et avec les applications qui tournent sur ce réseau.
Le présent document est structure en quatre chapitres.
 Dans le premier chapitre nous avons fait une étude préliminaire. Tout d’abord nous
présentons l’organisme d’accueil avec leur L’architecture réseau de l’entreprise.
 Dans le deuxième chapitre nous avons précisé une spécification des besoins.
 Le troisième chapitre est consacré à l’étude conceptuelle de notre application
 Le quatrième chapitre décrit l’implémentation et les tests de notre outil.
 Nous conclusions ce document en présentant les avantages apporte par notre
application réalisé
Le protocole SNMP est décrit dans l'annexe de ce document.

Page 2
Objectifde chapitre : ce chapitre consacre à l’étude préliminaire. Tout d’abord nous présentons
l’organisme d’accueil avec leur L’architecture réseau de l’entreprise
ETUDE PRELIMINAIRE

Page 3
CHAPITRE 1 : ETUDE PRELIMINAIRE
I. INTRODUCTION
Ce chapitre décrit le projet de fin d’étude intitule conception et Implémentation d'une
application d’administration de réseau basé sur le protocole SNMP [1].il est divisée en deux
parties. La première est consacrée à la mise en cadre de notre projet. Dans la deuxième partie,
on va parler sur les différentes méthodes de conception aussi le choix de méthodologie utilisé
pour développer ce projet.
II. CADRE ET CONTEXTE DE PROJET
1. PRESENTATION DE L’ORGANISME D’ACCEUIL
1.1 CRÉATION
La Société Nationale des Télécommunications, société anonyme dont le capital est de mille
quatre cent millions de dinars, inscrite au registre de commerce sous le numéro B646-1995
ayant le matricule fiscal N° 425665 XAM000, ayant son siège social à la rue du japon
Montplaisir , 1073 Tunis, au nom de son représentant légal. Ci-après dénommer « Tunisie
Telecom »
1.2 DOMAINE D’ACTIVITÉ DE TUNISIE TÉLÉCOM
Depuis sa création, Tunisie Telecom œuvre à consolider l’infrastructure des télécoms en
Tunisie, à améliorer le taux de couverture et à renforcer sa compétitivité. Elle contribue
également activement à la promotion de l’usage des TIC et au développement des sociétés
innovantes dans le domaine des télécoms. Tunisie Telecom compte dans ses rangs plus de 6
millions abonnés dans la téléphonie fixe et mobile, en Tunisie et à l’étranger. Elle joue en
outre un rôle important dans l’amélioration du taux de pénétration de l’Internet en Tunisie, ce
qui lui a permis d’atteindre le nombre 140 mille abonnés à la toile à la fin du mois d’avril
2008 [Tunisie Télécom, 2008]. Au niveau du marché local, Tunisie Télécom a su tirer profit
de la concurrence accrue après l’entrée en service du premier opérateur GSM privé, pour
développer davantage ses services et ses produits.
Il importe de souligner que l’activité de Tunisie Télécom ne se limite pas uniquement aux
services de la téléphonie fixe et mobile. Elle englobe, également, l’installation, l’entretien et
l’exploitation des réseaux publics de télécommunications, la contribution au développement
des études et recherches scientifiques liées au secteur, et la promotion de la coopération à
tous les niveaux dans tous les branches du secteur.…

Page 4
Outre que son activité à l’échelle nationale ,Tunisie Télécom s’est orientée vers l’exportation
de son savoir pour le développement des réseaux et de nouveaux services dans certains
marchés émergents, notamment, celui de la Mauritanie où mis en place, exploité et
commercialisé le premier réseau GSM après la création de l’opérateur Mattel en
collaboration avec le secteur privé mauritanien. La société a conclu, ces dernières années, une
convention de coopération technique avec Djibouti Télécom pour le développement de ses
réseaux de télécommunications, et dispose aussi de certains accords de partenariat avec des
opérateurs de renommée internationale à l’instar de Thuraya.
1.3 HISTORIQUE
L’office national des télécommunications est créé suite à la promulgation de la loi N°36 du
17 avril 1995. L’office a ensuite changé de statut juridique, en vertu du décret N°30 du 5
avril 2004, pour devenir une société anonyme dénommée « Tunisie Telecom ».
En juillet 2006, il a été procédé à l’ouverture du capital de Tunisie Telecom à hauteur de 35%
en faveur du consortium émirati TeCom-DIG. Cette opération vise à améliorer les 4
rentabilités de Tunisie Telecom et à lui permettre de se hisser parmi les grands opérateurs
internationaux.
- Les étapes clés de l’évolution de la société :
17 Avril 1995 : Promulgation de la loi N°36 portant création de l'Office National
des Télécommunications, dénommé Tunisie Télécom.
1er Janvier 1996 : Mise en place de l’Office National des Télécommunications.
20 Mars 1998 : Inauguration de la première ligne GSM par Monsieur le Président de
la République.
Décembre 1999 : Promulgation du décret N°2844 du 27 décembre 1999, relatif au
statut de Tunisie Télécom.
17 Mai 2000 : Attribution de la première licence de téléphonie mobile en Mauritanie
au consortium Mattel (détenue à 51% par Tunisie Télécom).
Fin 2002 : Restructuration de Tunisie Télécom en Société Anonyme.
07 Juillet 2004 : Signature de la convention d'interconnexion entre Tunisie Télécom
et Orascom Télécom Tunisie
09 Juillet 2004 : Premier Conseil d'Administration de la Société Nationale des
télécommunications suite à la transformation de Tunisie Télécom en Société
Anonyme.
27 Avril 2006 Telecom Dubaï partenaire stratégique de Tunisie Télécom

Page 5
1.4 ORGANISATION
Tunisie Telecom se compose de 24 directions régionales, de 80 Actels et points de vente et
de plus de 13 mille points de vente privés. Elle emploie plus de 8000 agents. L’opérateur
historique dispose, également, de six centres d’assistance à la clientèle de la téléphonie fixe,
mobile et data. Tunisie Télécom a une direction nommée « Direction centrale des opérations
des réseaux NOC » qui est lié directement au PDG de la société à l’inverse d’autres
directions. Cette direction a pour rôle de gérer tous types d’opérations directes effectuées sur
les réseaux. La sous-direction dans laquelle nous faisons notre projet est intitulée «
subdivision de programmation ». Cette subdivision s’intéresse à la gestion des plateformes de
réseau et de contrôle.
FIGURE 1 : ORGANIGRAMME DE L'AGENCE TUNISIE TELECOM JENDOUBA
En interprétant cet organigramme, nous constatons que quatre subdivisions sont supervisées
hiérarchiquement par le Directeur Général. Parmi ces quatre on cite la subdivision des
réseaux qui dérive en deux autres subdivisions : subdivision des projets, commutation
transmission.

Page 6
1.5 DONNES FINANCIERE
Selon les nouvelles statistiques de l’année 2015 la société 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.
2. ARCHITECTURE RÉSEAU DE TUNISIE TELECOM
FIGURE 2: ARCHITECTURE RÉSEAU DE TUNISIE TELECOM
III. ETUDE ET CRETIQUE DE L’EXISTANT
1. ÉTUDE DE L’EXISTANT
La société Tunisie Telecom pour gérer le réseau, les administrateurs réseau utilisent quelques
applications comme netsight et Nagios quelles permet la surveillance système et réseau.
Elles surveillent les hôtes et service spécifiés, alertant lorsque les systèmes ont des
dysfonctionnements et quand ils repassent en fonctionnement normale.
2. CRITIQUE DE L’EXISTANT
Ce type des applications ont des soucis fatale et des point négatives comme :
L’interface complexe et pas très intuitive.
Très Cher.
Une difficulté de détecter ou se localise l’erreur.
Intervention long tend vers la panne.
Le cout élevé de ces types des outils.
Une difficulté de consulter l’état des équipements.
La mesure de performance est négligée.

Page 7
3. SOLUTION PROPOSEE
En se basant sur le précédent Critique, nous avons l’envie de proposer notre solution optimal
et facile à utiliser spécialement, pour la gestion des serveurs, routeurs, commutateurs, et
monitoring de a ces équipements, En premier lieu
Et d’offrir la possibilité de devenir proactif face aux problèmes rencontrés en second lieu.
Finalement et le plus important, de pouvoir détecter et d’interpréter en un simple coup d’œil
les cause et origines des problèmes rencontres afin de les fixer le plus rapidement possible.
Pour cela on va concevoir et mettre en place un outil d’administration et supervision
réseau.
Se souciant de sa réputation et concerné par la satisfaction et le confort de ses clients la
société veut à tout prix éviter la confrontation à des clients mécontents. Notre plateforme
nous permet d’anticiper les pannes et éviter les arrêts de longue durée c’est la réaction bref
tend vers les soucis.
IV. CHOIX METHODOLOGIQUE
Nous présentons, dans cette les méthodes de conception les plus citées dans la littérature de
plus on va choisir une qui sera suivi tout au long de notre projet.
1. LE MODELE EN CASCADE
Le modèle de cycle de vie en cascade a été mis au point dès 1966, puis formalisé aux
alentours de 1970.
Il définit des phases séquentielles à l'issue de chacune desquelles des documents sont
Produits pour en vérifier la conformité avant de passer à la suivante (symbolisées dans le
schéma par des flèches vers le haut) :
FIGURE 3: LE MODÈLE EN CASCADE

Page 8
 Caractéristiques du cycle de vie en cascade :
 Linéaire, flot descendant
 Retour limité à une phase en amont
 Validation des phases par des revues
 Enchaînement depuis le cahier des charges jusqu’à la réalisation
 Bien adapté lorsque les besoins sont clairement identifiés et stables
2. LE MODELE EN V
Le modèle du cycle en V a été imaginé pour pallier le problème de réactivité du modèle en
cascade.
Ce modèle est une amélioration du modèle en cascade qui permet en cas d'anomalie, de
limiter un retour aux étapes précédentes.
Les phases de la partie montante doivent renvoyer de l'information sur les phases en vis-à-
vis lorsque des défauts sont détectés afin d'améliorer le logiciel.
De plus le cycle en V met en évidence la nécessité d'anticiper et de préparer dans les étapes
descendantes les « attendus » des futures étapes montantes : ainsi les attendus des tests de
validation sont définis lors des spécifications, les attendus des tests unitaires sont définis lors
de la conception, etc.
FIGURE 4: LE MODÈLE EN V

Page 9
3. LE MODELE PAR INCREMENT
L’image n'affiche que deux incrémentation, mais il peut y en avoir plusieurs.
Le développement est ainsi moins complexe, l'intégration est moins brutale et le client a plus
rapidement un système même s'il n'est pas complet. Par contre, le cœur du système peut être
à revoir lorsque on passe à une autre incrémentation du système .il peut aussi s'avérer
complexe d'ajouter certaines fonctionnalités.
FIGURE 5: LE MODÈLE PAR INCRÉMENT
4. LE PROCESSUS UNIFIE UP
Le processus unifié est un processus de développement logiciel itératif, centré sur
l'architecture, pilote par des cas d'utilisation et orienté vers la diminution des risques.
C’est un patron de processus pouvant être adapté à une large classe de système logiciels, à
différent domaines d’application, à différent types d'entreprises, à diffèrent niveaux de
compétences et à différent tailles de l'entreprise.
UP permet de gérer le processus de développement par deux axes :
- L’axe vertical : Représente les principaux enchainements d'activités, qui regroupent les
activités, selon leur nature. Cette dimension rend compte l'aspect statique du processus qui
s'exprime en termes de composant, de processus, d’activités, d’enchainements, d'artefacts et
de travailleurs.
- L’axe horizontal : représente le temps et montre le déroulement 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'itération et de jalons.

Page 10
FIGURE 6: LE CYCLE DE VIE D'UN PROCESSUS
5. MODELE EN SPIRALE
Le modèle en spirale (spiral model) est un modèle de cycle de développement logiciel qui
reprend les différentes étapes du cycle en V. Par l'implémentation de versions successives, le
cycle recommence, En proposant un produit de plus en plus complet et dur.
Le cycle en spirale met cependant plus, l’accent sur la gestion des risques que le cycle en V.
Le modèle en spirale a été défini par Barry Boehm en 1988 dans son article "A Spiral Model
of Software Development and Enchantement"
 Principe de Cycle en spirale
On distingue quatre phases dans le déroulement du cycle en spirale
- Détermination des objectifs, des alternatives et des contraintes
- Analyse se des risques, évaluation des alternatives
- Développement et vérification de la solution retenue
- Revue des résultats et vérification du cycle suivant.

Page 11
FIGURE 7: MODÈLE EN SPIRALE
6. DECISION DE CHOIX DE METHODOLOGIE
J’ai choisi comme méthodologie le modèle en cascade car c'est le modèle le plus pratique et
le plus utilisé dans le domaine de développement logiciel.
Ce modèle a comme avantages :
 Le montant des processus nécessaire pour mettre en œuvre les modèles est minime.
 Inutile de mentionner : il s'agit d'un modèle linéaire et bien sur les modèles linéaires
sont les plus simple à mettre en œuvre.
V. CONCLUSION
Ce chapitre nous permet de comprendre les notions liées à notre travail pour passer en
délicatesse au deuxième chapitre pour déterminer les besoins fonctionnels et non fonctionnels
de notre plateforme.

Page 12
Objectif de chapitre : Dans ce chapitre, nous allons présenter les spécifications de notre
solution d'administration réseau. Nous commencerons par le principe général
d'administration en suite et nous terminerons par l'identification des besoins
Spécificationdes besoins

Page 13
CHAPITRE 2 : SPÉCIFICATION DES BESOINS
I. INTRODUCTION
Dans ce chapitre, nous allons présenter les spécifications de notre solution d'administration
réseau. Nous commencerons par le principe général d'administration en suite et nous
terminerons par l'identification des besoins.
II. ADMINISTRATION ET ARCHETECTURE
1. PRINCIPE D’ADMINISTRATION
Sur le point de l’administration [2], un système de réseau informatique se compose d'un
ensemble d'objets qu'un système d'administration surveille et contrôle. Chaque objet est géré
localement par un processus appelé agent qui transmet régulièrement ou sur sollicitation les
informations de gestion relatives à son état et aux événements qui le concernent au système
d’administration.
Le système d'administration comprend un processus (manager ou gérant) qui peut accéder
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 appelée MIB (Management Information
Base) et l'ensemble des éléments administrés (objets) ;
 D'autre part, entre les éléments administrés et le système d'administration.
FIGURE 8: PROCESSUS AGENT/GÉRANT

Page 14
2. ARCHITECTURE D’ADMINISTRATION
L'architecture classique d'administration la plus utilisée est le modèle Gérant/ Agent
(Manager/Agent).comme nous l'avons montré dans le principe d'administration.
Le système est Composé d'une entité d'administration et des entités de gestion (NME) qui
sont géré par cette entité et un protocole pour la gestion
Chaque entité dans le réseau a un Agent pour l'opération de gestion, une base de données
stockées dans MIB et assume les travaux ci-dessous :
- Collecter des informations statistiques concernant à la communication, les opérations de
réseau.
- Stocker les informations localement dans les MIBs.
- Répondre les commandes de l'entité de contrôle de réseau, inclus : Transmet des
informations statistiques à l'entité d'administration de réseau, modifie les paramètres, donne
des informations d'état...
III. 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 générations des rapports et journalisations (historique).
1.1.MODULE DE GESTION D’APPLICATION
Le module de gestion d'application est forme par deux sous modules principaux qui sont :
- Authentification auprès de l'interface : ce module permet à l'administrateur de sécurité
de ce connecté à l'interface en introduisant le login et son mot de passe. Ce module va
chercher dans la base des données 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 :

Page 15
- 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 données et la même pour la suppression.
- Contrôle des équipements : Ce module permet de contrôler 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 précis ou d'une
plage des ports.
1.3.MODULE DE GESTION DES PANNES
Ce domaine recouvre la détection, l'isolement et la correction des pannes survenant sur un
équipement. L'action curative qui en découle peut être faite à distance (si l'équipement
répond) ou par un contact humain qui agira sur l'équipement. Un historique des évènements
est également disponible
 Type de panne : Les pannes peuvent être d'origine interne, à caractère permanent
(composant en pannes) ou externes (goulets d'étranglement, trafic intense, etc.), Cette
dernière est plus difficile à détecter, car elle est à caractère aléatoire.
La gestion de faute couvre l'ensemble des fonctionnalités suivantes :
 La détection des fautes : elle comprend la préparation de rapports d'incidents de
fonctionnement, la gestion de compteurs ou des seuils d'alarme, le filtrage
FIGURE 9: GESTION DES PANNES

Page 16
d'événements par filtrage en amont des informations, l'affichage des
dysfonctionnements.
 La localisation : on y procède au moyen de rapports d'alarme, de mesures et de tests.
 La réparation : elle consiste à prendre les mesures correctives (réaffectation de
ressources, routages, limitation du trafic par filtrage, maintenance), ou encore à
rétablir le service (tests de fonctionnement, gestion de systèmes de secours, etc.).
 L'enregistrement des historiques d'incidents et statistiques : la gestion des fautes ne
peut se limiter à ces actions ponctuelles, nécessaires 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 durée, les délais de réparation et, d'autre part,
un rôle d'interface avec les usagers qui consiste à les informer des problèmes réseau et
à leur donner la possibilité de signaler eux-mêmes des incidents telle que :
 La déconnexion d'un câble ;
 Une mauvaise configuration d'un équipement ;
 Une interface défectueuse d'un routeur.
 La réinitialisation accidentelle.
1.4.MODULE DE GESTION DE PERFERMANCE
Ce domaine comprend la collecte des données et l'analyse statistique permettant la création
de tableaux de bord. Ce domaine est essentiellement lié à l'évolution du réseau (permet de
planifier les changements à apporter afin d'améliorer les performances du réseau).
FIGURE 10: GESTION DE PERFORMANCE

Page 17
L'objectif est d'établir des statistiques à partir des paramètres du réseau.
 Débit
 Temps de réponse
 Taux d'erreur
 Temps d'établissement des connexions
Elle fournit des fonctions qui permettent à des fins de planification des ressources du réseau :
De recueillir des données statistiques (taux d'erreurs, temps de transit, débit, etc.),
 De maintenir et analyser des journaux sur l'historique de l'état du système
(événements). Les informations obtenues serviront à l'analyse et à la planification du
réseau. On peut diviser cette partie en deux : l'une traitant de la gestion de la
performance en temps réel et l'autre en temps différé. Pour gérer la performance d'un
réseau en temps réel, il faut mettre en place la fonction suivante :
 Enregistrements des mesures de performance : cela passe par l'établissement et la
mise à jour des critères 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 générer des rapports de chaque équipement qui décrit tous ses
informations et aussi génère 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 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 ce résument dans les points
suivants :
 Le code doit être clair pour permettre des futures évolutions ou améliorations
 L'ergonomie : l'application offre une interface conviviale et facile à utiliser
 La sécurité : l'application doit respecter la confidentialité des données
 Garantir l'intégrité et la cohérence des données à chaque mise à jour et à chaque
insertion.

Page 18
IV. LANGUAGE DE MODELISATION
UML (Unified Modeling Language), se définit comme un langage de modélisation graphique
et textuel destiné à comprendre et à définir des besoins, spécifier et documenter des systèmes,
esquisser des architectures logicielles, concevoir des solutions et communiquer des points de
vue. UML modélise l'ensemble des données et des traitements en élaborant des différents
diagrammes. En clair, il ne faut pas designer UML en tant que méthode mais plutôt comme
une boite d'outils qui sert à améliorer les méthodes de travail.
V. CONCLUSION
Ce chapitre nous a permis de présenter le principe général d'administration réseau
et d'identifier les besoins fonctionnels et non fonctionnels de notre système. Le chapitre
suivant sera consacré à spécification et la conception de l'outil d'administration réseau.

Page 19
Objectif de chapitre : Dans ce chapitre, nous allons modéliser notre application en utilisant
un langage de modélisation objet qui est UML. La conception de notre application se base sur
les diagrammes des cas d'utilisation(les acteurs, procédures d'administrateur), les diagrammes
de classes et les diagrammes de séquences
Étude Conceptuelle

Page 20
CHAPITRE 3 : ETUDE CONCEPTUELLE
I. INTRODUCTION
Dans ce chapitre, nous allons modéliser notre application en utilisant un langage de
modélisation objet qui est l’UML. La conception de notre application se base sur les
diagrammes des cas d'utilisation(les acteurs, procédures d'administrateur), les diagrammes de
classes et les diagrammes de séquences
II. IDENTIFICATION DES CAS D’UTILISATION
Le travail effectué au sein de cette partie permet d'identifier les acteurs mis en jeu et de
visualiser les scénarios de cas d'utilisation de notre application qui permettent de bien
superviser une machine.
Ce diagramme est destiné à représenter les besoins des utilisateurs par rapport au système. Il
constitue un des diagrammes les plus structurants dans l'analyse d'un système.
1. IDENTIFICATION DES ACTEURS
- Acteur : Représente un rôle joué par une entité externe (utilisateur humain, dispositif
matériel ou autre système) qui interagit directement avec le système étudié.
Les acteurs qui interagissent avec cette application sont les suivants :
- Administrateur : désigne la personne responsable de la politique de sécurité et de
son application par la surveillance et l'administration.
- Le système (Superviseur) : désigne l'entité qui s'occupe du contrôle d'une entité, de
la détection des pannes et de l'envoi des notifications à et l'administrateur.
- Scénario des cas d'utilisation :
Représente un ensemble des séquences d'actions qui sont réalisées par les acteurs et qui
produisent un résultat observable intéressant pour un acteur particulier.

Page 21
2. CAS D'UTILISATION « GESTION DES COMPTES »
FIGURE 11: DIAGRAMME DE CAS D'UTILISATION « GESTION DES COMPTES »
Seul l'administrateur réseau (super administrateur) peut créer, modifier, ajouter, et supprimer
un compte et un mot de passe. Les comptes et les mots passe valides sont initialisées et
enregistrées par l'administrateur réseau (super administrateur).

Page 22
3. CAS D'UTILISATION « GESTION DU SYSTÈME »
FIGURE 12: DIAGRAMME DE CAS D'UTILISATION « GESTION DU SYSTÈME »

Page 23
La figure 12 nous permet de savoir les différents droit de l'administrateur réseau :
l'administrateur réseau doit s'authentifier pour qu'il puisse consulter la liste des
routeurs (ouvert ou fermée) ,des serveurs (ouvert ou fermée) et des commutateurs (ouvert ou
fermée) disponible dans l'architecture réseau il peut aussi scanner les différents ports (ouvert
ou fermée) et de consulter la performance du réseau (débit, vitesse «...)
La gestion des alertes et des notifications, et la production des rapports sont présenté par
notre moniteur réseau.
III. DIAGRAMME DE SEQUENCE
1. DEFINITIONS
Les diagrammes des séquences documentent les interactions à mettre en œuvre entre les
classes pour réaliser un résultat, tel qu'un cas d'utilisation. UML étant conçu pour la
programmation orientée objet, ces communications entre les classes sont reconnues comme
des messages. Le diagramme des séquences énumère des objets horizontalement, et le temps
verticalement. Il modélise l'exécution des différents messages en fonction du temps.
Chaque diagramme de séquence doit comprendre :
 Les acteurs intervenants dans la séquence de messages
 Une note contenant la description de la séquence représentée (idéalement le cas
d'utilisation représentée)
 Les messages envoyés entre les entités (ou sur eux-mêmes) avec les paramètres
pertinents
 Les lignes de vie des entités doivent montrer la création et la destruction lorsque
pertinent.
 Les entités logicielles doivent avoir la bonne représentation UML : instance, instance
nommée ou classe.
Le diagramme de séquences se base sur les concepts suivants :
- Objet : description d'un objet du monde réel (instance de classe). Il peut être une
personne ou une chose.
- Message : Les messages indiquent les communications entre les objets.
- Message réflexif : un objet peut envoyer à lui-même : c'est un message réflexif.
- Période d'activité d'objet : Dans certains cas, il représenté par la période pendant
laquelle un objet est actif.

Page 24
- Acquittement : En informatique, l'acquittement d'une donnée ou d'une information
consiste à informer son émetteur de sa bonne réception. On utilise souvent le
terme ack pour un acquittement, ce terme correspond à l'équivalent anglais du
terme : acknowledgement.
2. DIAGRAMME DE SÉQUENCE « AUTHENTIFICATION »
Description du scénario
Le système affiche l'interface d'authentification.
L'utilisateur introduit un login et un mot de passe.
Le system vérifie le login et le mot de passe.
Si les données saisies sont correct le système affiche l'interface de l'application, sinon le
système demande de répéter la saisie de login et mot de passe
FIGURE 13: DIAGRAMME DE SÉQUENCE « AUTHENTIFICATION »

Page 25
3. DIAGRAMME DE SEQUENCE «GESTION DU COMPTES»
Après l'authentification de l'utilisateur le système affiche l'interface pour l'ajout, suppression
ou la modification des coordonnées d'un utilisateur
L'utilisateur introduit les nouvelles notifications (les coordonnées d'un nouvel
utilisateur ou la modification des coordonnées ou la suppression d'un utilisateur)
- Tout les modifications sont enregistrés dans la base de donné
FIGURE 14: DIAGRAMME DE SÉQUENCE « GESTION DES COMPTES »

Page 26
4. DIAGRAMME DE SEQUENCE « GESTION DE PANNES »
Description du scénario :
- L'utilisateur demande au système l'état de chaque équipement (routeur serveur et
commutateur)
- Le système scanne le réseau
- En cas de panne le système 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.
FIGURE 15: DIAGRAMME DE SÉQUENCE «CAS DES PANNES »

Page 27
5. DIAGRAMME DE SEQUENCE « GESTION DE PERFERMANCE »
- L'utilisateur demande au système l'état de chaque équipement (routeur, serveur et
commutateur)
- L'utilisateur peut avoir l'état de chaque équipement
- L'utilisateur demande au système l'état des ports
- L'utilisateur peut avoir l'état de chaque port
- L'utilisateur demande au système l'état de performance des équipements
Le système scanne le réseau pour avoir l’état de performance des équipements
FIGURE 16: DIAGRAMME DE SÉQUENCE « GESTION DE PERFORMANCE »

Page 28
IV. DIAGRAMME DE CLASSE
1. DÉFINITIONS
Un diagramme de classes est une collections de modélisations statiques (classes, Package..),
qui montre d’un modèle.
Association entre classes
Une association exprime une connexion sémantique bidirectionnelle entre deux classes.
L’association est distanciable dans un diagramme d’objets ou de collaboration, sous forme de
liens entre objets issus de classe associes
Cardinalité
Précise le nombre d’instance qui participent à une relation.
Relation de dépendance
Relation d’utilisation unidirectionnelle et d’obsolescence (une modification de l’élément dont
on dépend, peut nécessiter une mise à jour de l’élément dépendant)
Association n-aire
Il s’agit d’une association qui relie plus de deux classes.
NB : De telles associations sont difficiles à déchiffrer et peuvent induire une erreur.
Il vaut mieux limiter leur utilisation, en définissant de nouvelles catégories d’associations.
Classe d’association
Il s’agit d’une classe qui réalise la navigation entre les instances d’autres classes.

Page 29
2. DIAGRAMME DE CLASSE GLOBALE
FIGURE 17: DIAGRAMME DE CLASSE PRINCIPALE

Page 30
3. EXPLICATION DU DIAGRAMME DE CLASSE
 Administrateur
 Système
Attribut Type Signification
Nom String Nom du système
Version String Version du système
Login String Login de l’administrateur
Mot de passe String Mot de passe de l’administrateur
Méthode Signification
Gérer les comptes () Ajouter, supprimer ou modifier des comptes
administrateurs
Gérer les équipements () Ajouter ou supprimer un équipement
Gérer les notifications () Ajouter l’adresse mail de Faculté pour recevoir les
notifications
Scanner les ports () Faire un balayage sur les ports d’équipements
Config le service SNMP () Modifier la communauté et le port de service SNMP

Page 31
Superviser les équipements () Controller les équipements
Afficher la cartographie () Dessiner la cartographie du réseau (UP, DOWN)
Collecter les informations () Collecter les informations de chaque équipement
Générer des rapports () Générer des rapports de chaque équipement
Envoyer des alertes () Envoie des alertes (mail) en cas de panne
 Équipements
Adresse IP String Adresse IP de l’équipement
Nom String Nom de l’équipement
 Cartographie
Routeur Routeurs Représente le routeur sur la carte
Serveur Serveur Représente le serveur sur la carte
Commutateur Commutateur Représente le commutateur sur la carte
 Mail
Adresse mail String Correspond le mail de la faculté
Mot de passe String Correspond le mot de passe du compte

Page 32
Recevoir des notifications Enregistrer tous les notifications reçus
 Rapport
Nom String Nom du rapport générer
Date Date Date du rapport publie
 Historique
Date Date Date de l’historique
 Les fonctions SNMP utilises sont :
FIGURE 18: LES MESAGES SNMP

Page 33
V. CONCLUSION
Dans ce chapitre nous avons décrit les principaux diagrammes, considères les plus importants
et les plus adéquats a notre projet. Ces diagrammes sont choisis parmi les neuf diagrammes
de conception UML.
Le chapitre suivant décrit les deux principales étapes de la réalisation, à savoir codage et les
tests.

Page 34
Objectif de chapitre : À la fin de la construction du système que nous avons réalisé, nous
dans le stade opérationnel. Nous établissions le modèle de test.
Réalisation

Page 35
CHAPITRE 4 : REALISATION
I. INTRODUCTION
L’enchainement des activités de test s’attache à la vérification des résultats de
l’implémentation en testant chaque instruction, aussi bien les constructions internes et
intermédiaires que les versions finales du l’application. Deux activités peuvent être effectuées
aux niveaux d’un test : la vérification. La première consiste à vérifier que résultat correspond
à la spécification et la deuxième consiste à vérifier que le résultat correspond vraiment à ce
que voulait l’utilisateur.
II. ENVIRONNEMENT DE DEVELOPPEMENT
1. PRÉSENTATION
Nous décrivons dans ce chapitre l'environnement de travail requis qui est le développement
d'une application réseau utilisant le protocole SNMP.
Pour qu'une application réseau puisse être mise en œuvre, il est nécessaire que les
composants réseaux 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 :
- système d'exploitation : Windows 7 SP 1 Professionnel.
- Netbeans 8.0.2, Microsoft office 2013, kit Java runtime 8 Update 40
- Protocoles : SNMP.
- Langage de programmation : JAVA.
2. BRÈVE PRÉSENTATION 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 réseau. Il permet également de contrôler un
réseau à distance en interrogeant les stations qui en font partie sur leur état et configurer leur

Page 36
configuration, de faire des tests de sécurité et observer les différentes informations liées à
l’émission de données. Il peut même être utilise pour gérer les logiciels et bases de données
liées à distance.
Le protocole SNMP est le protocole le plus adéquat à 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'exécution.
Java peut être séparée 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'exécution de votre
programme Java.
C'est cette plateforme qui garantit la portabilité de Java. Il suffit qu'un système ait une
machine virtuelle Java pour que tout programme écrit en Java puisse fonctionner.
Avec le langage Java, vous pouvez développer, des applications Desktop, développer des
applets pour vos sites web, développer des sites en JSP, des applications pour téléphone
mobile. La première chose à faire est bien évidemment d'apprendre à faire des applications
stadalones simples.
III. IMPLEMENTATION
Initialement nous avons utilisé Netbeans 8.0.2 (Environnement de développement intégré
pour Java, Java EE, Java FX et d'autres langages) pour simplifier de développer les interfaces
de notre application.
Notre application fait appel à seize bibliothèques .jar et contient également treize interfaces
graphiques.

Page 37
FIGURE 20 BIBLIOTHÈQUES UTILISÉS JAVA (.JAR)
 LES TESTS
Fenêtre principale « Network Manager 1.0.1 »
FIGURE 21: FENÊTRE D'AUTHENTIFICATION

Page 38
 Fenêtre principale «Network Manager 1.0.1»
C’est une fenêtre qui affiche la cartographie du réseau après un balayage complet il y a aussi
une barre de progression qui permet de visualiser le pourcentage de balayage de réseau
depuis le lancement de l’application
FIGURE 22: FENÊTRE PRINCIPALE AVANT LE BALAYAGE
FIGURE 23: FENÊTRE PRINCIPALE APRÈS LE BALAYAGE

Page 39
 Explication
Dans notre application le balayage du réseau se fait automatiquement chaque 5 minutes
en interrogeant chaque équipement sur le réseau si l’agent SNMP installe il envoie une
requête (get_request) au client suivant l’OID donné, le client de son tour envoie une
réponse (get_response).
C’est la fenêtre la plus importante dans notre projet puisqu’elle visualise à
l’administrateur la cartographie des réseaux et toutes les options et les choix qu’il peut les
faire. Cette fenêtre contient une partie fixe composée d’un menu, d’un entête et des
boutons.
Contient aussi une partie dynamique composée d’une cartographie.
 Fenêtre de liste des routeurs
Cette fenêtre affiche dans un tableau les listes des routeurs existant dans l’architecture de
réseau en affichant leur statut, nom, adresse IP, nombre d’interface et la température.
FIGURE 24: FENÊTRE DE LISTE DE ROUTEURS

Page 40
 Fenêtre de liste des commutateurs
Cette fenêtre affiche dans un tableau les listes des routeurs existant dans l’architecture de
réseau en affichant leur statut, nom, adresse IP, nombre d’interface et leur description.
FIGURE 25 : LISTE DES COMMUTATEURS
 Fenêtre de liste des serveurs
Cette fenêtre affiche dans un tableau les listes desserveurs existant dans l’architecture de
réseau en affichant leur statut, nom, adresse IP, nombre d’interface, leur description et leur
espace mémoire RAM.
FIGURE 26: LISTE DES SERVEURS

Page 41
 Fenêtre de liste des pannes
Cette fenêtre affiche dans un tableau la liste des pannes au niveau des routeurs, serveur,
commutateur existant dans l’architecture de réseau en affichant type d’équipement, leurs
adresse IP et leur nom.
FIGURE 27: FENÊTRE DE LISTE DES PANNES AVANT LE BALAYAGE
FIGURE 28: FENÊTRE LISTE DES PANNES APRÈS LE BALAYAGE

Page 42
 Fenêtre de mesure de performance
Cette fenêtre affiche la mesure de performance pour chaque équipement comme le montre
dans la figure suivante :
FIGURE 29: FENÊTRE DE MESURE DE PERFORMANCE DES ROUTEURS
FIGURE 30: FENÊTRE DE MESURE DE PERFORMANCE DES SERVEURS

Page 43
 Les rapports qui sont généré par notre l’application : Notre application génère trois
rapports :
- Rapport des routeurs.
- Rapport des commutateurs.
- Rapport des serveurs.
 Rapport des routeurs. Ce rapport contient tous les informations des routeurs
existant dans l’architecture réseau.
FIGURE 31: RAPPORT DES ROUTEURS

Page 44
 Rapport des commutateurs : Ce rapport contient toutes les informations des
commutateurs existant dans l’architecture réseau :
FIGURE 32: RAPPORT DES COMMUTATEURS

Page 45
 Rapport des Serveurs : Ce rapport contient toutes les informations des serveurs
existant dans l’architecture réseau.
FIGURE 33: RAPPORT DES SERVEURS

Page 46
 Fenêtre Gestion d’équipements
FIGURE 34: FENÊTRE DE GESTION DES ÉQUIPEMENTS
 Fenêtre de gestion des comptes
Cette fenêtre permet de gérer (ajouter, supprimer et modifier) les comptes administrateurs et
permet aussi d’afficher la liste d’administrateur.
FIGURE 35: FENÊTRE GESTION DE COMPTES

Page 47
 Fenêtre de configuration des notifications
Cette fenêtre permet de changer l’adresse mail que l’application va envoyer des notifications
FIGURE 36: FENÊTRE DE GESTION DE NOTIFICATION
FIGURE 37: NOTIFICATION APRÈS LE BALAYAGE

Page 48
 Fenêtre de scan des ports
Cette fenêtre permet de scanner les ports des équipements en entrant les adresse IP, il ya deux
cas de scan :
 Scan par un seul port précis.
 Scan la plage des ports
FIGURE 38: FENÊTRE DE SCAN DE PORT
IV. CONCLUSION
Dans ce chapitre nous avons décrit les principales images écrans de notre application. Ces
images contiennent des tests réels effectues au sein de L'agence de Tunisie Telecom
Jendouba.
Nous avons essayé de rendre nos programmes les plus claires possibles, pour permettre aux
autres développeurs la mise à jour de cette application.

Page 49
CONCLUSION GÉNÉRALE
Il est largement reconnu que l'informatique support et vecteur des transmissions des
connaissances joue un rôle très important dans le secteur de l'information.
A l'instar des autres facteurs de production, l'informatique est un variable facteur de progrès
socio-économique au service de développement de toute notion. C'est pourquoi il est devenu
impératif majeur pour les pays en développement de maitriser cet outil de savoir en gérant de
façon 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 réseaux informatique se situe dans cette optique et se veut être l'outil cohérent
d'intégration et d'exploitation du patrimoine informationnel. Il devra ainsi transcender le
cloisonnement entre administration publique, entreprises privées, universités, laboratoires de
recherche, bibliothèques nationales, ... pour devenir un réseau automatise de coordination et
d'échanges entre les diverses afin d'établir des complémentaires et de meilleurs synergies.
Le travail que nous avons réalisé à la compagnie de Ciment de Bizerte, présenté dans ce
rapport, consiste à développer un outil d'administration réseaux, et effectue les objectifs,
proposes par les spécialités réseaux, qui sont les suivants :
 Exploitation du réseau (afficher la cartographie du réseau).
 Mesurer les performances et superviser les changements d'architecture du réseau.
 Détection des pannes.
 Notification (mail).
Pour concrétiser ces objectifs nous avons adopté une démarche simple et claire.
Nous avons suivi les étapes de cette démarche en décrivant dans un premier lieu les besoins à
satisfaire.
Pour la conception, nous avons la méthode 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 spécifies et nous faciliter les taches de programmation.
A la dernier étape du projet, nous avons réalisé la majorité des objectifs souhaites en utilisant
un langage puissant de programmation à savoir JAVA.

Page 50
Enfin, nous avons réalisé une application (Client-serveur) permettant de superviser et
contrôler le réseau de compagnie, mais ce dernier très couteux de point de vue temps de
processeur, ce qui est une solution non optimale.

Page 51
BIBLIOGRAPHIE
LIENS INTERNET
 SNMP
[1] http://ram-0000.developpez.com/tutoriels/reseau/SNMP/
 Administration Réseau
[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 52
ANNEXE :
LE PROTOCOLE SNMP
Objectif de document : Dans cette annexe on va présenter le protocole SNMP, le principe de
fonctionnement et les différents messages entre les différents agents pour bien éclaircir notre
idée.

Pfe 2015

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Viewers also liked

Viewers also liked (20)

Similar to Pfe 2015

Similar to Pfe 2015 (20)

Pfe 2015