Rapport de Stage Ericsson PDF

Rapport de stage
éme
4 année
« Conception et réalisation d’un système

de gestion et de suivi des sites réseaux »
Réalisé par : Encadré par :

AITSAID Souhail BAKHOUSS El Mehdi
Année universitaire 2013-2014

Dédicace
Je dédie ce rapport:
A mes parents :
Toute dédicace demeure insuffisante pour vous exprimer notre
reconnaissance. Vos sacrifices constants et démesurés, vos prières et
vos encouragements nous ont permis de progresser de continuer nos
études dans des conditions propices. Puisse Dieu tout puissant vous
procurer santé, bonheur et longue vie.
A mes professeurs :
Votre professionnalisme et votre modestie exemplaire sont pour nous
une source d’admiration et de profond respect.
Nous vous remercions infiniment pour tous les efforts déployés afin de
contribuer à ma formation.
A mes amis :
En témoignage de nos inoubliables moments de liesse, de fraternité.
Je vous souhaite beaucoup de persévérance.
A tout le personnel de l’EMSI :

Les qualités humaines et la disponibilité dont vous avez fait preuve à
mon égard me sont d’une aide cruciale.
Remerciement
Avant tout développement sur le projet je souhaite commencer ce

rapport par des remerciements à mon encadrant Monsieur BAKHOUS
Mehdi dont l’aide à la réalisation de ce travail était d’un grand apport.
Votre dynamisme et votre grande compétence forcent mon admiration.
Veuillez croire, en l’assurance de mon respect et ma grande
reconnaissance.
Je tiens à remercier tout particulièrement et à témoigner toute ma

reconnaissance à Monsieur NADIRI, L’ampleur de vos connaissances,
votre gentillesse et votre disponibilité ont toujours suscité mon respect.
Nous vous remercions pour votre soutien, pour vos encouragements et
vos critiques constructives ainsi que la rigueur que vous avez su nous
donner.
Puis, mille mercis à tout le personnel de l’EMSI. Nous avons été touchés
de près tout au long de notre parcours par votre amabilité et efficacité,
votre simplicité exemplaire n’a d’égale que vos compétences.
Résumé
Le projet que présente ce document s’inscrit dans le cadre du stage de

la 4éme année de mon cursus en Ingénierie Informatique et Réseaux au
sein de l’Ecole Marocaine des Sciences de l’Ingénieur.
Le but de ce stage est la conception et la réalisation d’système de

gestion des sites réseaux au sein de la société ERICSSON, dans la
perspective d’améliorer leur service de gestion et répondre aux
plusieurs attentes qualitatives.
Cette mise en place a pour but l’amélioration de la performance de la

société vis à vis de ses clients et du marché. Car en effet, grâce à cet
outil informatique adapté, la société répondra aux mieux à la demande
et à la rivalité.
Abstract
The project presented in this document is part of the traineeship of the

4th year in Computer Engineering and Networks in the Moroccan School
of Engineering Sciences.
The purpose of this traineeship is the conception and realization of a

system that manages and monitors network sites of ERICSSON’s
society, with the prospect to improve their service management and
respond to several expectations.
This set up aims to improve the performance of the company with

respect to its clients and the market. For indeed, with this customized
computer tool, the company will respond to more demand and rivalry.
Glossaire
API : Application Programming Interface
CSS : Cascade StyleSheet
DAO : Data Access Object
DQL : Doctrine Query Language
FOS : Friends Of Symfony
HTML : Hypertext Markup Language
IHM : Interface Homme Machine
MVC : Model View Controller
ORM : Object Relational Mapping
SGBDR : Système de Gestion de Base de Données
Relationnelles
SQL : Structured Query Language
UML : Unified Modeling Language
URL : Uniform Resource Locator
XML : eXtensible Markup Language
YML : Ain’t Markup Language
Rapport de stage Table des figures
Table des figures

Figure 1 Diagramme de Gant 1 ______________________________________________________________ 9
Figure 2 Diagramme de Gant 2 _____________________________________________________________ 10
Figure 3 Diagramme de contexte ____________________________________________________________ 13
Figure 4 Diagramme de cas d'utilisation global _________________________________________________ 15
Figure 5 Diagramme de cas d'utilisation : Gestion des sites _______________________________________ 16
Figure 6 Diagramme de séquence gestion sites réseaux ___________________________________________ 21
Figure 7 Diagramme d'interactions d'ajout site réseau ___________________________________________ 22
Figure 9 Diagramme d'interactions : Suppression site réseau ______________________________________ 23
Figure 8 Diagramme d'interactions : modification site réseau ______________________________________ 23
Figure 10 Diagramme de classes : Gestion sites réseaux __________________________________________ 24
Figure 11 Diagramme de navigation : Gestion des sites __________________________________________ 25
Figure 12 Diagramme de séquences : Gestion des utilisateurs _____________________________________ 29
Figure 13 Diagramme d'interactions : Ajouter un utilisateur _______________________________________ 30
Figure 14 Diagramme d'interaction : Suppression d'un utilisateur __________________________________ 30
Figure 15 Diagramme de classe : Gestion des utilisateurs _________________________________________ 31
Figure 16 Diagramme de navigation : Gestion des utilisateurs _____________________________________ 32
Figure 17 Diagramme de déploiement ________________________________________________________ 33
Figure 18 Pattern MVC ____________________________________________________________________ 36
Figure 19 Implémentation du pattern MVC par Symfony2.3 _______________________________________ 41
Figure 20 Fonctionnement du routeur Symfony _________________________________________________ 42
Figure 21 Aperçu du routeur de l'application ___________________________________________________ 42
Figure 22 Aperçu du fichier security.yml ______________________________________________________ 45
Figure 23 Aperçu d'utilisation d'objet Highcharts _______________________________________________ 46
Figure 24 L'architecture globale des fichiers du projet Symfony ____________________________________ 50
Figure 25 Aperçu de la page d'authentification depuis un écran de 15° ______________________________ 52
Figure 26 Page d'authentification depuis un écran mobile _________________________________________ 53
Figure 27 Aperçu de la page principale de la gestion des sites réseaux _______________________________ 54
Figure 28 Aperçu de la page principale de la gestion des stations réseaux ____________________________ 55
Figure 29 Aperçu de la page dédiée à l'ajout d'un nouvel utilisateur _________________________________ 56
Figure 30 Aperçu de la page d'erreur relative au manque de privilèges d'accès ________________________ 56
Rapport de stage Liste des tableaux
Liste des tableaux

Tableau 1 Description de la gestion des sites réseaux .......................................................................................... 17
Tableau 2 Scenario nominal : gestion des sites réseaux ....................................................................................... 18
Tableau 3 Alternative : suppression d'un site réseau ............................................................................................ 18
Tableau 4 Alternative : modification d'un site réseau ........................................................................................... 19
Tableau 5 Exception: ajouter un site réseau ......................................................................................................... 20
Tableau 6 Description de la gestion des utilisateurs ............................................................................................. 25
Tableau 7 Scenario nominal: Ajouter un utilisateur ............................................................................................. 26
Tableau 8 Alternative : Affecter des rôles ............................................................................................................. 27
Tableau 9 Alternative: Modifier un utilisateur ...................................................................................................... 28
Tableau 10 Exception: Ajouter un utilisateur ....................................................................................................... 29
Rapport de stage Sommaire
Sommaire
Introduction générale _______________________________________________________ 1
Chapitre I Contexte Général du projet ________________________________________ 2
1. Présentation de l’organisme d’accueil _____________________________________ 3
1.1. Les services offerts par ERICSSON ___________________________________________________ 3
1.2. Situation et axes forts d’ERICSSON ___________________________________________________ 3
2. Présentation du sujet ___________________________________________________ 4

Chapitre II Etude préliminaire et fonctionnelle _________________________________ 5
1. Cadre général du projet _________________________________________________ 6
1.1. Contexte _________________________________________________________________________ 6
1.2. Problématique ____________________________________________________________________ 6
1.3. Objectifs_________________________________________________________________________ 7
1.4. Étude fonctionnelle ________________________________________________________________ 7
2. Déroulement du projet __________________________________________________ 9

2.1. Diagramme de Gantt _______________________________________________________________ 9
Chapitre III Analyse et conception ___________________________________________ 11

1. UML ________________________________________________________________ 12
1.1. Présentation _____________________________________________________________________ 12
1.2. Choix d’UML ___________________________________________________________________ 12
2. Diagramme de contexte ________________________________________________ 12

3. Diagramme de cas d’utilisation __________________________________________ 14
4. Entité de gestion des sites réseaux : _______________________________________ 16
4.1. Diagramme de cas d’utilisation ______________________________________________________ 16
4.2. Diagramme de séquences système ____________________________________________________ 20
4.3. Diagramme d’interactions __________________________________________________________ 21
4.4. Diagramme de classes _____________________________________________________________ 24
4.5. Diagramme de navigation Gestion des sites ____________________________________________ 24
5. Entité de Gestion des utilisateurs : _______________________________________ 25

5.1. Diagramme de cas d’utilisation ______________________________________________________ 25
5.2. Diagramme de séquences système ____________________________________________________ 29
5.3. Diagrammes d’interactions _________________________________________________________ 30
5.4. Diagramme de classes _____________________________________________________________ 31

5.5. Diagramme de navigation Gestion des utilisateurs _______________________________________ 32
6. Diagramme de déploiement _____________________________________________ 32

Chapitre IV Aspect technique _______________________________________________ 34
1. Spécification technique _________________________________________________ 35
1.1. MVC __________________________________________________________________________ 35
1.2. Architecture 3-tiers _______________________________________________________________ 36
2. Technologies utilisée ___________________________________________________ 38

2.1. Framework Symfony 2.3 ___________________________________________________________ 38
2.2. Les fonctionnalités de Symfony 2.3___________________________________________________ 38
2.3. Pourquoi Symfony 2.3 ? ___________________________________________________________ 39
2.4. Le fonctionnement de Symfony 2.3 ___________________________________________________ 39
2.5. Le Design Pattern MVC en Symfony 2.3 ______________________________________________ 39
2.6. Décomposition fonctionnelle de l’application ___________________________________________ 41
3. Outils utilisés _________________________________________________________ 46

3.1. PHP ___________________________________________________________________________ 46
3.2. MySQL ________________________________________________________________________ 47
3.3. HTML5 ________________________________________________________________________ 47
3.4. CSS3 __________________________________________________________________________ 48
3.5. JavaScript_______________________________________________________________________ 48
3.6. jQuery _________________________________________________________________________ 48
3.7. YAML _________________________________________________________________________ 49
3.8. Visual Paradigm__________________________________________________________________ 49
4. L’architecture des fichiers ______________________________________________ 50

Chapitre V Réalisation _____________________________________________________ 51
1. Page d’accueil ________________________________________________________ 52
2. Gestion des sites réseaux _______________________________________________ 53
3. Gestion des stations réseaux_____________________________________________ 54
4. Gestion des utilisateurs _________________________________________________ 55
5. Privilège d’accès ______________________________________________________ 56
Conclusion générale _______________________________________________________ 58
Rapport de stage Introduction générale
Introduction générale
En raison de l’importance de ses missions, Ericsson se trouve au cœur du marché de

télécommunication au Maroc. Par ses interventions elle permet aux différentes entreprises de
télécommunication de déployer leurs réseaux de communication. Sur un autre plan, la mission
d’Ericsson peut être qualifiée d’une mission d’intérêt générale vu l’importance du rôle qu’elle
joue dans le domaine.
Ma mission était donc l’élaboration d’un système offrant une meilleure gestion des sites, des
stations, antennes et des équipements Ericsson dans le but de réduire l’utilisation excessive
des différentes ressources (matérielles, humaines…) qui résulte de l’utilisation de systèmes
classiques et non intègres. C’est dans ce cadre que s’inscrit mon projet de fin d’année intitulé
«Conception et la réalisation d’un système de gestion des sites réseaux».
L’application doit permettre d’avoir une vue globale sur les sites réseaux et leur différents
états. Elle doit être développée pour un fonctionnement Intranet et compatible avec un serveur
web Apache.
Le présent rapport présente le travail réalisé durant ma période de stage. Il comporte cinq
chapitres structurés dont le premier définit le contexte général du projet. Une étude
fonctionnelle que doit assurer l’application est l’objet du second chapitre. Le troisième
chapitre va porter sur l’analyse et conception de l’application. Les différentes technologies
qu'on a utilisées, avec description des différents Framework qu’elle implémente feront l’objet
du quatrième chapitre. Puis le dernier chapitre exposera la partie réalisation de ce projet.
Rapport de stage CH1 : Contexte général du projet
Chapitre I Contexte Général du projet
Ce chapitre a pour objectif de situer le projet dans
son contexte général. La première section est dédiée
à la présentation de l’organisme d’accueil ERICSSON,
la deuxième section discute la problématique et
expose le sujet du projet.
2
1. Présentation de l’organisme d’accueil

ERICSSON est le leader mondial dans la fourniture de technologies et de services aux
opérateurs de télécommunications.
Il a pour ambition d’être l’acteur principal d’un monde communicant à travers l’innovation,
la technologie, et des solutions durables. Il se trouve désormais devant de grandes
opportunités d’innovation que ce soit pour l’industrie, les services publics ou encore la sphère
privée. Cet organisme passe de la Société de l’Information à la Société en Réseau, dans
laquelle la préoccupation première n’est plus l’accès à l’information mais quel bénéfice en
tirer. Il a fallu 100 ans pour connecter 1 milliard de lieux, et 25 ans pour connecter 5 milliards
de personnes. La prochaine étape consiste à connecter les objets.
1.1. Les services offerts par ERICSSON

Ericsson est spécialisé dans la conception, la fabrication et la commercialisation de systèmes
et d'équipements de télécommunications fixes et mobiles. Le par famille de produits et
services se répartit comme suit :
- Systèmes et équipements de téléphonie et de réseaux de transmission (53,2%) ;
- Services (41,1%) : notamment services de gestion et de contrôle de réseaux et d'intégration
de systèmes
- Equipements multimédia (5,7%).
A fin 2012, le groupe dispose de 16 sites de production dans le monde.
La répartition géographique du CA est la suivante : Suède (2,2%), Chine (5,5%), Inde (2,8%),
Europe et Asie-Pacifique (27,4%), Etats-Unis (24,9%), Amérique du Nord (0,1%), Amérique
latine (9,7%), Moyen Orient (6,8%), Afrique sub-saharienne (5%) et autres (15,6%).
1.2. Situation et axes forts d’ERICSSON

Actuellement, Ericsson est présente dans 180 pays, compte plus de 110 000 employés, plus de
33000 brevets et 40% des appels mobiles transit par leurs systèmes.
ERICSSON a plusieurs axes forts en Telecom, haut débit fixe, haut débit mobile, services de
communication, services managés, UMTS, LTE, 3G, 4G, OSS, BSS, Cloud, réseaux, TV et
3
Media Management, IPTV, ICT, IT, IP, programme de responsabilité, développement

durable.
2. Présentation du sujet
Ce projet est une Application Web dédiée à Ericsson au Maroc pour répondre aux multiples
problématiques que cette tranche de professionnels rencontre au quotidien.
Cette application doit assurer une gestion minutieuse des sites réseaux, de leurs stations,
antennes et équipements pour répondre aux attentes et besoins des utilisateurs et optimiser le
temps.
L’application doit également offrir un tableau de bord pour assurer une meilleure visibilité
pour les utilisateurs, avec aptitude de supervision de l’état des différents composants gérés par
l’application.
Ma mission consiste aussi à l’élaboration d’un module pour la gestion des utilisateurs qui
permettras de crée des utilisateurs, leur attribuer des droits afin d’utilisé l’application selon
leurs postes dans la société.
Conclusion
Dans ce premier chapitre j’ai visé en premier lieu à situer le projet dans son cadre général en
présentant l’organisme d’accueil, puis j’ai dédié la seconde partie à la définition du sujet puis
la problématique soulevée Ericsson. Ce chapitre sert donc à présenter théoriquement mon
sujet mieux comprendre le système implémenté. Le chapitre suivant sera consacré à l'étude
des besoins fonctionnels et non fonctionnels que notre application doit assurer.
4
Rapport de stage Etude préliminaire et fonctionnelle
Chapitre II Etude préliminaire et

fonctionnelle
Ce chapitre vise à décrire le projet et ses objectifs.
Ensuite, les différentes fonctionnalités que
l’application doit assurer, la méthodologie du travail,
puis une dernière partie dédiée au planning du projet.
5
1. Cadre général du projet
1.1. Contexte
Actuellement, il existe une offre importante de logiciel de gestion sur le marché. Cependant,
ils sont plus adaptés aux entreprises et organisation dont l’activité principale est purement
commerciale (Achat/Vente) qu’aux entreprises dont l’activité est déterminée par un ensemble
de processus métiers intègres. Ma mission était donc de mettre au point une application web
dédiée à ERICSSON, répondant à ses attentes en termes de gestion d’informations des sites
réseaux tout en offrant une visibilité globale sur son état actuel, en se basant sur un cahier de
charges élaboré minutieusement.
1.2. Problématique
Une grande majorité des entreprises au Maroc se basent sur un système d’information limité,
employant des méthodes dépassées et inefficaces à base d’outils de bureautique de traitement
de texte, ce qui produit des redondances d’informations, des pertes de données, et constitue de
grands gaspillages de temps et de ressources, ce qui se traduit par des pertes pour les
entreprises en question.
La plupart des responsables sont confrontés aux mêmes problèmes que je décriai comme suit :
- Perte de données, difficultés de recherches d’informations lorsqu’il s’agit des milliers des
sites réseaux installés au Maroc.
- Redondance des informations : Tout est inscrit dans des documents Excel, pas de
centralisation des données.
- Difficulté de mise au point des situations des sites réseaux.
- Difficultés de suivi de sites réseaux, de mise au point de l’état actuel.
- Gestion manuelle des informations.
- Absence de gestion d’utilisateurs et d’autorisations.
6
- Absence de traçabilité et de supervision.
- Absence de tableau de bord.
1.3. Objectifs
L’objectif principal dans la mise en œuvre de cette application le développement d’une
solution informatique permettant une gestion de pointe des sites et stations réseaux
ERICSSON installé au Maroc.
L’application est réalisée en utilisant le Framework Symfony 2.3 basé sur une architecture
MVC (Model, View, Controller), en interaction avec une base de données MySQL.
Le but de cette application est de respecter les contraintes suivantes pour sa réalisation et son
bon fonctionnement :
 L’application doit être accessible par plusieurs acteurs distincts.

 L’application doit fournir un tableau de bord intuitif et global
 L’application doit être consultable depuis le réseau Intranet.
 L’application doit être développée pour être compatible avec un serveur web Apache.
1.4. Étude fonctionnelle
 Principaux besoins fonctionnels
L’objectif principal dans la mise en œuvre de ce premier module est l’élaboration d’une
solution informatique générique s’adaptant à tous les bureaux ERICSSON marocains.
Ce module comprendra principalement les fonctionnalités présentes :
 Tableau de bord offrant une visibilité globale de l’état des sites.

 Gestion des stations réseaux dans un site, cette gestion nous permettra de garantir un
suivi de l’état d’un site réseau.
 Gestion des antennes et des équipements d’une station, offrant une possibilité de
mise à jour
7
 L’utilisateur peut également lister les antennes et équipement de cette

même station.
 Gestion des utilisateurs et leurs rôles.
 L’utilisateur ayant les privilèges peut également affecter ou désaffecter
des rôles aux utilisateurs.
 Besoins non fonctionnels
Les besoins non fonctionnels décrivent toutes les contraintes auxquelles est soumis
l’application pour sa réalisation et son bon fonctionnement.
-Confidentialité
La notion de confidentialité est importante lorsqu’il s’agit de formation. Il faudra donc veiller
à ce qu’aucune information des utilisateurs ne puisse tomber dans les mains d’une tierce
personne. Il faudra donc sécuriser les données et les accès à ces données.
-Ergonomie et souplesse
L'application doit offrir une interface conviviale et ergonomique exploitable par l’utilisateur
en envisageant toutes les interactions possibles à l'écran du support tenu.
-Rapidité
L'application doit optimiser les traitements pour avoir un temps de génération de schéma
raisonnable.
- Efficacité
L'application doit être fonctionnelle indépendamment de toutes circonstances pouvant

entourer l'utilisateur.
8
2. Déroulement du projet
2.1. Diagramme de Gantt
 Définition
Le diagramme de GANTT est un diagramme permettant de modéliser la planification des

tâches nécessaires à la réalisation d'un projet. Il permet de visualiser dans le temps ces
diverses tâches.
 Gantt
Le diagramme de GANTT présenté ci-dessous jouait le rôle d’un fil conducteur tout au long
du projet. Il m’a permis d’ajuster les dérives et de maîtriser la gestion du temps alloué pour la
réalisation du projet.
Les deux figures ci-dessous montrent le planning du déroulement du stage :
Figure 1 Diagramme de Gant 1
9
Figure 2 Diagramme de Gant 2
Conclusion
Dans ce premier chapitre j’ai visé en premier lieu la description du projet puis les
fonctionnalités diverses que doit assurer notre solution en cernant les besoins fonctionnels et
non fonctionnels de l’application, puis finalement donne un aperçu des étapes de déroulement
du stage concrétisés par un diagramme de GANTT.
10
Rapport de stage Analyse et conception
Chapitre III Analyse et conception
Ce chapitre va décrire la méthodologie suivie pour la
réalisation de ce travail ainsi que la technologie de
base de la conception de notre système, pour élaborer
les différents diagrammes qui vont nous aider à
modéliser le system à mettre en place.

11
1. UML
1.1. Présentation
UML «Unified Modeling Language» [1] est un langage de modélisation formel et normalisé,
né de la fusion de plusieurs méthodes existantes. Il est conçu pour l'écriture des plans
d'élaboration de logiciels.
UML est utilisé pour spécifier, visualiser, modifier et construire les documents nécessaires au
bon développement d'un logiciel orienté objet. Il offre un standard de modélisation, pour
représenter l'architecture logicielle.
UML comble une lacune importante des technologies objet. Il permet d'exprimer et d'élaborer
des modèles objet, indépendamment de tout langage de programmation. C'est un langage très
expressif qui couvre toutes perspectives nécessaires au développement puis au déploiement
des systèmes.
1.2. Choix d’UML

J’ai choisi la modélisation avec UML pour sa notation qui est la plus appropriée pour des
projets orientés objets. En effet, le langage UML offre une multitude de possibilités :
La notation UML facilite la compréhension et la communication d’une modélisation objet.
UML offre une très bonne compréhension du problème : le système à étudier sera traité
suivant différents angles et suivant les différents cas d’utilisation de ce système.
UML s’adapte parfaitement à la modélisation des applications à base d’objets et offre grâce à
ses différents diagrammes - une grande souplesse permettant la modélisation de différents
aspects de l’application. UML est aujourd’hui un standard adopté par les grands constructeurs
de logiciel du marché.
2. Diagramme de contexte
Pour ce projet, et dans la mesure de s’aligner avec le choix du formalise UML, nous avons
élaboré le diagramme de contexte, ce dernier un modèle métier ou fonctionnel qui est utile en
début de projet pour clarifier le domaine d'étude car il permet de :
12
- Le situer dans son environnement (ce qui le concerne et ce qui ne le concerne pas) ;
- Identifier ses flux d'informations avec son environnement.
- Délimiter ce qu’il y a à faire et ne pas faire.
Le diagramme de contexte [1] permet également de modéliser les principaux besoins que l’on
aura pour l’application, et de présenter les interactions entre les différents types d’utilisateurs
et la plateforme.
On se positionne uniquement sur le problème : on ne fait donc figurer que les flux entre le
domaine étudié et les domaines connexes ou partenaires.
Figure 3 Diagramme de contexte
Sur le diagramme de contexte, on constate que ce système est en interaction avec des trois
acteurs distincts :
13
 l’utilisateur, c’est l’acteur qui est responsable de gérer les zones, les programmes,
les antennes et les équipements des sites réseaux ainsi le suivi des stations.
 Le responsable, c’est l’acteur qui gère les sites et les stations réseaux.
 L’administrateur est l’acteur le plus privilégié, responsable de la gestion interne de
l’application et gestions des utilisateurs et leurs rôles.
3. Diagramme de cas d’utilisation

Les diagrammes de cas d'utilisation [1] sont des diagrammes UML utilisés pour donner une
vision globale du comportement fonctionnel d'un système logiciel. Ils sont utiles pour des
présentations auprès de la direction ou des acteurs d'un projet.
Un cas d'utilisation représente une unité discrète d'interaction entre un utilisateur (humain ou
machine) et un système. Dans un diagramme de cas d'utilisation, les utilisateurs sont appelés
acteurs (Actors), ils interagissent avec les cas d'utilisation (Use Cases).
 Diagramme de cas d’utilisation global :

Le système englobant dispose de plusieurs cas d’utilisations qui résument l’ensemble des
fonctionnalités clés de l’application, et sont les suivants :
- Gestion des zones
- Gestion des programmes
- Gestion des antennes
- Gestion des équipements
- Suivi des stations
- Gestion des sites
- Gestion des stations
- Gestion des utilisateurs
14
Ci-dessous le diagramme de cas d’utilisation global qui cerne les fonctionnalités clés de
l’application :
Figure 4 Diagramme de cas d'utilisation global
Ce diagramme donne une vision globale sur le système, comme suit:
• Tous les cas d'utilisation nécessitent une authentification.
• Un utilisateur peut gérer différentes entités telles que les zones des sites réseaux, les
programmes, antennes et équipements utilisées dans les sites réseaux ainsi le suivi des
stations.
• Un responsable dispose des mêmes privilèges que l’utilisateur, mais peut en plus gérer les
sites et stations réseaux directement et suivre leurs états.
• L’administrateur est l’acteur ayant le plus de privilèges, disposant des mêmes droits que le
responsable, avec en plus la possibilité de gérer les utilisateurs de l’application, et leur
affecter les rôles.
15
4. Entité de gestion des sites réseaux :

Après avoir présenté une vue générale sur les cas d’utilisation du système, nous allons
présenter la conception relative à une des différentes entités en offrant une description
détaillée de chaque diagramme.
Cette entité englobe différentes fonctionnalités relatives à la gestion des sites réseaux, à
savoir la mise à jour des informations, le suivi de leurs états et l’enregistrement des nouveaux
sites réseaux.
4.1. Diagramme de cas d’utilisation
Figure 5 Diagramme de cas d'utilisation : Gestion des sites
 Descriptifs textuels
Le responsable a le droit de gérer le volet dédié aux sites réseaux, pouvant donc ajouter un
nouveau site, afficher ses informations ou les mettre à jour, le supprimer ou le rechercher
parmi la liste des sites réseaux. Toutes ces fonctionnalités nécessitent une authentification
d’utilisateur ayant au minimum le rôle Responsable.
16
 Description générale
Cas d’utilisation Gestion des sites réseaux
Acteurs - Responsable
Objectifs - Le responsable veut ajouter, modifier, supprimer ou

rechercher un site réseau
Pré-conditions - Le responsable est connecté à l’application

- L’application doit être en état de marche
Tableau 1 Description de la gestion des sites réseaux
 Scenario
Scenario nominal 1 Ajouter un site réseau
Description - Le responsable ajoute un ensemble de sites réseaux

Etapes - Le responsable clique sur « Sites »

- Le responsable clique sur « Add new site »
- Une interface de créations avec les champs nécessaires
s’affiche
- Le responsable saisie les informations du site :
* ajouter le code et le nom du site réseau
*ajouter les informations sur la géo position du site réseau
*choisir le type et le programme fonctionnel sur le site
réseau
- Le responsable clique sur le bouton « Create »
- La liste des sites réseaux est mise à jour en cas de réussite
17
Post-conditions - Un site réseau est crée et figure dans la liste des sites
Tableau 2 Scenario nominal : gestion des sites réseaux
 Alternatives
Alternative 1 supprimer un site réseau
Description - Le responsable supprime un site réseau

- Le site réseau doit exister

- La liste des sites réseaux est affichée avec un filtre de
recherche
- Le responsable recherche le site en question
- Le responsable choisi le site et clique sur l’icône de
suppression:
- Un message de demande de confirmation de suppression
s’affiche.
*Confirm
*Abort
Post-conditions - Un site réseau est supprimé crée et ne figure plus dans la

liste des sites
Tableau 3 Alternative : suppression d'un site réseau
18
Alternative 2 Modifier un site réseau
Description - Le responsable met à jour les informations d’un site réseau

- Le site réseau doit exister

- La liste des sites réseaux est affichée avec un filtre de
recherche
- Le responsable recherche le site en question
- Le responsable choisi le site et clique sur l’icône de
Modification:
- Le responsable met à jour les informations du site réseau :
* Modifier le code et le nom du site réseau
*Modifier les informations sur la géo position du site
réseau
*Modifier le type et le programme fonctionnel sur le site
réseau
- Le responsable clique sur « Update » pour enregistrer les
modifications
Post-conditions - Un site réseau est modifié
Tableau 4 Alternative : modification d'un site réseau
19
 Exceptions
Exception 1 Ajouter un site réseau
Description - Le responsable ajoute un ensemble de sites réseaux
Contexte du - Le responsable veut valider la création d’un site réseau avec

des champs non remplis
déclenchement


- Le responsable clique sur « Add new site »
s’affiche
- Le responsable rempli le formulaire avec des champs
importants vides
- Le système renvoi le formulaire avec un message d’erreur
indiquant que des champs important n’ont pas été remplis
Post-conditions - Un site réseau n’est pas crée et ne figure pas dans la liste
des sites
Tableau 5 Exception: ajouter un site réseau
4.2. Diagramme de séquences système

Les diagrammes de séquences [1] sont la représentation graphique des interactions entre les
acteurs et le système selon un ordre chronologique. Les principales informations contenues
dans ce diagramme sont les messages échangés entre les lignes de vie, présentés dans un ordre
chronologique. Pour les messages propres à un cas d’utilisation, les diagrammes de séquence
système montrent non seulement les acteurs externes qui interagissent directement avec le
système, mais également ce système (en tant que boîte noire) et les événements système
20
déclenchés par les acteurs. L’ordre chronologique se déroule vers le bas et l’ordre des
messages doit suivre la séquence décrite dans le cas d’utilisation.
Pour tous les diagrammes traités, on considère qu’une phase d’authentification est faite avant.
 Diagramme de séquences du cas d’utilisation « Crée site » et

« Supprimer site »
Figure 6 Diagramme de séquence gestion sites réseaux
4.3. Diagramme d’interactions

UML a introduit les diagrammes d’interaction [1] pour permettre de décrire les modalités de
communication entre objets, et non la manipulation des données impliquées dans cette
transaction. Les diagrammes d’interaction se focalisent sur les messages spécifiques échangés
par les objets, et sur la façon dont ces messages concourent à la réalisation de fonctionnalités.
Les structures composites ont pour but de montrer comment l’association de plusieurs objets
21
permet d’assurer une fonctionnalité : les diagrammes d’interaction décrivent comment ces
objets vont assurer cette fonctionnalité.
Ci-dessous les diagrammes d’interactions relatif à la gestion des sites réseaux :
 Diagramme d’interactions illustrant l’ajout d’un site réseau
Figure 7 Diagramme d'interactions d'ajout site réseau
22
 Diagramme d’interactions illustrant la modification d’un

sites réseaux
Figure 8 Diagramme d'interactions : modification site réseau
 Diagramme d’interaction illustrant la suppression d’un site

réseaux
Figure 9 Diagramme d'interactions : Suppression site réseau
23
4.4. Diagramme de classes
Figure 10 Diagramme de classes : Gestion sites réseaux
4.5. Diagramme de navigation Gestion des sites

Ce diagramme nous permet de bien voir la façon par laquelle on peut naviguer sur
l’application, il montre les différentes pages accessibles selon l’utilisateur
24
Figure 11 Diagramme de navigation : Gestion des sites
5. Entité de Gestion des utilisateurs :

Cette entité des fonctionnalités d’administration l’application telles que le paramétrage, la
gestion des utilisateurs et la gestion des droits.
5.1. Diagramme de cas d’utilisation

L’administrateur gérer les utilisateurs et leurs affecter des rôles, Ces fonctionnalités
nécessitent une authentification avec comme rôle celui d’Administrateur.
 Description général
Cas d’utilisation Gestion des utilisateurs
Acteurs - Administrateur
Objectifs - L’Administrateur veut ajouter, modifier, supprimer ou

rechercher un utilisateur, et lui affecter des droits
Pré-conditions - L’Administrateur est connecté à l’application

- Les utilisateurs et rôles doivent exister
Tableau 6 Description de la gestion des utilisateurs
25
 Scénario nominal
Scenario nominal 1 Ajouter un utilisateur
Description - L’administrateur ajoute un utilisateur
Pré-conditions - L’administrateur est connecté à l’application

Etapes - L’administrateur clique sur « Users »

- L’administrateur clique sur « Add new user »
s’affiche
- L’administrateur saisie les informations de l’utilisateur:
* nom d’utilisateur
*mot de passe
*choisir adresse e-mail
- L’administrateur clique sur le bouton « Create »
- La liste des utilisateurs est mise a jours en cas de réussit
Post-conditions - Un utilisateur est crée et figure dans la liste des sites
Tableau 7 Scenario nominal: Ajouter un utilisateur
26
 Alternatives
Alternative 1 Affecter des rôles
Description - L’administrateur affecte des rôles a un utilisateur

- L’utilisateur doit exister
Etapes - L’administrateur clique sur « Users »

- La liste des utilisateurs est affichée avec un filtre de
recherche
- L’administrateur recherche l’utilisateur question
- L’administrateur choisi l’utilisateur et clique sur l’icône de
modification
- L’administrateur affecte les rôles souhaité
- L’administrateur clique sur le bouton « Update »
- Un message de demande de confirmation de modification
s’affiche :
*Confirm
*Abort
Post-conditions - Un utilisateur est mis à jours et dispose de nouveaux

privilèges
Tableau 8 Alternative : Affecter des rôles
Alternative 2 Modifier un utilisateur
- L’administrateur active/désactive un utilisateur ou met à

Description jour ses informations d’authentification ou le supprime.
- L’administrateur est connecté à l’application

Pré-conditions - L'application doit être en état de marche
- L’utilisateur doit exister
- L’administrateur clique sur « Gestion des utilisateurs»
Etapes - La liste des utilisateurs est affichée avec un filtre de
recherche.
27
- L’administrateur recherche l’utilisateur en question.

- L’administrateur choisi l’utilisateur en question et clique
sur l’icône de Modification.
- L’administrateur a le droit de mettre à jour l’utilisateur:
* Activer l’utilisateur
* Désactiver l’utilisateur
* Supprimer l’utilisateur
* Modifier les informations de connexion
- L’administrateur clique sur le bouton « Update » pour
enregistrer les modifications.
- La liste des utilisateurs est mise à jour en cas de réussite.
Post-conditions - Un utilisateur est mis à jours
Tableau 9 Alternative: Modifier un utilisateur
 Exceptions
Exception 1 Ajouter un utilisateur
Description - L’administrateur ajoute un utilisateur
Contexte du - L’administrateur veut valider la création d’un utilisateur

réseau avec des champs non remplis
déclenchement

Etapes - Le responsable clique sur « Users »

- Le responsable clique sur « Add new user »
s’affiche
- L’administrateur rempli le formulaire avec des champs
importants vides
- Le système renvoi le formulaire avec un message d’erreur
indiquant que des champs important n’ont pas été remplis
28
Post-conditions - L’utilisateur n’est pas crée et ne figure pas dans la liste des
utilisateurs
Tableau 10 Exception: Ajouter un utilisateur
5.2. Diagramme de séquences système

 Diagramme de séquence du cas d’utilisation « Gestion des
utilisateurs »
Figure 12 Diagramme de séquences : Gestion des utilisateurs
29
5.3. Diagrammes d’interactions

 Diagramme d’interactions illustrant l’ajout d’un utilisateur
Figure 13 Diagramme d'interactions : Ajouter un utilisateur
 Diagramme d’interactions illustrant la suppression d’un

utilisateur
Figure 14 Diagramme d'interaction : Suppression d'un utilisateur
30
5.4. Diagramme de classes

 Diagramme de classe relatif a la gestion des utilisateurs
Figure 15 Diagramme de classe : Gestion des utilisateurs
L’entité User est une entité générée par le bundle FOSUserBundle implémenté dans notre
projet pour gérer la sécurité et les privilèges d’accès aux URL suivant les rôles de la personne
connectée.
31
5.5. Diagramme de navigation Gestion des utilisateurs
Figure 16 Diagramme de navigation : Gestion des utilisateurs
6. Diagramme de déploiement
Le diagramme de déploiement [1] est une vue statique qui sert à représenter l'utilisation de
l'infrastructure physique par le système et la manière dont les composants du système sont
répartis ainsi que leurs relations entre eux. Les éléments utilisés par un diagramme de
déploiement sont principalement les nœuds, les composants, les associations et les artefacts.
Ci-dessous le diagramme de déploiement relatif à l’architecture physique mise en place.
32
Figure 17 Diagramme de déploiement
Conclusion
Dans ce chapitre j’ai tout d’abord décrit la méthodologie de travail utilisée pour la réalisation
de ce travail, puis j’ai fait une brève description du langage utilisé pour l’étape de la
conception, et finalement on a élaboré les différents diagrammes qui vont nous aider à
modéliser le système à mettre en place.
33
Rapport de stage Aspect technique
Chapitre IV Aspect technique
Ce chapitre présente les spécifications techniques à
savoir l’architecture, les Frameworks ainsi que les
outils utilisés pour le développement.
34
1. Spécification technique
L'étude technique consiste à mener une analyse des besoins techniques, puis trouver une
implémentation qui répond à ces besoins indépendamment des choix fonctionnels. Ce chapitre
fera donc l'objet de capture des besoins techniques et présentera ensuite la conception
générique qui décrit la solution adoptée.
1.1. MVC
Le pattern MVC [2] est un modèle de conception pour le développement d'applications
logicielles qui sépare le modèle de données, l'interface utilisateur et la logique du contrôle.
Ce modèle d'architecture impose la séparation entre les données, les traitements et la

présentation, ce qui donne 3 parties fondamentales dans l'application finale: le modèle, la vue
et le contrôleur.
 Le modèle représente le comportement de l'application : traitement des données,

interaction avec la base de données etc. Il décrit les données manipulées par l'application
et définit les méthodes d'accès.
 La vue correspond à l'interface avec laquelle l'utilisateur interagit. Les résultats renvoyés
par le modèle sont dénués de toute présentation mais sont présentés par la vue. Plusieurs
vues peuvent afficher les informations d'un même modèle.
 Le contrôleur prend en charge la gestion des événements de synchronisation pour mettre
à jour la vue ou le modèle et les synchroniser. Il reçoit tous les événements de l'utilisateur
et enclenche les actions à effectuer.
35
Figure 18 Pattern MVC
1.2. Architecture 3-tiers

L'architecture 3-tiers [1] est un modèle logique d'architecture applicative qui vise, à séparer
très nettement trois couches logicielles au sein d'une même application ou système, à
modéliser et à présenter cette application comme un empilement de trois couches, étages,
niveaux dont le rôle est clairement défini :
 La présentation des données : correspondant à l'affichage, la restitution sur le poste de

travail, le dialogue avec l'utilisateur ;
 Le traitement métier des données : correspondant à la mise en œuvre de l'ensemble des
règles de gestion et de la logique applicative ;
 En fin, l’accès aux données persistantes : correspondant aux données qui sont destinées à
être conservées sur la durée, voire de manière définitive. Dans cette approche, les
couches communiquent entre elles au travers d'un « modèle d'échange », et chacune
d'entre elles propose un ensemble de services rendus.
Ce modèle d'architecture 3-tiers a pour objectif de répondre aux préoccupations suivantes :
 Allègement du poste de travail client ;

 Prise en compte de l'hétérogénéité des plateformes (serveurs, clients, langages, etc.) ;
36
 Amélioration de la sécurité des données, en supprimant le lien entre le client et les

données. Le serveur a pour tâche, en plus des traitements purement métiers, de vérifier
l'intégrité et la validité des données avant de les envoyer dans la couche de données ;
 Rupture du lien de propriétés exclusives entre application et données. Dans ce modèle, la
base de données peut être plus facilement normalisée et intégrée à un Entrepôt de
données
 Et enfin, meilleure répartition de la charge entre différents serveurs d'application.
L’architecture ci-dessus permet d’avoir une indépendance entre les différentes couches, grâce
à la façade qui nous permet de changer de la technologie tout en conservant le métier intact.
Couche présentation: Elle correspond à la partie de l'application visible et interactive

avec les utilisateurs. On parle d'interface Homme Machine. Elle peut être réalisée par une
application graphique ou textuelle. Elle peut aussi être représentée en HTML pour être
exploitée par un navigateur web ou en WML pour être utilisée par un mobile.
Couche métier (service): Elle correspond à la partie fonctionnelle de l'application, celle

qui implémente la logique et qui décrit les opérations que l'application opère sur les données
en fonction des requêtes des utilisateurs, effectuées au travers de la couche présentation. Les
différentes règles de gestion et de contrôle du système sont mises en œuvre dans cette couche.
La couche métier offre des services applicatifs et métiers à la couche présentation. Pour
fournir ces services, elle s’appuie, le cas échéant, sur les données du système, accessibles au
travers des services de la couche inférieure. En retour, elle renvoie à la couche présentation
les résultats qu’elle a calculés.
Couche accès aux données : Elle consiste en la partie gérant l'accès aux gisements de
données du système. Cette couche gère l’accès et la sauvegarde des données. Elle
communique avec la couche
Service en utilisant les objets du domaine. Elle renvoie à la couche Service les objets métier
construits à partir des données de la base. Elle persiste dans la base de données les objets
qu’elle obtient de la couche Service. La couche persistance regroupe les éléments suivants :
 Des services qui proposent des méthodes CRUD (Create, Retrieve, Update, Delete)
pour manipuler les entités.
 Utilisation des API de mapping Objet / Relationnel.
37
2. Technologies utilisée
2.1. Framework Symfony 2.3

Symfony [3] est un Framework MVC libre écrit en PHP 5. En tant que Framework, il facilite
et accélère le développement de sites et d'applications Internet et Intranet de façon structurée
et avec un code clair et maintenable.
2.2. Les fonctionnalités de Symfony 2.3

 Une séparation du code en trois couches, selon le modèle MVC, pour une plus
grande maintenabilité et évolutivité
 Un templating simple, basé sur PHP et des jeux de "Helpers", ou fonctions
additionnelles pour les gabarits : Twig
 Des performances optimisées et un système de cache pour garantir des temps de
réponse optimums
 Une gestion des url parlantes, qui permet de formater l'url d'une page
indépendamment de sa position dans l'arborescence fonctionnelle : Routing
 Un système de configuration en cascade qui utilise de façon extensive le langage
YAML
 Un générateur de back-office
 Un support de l'internationalisation - Symfony est nativement multi-langue
 Une couche de Mapping Objet-Relationnel (ORM) et une couche d'abstraction de
données
 Le support de l'Ajax
 Une architecture extensible, permettant la création et l'utilisation de plugins
La qualité du code de Symfony le rend très adaptable :
 Le code est découplé

 La configuration en cascade application / module permet de
personnaliser simplement de nombreux paramètres
Toutefois, pour développer avec Symfony, l'utilisation de la ligne de commande est

obligatoire.
38
2.3. Pourquoi Symfony 2.3 ?

Symfony [4] est un ensemble d’outils PHP, un environnement de travail qui permet de
développer plus rapidement et plus proprement.
En plus de fournir une librairie très riche, il fournit également la possibilité de générer un
squelette de site internet, des classes et une base de données à partir d’une seule ligne de
commande.
Symfony permet de développer en MVC en séparant bien les 3 couches. Il fournit aussi la
possibilité de faire des tests unitaires, des tests fonctionnels, gérer l’internationalisation
facilement, utiliser des fichiers de configurations facilement, faire de l’url rewriting…et bien
d’autres fonctionnalités.
Il permet tout simplement de gagner du temps (et donc de l’argent) sur la mise en place des
projets web, et aussi sur leurs maintenance car le code est plus facilement modifiable et mieux
structuré ce qui permet de pouvoir faire évoluer les sites plus facilement.
2.4. Le fonctionnement de Symfony 2.3

Chaque élément du site est découpé en modules, appelés Bundles. Chaque Bundle contient les
vues (pour l’affichage pur), les contrôleurs (chargés de toute la partie logique) et les entités
(toutes les données de la base de données sous forme d’objets PHP). On y trouve également
des fichiers de configuration, de traduction et d’autres utilitaires bien pratiques.
Cette architecture est utilisée par le Framework lui-même pour séparer ses éléments de
fonctionnement.
Tout est fait pour fonctionner au plus bas niveau possible, c’est à dire depuis la requête http
jusqu’au rendu de la page dans le navigateur.
2.5. Le Design Pattern MVC en Symfony 2.3
 Le modèle
Le modèle représente le comportement de l'application : traitements des données, interactions
avec la base de données, etc. Il décrit ou contient les données manipulées par l'application. Il
assure la gestion de ces données et garantit leur intégrité. Dans le cas typique d'une base de
données, c'est le modèle qui la contient. Le modèle offre des méthodes pour mettre à jour ces
39
données (insertion, suppression, changement de valeur). Il offre aussi des méthodes pour
récupérer ces données. Les résultats renvoyés par le modèle sont dénués de toute présentation
 La vue
La vue correspond à l'interface avec laquelle l'utilisateur interagit. Sa première tâche est de
présenter les résultats renvoyés par le modèle. Sa seconde tâche est de recevoir toutes les
actions de l'utilisateur (clic de souris, sélection d'une entrée, boutons, etc). Ces différents
événements sont envoyés au contrôleur. La vue n'effectue aucun traitement, elle se contente
d'afficher les résultats des traitements effectués par le modèle et d'interagir avec l'utilisateur.
 Le contrôleur
Le contrôleur prend en charge la gestion des événements de synchronisation pour mettre à
jour la vue ou le modèle et les synchroniser. Il reçoit tous les événements de l'utilisateur et
enclenche les actions à effectuer. Si une action nécessite un changement des données, le
contrôleur demande la modification des données au modèle, et ce dernier notifie la vue que
les données ont changée pour qu'elle se mette à jour.
D'après le patron de conception observateur/observable, la vue est un "observateur" du

modèle qui est lui "observable". Certains événements de l'utilisateur ne concernent pas les
données mais la vue. Dans ce cas, le contrôleur demande à la vue de se modifier. Le
contrôleur n'effectue aucun traitement, ne modifie aucune donnée. Il analyse la requête du
client et se contente d'appeler le modèle adéquat et de renvoyer la vue correspondant à la
demande.
40
Figure 19 Implémentation du pattern MVC par Symfony2.3
2.6. Décomposition fonctionnelle de l’application
 Le routeur de Symfony
Le but du routeur [3] est de trouver la route correspondante à partir d'une URL, puis de
retourner le contrôleur que veut cette route.
Pour trouver la bonne route, le routeur va les parcourir une par une, dans l'ordre du fichier, et
s'arrêter à la première route qui fonctionne :
41
Figure 20 Fonctionnement du routeur Symfony
Voici un aperçu du routeur de l’application :
Figure 21 Aperçu du routeur de l'application
42
 La couche de persistance (O.R.M.) : Doctrine
ORM (Object-Relational Mapping) [3], désigne la concordance entre les tuples du modèle
relationnel de la base de données et les classes équivalentes de l'application (les
DataBaseObject).
Doctrine est une bibliothèque d'ORM pour PHP. Elle repose sur l'extension PDO. Elle permet
une génération totale de la base de données en se reposant sur les classes et leurs associations.
Toutefois pour avoir un schéma cohérent il faudrait maîtriser et optimiser la conception de
son système d’information.
Le service Doctrine de Symfony est celui qui va permettre de gérer la persistance des objets.
Ce service est accessible depuis le contrôleur comme n'importe quel service : $doctrine =
$this->get('doctrine');
Ou encore : $doctrine = $this->getDoctrine;
Ce service permet de gérer 2 choses :
 Les différentes connexions à des bases de données. C'est la partie DBAL de

Doctrine2. En effet on peut tout à fait utiliser plusieurs connexions à plusieurs bases
de données différentes. Cette partie DBAL permet à Doctrine2 de fonctionner sur
plusieurs types de SGBDR, tels que MySQL, PostgreSQL, etc.
 Les différents gestionnaires d'entités, ou EntityManager. C'est la partie ORM de
Doctrine2.
Doctrine permet d’utiliser plusieurs gestionnaires d'entités, ne serait-ce qu'un par
connexion ! Le service dispose donc, entre autres, de la méthode dont nous nous
servirons beaucoup : $doctrine- >getEntityManager($name) qui permet de
récupérer un ORM à partir de son nom.
Doctrine met à disposition également un langage d’interprétation de requêtes SQL sous le

nom de DQL :
Doctrine Query Language qui permet de faciliter la manipulation des données avec une
syntaxe très proche du langage SQL.
 Le moteur de Template : Twig
Les templates [3] permettent de séparer le code PHP du code HTML. Seulement, pour faire
du HTML de présentation, on a toujours besoin d'un peu de code dynamique : comme par
43
exemple faire une boucle ou créer des conditions, etc... Pour faciliter ce code dynamique dans
les templates, le moteur de template Twig offre son pseudo-langage à lui. Ça n'est pas du
PHP, mais c'est plus adapté et voici pourquoi :
" La syntaxe est plus concise et plus claire. Par exemple pour afficher une
variable, {{ mavar }} suffit, alors qu'en PHP, il faudrait faire <?php echo $mavar; ?>.
" Il y a quelques fonctionnalités en plus, comme l'héritage de templates. Cela serait bien
entendu possible en PHP.
" Il sécurise vos variables automatiquement : plus besoin de se soucier de <?php htmlentities()
ou <?php addslashes().
" Il dispose de différents filtres facilitant la manipulation des données affichées tels que :
{{ user.lastLogin | date('d/m/Y') }} ou {{ var | upper }}
 L’héritage des template
L’héritage est très utile dans le cas ou l’on dispose d’une Template mère qui contient le
design de l’application, ou l’on doit définir des blocs (appelés blocks en anglais) qui vont être
alimentés par les Templates filles. Les filles vont donc hériter de la mère en remplaçant
certains éléments par leur propre contenu.
L'avantage est que les Templates filles peuvent modifier plusieurs blocs de la Template mère.
{% extends "EricssonGestionBundle:layout.html.twig" %}
{% block body %}
{% endblock %}
 L’inclusion des templates :

L’inclusion est par ailleurs utilisée dans le cas de code répétitif afin d’éviter le copier/coller
du même code, l’inclusion permet d’écrire le code une seule fois et de l’inclure dans les
différents emplacements ou l’on désire le mettre.
{% include "EricssonGestionBundle::header.html.twig" %}
 Gestion de la sécurité : FOSUserBundle
FOSUserBundle [5], développé par le groupe « Friends Of Symfony » est un bundle

permettant une gestion aisée des utilisateurs et de leurs droits. Il offre des fonctionnalités
44
avancées permettant l’ajout des utilisateurs, l’affectation des rôles, la génération de formulaire
d’inscription, de modification de profiles, persistance en base de données avec des
mécanismes avancés d’authentification utilisant le cryptage des mots de passe.
FOSUserBundle utilise le pare-feu Symfony pour contrôler l’accès aux pages, muni d’un
mécanisme de vérification des rôles pour juger de l’accessibilité de l’utilisateur à l’url
demandé.
Figure 22 Aperçu du fichier security.yml
Et pour qu’il puisse être reconnu, l’enregistrement fos_user_security [6] s’ajoute au fichier
routing.yml, pour que le routage puisse prendre en considération les privilèges et rôles des
utilisateurs comme le montre la figure 19 précédemment montrée, elle contient les
enregistrements générés par FOSUserBundle lors de son implémentation.
45
 Les graphes : ObHighchartsBundle

ObHighchartsBundle facilite l'utilisation de Highcharts pour afficher des graphes riches dans
une application Symfony2.3 en fournissant des extensions Twig et des objets. L'ensemble
utilise l'excellente librairie HighchartsJS. Ci-dessous un appaercus de l’utilisation d’un objet
fourni par ce bundle.
Figure 23 Aperçu d'utilisation d'objet Highcharts
3. Outils utilisés
L’application est développée avec le framework Symfony 2.3 qui est basé sur le langage
PHP. Elle est connectée à un serveur de base de données utilisant le SGBD MySQL.
Pour la phase de test et de développement on a utilisé le serveur WAMP, pour la production

l’application sera hébergée dans un serveur interne fonctionnant sous Apache.
L’application utilise une Template Admire, cette dernière a été intégrée en utilisant
HTML5, CSS3 et jQuery.
Pour les fichiers de configuration Symfony elles utilisent le format XML ou souvent YAML
puisque ce dernier demeure le plus utilisé vu la meilleure organisation visibilité et qu’il offre
3.1. PHP
PHP (Hypertext Preprocessor) [7], est un langage de scripts libre principalement utilisé pour
produire des pages Web dynamiques via un serveur HTTP, mais pouvant également
fonctionner comme n'importe quel langage interprété de façon locale, en exécutant les
programmes en ligne de commande. PHP est un langage impératif disposant depuis la version
46
5 de fonctionnalités de modèle objet complètes. En raison de la richesse de sa bibliothèque, on

désigne parfois PHP comme une plate-forme plus qu'un simple langage.
Le langage PHP est utilisé principalement en tant que langage de script côté serveur, ce qui
veut dire que c'est le serveur (la machine qui héberge la page Web en question) qui va
interpréter le code PHP et générer du code qui pourra être interprété par un navigateur.
C'est un langage peu typé et souple et donc facile à apprendre par un débutant, il ne
s'encombre pas de théorie et a tendance à choisir le chemin le plus direct.
3.2. MySQL
MySQL [1] est un système de gestion de base de données (SGBD). Selon le type
d'application, sa licence est libre ou propriétaire. Il fait partie des logiciels de gestion de base
de données les plus utilisés au monde, autant par le grand public (applications web
principalement) que par des professionnels. Il est en concurrence avec Oracle 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.
3.3. HTML5
HTML (Hypertext Markup Language) [7], est le format de données conçu pour représenter
les pages web. C’est un langage de balisage qui permet d’écrire de l’hypertexte, d’où son
nom. HTML permet également de structurer sémantiquement et de mettre en forme le contenu
des pages, d’inclure des ressources multimédias dont des images, des formulaires de saisie, et
des éléments programmables tels que des applets. Il permet de créer des documents
interopérables avec des équipements très variés de manière conforme aux exigences de
l’accessibilité du web. Il est souvent utilisé conjointement avec des langages de
programmation (JavaScript) et des formats de présentation (feuilles de style en cascade).
La version HTML5 est la prochaine révision majeure d'HTML (format de données conçu pour
représenter les pages web). Cette version est en développement en 2012. HTML5 spécifie
deux syntaxes d'un modèle abstrait défini en termes de DOM : HTML5 et XHTML5. Le
langage comprend également une couche application avec de nombreuses API, ainsi qu'un
algorithme afin de pouvoir traiter les documents à la syntaxe non conforme.
47
3.4. CSS3
CSS (Cascading Style Sheets : feuilles de style en cascade) [7] est un langage informatique
qui sert à décrire la présentation des documents HTML et XML. Les standards définissant
CSS sont publiés par le World Wide Web Consortium (W3C). Introduit au milieu des années
1990, CSS devient couramment utilisé dans la conception de sites web et bien pris en charge
par les navigateurs web. Le développement du troisième niveau des feuilles de styles en
cascade commence dès 1999.
CSS3 devient « modulaire », afin de faciliter ses mises à jour, mais aussi son implémentation
par des agents utilisateurs aux capacités et aux besoins de plus en plus variés (navigateurs
graphiques, navigateurs pour mobiles, navigateurs vocaux). Les navigateurs peuvent ainsi
implémenter des sous ensembles de CSS3.
Parmi les enjeux du CSS3 on peut citer :
 Permettre la séparation de la structure d'un document de ses styles de présentation.

 Décliner les styles de présentation selon le récepteur et Permettre la cascade des
styles.
3.5. JavaScript
JavaScript [7] est un langage de programmation de scripts principalement utilisé dans les
pages web interactives mais aussi côté serveur1. C'est un langage orienté objet à prototype,
c'est-à-dire que les bases du langage et ses principales interfaces sont fournies par des objets
qui ne sont pas des instances de classes, mais qui sont chacun équipés de constructeurs
permettant de créer leurs propriétés, et notamment une propriété de prototypage qui permet
d'en créer des objets héritiers personnalisés.
Le propos de JavaScript est de manipuler de façon simple des objets, au sens informatique,
fournis par une application hôte.
3.6. jQuery
jQuery [7] est une bibliothèque JavaScript libre qui porte sur l'interaction entre JavaScript
(comprenant Ajax) et HTML, et a pour but de simplifier des commandes communes de
JavaScript. La première version date de janvier 2006.
48
jQuery se présente comme un unique fichier JavaScript de 247 Kio (92,2 Kio dans sa version
minimalisée par la suppression des commentaires et caractères d’espacements) contenant
toutes les fonctions de base.
jQuery contient notamment les fonctionnalités suivantes :
 Parcours et modification du DOM (y compris le support des sélecteurs CSS 1 à 3 et un

support basique de Xpath).
 Événements.
 Effets et animations.
 Manipulations des feuilles de style en cascade (ajout/suppression des classes,
d’attributs).
 Ajax.
 Plugins.
 Utilitaires (version du navigateur).
3.7. YAML
YAML, acronyme récursif de « Ain't Markup Language » [1], est un langage de sérialisation
en données Unicode. Il reprend des concepts d'autres langages comme XML, ou encore du
format de message électronique tel que documenté par RFC 2822.
L'idée de fond de YAML est que toute donnée peut être représentée par une combinaison de
listes, tableaux (de hachage) et données scalaires. YAML décrit ces formes de données (les
représentations
YAML), ainsi qu'une syntaxe pour présenter ces données sous la forme d'un flux de caractères
(le flux YAML).
La syntaxe du flux YAML est relativement simple et efficace, moins verbeuse que du XML,
moins compacte que du CSV, et a été établie de sorte qu'elle soit le plus lisible possible par
des humains, tout en pouvant être mise en correspondance facilement avec les types de
données précités, communs dans les langages de haut niveau. À ces langages il emprunte
certaines notations.
3.8. Visual Paradigm

Visual Paradigm for UML [8] est un logiciel permettant aux programmeurs de mettre en place
des diagrammes UML. Disposant d'un outil créant des rapports personnalisables aux formats
49
PDF, Word ou HTML afin de les partager et les publier sur Internet, cette application est
compatible avec de nombreuses applications, standards et environnements. Ainsi, vous
pourrez générer notamment des diagrammes de séquences ou de cas d'utilisation et ainsi
produire du code source dans de nombreux langages comme le Java ou encore le C++, ou
bien faire l'inverse, générer des diagrammes à partir de code déjà existant.
4. L’architecture des fichiers

Ci -dessous l’architecture des fichiers du projet :
Figure 24 L'architecture globale des fichiers du projet Symfony
Conclusion
Dans ce chapitre j’ai présenté l’architecture mise en place, les Framework implémentés ainsi
que les outils utilisés pour la réalisation du projet.
50
Rapport de stage Réalisation
Chapitre V Réalisation
Ce chapitre présente la partie de réalisation de
l’application par le biais de prises d’écrans depuis un
écran d’ordinateur, celui d’une tablette puis d’un
appareil mobile.
51
1. Page d’accueil
La page d’accueil de l’application est la page d’authentification. Après s’être authentifié
l’utilisateur est redirigé vers la page principale de l’application, qui, selon ses privilèges, offre
plusieurs fonctionnalités de gestion back-office.
Cette page d’authentification est accessible pour tous les utilisateurs et représenté dans la
figure ci-dessus prise a partir d’un écran 15 pouces :
Figure 25 Aperçu de la page d'authentification depuis un écran de 15°
Le Template utilisé est un Template responsive, pouvant s’adapter à différentes largeurs

d’écrans pour une meilleure visibilité et ergonomie dans tous les périphériques.
52
Puis la même page à partir d’un écran 4 pouces :
Figure 26 Page d'authentification depuis un écran mobile
2. Gestion des sites réseaux

Pour pouvoir accéder à la gestion des sites réseaux, l’utilisateur clique sur le volet « Manage
sites » dans la barre de menu gauche, cet utilisateur doit disposer au minimum du rôle
Responsable.
La page dédiée Responsables est composée du menu de navigation dans la barre gauche, puis
offre la liste des sites réseaux, munie d’un champ de recherche global qui permet de chercher
le mot clé saisi dans tous les champs des enregistrements affichés.
53
Pour chaque enregistrement correspondent plusieurs actions possibles, une icône « show »
permet d’afficher les détails du site réseau, une icône « edit » permet d’afficher un formulaire
de modification.
Ci-dessous un aperçu de la gestion des sites réseaux offerte par l’application.
Figure 27 Aperçu de la page principale de la gestion des sites réseaux
Cette page met également à disposition un bouton d’ajout d’un nouvel enregistrement, et un
bouton affichant la totalité des sites réseaux ainsi qu’un bouton pour chaque site réseau qui
permet d’afficher les stations reliées a ce dernier.
3. Gestion des stations réseaux

Pour pouvoir accéder à la gestion des stations réseaux, l’utilisateur clique sur le volet
«Manage stations» dans la barre de menu gauche, cet utilisateur aussi doit disposer au
minimum du rôle Responsable.
La page dédiée Responsables est composée du menu de navigation dans la barre gauche, puis
offre la liste des stations réseaux, munie aussi d’un champ de recherche global.
Pour chaque enregistrement correspondent plusieurs actions possibles, une icône « show »
permet d’afficher les détails du site réseau, une icône « edit » permet d’afficher un formulaire
de modification.
54
Ci-dessous un aperçu de la gestion des stations réseaux offerte par l’application.
Figure 28 Aperçu de la page principale de la gestion des stations réseaux
4. Gestion des utilisateurs

La page d’ajout d’un nouvel utilisateur est accessible uniquement pour les utilisateurs ayant
comme rôle celui d’Administrateur « Admin ».
L’administrateur renseigne le nom d’utilisateur, le mot de passe, l’email et affecte le rôle

adéquat. Ci-dessous la page d’ajout d’un nouvel utilisateur :
55
Figure 29 Aperçu de la page dédiée à l'ajout d'un nouvel utilisateur
5. Privilège d’accès
Si un utilisateur n’ayant pas suffisamment de privilèges tente d’accéder à une page réservée à
des utilisateurs ayant des rôles supérieurs, il est redirigé à une page d’erreur, en voici un
aperçu :
Figure 30 Aperçu de la page d'erreur relative au manque de privilèges d'accès
56
Conclusion
Dans ce chapitre j’ai présenté par le biais d’imprimés écrans quelques uns parmi les différents
volets dont dispose l’application, en mettant l’accent sur les restrictions d’accès qui reposent
sur les privilèges de chaque utilisateur.
57
Conclusion générale
Ce rapport entre dans le cadre de mon stage de 4 éme année. Le projet a été réalisé
au sein de la société ERICSSON. Il consiste à la conception et la réalisation
d’un système de gestion et suivi des sites réseaux.
Ma mission dans le cadre de ce projet a été déclinée en cinq grandes phases.

Dans une première, on a décrit le contexte général du projet, après, une étude
fonctionnelle a été menée qui comprend d’abord la spécification des besoins
fonctionnels, qui ont ensuite donné lieu à l’étape d’analyse et conception du
système ayant pour but de fournir une image prête à coder de l’application. La
quatrième phase a consisté en une étude technique qui comprend d’abord la
capture des besoins techniques. Et enfin, la dernière phase a été consacrée à la
réalisation de l’application.
Comme perspective, il serait intéressant de travailler sur d’autres indicateurs

pour enrichir le tableau de bord, d’ajouter des notifications des problèmes
survenus dans une station, mettre en place un module de gestion du stock des
équipements, suivre une méthodologie de travail agile.
58
Apports de stage
Durant ce stage, j’ai pu tirer tout un ensemble de savoirs et savoir-faire
nécessaires à l'exercice du métier de développement. J’ai appris à m’adapter à
des nouvelles méthodes dans les domaines de développement et à l’organisation
du temps consacré pour cela.
Sur le plan personnel, ce projet fut un véritable test de mes capacités à résoudre
d’une façon autonome, les problèmes posés jour après jour et de mon aptitude à
assumer les responsabilités qui m’ont été confiées.
Ce stage m’a été d’une grande opportunité pour maitriser l’utilisation de

nouvelles technologies et ainsi contribuer au développement d’une application
qui répond aux besoins. Ce qui va incontestablement renforcer mon parcours
professionnel, ce stage m’a également offert l’opportunité de développer de
nouvelles aptitudes d’adaptation à des projets ayant des besoins incrémentales et
dont le cahier de charge peut varier avec le temps.
Pour conclure, j’espère avoir répondu aux attentes de la société et avoir été à la
hauteur de la confiance qu’ils m’ont témoignée.
59
Références
[1] http://www.wikipedia.org, consulté le 10 juillet 2014.
[2] http://dico.developpez.com/html/3020-Conception-MVC-Model-View-
Controller.php, consulté le 12 juillet 2014.
[3] http://fr.openclassrooms.com/informatique/cours/developpez-votre-site-web-avec-
leframework- symfony2, consulté le 12 juillet 2014.
[4] http://www.symfony.com, consulté le 20 juillet 2014.
[5] https://github.com/FriendsOfSymfony/FOSUserBundle, consulté le 15 out 2014.
[6] http://www.grafikart.fr/tutoriels/symfony/gestion-user-fosuserbundle-383, consulté

le 15 out 2014.
[7] http://www.w3schools.com, consulté le 19 out 2014.
[8] http://www.visual-paradigm.com, consulté le 20 out 2014.
[9] http://www.hightcharts.com, consulté le 28 out 2014.
60

Langue

Rapport de Stage Ericsson PDF

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 de Stage Ericsson PDF

Titre original :

Transféré par

Droits d'auteur :

Formats disponibles

Titres liés

Rapport de stage

« Conception et réalisation d’un système

Réalisé par : Encadré par :

Année universitaire 2013-2014

A tout le personnel de l’EMSI :

Avant tout développement sur le projet je souhaite commencer ce

Je tiens à remercier tout particulièrement et à témoigner toute ma

Le projet que présente ce document s’inscrit dans le cadre du stage de

Le but de ce stage est la conception et la réalisation d’système de

Cette mise en place a pour but l’amélioration de la performance de la

The project presented in this document is part of the traineeship of the

The purpose of this traineeship is the conception and realization of a

This set up aims to improve the performance of the company with

Table des figures

Liste des tableaux

2. Présentation du sujet ___________________________________________________ 4

2. Déroulement du projet __________________________________________________ 9

Chapitre III Analyse et conception ___________________________________________ 11

2. Diagramme de contexte ________________________________________________ 12

5. Entité de Gestion des utilisateurs : _______________________________________ 25

5.4. Diagramme de classes _____________________________________________________________ 31

6. Diagramme de déploiement _____________________________________________ 32

2. Technologies utilisée ___________________________________________________ 38

3. Outils utilisés _________________________________________________________ 46

4. L’architecture des fichiers ______________________________________________ 50

En raison de l’importance de ses missions, Ericsson se trouve au cœur du marché de

Chapitre I Contexte Général du projet

Ce chapitre a pour objectif de situer le projet dans

son contexte général. La première section est dédiée

à la présentation de l’organisme d’accueil ERICSSON,

la deuxième section discute la problématique et

expose le sujet du projet.

1. Présentation de l’organisme d’accueil

1.1. Les services offerts par ERICSSON

1.2. Situation et axes forts d’ERICSSON

Media Management, IPTV, ICT, IT, IP, programme de responsabilité, développement

Chapitre II Etude préliminaire et

Ce chapitre vise à décrire le projet et ses objectifs.

Ensuite, les différentes fonctionnalités que

l’application doit assurer, la méthodologie du travail,

puis une dernière partie dédiée au planning du projet.

1. Cadre général du projet

- Difficulté de mise au point des situations des sites réseaux.

- Difficultés de suivi de sites réseaux, de mise au point de l’état actuel.

- Gestion manuelle des informations.

- Absence de gestion d’utilisateurs et d’autorisations.

- Absence de traçabilité et de supervision.

- Absence de tableau de bord.

 L’application doit être accessible par plusieurs acteurs distincts.

1.4. Étude fonctionnelle

 Principaux besoins fonctionnels

Ce module comprendra principalement les fonctionnalités présentes :

 Tableau de bord offrant une visibilité globale de l’état des sites.

 L’utilisateur peut également lister les antennes et équipement de cette

 Besoins non fonctionnels

L'application doit être fonctionnelle indépendamment de toutes circonstances pouvant

2.1. Diagramme de Gantt

Le diagramme de GANTT est un diagramme permettant de modéliser la planification des

Les deux figures ci-dessous montrent le planning du déroulement du stage :

Figure 1 Diagramme de Gant 1