Mise en place d'une plate forme d'intégration d'outils de supervision: cas du ctmi-uemoa

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

<<interne>> Responsable

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

SAKITI Lionel	40

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

SAKITI Lionel	71

· 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

	inclut		inclut

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