|
REPUBLIQUE DU SENEGAL
***** * UNIVERSITE CHEIKH AN*********
TA DIOP DE DAKAR
ECOLE SUPERIEURE POLYTECHNIQUE
DEPARTEMENT GENIE
INFORMATIQUE
MEMOIRE DE FIN DE CYCLE
Pour l'obtention du
:
DIPLOME D'INGENIEUR DE CONCEPTION (DIC)
|
SUJET :
MISE EN PLACE D'UNE PLATE-FORME
D'INTEGRATION
D'OUTILS DE SUPERVISION :
CAS DU CTMI-UEMOA
|
Lieu de stage : CTMI-UEMOA
Période de stage : 02/2008 - 07/2008
Présenté et soutenu par Professeur
encadreur Maitre de stage
SAKITI Lionel Mr Mamadou NIANG Mme Fatou Tounkara
SECK
Qui peut trouver une femme vertueuse ? Elle a bien
plus de valeur que les perles.
Le coeur de son mari a confiance en elle, Et les
produits ne lui feront pas défaut.
Elle lui fait du bien, et non du mal, Tous les jours
de sa vie.
Elle se procure de la laine et du lin, Et travaille
d'une main joyeuse. Elle est comme un navire marchand, Elle amène son
pain de loin.
Elle se lève lorsqu'il est encore nuit, Et
elle donne la nourriture à sa maison et la tâche
à
ses servantes.
Elle pense à un champ, Et elle l'acquiert
;
(...) Elle ceint de force ses reins, Et elle affermit
ses bras.
Elle sent que ce qu'elle gagne est bon ; Sa lampe ne
s'éteint point pendant la nuit.
(...)Elle tend la main au malheureux, Elle tend la
main à l'indigent.
Elle ne craint pas la neige pour sa maison, Car toute
sa maison est vêtue de cramoisi. (...)Son mari est
considéré aux portes, Lorsqu'il siège avec les anciens du
pays.
(...) Elle est revêtue de force et de gloire,
Et elle se rit de l'avenir.
Elle ouvre la bouche avec sagesse, Et des
instructions aimables sont sur sa langue.
Elle veille sur ce qui se passe dans sa maison, Et
elle ne mange pas le pain de paresse.
Ses fils se lèvent, et la disent heureuse ;
Son mari se lève, et lui donne des louanges :
(...) La femme qui craint l'Éternel est celle
qui sera louée.
Récompensez-la du fruit de son travail, Et
qu'aux portes ses oeuvres la louent.
Proverbes 31 : 10 -31 (La Bible)
DEDICACES
Au~ourd'hui, plus que tout,
de désire qu'~ mes cStés, siège en son
temps,
(Une toi, pleine de ta grdce,/aman
|
Je déd~e cette oeuvre
A papa~ pour tout,
ets-urtou~les-wes-~ervuv,o~
A nies- frères- et s-oeurs- :
Lewis-~ Kate~ Aurel~ AlvbreetBelvbre A
lajeutes-s-e des- as-s-eniblées- de'Dieude Baobabs-
A trmien. 'Drieet, pour toutes-
ces- belles- artées-
|
REMERCIEMENTS
Je remercie :
Le Seigneur Tout Puissant, parce que je suis
la prunelle de ses yeux.
Merci à mon ami Jésus Christ, le fils
de DIEU qui a donné sa vie pour moi, sans quoi, je ne serais
pas là.
Tonton et Tanti THON, pour tout ce
que vous avez fait pour moi, pendant ces cinq années. Mr Mamadou
NIANG, Mon professeur encadreur pour toutes ses orientations et
conseils. Tout le personnel enseignant de l'ESP, pour la
qualité de l'enseignement dispensé.
Le pôle informatique et
technique pour leur disponibilité et leur appui qu'ils
n'ont sans cesse apporté tout au long de mon stage, en particulier
Mme Fatou Tounkara SECK, la chef du pôle.
Mr Ibrahima MBENGUE, Responsable
Base de données et Applications, pour toutes ses orientations
techniques.
Tout le personnel du CTMI-UEMOA, d'aucuns
pour leur sourire, d'autres pour leur aide sans oublier le club du
petit-déjeuner.
Issa Ibrahim pour m'avoir
épaulé durant tous ces mois de collaboration. Ma famille
en Jésus Christ, qui n 'a de cesse de me soutenir dans la
prière.
Mes amis de l'ESP, pour ces trois
belles années que nous avons passés ensemble.
A~ANT-PROPOS
L'Ecole Supérieure Polytechnique a, entre autres, pour
vocation de former des ingénieurs de conception en informatique. Cette
formation qui s'échelonne sur trois années est sanctionnée
par la délivrance d'un diplôme : le diplôme
d'ingénieur de conception en informatique. Ces ingénieurs
bénéficient d'une bonne formation théorique. La sanction
de cette formation passe par une expression pratique des connaissances acquises
à l'école. Dans l'accomplissement de ces objectifs, nous sommes
donc appelés à effectuer un stage, en entreprise, qui permettra
de mettre en application les connaissances acquises. Ledit stage fait l'objet
d'un mémoire écrit et dûment soutenu. Nous avons accompli
ce stage au sein du pôle informatique et technique du CTMI-UEMOA (Centre
de Traitement Monétique Interbancaire de l'Union Economique et
Monétaire Ouest Africaine) qui représente un cadre
agréable, mais aussi intégrateur des nouvelles technologies.
La question qui nous a été soumise, dans le
cadre du stage est : Comment contrôler aisément les outils de
supervision mis en place au sein du CTMI-UEMOA ? Cette question constitue,
alors la base de notre travail de mémoire. L'approche que nous retenons
- et qui constitue le thème de notre mémoire - est le
déploiement d'une plate forme qui permettra l'intégration des
différents outils de supervision. Nous reconnaissons l'appui de
l'équipe du pôle informatique et technique dans ces diverses
interventions.
des
Table matières
SIGLES ET ABREVIATIONS 6
TABLE DES FIGURES 7
INTRODUCTION 8
CHAPITRE 1 : EXPLOITATION ET SUPERVISION
INFORMATIQUE
1. Présentation du CTMI-UEMOA 12
2. Problématique 13
3. Les outils de supervision 14
3.1 Supervision Réseaux 14
3.2 Supervision Système et Bases de données 19
4. Logique d'intégration des outils de
supervision 26
4.1 Structure générale d'un outil de supervision
26
4.2 Niveaux d'intégration 27
CHAPITRE 2 : ANALYSE ET CONCEPTION DE LA PLATE-FORME
1. Choix de la méthode 32
2. Analyse 34
2.1 Analyse des besoins 34
2.2 Analyse applicative 59
3. Conception 63
3.1 Le pattern MVC (Modèle-Vue-Contrôleur) 63
3.2 Modélisation des interactions 64
3.3 Diagramme de classe conception 72
CHAPITRE 3 : REALISATION ET DEPLOIEMENT DE LA
PLATE-FORME
1. Choix technologiques 76
2. Structure des données 78
2.1 La base de données de la plate-forme 78
2.2 Intégration des données 80
3. Structure de la plate-forme d'intégration
81
3.1 Communication entre les composants de la plate-forme 81
3.2 Les interfaces Homme-Machine 86
3.3 Déploiement de la plate-forme 87
CONCLUSION ET PERSPECTIVES 90
BIBLIOGRAPHIE 93
ANNEXES 94
et
Sigles abréviat ions
Nous présentons ici les sigles et abréviations que
nous utiliserons dans le document.
|
BCEAO
|
Banque Centrale des Etats de l'Afrique de l'Ouest
|
|
CTMI-UEMOA
|
Centre de Traitement Monétique Interbancaire de l'UEMOA
|
|
DNS
|
Domain Name Service
|
|
GLPI
|
Gestion Libre de Parc Informatique
|
|
HTTP
|
HyperText Transfer Protocol
|
|
IMAP
|
Internet Message Access Protocol
|
|
JMX
|
Java Management eXtensions
|
|
MVC
|
Model - View - Controller
|
|
NNTP
|
Network News Transfer Protocol
|
|
OCSING
|
Open Computer System Inventory Next Generation
|
|
OMT
|
Object Modeling Technique
|
|
PEAR
|
PHP Extension and Application Repository
|
|
PHP
|
PHP Hypertext Preprocessor
|
|
POP3
|
Post Office Protocol Version 3
|
|
SMTP
|
Simple Mail Transfer Protocol
|
|
SNMP
|
Simple Network Management System
|
|
SOAP
|
Simple Objet Access Protocol
|
|
UEMOA
|
Union Economique Monétaire Ouest Africaine
|
|
UML
|
Unified Modeling Language
|
|
VSAT
|
Very Small Apertute Terminal
|
Table des figures
Liste des figures
Figure n° I-4-1: Niveaux d'intégration des
outils de supervision 27
Figure n° II-2-1: Cas d'utilisation du
système par un utilisateur générique 39
Figure n° II-2-2: Cas d'utilisation du
système par un exploitant 40
Figure n° II-2-3: Cas d'utilisation du volet
d'administration du système 40
Figure n° II-2-4: Cas d'utilisation du
système 41
Figure n° II-2-6: Diagramme de séquence
illustrant le processus d'authentification 43
Figure n° II-2-7: Scénarii de la surveillance
générale 44
Figure n° II-2-8: Diagramme de séquence
illustrant le processus de génération d'un état
45
Figure n° II-2-9: Scénarii de gestion
Incidents 46
Figure n° II-2-11: Diagramme de séquence
illustrant le processus de génération d'une alerte
52
Figure n° II-2-13: Diagramme de séquence
illustrant la génération d'alerte sauvegarde 53
Figure n° II-2-14: Diagramme de séquence
illustrant la génération d'alerte GLPI 53
Figure n° II-2-15: Diagramme de séquence
illustrant la génération d'alerte incident 54
Figure n° II-2-16: Scénarii de gestion des
utilisateurs 55
Figure n° II-2-17: Procédure de gestion d'une
alerte 59
Figure n° II-2-18: Procédure de gestion d'un
incident 60
Figure n° II-2-19: Les différents
états d'une alerte 61
Figure n° II-2-20: Les différents
états d'un incident 62
Figure n° II-3-1: Pattern MVC 63
Figure n° II-3-2: Diagramme de communication
illustrant l'ouverture d'un nouvel incident 65
Figure n° II-3-3: Diagramme de séquence
illustrant la résolution d'un incident 67
Figure n° II-3-4: Diagramme de communication
illustrant la génération d'une alerte 68
Figure n° II-3-5: Diagramme de séquence
illustrant le processus générique de transfert 69
Figure n° II-3-6: Processus d'administration et de
maintenance du système 70
Figure n° II-3-7: Diagramme de communication
illustrant le processus de création générique
71
Figure n° II-3-8 : Diagramme de classe illustrant le
modèle du domaine 73
Figure n° II-3-9 : Diagramme de classe illustrant
l'architecture de la plate-forme 74
Figure n° III-3-1: Illustration de la
procédure d'authentification 81
Figure n° III-3-2: Appel des contrôleurs
modulaires 82
Liste des tableaux
Tableau n° I-3-1 : Fonctionnalités de WhatsUp
Professionnel 17
Tableau n° I-3-2 : Ressources supervisées par
ApplicationManager 20
Tableau n° I-3-3 : Fonctionnalités de
ApplicationManager 23
Tableau n° II-2-1 :Matrice des menus utilisateur
57
Tableau n° II-2-2 : Tableau récapitulatif des
cas d'utilisation 58
Tableau n° III-2-1 : Mappage entre la table Syslog
et la table Alerte 80
INTRODUCTION
L'informatique est au coeur de l'entreprise, quelque soit son
secteur d'activité. On peut facilement comparer la place que joue
l'informatique au sein d'une entreprise à celle que joue le
système nerveux chez l'être humain. En effet, l'informatique est
au centre de l'activité, et doit fonctionner pleinement et en
permanence. Les activités des entreprises reposent essentiellement sur
leurs systèmes informatiques. Ces derniers sont liés de
façon intrinsèque au bon fonctionnement de l'entreprise. La
continuité dans les services offerts est un facteur
prépondérant dans la survie d'une entreprise parce que la rupture
dans l'offre de ces services constitue une perte, souvent énorme pour
une entreprise.
Il est alors important de prévenir et de gérer
les problèmes qui surviennent, afin de garantir, non seulement la
qualité des services fournis mais aussi et surtout la vie de
l'entreprise.
Superviser veut dire avoir le regard sur, observer en vue de
prévenir d'éventuels problèmes mais aussi et surtout
réagir dans des brefs délais. La supervision consiste à
indiquer et à juger de l'état d'un système ou d'un
réseau. La supervision permet de surveiller, de rapporter et d'alerter
les fonctionnements normaux et anormaux des systèmes et réseaux
informatiques.
La supervision répond aux préoccupations suivantes
:
· Technique : surveillance du réseau et des
systèmes,
· Applicative : surveillance des applications et des
processus métiers.
A ces préoccupations majeures s'ajoutent les actions
indispensables à la surveillance du système. Ce sont les actions
automatisées ou manuelles en fonction d'alertes définies.
La supervision s'applique à plusieurs domaines :
· les réseaux informatiques,
· les systèmes informatiques
· les ressources techniques,
· les bases de données,
· les applications,
· les systèmes d'information
La supervision permet de suivre l'état des
systèmes, des réseaux et des services offerts. Plusieurs outils
logiciels ou matériels implémentent la supervision. Ces outils de
supervision s'adaptent à un domaine d'application. Une entreprise qui
veut superviser son système d'information se dote alors de plusieurs
outils de supervision.
Le CTMI-UEMOA (Centre de Traitement Monétique
Interbancaire de l'Union Economique et Monétaire Ouest Africaine) n'est
pas en marge de cette évolution. Le CTMIUEMOA offre des services
monétiques à toutes les banques et établissements
financiers et postaux de l'espace UEMOA. Les services monétiques offerts
ne doivent pas connaitre une rupture. Les services fournis ont pour support
principal le réseau du CTMI-UEMOA et sont offerts via des ordinateurs,
serveurs, GAB (Guichet Automatique de Banque), etc. La supervision de ces
systèmes et réseaux informatiques s'avère donc
indispensable. L'équipe informatique et technique est en charge du
contrôle des ressources et réseaux informatiques du CTMI-UEMOA.
Pour ce faire, chaque responsable d'un domaine de
compétence met en oeuvre un ou plusieurs outils logiciels ou
matériels qui lui permettent de superviser les différentes
ressources. Les outils de supervision sont gérés par
l'équipe d'exploitation informatique. L'utilisation de tous ces outils
de supervision pose plusieurs problèmes à l'équipe
d'exploitation informatique.
· Les alertes ne sont pas centralisées.
· Il est difficile d'apprécier une panne parce que
chaque outil présente une partie de solution.
· Les outils de supervision n'intègrent pas des
fonctions nécessaires à un suivi temps réel à moins
d'avoir les yeux rivés sur les différents écrans.
· L'exploitation des résultats de supervision est
manuelle parce que les outils de supervision n'intègrent pas les
procédures d'exploitation propres aux besoins du CTMI-UEMOA.
Ces différentes limites font ressortir alors plusieurs
questions fondamentales que nous nous tentons de résoudre tout au long
de ce document :
· Comment centraliser toutes les alertes provenant des
différents outils de supervision ?
· Comment rassembler les différents outils de
supervision ?
· Comment ajouter aux outils de supervision des
fonctionnalités qui sont spécifiques aux besoins du
CTMI-UEMOA?
Afin de répondre à ces différents
besoins, nous avons proposé, étudié et mis en place une
plateforme utilisateur qui permet de fédérer les
différents outils de supervision et d'intégrer les
procédures d'exploitation inhérentes aux processus métier
du CTMI-UEMOA.
Ce document qui est un résultat du projet qui nous a
été assigné, est subdivisé en trois parties.
Dans un premier chapitre, après avoir succinctement
posé le problème, nous définirons les différents
outils d'exploitation et de supervision actuellement mis en place au sein du
CTMI-UEMOA en présentant la logique de leur intégration.
Dans un second chapitre, nous étudierons la mise en
place de ladite plateforme depuis l'expression des besoins par l'utilisateur
final jusqu'à sa conception en passant par une analyse claire et concise
de ladite plateforme.
Dans un troisième chapitre, nous justifierons les
choix technologiques notables, pour aboutir à l'implémentation et
au déploiement de la plateforme d'intégration.
Enfin, nous aborderons ce qui a été
réellement fait durant ce stage, pour finir par les perspectives,
permettant ainsi à toute personne intéressée de poursuivre
l'oeuvre que nous avons commencée.
CHAPITRE 1
EXPLOITATION ET SUPERVISION INFORMATIQUE
Les problèmes liés à l'informatique
doivent être réduits au maximum, car une indisponibilité du
système d'information peut être la cause d'une perte énorme
pour l'entreprise. Deux phases sont donc importantes dans la gestion des
systèmes et réseaux informatiques:
· Superviser
Superviser c'est surveiller, visualiser et analyser. La
supervision permet de suivre la disponibilité du système afin de
prévenir les pannes ou les indisponibilités. La supervision
conduit à une remontée d'information rapide et une durée
d'intervention minimale.
· Exploiter
Exploiter c'est piloter et agir. L'exploitation est
l'ensemble des actions qui permettent de réagir face aux
résultats issus de la supervision afin de garantir une
disponibilité quasi- permanente du système.
1. Présentation du
CTMI-UEMOA
Le CTMI-UEMOA (Centre de Traitement Monétique
Interbancaire de l'UEMOA) est une structure de traitement monétaire
créée sous forme de société anonyme en janvier
2005. Il a été initié par la BCEAO (Banque Centrale des
Etats de l'Afrique de l'Ouest) pour pallier aux carences
d'interbancarité et d'interopérabilité entre les
systèmes des banques, établissements financiers et postaux de
l'UEMOA.
Le CTMI-UEMOA est chargé d'assurer des services
monétiques à trois niveaux :
· services interbancaires (interopérabilité
nationale, régionale (GIM-UEMOA) et internationale (VISA, MasterCard
etc.) des transactions
· services bancaires par délégation
(permanente, temporaire ou en secours)
· services complémentaires (suivi, maintenance,
vente, support).
Le CTMI-UEMOA est le volet technique du projet
d'interconnexion des banques et établissements financiers et postaux de
l'UEMOA. Il a donc à charge la mise en place matérielle et le
suivi technique inhérant au bon fonctionnement des différentes
transactions. Il relie les huit pays de l'espace UEMOA afin d'offrir une
communication constante entre eux, mais aussi avec les opérateurs
internationaux.
Pour ce fait le CTMI-UEMOA dispose d'équipements
réseau dans chacun de ces pays, entre autres, une antenne VSAT et des
routeurs. Cette infrastructure déployée dans les
diiférents pays de l'UEMOA permet de désservir les banques,
établissements bancaires, financiers et postaux desdits pays. Une
interconnexion satellitaire relaie les communications entre les pays. Une
liaison Internet chez des fournisseurs d'accès Internet permet d'obtenir
un relai constant. L'architecture interne du CTMI-UEMOA est constituée
de serveurs pour le stockage et le traitement des données
monétiques. Ces équipements doivent être disponibles de
manière continu.
Le CTMI-UEMOA est divisé en pôles. Nous avons
effectué notre stage au sein du pôle informatique et technique, au
service d'exploitation informatique.
NB : Des annexes sont insérées
afin de présenter en détail le CTMI-UEMOA : sa genèse et
ses activités.
2. Problématique
Un réseau informatique peut être l'objet de
nombreux problèmes tels que l'indisponibilité d'un serveur ou la
défaillance physique du réseau. Les risques sont multiples. De
plus, le CTMI-UEMOA, qui est un centre monétique, s'occupe de
l'interconnexion de toutes les banques et établissements financiers et
postaux de l'UEMOA (une centaine environ). Il gère également les
transactions monétiques entre ces derniers. Toute
indisponibilité, même d'une seconde, pourrait coûter des
millions de FCFA. La nécessité d'empêcher ou
d'atténuer les indisponibilités est vitale.
La supervision est donc un volet prioritaire dans le maintien
des services offerts aux adhérents du CTMI-UEMOA. Il y a plusieurs
outils de supervision qui répartissent la surveillance des ressources du
CTMI-UEMOA, selon les différents domaines de compétence. Les
différents domaines sont : les réseaux et télécoms,
systèmes, bases de données et applications. Le contrôle de
ces outils de supervision est rendu difficile pour l'exploitation informatique
parce que chacune d'entre elles présente une partie de solution dans la
gestion des différents incidents qui pourraient survenir. Les
préoccupations majeures qui découlent de ces difficultés
et contraintes sont :
· Comment intégrer les outils de supervision mis en
place au sein du CTMIUEMOA ?
· Comment ajouter des fonctionnalités
inhérentes aux procédures d'exploitation comme celles
élaborées par le CTMI-UEMOA ?
Notre objectif est donc de mettre en place une plate-forme
qui agrège tous les outils de supervision. En effet, quand on
considère tous les outils de supervision mis en place, on se demanderait
à quoi servirait une plate-forme de plus. En fait,
l'intérêt réside en ce que la plate-forme doit
présenter une vue globale des outils de supervision et compléter
leurs fonctionnalités. La plate-forme d'intégration doit
exploiter leur potentiel pour améliorer et faciliter l'exploitation et
la supervision informatique.
Notre objectif est de rendre la plate-forme extensible,
c'est-à-dire capable d'intégrer de façon plus ou moins
simple de futurs outils d'exploitation et de supervision. L'orientation de la
conception permet de répondre alors à ces différents
besoins au travers de démarches et de modèles fortement
éprouvés.
3. Les outils de supervision
Un outil de supervision est destiné à informer
de problèmes éventuels dans le système d'information avant
que les clients ou utilisateurs ne le fassent. Afin de bénéficier
d'une surveillance routinière, permanente et efficace de l'ensemble des
ressources du CTMIUEMOA et aussi des réseaux informatiques, il est
nécessaire de confier la tâche de surveillance à des
logiciels, qui auront pour tâche de relever à intervalles
réguliers toutes les informations portant sur les systèmes et
réseaux informatiques. On bénéficie ainsi d'une
surveillance régulière.
Ces outils de supervision utilisent plusieurs
méthodes:
· Analyse des fichiers de log
· Récupération des résultats de
commandes et de scripts locaux ou distants
· SNMP : Simple Network Management Protocol
Le marché de la supervision peut être
découpé en deux grandes parties :
· Les offres éditeurs (code fermé)
· Les offres du monde libre (code ouvert)
3.1 Supervision
Réseaux
La supervision réseau porte sur la surveillance de
manière continue de la disponibilité des services en ligne, du
fonctionnement des noeuds d'interconnexion (routeurs, switchs, etc.),
l'évaluation des débits et fréquences utilisées,
mais également des flux (entrées et sorties) sur le
réseau. Les outils de supervision utilisés au sein du CTMI-UEMOA
sont logiciels ou matériels (avec des consoles embarquées).
3.1.1 Logiciel cartographique de supervision
réseau (IPSwitch WhatsUp Professionnel)
3.1.1.1 Présentation
WhatsUp Professionnel est une solution informatique pour
surveiller les réseaux. L'application fournit aux directions
informatiques des données réseaux facilement convertibles en
informations métiers et en paramètres sur lesquels on peut agir.
En surveillant de façon proactive tous les périphériques
et services critiques du réseau, WhatsUp Professionnel réduit les
délais d'interruption à la fois dommageables aux
activités, frustrants et coûteux.
WhatsUp Professionnel isole les problèmes
réseau et procure une connaissance fine des performances et de la
disponibilité du réseau. Il scrute le réseau afin
d'interroger les équipements et les services. Il alerte lorsqu'un
problème survient sur le réseau
3.1.1.2 Fonctionnalités
Le recueil d'informations se fait selon une fréquence
qui est paramétrable. Selon le résultat de ce polling, WhatsUp
Professionnel applique des actions définis par rapport au changement
d'état des équipements. Il récupère les
informations du réseau puis génère des rapports. Ces
rapports sont utilisés pour prévenir et réagir à
temps. Pour vérifier la connectivité des équipements,
WhatsUp Professionnel envoie des trames ICMP en destination des
équipements. WhatsUp Professionnel utilise les protocoles SNMP v1/2/3
pour la surveillance et l'édition des rapports. Les moniteurs de
performance de WhatsUp Professionnel recueillent les informations importantes
des périphériques actifs du réseau. Ils exploitent ces
données pour créer des rapports de tendance sur l'utilisation et
la disponibilité des périphériques.
WhatsUp Professionnel est installé avec cinq moniteurs de
performance :
· Utilisation CPU
· Utilisation disque
· Utilisation mémoire
· Utilisation des interfaces
· Temps de latence ping et disponibilité
WhatsUp Professionnel présente, sous forme de
graphiques, des données en temps réel. Ces données
concernent les performances et la disponibilité des équipements
réseau.
Il utilise une base de données relationnelle
(Microsoft SQL Server) pour stocker l'information sur les différents
équipements surveillés dans le réseau. Le tableau
ci-dessous recense toutes les fonctionnalités de WhatsUp.
Mesures de Performances
|
Temps de réponse
|
Ping
|
Polling par fréquence paramétrée
|
Disponibilité
|
Ping
|
|
SNMP
|
|
SNMP
|
|
SNMP
|
|
Moniteur TCP/IP
|
|
Moniteur passif
|
Envoyé par l'équipement
|
|
|
|
Remontée d'Alertes
|
Mail
|
Via serveur mail externe
|
Déclenchés selon les seuils
paramétrés
|
Alarme Web
|
Portail web
|
|
Console local
|
|
Console local
|
|
|
|
Cartographie réseau
|
Cartographie dynamique
|
Etat des ressources Etat des liens
|
Changement d'état constaté en temps réel
par les couleurs
|
Découverte des ressources
|
Manuel, dynamique
|
Propriétés modifiables
|
Type de ressources
|
Equipements réseau Ordinateurs
|
Adressage IP et IPX
|
|
|
Reporting
|
Reporting système
|
Statistiques systèmes d'une période sur les
moniteurs
|
Logs, Erreurs sur une période
|
Reporting de Ressources
|
Statistiques sur un équipement
|
Changements sur une période
|
Reporti ng de groupe de Ressources
|
Statistiques sur un groupe équipement
|
Changements sur une période avec classement
croissant/décroissant
|
Production ponctuel de Reporting
|
Manuel
|
Selon le besoin
|
Production régulier de Reporti ng
|
Automatique
|
Envoi par mail
|
|
|
|
Modules Systèmes
|
Bases de données MS SQL
|
Intégré
|
|
Serveur web
|
http
HTTPS (Sécurisé)
|
Accès à la console via portail web
|
Gestionnaire de compte
|
Administrateur Utilisateur simple
|
Restriction d'accès
|
|
Tableau n° I-3-1: Fonctionnalités de
WhatsUp Professionnel
3.1.2 Logiciel de suivi des messages log (Orion
SolarWinds SyslogViewer)
SolarWinds est une plateforme de gestion réseau qui
s'adapte à la croissance du réseau et étend les besoins de
supervision de réseau. Il présente plusieurs modules :
· SystemManager
· SyslogViewer
· NetworkDiscovery
· TrapViewer
SyslogViewer est une application de gestion de messages syslog.
Il intègre un serveur syslog qui reçoit, analyse et qualifie les
messages syslog.
Un journal au format syslog comporte dans l'ordre les
informations suivantes : la date a laquelle a été émis le
log, le nom de l'équipement ayant généré le log, le
processus qui a déclenché cette émission, le niveau de
gravité du log, l'identifiant du processus ayant
généré le log et enfin le message. Les niveaux de
gravité Syslog, souvent appelés level sont au nombre de huit
représentés par un chiffre de 0(Emergency) à 7(Debug):
· 0 Emergency
· 1 Alert
· 2 Critical
· 3 Error
· 4 Warning
· 5 Notice
· 6 Informational
· 7 Debug
Cette indication est particulièrement importante car
elle normalise de fait la représentation de la gravité d'un log,
ce qui rend par exemple possible l'interopérabilité entre
équipements de collecte de logs et équipements de
génération d'alertes.
ORION SolarWinds SyslogViewer intègre des fonctions
supplémentaires comme la définition d'une base d'alertes et le
filtrage des messages syslog. Ce module permet de résoudre rapidement
des problèmes en analysant ces messages syslog. Il liste et analyse
toutes les transactions qui passent au niveau du pare-feu.
En outre, il stocke les messages syslog dans une base de
données au format Microsoft SQL express.
3.2 Supervision Système et Bases de
données La supervision système porte sur :
· L'utilisation du processeur
· L'utilisation de la mémoire
· L'utilisation des unités de stockage physiques et
logiques
Superviser les bases de données et les applications
est moins standard parce qu'elle est propre à la structure de
l'application ou aux différentes vues qu'offre la base de
données. Un outil de supervision orientée vers les bases de
données et les applications est plus spécifique à certains
types de bases de données
3.2.1 Logiciel de suivi des systèmes et
applications (ManageEngine ApplicationManager)
3.2.1.1 Présentation
ApplicationManager est un logiciel de gestion de systèmes
et d'applications qui facilite la surveillance des serveurs d'applications, des
bases de données, des serveurs, la gestion des services, la surveillance
des sites Internet et la surveillance d'applications personnalisées.
ApplicationManager surveille les performances et la disponibilité des
différentes ressources système et fournit de puissantes
capacités de gestion d'erreurs et de notification.
3.2.1.2 Fonctionnalités
ApplicationManager surveille les performances et la
disponibilité des serveurs d'applications (JBoss, WebSphere, WebLogic,
Tomcat, Microsoft .NET, Oracle AS), des bases de données (MySQL, SQL
Server, Oracle, IBM DB2), des sites Internet, des systèmes (Windows,
Linux, Solaris, AIX, HP-UX, FreeBSD, Mac OS) et d'autres services.
Surveillance d'applications
· Microsoft .NET
· JBoss
· Tomcat
· WebLogic
· Web sphere
· Oracle AS
|
Surveillance de bases de données
· Oracle
· MySQL
· SQL Server
· DB2
|
Surveillance de serveurs de messagerie
· Microsoft Exchange Server
· Autres serveurs de messagerie
|
|
Gestion de serveurs
|
Surveillance de sites
|
Surveillance de serveurs
|
· Windows
|
Internet
|
Web
|
· Linux
|
· URL
|
· SOAP - Web
|
· Solaris
|
· séquences d'URL
|
Services
|
· IBM AIX
|
· contenus d'URL
|
· Apache
|
· HP-Unix
|
|
· IIS
|
· FreeBSD
|
|
· PHP
|
· Mac OS
|
|
· Autres serveurs Web
|
Surveillance personnalisée
|
Autres dispositifs de
|
Autres caractéristiques
|
· Consoles JMX & SNMP
|
surveillance
|
· Gestion de services
|
· Surveillance de scripts
|
· Transactions Web
|
professionnels
|
· Windows Performance
|
· services
|
· Gestion d'erreurs
|
Counters
|
|
· Rapports
|
|
Tableau n° I-3-2: Ressources
supervisées par ApplicationManager
ApplicationManager gère les spécificités
de chaque type de système ou d'application. Par exemple pour une base de
données Oracle, il affiche les tablespaces, les fichiers de
données, les sessions. Deux instances ont été
déployées au sein du CTMI-UEMAOA pour distinguer la supervision
système et la supervision base de données et applications.
La supervision système concerne les serveurs
monétiques (production, recette et backup et les serveurs internes
(proxy, messagerie, site web, serveur de fichiers, servers d'applications). Ils
sont principalement du type IBM AIX et Microsoft Windows Server 2003.
ApplicationManager fournit entre autres le temps de connexion, le taux
d'utilisation de la mémoire, des processeurs et disque dur.
La supervision Base de données et Applications se
reporte aux bases de données Oracle et applications utilisées
pour l'activité monétique mais aussi les applications
utilisées pour le fonctionnement interne du CTMI-UEMOA.
ApplicationManager utilise SNMP pour le recueil
d'informations. Pour les bases de données, ApplicationManager interroge
des vues spécifiques. ApplicationManager intègre une gestion
d'alertes qui équivaut à définir des seuils sur certains
paramètres.
Mesures de Performances
SNMP
SNMP
SNMP
SUPERVISION SYSTEME
SNMP
SNMP
SNMP
SNMP
SNMP
Moniteur TCP/IP
SUPERVISION BASES DE DONNEES
SNMP
SNMP
SNMP
SNMP
SNMP
Tableau de bord
Temps de réponse
Disponibilité
Santé
Statistiques interface
Statistiques CPU
Statistiques E/S
Utilisation des Disques
Statistiques Mémoire
Services:
HTTP, HTTPS, IMAP4, POP3, Radius, SMTP, TELNET, etc.
|
|
Etat global de la BDD
Statistiques des tablespaces, des tables...
Performance de la SGA
Statistique des fichiers de données
|
|
Statistiques sur l'ensemble des sessions
Polling par fréquence paramétrée
|
|
Statistique sur les « undo segment »
|
SNMP
|
|
|
|
|
Remontée d'Alertes
|
Mail
|
Via serveur
|
Déclenchés selon les seuils
paramétrés
|
SMS
|
Téléphonie IP
|
|
En local ou à distance
|
|
|
|
Ressources supervisées
|
Découverte des ressources
|
Manuel, dynamique
|
Propriétés modifiables
|
Type de ressources
|
Equipements réseau Ordinateurs, etc.
|
Adressage IP
|
Regroupement des ressources
|
Par Fonction principale
|
|
Type de systèmes (OS)
|
AIX, Windows, HP-UX, Linux, Sun Solaris, Mac, etc.
|
|
Reporting
|
Reporting système
|
Statistiques systèmes d'une période sur les
moniteurs
|
Logs, indisponibilité, Erreurs sur une période
|
Reporting de Ressources
|
Statistiques sur un équipement ou un groupe de
ressources
|
Changements sur une période
|
Reporting sur la disponibilité
|
Statistiques sur la
|
Logs, indisponibilité, Erreurs,
|
|
des ressources
|
disponibilité des moniteurs
|
temps moyens de récupération sur une
période
|
Reporting sur la santé des ressources. La
période est paramétrable
|
Statistiques sur la santé
D'un moniteur ou groupe de moniteurs
|
Etat (critique, avertisseur ou dégager)
|
Reporting sur le temps de réponse d'une ressource
|
Statistiques sur un groupe de moniteur
|
Temps de réponses (maximal, minimal, moyen) de tous les
moniteurs
|
Production ponctuel ou régulier de Reporting
|
Manuel ou Automatique
|
Selon le besoin (impression, format csv, format PDF) ou par
mail
|
|
|
|
Modules Systèmes
|
Bases de données MySQL
|
Intégré
|
|
Serveur web apache
|
HTTP
HTTPS (Sécurisé)
|
Accès à la console via portail web
|
Gestionnaire de compte
|
Administrateur Utilisateur simple
|
Restriction d'accès
|
Fonctionnalités supplémentaires
|
Ajout de MIB, de script, etc. dans l'environnement de travail,
Rapport de plan d'exécution, etc....
|
|
|
Tableau n° I-3-3: Fonctionnalités de
ApplicationManager
3.2.2 Logiciels de gestion du parc
informatique
3.2.2.1 GLPI (Gestion Libre de Parc Informatique)
GLPI est une application libre, distribuée sous
licence GPL destinée à la gestion de parc informatique et de
helpdesk. GLPI est une application web, développée en PHP. GLPI
est composé d'un ensemble de services PHP qui permettent de recenser et
de gérer la totalité des composantes matérielles ou
logicielles d'un parc informatique, et ainsi d'optimiser le travail des
techniciens grâce à une maintenance plus efficace.
Les fonctionnalités principales de l'application
s'articulent autour de différents axes :
· Référencement du matériel d'un parc
informatique.
o Inventaire des ordinateurs, périphériques,
réseau, imprimantes et consommables associés.
o Affectation du matériel par zone géographique
(salle, étage...), par groupes d'utilisateurs et par utilisateurs.
o Gestion des licences (acquises, à acquérir,
sites, etc.) et des dates d'expiration. o Gestion des informations commerciales
et financières (achat, garantie et extension, amortissement).
· Gestion des tickets incidents où les utilisateurs
présentent leurs problèmes o Gestion des demandes d'intervention
pour tous les types de matériel de l'inventaire.
o Gestion des interventions réalisées par vos
techniciens.
o Interface pour permettre à l'utilisateur final de
déposer une demande d'intervention.
o Réservation de matériel
· Gestion d'une base de connaissances des problèmes
utilisateurs
o Génération de rapports sur le matériel,
de rapports réseau, de rapports sur les interventions.
o gestion d'une FAQ publique.
· Gestion des états de matériel.
3.2.2.2 OCS ING (Open Computer System Inventory Next
Generation)
OCS Inventory NG est une application permettant de
réaliser un inventaire sur la configuration des machines du
réseau et sur les logiciels qui y sont installés. OCS Inventory
NG permet de visualiser cet inventaire grâce à une interface Web.
Il comporte également la possibilité de
télé-déployer des applications sur un ensemble de machines
selon des critères de recherche. Une fonction IpDiscover permet
de connaître l'intégralité des interfaces du réseau.
OCS Inventory NG est publié sous licence GNU GPL. OCS Inventory NG
permet de faire un scan complet du réseau pour en sortir au choix les
résultats suivants :
· Le numéro de série du constructeur,
l'occupation du disque dur, le système d'exploitation installé,
le processeur et la mémoire, les lecteurs logiques, les
caractéristiques des cartes vidéo et des cartes réseau,
les logiciels installés, et les utilisateurs qui se sont
connectés à la machine ;
· une vue d'ensemble de tous les logiciels
installés sur le réseau et les licences;
· une vue de toutes les connexions utilisateurs sur les
ordinateurs du réseau.
OCS Inventory NG utilise un agent, qui exécute
l'inventaire sur les machines clientes, et un server de gestion (management
server), qui centralise les résultats d'inventaire, autorise leur
affichage et la création des paquets de déploiement.
3.2.2.3 Le couplage de GLPI avec OCS Inventory NG
GLPI peut être utilisé simultanément avec
un logiciel d'inventaire automatique comme OCS Inventory NG mettant ainsi
à disposition une solution puissante et dynamique d'inventaire et de
gestion de parc informatique. OCS Inventory NG se charge, avec son
système d'agents de rapatrier l'information sur les machines pour
fournir la base de données de GLPI. Les fonctions les plus importantes
sont :
· l'inventaire automatique du parc informatique,
· la gestion des contrats de licences logiciels et des
contrats de maintenance du matériel.
· le déploiement des logiciels sur tout le
réseau.
· l'édition des statistiques sur le parc
installé et le helpdesk.
· la gestion des tickets d'interventions.
· le maintien d'une base de connaissances (FAQ).
4. Logique d'intégration des outils de
supervision 4.1 Structure générale d'un outil de
supervision
L'étude des différents outils d'exploitation et
de supervision permet de dégager les parties qui serviront à
l'intégration. Cette architecture générale facilite leur
interfaçage avec d'autres outils d'exploitation et de supervision.
· La visualisation
Les outils d'exploitation et de supervision présentent
souvent la liste des équipements sous forme de cartes ou de tableaux de
bord.
· Le reporting
Le reporting consiste à afficher des statistiques sur
les équipements ou les applications surveillées. Ces statistiques
concernent l'état, la disponibilité, les performances ou les
propriétés de ces équipements ou applicatifs. Les
différents rendus sont généralement
présentés sous forme de graphes, de tableaux ou du texte.
· La gestion des alertes
Lorsqu'une indisponibilité est détectée
ou une propriété atteint un seuil « critique », l'outil
de supervision est en mesure d'alerter. Les niveaux d'alertes sont
configurables. Les outils de supervision intègrent l'envoi des sms ou de
messages électroniques (mail).
· Authentification
Un logiciel d'exploitation et de supervision offrent une
interface d'authentification. L'authentification permet de différencier
les statuts de connexion et les rôles. Les services sont alors
assignés selon le rôle.
· Le stockage et l'accès aux
données
Les bases de données et/ou les fichiers sont les
moyens utilisés pour le stockage des données. Elles sont
utilisées pour répertorier les équipements et applicatifs
supervisés, les utilisateurs. Ils gardent aussi des traces.
Mémoire de fin de cycle CHAPITRE
1
SAKITI Lionel
|
27
|
|
|
4.2 Niveaux d'intégration
La logique d'intégration est élaborée en
tenant compte de la structure sus-définie.
L'intégration par couches permet d'éviter la
redondance dans l'analyse et la conception de la plate-forme
d'intégration. Elle facilite l'extension vers de nouveaux outils
d'exploitation et de supervision. Par exemple, si le pôle
monétique se dote d'un outil de supervision des GAB, il est
aisément intégrable au sein de cette plate-forme
d'intégration
Figure n° I-4-1: Niveaux d'intégration
des outils de supervision
4.2.1 Intégration des
données
Chaque application de supervision met en oeuvre un processus
de stockage de ses données. Intégrer toutes ses données
revient alors à effectuer une sélection des données
importantes et significatives pour la plate-forme d'intégration. Ces
données correspondent aux entités métier des outils de
supervision. Les données ainsi puisées peuvent refournir une
nouvelle base de données .Cette intégration nécessite
alors une étude laborieuse de la structure de ces processus de stockage.
On peut utiliser deux modes d'intégration :
· Une intégration dynamique
L'intégration dynamique consiste à copier les
données vers la base de données fédératrice
lorsqu'on a besoin de ces données. Donc seules les informations
nécessaires seront chargées et au moment voulu. Elle peut
être provoquée par une action utilisateur.
· Une intégration temporelle
Elle rapatrie toutes les informations après un temps
donné. Donc la synchronisation se fait de manière
fréquentielle.
Néanmoins, il convient de définir un
modèle unique de données afin d'effectuer un mappage clair et
unifié des données. Par exemple plusieurs champs d'une table
donnée peuvent être concaténés dans un champ unique.
Une table dans la plate-forme d'intégration peut être obtenue par
une jointure sur plusieurs tables.
L'application de l'intégration des données
propre à ce cas de figure sera explicitée dans la phase de
conception. Cette étape répond à la question : quelles
données dois-je réutiliser ? SolarWinds SyslogViewer et WhatsUp
IpSwitch utilisent des bases de données Microsoft SQL Server.
ApplicationManager et GLPI utilisent des bases de données MySQL.
4.2.2 Intégration de
l'authentification
Chaque application intègre un mode d'authentification.
D'après wikipedia, l'authentification est la procédure qui
consiste, pour un système informatique à vérifier
l'identité d'une entité (personne, ordinateur, etc.) afin
d'autoriser l'accès de cette entité à des ressources.
L'authentification permet de restreindre l'accès aux
fonctionnalités d'une application. La plate-forme
fédératrice doit permettre d'accéder directement aux
outils de supervision sans nécessiter plusieurs niveaux
d'authentification. Le but de l'intégration d'authentification est de
fournir, si possible, une authentification unique.
ApplicationManager fournit plusieurs types d'utilisateurs
(opérateur, utilisateur, administrateur, gestionnaire). Supposons que le
responsable système a un accès administrateur
(admin/mot_de_passe) sur ApplicationManager Système. Lorsqu'il va se
connecter sur la plate-forme fédératrice, en cliquant sur le lien
qui le redirige sur Application Manager, il apparait directement
connecté. Le but est de rendre l'authentification transparente et
unique. Elle permet de répondre à la question : Comment
accéder aux outils de supervision ?
Pour ce fait, il est nécessaire de connaitre comment
chaque outil de supervision réalise son authentification. Les outils de
supervision utilisent une base de données pour stocker les identifiants
de connexion. Par exemple, PHP permet d'utiliser les variables de session. Donc
il offre la possibilité de charger les variables dès la
première connexion. Ce qui permet de préparer l'accès
à des applications écrits avec PHP. L'accès au code source
est donc un atout.
4.2.3 Modélisation des
alertes
L'alerte désigne un signal qui avertit l'usager d'un
fait inhabituel, comme une panne ou l'arrêt d'un service. La notion
d'alertes est une fonction première des outils de supervision. Elle
incarne l'essence même de la supervision.
Leur utilisation va permettre de gérer des
systèmes d'alarme, que le programme enclenchera dans des moments
prédéfinis. Des alertes peuvent être définies selon
des seuils indiqués, des états critiques ou des
indisponibilités de services. Une alerte peut fournir un envoi de mail,
de sms ou une alarme. Chaque outil de supervision intègre plus ou moins
une remontée des alertes. La remontée d'alertes désigne le
procédé par lequel tous les signaux d'alerte émis par
différents serveurs sont reçus sur une seule machine. Donc chaque
outil de supervision reçoit les alertes émis uniquement sur les
équipements qu'il « supervise ».
Modéliser ces différents systèmes de
gestion des alertes revient à :
· Sélectionner les alertes significatives
· requalifier les alertes en utilisant des termes propres
au CTMI-UEMOA.
· Centraliser toutes les alertes vers une plate-forme
fédératrice unique
Cette modélisation permet un suivi plus efficace
compte tenu du contexte qui est relatif à l'aspect métier du
CTMI-UEMOA. Elle permet d'appliquer la gestion des alertes aux processus
d'exploitation du CTMI-UEMOA. Elle oriente et cadre de facto la
Le retour d'alertes peut se faire de plusieurs manières
:
· En cas d'emploi d'une GUI (interface graphique), ce
signal apparaît dans une boîte dédiée.
· Un bip sonore est employé
· Un mail ou un sms est envoyé
· Un message vocal est laissé sur un
téléphone
En fonction du cadre et des possibilités, un ou plusieurs
moyens peuvent être utilisés et combinés
4.2.4 Reporting
unifié
La génération de rapports constitue, avec la
remontée d'alertes les grandes fonctionnalités des outils
d'exploitation et de supervision. Elle permet de présenter l'ensemble
des informations recueillis par outil. Ces archives seront très
instructives sur le comportement d'une ressource. Ils donnent la
possibilité de connaître l'ensemble des événements
qui ont conduit à l'arrêt du service ; l'intérêt est
ainsi double, car cela va permettre de mieux comprendre la panne et d'y
remédier beaucoup plus vite ainsi que de prendre connaissance de
nouvelles « fragilités » dans un réseau. A cette
étape, il convient de répondre à la question : Qui
génère quel rapport et pourquoi ? La réponse à
cette question permet de restreindre l'accès aux rapports en fonction de
l'authentification. Par exemple, un utilisateur du pôle support et
services ne doit pas voir des rapports purement informatiques. En plus des
rapports sur la disponibilité d'un équipement que fournissent les
applications d'exploitation suscitées, la plate-forme
d'intégration présentera aussi des rapports sur les alertes et
les incidents (par semaine/ par mois/ par année).
4.2.5 Modules
Il est important de connaitre les services fournis par les
différentes plateformes déjà existants. Le but est alors
de ne pas reprendre les fonctionnalités dans leurs moindres
détails. On pourrait alors redéployer ces fonctionnalités
dans la plate-forme d'intégration quitte à les améliorer
ou à les automatiser. Ces fonctionnalités sont
redéveloppées sous forme de modules composants la plate-forme
d'intégration. L'intérêt de définir les modules
nécessaires dans une plate-forme d'intégration est d'automatiser
leur utilisation ou la rendre plus conviviale. La plupart du temps, certaines
fonctionnalités très intéressantes sont finalement mal
présentées à l'utilisateur ou ne cadrent pas
forcément pas avec les besoins du CTMI-UEMOA.
CHAPITRE 2
Analyse et Conception
Modéliser un système avant sa
réalisation permet de mieux comprendre son fonctionnement. C'est
également un moyen de maîtriser la complexité du
système et d'assurer sa cohérence.
L'analyse et la conception ont pour objectif de formaliser
les étapes préliminaires du développement d'un
système afin de rendre ce développement plus fidèle aux
besoins du client. Un modèle est un langage commun, précis, qui
est connu par tous les membres de l'équipe projet et il est donc,
à ce titre, un vecteur privilégié pour communiquer. Cette
communication est essentielle pour aboutir à une compréhension
commune et précise d'un problème donné.
Elle part des besoins tels qu'ils sont exprimés par
les utilisateurs ainsi que de l'analyse de l'existant éventuel
(c'est-à-dire la manière dont les processus à traiter par
le système se déroulent actuellement).
La phase d'analyse permet de lister les résultats
attendus, en termes de fonctionnalités, de performance, de robustesse,
d'extensibilité, etc.
La phase de conception permet de décrire le fonctionnement
futur du système afin d'en faciliter la réalisation.
1. Choix de la méthode
Il y a trois grandes familles de méthodes que sont :
· Les méthodes cartésiennes ;
Les méthodes cartésiennes ont leur origine dans
le développement des langages procéduraux. Le processus de
modélisation débute par l'identification d'une fonction globale.
Au vu de la règle de division, on procède ensuite à une
découpe cartésienne (fonctionnelle et hiérarchique) des
processus et des flux d'informations. Elles mettent en évidence les
fonctions à assurer et proposent une approche hiérarchique,
descendante et modulaire en précisant les liens entre les
différents modules. Les avantages de cette approche sont sa
simplicité et son appel au bon sens. Elle est en adéquation avec
la capture des besoins. Cependant, les efforts sont concentrés sur les
fonctions au détriment des données et les règles de
décomposition ne sont pas explicites. Les plus connues sont SA-SD
(Structured Analysis - Structured Design) de Yourdon, DeMarco, Constantine,
Gane et Sarson, SADT (Structured Analysis and Design Technique).
· Les méthodes systémiques
Elles s'appuient sur une approche systémique. Le
système est alors vu comme une structure avec un comportement. Les
données et les traitements sont modélisés
séparément. En effet, d'une part les données suivent des
modélisations conceptuelle et logique et, d'autre part, les traitements
sont soumis aux modélisations conceptuelle et organisationnelle. Les
méthodes systémiques font preuve d'une bonne prise en charge des
données. Les niveaux d'abstraction y sont bien définis : niveau
externe, niveau conceptuel, niveau interne. Le principal souci demeure le
manque de cohérence entre données et traitements, leur
étude séparée conduisant à un certain
décalage lors de la mise en place du modèle physique.
Les méthodes systémiques les plus connues sont
MERISE (méthode la plus utilisée en informatique de gestion),
AXIAL (IBM-systèmes d'information), OSSAD (systèmes
bureautiques).
· Les méthodes orientées objet
L'approche orientée objet considère le logiciel
comme une collection d'objets dissociés, identifiés et
possédant des caractéristiques. La fonctionnalité du
logiciel émerge alors de l'interaction entre les différents
objets qui le constituent. Les méthodes orientées objet les plus
connues sont : OMT (Rumbaugh et al. 1995), OOA (Object Oriented Analysis - Coad
& Yourdon 1992), BOOCH (Booch 1991).
Les avantages de l'approche orientée objet sont :
· la combinaison (prise en charge commune) des
données et des traitements qui constituait la limite majeure des
méthodes systémiques ;
· l'abstraction par rapport aux outils
d'implémentation ;
· les possibilités de réutilisation (on ne
peut s'attarder sur un problème déjà
efficacement résolu) et d'évolutivité
(paramètre primordial à prendre en compte).
Les concepts de la modélisation sont divers et
complexes. Les concepts Orienté objet ne sont pas formels variant alors
d'une modélisation à une autre. Il convient alors de choisir un
langage pour orienter et canaliser sa modélisation.
Le langage de modélisation que nous emploierons tout au
long de l'analyse et la conception est l'UML (Unified Modeling Language).
UML est née de la fusion de plusieurs méthodes
orienté objet (OOSE, OMT, BOOCH...), et est devenu désormais la
référence en matière de modélisation objet. Sa
notation graphique est très utile dans la définition des
éléments de modélisation et de leur sémantique.
Alliée au processus unifié qui est une méthode
itérative et incrémentale, il permet de modéliser en
plusieurs étapes à travers les phases de création,
d'élaboration, de construction et de transition. Cependant, UML n'est
pas une méthode dans la mesure où elle ne présente aucune
démarche.
Le recours à des logiciels de graphisme UML est un gage
de productivité pour la rédaction des diagrammes UML, car :
· ils facilitent la navigation entre les différentes
vues,
· ils permettent de centraliser, organiser, partager et
synchroniser les diagrammes (indispensable avec un processus
itératif),
· facilitent l'abstraction, par des filtres visuels,
· simplifient la production de documents et autorisent
(dans certaines limites) la génération de code.
2. Analyse
2.1 Analyse des besoins
2.1.1 Expression des besoins
utilisateur
L'identification des besoins est la pierre angulaire du
développement de logiciels. Elle aide à orienter le produit final
vers son utilisation. Elle représente le point d'entrée du
développement logiciel.
Les besoins utilisateurs sont repartis comme suit :
· Surveillance générale des ressources
critiques
Chaque responsable (systèmes et intranet,
réseaux et télécoms, base de données et
applications) gère les équipements qui sont sous sa
responsabilité. Donc l'outil de supervision orientée vers son
domaine ne gère que les ressources le concernant. La plate-forme
d'intégration doit présenter des vues sur l'état
(indisponibilité et statistiques) de tous les équipements sous
supervision sans pour autant entrer dans les brefs détails. Il se doit
d'être synthétique dans la fourniture de ces informations.
o Réseau et Télécoms
· Antennes VSAT
· Commutateurs (ports et services)
· Routeurs
· GABs
· Serveurs monétiques
· Serveurs de téléphonie
· Serveur mail (https, smtp)
· Serveurs internationaux (Visa, Mastercard)
o Système (CPU/Ram/température/Disque dur,
etc.)
· Contrôleur de domaine
· Serveur monétiques
· Serveurs internes (mail, web, etc.)
o Bases de données Oracle
· Utilisateurs
· Tablespaces
· Sessions
· Contentions, etc. o Applications
· Oracle IAS
· Sage Saari
· Etc.
· Génération des états
Les utilisateurs de la plate-forme veulent savoir chaque
jour, par semaine, mensuellement, trimestriellement ou annuellement
l'état global du réseau. Par exemple si le responsable
réseaux et télécoms désire savoir quelle est a
été la fréquence d'indisponibilité d'un routeur, la
plate-forme d'intégration doit reproduire et lui envoyer cet
état. Il convient de savoir qui peut générer un
état et à quelles informations il peut avoir accès.
· Gestion d'alertes centralisée (définition
des seuils)
Chaque outil de supervision intègre son système
d'alertes. L'exploitant qui reçoit actuellement une alerte doit se
reporter sur l'outil de supervision concerné pour vérifier
l'alerte. L'intégration et la qualification des alertes dans une
interface unique permettent d'alléger alors certaines difficultés
liées à la dispersion des vues de supervision. On distingue
plusieurs catégories d'alertes :
o Alertes réseaux
· Indisponibilité d'une ressource en zone
critique
La zone critique est constituée des ressources dont
l'indisponibilité paralyse l'activité. Son suivi est alors
pertinent. Elle rassemble les équipements backbone et du WAN (Wide Area
Network) mais aussi certaines ressources du réseau interne.
· Basculement active-active (firewall, routeur, switch)
Les routeurs, Switch, pare-feux sont dupliqués pour
offrir un partage de charge mais aussi une reprise instantanée. Cette
duplication augmente aussi leur capacité. Il est alors indispensable de
connaitre lequel est actif et ce qui a motivé le basculement afin de
prendre les dispositions qui conviennent.
o Alertes Base de données & applications
o Alertes systèmes
· Changement de serveur en mode cluster
· Alertes sur les incidents détectés
(réception par mail ou sms)
· Alertes sauvegarde (état, déroulement,
erreurs)
NB : Ces différentes alertes doivent être
redirigées automatiquement vers les chargés d'astreinte soit par
mail ou sms. Mais pour cela, il faut une qualification automatique et une
définition d'un niveau de criticité.
· Gestion des incidents (volet exploitation)
Les outils de supervision n'intègrent pas une
procédure de suivi des incidents qui surviennent lors de la supervision.
Ils se bornent à générer des alertes. Un utilisateur de la
plate-forme d'intégration doit ouvrir un ticket incident et suivre la
résolution de son incident. La gestion d'incident comporte les
étapes suivantes :
o Ouverture de ticket incident
· Qualification de l'incident
· Type d'incident
· Niveau de criticité (vert, orange, rouge)
o Suivi de la résolution de l'incident
o Clôture de l'incident
o Transcription de l'incident dans une base de connaissances
· Gestion des sauvegardes
A des heures précises, les serveurs dupliquent leurs
données sur bande. Il est donc important de suivre le déroulement
de ces sauvegardes.
2.1.2 Reformulation des
besoins
Elle représente le point d'entrée de l'analyse.
Elle se base sur le dossier d'expression des besoins utilisateur. A ce niveau
d'abstraction, on doit capturer les besoins principaux des utilisateurs. Il
convient de clarifier, filtrer et organiser les besoins sans pour autant
rechercher l'exhaustivité.
Le but de la conceptualisation est :
· de définir le contour du système à
modéliser (de spécifier le "quoi"),
· de capturer les fonctionnalités principales du
système, afin d'en fournir une meilleure compréhension,
· de fournir une base à la planification du
projet.
Elle est fortement illustrée par les diagrammes de cas
d'utilisation UML et les diagrammes de séquence système qui
présentent le déroulement des cas d'utilisation
Un acteur est l'idéalisation d'un rôle
joué par une personne externe, un processus ou une chose qui interagit
avec un système. Les acteurs d'un système sont les entités
externes à ce système qui interagissent avec lui. Les acteurs
sont donc à l'extérieur du système et dialoguent avec lui.
Ces acteurs permettent de cerner l'interface que le système va devoir
offrir à son environnement. Oublier des acteurs ou en identifier de faux
conduit donc nécessairement à se tromper sur l'interface et donc
la définition du système à produire. Les acteurs inclus
les utilisateurs humains mais aussi les autres systèmes informatiques ou
hardware qui vont communiquer avec le système.
· Acteurs principaux
o Utilisateur
Acteur générique représentant un
utilisateur simple du système
o Exploitant (hérite de Utilisateur)
L'exploitant constitue le principal utilisateur de la plate
forme. Il doit suivre les alertes, gérer les incidents jusqu'à
leur résolution. La plateforme étant son principal outil de
supervision.
o Astreinte (hérite de Utilisateur)
L'astreinte est la personne physique ou l'équipe qui
est chargée de conduire la résolution d'un incident après
sa détection ou à partir d'un appel de l'exploitation
informatique. Elle constitue l'acteur capable de résoudre efficacement
le problème dès sa qualification.
o Responsable (hérite de Utilisateur)
Le responsable est mis au courant par l'exploitant des
alertes réellement critiques qui le concernent directement. Il peut
effectuer certaines tâches d'administration sur les ressources qui sont
sous sa direction.
· Acteurs secondaires
Ils représentent les différentes sources
d'informations. Le système rapatrie les informations nécessaires
à partir de ces différents acteurs. Ils n'utilisent alors le
système que pour lui envoyer des informations.
o BD_exploitation
C'est l'acteur générique qui représente
les bases de données qui envoient des informations à partir des
différents outils de supervision et les systèmes avec lesquels
communiquent directement la plateforme d'intégration.
Un cas d'utilisation est une unité cohérente
représentant une fonctionnalité visible de l'extérieur. Il
permet de structurer les besoins des utilisateurs et les objectifs
correspondants d'un système. Il réalise un service de bout en
bout, avec un déclenchement, un déroulement et une fin, pour
l'acteur qui l'initie. Un cas d'utilisation modélise donc un service
rendu par le système, sans imposer le mode de réalisation de ce
service. Il centre l'expression des exigences du système sur ses
utilisateurs : ils partent du principe que les objectifs du système sont
tous motivés.
Les cas d'utilisation du système sont
présentés comme des modules qui regroupent plusieurs
scénarii.
Mémoire de fin de cycle CHAPITRE
2
SAKITI Lionel
|
39
|
|
|
· Utilisateur
la gestion concerne l'ouverture,
la modification et le suivi
de
sa résolution.seul l'exploitant
peut clôturer ou
supprimer un
incident.
Gérer incident
S'authentifier
Utilisateur
Astreinte
Administrateur
malgré l'héritage,
un responsable ne
peut
pas clôturer un
incident
<<interne>>
Responsable
Surveillance générale
Gerer alerte
<<interne>>
Exploitant
Cloturer incident
Afficher indisponibilité
Afficher statistiques
Générer état
<<interne>> Exploitant
Figure n° II-2-1: Cas d'utilisation du
système par un utilisateur générique
· Exploitant
SYSTEME
gestion des incidents
<<extends>>
Cloturer incident
Utilisateur
<<include>>
authentification
<<include>>
Tâches d'administration
<<interne>>
Responsable
<<include>>
surveillance générale
<<include>>
envoi information
<<include>>
<<interne>>
Exploitant
<<include>>
<<include>>
<<secondaire>>
BD exploitation
<<include>>
gestion de l'astreinte
gestion des alertes
Administrateur
gestion des utilisateurs
Mémoire de fin de cycle CHAPITRE
2
Figure n° II-2-2: Cas d'utilisation du
système par un exploitant
· Administrateur
L'administration inclut toutes les tâches de gestion
(ajout, modification, suppression) du système. Elle permet de garantir
une maintenance aisée au fonctionnement du système.
S'authentifier
Administration
Gérer utilisateur
Administrateur
Gérer Astreinte
Gérer menus
<<interne>>
Responsable
Figure n° II-2-3: Cas d'utilisation du volet
d'administration du système
Le schéma ci-dessous représente une synthèse
de tous les cas d'utilisation du système.
|
Mémoire de fin de cycle CHAPITRE
2
SAKITI Lionel
|
41
|
|
Figure n° II-2-4: Cas d'utilisation du
système
Les cas d'utilisation sont regroupés afin d'orienter le
système comme un ensemble de services (modules) fournis. Ces
différents modules sont regroupés en deux catégories : Les
modules qui concernent le fonctionnement interne de l'application (BackOffice)
et les modules qui fournissent des services (Front Office).
BACK - OFFICE
FRONT - OFFICE
Administration
Gestion des Utilisateurs
Gestion de l'Astreinte
Gestion des menus
Configuration
Surveillance générale
Afficher alerte
Générer alerte
Gestion des Alertes
Générer état sur incidents
Générer alerte
Ouvrir ticket incident
Gestion des Incidents
Figure n° II-2-5: Schéma de communication
entre les modules fonctionnels
2.1.3 Spécification détaillée
des besoins
Après avoir eu connaissance des différents cas
d'utilisation, il faut les détailler afin de présenter
l'interaction qu'effectuent les acteurs avec le système. Cette phase
décrit le scénario nominal des cas d'utilisation mais aussi liste
toutes les variantes possibles dudit cas. Tous les cas d'utilisation du
système ne seront pas détaillés.
·
· Cas
d'utilisation : S'authentifier
Acteurs : utilisateur
Pré-conditions : L'utilisateur doit avoir
été créé au préalable
Scénario nominal :
1. L'utilisateur clique sur le lien vers l'application
2. Le système communique un formulaire de connexion
3. L'utilisateur renseigne son login et mot de passe
4. Le système vérifie et charge son profil
Post-conditions : L'utilisateur a accès
à sa page d'accueil et ses menus
Le système enregistre les informations sur la connexion de
l'utilisateur (matricule de l'utilisateur, type d'utilisateur, heure de
connexion)
Variantes :
3. les informations de l'utilisateur sont erronées :
a. le système affiche un message d'erreur
b. retour en 2
Authentification
pas de session
alt
Utilisateur
sinon
alt
session active
opt
opt
refAuthentification()
ref Authentification()
login inexistant ou mot de passe incorrect
[utilisateur deja connecté]
[non]
affiche la page d'acceuil de l'utilisateur charge le
profil(menus) de l'utilisateur
affiche ("Session ouverte.Voulez vous
continuer?")
affiche ("utilisateur deja connecté")
demande la page de connexion
affiche ("identifiants incorrects")
envoie la page de connexion
envoie login, mot de passe
verifie si le login et le mot de p
verifie si l'utilisateur est déja
connecté
Systeme
verifie si une session est active
asse sont
corrects
Figure n° II-2-6: Diagramme de séquence
illustrant le processus d'authentification
> Surveillance générale
<<interne>>
Exploitant
<<secondaire>> BD exploitation
Imprimer état
Informations critiques à afficher (BD, fichier de
logs)
SURVEILLANCE GENERALE
indisponibilité
équipement ou
service
Afficher statistiques
Afficher indisponibilité
<<i nclude>>
Générer état
<<i ncl ude>>
envoyer information
Figure n° II-2-7: Scénarii de la
surveillance générale
·
· Cas
d'utilisation : afficher indisponibilité
Acteurs : exploitant
Scénario nominal :
1. L'utilisateur indique l'équipement ou le service
2. Le système interroge la BD exploitation
concernée
3. La BD exploitation renvoie l'information sur
l'indisponibilité
4. Le système affiche la dernière
indisponibilité à l'utilisateur Post-conditions
: Le système stocke l'information sur
l'indisponibilité
·
· Cas
d'utilisation : afficher statistiques
Acteurs : exploitant
Scénario nominal :
1. L'utilisateur indique l'équipement ou le service
2. Le système affiche la liste des rubriques possibles
3. L'utilisateur choisit la rubrique à afficher
4. Le système interroge la BD exploitation
concernée
5. La BD exploitation renvoie les statistiques au
système
6. Le système affiche l'information à
l'utilisateur
+ Cas d'utilisation :
générer état Acteurs : exploitant
Pré-conditions : Les statistiques sur
l'équipement sont enregistrées par le système
Scénario nominal :
1. L'utilisateur clique sur « générer
état »
2. Le système affiche un formulaire des paramètres
de l'état (nom de l'équipement, service ou application, seuil)
3. L'utilisateur choisit et valide
4. Le système récupère et envoie la page
d'état
générer état
Systeme
l'état peut être
généré
sur un
équipement ou un
service
le seuil est une
date limite
dans le temps
evalue les indisponibilités
opt
Exploitant
[type=service]
demande le type d'état
(équipement/service)
affiche la liste des équipements
choisit l'équiupement
définit le type
affiche les services surveillés
choisit le service
demande le seuil
choisit une date
affiche l'état
Figure n° II-2-8: Diagramme de séquence
illustrant le processus de génération d'un
état
|
Mémoire de fin de cycle CHAPITRE
2
SAKITI Lionel
|
46
|
|
> Gestion des incidents
<<interne>>
Exploitant
Utilisateur
Astreinte
<<secondary>>
<<primary>>
Transferer incident
Qualifier incident
Cloturer incident
<<extends>>
<<include>>
<<include>>
sauvegarde
Ouvrir incident
sauvegarde dans
une base de
connaissances
GESTION DES INCIDENTS
<<include>>
<<include>>
Resoudre incident
Imprimer incident
redaction fiche
incident
Ouvrir incident par alerte
<<nclude>>
envoyer information
<<include>>
Informations de
type alerte
<<secondaire>>
BD exploitation
Figure n° II-2-9: Scénarii de gestion
Incidents
·
· Cas
d'utilisation : Ouvrir incident
Acteurs : utilisateur
Pré-conditions :
La source (détection) de l'incident peut être :
« visuel » ou «contact» (téléphone ou mail)
Scénario nominal :
1. L'utilisateur clique sur « Ouvrir ticket incident
»
2. Le système communique un formulaire d'incident
3. L'utilisateur renseigne les informations (type, description,
degré de gravité, fichiers, Remarques, etc.)
4. Le système enregistre les informations et envoie la
liste des chargés d'astreinte
5. L'utilisateur choisit les personnes capables de suivre
l'incident
6. Le système enregistre et demande à
l'utilisateur s'il veut suivre l'incident
7. L'utilisateur accepte
8. Le système met le champ « suivi » à
1
9. Le système génère une alerte vers les
exploitants connectés
Post-conditions :
Le ticket incident est affiché à l'utilisateur
Le système envoie des mails vers les chargés de
suivre l'incident
Le système envoie une notification aux responsables selon
le type de l'incident Variantes :
7. L'utilisateur refuse de suivre l'incident
a. Le système met le champ « suivi » à
0
·
· Cas
d'utilisation : Ouvrir incident à partir d'une
alerte
Acteurs : Exploitant
Pré-conditions :
· Une alerte grave (criticité élevée)
est générée et l'utilisateur veut en faire un incident
· L'utilisateur clique sur « Ouvrir incident »
à partir de la ligne de l'alerte
Scénario nominal :
1. Le système communique un formulaire d'incident
où :
· La description d'incident est par défaut le
message de l'alerte
· La source (détection) de l'incident est «
alerte »
· Le type de l'incident est le type de l'alerte
· La date de l'incident est la date courante
2. L'exploitant renseigne les autres informations (degré
de gravité, fichiers, Remarques, etc.)
3. Le système enregistre les informations et envoie la
liste des chargés d'astreinte
4. L'exploitant choisit les personnes capables de suivre
l'incident
5. Le système enregistre et demande à
l'utilisateur s'il veut suivre l'incident
6. L'utilisateur accepte
7. Le système met le champ « suivi » à
1
8. Le système génère une alerte vers les
exploitants connectés
Post-conditions :
Le ticket incident est affiché à l'utilisateur
Le système envoie des mails vers les chargés de
suivre l'incident
Le système envoie une notification aux responsables selon
le type de l'incident Variantes :
7. L'utilisateur refuse
a. Le système met le champ « suivi » à
0
·
· Cas
d'utilisation : Mettre à jour un incident
Acteurs : utilisateur
Pré-conditions : L'utilisateur qui veut
mettre à jour l'incident est soit un exploitant soit celui qui a ouvert
le ticket
Scénario nominal :
1. L'utilisateur clique sur « modifier incident »
2. Le système affiche la liste de
ses incidents
3. L'utilisateur choisit l'option « modifier » au
niveau de la ligne de l'incident
4. Le système envoie le formulaire de l'incident avec les
anciennes valeurs
5. L'utilisateur modifie les informations et valide
6. Le système enregistre les informations
Variantes :
NB : En consultation, l'incident est visible par tous mais la
variante ci-dessous s'applique pour la modification d'un incident.
2. L'utilisateur est :
a. un exploitant : Le système affiche tous les
incidents
b. d'astreinte : Le système affiche aussi tous les
incidents qui lui ont été transférés
c. un responsable : Le système affiche tous les incidents
qui le concernent selon le type d'incident
·
· Cas
d'utilisation : Transférer l'incident vers
l'astreinte
Acteurs : utilisateur
Pré-conditions : L'incident est
déjà ouvert
Scénario nominal :
1. L'utilisateur clique sur « lister incidents »
2. Le système affiche la liste de
ses incidents
3. L'utilisateur choisit l'option « transférer
» au niveau de la ligne de l'incident
4. Le système affiche l'incident et la liste des
personnes chargés de suivre l'incident
5. L'utilisateur coche les personnes vers qui il veut
transférer l'incident
6. Le système envoie (par mail) l'incident aux personnes
signifiées par l'utilisateur Post-conditions :
Le système envoie une notification aux responsables selon
le type d'incident
·
· Cas
d'utilisation : Résoudre l'incident
Acteurs : Utilisateur
Pré-conditions : L'incident n'est pas
encore clôturé
Scénario nominal :
1. L'utilisateur clique sur « afficher ticket »
2. Le système affiche le ticket incident avec l'option
« résoudre »
3. L'utilisateur clique sur l'option « résoudre
» au niveau de la ligne incident
4. Le système envoie le formulaire d'ajout de
résolution
5. L'utilisateur remplit le formulaire et met le champ
"état" de l'incident à « résolu» et valide les
entrées.
6. Le système génère une alerte vers les
exploitants connectés
7. Le système affiche le ticket incident à
l'utilisateur
Post-conditions :
· Si le champ « suivi » est à 1, le
système envoie un mail à l'utilisateur qui a ouvert l'incident
· Le système envoie un mail à tous les
utilisateurs qui suivent l'incident
Variantes :
5. La résolution n'est pas définitive
a. L'utilisateur met le champ "état" de l'incident
à « en cours»
b. Continuer en 6
·
· Cas
d'utilisation : Clôturer incident
Acteurs : Exploitant
Pré-conditions : l'incident est
entièrement résolu
Scénario nominal :
1. L'exploitant clique sur « liste incidents »
2. Le système envoie la liste des incidents dont
l'état est « résolu »
3. L'exploitant clique sur l'option « clôturer »
au niveau de la ligne de l'incident
4. Le système crée l'archive et demande à
l'exploitant s'il veut déplacer dans la base de connaissances
5. L'exploitant accepte
6. Le système crée la ligne correspondante dans la
base de connaissances de l'Intranet. Post-conditions :
Le système réaffiche la liste des incidents non
encore clôturés
Le système envoie une notification à l'utilisateur
qui a ouvert le ticket que son incident a été
clôturé.
Variantes :
4. L'exploitant refuse
a. Le scénario termine
> Gestion des alertes
Astreinte
<<interne>>
Responsable
<<interne>>
Exploitant
<<secondary>>
<<secondary>>
<<primary>>
<<secondary>>
Transferer alerte
Mettre a jour alerte
<<i ncl ude>>
Supprimer alerte
archiver alerte
<<i ncl ude>>
<<include>>
GESTION DES ALERTES
<<include>> <<extends>>
Reporter alerte
<<i ncl ude>>
Generer alerte
génération automatique par envoi d'information
envoyer information
Information de
type alerte
<<secondaire>>
BD exploitation
Figure n° II-2-10: Scénarii de la gestion
des alertes
+ Cas d'utilisation :
Générer alerte
Acteurs : BD exploitation, exploitant
Pré-conditions : la BD exploitation est
connectée
Scénario nominal :
1. Le système interroge une BD exploitation ou sa base de
données
2. La BD exploitation envoie l'information au système
3. Le système récupère l'information et
qualifie
4. Le système enregistre l'alerte
5. Le système envoie l'information aux exploitants
connectés. Post-conditions :
Variantes :
1. Le système interroge sa base de données (table
"sauvegarde") a. Continuer en 5
|
Mémoire de fin de cycle CHAPITRE
2
SAKITI Lionel
|
52
|
|
NB : On met des triggers sur la table
"sauvegarde" pour gérer toute nouvelle sauvegarde
generer alerte
Exploitant
loop
[nbre d'exploitants connectés]
opt
[si exploitant connecté]
Systeme
récupere la liste des exploitants
connectés
crée et sauvegarde l'alerte
affiche
l' alerte
:alerte
Figure n° II-2-11: Diagramme de séquence
illustrant le processus de génération d'une
alerte
· Source de l'alerte : BD exploitation
Alerte BD exploitation
<<interne>>
Exploitant
Informations
critiques de type
alerte (politiques
de
supervision) et
crée une liste des
alertes
loop
[nombre d'alertes]
loop
Systeme
ref
[temps de polling]
traite le flux d'information
Envoie un flux d'information
qualifie l'alerte
interroge la base
generer alerte()
:BD exploitation
le temps de
polling est
défini par
l'administrateur
:alerte
la séquence est
appliquée à
chaque
alerte si
une information
en contient
plusieurs
Figure n° II-2-12: Diagramme de séquence
illustrant la génération d'alerte BD exploitation
· Source d'alerte : Sauvegarde
Alerte sauvegarde
<<interne>> Exploitant
alt
ref
else
erreur
afficheÇsauvegarde réussie")
après un temps de polling
generer alerte()
Systeme
récupere et verifie l'information
ecrit l'information de sauvegarde
A partir d'un
script shell
executé
après
chaque
sauvegarde
erreur lors de la sauvegarde
:Serveur CTMI
Figure n° II-2-13: Diagramme de séquence
illustrant la génération d'alerte sauvegarde
· Source d'alerte : GLPI
Alerte GLpi
Exploitant
ref
loop
Systeme
[temps de polling]
envoie la liste des tickets
generer alerte()
éffectue une requete
Glpi:BD exploitation
récupere les tickets
déposés
le temps de
polling est
défini par
l'administrateur
:alerte
Figure n° II-2-14: Diagramme de séquence
illustrant la génération d'alerte GLPI
· Source d'alerte : Déclaration d'incident
Alerte incident
<<interne>> Exploitant
ref
Utilisateur
generer alerte()
Ouvre un ticket incident
Systeme
Crée l'alerte
:alerte
Figure n° II-2-15: Diagramme de séquence
illustrant la génération d'alerte incident
·
· Cas
d'utilisation : Transférer alerte
Acteurs : exploitant, astreinte, responsable
Pré-conditions : L'alerte est affichée sur la
page de l'exploitant
Scénario nominal :
1. L'exploitant clique sur « transférer l'alerte
»
2. Le système lui affiche la liste des personnes
chargées d'astreinte
3. L'utilisateur coche les personnes vers qui il veut
transférer l'alerte
4. Le système envoie (par mail) l'alerte aux personnes
signifiées par l'utilisateur:
·
· Cas
d'utilisation : Supprimer alerte
Acteurs : exploitant
Pré-conditions : L'alerte est
affichée sur la page de l'exploitant Scénario
nominal :
1. L'exploitant clique sur l'option « supprimer »
2. Le système demande si l'exploitant veut archiver
l'alerte
3. L'utilisateur accepte
4. Le système met le champ archive de l'alerte à
« oui » Post-conditions : L'alerte est
supprimée.
Variantes :
2. l'utilisateur refuse d'archiver
a. Le système lui affiche le message « votre alerte
sera définitivement perdu »
b. Le scénario termine
> Administration
GESTION DES UTILISATEURS
Mettre a jour utilisateur
<<i ncl ude>>
Creer utilisateur
Administrateur
<<include>>
Supprimer utilisateur
Figure n° II-2-16: Scénarii de gestion des
utilisateurs
+ Cas d'utilisation :
créer utilisateur
Acteurs : administrateur
Pré-conditions : L'utilisateur n'existe
pas (deux utilisateurs ne peuvent avoir le même login)
Scénario nominal :
1. L'administrateur clique sur « créer utilisateur
»
2. Le système affiche le formulaire « nouvel
utilisateur »
3. L'administrateur remplit le formulaire en indiquant le type
d'utilisateur (exploitant, responsable, astreinte, simple, ...)
4. Le système affiche la liste des menus utilisateur
selon le type d'utilisateur
5. L'administrateur coche les menus qu'il veut activer pour
l'utilisateur
6. Le système affiche les informations et demande
à l'administrateur de valider
7. L'administrateur valide
8. Le système crée l'utilisateur
Post-conditions :
Le système envoie un mail à l'utilisateur en lui
signifiant d'activer son compte et de changer son mot de passe
·
· Cas
d'utilisation : Mettre à jour utilisateur
Acteurs : administrateur
Pré-conditions :
Scénario nominal :
1. L'administrateur clique sur « liste des utilisateurs
»
2. Le système affiche la liste des utilisateurs
3. L'administrateur clique sur « éditer »
devant la ligne de l'utilisateur
4. Le système affiche la fiche complète de
l'utilisateur
5. L'administrateur effectue les modifications
6. Le système affiche les informations et demande
à l'administrateur de valider
7. L'administrateur valide
8. Le système affiche « utilisateur mis à
jour »
Post-conditions :
Le système envoie un mail à l'utilisateur en lui
signifiant que les informations de sa session ont été
modifiées par l'administrateur.
Le tableau ci-dessous représente une matrice des menus
auxquels a droit chaque type d'utilisateur.
|
Exploitant
|
Responsable
|
Astreinte
|
Administra
teur
|
Utilisateur
simple
|
|
Administration
|
|
|
|
|
|
|
>Gestion des utilisateurs
|
|
|
|
X
|
|
|
>>Nouvel utilisateur
|
|
|
|
X
|
|
|
>>Modifier utilisateur
|
|
|
|
X
|
|
|
>>>Supprimer utilisateur
|
|
|
|
X
|
|
|
>>Liste Utilisateur
|
|
|
|
X
|
|
|
>>Afficher menus
|
|
|
|
X
|
|
|
>>Ajouter menu
|
|
|
|
X
|
|
|
>Gestion de l'astreinte
|
|
|
|
X
|
|
|
>>Afficher planning
|
X
|
X
|
X
|
X
|
X
|
|
>>modifier planning
|
|
|
|
X
|
|
|
>>Ajouter chargé d'astreinte
|
|
|
|
X
|
|
|
>>Allouer période
|
|
|
|
X
|
|
|
|
>Gestion des menus
|
|
|
|
X
|
|
|
>>nouveau menu
|
|
|
|
X
|
|
|
>>Tableau des menus
|
|
|
|
X
|
|
|
>>>Editer menu
|
|
|
|
X
|
|
|
>>>Attribuer menu
|
|
|
|
X
|
|
|
>>>Supprimer menu
|
|
|
|
X
|
|
|
|
Surveillance générale
|
X
|
X
|
|
|
|
|
>Applications de supervision
|
X
|
X
|
|
|
|
|
>Gestion des équipements
|
X
|
X
|
|
|
|
|
>>Liste équipements
|
X
|
X
|
|
|
|
|
>>>Afficher indisponibilité
service
|
X
|
X
|
|
|
|
|
>>>Editer équipement
|
X
|
|
|
|
|
|
>>>Afficher statistiques
|
X
|
X
|
|
|
|
|
>>>Générer état
|
X
|
X
|
|
|
|
|
>>>Administrer équipement
|
|
X
|
|
|
|
|
|
|
|
|
|
|
Gestion des Alertes
|
X
|
|
|
|
|
|
>Rechercher alerte
|
X
|
X
|
|
|
|
|
>Lister Alertes
|
X
|
X
|
|
|
|
|
>>Transférer alerte
|
X
|
|
|
|
|
|
>>Reporter alerte
|
X
|
|
|
|
|
|
>>Archiver alerte
|
X
|
|
|
|
|
|
>>Supprimer alerte
|
X
|
|
|
|
|
|
|
Gestion des incidents
|
X
|
X
|
X
|
|
X
|
|
>Ouvrir incident
|
X
|
X
|
X
|
|
X
|
|
>Résoudre incident
|
X
|
X
|
X
|
|
|
|
>Liste incidents
|
X
|
X
|
X
|
|
X
|
|
>>Transférer incident
|
X
|
|
|
|
|
|
>>Modifier incident
|
X
|
|
|
|
|
|
>>Qualifier incident
|
X
|
X
|
X
|
|
X
|
|
>>Clôturer incident
|
X
|
|
|
|
|
|
>Base de connaissances
|
X
|
X
|
X
|
|
X
|
Tableau n° II-2-1: Matrice des menus
utilisateur
Le tableau ci-dessous répertorie tous les scénarii
des différents cas d'utilisation
|
Nom du cas
|
Scénario
|
Acteurs
|
|
S'authentifier
|
|
Utilisateur
|
|
Envoyer information
|
|
BD_exploitation
|
|
Exécuter Taches
|
|
Responsable
|
|
SURVEILLANCE GENERALE
|
|
Afficher indisponibilité
|
- d'un service
- d'un équipement
|
exploitant
|
|
Afficher statistiques
|
|
exploitant
|
|
Générer état
|
|
exploitant
|
|
GESTION DES ALERTES
|
|
Générer alerte
|
- BD exploitation - incident
- sauvegarde
|
|
|
Mettre à jour alerte
|
|
exploitant
|
|
Transférer alerte
|
|
exploitant
|
|
Reporter alerte
|
|
exploitant
|
|
Archiver alerte
|
|
exploitant
|
|
Supprimer alerte
|
|
exploitant
|
|
GESTION DES INCIDENTS
|
|
Ouvrir incident
|
- à partir d'un contact
- à partir d'une alerte
- à partir d'une détection
|
Utilisateur
|
|
Qualifier incident
|
|
Utilisateur
|
|
Imprimer incident
|
|
Utilisateur
|
|
Transférer incident
|
|
exploitant
|
|
Clôturer incident
|
|
exploitant
|
|
Supprimer incident
|
|
exploitant
|
|
GESTION DES UTILISATEURS
|
|
Créer utilisateur
|
|
Administrateur
|
|
Mettre à jour utilisateur
|
|
Administrateur
|
|
Supprimer utilisateur
|
|
Administrateur
|
|
Gestion des menus
|
- Créer menu
- Modifier menu
- Supprimer menu
|
Administrateur
|
|
Gestion de l'astreinte
|
- Afficher planning
- Créer planning
|
Administrateur
|
Tableau n° II-2-2: Tableau récapitulatif
des cas d'utilisation
2.2 Analyse applicative
2.2.1 Procédures de
gestion
Le diagramme d'activités représente un outil
pour l'élaboration des procédures. Il permet de modéliser
un processus interactif, global ou partiel pour un système donné.
Il permet d'exprimer une dimension temporelle sur une partie du modèle
des cas d'utilisation. Le diagramme d'activité montre
l'enchaînement des activités qui concourent au processus.
· Procédure de gestion d'une alerte
Lorsqu'une BD exploitant envoie une information (de
manière globale), le système génère une alerte.
Cette génération d'alerte est symbolisée par la
création d'un objet « alerte ». Le processus de gestion de
l'alerte est alors initié.
|
exploitant
|
astreinte
|
BD exploitation
|
|
|
|
|
|
utiliser les triggers sur la base de données
|
|
|
:alerte
[Créé]
|
|
|
|
envoi information
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
selon la
categorisation
de l'alerte
|
|
[aucun]
connecté
|
|
|
|
recevoir sms/mail
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
voir alerte reporter alerte
|
|
|
|
|
|
|
|
|
|
qualifier alerte
|
|
|
|
|
|
niveau critique
assez élevé
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
rouge archiver alerte
|
|
|
|
|
|
|
|
|
|
|
[OK]
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
ouverture incident supprimer alerte
|
|
|
|
|
|
|
|
|
|
|
|
Figure n° II-2-17: Procédure de gestion
d'une alerte
|
Mémoire de fin de cycle CHAPITRE
2
SAKITI Lionel
|
60
|
|
· Procédure de gestion d'un incident
Tout utilisateur peut ouvrir un ticket incident. Dans la
procédure, seul l'exploitant peut clôturer un incident
entièrement résolu. Ceci garantit un suivi de l'incident par
l'exploitation informatique.
|
Utilisateur
|
Exploitant
|
Astreinte
|
|
|
|
|
|
[SINON]
resoudre incident [OK]
|
reception incident
|
|
|
ouverture incident
|
|
connecté
|
|
|
|
|
|
|
[SINON]
envoi transfert incident resolution incident
|
|
[Resolution=OK]
|
|
archiv
|
é
|
|
|
|
impression incident
|
|
|
|
|
incident
cloturer
|
[Resolution=OK]
|
|
|
|
avec possibilité
de
génération
fichier xml,pdf,
word
|
|
|
|
|
|
|
|
|
|
|
|
|
|
[SINON]
|
que
criti
|
|
|
|
|
|
|
|
|
|
|
[OK]
|
|
|
|
|
|
|
archiver incident sauvegarder
|
vers base de connaissances
|
|
|
|
|
|
|
|
|
|
|
|
vider
|
creation
fichier xml
|
|
|
|
|
|
[Manque d'espace]
|
|
|
|
Supprimer incident
|
|
|
Figure n° II-2-18: Procédure de gestion
d'un incident
2.2.2 Diagrammes
d'état-transitions
Le diagramme d'état représente la façon
dont évoluent les objets appartenant à une même classe
durant leur cycle de vie. La modélisation du cycle de vie est
essentielle pour représenter et mettre en forme la dynamique du
système. Il est le plus souvent utilisé pour modéliser les
objets du système qui subissent un changement d'état.
L'incident et l'alerte sont les deux ressources du
système qui varient souvent. La modélisation des
différents états qu'ils peuvent subir au cours de leur survie
dans le système est alors une aide à l'analyse. Un incident, de
sa création jusqu'à sa suppression totale ou à son
archivage, subit plusieurs états. Il en est de même pour une
alerte dès sa génération.
archivé
purger/diminuer nbre enregistrements
purger/diminuer nbre enregistrements
généré
entry / définir source alerte do / crée alerte
exit / afficher alerte
demande /envoi astreinte
envoi astreinte
entry / afficher liste astreinte do / envoi mail
transféré
effacer
supprimé
Figure n° II-2-19: Les différents
états d'une alerte
Créé
T ra nsfe ré
résolution
résolu
qualifié / envoyer email ou
entry / afficher ticket incident vierge do / creer ticket
incident
do / afficher aide
demande/ envoi mail
résolution
corriger [type_résolution non définitive] /
modifier l'incident
do / creer une ligne de solution exit / définir type
résolution
entry / afficher liste astreinte
cloture/changer état
cloturé
entry / verifier resolution do / sauvegarder
vider [nombre incidents élevé] / creer
fichier xml
effacer
entry / vérifier cloture exit / déplacer
l'incident
Archivé
L'incident doit
être cloturé
Supprimé
Figure n° II-2-20: Les différents
états d'un incident
3. Conception
3.1 Le pattern MVC
(Modèle-Vue-Contrôleur)
Le Modèle-Vue-Contrôleur (en abrégé
MVC, de l'anglais Model-View-Controller) est une architecture de conception qui
organise l'interface Homme-machine d'une application logicielle. Il divise
l'interface homme machine en un modèle
(modèle de données), une vue
(présentation, interface utilisateur) et un
contrôleur (logique de contrôle, gestion des
évènements, synchronisation), chacun ayant un rôle
précis dans l'interface. Cette méthode a été mise
au point en 1979 par Trygve Reenskaug, qui travaillait alors sur Smalltalk dans
les laboratoires de recherche Xerox PARC.
Une application web respectant ce modèle sera
architecturée de la façon suivante :
Figure n° II-3-1: Pattern MVC
Le traitement d'une demande d'un client se déroule selon
les étapes suivantes :
1. le client fait une demande au contrôleur. Ce
contrôleur voit passer toutes les demandes des clients. C'est la porte
d'entrée de l'application. C'est le C de MVC.
2. le contrôleur traite cette demande. Pour ce faire, il
peut avoir besoin de l'aide de la couche métier, ce qu'on appelle le
modèle M dans la structure MVC.
3. le contrôleur reçoit une réponse de la
couche métier. La demande du client a été traitée.
Celle-ci peut appeler plusieurs réponses possibles. Un exemple classique
est
· une page d'erreurs si la demande n'a pu être
traitée correctement
· une page de confirmation sinon
4. le contrôleur choisit la réponse (vue) à
envoyer au client. Celle-ci est le plus souvent une page contenant des
éléments dynamiques. Le contrôleur fournit ceux-ci à
la vue.
5. la vue est envoyée au client. C'est le V de MVC.
3.2 Modélisation des
interactions
Les diagrammes d'interaction représentent le
système comme une collection d'objets qui coopèrent. Les
diagrammes d'interaction permettent d'établir un lien entre les
diagrammes de cas d'utilisation et les diagrammes de classes : ils montrent
comment des objets communiquent pour réaliser une certaine
fonctionnalité. Ils apportent ainsi un aspect dynamique à la
modélisation du système.
On distingue deux types de diagrammes d'interaction UML :
· Le diagramme de séquence dynamique
Le diagramme de séquence est un diagramme
d'interaction mettant l'accent sur la chronologie de l'envoi des messages. Les
principales informations contenues dans un diagramme de séquence sont
les messages échangés entre les lignes de vie,
présentés dans un ordre chronologique. A la différence du
diagramme de séquence système, le diagramme de séquence
dynamique explore le système. Il présente alors les messages
envoyés par les objets qui composent le système.
· Le diagramme de communication
Le diagramme de communication ou collaboration est un diagramme
d'interaction mettant l'accent sur l'organisation structurelle des objets qui
envoient et reçoivent des messages.
Contrairement à un diagramme de séquence, un
diagramme de communication rend compte de l'organisation spatiale des
participants à l'interaction, il est souvent utilisé pour
illustrer un cas d'utilisation ou pour décrire une opération. Le
diagramme de communication aide à valider les associations du diagramme
de classe en les utilisant comme support de transmission des messages.
En fait, diagramme de séquence et diagramme de
communication sont deux vues différentes mais logiquement
équivalentes d'une même chronologie, ils sont dits isomorphes.
La modélisation des interactions permet de concevoir
la dynamique du système. Lle explique comment les demandes client sont
satisfaites en organisant le système selon le modèle MVC. Nous
n'illustrerons pas toutes les interactions du système, mais
présentons certaines interactions réalisées entre les
acteurs et le système.
Mémoire de fin de cycle CHAPITRE
2
SAKITI Lionel
|
65
|
|
|
3.2.1 Gestion des incidents
· Ouverture d'incident
Dans la procédure d'ouverture d'un incident, on observe
plusieurs étapes :
o L'utilisateur demande au contrôleur incident à
ouvrir un incident.
o Le contrôleur charge la vue correspondante
o L'utilisateur renseigne l'incident et envoie au
contrôleur
o Le contrôleur charge les données et les envoie
à la vérification
o Ensuite, selon la vérification :
· Si elle est mauvaise, le contrôleur renvoie la vue
« erreur incident»
· Si elle est bonne, il charge le modèle
d'accéder aux bases données et d'enregistrer l'incident
ACCES DONNEES
<<interne>>
Exploitant
4.1.b: ecrire(alerte)
1.1.b: ref:= concat(anneecourante(),"/",nbincidents)
1.1: afficherFormulaire(ref)
3.1 .2.b: afficherticket(ligne)
PRESENTATION
1.1.a: nbincidents:= nbreLignesTable(incident)
3.1.2.a: ligne:= lire(incident)
nouvincident:formulaire
3.2.1[retour]: afficherFormulaire(incident[ ])
2.1: incident[ ]:= chargerInfos(formulaire)
1.2: redigerIncident(ref)
CONTROLE
1: envoiIncident(ref)
3.2[verif=faux]: retour:= renvoyerInfos(i ncident[ ])
incident:verif
2.2: verif:= testChamps(incident[ ])
Utilisateur
COUCHE METIER
3.1[verif=vrai]: ouvrirIncident(ref)
4.2.a: liste:= ExploitantsEnLligne()
4.2.b[i:= 1 ..taille(liste)]: afficheralerte(matricule)
4.1.a[ajout=vrai]: creerAlerte(incident)
3.1.1: ajout:= ecrire(incident)
:alerte
:incident
pfctmi:BD
Figure n° II-3-2: Diagramme de communication
illustrant l'ouverture d'un nouvel incident
Toutes les interactions entre un acteur et le système,
dans leur logique d'application,
sépareront les couches suivantes :
o La couche présentation o La couche contrôle
o La couche métier
o La couche d'accès aux données.
· Résolution d'incident
Le contrôleur reçoit et traite toutes les
actions de l'utilisateur. Les requêtes parviennent au contrôleur
sous la forme générale "action=" suivies d'autres informations
fournies par l'utilisateur. Selon l'action, le contrôleur charge les vues
nécessaires et effectue les redirections. Chaque entité de la
couche métier se charge alors de réaliser l'interface avec la
couche d'accès aux données.
solution
contrôle
:vue
pfctmi:BD
Utilisateur
action="resoudre"&id="idincident"
chargerInfos(action)
envoiDonnees(id)
alt
ajout=faux
affiche("resolution impossible")
mail(listeSuivi[ ].mail,"étape de
résolution", ligne[ ])
affiche(resolution)
DSD Resolution incident
chargerInfosIncident(id)
:incident
[lecture=vrai]: incident[ ]:= envoiDonnees
lecture:= lireB
|
D(incident)
|
|
interface:= choixFormulaire("resolution", incident[
])
affiche(interface)
action=ajoutligne&incident[ ]
ligne[ ]:= chargerInfos(interface)
initier(incident[ ])
resoudre(ligne[ ])
ajout:= ecrireBD(incident)
ajout=vrai
BD(incident)
l isteSuivi[ ]:= envoiDonnees(id, suivi)
choisirAffichage(resolution)
lecture:= lire
<<interne>>
Exploitant
Figure n° II-3-3: Diagramme de séquence
illustrant la résolution d'un incident
|
67
|
Mise en place d'une plate-forme d'intégration d'outils
de supervision : cas du CTMI-UEMOA
|
|
|
3.2.2 Gestion des alertes
· Génération d'alerte
La génération d'une alerte est automatique.
Lorsqu'une base de données des applications de supervision envoie une
information d'alerte, cette dernière est traitée par le
système qui la stocke. Après le traitement le contrôleur
d'alerte affiche aux exploitants connectés (par un système de
rafraichissement de page) les dernières alertes
générées.
<<interne>>
Exploitant
5[i:=1..nbalertes]: ajout:= ecrire(alerte)
1: etatconnect:= seConnecter(chaine) 3: listealertes[]:=
produireAlerte(flux)
2[etatconnect=vrai]: fl ux:= envoyerFl ux(adresse)
:Traitementfl ux
:BDsuperv
4: nbalertes:= genererAlerte(listealertes[])
5.1: liste:= exploitantsEnLigne()
5.2[ajout=vrai]: afficherAlerte(alerte,l iste)
:alerte
pfctmi :BD
Figure n° II-3-4: Diagramme de communication
illustrant la génération d'une alerte
· Transfert d'alerte ou d'incident
Le transfert d'un incident et le transfert d'une alerte
suivent le même processus dans le système. Ils sont rendu
néanmoins transparents à l'utilisateur qui interroge l'un ou
l'autre. Afin de ne pas reprendre la même chose deux fois, Il est
intéressant de le rendre générique. Le contrôleur
doit alors faire la différence pour savoir quelles vues afficher et
quelles classes métier appeler. Pour cela, dans la requête du
client, on introduit une variable « type » qui pointe vers alerte ou
incident selon le transfert sollicité.
|
68
|
|
Mise en place d'une plate-forme d'intégration d'outils de
supervision : cas du CTMI-UEMOA
|
|
type=
incident ou
alerte
DSD Transférer
contrôle
<<interne>>
Exploitant
action="transferer"&type="choix"&id="valeur"
afficher(astreinte[ ])
cocherAstrei nte
nous continuerons le
processus en
considérant le
transfert
d'un incident
:vue
afficher(astreinte)
transfert
:incident
:alerte
pfctmi:BD
chargerInfos(action)
listerAstreinte
lecture:= lireBD(astrei
nte)
alt
type=incident
envoiDonnees(id,action,astreinte[ ])
type=alerte
envoiDonnees(id,action, astreinte[ ])
transferer(astreinte[ ])
ajout:= ecrireBD(id, astreinte[ ])
alt
ajout=faux
ajout=vrai
lecture:= lireBD(id, "t
ransfert")
[lecture=vrai]: astreinte[ ]:= envoidonnees(id,
transfert)
mail(astreinte[ ].mail, infosid, type)
envoiDonnees(type,id)
choisirAffichage [lecture=vrai]: astreinte[ ]:=
envoiDonnees(astreinte)
afficher("Transfert impossible")
astreinte[ ]:= envoiDonnees(type,id)
choisirAffichage
Figure n° II-3-5: Diagramme de séquence
illustrant le processus générique de transfert
|
69
|
|
Mise en place d'une plate-forme d'intégration d'outils de
supervision : cas du CTMI-UEMOA
|
|
3.2.3 Volet d'administration
· Processus global d'administration de la plate-forme
Le volet d'administration représente le back office de
la plate-forme d'intégration. Le Back Office
désigne l'ensemble des parties du système d'information
auxquelles l'utilisateur "final" (exploitant, responsable) n'a pas
accès. Il s'agit donc de tous les processus internes nécessaires
au bon fonctionnement de l'application.
> ajout, modification, suppression des ressources
(entités) métier ;
> modification de paramètres ;
> gestion des utilisateurs ;
> gestion des menus;
> gestion de l'astreinte
Les grandes étapes du processus de réalisation
d'une action sont :
1. Sollicitation de l'action par l'utilisateur
2. Traitement de l'action par le contrôleur pour le choix
de la vue correspondante
3. Vérification des données utilisateur
4. Chargement de classe métier correspondante et
interactions avec la base de données
5. Affichage de la vue nécessaire pour l'utilisateur
Interfaces IHM d'administration
2) IHM(action)
1) action==>
<==affiche IHM
envoi donnees(IHM)==>
<== 5)affiche resultat (IHM)
transmet (action)==>
<==envoi IHMØ
choix IHM
BUS
transmet donnes(IHM)==>
verif
transmet(donnees, action)==>
<==etat modif base
choix metier
dans le cas d'une operation qui modife la base
controleur
3)verifie donnees (IHM)
Administrateur
les actions possibles: créer, modifier, supprimer,
afficher
4)crée objet(donnees, action)
Classes métier
agir sur les données
pfctmi :BD
Figure n° II-3-6: Processus d'administration et
de maintenance du système
|
70
|
|
Mise en place d'une plate-forme d'intégration d'outils de
supervision : cas du CTMI-UEMOA
|
|
IHM
1.2.1 .a: choix:= newIHM(formulaire)
choix:IHM
1.2.1 .b: donnees[ ]:= donneesIHM(formulaire)
1.1: transmet(choix)
1 .2.2.a: interface:= envoiForm(formulare, donnees[ ])
1: new?choix=action
1 .2.2.b: afficherFormulaire(interface) 2:
envoidonnees(interface)
3.3.b: affficherformulaire(interface, ligne)
2.1 .a: donnees[ ]:= chargerInfos(interface)
2.1 .b: verif:= testChamps(donnees[ ])
contrôle
choix:verif
Administrateur
3[verif=vrai]: transmet(choix, donnees[ ])
3.1: metier:= inclureclasse(choix)
choix:metier
3.2.1: chargedonnees(donnees[ ])
Metier
3.3.a[ajout=vrai]: ligne:= lire(metier)
3.2.2: ajout:= ecrire(metier)
pfctmi:BD
Figure n° II-3-7: Diagramme de communication
illustrant le processus de création
générique
Mémoire de fin de cycle CHAPITRE
2
· Processus de création générique
d'un objet
Afin d'illustrer la logique implémentée dans le
back office, nous avons mis en place un processus générique de
création d'un objet métier. Cette logique s'applique à
tous les autres aspects de l'administration de la plate-forme (modification,
suppression, lecture).
3.3 Diagramme de classe conception
3.3.1 Diagramme de classe
métier
L'entrée de l'analyse à ce niveau, est le
modèle des besoins utilisateur (les cas d'utilisation UML).
Il s'agit de modéliser les éléments et
mécanismes principaux du système. On identifie les
éléments du domaine, ainsi que les relations et interactions
entre ces éléments :
· les éléments du domaine sont liés
au(x) métier(s) de l'application,
· ils sont indispensables à la mission du
système,
· ils gagnent à être réutilisés
(ils représentent un savoir-faire).
Le diagramme de classes ci-dessous présente les classes
intrinsèquement liées aux objectifs métiers de ladite
application.
73
Mémoire de fin de cycle CHAPITRE
2
SAKITI Lionel
etat : "en
cours"
ou "résolu"
ou "cloturé"
reference=AnneeCourante/ Domaine/Nbreincidents
format de l'heure
hh:mm :ss
- id
- heureDebut - heureFin
<<entity>>
Indisponibilite
- reference - domaine - categorie
- commentaires - indGravite
- etat
+ creer ()
+ transferer () + qualifier () + modifier () + supprimer () +
reporter () + imprimer () + creerXml ()
- dateOuverture : Date
: int
: date
: date
0..1
*
ouvre
<<entity>>
Incident
0..*
- dateResolution - message
- commentaires - fichier
*
: boolean
: collection Astreinte : int
: int
: boolean : date
: boolean
: boolean
- date : date
: String : String : String : String : int
: String
génere
subit
*
resoud
*
: Date
: String
: String
: String
0..1
- id
- libelle
0..1
en cas de probleme , la
personne avec l'indice la
plus
faible sera avisée
premierement
Exploitant
Service
porte sur
: int
: String
0..1
0..1
- libelle : String
- type
- indGravite - message
- date
+ generer () + qualifier () + transferer () + supprimer () +
reporter () + afficher ()
concerne
1..1
1..*
Responsable
*
- modele
- numSerie
- matricule - nom
- prenom
- login
- motPasse - mail
- numPort - fonction
- pole
+ seConnecter () + seDeconnecter () + estConnecte () +
nbSessions () + chargemenus ()
<<entity>>
Alerte
: String : int
: String : Date
Equipement
: boolean : int
: collection Astreinte : boolean
: date
: alerte
<<entity>>
Utilisateur
+ listerIncidents () : int
*
*
: String
: String
: int
: String : String : String : String : String : String :
String : int
- indice
- dateDebut - dateFin
*
- nom - type - adresse
- emplacement
- commentaires
+ ajouterService () : int
: Boolean : int
: Boolean : int
: array
Astreinte
<<entity>>
RessourceSuperv
: int
: Date
: Date
0..*
*
0..*
0..*
genere
: String : String : string : String : String
charge
crée
Applicatif
supervise
Bd Exploitation
supervise
0..*
1..1
*
1..1
- id
- login
- motPasse - portCon - adresse - sgbd
- nombd
+ envoiFlux () + triFlux ()
+ executer ()
- dateReq - requete
+ creeUser ()
+ supprimerUser () + MetAJourUser () + ajoutMenuUser ()
1..*
*
Bases de données des
ouils de supervision
-
-
+ afficher () + cacher ()
interroge
<<entity>>
BdSuperv
titre
lien
<<entity>>
menu
Administrateur
: Date
: String
: int
: String : String : int
: String
: String
: String
- crypterFlux () : int
: String
: String
: String
: tableau : Boolean
Bases de données
critiques du
CTMI-UEMOA
: int
: int
BdCtmi
: Utilisateur : Boolean : Utilisateur : Utilisateur
inclut
*
0..1
Mémoire de fin de cycle CHAPITRE
2
SAKITI Lionel
|
74
|
|
|
3.3.2 Diagramme de classe
d'application
Afin d'implémenter le pattern MVC (Model- View-
Controller), nous avons dégagé le diagramme de classes ci-dessous
en séparant le modèle, les différentes vues et les
contrôleurs. L'accès aux données a aussi été
présenté. Chaque contrôleur exécute des actions bien
définies. CRUD signifie Create (créer)- Read (lire)- Update
(mettre à jour)- Delete (supprimer). Pour chaque objet de la classe
métier, ces quatre actions sont définies.
<<interface>>
metier
* agit
+ CRUD ()
+ verifiedonnees ()
*
<<acces donnees>>
BD
- chaineConnexion - requete
- erreurs
: string
: string
: array
*
+ traiterchaine () + lire ()
+ ecrire ()
+ seConnecter ()
+ seDeconnecter ()
: int
: tableau : boolean : boolean : boolean
envoie données
*
- libelle : String
+ chargermetier () + chargervue ()
+ transfereraction () + verifiedonnees ()
control eu r
: metier
: vue
: controleur : boolean
*
charge
*
*
- fichier
- donnees
+ affiche () : boolean
vue
: String
: tableau
*
appelle
1..1
execute
1..*
- libelle
- donnes
action
: string
: tableau
Figure n° II-3-9: Diagramme de classe illustrant
l'architecture de la plate-forme
CHAPITRE 3
Réalisation et Déploiement de la
plate-forme
1. Choix technologiques
·
· Choix du langage de
programmation (PHP)
Le langage PHP est utilisé, principalement comme
langage de script côté serveur, ce qui veut dire que c'est le
serveur qui va interpréter le script PHP et générer du
code (constitué généralement d'XHTML ou d'HTML, de CSS, et
parfois de JavaScript) qui pourra être interprété par un
navigateur.
PHP dans sa version 5, est sorti le 13 juillet 2004. Il
utilise Zend Engine 2. Il introduit un véritable modèle
objet, une gestion des erreurs fondée sur le modèle des
exceptions, ainsi que des fonctionnalités de gestion pour les
entreprises. PHP 5 apporte beaucoup de nouveautés, telles que le support
de SQLite, qui est un système léger de gestion de bases de
données embarqué, au détriment de la bibliothèque
cliente de MySQL, plus puissante mais qui n'est désormais plus
activée par défaut, ainsi que des moyens de manipuler des
fichiers et des structures XML basés sur libxml2 :
· une API simple nommée SimpleXML,
· une API Document Object Model assez complète,
· une interface XPath utilisant les objets DOM et
SimpleXML,
· intégration de libxslt pour les transformations
XSLT via l'extension XSL,
La gestion des objets en PHP a été
complètement réécrite avec PHP5, permettant de meilleures
performances ainsi que plus de fonctionnalités. Cette
réécriture offre des possibilités équivalentes
à celles de Java.
·
· Choix du système de
gestion de base de données (MySQL)
MySQL est un système de gestion de bases de
données fonctionnant sous Linux et Windows. La version 5 de MySQL
présente comme fonctionnalités:
· Intégration des contraintes
d'intégrité référentielles,
· Intégration des procédures
stockées,
· Intégration des Triggers,
· Intégration des vues,
· Meilleure intégration du langage SQL standard.
MySQL est une solution libre qui s'est rapidement
imposé comme un concurrent solide dans les bases de données
adossées aux services Web. La raison principale est la rapidité
d'exécution de son moteur, et une certaine souplesse d'utilisation.
Les données que stocke une application de supervision
ne sont pas très conséquentes. Elle ne nécessite donc pas
d'employer une base de données qui est très gourmande en
ressources et qui est le plus souvent utilisée pour des systèmes
d'information qui manipulent des données d'une quantité
énorme. En outre, compte tenu des requêtes, qui sont à
intervalles régulièrement très proches, il est important
d'obtenir des temps de connexion et d'exécution très faibles. Au
vu de ces avantages inhérents à MySQL, notre choix s'est
posé sur ce dernier.
·
· La bibliothèque PEAR (PHP
Extension and Application Repository)
PEAR est une bibliothèque de scripts PHP. La
bibliothèque est composée de packages eux-mêmes
composés de scripts. Chaque package constitue une
fonctionnalité.
En utilisant un code de qualité pré
écrit et réutilisable, le cycle de développement d'un
logiciel est allégé. L'exploitation et l'enrichissement de la
base de code PEAR contribuent à améliorer les délais de
livraison des projets et à produire de meilleures applications,
aujourd'hui et par la suite.
La mission de PEAR est de fournir :
· Une librairie structurée de code source libre pour
les utilisateurs de PHP
· Un système de distribution du code source et de
maintenance des paquets.
· Un style de codage pour les programmes écrit en
PHP
· Une bibliothèque d'extensions de PHP (PECL - PHP
Extension Code Library
2. Structure des données
2.1 La base de données de la
plate-forme
Toute la modélisation a débouché sur un
diagramme de classes qui va servir de base pour la programmation
orientée objet. Certaines données doivent être
persistées, notamment les objets métier. Notre choix s'est
porté sur l'utilisation d'une base de données relationnelle pour
stocker les données persistantes et les paramètres de
configuration.
Le schéma de la page suivante explique la structure de la
base de données et les relations entre les différentes tables.
Figure n° III-2-1: Schéma relationnel de
la base de données
79
Mise en place d'une plate-forme d'intégration d'outils de
supervision : cas du CTMI-UEMOA
2.2 Intégration des
données
L'intégration des différentes bases de
données permet de définir un modèle unique de mappage des
données. Il y a plusieurs types de données utiles à la
plate-forme d'intégration qu'elle peut directement puiser au niveau des
bases de données existantes : les ressources supervisées, les
informations d'alertes et les indisponibilités.
Le schéma ci-dessous présente l'architecture des
données à exploiter dans la base de données de Orion
SyslogViewer.
Figure n° III-2-2: Modèle de base de
données d'Orion SyslogViewer
La table Syslog sera mappée sur la table Alerte de la base
de données de la plate-forme d'intégration selon le tableau
ci-dessous.
|
Alerte
|
Syslog
|
|
dateGen
|
laDate
|
|
TypeAl
|
"Réseaux"
|
|
indGravite
|
Si SyslogSeverity= 0, 1 => 2 (critique) Si SyslogSeverity
=2 => 1 (avertisseur) Si SyslogSeverity =3 ou 4 =>0 (faible)
|
|
Message
|
Concaténation (Hostname, Message)
|
Tableau n ° III-2-1: mappage entre la table
syslog et la table alerte
|
Mémoire de fin de cycle CHAPITRE
3
SAKITI Lionel
|
81
|
|
3. Structure de la plate-forme
d'intégration
3.1 Communication entre les composants de la
plate-forme
Le langage de programmation utilisé est PHP,
couplé avec MySQL comme SGBDR. Le but de cette partie est d'expliquer
comment sera implémenté le pattern MVC avec un langage de
programmation tel que PHP.
3.1.1 Processus
d'authentification
L'authentification est le point d'entrée pour
accéder à l'application. En effet, il présente à
l'utilisateur, l'écran de connexion lui indiquant d'inscrire ses
identifiants de connexion. Après l'authentification, le contrôleur
général gère toutes les actions utilisateurs.
saisir identifiants
<<vu e>>
Login .php
<<cl asse>>
User.class.php
menu et onglets
inclut
donnees[ ]
stockage de
toutes les actions
possibles
gestion des
alertes
controleAlerte.php
<<controle>>
main.php
foote r. ph p
entete.php
controleSurv.php
procedures de
surveillance générale
<<fichier>>
confi g. ph p
inclut
utilise
<<Base de données>>
pfctmi
Utilisateur
inclut
<<classe>>
MDB2.php
<<bibliotheque>>
PEAR
<<classe>>
B D.cl
ass. ph p
Figure n° III-3-1: Illustration de la
procédure d'authentification
3.1.2 Le contrôleur
frontal
Le système est organisé sous forme de modules
qui sont indépendants d'un point de vue besoins mais qui s'appellent
entre eux. L'avantage de cette construction est de pouvoir séparer le
développement de l'application par modules pour les confier à
plusieurs équipes. Pour la synchronisation et l'intégration de
tous les modules, un contrôleur frontal (main.php) est mis en place. Le
contrôleur frontal représente le contrôleur
général de l'application. Il récupère et traite
toutes les actions des utilisateurs. Il oriente les actions utilisateur vers le
contrôleur du module demandé par l'utilisateur. Le
contrôleur frontal fait en quelque sorte le pont entre tous les
contrôleurs modulaires.
Pour cela, il inclut un fichier de configuration (config.php) qui
renferme toutes les actions utilisateurs et les modules correspondants.
<<controle>>
controleAlerte.php
donnees[ ]
controleSurv.php
<<controle>>
main.php
php
fo n
selon l'action charge le
controleur du
module
correspondant a partir du
fichier de config
action utilisateur
inclut
inclut
<<controle>>
controleIncident.php
inclut
<<controle>>
controleSurv.php
<<controle>>
ControleAdmin.php
<<fichier>>
config.php
Figure n° III-3-2: Appel des contrôleurs
modulaires
3.1.3 Gestion de la zone d'administration (back
office)
Dans le volet administration, plusieurs actions sont
gérées par la plate-forme d'intégration. D'une
manière générale, ces actions concernent l'ajout, la
modification, la suppression et l'affichage. C'est le contrôleur du
module d'administration (controleAdmin.php) qui gère le back office.
Selon l'action sollicitée par l'administrateur, le contrôleur
frontal sollicite le contrôleur d'administration qui prend en charge
l'action pour valider son déroulement.
Prenons par exemple la création d'un utilisateur.
1. l'administrateur clique sur le lien «
main.php?action=new&obj=utilisateur».
2. Le contrôleur frontal demande au contrôleur
d'administration qui charge le formulaire de création d'un nouvel
utilisateur (new.php?obj=utilisateur ou newUser.php).
3. L'utilisateur envoie les informations concernant
l'utilisateur avec la méthode post avec
action=controleAdmin.php?obj=utilisateur&verif.
4. Le contrôleur d'administration charge la couche
métier d'effectuer la vérification et l'ajout. Dans ce cas, il
transmet à utilisateur.class.php qui communique avec la classe
d'accès aux données (db.class.php) pour le stockage dans la base
de données.
5. Après validation, le contrôleur d'administrateur
signifie à l'administrateur que l'utilisateur a été bien
créé.
Chaque contrôleur intègre une partie
choixvue et choixverif qui permettent
respectivement de charger la vue correspondante ou la classe métier
correspondante.
Le contrôleur renvoie la vue correspondante à
l'utilisateur.
utilise
<<fichier>>
confi g . ph p
inclut
Utilisateur
Astreinte
action administrateur
<<vue>>
n ew.p h p
RessourceSuperv
BdSuperv
<<controle>>
main.php
contr leAlertephp
foote.php
etephp
surv.php
donnees[ ]
<<vue>>
m od
if.ph p
choixvue
<<controle>>
ControleAdmin.php
<<vue>> supprimer
ch oi xverif
<<classe>>
Ressou rceSu
perv. ph p
<<classe>>
BdSuperv.class.php
Uti li sateu r.cl
ass. ph p
<<classe>>
Astrei nte.class.php
inclut
inclut
inclut
inclut
<<Base de données>>
pfctmi
BdSuperv
Utilisateur
<<classe>>
BD.class.php
utilise
Ressou rceSu perv
Astreinte
Figure n° III-3-3: Processus global
d'administration de la plate-forme
|
84
|
|
Mise en place d'une plate-forme d'intégration d'outils de
supervision : cas du CTMI-UEMOA
|
|
|
Mémoire de fin de cycle CHAPITRE
3
SAKITI Lionel
|
85
|
|
3.1.4 Gestion des incidents
Toutes les actions concernant la gestion des incidents sont
gérées par le contrôleur d'incident (controleIncident.php).
Lorsqu'un incident est critique, l'utilisateur peut décider de
générer l'alerte correspondante. Pour ce fait, le
contrôleur incident passe la main au contrôleur alerte en lui
envoyant les informations nécessaires pour la génération
d'alerte.
action utilisateur
controleAlerte controleSurv.php footerphp tth
<<controle>>
main.php
donnees[ ]
choixvue
choixverif
<<vue>>
modifIncident.php
<<vue>>
newIncident.php
modif
resoud re
<<vue>>
afficheIncident.php
<<controle>>
controleIncident.php
<<controle>>
controleAlerte.php
appelle
Figure n° III-3-4: Procédure globale de
gestion des incidents
3.2 Les interfaces
Homme-Machine
Les interfaces homme-machine sont les différentes vues
qui sont présentées par le système à l'utilisateur
final. Ces interfaces doivent être conviviales et explicites. Les
différentes vues sont chargées par les contrôleurs. A
chaque demande utilisateur, le contrôleur charge la vue
correspondante.
· Les vues de création
Elles concernent la création d'un objet et se
présentent sous la forme de formulaires à renseigner par
l'utilisateur. Entre autres on peut citer :
o l'ouverture d'un incident
o la création d'un utilisateur
o La création d'une ligne d'astreinte, etc.
· Les vues de modification (mises à jour)
Elles exploitent les vues de création pour modifier les
données stockées dans la base de données.
· Les vues d'affichage
Elles concernent la présentation des données. On
distingue: o la liste des incidents
o La liste des alertes
o Le planning d'astreinte, etc.
· Les vues d'erreur
Elles sont associées aux contrôleurs afin de
gérer toutes les erreurs qui surviennent dans le chargement des pages ou
les réponses aux actions utilisateur.
o Erreur de lecture et d'écriture dans la base de
données o Erreur de données dans les formulaires
o Erreur de chargement de pages ou d'actions, etc. Quelques vues
sont présentées en annexes.
3.3 Déploiement de la
plate-forme
3.3.1 Contraintes
La plate-forme d'intégration réutilise les
informations stockées au sein des bases de données des
différents outils de supervision. La fiabilité de ces
données engage donc ces outils de supervision. Néanmoins, La
plate-forme d'intégration et les outils de supervision doivent
communiquer pour permettre la récupération des données.
MySQL par défaut est installé avec l'utilisateur
root (sans mot de passe) avec tous les droits. Il est important de créer
un utilisateur et de lui donner les rôles nécessaires.
shell>mysql -u root
- Création de l'utilisateur
mysql>GRANT privilèges ON
nom_base.tables[ou *.*] TO 'user'@'localhost' IDENTIFIED BY 'mot _de_passe'
WITH GRANT OPTION
- Attribution des privilèges
mysql>FLUSH PRIVILEGES;
- Changement du mot de passe
mysql>SET PASSWORD FOR "user@'localhost' =
PASSWORD('mot_de_passe'); ou
mysql>UPDATE mysql.user SET
PASSWORD=PASSWORD('mot_de_passe') WHERE User="user;
3.3.2 Logique de
déploiement
La plate-forme d'intégration est orientée vers
une architecture 3-tiers. La
présentation est interfacée avec
le serveur apache. Le métier implémente les
fonctionnalités et l'accès aux données
fait l'interface avec le serveur MySQL.
Figure n° III-3-5: Architecture
3-tiers
Le schéma ci-dessous détaille l'organisation au
sein de chaque serveur.
Figure n° III-3-6: Architecture
applicative
Pour faciliter le déploiement et la maintenance de la
plate-forme d'intégration, une norme d'organisation des
répertoires a été définie. Tous les fichiers de
configuration sont stockés dans un répertoire. Le
répertoire « images » permet de stocker toutes les images
utilisée par les différentes vues. Le répertoire «
scripts » contient les feuilles de style et les scripts externes
(JavaScript, etc.). Chaque module a son fichier de configuration. Chaque module
est dans un répertoire donné. Cette normalisation permet de
faciliter l'ajout des modules. Cette organisation est définie dans le
schéma suivant:
Figure n° III-3-7: Arborescence de la
plate-forme d'intégration
CONCLUSION ET PERSPECTIVES
Le problème général qui nous a
été posé était : Comment contrôler
aisément les outils de supervision mis en place au sein du CTMI-UEMOA ?
La solution adoptée est la mise en place d'une plate-forme
d'intégration. Nous avons alors séparé la conception de la
plate-forme en plusieurs points :
· Définir une logique
d'intégration des outils de supervision
Les différentes couches de la logique d'intégration
sont :
o Intégration des données
o Intégration de l'authentification
o Modélisation des alertes
o La génération d'états
o La visualisation des données
· Centraliser les alertes des différents
outils de supervision
Chaque outil de supervision gère ses alertes et les
stocke dans une base de données. Afin de centraliser les alertes, un
filtrage et une qualification sont effectués. Une procédure de
gestion des alertes a été mise en place.
· Développer des modules
d'exploitation
Les outils de supervision ne prennent pas en compte
l'exploitation des informations qu'ils renvoient. Nous avons alors
analysé et conçu un volet d'exploitation en tenant compte des
procédures d'exploitation rédigées par le CTMI-UEMOA. Il
porte sur la gestion des incidents et la gestion de l'astreinte.
Ensuite, nous avons orienté le projet dans une dimension
réelle de développement logiciel :
· Analyse et conception (élaboration de deux cahiers
de charges : fonctionnel et technique)
· Développement logiciel sous la base du cahier de
charges technique.
Au terme de ce stage, nous avons donc analysé et
conçu la plate-forme d'intégration ce qui rend sa
réalisation plus aisée à une équipe de
développement logiciel.
Nous avons mis en place les modules de gestion d'astreinte et
de gestion des incidents. Le module de gestion d'astreinte qui est interne au
CTMI-UEMOA constitue un volet très utile dans la gestion des alertes et
la gestion des incidents.
Dans la conception, nous avons orienté la plate-forme
d'intégration vers une architecture modulaire. Cette architecture rend
le fonctionnement global de la plate-forme d'intégration
indépendant du déploiement des modules. Elle permet un maintien
du noyau de la plate-forme d'intégration qui n'a pas d'incidence
réelle sur l'utilisation des modules.
La plate-forme d'intégration vient renforcer
l'exploitation et la supervision informatique. Elle représente l'outil
de base de l'équipe d'exploitation informatique. De fait, il prendra en
compte, au fur et à mesure de sa maintenance, les besoins de
l'exploitation informatique.
Néanmoins, la plate-forme d'intégration pourrait
connaitre des améliorations. Au nombre des perspectives que nous
proposons, on peut indiquer :
· L'intégration d'outils de supervision
open source
L'intégration d'outils de supervision libres est plus
aisée parce que le code source est rendu accessible en lecture et en
écriture. Plusieurs outils "open source" de supervision réseaux
et systèmes s'affirment et connaissent une forte communauté
d'utilisateurs. On peut citer: Nagios/Centreon ou Zabbix.
· Le déploiement de services
web
Concevoir des services web autour de la plate-forme
d'intégration facilitera aux banques, établissements financiers
et postaux de l'UEMOA, la supervision de leurs ressources. Par exemple, une
banque délégataire peut développer une application pour
charger les informations de supervision ou générer des
états sur ses différents GAB.
On peut mettre en place une version de la plate-forme
d'intégration accessible à partir des téléphones
portables. L'utilisation des services web évitera un
redéploiement entier de la plate-forme. Lorsqu'un ingénieur se
déplace et désire connaitre l'état d'un équipement
ou la disponibilité d'une ressource, il peut accéder à
partir de son téléphone portable.
· La conception d'une plate-forme
entièrement paramétrable
L'évolution de la plate-forme vers un projet
entièrement paramétrable est un atout facilitant sa maintenance.
Ce paramétrage permettra d'ajouter des modules à la plate-forme
d'intégration sans être obligé de toucher au code.
L'utilisation de la plate-forme sera alors plus autonome.
Pour ce fait, il faudra se baser sur une convention de codage,
ce qui rendra uniforme la création des modules. Par exemple, le
répertoire d'un module sera module suivi du Nom
du Module. Le fichier de configuration du module (configModule.php)
contient toutes les actions à envoyer au module que le contrôleur
générique chargera simplement. Cela en appelle à une
conception plus minutieuse.
Bibliographie
Bibliographie
> Modélisation objet avec UML,
Pierre-Alain Muller, Nathalie Gaertner
Webographie
> Encyclopédie en ligne :
http://fr.wikipedia.org
> Documentation sur PHP :
http://fr.wikibooks.org/wiki/Programmation_PHP
> PHP et Pattern MVC :
http://tahe.developpez.com/web/php/mvc/,
Mars 2005 > Documentation sur PEAR :
http://pear.php.net/manual/fr/
> La supervision informatique :
http://www.linagora.org/IMG/pdf/
~ Supervision libre :
SupervisionLibreReportingAvance.pdf, Février 2006 >
Administration réseaux et système :
http://p2004ir.free.fr/
Annexes
1. Plaquettes de présentation du
CTMI-UEMOA
2. Interfaces de la plate-forme
d'intégration
> Authentification
> Panneau général de supervision
> Ouverture d'un ticket d'incident
| 
