Rapport PFE Emna GHRIB Et Wissem DRISSI

Diplôme National d’Ingénieur en Sciences Appliquées et Technologiques
1
République Tunisienne
Ministère de l’Enseignement Supérieur

et de la Recherche Scientifique
Université de Tunis El Manar
Institut Supérieur d’Informatique d’El Manar
Rapport de Projet de Fin d’Études
Présenté en vue de l’obtention du

Spécialité : Génie Logiciel et Systèmes d’Information
Par
Emna GHRIB Wissem DRISSI
« Monitor and trace »

Outil de supervision destiné pour le système
"Vermeg IPM and WM"
Encadrants professionnels : M. Mosab HSIS

M. Sabri BOUBAKER
Encadrant académique : Dr. Ines GAM
Réalisé au sein de Vermeg
Année Universitaire 2015 - 2016

République Tunisienne
Ministère de l’Enseignement Supérieur

et de la Recherche Scientifique
Université de Tunis El Manar
Institut Supérieur d’Informatique d’El Manar
Rapport de Projet de Fin d’Études
Présenté en vue de l’obtention du

Spécialité : Génie Logiciel et Systèmes d’Information
Par
Emna GHRIB Wissem DRISSI
« Monitor and trace »

Outil de supervision destiné pour le système
"Vermeg IPM and WM"
Encadrants professionnels : M. Mosab HSIS

M. Sabri BOUBAKER
Encadrant académique : Dr. Ines GAM
Réalisé au sein de Vermeg
Année Universitaire 2015 - 2016

J’autorise l’étudiant à faire le dépôt initial du mémoire ou de l’essai aux fins d’évaluation.
Encadrant professionnel,
Le
J’autorise l’étudiant à faire le dépôt initial du mémoire ou de l’essai aux fins d’évaluation.
Encadrant académique, Dr. Ines GAM
Le
Dédicaces
A mes parents
A qui je dois toute ma réussite. C’est grâce à vous que j’ai pu faire mes premiers pas dans
la vie et réaliser mes ambitions. votre pureté, droiture et honnêteté me serviront de modèle.
Ce travail est le fruit de vos innombrables sacrifices. J’en serai éternellement reconnaissant.
A ma soeur et mon frère
Je vous ai toujours trouvé proches de moi pour m’écouter, me soutenir et me conseiller.

J’en suis très reconnaissant. Que la vie ne vous réserve que de la réussite.
A ma fiancé
Qui a cru en moi et m’a soutenue par ses précieux conseils. Que Dieu te garde pour moi.
A mes amis
Qui m’apportez beaucoup. Votre amitié m’est plus précieuse que de l’or.
Emna GHRIB
i
Dédicaces
La vie n’est qu’un éclaire,

et un jour de réussite est un jour trés cher. A mes chers parents,
Que nulle dédicace ne puisse exprimer ce que je leurs dois ,pour leur bienveillance et leur
soutien..Trésors de bonté, de générosité et de tendresse, en témoignage de mon profond
amour et ma grand reconnaissance
"que dieu vous grade".
A mes chers frères et soeurs,

En témoignage d mes sincères reconnaissances pour les efforts qu’ils ont consenti pour
l’accomplissement de mes études.je leurs dédie ce modeste travail en témoignage de mon
grand amour et ma gratitude infinie.
A tous mes amis ,

Pour leurs aide et leur soutien moral durant l’élaboration de travail de fin d’etude .
Wissem DRISSI
ii
Remerciements
Nos vifs remerciements s’adressent tout d’abord, particulièrement, à Monsieur Mosab

HSIS et Monsieur Sabri BOUBAKER, chefs de projet chez Vermeg, pour nous avoir accueilli
au sein de leurs équipes. Leurs connaissances et assistances nous ont été d’un précieux apport.
Nous tenons aussi à remercier notre encadrante Dr.Ines GAM, enseignante à l’Institut
Supérieur d’Informatique de Tunis (ISI), pour ses orientations, conseils et remarques, et de
la qualité de nos rapports professionnels. Nous sommes reconnaissants de tout ce qu’elle nous
a appris. Qu’elle trouve ici l’expression de nos profondes gratitudes et reconnaissances.
Nous tenons à remercier chaleureusement nos familles respectives qui n’ont cessé de
nous encourager et de nous aider aux moments difficiles pour que nous réussissons au mieux.
Nous tenons aussi à remercier vivement toutes les personnes qui de près ou de loin ont
contribué au bon déroulement de ce projet. Qu’elles trouvent ici l’expression de nos profondes
gratitudes.
Enfin nous adressons nos remerciements les plus dévoués aux membres du jury pour
nous avoir honoré en acceptant d’évaluer ce travail tout en espérant qu’ils y trouvent les
qualités de clarté et de motivation qu’ils attendent.
iii
Table des matières
Introduction générale 1
1 Cadre du projet 3
1.1 Organisme d’accueil . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.2 Département d’accueil . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.3 Présentation du projet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
1.3.1 Situation de départ et problématique . . . . . . . . . . . . . . . . . . . . . . . 6
1.3.2 Objectifs et contribution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
1.4 Méthodologie adoptée . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
2 Étude préalable 11
2.1 Etude de systèmes existants . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
2.1.1 Nagios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
2.1.2 Centreon . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
2.1.3 Etude Comparative . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
2.2 Concepts à expliquer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
2.2.1 Java Management eXtensions (JMX) . . . . . . . . . . . . . . . . . . . . . . 15
2.2.2 Byte Code Instrumentation (BCI) . . . . . . . . . . . . . . . . . . . . . . . . 15
2.2.3 Processus du byte code java . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
2.2.4 Java Agent . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
2.2.5 ASM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
3 Analyse des besoins 18

3.1 Recensement des besoins . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
3.1.1 Besoins fonctionnels . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
3.1.2 Besoins non fonctionnels . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
3.2 Identification des acteurs du système . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
3.3 Spécification des besoins . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
3.3.1 Diagramme de cas d’utilisation global . . . . . . . . . . . . . . . . . . . . . . 22
3.3.2 Diagramme de cas d’utilisation «Monitoring JVM» . . . . . . . . . . . . . . . 24
iv
3.3.3 Diagramme de cas d’utilisation «Monitoring JBOSS» . . . . . . . . . . . . . . 26
3.3.4 Diagramme de cas d’utilisation «Superviser les sessions» . . . . . . . . . . . . 28
3.3.5 Diagramme de cas d’utilisation «Superviser la base de données de "Vermeg
IPM and WM"» . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
3.3.6 Diagramme de cas d’utilisation «Gérer les privilèges» . . . . . . . . . . . . . . 31
3.3.7 Diagramme de cas d’utilisation «Configurer les requêtes de supervision» . . . 32
3.3.8 Diagramme de cas d’utilisation «Tracer le code» . . . . . . . . . . . . . . . . 34
4 Architecture et conception du système 36

4.1 Architecture globale du système . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
4.1.1 Architecture opérationnelle . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
4.1.2 Architecture logicielle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
4.2 Conception détaillée . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
4.2.1 Aspect statique . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
4.2.2 Aspect dynamique . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
5 Réalisation et test 58
5.1 Choix technologiques et tehniques . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
5.1.1 Environnement matériel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
5.1.2 Environnement logiciel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
5.2 Technologie utilisées . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
5.2.1 Technologies de programmation . . . . . . . . . . . . . . . . . . . . . . . . . . 60
5.2.2 Technologies web . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
5.2.3 Framework et outils . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
5.3 Architecture logicielle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
5.4 Réalisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
5.4.1 Page d’accueil . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
5.4.2 Module de Monitoring JVM . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
5.4.3 Module de Monitoring JBoss . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
5.4.4 Module de Monitoring Oracle . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
5.4.5 Module Code tracer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70
5.5 Tests de la solution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70
v
5.5.1 Test unitaire . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
5.5.2 Test de performance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
Conclusion générale 75
Bibliographie 77
vi
Table des figures
1.1 Clients de Vermeg autour du monde . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

1.2 Organigramme de Vermeg . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.3 Organigramme du departement "Asset Management" . . . . . . . . . . . . . . . . . . 6
1.4 Schéma récapitulatif de la gestion des erreurs . . . . . . . . . . . . . . . . . . . . . . 7
1.5 Vue d’ensemble de l’application . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
1.6 Planification du projet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
2.1 Interface du logiciel Nagios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

2.2 Interface du logiciel Centreon . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
2.3 Processus du byte code java . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
3.1 Diagramme de cas d’utilisation global . . . . . . . . . . . . . . . . . . . . . . . . . . 22

3.2 Diagramme de cas d’utilisation pour «Monitoring JVM» . . . . . . . . . . . . . . . . 24
3.3 Diagramme de cas d’utilisation pour «Monitoring JBoss» . . . . . . . . . . . . . . . 26
3.4 Diagramme de cas d’utilisation pour «Superviser les sessions» . . . . . . . . . . . . . 28
3.5 Diagramme de cas d’utilisation pour «Superviser la base de données de Vermeg IPM
and WM» . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
3.6 Diagramme de cas d’utilisation pour «Gérer les privilèges» . . . . . . . . . . . . . . . 31
3.7 Diagramme de cas d’utilisation pour «Configurer les requêtes de supervision» . . . . 32
3.8 Diagramme de cas d’utilisation pour «Tracer le code» . . . . . . . . . . . . . . . . . 34
4.1 Architecture opérationnelle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37

4.2 Architecture logicielle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
4.3 Architecture de la couche présentation . . . . . . . . . . . . . . . . . . . . . . . . . . 38
4.4 Diagramme de paquetage du module JVM . . . . . . . . . . . . . . . . . . . . . . . . 41
4.5 Structure de la couche présentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
4.6 Structure de la couche RestService . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
4.7 Strcuture de la couche Métier . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
4.8 Diagramme de classe de la couche modèle . . . . . . . . . . . . . . . . . . . . . . . . 49
4.9 Diagramme de déploiement de l’outil M&T . . . . . . . . . . . . . . . . . . . . . . . 50
vii
Table des figures
4.10 Diagramme de séquence pour la supervision de la mémoire du JVM . . . . . . . . . . 51

4.11 Diagramme de séquence pour la supervision des threads actifs dans la JVM . . . . . 52
4.12 Diagramme de séquence pour la mesure des performances de (M&T) . . . . . . . . . 52
4.13 Diagramme de séquence pour l’affichage des informations de la VM . . . . . . . . . 53
4.14 Diagramme de séquence pour la superviservision du serveur d’application JBoss . . 53
4.15 Diagramme de séquence pour la suivie des sessions . . . . . . . . . . . . . . . . . . . 54
4.16 Diagramme de séquence pour la configuration des requêtes de supervision . . . . . . 55
4.17 Processus de « Traçage du code » . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
5.1 Outils utilisés . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60

5.2 technologies utilisées . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
5.3 Architecture Logicielle de M&T . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
5.4 Authentification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
5.5 Page d’accueil . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
5.6 Supervision de la mémoire de la JVM . . . . . . . . . . . . . . . . . . . . . . . . . . 65
5.7 Supervision des threads . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
5.8 Supervision de la VM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
5.9 Supervision de la mémoire de JBoss . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
5.10 Supervision des sessions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
5.11 Supervision des sessions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
5.12 "Advanced Monitoring 1" . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68
5.13 "Advanced Monitoring 2" . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68
5.14 Résultat d’une requête de monitoring . . . . . . . . . . . . . . . . . . . . . . . . . . . 68
5.15 Configuration du module Oracle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
5.16 Ajout d’une requête de monitoring . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
5.17 Résultat de l’ajout de la requête de monitoring . . . . . . . . . . . . . . . . . . . . . 70
5.18 Traçage du code . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70
5.19 Test de traçage du code . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
5.20 Configuration Jprofiler . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72
5.21 Performance du "Memoy pool" . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72
5.22 Performance du CPU . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73
5.23 Performance des classes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73
viii
5.24 Performance du "GC activity" . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74
5.25 Performance des threads . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74
ix
Liste des tableaux
1.1 Gestion du projet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
2.1 Tableau comparatif de Nagios et Centreon . . . . . . . . . . . . . . . . . . . . . . . . 14
3.1 Description textuelle du cas d’utilisation «Monitoring JVM» . . . . . . . . . . . . . . 25

3.3 Description textuelle du cas d’utilisation «Monitoring JBOSS» . . . . . . . . . . . . 27
3.5 Description textuelle du cas d’utilisation «Superviser les sessions» . . . . . . . . . . . 28
3.7 Description textuelle du cas d’utilisation «Superviser la base de données de "Vermeg
IPM and WM"» . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
3.9 Description textuelle du cas d’utilisation «Gérer les privilèges» . . . . . . . . . . . . 31
3.11 Description textuelle du cas d’utilisation «Configurer les requêtes de supervision» . . 33
3.13 Description textuelle du cas d’utilisation «Tracer le code» . . . . . . . . . . . . . . . 34
5.1 Frameworks et outils utilisés . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
x
Liste des abréviations
— BCI = Byte Code Instrumentation
— JMX = Java Management Extensions
— JVM = JavaVirtuelle Machine
— M&T = Monitorand Trace
xi
Introduction générale
L’informatique est devenue l’épine dorsale de l’entreprise quel que soit son secteur d’activité.
L’importance de fidéliser et avoir la confiance de ses clients est vitale pour elle. Partis de ce postulat,
les entreprises ont recherché des procédés visant à garantir la qualité des solutions qu’elles proposent.
Les problèmes liés à l’informatique doivent, donc être réduits au minimum, car l’indisponibilité
immédiate des solutions a des impacts très préjudiciables sur l’activité et sur la notoriété d’une
entreprise.
En effet, il existe deux enjeux majeurs pour les directions informatiques. Le premier est de
garantir la disponibilité et les niveaux de service du système en cas de panne ou de dégradation des
performances. Le second est de tenter de prévenir en cas de problème et, le cas échéant, garantir une
remontée d’information rapide et une durée d’intervention minimale.
Pour satisfaire ses clients et assurer ses performances, l’entreprise éditrice de logiciels doit
mettre en place un système de monitoring et de traçage du code. C’est dans ce cadre se situe notre
projet intitulé « "Monitor and Trace" Outil de supervision destiné pour le système "Vermeg IPM
and WM" », qui consiste à concevoir et développer une outil de monitoring pour la solution «Vermeg
Institutional Portfolio Management And Wealth Management » qui se présente essentiellement sur
deux axes : Le premier est celui de la supervision des composants, et le second s’appuie sur le traçage
d’un ou plusieurs scénarii de l’application au moment de son exécution.
Notre rapport documente la gestion et le developpement mis en place pour réaliser notre
projet. Le premier chapitre intitulé "Cadre du projet" est consacré, d’abord, à une présentation
générale du projet et de l’environnement de travail. Ensuite, la problématique est présentée ainsi que
la méthodologie adoptée. Dans le second chapitre intitulé « Étude préalable », nous passons par un
tour d’horizon sur les notions en relation avec notre sujet. Ensuite, nous faisons une étude de l’existant
et nous finissons par mettre en valeur le choix des technologies utilisées. Dans le troisième chapitre
"Analyse des besoins", nous présentons une analyse des besoins fonctionnels et non fonctionnels de
la solution proposée ainsi que la modélisation de ces besoins par le recours aux diagrammes de cas
d’utilisation. Dans le quatrième chapitre "Architecture et conception du système",nous abordons
l’architecture générale de l’application et offrons un aperçu des diagrammes de conception utilisés.
Cet aperçu mènera à la conception générale des différentes fonctionnalités offertes. Cette conception
est réalisée en utilisant le langage de modélisation UML en présentant le comportement statique et
1
Introduction générale
dynamique de la solution proposée. Ensuite, le cinquième chapitre intitulé « Réalisation et Test de la

solution » qui est réservé à l’implémentation de l’application, où nous récapitulons les différents outils
utilisés, présentons les différentes interfaces homme/machine de la solution proposée et réalisons des
tests de notre application. Finalement, le rapport est clôturé par une conclusion générale qui résume
notre travail et propose les éventuelles perspectives de ce travail.
2
Chapitre 1
Cadre du projet
Plan
1 Organisme d’accueil . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
2 Département d’accueil . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
3 Présentation du projet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
4 Méthodologie adoptée . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
Chapitre 1. Cadre du projet
Introduction
Ce chapitre, se situe dans le cadre général de notre projet. Cette étude consiste à présenter
l’organisme et le département d’accueil « Vermeg » et « Vermeg Institutional Portfolio Management
and Wealth Management ». Ensuite, nous introduisons le sujet tout en faisant une étude de l’existant
ainsi que sa critique. Enfin, nous exposons la méthodologie de gestion de projet adoptée pour notre
projet.
1.1 Organisme d’accueil
La société Vermeg située aux Berges du lac à Tunis, est fondée en 2002 comme entreprise
indépendante de la société mère BFI, établie depuis 1994. Vermeg est doté d’une ingénierie experte
en monétique et en édition de logiciels bancaires et financiers pour la gestion des titres et des
capitaux. Depuis sa création, elle n’a cessé de développer son expertise en finance pour offrir
une large gamme de logiciels innovants réalisant une multitude de fonctions pour les middle et
back-offices des institutions concernées par le traitement des titres. Vermeg emploie aujourd’hui
plus de 700 collaborateurs, ingénieurs et consultants. Elle compte parmi ses clients les plus grandes
banques et institutions financières de renommée mondiale Grupo Santander, Société Générale, ABSA
(Groupe Barclays), Banque de France, Banque d’Angleterre, Central Bank of Ireland, Raiffeisen
Zentralbank Group, Bangkok Bank, Aviva, Groupama, National Bank of Kuwait. Vermeg offre un
visage international et multiculturel et intervient dans plus d’une vingtaine de pays répartis sur trois
continents comme la montre la figure 1.1 [1]
Figure 1.1: Clients de Vermeg autour du monde
Dans le but d’assurer un niveau de qualité compatible avec les exigences clients les plus
élevées, Vermeg Tunisie a certifié son système de management de la qualité suivant les référentiels
ISO/IEC 27001, ISO 15022 et ISO 20022.
4
1.2 Département d’accueil
L’entreprise se compose des quatre départements, représentés par la figure 1.2, suivants :
• Marketing et Sales : département responsable du marketing, de la gestion des ventes et de la

prospection ;
• Customer Services : le département qui gère les relations avec le client et comprend également
une cellule de veille technologique ;
• Recherche et Développement : le département qui gère le développement et effectue les tests

et la validation des applications ;
• Support : département responsable du support IT, de l’assistance à l’installation et l’utilisation

des produits livrés et des mises à jour.
Figure 1.2: Organigramme de Vermeg
De plus, depuis 2014, suite à l’acquisition de BSB International (Business Solutions Builders),
une société belge, éditeur de logiciels axés sur l’assurance-vie, les pensions et les soins de santé, la
gestion d’actifs et les secteurs de gestion de patrimoine. Le département « Asset Management » a
vu le jour et a été connu avant avec le nom «Vermeg BSB ». Ce département est dotée d’un service
"Vermeg Institutional Portfolio Management and Wealth Management" (IPM and WM) qui est une
solution de back-to-front pour la gestion institutionnelle et la gestion de fortune. Ce projet de fin
d’études a été réalisé au sein des deux équipes : «Support» et «Architecture». La mission de l’équipe
de «Support» consiste à assurer la gestion de tout nouveau produit ainsi que permettre l’élaboration
du plan de maintenance spécifique à chaque processus durant le cycle de développement du logiciel.
Quant à l’équipe d’«Architecture», son rôle est d’assurer la conception et le développement des
nouvelles solutions Vermeg, ainsi que l’évolution des applications existantes à travers la maintenance
corrective et évolutive. La figure 1.3 représente l’organigramme de ce département. [2]
5
Figure 1.3: Organigramme du departement "Asset Management"
1.3 Présentation du projet
Nous allons présenter notre projet, comme le montre la figure 1.4, tout en abordant son
contexte et les limites de la solution existante pour aboutir à la solution proposée.
1.3.1 Situation de départ et problématique
Dans certaines situations, un client Vermeg confronterait des problèmes lors de l’utilisation
d’une application. Afin de le signaler, il procède par ouvrir un « ticket » destiné aux développeurs
Vermeg pour qu’il soit pris en charge et que les personnes chargées corrigent les erreurs. Pour ce faire,
le client envoi un fichier « Log » bien spécifique aux développeurs pour qu’ils localisent l’erreur et
la corrigent. Ces erreurs peuvent être, par exemple,du à un espace mémoire insuffisant dans la JVM
ou dans le serveur de base de données Oracle, d’un mauvais déploiement du serveur d’application,
ou bien d’un « bug » dans le code source de l’application.
L’approche utilisée par le département « Vermeg IPM and WM –Support » et celle du
département « Vermeg IPM and WM –Architecture » répond partiellement aux attentes. Néanmoins,
les approches adoptées possèdent certains inconvénients, à savoir la localisation de l’erreur générée
vu que le fichier log peut contenir des centaines même des milliers de lignes, donc ça peut couter des
heures et des jours pour pouvoir préciser l’emplacement de l’erreur.
Également, le processus adopté lors de la détection d’une anomalie au niveau du serveur
de base de données est très long : En effet, lors du décèlement de l’erreur, le client doit faire une
réclamation. Puis, Vermeg lui envoie un script à exécuter avant de refaire sa routine. Une fois l’erreur
est détectée, le client envoie le fichier log à Vermeg pour pouvoir cerner l’erreur en répétant ce
processus à chaque fois que c’est necessaire. Dans certains cas, la localisation de l’anomalie nécessite
une vue globale ou spécifique sur l’état du serveur en question. Cette supervision n’existait pas.
6
Figure 1.4: Schéma récapitulatif de la gestion des erreurs
1.3.2 Objectifs et contribution
Vermeg a en conséquence identifié le besoin de concevoir et développer un outil de monitoring

et de traçage du code pour son produit « Vermeg IPM and WM».
Cet outil a pour but de superviser la JVM, le serveur d’application Jboss et celui de base de
données Oracle en temps réel tout en dégageant les indicateurs nécessaires.De plus, ce travail a pour
but de tracer le code d’une application tierce en runtime.
Pour le serveur de base de données Oracle, en plus de l’exportation des indicateurs liés à cet
SGBD, nous devons simplifier le processus de détection des erreurs, d’exécution du script SQL et
d’envoi du résultat tout en stockant les requêtes de ce script dans une base de données.
En ce qui concerne la détection des bugs de codage, nous sommes invités à développer un
module de traçage du code qui permet de débuguer un ou plusieurs scénarii de l’application cible.
Ce traçage doit être fait au moment du « Runtime » sans aucune modification du code source.
Pour introduire notre contribution, notre application propose quatre volets à savoir le monitoring
du JVM, celui du serveur d’application Jboss ainsi que le serveur de base de données Oracle et enfin
le traçage du code comme le montre la figure 1.5.
7
Figure 1.5: Vue d’ensemble de l’application
1.4 Méthodologie adoptée
Afin de mettre en place les fonctionnalités resencées, nous avons adopté la méthodologie
Agile pour la gestion du projet où nous avons suivi un cycle de vie itératif et incrémental lors du
developpement de notre application.
Une méthode agile est une approche itérative et incrémentale dont les tâches s’effectuent petit
à petit, par ordre de priorité, avec des phases de contrôle et d’échange avec le client. [3] La finalité
de cette méthode est de générer un produit de haute qualité en prenant en compte l’évolution des
besoins des clients.
La méthode Scrum est une méthode agile qui s’appuie sur le découpage des projets en itérations «
Sprints ». Chaque sprint commence par une estimation suivie d’une planification opérationnelle, et
se termine par un prototype prêt à être utiliser.
Parce que Scrum est une méthode de gestion de projet Agile et qui permet de travailler en
petite équipe, d’une manière itérative et incrémentale, nous nous sommes inspirés tout au long de
la réalisation de notre projet. En effet, la méthode Scrum définit 3 rôles à savoir :
• Le Product Owner : Celui qui porte une vision globale du produit à réaliser, et qui travaille
en interaction avec l’équipe de développement. Dans notre projet, nos trois encadrants Vermeg
et ISI jouent le rôle du Product Owner ;
• Le Scrum Master C’est le coach auprès du Product Owner et l’équipe de développement.

Son rôle est de s’assurer que Scrum est correctement appliqué. [4] Dans notre cas, c’est notre
encadrant universitaire qui était en communication continue avec les encadrants Vermeg ;
• L’équipe de développement : Elle est chargée de transformer les besoins exprimés par le
product Owner en fonctionnalités utilisables. Nous avons formé cette équipe de développement
par deux ingénieurs.
8
Planification du projet Afin de mieux expliquer ce concept, nous illustrons par le schéma
de la figure 1.6 le cycle de gestion du projet suivi tout au long de la réalisation de notre projet selon
la méthode Scrum.
Figure 1.6: Planification du projet
Cette planification est récapitulée dans le « Backlog Produit » qui est « une liste ordonnée
de tout ce qui pourrait être requis dans le produit et est l’unique source des besoins pour tous les
changements à effectuer sur le produit » [5].La gestion et le découpage du projet sont récapitulés
dans le tableau 1.1.
Tableau 1.1: Gestion du projet
Sprint Sprint 1 Sprint 2 Sprint 3 Sprint 4
Description Module JVM Module JBoss Module Oracle Module Code

Tracer
Equipe Equipe composée de Equipe composée de Equipe composée de Equipe composée de

deux développeurs deux développeurs deux développeurs deux développeurs
9
Product Deux encadrants Deux encadrants Deux encadrants Deux encadrants

Owner techniques techniques techniques techniques
Scrum Encadrante de l’ISI Encadrante de l’ISI Encadrante de l’ISI Encadrante de l’ISI

Master
Durée 1 mois 1 mois 1 mois 1 mois
Conclusion
Dans ce chapitre, nous avons situé le projet dans son cadre général en présentant l’organisme
d’accueil et le sujet en faisant une étude descriptive et critique de l’existant, puis nous avons introduit
la solution qui s’inscrit dans le cadre de notre projet en précisant la méthodologie adoptée. En vue
d’avoir une idée plus claire sur le projet, une étude préalable est faite dans le chapitre suivant afin
de comprendre les concepts généraux et d’étudier les outils existants.
10
Chapitre 2
Étude préalable
Plan
1 Etude de systèmes existants . . . . . . . . . . . . . . . . . . . . . . . . . . 12
2 Concepts à expliquer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
Chapitre 2. Étude préalable
Introduction
Dans ce chapitre, nous réalisons une étude de systèmes de monitoring qui existent sur le
marché. Ensuite, nous effectuons une étude sur les concepts généraux autour desquels tourne notre
solution, et nous clôturons avec les choix technologiques.
2.1 Etude de systèmes existants
Durant la partie de préparation de notre solution, nous avons effectué une étude des systèmes
existants sur le marché afin de connaitre leurs caractéristiques et leurs fonctionnalités et ainsi nous
nous inspirons un nouvel outil personnalisé qui répond aux besoins de Vermeg.
2.1.1 Nagios
Nagios est un logiciel de supervision destiné à informer l’utilisateur des problèmes éventuels
dans leurs systèmes d’informations avant que leurs clients, utilisateurs ou managers ne le fassent. Il
est prévu pour fonctionner sur système d’exploitation Linux mais fonctionne également sans problème
sur la plupart des variantes *NIX. Le démon de supervision effectue des contrôles intermittents sur les
hôtes et services spécifiques en utilisant des plugins externes qui retournent un statut d’état à Nagios.
Quand des problèmes surviennent, il peut envoyer des notifications à des contacts administratifs de
façons différentes (email, SMS, messagerie instantanée, etc. . . ). [6]
Les informations d’états courants, les historiques et les rapports peuvent être consultés à
partir d’un simple navigateur. La figure 2.1 présente l’interface de Nagios.[7]
12
Figure 2.1: Interface du logiciel Nagios
2.1.2 Centreon
Centreon est un logiciel de supervision des applications, systèmes et réseaux, basé sur les
concepts de Nagios. Le cœur de Centreon est Open Source distribué sous licence GPL v2 et gratuit.
Des modules complémentaires à valeur ajoutée payants sont distribués par l’éditeur. Des
modules complémentaires gratuits et open sources sont développés par des contributeurs sur git
hub.
Centreon fournit une interface simplifiée pour rendre la consultation de l’état du système
accessible à un plus grand nombre d’utilisateurs, y compris des non-techniciens, notamment à
l’aide de graphiques de performance. Les techniciens ont cependant toujours accès aux informations
techniques de l’ordonnanceur.[8] [9] La figure 2.2 [10]montre l’interface du logiciel Centreon.
13
Figure 2.2: Interface du logiciel Centreon
2.1.3 Etude Comparative
Après avoir étudié les deux systèmes de surveillance, le tableau 2.1 présente une étude
comparative selon leurs principales fonctionnalités à savoir la surveillance du JVM, JBoss, et Oracle
et traçage de code.Ces quatre aspects soit cuix qui concernent notre mission.
Tableau 2.1: Tableau comparatif de Nagios et Centreon
Modules Fonctionnalités Nagios Centreon
JVM Surveillance JVM Oui Oui

Dashboard JVM Oui Oui
Surveillance JBoss Oui Oui

JBoss Dashboard JBoss Oui Oui
Surveillance BD Oracle Oui Oui

Oracle
Automatisation du processus de Non Non
détection des erreurs et d’envoie du
résultat lors de l’utilisation de la BD
Code tracer Traçage du code Non Non

Utilisation d’agents sur les machines Oui Oui
cibles
14
Suite à notre étude et bien que les deux outils cités précédemment sont efficaces, Vermeg a
décidé de ne pas les adapter. D’une part, parce que , juridiquement, Vermeg ne peut pas utiliser des
logiciels open sources. D’autre part, la fonctionnalité du traçage du code ainsi que celle d’automatisation
du processus de detection des erreurs du module Oracle n’existent pas dans les outils cités précédemment.
C’est pourquoi nous avons à concevoir et développer un outil de supervision et de traçage de code
pour le système "Vermeg IPM and WM".
2.2 Concepts à expliquer
Afin de mieux comprendre les notions sur lesquelles se base notre solution, nous présentons
ces concepts de bases.
2.2.1 Java Management eXtensions (JMX)
JMX est un standard développé par JCP (Java Community Process) pour la gestion et le
suivi des applications et services. Ce standard définit une architecture de gestion, des design patterns,
des APIs, et des services pour construire des solutions distribuées, dynamiques, et modulaires pour
la gestion de ressources de tous types. L’API JMX rend possible la manipulation et la gestion
d’équipements logiciels ou matériels [11].
C’est dans ce sens que nous avons choisi de l’utiliser afin d’extraire les données spécifiques au module
de JVM ainsi que celui de JBoss
2.2.2 Byte Code Instrumentation (BCI)
BCI est une technique permettant d’ajouter des instructions sous forme byte code à une
classe Java au cours de son exécution et plus précisément, pendant le temps "chargement" de cette
classe Java. [12]
Nous avons opté pour cette technique afin de réaliser le module de traçage du code. En effet, BCI
assure l’instrumentation des applications que nous ne possédons pas leurs code source mais que nous
voulons quand même les débugger et injecter de nouvelles instructions à une ou plusieurs classes.
2.2.3 Processus du byte code java
Après avoir écrit un fichier « .java » qui contient le code source de la routine que nous
voulons exécuter, ce fichier « .java » va être compilé à travers la commande « javac ». Le résultat
15
de ce processus est un fichier « .class », qui va être utilisé au moment d’exécution. Le fichier « .class
» va être stocké dans le « classloader » de la JVM pour qu’elle puisse vérifier son byte code. Ce
dernier est transformé en langage native de l’OS à travers le JRE. La figure 2.3 présente le processus
du byte code java.
Figure 2.3: Processus du byte code java
2.2.4 Java Agent
Pour pouvoir instrumenter une application tierce, nous avons besoin de créer un agent java
qui va exécuter la tâche d’instrumentation.
Un agent Java permet d’instrumenter des programmes s’exécutant dans une JVM en interceptant le
chargement des classes et en modifiant directement le byte code si nécessaire. Un agent est chargé
lors du démarrage de la JVM, accompagné ou non d’options. La JVM est belle et bien consciente de
son existence, si le chargement d’un agent échoue, l’exécution du programme est interrompue. [13]
2.2.5 ASM
Afin d’injecter des instructions aux classes Java de l’application que nous voulons instrumenter,
nous avons utilisé l’ASM.
ASM est une bibliothèque Java de manipulation et d’analyse du bytecode Java. Elle peut être utilisée
pour modifier des classes existantes ou créer dynamiquement des classes, directement sous forme
binaire. Les algorithmes de transformations et d’analyses fournis permettent d’assembler facilement
des transformations complexes et des outils d’analyse statique. ASM fournit des fonctionnalités
similaires aux autres Frameworks de manipulation du bytecode, mais porte une attention particulière
sur la simplicité d’usage et la performance. Il a été conçu pour être aussi petit et rapide que possible,
ce qui le rend intéressant pour être utilisé dans des systèmes dynamiques, mais il peut aussi être
16
utilisé de manière statique. [14]
Conclusion
Dans ce chapitre, nous avons entamé l’analyse de l’existant, qui nous a permis de cerner nos
objectifs afin de développer un système de qualité qui répond aux attentes de l’organisme d’accueil.
Ensuite, nous avons présenté les notions générales en relation avec notre projet. Dans le chapitre
suivant, nous spécifions les besoins fonctionnels et non fonctionnels de notre application.
17
Chapitre 3
Analyse des besoins
Plan
1 Recensement des besoins . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
2 Identification des acteurs du système . . . . . . . . . . . . . . . . . . . . 21
3 Spécification des besoins . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

Chapitre 3. Analyse des besoins
Introduction
Le présent chapitre est consacré à l’identification et l’analyse des besoins qui représentent
une phase importante dans le cycle de développement d’un logiciel. Pour ce faire, Nous présentons,
en premier lieu, les acteurs de notre système, puis nous spécifions les besoins fonctionnels et non
fonctionnels. Ensuite, nous modélisons ces besoins avec les diagrammes des cas d’utilisation en
décrivant et analysant leurs fonctionnalités majeures.
3.1 Recensement des besoins
Suite à l’étude de la problématique, nous avons dégagé l’ensemble des exigences que notre
application doit satisfaire. Ces exigences sont divisées en besoins fonctionnels, besoins non fonctionnels
et contraintes.
3.1.1 Besoins fonctionnels
C’est une description complète où tous les services requis pour l’utilisateur sont spécifiés, c’est
aussi une description consistante, dans la mesure qui ne contient pas des conflits ou contradictions.
Dans ce contexte, notre application doit fournir aux différents utilisateurs les fonctionnalités que
nous spécifions dans cette section.
• Mesure des performances du système :
• Suivre la mémoire vive du système.
• Surveiller l’état du CPU.
• Suivre la mémoire SWAP (disponible, occupée, totale).
• Supervision de la JVM afin de :
• Consulter la mémoire utilisée dans le tas de la JVM.
• Afficher la mémoire hors-tas utilisée de la JVM.
• Notifier lorsque la mémoire atteint un certain seuil bien défini.
• Notifier lorsque mémoire atteint un certain seuil après l’exécution du "Garbage Collector".
• Afficher les threads actifs dans la JVM.
• Superviser le chargement des classes dans la JVM.
• Obtenir des informations sur la machine virtuelle.
19
• Supervision du serveur d’application afin de :
• Afficher la mémoire utilisée dans le tas du serveur d’application,
• Consulter mémoire hors-tas utilisée de serveur d’application.
• Supervision des sessions :
• Consulter toutes les sessions, ainsi que les classer soit selon leurs statuts (Active/Inactive)
ou selon leurs nombre d’exécution,
• Afficher le temps d’attente de chaque requête,
• Exposer le taux total d’utilisation du CPU ainsi que son utilisation par session,
• Afficher le Hit ratio,
• Consulter la taille de mémoire SGA et PGA.
• Configuration des requêtes de supervision :
• Gérer les requêtes (Ajout, Suppression, Affichage).
• Supervision de la BD Oracle de "Vermeg IPM and WM" :
• Lancer des requêtes déjà ajoutées,
• Afficher les résultats des requêtes lancées.
• Gestion du traçage du code :
• Tracer les classes et les méthodes en cours d’exécutions,
• Tracer les paramètres des méthodes exécutées,
• Afficher le nom de la méthode, son package, ses attributs et leurs valeurs, et la valeur de
retour de cette méthode.
3.1.2 Besoins non fonctionnels
L’outil à réaliser doit répondre à un certain nombre d’exigences non fonctionnelles. Elle se
caractérise par :
• Ergonomie : L’interface de l’application doit être simple, conviviale et facile à utiliser. Elle
renseigne l’utilisateur sur le contexte dans lequel il se trouve.
• Performance : Le temps de réponse et le chargement des données doivent être minimaux. La

navigation d’un écran à un autre ne doit pas gêner l’utilisateur.
20
• Sécurité : Une authentification est nécessaire pour que l’utilisateur puisse accéder aux
différents Dashboard et de superviser ou configurer les systèmes voulus.
• Scalabilité : Etant donné que notre application est modulaire ce qui facilite la tâche d’ajouter
d’autre modules, notre solution doit s’adapter à tout changement.
3.2 Identification des acteurs du système
Pour notre système, nous avons identifié les acteurs suivants :
• Superviseur : Il a pour rôle de superviser l’état du JVM, JBOSS et Oracle ainsi que de tracer
le code d’une application tierce.
• Configurateur : Il est responsable de la configuration des requêtes du module Oracle.
De plus, notre application communique avec d’autres systèmes internes du client à savoir :
• SGBD Oracle : Il s’agit d’un serveur de base de données Oracle qui stocke, entre autre, les
données relatives à l’application « Vermeg IPM and WM ».
• Serveur d’application Jboss : Il s’agit d’un serveur installée sur un ordinateur, placée sur
un réseau distribué qui orchestre le logique métier de l’application « Vermeg IPM and WM ».
• JVM : Il s’agit d’une machine virtuelle ou s’exécute l’application «Vermeg IPM and WM»,
puisque c’est une application Java qui ne s’exécute pas directement sur le système d’exploitation.
3.3 Spécification des besoins
Durant cette phase, nous spécifions les besoins fonctionnels dégagés précédemment sous forme
de diagrammes de cas d’utilisation. Nous rappelons que les cas d’utilisation permettent de mettre
en évidence les fonctionnalités proposées aux acteurs par le système. Ils représentent un moyen
d’analyse des besoins et permettent de relier les actions réalisées par l’utilisateur et les réactions
attendues par le système.
Dans le diagramme du cas d’utilisation général de la figure 3.1, nous regroupons tous les cas
d’utilisation de base afin d’avoir une vue globale du fonctionnement de notre système ainsi que
mettre en évidence les éventuelles relations qui peuvent les lier.
21
3.3.1 Diagramme de cas d’utilisation global
Figure 3.1: Diagramme de cas d’utilisation global
En effet, le superviseur peut :
• Mesurer les performances du système tel que le nombre de processus disponibles, le système
d’exploitation utilisé, l’espace swap libre, le taux d’utilisation du CPU ainsi que d’autres
22
informations sur l’état de la mémoire à savoir le taux de mémoire disponible et utilisée.
• Superviser la machine virtuelle Java tout en extractant des informations sur la mémoire tas et
hors-tas, les thread actifs et d’autres informations liées à la VM.
• Superviser le serveur d’application JBOSS tout en affichant sa mémoire tas et hors-tas.
• Superviser la base de données de "Vermeg IPM and WM" : cette fonctionnalité assure le
suivie de l’intéraction de l’application "Vermeg IPM and WM" avec sa base de données Oracle
à savoir le plan d’execution des requêtes SQL, les statistiques par curseur...
• Tracer une application sans modification de son code source afin de pouvoir afficher le nom,
les paramètres et leurs valeurs ainsi que la valeur de retour de chaque méthode en cours
d’execution.
• Superviser les sessions qui permet de suivre les états des sessions et leurs caractéristiques ainsi
que d’extraire des mesures de performance de l’SGBD Oracle à savoir l’utilisation du mémoire
et du CPU.
Tandis que le configurateur peut :
• Configurer les requêtes de supervision tout en consultant les règles (requêtes) de supervision.
Le configurateur peut aussi gérer ces règles tout en ajoutant ou supprimant l’une d’elles. Ainsi,
il peut configurer les tables de supervision tout en créant toutes les tables nécessaires en même
temps ou bien en les supprimant. Il a aussi la possibilité de supprimer et d’ajouter une seule
table de supervision.
• Gérer les privilèges tout en accordant ou enlevant les droits nécessaires à l’utilisateur de la
base de données "Vermeg IPM and WM" "Soliam_User" afin de pouvoir créer les tables de
supervision et d’extraire les données nécessaires d’eux.
23
3.3.2 Diagramme de cas d’utilisation «Monitoring JVM»
Figure 3.2: Diagramme de cas d’utilisation pour «Monitoring JVM»
24
Tableau 3.1: Description textuelle du cas d’utilisation «Monitoring JVM»
Titre : Consulter les statistiques de JVM

Acteur : Superviseur
But : Superviser les statistiques liées à la JVM
Précondition : L’utilisateur doit se connecter à la JVM à superviser
Description : Ce cas d’utilisation permet au superviseur de superviser l’état de la JVM
(mémoire, threads, VM).
Scénario principal :
1. Le superviseur doit choisir la JVM à superviser.
2. Le superviseur peut consulter le dashboard, pour superviser les variations des mémoires
(Tas et hors-Tas) en temps réel. Ainsi, il peut voir les détails de ces mémoires à savoir la
taille initiale, utilisée, maximale et « comited ».
3. Le superviseur peut consulter les threads actifs depuis la JVM ainsi que leurs détails comme
l’id, nom, statut, temps d’attente, temps de blocage, et sa pile d’exécution
4. Le superviseur peut afficher toutes les informations liées à la machine virtuelle comme les
arguments, nom, classPath, classBoot, temps de démarrage et sa version.
Les compléments :
— Ergonomie : Le Dashboard doit être clair et simple à utiliser.
— Précision : Les valeurs de mesure doivent être précises.
— Traçabilité : le Dashboard offre une vision instantanée sur la mémoire de la JVM et garde
l’historique des états précédant.
— Performance : L’affichage du contenu des éléments doit être rapide et optimisé.
25
3.3.3 Diagramme de cas d’utilisation «Monitoring JBOSS»
Figure 3.3: Diagramme de cas d’utilisation pour «Monitoring JBoss»
26
Tableau 3.3: Description textuelle du cas d’utilisation «Monitoring JBOSS»
Titre : Consulter Dashboard de monitoring Jboss

But : Superviser les statistiques liées au serveur d’application Jboss
Précondition : L’utilisateur doit spécifier le serveur d’application JBOSS à superviser.
Description : Ce cas d’utilisation permet au superviseur de superviser l’état du serveur
d’application Jboss.
1. Le superviseur doit spécifier le serveur d’application à superviser
2. Le superviseur peut consulter le dashboard de JBoss, pour superviser les variations des
mémoires (Tas et hors-Tas). Ainsi, il peut voir les détails de ces mémoires à savoir la taille
initiale, utilisée, maximale et «comited»
Les compléments :
— Ergonomie : Le Dashboard doit être clair et simple à utiliser.
— Précision : Les valeurs de mesure doivent être précises.
— Traçabilité : le Dashboard offre une vision instantanée sur la mémoire de JBOSS et garde
l’historique des états précédant.
— Performance : L’affichage du contenu des éléments doit être rapide et optimisé.
27
3.3.4 Diagramme de cas d’utilisation «Superviser les sessions»
Figure 3.4: Diagramme de cas d’utilisation pour «Superviser les sessions»
Tableau 3.5: Description textuelle du cas d’utilisation «Superviser les sessions»
Titre : Superviser les sessions

But : Superviser les sessions ainsi que mesurer les performances du SGBD Oracle
Précondition : Le superviseur doit être connecté en tant que «sysdba» pour pouvoir extraire
les indicateurs souhaités.
28
Description : Ce cas d’utilisation permet, d’une part de suivre les sessions en extractant des
informations sur les sessions actives, les Top sessions, toutes les sessions ainsi que le temps
d’attente des sessions. D’autre part, il permet de mesurer les performances de l’SGBD Oracle en
consultant la mémoire SGA et PGA utilisée, la consommation du CPU et le nombre d’accès au
cache, nommé le «hit ratio».
1. Le superviseur consulte la page de supervision des sessions.
2. Le système affiche les mesures de performances due l’SGBD Oracle tel que la mémoire SGA
et PGA, l’utilisation du cpu ainsi que le hit ratio.
3. Le superviseur choisi de suivre, soit toutes les sessions, soit les sessions actives, soit les top
sessions, soit le temps d’attente des sessions.
Les compléments :
— Ergonomie : L’interface doit être claire et simple à utiliser.
— Performances : Le temps d’affichage des indicateurs doit être minimal.
— Sécurité : Une authentification est nécessaire pour que l’utilisateur puisse accéder à la page
de supervision des sessions.
29
3.3.5 Diagramme de cas d’utilisation «Superviser la base de données de

"Vermeg IPM and WM"»
Figure 3.5: Diagramme de cas d’utilisation pour «Superviser la base de données de Vermeg IPM
and WM»
Tableau 3.7: Description textuelle du cas d’utilisation «Superviser la base de données de "Vermeg
IPM and WM"»
Titre : Superviser la BD de "Vermeg IPM and WM"

But : Superviser l’état de la base de données Oracle de "Vermeg IPM and WM".
Précondition : Le superviseur doit être connecté en tant que «sysdba» pour pouvoir extraire
les indicateurs souhaités.
Description : Ce cas d’utilisation permet de suivre l’interaction de l’application "Vermeg IPM
and WM" avec sa base de données tout en exécutant l’une des requêtes de supervision à savoir
le plan d’exécution par exemple qui permet d’afficher l’historique des requêtes exécutées, ainsi
que d’autres informations sur chaque requête SQL lancée comme son taux d’utilisation du cpu,
le nombre de fois qu’elle était chargée, le nombre de lecture et d’écriture pour chaque exécution,
le temps de la dernière fois qu’elle était active ...
30
1. Le superviseur consulte la page de supervision de la base de données de "Vermeg IPM and
WM".
2. Le système affiche les requêtes de supervision sous forme de boutons.
3. Le superviseur appuie sur un bouton afin de lancer une requête de supervision.
4. Le système exécute la requête et affiche le résultat.

Les compléments :
— Performances : Le temps d’affichage des résultats doit être minimal.
3.3.6 Diagramme de cas d’utilisation «Gérer les privilèges»
Figure 3.6: Diagramme de cas d’utilisation pour «Gérer les privilèges»
Tableau 3.9: Description textuelle du cas d’utilisation «Gérer les privilèges»
Titre : Gérer les privilèges

Acteur : Configurateur
But : Donner et enlever des privilèges de l’utilisateur de la base de données «"Vermeg IPM and
WM"_User».
Précondition : Le configurateur doit être connecté en tant que «Sysdba».
Description : Ce cas d’utilisation permet au configurateur de donner ou enlever des privilèges
de création ainsi que de sélection depuis les tables de supervision.
31
1. Le configurateur donne les privilèges nécessaires à l’utilisateur de la BD «Soliam_User»
2. Le configurateur enlève les privilèges déjà donnés.

Les compléments :
— Performances : L’affectation des privilèges et leur suppression doit être rapide.
3.3.7 Diagramme de cas d’utilisation «Configurer les requêtes de

supervision»
Figure 3.7: Diagramme de cas d’utilisation pour «Configurer les requêtes de supervision»
32
Tableau 3.11: Description textuelle du cas d’utilisation «Configurer les requêtes de supervision»
Titre : Configurer les requêtes de supervision

Acteur : Configurateur
But : Configurer les requêtes de supervision.
Précondition : Le configurateur doit être connecté en tant que «Soliam_User».
Description : Ce cas d’utilisation permet au configurateur de réaliser la configuration des tables
de supervision ainsi que consulter et gérer les requêtes de supervision.
1. Le configurateur consulte la page de configuration.
2. Le configurateur supprime les tables de supervision.
3. Le configurateur crée les tables de supervision.

Scénario alternatif :
1. Le configurateur consulte les règles de supervision.
2. Le configurateur consulte la page de gestion des requêtes de supervision.
1. Le configurateur ajoute une règle de supervision.
2. Le configurateur supprime une règle de supervision.
3. Le configurateur consulte la page de configuration des tables de supervision.
1. Le configurateur configure soit la table «Segment_statistics» ou bien

«Sql_execution_statistics» ou bien «System statistics».
Les compléments :
— Performances : L’affichage de l’interface graphique doit être rapide.
33
3.3.8 Diagramme de cas d’utilisation «Tracer le code»
Figure 3.8: Diagramme de cas d’utilisation pour «Tracer le code»
Tableau 3.13: Description textuelle du cas d’utilisation «Tracer le code»
Titre : Tracer le code

But : Extraire le nom, le package, les attributs et leurs valeurs ainsi que la valeur de retour de
chaque méthode appartenant au package choisi.
Précondition : L’application doit être en cours d’exécution.
34
Description : Ce cas d’utilisation permet au superviseur de tracer le code source d’une

application cible qui est dans notre cas « "Vermeg IPM and WM" », sans modification de
son code source et en injectant des instructions sous format byte code lors de son exécution afin
de pouvoir extraire les informations de chaque méthode citée dans la partie description.
1. Le superviseur consulte la page de traçage du code.
2. Le superviseur configure l’instrumentation en entrant le nom du package à instrumenter.
3. Le superviseur instrumente l’application tout en appuyant sur le bouton «Start».
4. Le système affiche le résultat de cette instrumentation.
5. Le superviseur peut exporter le résultat obtenu.
Les compléments :
— Performances : L’affichage du résultat doit être instantané.
Conclusion
Dans ce chapitre, nous avons analysé les différents besoins de notre système « Monitor and Trace ».
Ces besoins ont été spécifiés à l’aide des diagrammes des cas d’utilisation d’UML. Dans le chapitre
suivant, nous décrivons d’une façon détaillée l’architecture ainsi que la conception de notre système.
35
Chapitre 4
Architecture et conception du
système
Plan
1 Architecture globale du système . . . . . . . . . . . . . . . . . . . . . . . 37
2 Conception détaillée . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
Chapitre 4. Architecture et conception du système
Introduction
Afin de mieux comprendre le système M&T à développer, une démarche de modélisation structurée
s’impose. Nous avons choisi d’utiliser le langage UML pour décrire les différents aspects de notre
système, ce qui permettra de faciliter et structurer le développement. Nous présentons en premier
lieu l’architecture globale que nous avons suivie dans notre application. Ensuite, nous présentons
une vue statique et dynamique du système à l’aide des diagrammes UML.
4.1 Architecture globale du système
En vue des besoins précédemment spécifiés, notre solution doit offrir un large degré d’évolutivité
et d’extensibilité et ce pour chaque élément qui la constitue. Ainsi, nous avons veillé à ce que ces
aspects soient visibles tant dans l’architecture opérationnelle qu’applicative faisant l’objet de cette
partie
4.1.1 Architecture opérationnelle
La solution que nous avons choisie est une application web qui suit l’architecture repésentée par la
figure 4.1.
Figure 4.1: Architecture opérationnelle
Un client léger qui n’est autre qu’un navigateur web permettant à son utilisateur d’accéder à
l’application via internet ou intranet de Vermeg.
Le serveur web qui héberge toutes les couches de notre application à savoir les composants de
AngularsJS, les web services, les modules métier et les méthodes d’accès à la tiers de données.
Un tiers de données qui est constitué de serveurs de base de données, serveurs d’applications et
des JVMs.
37
4.1.2 Architecture logicielle
Par opposition à l’architecture opérationnelle ou il s’agissait de distinguer entre les différents

niveaux physiques de l’application, l’architecture logicielle s’intéresse plutôt au découpage logique de
l’application et la façon de regrouper les composants selon le type de fonction et traitements qu’ils
effectuent. Pour notre solution nous avons opté pour une architecture multi couches illustrée par la
figure 4.3 et que nous présentons ci-dessous.
Figure 4.2: Architecture logicielle
La couche de présentation : Cette couche de plus haut niveau, responsable de l’affichage des
données et de l’aspect visuel et graphique de l’application. Elle fait appel à la couche applicative pour
répondre aux requêtes du client, et elle assure la logique de navigation ainsi que l’authentification
et l’autorisation.
Figure 4.3: Architecture de la couche présentation
38
Comme il est indiqué dans la figure ci-dessus la couche présentation suit l’architecture MVC ou on
a:
• Modèle : il est responsable de la gestion des données de l’application. Il répond à la demande

de la vue et les instructions du contrôleur pour se mettre à jour.
• View : permet la gestion des vues, où chaque vue fonctionne de pair avec un contrôleur. cet
dernier consomme les données en data-binding et appelle les méthodes du contrôleur.
• Contrôleur : il est responsable de la gestion des contrôleurs ou chaque contrôleur contient un

ou plusieurs model de données. Il contient des méthodes propres à la vue ainsi que des variables
d’état ou d’affichage.
La couche web service : Cette couche est constituée par des services web Rest représentent un
mécanisme de communication entre la couche présentation et la couche métier. Cette couche offre à
l’application la possibilité d’être utilisé dans un environnement distribué.
La couche métier : Elle contient tous les traitements métiers de l’application à savoir les
services des différents modules fonctionnels, les services de communication avec le JVM, le serveur
d’application JBoss et l’SGBD Oracle et le traçage de code. Ces traitements sont implémentés sous
forme de services Spring et communiqués à la couche présentation via les services web Rest. Spring
étant un conteneur léger permet de simplifier l’intégration des différentes couches.
La couche modèle : Elle regroupe l’ensemble des objets manipulés dans la couche métier de
l’application.
4.2 Conception détaillée
Cette partie vise à détailler le contenu des différents composants et modules de notre outil «M&T»
et les relations entre eux. Pour ce faire, plusieurs diagrammes UML sont utilisés pour mettre en
relief l’aspect statique et dynamique de notre application.
4.2.1 Aspect statique
Dans cette partie, nous montrons la structure statique de notre outil «M&T». Nous commençons par
une illustration des différents modules de notre application à travers le diagramme de paquetages,
puis nous enchainons avec les diagrammes de classes de chaque module. Enfin, nous illustrons la vue
statique de notre solution par un diagramme de déploiement pour présenter l’infrastructure physique
du système.
39
4.2.1.1 Diagramme de paquetages
Afin de mieux comprendre notre solution, nous présentons dans la figure 4.4 le diagramme de
paquetages qui expose la composition de chaque module.
Chaque module est composé de cinq packages à savoir :
• com.vermeg.monitoring.module_name.presentation : Ce package regroupe les classes

responsables de la création des interfaces graphiques de notre application. Il utilise le package
de sécurité lors de la phase d’authentification.
• com.vermeg.monitoring.module_name.security : Il encapsule les classes qui s’occupent

de la confidentialité et de l’aspect d’authentification et d’autorisation de notre application.
• com.vermeg.monitoring.module_name.service : Dans ce package, nous trouvons les

classes spécifiques aux services web «Rest» qui représente le pont entre la couche de
présentation et celle du métier.
• com.vermeg.monitoring.module_name.metier : Contient la logique métier de notre

solution M&T. ce package communique avec la couche modèle pour servir la couche service.
• com.vermeg.monitoring.module_name.modele : Il regroupe les entités de notre

application. Ces entités permettent le transfert des données depuis la couche métier jusqu’à
arriver à la couche présentation, et vice-versa.
Le mot «module_name» utilisé ci-dessus fait référence aux quatre modules de notre application à
savoir le module JVM, JBoss, Oracle et code tracer.
la figure 4.4 montre l’exemple du module "Monitoring JVM" composé des quatres paqutages cité
précédemment.
40
Figure 4.4: Diagramme de paquetage du module JVM
4.2.1.2 Diagramme de classes
Le diagramme de paquetages précédant contient les modules ainsi que les couches de chaque module
du système M&T à réaliser. Afin de mieux présenter la structure de ces couches, nous présentons les
diagrammes de classe associés.
Structure de la couche présentation :
Comme nous avons mentionné au début de ce chapitre, la couche présentation de notre application
«M&T» est constituée de trois packages :
• Le package Views : Ce package contient toutes les vues de notre application. Chaque vue
est écrite en Html5, Css3 et bootstrap et a pour but d’afficher des résultats et des données
spécifiques aux utilisateurs. Parmi ces views nous citons :
— JvmMemoryView : Cette interface graphique affiche les indicateurs relatifs à la mémoire

de la JVM.
— JvmThreadView : Consiste à afficher les threads qui sont en cours d’exécution.
— JBossView : Cette interface expose les mémoires heap et non-heap du serveur

d’application JBoss.
41
— OracleMonitoringView : Consiste à afficher les indicateurs relatifs aux sessions et à

l’SGBD Oracle.
— OracleConfigurationView : Cette interface graphique permet à l’utilisateur de configurer

les requêtes de monitoring ainsi d’afficher les indicateurs relatives à l’SGBD et l’historique
des requêtes SQL déjà exécutées.
— TracerView : Cette interface graphique permet à l’utilisateur de choisir les packages qu’il
souhaite instrumenter et affiche le résultat retourné.
• Le package Model : Ce package contient le modèle de notre application. il joue le rôle d’un
conteneur pour les différentes parties de notre application tel que les contrôleurs, les services,
les vues...
• Le package Controller : Ce package contient l’ensemble des contrôleurs utilisés. En effet, chaque
vue est liée à un controleur.
— JVMController : Il consiste à présenter les données spécifiques au JVM ainsi que les
traitements des données réalisés côté front-end de ce module.De même pour le module «
JBOSS monitoring ».
— OracleController : Ce contrôleur a pour rôle d’extraire les données depuis la partie

back-end sous format json de notre application tout en décorant la portée des données et
des résultats retournées.
— TracerController : De la même manière des contrôleurs cités précédemment, le contrôleur

TracerController permet d’extraire les données retournées par l’agent lors de son
instrumentation et les expose à l’utilisateur.
42
Figure 4.5: Structure de la couche présentation
Structure de la couche serviceRest

L’accès aux données de chaque module coté back-end se fait à travers une classe RestService. Cette
couche joue le rôle d’un pont entre la «couche métier» qui va fournir les données nécessaires au
client et la «couche présentation» qui va les afficher. Le format des données circulantes entre ces
deux couches n’est d’autre que le format Json qui fournit un support pour une écriture simple et
légère au format texte.
Dans cette couche, nous trouvons quatre classes java dont chacune fait référence à un module.
43
Chaque classe est constituée d’un ou plusieurs services web qui présentent un moyen rapide de
distribution de l’information entre le client et sa plateforme.
La figure 4.6 représente le diagramme de classe de la couche «serviceRest» de notre solution.
Figure 4.6: Structure de la couche RestService
Diagramme de classe de la couche Métier

En ce qui concerne la couche métier, et afin d’assurer le couplage faible, nous avons utilisé des
interfaces ainsi que leurs implémentation. La figure IV-8 illustre le diagramme de classe de cette
couche qui comporte :
— MonitoringJVMImpl : Il s’agit d’une classe qui implémente l’interface MonitoringJVM. Cette

classe offre les opérations d’extraction des données relatives au module JVM.
— QueryService : C’est une interface qui propose des opérations liées à la gestion des requêtes
telles que l’ajout, la suppression ainsi que la consultation.
— DatabaseConnectionImpl : Cette classe implémente les méthodes de l’interface
44
«DatabaseConnection» tout en utilisant la classe «Queries» qui sert à exécuter les requêtes
de monitoring. Elle assure aussi la connexion à la base de données Oracle pour effectuer la
tâche d’authentification.
— AuthentificationImpl : Cette classe assure la gestion des utilisateurs ainsi que la vérification
lors de l’authentification.
— TracerServiceImpl : Cette classe nous offre la possibilité de tracer le code d’une application
cible après que nous lui attachons le java agent.
— Agent : Cette classe est responsable à l’activation de l’agent java pour effectuer
l’instrumentation necessaire.
— ClassTransformer : C’est la classe responsable à effectuer la modification du code d’une classe

lors de son chargement dans la JVM.
— AgentClientConnection : Elle assure la connection à l’application cible à travers l’agent java.
45
Figure 4.7: Strcuture de la couche Métier
46
Strcuture de la couche Modèle
— SystemUser : Cette classe de stéréotype « entity » encapsule les données relatives à l’utilisateur
de l’application. Chaque utilisateur a un rôle à savoir superviseur ou bien un configurateur.
— DBUser : Cette classe de stéréotype « entity » regroupe les informations relatives à l’utilisateur
de la base de données.
— MonitoringQueries :Cette classe de stéréotype « entity » contient des informations sur les
requêtes de supervision comme son id, son nom, description...
— Mbeanserver : Composé de plusieurs Mbean soit du JVM soit du serveur d’application JBoss.
— InformationSystemCPU : Cette classe de stéréotype « entity » Regroupe les données de CPU,

notamment le taux de consommation de système ainsi le taux de consommation de processus
de l’application à superviser.
— InformationThread : Cette classe de stéréotype « entity » encapsule les données relatives aux
threads actifs dans le jvm, comme le nom, l’identifiant, statut de thread et sa pile d’exécution.
— Informationconnection : Cette classe de stéréotype « entity » Permet d’encapsuler les données

relative aux connections soit pour la connexion au jvm, soit pour la connexion au serveur
d’application Jboss.
— InformationSystem : Cette classe de stéréotype « entity » permet de regrouper les données

relatives aux systèmes d’exploitation où elle s’exécute l’application a supervisé.
— InformationVM : Permet d’encapsuler les données relatives à la machine virtuelle tel que
(bootclass, class path, arguments,..).
— InformationGC : Cette classe de stéréotype « entity » encapsule les données relatives au

ramasse miettes (garbage collector), tel que nombre d’exécution de garbage collector le gain
de la mémoire après son exécution.
— InformationMemory : Cette classe de stéréotype « entity » permet d’encapsuler les données

relatives au mémoire de la JVM soit que la mémoire tas ou la mémoire hors-tas.
— InformationClass : Cette classe de stéréotype « entity » encapsule les données relatives au

chargement et le déchargement de class dans le jvm.
— Utilisateur : Cette classe de stéréotype « entity » regroupe les données relatives à l’utilisateur
tel que login, mot de passe, rôle (superviseur, configurateur).
47
— Statics‘_per_cursor : elle regroupe les données relatives aux statistiques pour chaque curseur.
— Execution_plan : Cette classe de stéréotype « entity » contient les données liées au plan
d’exécution de chaque requête.
48
Figure 4.8: Diagramme de classe de la couche modèle
49
4.2.1.3 Diagramme de déploiement
Le diagramme de déploiement décrit la disposition physique des matériels qui composent le système
et la répartition des entités logiques identifiées dans la conception architecturale sur ces matériels.
Chaque machine est représentée par un nœud. [15]
Notre solution s’exécute dans un serveur web conteneur de servlet Tomcat. Les différentes couches, à
savoir la couche présentation, la couche serviceRest, la couche de logique métier et la couche d’accès
aux données s’exécutent dans le conteneur léger spring.
La base de données Oracle ainsi que le serveur des MBeans sont représentés chacun par un nœud.
Notre application communique avec l’application « Vermeg IPM and WM » via les sockets.
Le diagramme de déploiement de notre solution est représenté par la figure 4.9.
Figure 4.9: Diagramme de déploiement de l’outil M&T
50
4.2.2 Aspect dynamique
La vue dynamique permet de modéliser le comportement dynamique de notre système en indiquant

comment ses objets interagissent au moment de l’exécution. Pour se faire, nous utilisons les
diagrammes de séquence.
4.2.2.1 Diagrammes de séquences
Le diagramme de séquence montre les échanges et les interactions entre les différents composants
de notre système M&T selon un point de vue temporel. Dans cette partie nous présentons les
diagrammes de séquence des cas d’utilisation «Suivie Dashboard JVM», «Suivie Dashboard Oracle»,
«OracleConfiguration» et «TracerDashboard».
Diagrammes de séquence pour la supervision de la JVM
La figure 4.14 présente le scénario de supervision de la mémoire de JVM
Figure 4.10: Diagramme de séquence pour la supervision de la mémoire du JVM
La figure 4.14 présente le scénario de supervision des threads actifs dans la JVM.
51
Figure 4.11: Diagramme de séquence pour la supervision des threads actifs dans la JVM
La figure 4.14 présente le scénario de mesure de performances de systeme.
Figure 4.12: Diagramme de séquence pour la mesure des performances de (M&T)
52
La figure 4.14 présente le scénario d’affichage des informations relatives a la machine virtuelle.
Figure 4.13: Diagramme de séquence pour l’affichage des informations de la VM
Diagrammes de séquence de supervision Serveur d’application La figure 4.14 présente le

scénario de supervison de serveur d’application JBoss.
Figure 4.14: Diagramme de séquence pour la superviservision du serveur d’application JBoss
53
Diagramme de séquence pour la suivie des sessions

La figure 4.15 montre le scénario du suivie des sessions ainsi que les indicateurs de l’SGBD Oracle.
Figure 4.15: Diagramme de séquence pour la suivie des sessions
54
Diagramme de séquence pour la configuration des requêtes de supervision

La figure 4.16 présente le scénario du suivie des sessions ainsi que les indicateurs de l’SGBD Oracle.
Figure 4.16: Diagramme de séquence pour la configuration des requêtes de supervision
55
4.2.2.2 Processus de traçage du code
Lors de la phase de l’istrumentation, l’agent calcule le nombre de classes chargées dans la JVM.
Ensuite, il commence à parcourir ces classes une par une tout en injectant des instructions à travers
l’ASM sous forme byte code.
Ces injections de produisent lors de l’entrée et la sortie de chaque méthode avant son exécution et
permettent de fournir comme résultat le nom, le package, les attributs et leurs valeurs ainsi que la
valeur de retour d’une méthode. Ces résultats qui sont sous forme de bytecode seront par la suite
convertit à travers la classe « Base64 » puis la classe sera exécutée. Le résultat va etre envoyé vers
la parte frontend via les web services Rest pour être affichés à l’utilisateur.
Figure 4.17: Processus de « Traçage du code »
56
Conclusion
Au cours de ce chapitre, nous avons mis en place la partie conception de l’application. Ainsi, nous
avons présenté l’architecture adoptée les outils et les Frameworks utilisées. Puis, nous avons montré
une vue statique du système pour, ensuite, analyser son comportement dynamique. Dans le chapitre
suivant, nous décrivons la partie réalisation et test de l’application.
57
Chapitre 5
Réalisation et test
Plan
1 Choix technologiques et tehniques . . . . . . . . . . . . . . . . . . . . . . 59
2 Technologie utilisées . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
3 Architecture logicielle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
4 Réalisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
5 Tests de la solution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70
Chapitre 5. Réalisation et test
Introduction
Après la phase conception du projet, nous présentons la phase de réalisation qui consiste à
implémenter la solution envisagée. A cet effet, nous présentons le cadre de réalisation de notre
solution, à savoir les environnements matériel et logiciel utilisés, puis nous montrons l’essentiel des
interfaces de notre solution à travers des captures d’écran selon un scénario bien déterminé.
5.1 Choix technologiques et tehniques
Nous présentons dans cette section l’environnement matériel ainsi que logiciel utilisés pour le
développement de notre application.
5.1.1 Environnement matériel
Nous mentionnons les caractéristiques des ordinateurs sur lesquelles nous avons développé notre
application pour l’environnement matériel. L’application a été développée en premier temps sur un
ordinateur dont les caractéristiques sont :
— Système d’exploitation : Windows 7, 64 bits ;
— Processeur : Intel Core i7 2.4 GHZ ;
— Mémoire 8 GO de RAM ;
— Disque dur : 500 Go.
Elle a, aussi, été réalisée sur un ordinateur ayant la configuration suivante :
— Système d’exploitation : Windows 10, 64 bits ;
— Processeur : Intel Core i7 2.4 GHZ ;
— Mémoire 8 GO de RAM ;
— Disque dur : 1 To.
5.1.2 Environnement logiciel
Nous énumérons au cours de cette partie les différents outils et technologies employés tout au long
de la réalisation de notre projet. La figure 5.1 récapitule l’ensemble des logos de ces outils.
Outil de modélisation UML «Star Uml» Nous avons exploité pour la modélisation UML de
l’application l’outil Star Uml qui est un logicil open source permettant de gérer les diagrammes
spécifiés dans la norme UML 2.0. [16]
59
Figure 5.1: Outils utilisés
Environnement de développement intégré « Eclipse » C’est un environnement de

développement open source. Il s’agit aussi d’une version évoluée de la Fondation « Eclipse » visant
à développer un environnement de production de logiciels libre, extensible, universel et polyvalent,
en s’appuyant principalement sur Java pour répondre aux besoins des développeurs. [17].
Outil de gestion de base de données « Oracle » Oracle est un SGBDR édité par la société
Oracle Corporation qui a été créée en 1977 par Lawrence Ellison, Bob Miner et Ed Oates. Depuis
sa version 8, il est devenu un « Système de Gesion de Base de Données Relationnel-Objet ». [8]
Serveur d’application « JBOSS » JBoss est un serveur d’application J2EE développé à partir
de 1999 par un français Marc FLEURY. Il est écrit en Java et il est distribué sous licence LGPL.
Grâce au JMX, Jboss permet de charger les différents modules, conteneurs ou plugin en fonction des
besoins, ainsi d’implémenter ses propres services. [18]
5.2 Technologie utilisées
En ce qui concerne les technologies utilisées, nous avons opté à adopter des technologies de
programmation ainsi que celle pour le web.
5.2.1 Technologies de programmation
• Java : C’est est un langage typé et orienté objet. Il est compilé et basé sur une architecture
logicielle très particulière nécessitant une machine virtuelle Java. Il utilise les notions usuelles de
la programmation orientée objet : la notion de classe, d’encapsulation, d’héritage, d’interface,
de virtualité, de généricité. Il est accompagné d’un ensemble énorme de bibliothèques standard
couvrant de très nombreux domaines, notamment des bibliothèques graphiques [19]. C’est un
langage qui présente d’excellentes propriétés de portabilité du code. Nous avons Utilisé le Java
Développement Kit JDK 8.
60
5.2.2 Technologies web
Comme le montre la figure 5.2, nous avons utilisé un ensemble de technologies durant le
développement de notre solution.
Figure 5.2: technologies utilisées
• HTML 5 : (Hyper Text Markup Language / langage hypertexte) est le langage dans lequel
sont écrites les pages du web. Un site web est constitué d’un ou plusieurs documents HTML,
appelées aussi pages. Pour se déplacer d’une page à l’autre dans nos modules on passe par
l’intermédiaire d’hyperliens [20].
• CSS 3 : Les CSS, Cascading Style Sheets (feuilles de styles en cascade), servent à mettre
en forme des Documents web, type page HTML ou XML. Par l’intermédiaire de propriétés
d’apparence (couleurs, bordures, polices, etc.) et de placement (largeur, hauteur, côte à côte,
dessus, dessous, etc.), le rendu d’une page web peut être intégralement modifié sans aucun
code Supplémentaire dans la page web [21].
• Java script : C’est un langage de programmation de scripts principalement utilisé pour les pages
web interactives comme les pages HTML. JavaScript est exécuté sur l’ordinateur de l’internaute
par le navigateur lui-même. C’est une extension du langage HTML qui est incluse dans le
code. Ce langage est un langage de programmation qui permet d’apporter des améliorations
au langage HTML en permettant d’exécuter des commandes [22].
• Bootstrap : C’est un framework destiné aux applications web. Développé par Twitter et
distribué sous licence Apache 2, c’est un outil à considérer lors du développement rapide
d’applications web. L’utilisation combinée du HTML, du CSS, et du JavaScript propose au
développeur des méthodes de développement très efficaces [23].
61
5.2.3 Framework et outils
Ci-dessous un tableau récapitulatif des différents Frameworks utilisées pour le développement de

l’application. Ensuite nous présentons chaque Framework à part :
Tableau 5.1: Frameworks et outils utilisés
Logo Framework Version Description
Spring boot 1.3.5 Conteneur léger
AngularsJS 1.5.6 Framework de présentation MVC
Maven 1.3.5 Outil pour la gestion et

l’automatisation de production des
projets logiciels Java
Log4j 2.0 Outil de logging
• Spring Boot est un nouveau Framework créé par l’équipe de chez Pivotal, conçu pour simplifier
le démarrage et le développement de nouvelles applications Spring. Le Framework propose une
approche dogmatique de la configuration, qui permet d’éviter aux développeurs de redéfinir la
même configuration à plusieurs endroits du code [24].
• AngularJS est un Framework JavaScript libre et open-source, développé par Google. Il est fondé
sur l’extension du langage HTML par de nouvelles balises (tags) et attributs pour aboutir à une
définition déclarative des pages web, par opposition à l’utilisation systématique de l’élément
div et à la définition des éléments de présentation en JavaScript. Le code HTML étendu
représente alors la partie « vue » du patron de conception MVC (Modèle-vue-contrôleur)
auquel AngularJS adhère, avec des modèles appelés « scopes » et des contrôleurs permettant de
définir des actions en code JavaScript impératif. AngularJS utilise une boucle de dirty-checking
(qui consiste à surveiller et à détecter des modifications sur un objet JavaScript) pour réaliser
un data-binding bidirectionnel permettant la synchronisation automatique des modèles et des
vues [25].
Ci-dessous un tableau récapitulatif des différents outils utilisés pour le développement de

l’application. Nous présentons ensuite chaque outil.
62
• Apache Maven est un outil pour la gestion et l’automatisation de production des projets
logiciels Java en général. Nous avons utilisé maven comme outil de construction de notre
projet et d’automatisation des tests de différents modules de l’application [26].
• Log4J est un projet open source distribué sous la licence Apache et maintenu par le groupe
Jakarta. Cette API permet aux développeurs d’utiliser et de paramétrer un système de gestion
de journaux (logs). Le logging permet de gérer des messages émis par une application durant
son exécution et de permettre leur exploitation immédiate ou à postériori [27].
5.3 Architecture logicielle
Après avoir présenté les technologies utilisées pour implémenter notre solution, nous reprenons
l’architecture applicative de « Monitor and trace » en mettant en évidence le rôle de chaque
technologie dans l’architecture.
Figure 5.3: Architecture Logicielle de M&T
5.4 Réalisation
Dans cette partie, nous présentons à travers un enchaînement de captures d’écran, un scénario
d’exécution donnant un aperçu général sur les fonctionnalités de notre système. La figure 5.4 montre
la page d’authentification.
63
Figure 5.4: Authentification
5.4.1 Page d’accueil
En choisissant le menu « Home» de notre application, le superviseur peut suivre l’état de système à
savoir les informations sur le système d’exploitation, la mémoire ainsi l’état de CPU. La figure 5.5
présente la page d’accueil de notre application après la phase d’authentification.
Figure 5.5: Page d’accueil
5.4.2 Module de Monitoring JVM
Supervision de la mémoire
Le superviseur peut suivre l’état de la mémoire tas et hors-tas de la JVM en temps réel, étant donné
que cet indicateur est lié à l’allocation dynamique de la mémoire de l’application qui est en cours
d’exécution au JVM.
64
Figure 5.6: Supervision de la mémoire de la JVM
Supervision des threads

Le superviseur peut suivre les threads actifs dans le JVM et peut à savoir leurs détails nom, id,
statut (bloqué, encours d’exécution, en attente)et leur pile d’exécution. La figure 5.7 présente la
page de supervision des threads.
Figure 5.7: Supervision des threads
Supervision de la VM
Le superviseur peut consulter la machine virtuelle et ses détails tel que son nom, les arguments
passés en paramètre, le "class boot" ainsi que le "class path" comme le montre la figure 5.8.
65
Figure 5.8: Supervision de la VM
5.4.3 Module de Monitoring JBoss
Supervision de la mémoire
Le superviseur peut suivre l’état de la mémoire tas et hors-tas du serveur d’application JBoss en
temps réel. La figure 5.9 présente la page de supervision de la mémoire.
Figure 5.9: Supervision de la mémoire de JBoss
5.4.4 Module de Monitoring Oracle
Connecxion à la base de données

Le superviseur doit se connecter à la base de données en tant que "sysdba" pour pouvoir superviser
les sessions ainsi que le taux de la mémoire utilisée. La figure V-10 montre la page d’authentification
66
en cas du succes. 5.10 présente la page de supervision de la mémoire.
Figure 5.10: Supervision des sessions
Connection à la base de données

En cliquant sur le menu «Sessions» de notre solution, le superviseur peut consulter les statistiques
des sessions ainsi que celle qui décrivent l’état de l’SGBD Oracle à savoir la mémoire SGA et
PGA, l’utilisation du cpu et du pourcentage du hit ratio (Rapport, pour un cache donné, entre les
cache-miss et cache-hit). La figure 5.11 montre la page de monitoring d’Oracle de notre système.
Figure 5.11: Supervision des sessions
Advanced Monitoring
En cliquant sur le menu «AdvancedMonitoring» de notre outil comme le montre la figure 5.12 ,
le superviseur doit se connecter en tant que "sysdba" s’il n’est pas encore connecté, sinon il peut
donner ou enlever les privilèges de l’utilisateur "User".
67
Figure 5.12: "Advanced Monitoring 1"
Il peut aussi exécuter les requêtes de monitoring depuis l’utilisateur "User" apres la phase de
connecxion à ce dernier. La figure 5.13 illustre cette page.
Figure 5.13: "Advanced Monitoring 2"
l’exécution d’une des requêtes de monitoring affiche le résultat comme l’illustre la figure 5.14.
Figure 5.14: Résultat d’une requête de monitoring
68
Configuration
La figure 5.15 montre la page de configuration du module Oracle. Le superviseur peut ajouter une
requête, la supprimer ou bien la consulter.
Figure 5.15: Configuration du module Oracle
Lorsque le superviseur choisit d’ajouter une requête, un pop-up sera apparu pour ajouter l’id, le
nom, la description, l’utilisateur ainsi que le script de la requête. La figure 5.16 illustre le processus
d’ajout d’une requête.
Figure 5.16: Ajout d’une requête de monitoring
Apres l’appui sur le bouton « submit » lors de l’ajout d’une requête, cette dernière est ajoutée au
tableau spécifique.
69
Figure 5.17: Résultat de l’ajout de la requête de monitoring
5.4.5 Module Code tracer
La figure 5.18 illustre la page de traçage du code après le lancement de l’application cible à tracer
et après la configuration des packages à instrumenter.
Figure 5.18: Traçage du code
5.5 Tests de la solution
Afin de réaliser nos tests, nous avons choisi de faire deux types de tests à savoir le test unitaire et le
test de performance.
70
5.5.1 Test unitaire
Concernant les tests unitaires, il existe plusieurs solutions pour réaliser ces tests, nous avons opté
pour JUnit.
JUnit désigne un Framework de rédaction et d’exécution de tests unitaires. Son but principal est
d’offrir au développeur un environnement de développement simple, le plus familier possible, et ne
nécessitant qu’un travail minimal pour rédiger de nouveaux tests. L’idée principale de JUnit est de
représenter chaque test par un objet à part. Un test correspond souvent à une classe du programme.
Avant d’exécuter les méthodes et les fonctionnalités effectuées dans les différents modules de notre
application, un test unitaire est effectué pour chaqu’un d’entre eux.[28]
Nous présentons par la figure 5.19 la classe de test « TracerTest » qui s’occupe de tester les méthodes
du module de «Traçage du code». Cette approche a été appliquée à tous les autres modules.
Figure 5.19: Test de traçage du code
5.5.2 Test de performance
Jprofiler est un outil de profilage Java sous licence commerciale. Il vise les applications Java
Enterprise Edition et Java SE. Nous avons opté le Jprofiler pour effectuer notre test de performance.
Etapes Afin de pouvoir connecter le Jprofiler à notre application, nous avons installer le Jprofiler et
le configurer en entrant l’url de notre solution comme le montre la figure 5.20
71
Figure 5.20: Configuration Jprofiler
La figure 5.21 montre le taux total de la mémoire tas, son taux d’utilisation ainsi que l’espace libre
qu’elle comporte. Dans notre cas,notre application consomme presque la moitié de la taille totale de
la mémoire tas.
Figure 5.21: Performance du "Memoy pool"
72
La figure 5.22 illustre la valeur du chagement du CPU au cours de l’exécution de notre application,
qui restera nulle apres une minute et quarante secondes du lanncement de cette dernière.
Figure 5.22: Performance du CPU
La figure 5.23 illustre la valeur du chagement des classes java de notre application dans le JVM.
Figure 5.23: Performance des classes
La figure 5.24 illustre la performance du "Garbage Collector" GC qui etait dans les normes.
73
Figure 5.24: Performance du "GC activity"
La figure 5.20 illustre la performance des threads utilisés dans notre application à savoir les threads
bloquées, en cours d’exécution et en attente.
Figure 5.25: Performance des threads
Conclusion
Dans ce chapitre, nous nous sommes intéressés à la réalisation des fonctionnalités de notre solution.
Nous avons décelés cette réalisation à travers un ensemble d’interfaces accompagnées de description et
interprétation. Ainsi qu’un ensemble de tests unitaires sur les différents modules de notre Framework
de traçage et monitoring. Nous clôturons notre travail par une conclusion qui résume notre travail
et avise ses futures perspectives.
74
Conclusion générale
La supervision est un des moyens indispensables pour favoriser la croissance de rendement d’une
entreprise. En effet il n’est pas envisageable d’avoir une plateforme de production sans avoir une
image de l’état de santé de celle-ci. Il faut une console de supervision qui regroupe et synthétise
toutes les informations relatives au système et réalise le traçage du code afin de prévenir et anticiper
les pannes.
C’est dans ce cadre que s’inscrit ce projet de fin d’études au sein de la société Vermeg. Il consiste
à concevoir et implémenter un outil de supervision qui permet de monitorer la JVM, le serveur
d’application Jboss, le serveur de base de données Oracle, ainsi que tracer le code d’un programme
au moment de son exécution sans modification de son code source. Nous avons décomposé cet outil
en quatre modules : un module de supervision de la JVM, un module de supervision du serveur
d’application Jboss, un module de supervision du serveur de base données Oracle et un module de
traçage de code.
Pour atteindre cet objectif, nous avons commencé par l’étude préalable qui a permis de décrire et
de comprendre les principaux concepts autour desquels tourne notre projet ainsi que les différents
choix technologiques adoptés. Puis nous avons effectuer l’analyse des besoins. Ensuite, nous avons
entammé la phase d’architecture et conception du système tout en commençant par l’architecture
adoptée, pour aboutir par la suite à la conception, qui met l’accent sur l’aspect, dynamique et
statique du système. Enfin, nous avons abordé l’étape de réalisation au cours de laquelle nous avons
traduit notre modélisation conceptuelle en une implémentation physique moyennant les différentes
technologies et techniques aussi bien choisies que celles exigées par l’entreprise.
Ce projet nous a permis de renforcer nos connaissances liées aux technologies de web en utilisant
les différentes plateformes de developpement tel que Spring boot et angularJs. En plus, il nous a
permis de nous intégrer dans le monde professionnel et de mettre en pratique les connaissances
théoriques acquises tout au long de notre cursus universitaire en utilisant différentes technologies..
Néanmoins, nous tenons à présent à souligner quelques extensions intéressantes de notre Projet.
75
Conclusion générale
Grâce à son caractère extensible et sa modularité, notre outil pourra être amélioré en ajoutant un
autre module de supervision du serveur d’application tel que le WebSphere.Nous pouvons aussi
ajouter un module de notification qui assure l’envoie d’un message d’alerte au client lors d’un
dépassement des seuils. Ainsi réaliser une application mobile offrant au client une autre vue de
supervision.
76
Bibliographie
[1] Vermeg. Présentation de Vermeg. [consulté le 10 Mai 2016]. 2016. url : http://www.vermeg.
com.
[2] Soliam : Wealth and institutional asset management software. [consulté le 25 Mai 2016]. url :
http://www.bsb.com/bsb-solutions/soliam.
[3] Lothon Florent. Guide de démarrage Scrum. [consulté le 20 Mai 2016 ]. 2013. url : http:
//www.agiliste.fr/guide-de-demarrage-scrum/.
[4] MÉTHODES AGILES : SCRUM. [consulté le 19 Mai 2016]. url : http://www.groupeafg.

com/methodes-agiles-scrum/.
[5] scrumguides. Scrum. [consulté le 24 Mai 2016]. url : https : / / fr . scrumguides . org /
Scrum_(m%C3%A9thode.
[6] Nagios. [consulté le 13 Mai 2016]. url : http://wiki.monitoring-fr.org/nagios/start.
[7] Axel Schmidt. A Xen Virtual Machine Monitor Plugin for Nagios. [consulté le 21 Avril 2016].
2007. url : https://www.novell.com/coolsolutions/feature/19490.html.
[8] Jean-François PILLOU. Introduction au SGBD Oracle. [consulté le 11 Avril 2016 ]. 2016.
url : http://www.commentcamarche.net/contents/702-oracle-introduction-au-sgbd-
oracle.
[9] Centreon. Pourquoi choisir Centreon. [consulté le 27 Mai 2016]. url : https : / / www .
centreon.com/fr/Centreon.
[10] Nagios. [consulté le 23 Avril 2016]. url : https : / / namur - jordan . shost . ca / nagios -
centreon-fan/.
[11] Administration des ressources avec JMX. [consulté le 10 Mai 2016 ]. url : http://skebir.
developpez.com/tutoriels/java/jmx/.
[12] Java Bytecode Instrumentation : An Introduction. [consulté le 15 Mai 2016]. 2015. url : http:
//www.correlsense.com/java-bytecode-instrumentation-an-introduction/.
[13] Erwan Alliaume. JAVA AGENT – INSTRUMENTEZ VOS CLASSES. [consulté le 27 Mai
2016]. url : http : / / blog . xebia . fr / 2008 / 05 / 02 / java - agent - instrumentez - vos -
classes/.
77
Bibliographie
[14] tutorialspoint. ASM. [consulté le 27 Mai 2016 ]. url : https://fr.tutorialspoint.org/

ASM_(logiciel).
[15] Tarak Chaari. Méthodes de conception de SI. [consulté le 30 Avril 2016 ]. url : http://www.
redcad.org/members/tarak.chaari/cours/cours_MCSI.pdf.
[16] StarUML. [consulté le 25 Mai 2016]. 2005. url : http://staruml.sourceforge.net/v1/.
[17] eclipse. [consulté le 10 Avril 2016 ]. 2016. url : https://eclipse.org/ide/.
[18] Alexandre BOLE. Le serveur JBoss. [consulté le 21 Avril 2016]. url : http://www-igm.univ-
mlv.fr/~dr/XPOSE2003/alexandrebole/jboss_1.html.
[19] Buildbot Team Members. Buildbot 0.8.12 documentation. [consulté le 25 Mai 2016]. 2012.
url : http://docs.buildbot.net/current/.
[20] Html5 introduction. [consulté le 25 Mai 2016]. 2015.
[21] Eric A. Meyer et Bert Bos. Introduction to css3. [consulté le 25 Mai 2016]. 2001.
[22] Learn the fundamentals of javascript, the programming language of theweb. [consulté le 25 Mai
2016]. 2002. url : http://www.codecademy.com/en/tracks/javascript.
[23] A quoi sert le Bootstrap de Twitter. [consulté le 15 Avril 2016].
[24] Dan Woods. A la découverte des Micro-frameworks :Spring Boot. [consulté le 25 Avril 2016].
2014. url : https://www.infoq.com/fr/articles/microframeworks1-spring-boot.
[25] Web amp ; Tech Développeur AngularJS : le framework JavaScript de Google au crible. [consulté
le 30 Avril 2016]. url : http://www.sandhconsulting.com/index.php/actualites/113-
angularjs.
[26] Karim Litim. Gestion des versions dans maven : Snapshot. [consulté le 28 Avril 2016].
[27] Apache log4j api 2.3 api. [consulté le 27 Avril 2016]. url : https://logging.apache.org/
log4j/2.x/.
[28] Romain Guy. Conception de tests unitaires avec JUnit. [consulté le 14 Avril 2016]. 2006. url :
http://gfx.developpez.com/tutoriel/java/junit/.
78
PÌl
\¤ Ayrb TFdn¡ ¨ x¤Cd t ¤rK CAV ¨ znm m` r§rqt @¡ |r`§
ybWt A , JVM d}C y m§ ybW @yfn w¡ ¢n ¨sy¶r dh .Awl`m
Y hs§ ybWt @¡ .¢lyK ¤ ¨ r ybW ºAft ¤ Oracle AAyb dA A ,JBoss
Ar TrJ ¨rbm ºAW± Tylm ryb d
r ybW ºAft , Oracle , JBoss, JVM ,d}C : yAf Aml
Résumé
Ce présent rapport fait état du travail effectué dans le cadre de projet de fin d’étude
du cycle d’ingénierie en Génie Logiciel et Systèmes d’Informations. Cette application
a pour finalité de faciliter le processus de résolution des bugs pour les développeurs
de la société Vermeg
Son objectif principal consiste à implémenter une solution combinant à la fois le
monitoring de la JVM, du serveur d’application JBOSS, de serveur de base de
données Oracle, et le traçage d’une application tierce lors de son exécution.
Mots clés : Monitoring, JVM, JBOSS, Oracle, Traçage de code.
Abstract
This report outlines the work done as part of the final project of engineering degree
in Software Engineering and Information Systems. This application aims to facili-
tate the bug resolution process for developers of Vermeg company.
Its main purpose is to implement a solution that combines the monitoring of the
JVM, the JBOSS application server, the Oracle database server, and tracing of
third-party application execution at its runtime.
This application greatly facilitate the bug resolution process for developers of Ver-
meg company.
Keywords : Monitoring, JVM, JBOSS, Oracle, code tracing.
Vous pouvez ajouter l’intitulé de l’entreprise ici.
isi@isim.rnu.tn : ¨¤rtk¯ d§rb 71 706 698 :HAf 71 706 164 :Ah TA§C 2080 ¨¤CAb A§r w h 2
2 Abou Raihane Bayrouni 2080 l’Ariana Tél: 71 706 164 Fax: 71 706 698 Email: isi@isim.rnu.tn
Bibliographie
80

Rapport PFE Emna GHRIB Et Wissem DRISSI

Transféré par

Informations du document

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Rapport PFE Emna GHRIB Et Wissem DRISSI

Transféré par

Droits d'auteur :

Formats disponibles

Diplôme National d’Ingénieur en Sciences Appliquées et Technologiques

Ministère de l’Enseignement Supérieur

Université de Tunis El Manar

Institut Supérieur d’Informatique d’El Manar

Rapport de Projet de Fin d’Études

Présenté en vue de l’obtention du

Diplôme National d’Ingénieur en Sciences Appliquées et Technologiques

Emna GHRIB Wissem DRISSI

« Monitor and trace »

Encadrants professionnels : M. Mosab HSIS

Encadrant académique : Dr. Ines GAM

Réalisé au sein de Vermeg

Année Universitaire 2015 - 2016

Ministère de l’Enseignement Supérieur

Université de Tunis El Manar

Institut Supérieur d’Informatique d’El Manar

Rapport de Projet de Fin d’Études

Présenté en vue de l’obtention du

Diplôme National d’Ingénieur en Sciences Appliquées et Technologiques

Emna GHRIB Wissem DRISSI

« Monitor and trace »

Encadrants professionnels : M. Mosab HSIS

Encadrant académique : Dr. Ines GAM

Réalisé au sein de Vermeg

Année Universitaire 2015 - 2016

Encadrant académique, Dr. Ines GAM

A ma soeur et mon frère

Je vous ai toujours trouvé proches de moi pour m’écouter, me soutenir et me conseiller.

La vie n’est qu’un éclaire,

A mes chers frères et soeurs,

A tous mes amis ,

Nos vifs remerciements s’adressent tout d’abord, particulièrement, à Monsieur Mosab

3 Analyse des besoins 18

4 Architecture et conception du système 36

1.1 Clients de Vermeg autour du monde . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

2.1 Interface du logiciel Nagios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

3.1 Diagramme de cas d’utilisation global . . . . . . . . . . . . . . . . . . . . . . . . . . 22

4.1 Architecture opérationnelle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37

4.10 Diagramme de séquence pour la supervision de la mémoire du JVM . . . . . . . . . . 51

5.1 Outils utilisés . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60

1.1 Gestion du projet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

2.1 Tableau comparatif de Nagios et Centreon . . . . . . . . . . . . . . . . . . . . . . . . 14

3.1 Description textuelle du cas d’utilisation «Monitoring JVM» . . . . . . . . . . . . . . 25

5.1 Frameworks et outils utilisés . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62

— BCI = Byte Code Instrumentation

— JMX = Java Management Extensions

— JVM = JavaVirtuelle Machine

— M&T = Monitorand Trace

dynamique de la solution proposée. Ensuite, le cinquième chapitre intitulé « Réalisation et Test de la

1.1 Organisme d’accueil

Figure 1.1: Clients de Vermeg autour du monde

1.2 Département d’accueil

• Marketing et Sales : département responsable du marketing, de la gestion des ventes et de la

• Recherche et Développement : le département qui gère le développement et effectue les tests

• Support : département responsable du support IT, de l’assistance à l’installation et l’utilisation

Figure 1.2: Organigramme de Vermeg

Figure 1.3: Organigramme du departement "Asset Management"

1.3 Présentation du projet

1.3.1 Situation de départ et problématique

Figure 1.4: Schéma récapitulatif de la gestion des erreurs

1.3.2 Objectifs et contribution

Vermeg a en conséquence identifié le besoin de concevoir et développer un outil de monitoring

Figure 1.5: Vue d’ensemble de l’application