1
MEMOIRE
DE STAGE DE FIN D’ETUDES
Pour l’obtention du
«Mastère professionnel en Nouvelles Technologies des Télécommunications et Réseaux (N2TR)»
Présenté par :
Akrem HAMMAMI
Titre
Orchestration et Virtualisation de réseau de la Caisse Nationale d’Assurance Maladie
Soutenu le : 12 / 07 / 2018
Devant le jury : Présidente : Mme. BOUSNINA Ines
Encadreur : Mr.BEN BRAIEK Ezzedine (UVT) Mr. BEN GAIED Mohsen (CNAM) Rapporteuse : Mme. AMMARI Imen
Année Universitaire : 2017 / 2018
2
Résumé
Dans le cadre de mon projet de fin d’études à l’Université Virtuelle de Tunis (UVT) et en vue de l’obtention du titre de Mastère en Nouvelles Technologies des Télécommunications et Réseaux, j’ai effectué un stage de quatre mois à la CNAM.
Durant mon séjour dans ladite société, j’avais pour mission de concevoir et de réaliser une application d'orchestration et de virtualisation des équipements réseaux en suivant des étapes qui commencent par l’étude de l’existant ensuite l’étape de la conception jusqu'à l’étape de la réalisation.
« As part of my graduation project at the Tunisian Virtual University (UVT) and in order to obtain the title of Master in New Technologies of Telecommunications and Networks, I did a four-month internship at the CNAM.
During my stay in this company, my mission was to design and implement an application of orchestration and virtualization of network equipment by following steps that begin with the study of the existing then the design stage up to 'at the stage of the realization. »
3
Dédicace
A ma Chère Mère Latifa A mon Père Lotfi A ma Femme Meriem A mon fils Mohamed Amine
A ma nouvelle née Nour
Dont le mérite, les sacrifices et les qualités humaines m’ont permis de vivre ce jour.
A mon Frère et mes sœurs Haithem, Anissa, Oumaima A tous les gens qui m'aiment...
(Akrem Hammami)
4
Remerciements
Au terme de ce projet de fin d’études, j’adresse mes sincères remerciements à Monsieur Ezzedine Ben Braiek, mon encadreur de l’UVT pour son encadrement.
Je tiens à remercier également Monsieur Mohsen Ben Gaied, chef de service à la Caisse Nationale d’Assurance Maladie, pour m’avoir proposé ce projet, pour son suivi et ses remarques qui m’ont permis de mener à bien ce travail.
Mes remerciements s’adressent également à l’administration et aux professeurs de l’UVT pour les moyens qu’ils ont mis à notre disposition afin d’élaborer ce travail.
Je souhaite exprimer enfin ma gratitude et mes vifs remerciements à ma famille et mes amis pour leurs soutiens.
Pour finir, je remercie les membres du jury qui ont accepté d’évaluer mon projet. Je leurs présentons toute mes gratitudes et mes profonds respects.
5
Table des matières
Introduction Générale ...7
Chapitre I : Présentation générale ... 10
I.1. Présentation de l’organisme d’accueil ... 10
I.2. Contexte ... 12
I.3. Problématique ... 13
I.4. Travail à réaliser ... 13
I.5. Méthodologie de conception ... 14
I.6. Langage de conception... 14
I.7. Conclusion ... 15
Chapitre II – Etude préalable et spécification des besoins ... 17
II.1. Etude préalable ... 17
II.2. Spécification des besoins ... 22
II.3. Conclusion ... 27
Chapitre III – Conception ... 29
III.1. Conception architecturale ... 29
III.2. Conception détaillée ... 31
III.3. Conclusion ... 38
Chapitre IV – Réalisation ... 40
IV.1. Environnement matériel ... 40
IV.2. Environnement logiciel ... 40
IV.3. Outils de développement ... 41
IV.4. Interfaces de l’application ... 43
IV.5. Conclusion ... 52
Conclusion Générale ... 53
Netographie ... 54
6
Liste des figures
Figure I.1 : Organigramme de la CNAM...11
Figure I.2 : Structure de la direction Systèmes, Réseaux et Maintenances Informatiques...12
Figure I.3 : Modèle en Cascade...14
Figure II.1 : Architecture de réseau de la CNAM...19
Figure II.2 : Diagramme de cas d’utilisation généralisé...24
Figure II.3 : Diagramme de cas d’utilisation de gestion des utilisateurs...25
Figure II.4 : Diagramme de cas d’utilisation de gestion des préférences...25
Figure II.5 : Diagramme de cas d’utilisation de gestion des produits...26
Figure II.6 : Diagramme de cas d’utilisation de configuration et d'administration...26
Figure III.1 : Architecture 2 tiers (Client-serveur)...29
Figure III.2 : Schéma de l'architecture MVC...30
Figure III.3 : Diagramme de déploiement...31
Figure III.4 : Diagramme de paquetage...32
Figure III.5 : Diagramme de classe de la couche Model...32
Figure III.6 : Modèle relationnel de la Base de Données...34
Figure III.7 : Diagramme de séquence de processus d’authentification...36
Figure III.8 : Diagramme de séquence de processus d'ajout d'un utilisateur...36
Figure III.9 : Diagramme de séquence de processus de modification d'un équipement...37
Figure III.10 : Diagramme de séquence de processus de supervision...38
Figure IV.1 : Interface d’authentification...43
Figure IV.2 : Interface d'accueil de l'administrateur...44
Figure IV.3 : Interface de gestion des utilisateurs...44
Figure IV.4 : Interface d’ajout d’un utilisateur...45
Figure IV.5 : Interface d’accueil de modification d’un utilisateur...46
Figure IV.6 : Interface de suppression d’un utilisateur...46
Figure IV.7 : Interface de liste des utilisateurs...47
Figure IV.8 : Interface de gestion des préférences...48
Figure IV.9 : Interface de gestion des centres...49
Figure IV.10 : Interface d’ajout d’un équipement...49
Figure IV.11 : Interface de création d'une affectation...50
Figure IV.12 : Interface d'administration et de configuration...51
Figure IV.13 : Interface de cartographie...52
7
Introduction Générale
Le système d’information et les réseaux sont aujourd’hui un élément critique de la compétitivité de l’entreprise. De mauvaises performances de ceux-ci se déclinent en pertes de productivité et les indisponibilités de service se traduisent en pertes de vente, irrégularités d’exploitation ou interruption de la production. La qualité du service global rendu aux utilisateurs doit être garantie, ce qui implique la maîtrise d’un ensemble complexe de systèmes, réseaux, middleware et applications. On compte sur les services offerts par les réseaux pour transactions bancaire, les recherches web, la téléconférence, etc. Ces services sont de ce fait devenus indispensable. Pour s'assurer que les services rendus par les réseaux soient convenable, il est nécessaire de surveiller et d'agir quand une erreur se produit. Pour ce faire, il faut obtenir les données de gestion des équipements des réseaux et, si nécessaire, contrôler ces équipements d'où l'utilité de recourir aux outils d'orchestration et d'administration des réseaux.
Ce projet a été réalisé dans le cadre de la mise en place d'un outil d'administration réseau de la Caisse Nationale d’Assurance Maladie. Il consiste à concevoir et mise en place un système d’orchestration réseaux qui permet à la fois de collecter des données sur les routeurs, les firewalls et les commutateurs, afficher l'état de chaque équipement et l'accéder.
Et afin de faciliter l'administration et le contrôle de tout les équipements réseaux de la CNAM développés sur tout le territoire Tunisien, il m’a été confié de concevoir et de développer une application d'orchestration et de virtualisation de réseau de la CNAM. En faite, avec cette application, le réseau peut être provisionné de manière orchestrée. Elle offre un concept fondamental qui sert à automatiser les réseaux définis. L'automatisation permet de provisionner des services réseaux rapides et à grande échelle, en réduisant le risque d'erreur humaine.
8
Pour cela, et après avoir effectué des recherches et grâce à des informations collectées, nous avons élaboré notre vision de l’application, son architecture, ainsi que les outils et les technologies utiles. Dans ce cadre, notre travail est établi sur quatre chapitres principaux dont on parle: Le premier chapitre est une présentation générale de ce projet, le deuxième est une étude des besoins de la solution adoptée et identification des acteurs ainsi que leurs cas d’utilisation. Le troisième chapitre est la conception détaillée où nous allons adopter une architecture logicielle, modéliser les différentes entités de notre application par les diagrammes de classes, étudier les différents scénarios et mettre en place notre application d'orchestration réseau tout en modélisant différents composants et leurs fonctionnements.
Dans le dernier chapitre, nous présenterons l’environnement de développement qui aide à réaliser notre projet.
9
Chapitre I
Présentation générale
10
Chapitre I : Présentation générale
Ce chapitre comportera une brève présentation de l’organisme qui a accepté de m’accueillir et m’a donné la chance de réaliser mon projet de fin d’études, citant son origine, ses objectifs, son organisation, sa structure et quelque notion de sujet.
I.1. Présentation de l’organisme d’accueil
Crée sous la forme d’un établissement public à caractère non administratif, la Caisse Nationale d’Assurance Maladie (CNAM) possède la personnalité morale autrement dit, elle est autonome et dispose d’un budget qui l’est aussi. Placée sous la tutelle du ministère des affaires sociales et de la solidarité et des Tunisiens à l’étranger, la CNAM est la troisième caisse sociale aux coté de la CNSS et de la CNRPS mais agissant dans un seul domaine, à savoir l’assurance maladie.
D’ailleurs, son personnel est issu de ces deux caisses puisque conformément à l’article 9 de la loi du 2 août 2004, les agents de la CNSS et de la CNRPS exerçants dans le domaine de l’assurance maladie sont intégrés à la CNAM.
I.1.1. Missions
La CNAM a été créée en vertu de la loi 71/2004 du 2 août 2004 ayant instituée le régime d’assurance maladie. Les missions de la CNAM portent sur :
La gestion des régimes légaux : régimes des repartions des dommages résultants des accidents de travail et des maladies professionnelles dans les secteurs public et privé.
La gestion des autres régimes légaux d’assurance maladie prévus par la législation en vigueur (couverture de la longue maladie et régime de remboursement CNRPS).
L’octroi des indemnités de maladie et de couches prévu par les régimes de sécurité sociale.
La gestion des conventions bilatérales en matière d’octroi des soins.
La gestion du «régime assurance maladie » institué par la loi 2004-71 du 2 août 2004
Comportant un régime de base et éventuellement un régime complémentaire.
11 I.1.2. Objectifs
La CNAM est organisée en structures régionales chargées de l’octroi des prestations et structures centrales chargées essentiellement du suivi de l’activité et de son évaluation. La CNAM a pour objectifs :
Une meilleure qualité des services rendus aux bénéficiaires et aux différents utilisateurs du système (délais, procédures, accueil).
La maîtrise des frais de gestion.
La maîtrise des dépenses et le maintien de l’équilibre du régime.
La gestion rationnelle du nouveau régime.
I.1.3. Organigramme de la CNAM
La figure I.1 présente l’organigramme de la caisse nationale d’assurance maladie (CNAM) :
Figure I.1 : Organigramme de la CNAM
12
I.1.4. Structure de la Direction Systèmes, Réseaux et Maintenance Informatique : La direction systèmes, réseaux et maintenances informatiques gère l'ensemble des ressources informatiques. Elle s'occupe également de l'assistance quotidienne des utilisateurs (réparation des pannes, installation des logiciels et des anti-virus, gestion du matériel informatique, administration du réseau, etc.).
La figure I.2 présente la répartition et l’organisation de la direction Systèmes, Réseaux et Maintenances Informatiques :
Figure I.2 : Structure de la direction Systèmes, Réseaux et Maintenances Informatiques I.2. Contexte
Les réseaux informatiques, sont des éléments essentiels et primordiaux des technologies actuelles des transmissions des données entre sites éloignés, leur traitement et leur restitution, touchent de plus en plus notre vie courant. La gestion des réseaux informatiques est toujours un travail pénible, laborieux, sujet aux erreurs et dont la complexité est sans cesse croissante en raison de l’évolution des technologies et du matériel qui entre en compte. D’une part, les équipements qui forment le réseau doivent se comporter comme un groupe ; cependant, chacune de ces machines est gérée et configurée individuellement.
D'autre part, l’évolution fulgurante du nombre de dispositifs, la complexité des configurations, les besoins spécifiques de chaque service, le nombre même de services qu’un réseau doit être capable de supporter, et le fait que les données traversent généralement des réseaux hétérogènes appartenant à plusieurs opérateurs, rendent cette tâche de plus en plus difficile. Nous pouvons aisément comprendre la nécessité de nouvelles approches au problème de gestion de configuration réseau.
13
C’est dans ce contexte, l'outil de l'administration réseau assure une gestion des ressources réseau de manière efficace, un accès rapide aux menu de configuration des équipements et il permet aux administrateurs réseau de surveiller les tendances, de planifier la capacité et d'optimiser les performances.
I.3. Problématique
Au terme d’une réunion entre le directeur centrale de l’informatique de la CNAM, mon encadrant et moi-même, nous avons convenu qu'il y a des difficultés de surveillance, de maintient et de gestion des réseaux informatiques. A l'heure actuelle, la Caisse Nationale d’Assurance Maladie dispose d'un important lot d'équipements réseaux (routeurs, switchers, firewalls…) qui suit le nombre de centres régionaux, locaux et des maisons des affaires sociales. Des dysfonctionnements ou de mauvaises performances de réseau peuvent occasionner une perte de productivité au sein de la CNAM. Une bonne exploitation impose la gestion d'éléments essentiels comme le coût, la qualité de service et la réactivité des systèmes.
Pour le service réseau, mission d'autant plus complexe qu'un administrateur de réseau doit souvent gérer un ensemble de systèmes hétérogènes, avec protocoles standards et technologies variés.
I.4. Travail à réaliser
Il nous revient alors de proposer une solution informatique à même de résoudre les difficultés que connaît le service informatique dans la gestion des équipements réseaux. De ce faite, l’idée générale du projet consiste à concevoir un outil applicatif qui pourra de façon concrète nous permettre de faire la gestion des routeurs, des commutateurs et des firewalls et le monitoring de tous ces équipements. Ainsi, la CNAM a exprimé un besoin pressant de mettre à niveau son système d’information et d’adopter un système efficace et ouvert afin de remédier aux problèmes d’orchestration des équipements réseaux.
Cette application va nous permettre de :
Lister et identifier tous les équipements réseaux existants dans l’architecture du système actuel de la CNAM ;
Superviser les états des équipements réseaux ;
Accéder à tous les produits répartis sur le territoire d'une même interface ;
Faciliter l’accès à chaque équipement réseau ;
Faire la configuration de chaque équipement réseau ;
14
I.5. Méthodologie de conception
Il existe différents types de cycles de développement entrant dans la réalisation d'un logiciel. Ces cycles prendront en compte toutes les étapes de la conception d'un logiciel. Le type de méthode le plus utilisé aujourd’hui dans tous les domaines qui nécessitent de concevoir avant de produire quelque chose. Pour parvenir à un produit fini, on passe par plusieurs phases du cadrage du projet jusqu’à la livraison finale. Cette méthode présente de nombreux avantages, notamment celui de sécuriser le planning du projet puisque l’on verrouille chacune des étapes les unes après les autres : on s’entend sur ce que l’on va faire (cadrage), on le conçoit dans les grandes lignes (conception générale) puis dans le détail (conception détaillée) avant de le produire (production), de le tester (tests/corrections) et de le livrer (livraison).
Elle permet également de bien s’entendre sur les attendus du projet et elle est très facile à expliciter à un groupe de travail. Enfin, bien menée, elle permet d’éviter les dérives en termes de planning : il est facile de visualiser que si une étape se décale, les suivantes sont impactées. La figure I.3 présente les différentes étapes du modèle en cascade.
Figure I.3 : Modèle en Cascade
I.6. Langage de conception
Dans le but de concevoir un système extensible, évolutif, modulaire et orienté objet, le langage UML s’est imposé comme un outil performant afin d’élaborer ce projet. En effet, ce langage permet de mener la phase de conception tout en bénéficiant de la puissance et de la simplicité de ses diagrammes. Le choix d’UML, comme outil de modélisation des flux et les différentes actions de l’application, peut être justifié par plusieurs raisons :
15
UML facilite la compréhension et la communication d’une modélisation objet,
La notation UML s'impose comme un standard de fait à l'heure actuelle sur le marché,
Il est adopté par les grands constructeurs de logiciel du marché,
L’utilisation d’UML offre l’avantage de disposer de vues de haut niveau d'abstraction,
Pour favoriser la communication entre utilisateurs, spécialistes et informaticiens.
I.7. Conclusion
L’application proposée devra donc être à mesure d’apporter une solution concrète à la prise en charge des différents problèmes d'orchestration de réseau de la CNAM. Pou cela, on va passer au chapitre suivant pour faire une étude préalable et spécifier les besoins.
16
Chapitre II
Etude préalable Et
Spécification des besoins
17
Chapitre II – Etude préalable et spécification des besoins
Ce chapitre détaille les spécifications pour la réalisation de l’application d’orchestration et de virtualisation de réseau de la CNAM. Il décrit l’ensemble des cas d’utilisations du système. En effet, le présent chapitre définira les interactions entre les utilisateurs et l’application proposée tout au long du cycle de vie des équipements réseaux.
II.1. Etude préalable
L’étude préalable du projet consiste principalement à recenser l’existant c'est-à-dire les solutions informatiques déjà mises en œuvre dans l’entreprise et à recenser les besoins notamment en termes de fonctionnalités nouvelles du logiciel. Elle peut être l’occasion d’une étude de rentabilité du projet.
II.1.1. Etude de l’existant
La Caisse Nationale d’Assurance Maladie possède un grand nombre de routeurs, de switchers et de serveurs qui sont installés au niveau du site central, des centres régionaux, des centres locaux, des maisons d’affaires sociales et des maisons de services.
L’architecture réseau de la CNAM est articulée autour de 3 couches :
La couche Core : est constituée :
D’un cluster de deux Firewalls Cisco PIX 525. Ce cluster gère le routage entre les différentes zones ainsi que les listes d’accès aux différentes ressources du système d’information.
D’un cluster de deux switchers Cisco 4503 et qui a pour rôle de fédérer les différentes connexions des switchers d’accès à la couche cœur du système d’information.
La couche Accès : est constituée de :
Un ensemble de switchers de différentes marques et modèles répartis sur les étages du bâtiment qui héberge le Data Center.
Un point d’accès Wifi, installé dans le 7ème étage du bâtiment.
18
La couche Edge : est constituée de :
Un cluster de deux Firewalls Fortigate FG200B. Ce cluster est divisé en deux domaines virtuels (VDOM) ; un VDOM pour la navigation internet et un VDOM pour le trafic inter-sites/inter-systèmes de la CNAM.
Un firewall Cisco PIX 525 pour gérer le DMZ de la CNAM où est publié un serveur Web et un serveur de messagerie.
Des équipements d’accès aux routeurs des partenaires de la CNAM comme la CNSS et la CNRPS ainsi que les réseaux de ses directions régionales. Ces équipements sont gérer par les différents fournisseurs de service comme Tunisie Télécom, Orange, Ooredoo.
Les connexions WAN qui relient la CNAM à ses différents partenaires et fournisseurs de services sont principalement :
Une connexion au réseau internet assurée par deux ADSL 8 Mbps chacune,
Une connexion MPLS composée d’une liaison fibre optique de 50 Mbps et assurant l’interconnexion des différentes directions régionales au Data Center,
Deux liaisons spécialisées de 2 Mbps chacune et assurant la connexion du DC de la CNAM à la CNSS et la CNRPS,
Une liaison ADSL de 4 Mbps et faisant office de support d’accès aux passerelles SMS de deux fournisseurs de services : Ooredoo et Orange,
Une connexion Wimax de 2 Mbps assurée par le fournisseur Orange pour la publication du site Web et le serveur de messagerie de la CNAM.
La figure II.1 illustre l’architecture LAN/WAN de la CNAM
19
Figure II.1 : Architecture de réseau de la CNAM
20 I.1.2. Critiques de l’existant
Avant de plonger dans l’étude proprement dite de la solution, il est indispensable de prendre du recul et de faire un résumé des problèmes concrets existants que rencontrent au jour le jour nos différents acteurs. Les administrateurs réseau de la Caisse Nationale d’Assurance Maladie utilisent les lignes de commandes via l’interface MS-DOS de Windows ou bien le logiciel PUTTY pour accéder aux routeurs ou switchers ou firewalls se qui entraine parfois l’oublie des mots de passe. De plus, ils ne peuvent pas supervisés tous les équipements en temps réel et en même temps et de vérifier leurs états. C’est donc dans cette optique qu’une petite enquête a été menée auprès de ces personnes et la plupart des problèmes recensés sont les suivants :
Pour un très grand nombre de routeurs, de switchers à gérer, l’administrateur est incapable de vérifier leurs disponibilité (en ligne ou pas), de déterminer la qualité des services qu’ils offrent, ni détecter la défaillance des équipements.
Le seul moyen de détecter ces anomalies ne peut se faire que par la réception des différentes plaintes et réclamations des agents de centres régionaux ou locaux distants.
Nombreux sont les problèmes que rencontre un centre lors d’une panne d’équipement causant une coupure globale au niveau du réseau. D’une part, Celle-ci contrariait les assurés en créant un retard au niveau du service au guichet, mais aussi un retard pour fixer ce problème puisqu’il fallait contacter la direction informatique afin de régler cette défaillance technique et cela prenait assez de temps. D’autre part, il existe en Tunisie plus de 65 centres CNAM qui ont besoin d’être constamment suivis mais le manque d’informaticiens ne permet pas de remplir cette tache.
II.1.3. Solutions Web existantes
Le logiciel libre est aujourd'hui aux portes des administrations qui sont maintenant confrontées à des choix. Bien que le modèle dominant soit souvent celui du logiciel propriétaire, de nombreux arguments montrent chaque jour un peu plus que les logiciels libres sont une alternative crédible.
Il existe évidemment des obstacles à l'adoption des logiciels libres dans la CNAM et parmi ces obstacles, on trouve que les meilleurs logiciels libres sont matures, mais d'autres n'ont pas encore atteint le stade de la version 1.0. Il convient donc de bien vérifier auprès de son conseiller si le produit choisi est mature et si la communauté pouvant le supporter est bien active.
21
La direction informatique de la CNAM a utilisé plusieurs logiciel libre comme le PRTG (Paessler Router Traffic Grapher) [N1] comme outil open source pour superviser le réseau mais ce dernier a présenté plusieurs contraintes, parmi ces contraintes, une partie d’administration des équipements est manquante, une documentation incomplète et parcellaire, manque de souplesse pour modifier certains comportements et la documentation recommande de modifier le code source.
De plus l'intégration d'une application open source est rarement maîtrisée, ce qui peut entraîner des coûts imprévus ou dévaluer des actifs logiciel. Ces risques découlent d'une réutilisation insouciante ou imprudente de l'open source et peuvent survenir tout au long du cycle de vie du logiciel, de l'écriture du code à la distribution du logiciel final. Ils ont pour origine les problèmes de compatibilité de licence, mais aussi d'obsolescence des composants et de vulnérabilité logicielle.
II.1.4. Solution proposée et retenu
L’administration, la gestion et la supervision des équipements réseaux distants représentent un souci important pour l’administrateur. Le système actuel de gestion du réseau au sein de la CNAM présente plusieurs contraintes. Alertée, la direction informatique de la CNAM a pris conscience de ce problème qui risque de ternir l’image de la société auprès du reste des directions et des centres régionaux et locaux. De ce fait, nous avons jugé nécessaire de mettre en place un outil pour contrôler le fonctionnement du réseau, d’étudier les données collectées et de définir des mécanismes déclenchant des alertes lors de détection des problèmes. Elle a donc décidé la mise en place d’un outil applicatif qui pourra grâce aux différentes fonctionnalités qu’il offre, faciliter la gestion et la configuration des équipements réseaux, alertés les administrateurs en cas de panne ou de coupure.
En effet, une nouvelle application en environnement graphique et utilisant une base de données fait l'objet d'une étude pour la gestion du réseau informatique de la CNAM. Réaliser une base de données ainsi qu’une interface graphique associée, qui rend transparent pour l’administrateur la gestion de la base. Cette interface devra être la plus simple et intuitive possible de façon à ne nécessiter aucun apprentissage particulier. Aussi la maintenance et la mise à jour de cette interface devra être facile dés lors qu’on possède les fichiers sources.
22
II.2. Spécification des besoins
Cette phase consiste à comprendre le contexte du système. Il s'agit de déterminer les fonctionnalités et les acteurs les plus pertinents, de préciser les risques les plus critiques et d'identifier les cas d'utilisation initiaux.
II.2.1. Besoins fonctionnels
Avant de parler du fonctionnement proprement dit du système, il est nécessaire de définir dans un premier temps les fonctionnalités qui seront implémentées au sein dudit système. Ainsi, cette étape décrira ce que nous attendons de notre application. Puis, tout ceci sera modélisé sous forme de diagramme à l’aide du langage de modélisation UML, en ce que nous appellerons par la suite cas d’utilisation. De ce fait, s’il faut redéfinir concrètement les fonctionnalités de notre système, nous pouvons tout simplement dire que notre application doit être capable de :
Gestion des utilisateurs : il s’agit d’un outil permettant d’effectuer les opérations de gestion telles que l’ajout, la modification, la suppression et le listage.
Gestion des préférences : il s’agit d’un outil permettant pour chaque utilisateur la gestion des centres, gestion des types, gestion des marques et la gestion des modèles en effectuant les opérations de l'ajout, la modification, la suppression et le listage.
Gestion des produits : il s’agit d’un outil permettant d’effectuer les opérations de gestion des équipements telles que l’ajout, la modification, la suppression et le listage et les opérations d'affectation d'un équipement.
Configuration et administration : il s'agit d'un outil permettant la visualisation des états, la configuration et l'administration des équipements qui sont déjà connectés, consulter l'historique et les statistiques.
II.2.2. Besoins non fonctionnels
Nous entendons par là les besoins qui caractérisent le système. Autrement dit, il s’agit de définir un ensemble de critères essentiels pour le bon fonctionnement de notre application.
Il est à noter cependant qu’ils peuvent être exprimés en matière de performance, de type de matériel ou le type de conception. Dans le cadre de notre travail, nous pouvons citer par exemple :
23
Ergonomie : L’interface de l’application doit être simple et utilisable afin que l’utilisateur puisse l’exploiter sans se référer à des connaissances particulières, en d’autres termes, notre application doit être lisible et facile à manipuler par n’importe quel utilisateur ;
Sécurité : L’application devra assurer la sécurité des utilisateurs. D’où la nécessité de procéder à l’authentification des agents et administrateurs tout en assurant la confidentialité de leurs données ;
Maintenabilité : C’est-à-dire qu’il doit y avoir une possibilité d’ajouter de nouvelles fonctionnalités ou de modifier celles existantes ;
Rapidité et intégrabilité dans d’autres applications : L’application devra être rapide et assure que les modules seront intégrables et utilisables dans d’autres applications ;
II.2.3. Besoins architecturaux
Pour notre application nous avons besoins d’un réseau local, intranet et d’une architecture 2 tiers/niveaux. Ce type d'architecture caractérise les environnements client- serveur où le poste client demande une ressource au serveur qui la fournit à partir de ses propres ressources. L’application d'administration et de supervision doit être accessible uniquement à partir des postes d'un réseau local, ou bien d'un ensemble de réseaux bien définis, et invisibles (ou inaccessibles) de l'extérieur.
Dans l'architecture à 2 niveaux, on a généralement une architecture partagée entre :
Un poste client : l'ordinateur demandeur de ressources, équipée d'une interface utilisateur (généralement un navigateur web) chargée de la présentation ;
Un serveur physique : sur ce serveur, il sera installé un serveur d'application et un serveur de base de données. Le serveur d’application est chargé de fournir la ressource mais faisant appel au serveur de données, qui ce dernier fournissant au serveur d'application les données dont il a besoin.
II.2.4. Diagramme de cas d’utilisation
Les diagrammes de cas d'utilisation sont des diagrammes UML utilisés pour donner une vision globale du comportement fonctionnel d'un système logiciel. Avant de modéliser nos besoins fonctionnels, nous allons préciser les différents acteurs qui vont interagir avec notre application.
24 II.2.4.a. Identification des acteurs
Au niveau de cette section, nous présentons les différents acteurs susceptibles d’utiliser cette application, mais tout d’abord, nous donnons une définition du concept acteur.
Un acteur représente l'abstraction d'un rôle joué par des entités externes (utilisateur, dispositif matériel ou autre système) qui interagissent directement avec le système étudié. La mise en marche du système nécessite essentiellement trois acteurs :
Administrateur : L’administrateur a le droit de gérer les utilisateurs, de définir les rôles et les privilèges des utilisateurs du système. De plus, il peut gérer les produits, gérer les préférences et configurer et administrer les équipements.
Utilisateur : Son rôle consiste à gérer les produits, gérer les préférences et configurer et administrer les équipements.
II.2.4.b. Diagramme de cas d’utilisation général
La figure II.2 présente le diagramme de cas d'utilisation généralisé. L’administrateur peut utiliser l'interface "gestion des utilisateurs" pour ajouter des comptes utilisateurs et gérer leurs accès à l'application. L'administrateur ainsi que l'utilisateur, après l'authentification, peuvent gérer les mêmes interfaces tels que l'interface de gestion des préférences, l'interface de gestion des produits et l'interface de configuration et d'administration.
Figure II.2 : Diagramme de cas d’utilisation généralisé
25
Le diagramme de cas d'utilisation de gestion des utilisateurs représenté par la figure II.3 nous définit certaines fonctionnalités de l'administrateur comme l'ajout d'un utilisateur, modification des utilisateurs, suppression des utilisateurs et le listage des utilisateurs.
Figure II.3 : Diagramme de cas d’utilisation de gestion des utilisateurs
La figure II.4 nous illustre le diagramme de cas d'utilisation de gestion des préférences. Cette interface nous permet de gérer les centres, gérer les modèles, gérer les marques et gérer les types.
Figure II.4 : Diagramme de cas d’utilisation de gestion des préférences
26
Le diagramme de cas d'utilisation de gestion des produits représenté par la figure II.5 englobe la gestion des équipements qui se présente par l'ajout, la modification, la suppression et le listage des produits et la gestion des affectation qui se présente par la création, la modification, la suppression des équipements et le listage des équipements affectés et des équipements non affectés.
Figure II.5 : Diagramme de cas d’utilisation de gestion des produits
La figure II.6 nous illustre le diagramme de cas d'utilisation de configuration et administration. L'utilisateur peut configurer et administrer tous les produits. Cette interface de configuration et administration englobe plusieurs fonctionnalités comme l'affichage des équipements avec leurs états, consulter l'historique, la recherche et les statistiques.
Figure II.6 : Diagramme de cas d’utilisation de configuration et d'administration
27
II.3. Conclusion
Ce chapitre présente une phase indispensable pour l’étude et l’analyse de notre application. Nous avons défini les différents besoins fonctionnels, non fonctionnels et architecturaux, nous avons présenté le diagramme de cas d’utilisation général.
Nous entamerons dans le chapitre suivant la conception de cette application qui comporte diagramme de paquetage, diagramme de séquence et diagramme de classe.
28
Chapitre III
Conception
29
Chapitre III – Conception
L’étape de conception définit généralement les structures et les modèles à suivre lors de la phase d’implémentation de l’application. C’est la phase où nous préparons l’architecture logicielle de l’application, et où nous définissons la structure de l’application.
III.1. Conception architecturale
La structuration du système peut être vue sous différents angles, selon que l’on considère :
le découpage « logique » hors de tout contexte d’exécution (machines, OS et réseaux)
le découpage « physique » (prenant en compte le contexte d’exécution)
III.1.1. Architecture physique
Dans le domaine informatique, l'architecture physique (également nommée architecture technique) décrit l'ensemble des composants matériels supportant l'application.
Pour notre application, on va choisir un environnement client/serveur, cela signifie que des machines clientes (des machines faisant partie du réseau) contactent un serveur, une machine généralement très puissante en termes de capacités d'entrée-sortie, qui leur fournit des services. Ces services sont des programmes fournissant des données telles que l'heure, des fichiers, une connexion, etc. La Figure III.1 montre l’architecture technique générale et le contexte de déploiement de l’application.
Figure III.1 : Architecture 2 tiers (Client-serveur)
30
Cette architecture est basée sur deux composants essentiels :
Le Client : C’est une machine (faisant partie du réseau), communiquant avec le serveur pour la récupération d’un service donné.
Le Serveur d’application : Ce serveur est chargé de fournir la ressource mais en faisant appel au serveur de données.
Le serveur d’application et la logique applicative (l’ensemble des traitements nécessaires pour répondre aux besoins des utilisateurs) se trouvent sur une même machine.
III.1.2. Architecture logique
Notre application se base sur l’architecture MVC (Modèle / Vue / Contrôleur).
L'architecture MVC est une façon d'organiser une interface graphique d'un programme. Elle consiste à distinguer trois entités distinctes qui sont, le modèle, la vue et le contrôleur présentés dans la figure III.2 ayant chacun un rôle précis dans l'interface. L'organisation globale d'une interface graphique est souvent délicate. Bien que la façon MVC d'organiser une interface ne soit pas la solution miracle, elle fournit souvent une première approche qui peut ensuite être adaptée. Elle offre aussi un cadre pour structurer une application. Dans l'architecture MVC, les rôles des trois entités sont les suivants :
Modèle : données (accès et mise à jour)
Vue : interface utilisateur (entrées et sorties)
Contrôleur : gestion des événements et synchronisation
Figure III.2 : Schéma de l'architecture MVC
31 III.1.3. Diagramme de déploiement
Le diagramme de déploiement représenté dans la figure III.3 décrit la disposition physique des ressources matérielles qui composent le système et montre la répartition des composants sur ces matériels.
Figure III.3 : Diagramme de déploiement
III.2. Conception détaillée
La conception détaillée fournit la structure interne des composants logiciels utilisés dans le module d’analyse structurelle.
III.2.1. Conception de l’aspect statique
Après l’élection des besoins exprimés sous la forme de fonctionnalités modélisées comme des cas d’utilisation et sous la forme de scénarios modélisés dans des diagrammes d’activité, nous pouvons modéliser la structure logique du système, c’est-à-dire les aspects statiques du système.
Cette modélisation est en grande partie effectuée dans un diagramme de classes, avec éventuellement un diagramme de paquetage montrant des configurations spécifiques du système dans des conditions particulières.
III.2.1.a. Diagramme de paquetage
Le diagramme paquetage présenté dans la figure III.4 fournit une description détaillée l’interaction des packages existants dans notre projet entre eux ainsi il nous aide à mieux comprendre le mécanisme de fonctionnement de notre application.
32
Figure III.4 : Diagramme de paquetage
III.2.1.b. Diagramme de classe
Le diagramme de classe est considéré comme le plus important de la modélisation orientée objet, il est le seul obligatoire lors d’une telle modélisation. Le diagramme de classes du package model de la figure III.5 montre la structure interne du système.
Figure III.5 : Diagramme de classe de la couche Model
33 III.2.1.c. Conception de la Base de données
A partir du diagramme de classe de la package model, nous avons conçu une base de données relationnelle, il est important de clairement définir toutes les tables qui la composent :
Table utilisateur (matricule, prenom, nom, tel, email, password, id_profil)
Table profil (id_profil, lib_profil)
Table centre (code_centre, lib_centre, tel_centre, adresse_centre, lat, lng)
Table equipement (num_serie, designation, statut, adresse_ip, id_marque, id_type, code_centre)
Table type (id_type, lib_type)
Table marque (id_marque, lib_marque)
Table modele (id_modele, lib_modele, id_marque)
Table gerer (matricule, num_serie, date_debut, date_fin)
Table affecter (num_serie, code_centre, date_debut_affec, date_fin_affec ,adress_ip)
La figure III.6 présente la relation entre les tables de notre base de données, en faite la mise en relation de tables permet de relier les données d’une table à celles d’une autre table et ainsi d’établir une base de données de type relationnelle. Les relations entre des tables permettent d’utiliser les données d’une table dans une autre et d’éviter ainsi la saisie redondante d’informations.
34
Figure III.6 : Modèle relationnel de la Base de Données
III.2.2. Conception de l’aspect dynamique
La modélisation des aspects dynamiques de l’analyse consiste en la connaissance des messages échangés entre les objets, de l’ordre de ces interactions, ainsi que des changements d’états significatifs des objets.
III.2.2.a. Les règles de gestion
Pour obtenir un résultat dans un traitement, il est souvent nécessaire d'inclure des règles de gestion dans le modèle conceptuel. A partir de ces règles de gestion, une réflexion doit être réalisée quant aux règles d'organisation de la base de données à construire. Pour notre application voici quelques règles de gestion qui vont être définis :
Règle 1: Si au moins un des champs de l'interface d'authentification ne sont pas remplis alors le message et même dans tous les champs de saisie de l'application, le message "Vous avez oublié de remplir un champ" va être affiché.
Règle 2: Si un matricule ou un mot de passe n'est pas valide dans l'interface de l'authentification alors un message "Mauvais matricule / mot de passe. Merci de recommencer" va être affiché.
Règle 3: Si dans l'interface "ajout d'un utilisateur" on saisie un matricule n'est pas numérique alors un message "Merci de vérifier le matricule" va être affiché.
35
Règle 4: Si dans l'interface "ajout d'un utilisateur" on saisie une adresse email n'a pas la forme d'un email alors un message "Vous devez entrer une adresse de messagerie valide"
va être affiché.
Règle 5: Si dans l'interface "ajouter un équipement" on ajout un numéro de série qui déjà existe alors un message "Numéro de série déjà existant" va être affiché.
Règle 6: Si dans l'interface "créer une affectation" on saisie une adresse IP n'a pas la forme d'une adresse IP alors un message "Veuillez modifier la valeur pour correspondre au format demandé" va être affiché.
Règle 7: Si dans l'interface "statistique" on introduit une période qui n'est pas valable ou des données non valables alors un message d'erreur s'affichera.
III.2.2.b. Diagramme de séquence
Un diagramme de séquence est un document graphique qui montre pour des scénarios de cas d'utilisation précis, les événements générés et les interactions entre objets en se basant sur des messages ordonnés. Chaque message transitant sur un lien est symbolisé par une flèche porteuse d'une expression. La lecture se fait de haut en bas, et l'ordre chronologique doit respecter ce sens. La réalisation de diagramme de séquence permet de lister les méthodes dont on aura besoin lors de la phase de développement.
Le diagramme de séquence de la figure III.7 illustre le processus d’authentification d’un utilisateur. L'utilisateur va remplir le formulaire d'authentification, il y aura une authentification sur les données saisies. Si les informations sont correctes, selon le profil utilisateur ou administrateur une page d'accueil s'affichera. Si les informations sont incorrectes, un message d'erreur s'affichera et il va retrouver la page d'authentification.
36
Figure III.7 : Diagramme de séquence de processus d’authentification
Le diagramme de la figure III.8 illustre le processus d'ajout d'un utilisateur au sein du l’application bien sûr qui doit être précédé par une authentification. Ce processus se déroule de la même manière pour la modification, la suppression et la recherche d'un utilisateur. En faite, l'utilisateur rempli le formulaire d'ajout d'un utilisateur Après la vérification, si les informations sont correctes alors l'opération s'effectuera, sinon un message d'erreur s'affichera.
Figure III.8 : Diagramme de séquence de processus d'ajout d'un utilisateur
37
Le diagramme de la figure III.9 illustre le processus de modification d’un équipement au sein de l’application bien sûr qui doit être précédé par une authentification. Ce processus se déroule de la même manière pour la suppression d’un équipement. En faite, l'utilisateur sélectionne le numéro de série à modifier, la page de modification s’affiche avec les informations de l’équipement sélectionné. Une fois que les informations modifiés sont correctes alors l’opération de sauvegarde d’effectue, sinon un message d'erreur s'affichera.
Figure III.9 : Diagramme de séquence de processus de modification d'un équipement
Le diagramme de la figure III.10 illustre le processus de supervision au sein de l’application bien sûr qui doit être précédé par une authentification. Après authentification, l’utilisateur va choisir l’interface de supervision et d'administration qui va afficher les positions géographiques de tous les équipements ainsi que leurs états.
38
Figure III.10 : Diagramme de séquence de processus de supervision et d'administration
III.3. Conclusion
Dans ce chapitre nous avons fait la description des diagrammes de classe, de séquence et de paquetage afin de délimiter le cadre de notre travail et de préparer un terrain favorable pour la prochaine étape.
Maintenant, notre application est prête à être codée. Dans le chapitre suivant, nous allons nous intéresser à l’implémentation de notre système en se basant sur la conception détaillée réalisée dans ce chapitre.
39
Chapitre IV
Réalisation
40
Chapitre IV – Réalisation
Dans ce chapitre, nous allons évoquer une phase cruciale de notre projet, qui est l’implémentation de l’application. Nous commencerons par la représentation de l’environnement matériel et logiciel et les différents outils de développement utilisés. Enfin, nous représenterons des captures d’écran qui illustrent notre travail.
IV.1. Environnement matériel
Pour la réalisation de notre application, Nous avons utilisé deux PC, dont les configurations sont les suivantes :
Poste serveur :
OS : Windows 8
RAM : 8 Go
Disque Dur : 1To
Processeur : i5
Poste client :
OS : Windows 7
RAM : 2 Go
Disque Dur : 500 Go
Processeur : i3
IV.2. Environnement logiciel
Pour réaliser notre projet, nous avons eu recours à une multitude des logiciels :
Outil de développement :
o Langage de programmation : PHP.
o Langage de mise en forme : CSS o SGBD : MySQL server.
Outil de conception : UML Diagrammer.
Système d'exploitation : Windows 8, Windows 7
41
IV.3. Outils de développement
Les outils de développement désignent un ensemble d’outils destinés à nous aider à créer et à développer des pages Web.
IV.3.a Langage de programmation PHP
PHP est un langage de script utilisé le plus souvent côté serveur : dans cette architecture, le serveur interprète le code PHP des pages web demandées et génère du code (HTML, XHTML, CSS par exemple) et des données (JPEG, GIF, PNG par exemple) pouvant être interprétés et rendues par un navigateur. PHP peut également générer d'autres formats comme le WML, le SVG, le PDF. [N2]
Il a été conçu pour permettre la création d'applications dynamiques, le plus souvent développées pour le Web. PHP est le plus souvent couplé à un serveur Apache bien qu'il puisse être installé sur la plupart des serveurs HTTP tel que IIS. Ce couplage permet de récupérer des informations issues d'une base de données, d'un système de fichiers (contenu de fichiers et de l'arborescence) ou plus simplement des données envoyées par le navigateur afin d'être interprétées ou stockées pour une utilisation ultérieure.
C'est un langage peu typé et souple et donc facile à apprendre par un débutant mais, de ce fait, des failles de sécurité peuvent rapidement apparaître dans les applications.
Pragmatique, PHP ne s'encombre pas de théorie et a tendance à choisir le chemin le plus direct. Néanmoins, le nom des fonctions (ainsi que le passage des arguments) ne respecte pas toujours une logique uniforme, ce qui peut être préjudiciable à l'apprentissage
IV.3.b Langage de mise en forme CSS
Le terme CSS [N3] est l'acronyme anglais de Cascading Style Sheets qui peut se traduire par "feuilles de style en cascade". Le CSS est un langage informatique utilisé sur l'internet pour mettre en forme les fichiers HTML ou XML. Ainsi, les feuilles de style, aussi appelé les fichiers CSS, comprennent du code qui permet de gérer le design d'une page en HTML.
Bien que l'HTML puisse être mis en forme à l'aide de balises prévus à cet effet, de nos jours il est plus judicieux d'utiliser le CSS et de n'utiliser le XHTML que pour le contenu.
L'avantage de l'utilisation d'un fichier CSS pour la mise en forme d'un site réside dans la possibilité de modifier tous les titres du site en une seule fois en modifiants une seule partie du fichier CSS. Sans ce fichier CSS, il serait nécessaire de modifier chaque titre de chaque page du site (difficilement envisageable pour les énormes sites de plusieurs milliers de pages).
42 IV.3.b Base de données MYSQL
MYSQL est un système de gestion de bases de données relationnelles (SGBDR). Il est distribué sous une double licence GPL et propriétaire [N4] .Il fait partie des logiciels de gestion de base de données les plus utilisés au monde3, autant par le grand public (applications web principalement) que par des professionnels, en concurrence avec Oracle, Informix et Microsoft SQL Server.
MySQL est un serveur de bases de données relationnelles SQL développé dans un souci de performances élevées en lecture, ce qui signifie qu'il est davantage orienté vers le service de données déjà en place que vers celui de mises à jour fréquentes et fortement sécurisées.
Afin de bénéficier des outils indiqués dans le paragraphe ci-dessus, on a installé en local le pack EasyPHP qui regroupe les applications suivantes :
Le serveur web Apache
Le serveur de base de données MySQL
Le serveur d'application PHP
L’outil phpMyAdmin permettant de gérer des bases MySQL
43
IV.4. Interfaces de l’application
Un exemple d’interfaces est représenté par les figures suivantes :
Figure IV.1 : Interface d’authentification
Pour bénéficier des services de mon application chaque utilisateur doit saisir son matricule et un mot de passe valide. Ce dernier sera redirigé soit pour l’interface des administrateurs, ou l'interface des utilisateurs selon son profil.
Dans la fenêtre de la figure IV.2, on trouve l'interface d'accueil de l'administrateur. Par cette interface on peut accéder aux différentes modules, tel que la gestion des utilisateurs, la gestion des équipements, la gestion préférences et l'administration et la configuration.
44
Figure IV.2 : Interface d'accueil de l'administrateur
Dans la fenêtre de la figure IV.3, on trouve l'interface de gestion des utilisateurs. Par cette interface on peut accéder aux différentes fonctionnalités, tel que l'ajout, la modification, la suppression et le listage des utilisateurs.
Figure IV.3 : Interface de gestion des utilisateurs
45
Après l’affichage de la fenêtre de la figure IV.4 on doit la remplir par les informations demandées ci-dessous (matricule, nom, prénom, centre, téléphone, email, mot de passe, profil). Si tous les champs sont remplis, on clique sur le bouton valider pour enregistrer les informations. Un contrôle se fait sur le format de l'adresse email.
Figure IV.4 : Interface d’ajout d’un utilisateur
Après l’affichage de la fenêtre de la figure IV.5 on sélectionne le matricule de l'utilisateur à partir d'une liste déroulante pour modifier l’une ou toute ses informations (profil, nom, prénom, téléphone, email, mot de passe), sauf le matricule qui est inchangeable.
Cette interface semble à l'interface d'accueil de suppression d'un utilisateur, c'est à dire l'administrateur doit sélectionner le matricule pour passer à l'interface de suppression.
