UNIVERSITÉ MOHAMMED V de Rabat

Faculté des Sciences

DÉPARTEMENT INFORMATIQUE
Filière Licence fondamentale
en Sciences Mathématiques et Informatique

PROJET DE FIN D’ÉTUDES

Application web pour la gestion des compétitions

d’algorithmes d’optimisation combinatoire

Présenté par : - Majda Athmani

- Ali Goumanneh Darar

Soutenu le 17 Juin 2016 devant le jury :

Mr.AHIOD BelaÏd Professeur à la FSR Encadrant

Mme.ELKHATTABI Noussaima Professeur à la FSR Examinatrice

Année universitaire 2015/2016

 Remerciements
Au terme de ce travail, nous tenons tout d’abord à remercier :

Dieu de nous avoir donné le courage, la force et la volonté pour

achever ce modeste travail.

Notre encadrant Monsieur le professeur AHIOD BelaÏd pour son en-

cadrement, ses remarques constructives tout le long de notre travail.

Ainsi que les doctorants Mr EL KRARI Mehdi et Mr EL YAFRANI

Mohamed, pour leurs qualités professionnelles, leurs conseils et la
confiance qu’ils nous ont accordé tout au long de ce travail.

Nous remercions également le jury qui a bien examiné notre travail,

aussi bien toute l’équipe pédagogique de la faculté des sciences de
rabat

Finalement nous tenons à remercier nos parents pour leur soutien

inconditionnel dont ils ont fait preuve depuis que notre projet est
défini, merci pour leur soutien financier, moral, psychologique et ma-
tériel. Si on est ici aujourd’hui, c’est grâce à eux !

i
RESUME
Ce travail s’inscrit dans le cadre de l’accomplissement de notre projet de fin
d’études à la faculté des sciences de rabat.
Le sujet de notre projet est une application web pour la gestion des compétitions
d’algorithmes d’optimisation combinatoire.
Pour réaliser ce travail, nous allons utiliser le langage PHP avec le Framework
Symfony2. Notre application permet à un utilisateur de participer à des com-
pétitions de son choix.
L’objectif de ce travail est de faire la gestion des participants, des responsables
et des compétitions. Tout cela se fait par l’Administrateur de notre application.

Mots clés : PHP, Symfony Framework, WampServer, Doctine, Twig, Modelio,

ii
ABSTRACT

This work is part of the fulfillment of our final project studies in the Faculty
of Science flap.
The subject of our project is a web application for managing competitions com-
binatorial optimization algorithms.
To make this work, we will use PHP with Symfony2 Framework. Our applica-
tion allows a user to participate in competitions of their choice.
The objective of this work is to make the management of participants, officials
and competitions. All this is done by the Administrator of our application

key words : PHP, Symfony Framework, WampServer, Doctine, Twig, Modelio,

iii
Table des matières
Remerciement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . i
Resumé . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ii
Abstract . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . iii
Liste des figures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . vi
Liste des tableaux . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . vii
Introduction Générale . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1

Chapitre 1 : Contexte de projet et cahier de charge . . . . . . . . . . . . . . 2

1.1-Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.2-Contexte . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.3-Présentation de sujet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.4-Objectifs de l’application . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.5-Approche du travail . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.6-Methodologie et formalismes adoptés . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.7-Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

Chapitre 2 : Analyse et spécification des besoins . . . . . . . . . . . . . . . . 13

2.1-Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.2-Présentation des acteurs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.3-Identification de fonctionnalité par acteur . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.4-Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

Chapitre 3 : Conception de l’application . . . . . . . . . . . . . . . . . . . . . . . . . 10

3.1-Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .10
3.2-Phase d’expression des besoins . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
3.2.1-Diagramme de cas d’utilisation générale . . . . . . . . . . . . . . . . . . . . . . . . . 11
3.2.2-Diagramme de cas d’utilisation relatif à un utilisateur . . . . . . . . . . . 12
3.2.3-Diagramme de cas d’utilisation relatif à un responsable . . . . . . . . . . 14
3.2.4-Diagramme de cas d’utilisation relatif à un administrateur . . . . . . 16

3.3-Conception de la vue dynamique . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

3.3.1-Description de classe : diagramme de Classe . . . . . . . . . . . . . . . . . . . . . 18
3.3.2-Diagramme de séquence relatif à une compétition . . . . . . . . . . . . . . . 21

3.4-Description de la base de données . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

3.4.1-Descriptions des tables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

iv
 3.4.2-Modèle logique de données (MRD) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
3.4.3-Règle de gestion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

3.5-Comportement dynamique de l’application . . . . . . . . . . . . . . . . . . . . . . . . . 28

3.5.1-Gérer les utilisateurs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
3.5.2-Gérer les droits d’accès . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .28
3.5.3-Attribuer un responsable à une compétition . . . . . . . . . . . . . . . . . . . . . 28
3.6-Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

Chapitre 4 : Réalisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
4.1-introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
4.2-Environnement matériel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
4.3-Environnement logiciel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
4.4-Langages utilisés . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
4.5-Principales interfaces graphiques . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .38
4.5.1-Authentification et Inscription . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
4.5.2-Espace <Utilisateur> . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
4.5.3-Espace <Responsable> . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
4.5.4-Espase <Administrateur> . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
4.6-Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44

Conclusion Générale . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
Webographie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46

v
 Liste des figures
1.1-Cycle resumant la structure du travail . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
3.1 Diagramme de cas d’utilisation générale . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
3.2 Diagramme de cas d’utilisation d’un utilisateur . . . . . . . . . . . . . . . . . . . . . . . . . 12
3.3 Diagramme de cas d’utilisation du responsable . . . . . . . . . . . . . . . . . . . . . . . . . 14
3.4 Diagramme de cas d’utilisation de l’administrateur . . . . . . . . . . . . . . . . . . . . .16
3.5 Diagramme de classe générale . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .19
3.6 Diagramme de séquence relatif à une compétition . . . . . . . . . . . . . . . . . . . . . . 22
3.7 Table Utilisateur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
3.8 Table Competition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .24
3.9 Table Inscription . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
3.10 Table Algorithme . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
3.11 Table Executable . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
4.1 logo de Symfony2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
4.2 le model de fonctionnement du MVC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
4.3 logo de doctrine . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
4.4 logo de TWIG . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
4.5 logo de WampServer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
4.6 logo de Modelio . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
4.7 logo de Latex . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
4.5.1 Interface d’Authentification et Inscription . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
4.5.2 Interface Utilisateur 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
4.5.3 Interface Utilisateur 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
4.5.4 Interface Responsable 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
4.5.5 Interface Responsable 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
4.5.6 Interface Administrateur 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
4.5.7 Interface Administrateur 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44

vi
 Liste des tableaux
2.1 Acteurs du système . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

vii
 Introduction générale
Depuis quelques années, les innovations dans le domaine de développe-
ment web se multiplient et évoluent sans cesse. De ce fait les entreprises sont
amenées à avoir un site, qui les présente auprès de leurs clients ainsi qu’auprès
des autres personnes, montrant leurs fonctionnalité et éventuellement leurs nou-
velles offres.

Notre projet consiste à concevoir une application web pour la gestion des
compétitions d’algorithmes d’optimisation combinatoire. En premier temps un
utilisateur accède à l’interface de l’application via une authentification ou une
inscription, choisit une compétition parmi celles qui sont disponibles ou bien
reçoit un code de participation de la part du responsable de la compétition s’il
est déjà inscrit.

Notre rapport se divise en quatre chapitres :

En premier temps, nous présenterons une étude détaillée du cahier de

charge, puis en second lieu une identification des différents besoins auxquels se
porte notre travail. Ensuite nous passerons à la conception c’est-à-dire voir une
description de notre base de données et de la vue dynamique ( les diagrammes
de séquence, diagramme de classes). Finalement dans la partie réalisation nous
présenterons l’environnement logiciels utilisés, les différents techniques de réali-
sation et les différentes interfaces de l’application.

1
Chapitre 1 : Contexte du projet et cahier de charge

1.1 Introduction :

Afin de valider nos études acquises au fil de trois ans au sein de la faculté
des sciences de rabat et en vue de l’obtention de la licence fondamentale en Ma-
thématiques et Informatique nous sommes appelés à effectuer une Application
Web pour gérer les compétitions d’algorithme d’optimisation combinatoire.
Tout d’abord, nous commencerons par faire une présentation succincte du sujet
en détaillant son cadre et ses fonctionnalités. Ensuite, nous détaillerons le cahier
des charges proposé et le chronogramme suivi tout au long de la réalisation de
ce projet.

1.2 Contexte

En informatique, une application web est une application qui désigne un

logiciel applicatif hébergé sur un serveur et accessible via un navigateur web.

Avec une Application Web :

1. Plus besoin d’installation sur les postes informatiques

2. Plus de mise à jour à gérer sur les postes informatiques
3. Sauvegarde centralisée sur le serveur
4. Plus de risque de fuite de données par le poste informatique du collabo-
rateur ou client
5. Possibilité de remplacer son poste informatique rapidement et reprendre
le travail.
6. Possibilité de Mise en place automatique de version multipostes corres-
pondant à des multi accès par login et mot de passe.
7. Partage d’information plus simple et plus rapide.

Dans notre projet nous allons utiliser le langage PHP et le Framework

Symfony2. Notre application web va servir aux visiteurs en leur offrant un es-
pace de divertissement et aussi du défi de participation à des compétitions.

2
 1.3 Présentation du Sujet

Notre projet est une Application Web pour la gestion des compétitions
d’algorithmes qui permettent de résoudre des problèmes d’optimisation combi-
natoire pour la gestion en ligne.
Un problème d’optimisation consiste à trouver des ensembles discret une solu-
tion parmi un ensemble des solutions réalisables (Vérifiant les contraintes liées
au problème). Une solution peut être optimale (exacte) ou approchée (proche
de l’optimale). Les solutions se distinguent par leur coût (valeur objective).
Plusieurs équipes peuvent participer et plusieurs compétitions peuvent être or-
ganisées. Le système doit être capable d’enregistrer et récupérer les résultats de
la base de données et afficher des tableaux et des graphes de comparaison de
résultats obtenues.

1.4-Objectifs de l’application

Notre projet de fin d’études a pour objectifs de :

1. Permettre à un participant de s’authentifier avec email et mot de passe

2. Saisir les résultats obtenus via un formulaire.
3. Afficher un histogramme pour comparer les résultats des participants
selon le score et la date.
4. Afficher un diagramme pour comparer les résultats du participant avec
ceux des autres participants selon la taille de problème.
5. Exporter les résultats des compétitions en fichier (CSV).

1.4-Approches du travail

Le projet comprend deux phases : la première est la phase de conception

et la deuxième est la phase de développement de l’application.

-Phase de Conception : Dans cette étape nous allons élaborer les di-
grammes de classe, de cas d’utilisation et de séquence pour affiner l’étude préa-
lable et le recueil des besoins pour résoudre nos problématiques et répondre à
nos besoins afin de réussir notre projet.

3
 -Phase de Développement : Nous avons réservé cette partie pour
concevoir l’application dans tout son ensemble y compris les différentes tâches
à accomplir dans la partie développement ainsi que la programmation.

1.5-Méthodologie et formalismes adoptés

L’organisation du travail est un facteur essentiel de productivité et d’ef-

ficacité. Nous adopterons la méthode agile dans une version plus simple :

La figure 1.1 présente les étapes à suivre dans notre travail sous forme d’un cycle

4
 1.1-Cycle résumant la structure du travail

Le cycle contient cinq phases :

1. la première phase est «Expression des besoins», dans laquelle se défi-

nissent les différents besoins de notre application tels que les acteurs
avec leurs fonctionnalités.
2. la deuxième phase est «Analyse» dans laquelle nous visons à bien exa-
miner et à trouver des solutions globales et optimales.
3. la troisième phase est «Conception » dans laquelle nous introduisons en
premier lieu les différents diagrammes de cas d’utilisation puis le dia-
gramme de classe et finalement le diagramme de séquence relatif à une
compétition
4. la quatrième phase est «Implémentation». C’est dans laquelle nous spé-
cifions les outils dont on aura besoin pour la réalisation de l’application.
5. la cinquième phase est «Test » dans laquelle testons le fonctionnement
correct de l’application

1.7 Conclusion

Dans ce chapitre, nous avons présenté le sujet de notre projet , analysé

le cahier de charge et donné une vue générale sur la structure de ce travail en
présentant les étapes à suivre. Dans le chapitre suivant, nous allons présenter
les besoins fonctionnels.

5
 Chapitre 2 : Spécification des besoins
2.1 Introduction

La spécification des besoins est la première étape dans un projet. Cette

étape est déterminante pour le bon déroulement du projet. Elle consiste à
connaître le travail demandé et les différents problèmes posés par le sujet.
Nous commencerons dans la première partie par une présentation de la spéci-
fication générale de notre projet du point de vue acteurs et leurs fonctionnalités.

2.2 Présentation des acteurs

Tout d’abord, les acteurs sont des entités externes par rapport à un sys-
tème modélisé et qui interagissent avec ce système (operateur, centre distant,
autre système. . . etc). Identifier les acteurs intervenants et surtout ceux sur les
cas d’utilisation, peut en fait représenter une véritable problématique. Pour nous
aider à mieux les identifier voici quelques questions qui nous permettrons plus
facilement d’identifier les acteurs de notre système :

- Quels sont les utilisateurs qui ont besoin d’un système pour réaliser le
travail ?
- Quels sont les utilisateurs qui vont effectuer les fonctions principales du
système ?
- Quels sont les utilisateurs qui vont exécuter les fonctions principales du
système (maintenance et administration) ?
- Est-ce que le système interagit avec du matériel ou d’autres logiciels ?

Donc finalement, en se basant sur ces quatre dernières questions, on peut

facilement identifier nos acteurs. Notre système étant évidemment notre appli-
cation web, la première réponse ne peut être rien d’autre que les utilisateurs
habituels comme toute autre application utilisant les ressources du site pour
leurs besoins. Ensuite se présente l’acteur responsable dans notre cas, ce qui
n’est pas toujours le cas pour tous les autres sites, qui prend le contrôle de cer-
tains nombres d’éléments de l’application(les compétitions) et puis nous avons
l’administrateur qui est chargé de la maintenance et la gestion du site.

Le tableau 2.1 résume les acteurs de notre systeme.

6
 Tableau 2.1 : Acteurs du système

2.3 Identification de fonctionnalité par acteur

2.2.1 Fonction utilisateur :

Un utilisateur est une personne qui utilise un système informatique mais qui
n’est pas nécessairement informaticien (par opposition au programmeur).
Il existe au sein de ce même acteur des différentes sortes d’utilisateurs :

1. L’utilisateur humain qui n’a aucune compétence en informatique, qui

utilise le système dans le cadre de son temps de loisir, celui-ci pourrait
donc adopter un comportement d’utilisateur au sens commerciale.
2. L’utilisateur professionnel qui aborde le système dans le cadre de contraintes
liées à son activité.
3. L’utilisateur avancé, qui connaît plusieurs détails de fonctionnement du
système et ce type de catégorie regroupe essentiellement les humains
qui sont plongés à longueur de journée dans les nouvelles technologies.
Ce type d’utilisateur est pratique dans la mesure où il peut fournir une

7
 analyse du fonctionnement d’un système (rapport de bugs, évaluation
d’interface, etc.).

Ci-après ces actions possibles dans notre cas :

1. S’inscrire sur le site.

2. Choisir une compétions parmi les compétitions publiques.
3. Saisir ses résultats sur un formulaire et éventuellement l’exporter sur un
fichier Excel.

2.2.2 Fonction administrateur

Un administrateur est avant tout un utilisateur sauf que celui-ci dispose

plus de rôle qu’un simple utilisateur qui utilise l’application pour des besoins
personnels, il régit le bien du site, résous les problèmes pouvant intervenir mais
son rôle ne se limite pas uniquement à cela car il doit également proposer des
solutions en adéquation avec les besoins de son client.

Ci-après ces actions possibles dans notre cas :

1. création d’une compétition,

2. fermeture d’une compétition.
3. Nommer un responsable.
4. Supprimer un responsable ou un utilisateur en générale.
5. Mettre à jour une compétition

2.2.3 Fonction responsable

Un responsable assure l’organisation, le suivi et la mise en œuvre des éléments

de notre système mais à condition que ce rôle lui est attribué par l’administra-
teur.

Ci-après ces actions possibles dans notre cas :

1. Gère certaines compétitions.

8
 2. Envoie le code de validation pour les compétitions privées à des partici-
pants.

Conclusion

Dans ce chapitre, nous nous sommes concentrés dans un premier temps

sur la détermination des acteurs. Dans un deuxième lieu, nous avons détaillé les
cas d’utilisations de l’application du point de vue de ces acteurs. Ces besoins vont
être la base sur laquelle nous allons réaliser la conception de notre application.
Cette conception va être l’objet du chapitre suivant.

9
Chapitre 3 : Conception de l’application
3.1 Introduction

Ce chapitre s’intéresse à la partie conception qui constitue une phase pri-

mordiale dans le processus de développement. Nous allons commencer par une
expression des besoins puis une description de la base de données et le compor-
tement dynamique de l’application.

3.2 Phase d’expression des besoins

La phase d’expression des besoins permet de décrire les cas d’utilisa-

tions global et les cas d’utilisation détaillés de l’application. Le diagramme de
cas d’utilisation décrit l’interdépendance entre le système et l’acteur en détermi-
nant le besoin de l’utilisateur et de tout ce que doit faire le système pour l’acteur.

3.2.1-Diagramme de cas d’utilisation générale

La figure 3.1 montre le diagramme de cas d’utilisation générale :

10
Figure 3.1 -Diagramme de cas d’utilisation générale

11
3.2.2-Diagramme de cas d’utilisation relatif à un utilisateur

La figure 3.2 montre le diagramme de cas d’utilisation générale du module

utilisateur :

Figure 3.2 -Diagramme de cas d’utilisation d’un utilisateur

12
La figure 3.2 représente le diagramme de cas d’utilisation d’un utilisateur com-
posé de trois cas d’utilisation qui sont : participer à une compétition, visiter le
site et s’authentifier .Ces cas seront détailler dans ce qui suit.

Description du cas d’utilisation « participer à une compétition »

1. Nom du cas : « participer à une compétition

2. Acteur : Utilisateur
3. Pré-condition : l’utilisateur est connecté sur le site
4. Post-condition : l’utilisateur trouve les différentes compétitions publiques
5. Le cas d’utilisation : l’utilisateur veut participer à une compétition
6. Scénario principale :
— le système affiche les différentes compétitions
— L’utilisateur choisi une compétition

Description du cas d’utilisation « visiter le site »

1. Nom du cas : « visiter le site »

2. Acteur : Utilisateur
3. Pré-condition : l’utilisateur n’est pas connecté sur le site
4. Post-condition : l’utilisateur saisi son login et son mot de passe
5. Le cas d’utilisation : l’utilisateur veut se connecter sur le site
6. Scénario principale :
— l’utilisateur se rend sur le site
— saisi éventuellement son login et son mot de passe pour se connecté

Description du cas d’utilisation « s’authentifier »

1. Nom du cas : « s’authentifier »

2. Acteur : Utilisateur
3. Pré-condition : l’utilisateur n’est pas connecté sur le site
4. Post-condition : le système vérifie l’authentification
5. Le cas d’utilisation : l’utilisateur veut se connecter sur le site

13
3.2.3-Diagramme de cas d’utilisation relatif à un Responsable

Figure 3.3 Diagramme de cas d’utilisation du responsable

14
 Cette dernière figure représente le diagramme de cas d’utilisation du respon-
sable composé de trois cas d’utilisation qui sont : envoyer le code de participa-
tion, accepter ou refuser la participation et supprimer ou ajouter des participants
à des compétitions .Ces cas seront détaillé dans ce qui suit.

Description du cas d’utilisation « envoyer le code de participation»

1. Nom du cas : « envoyer le code de participation»

2. Acteur : Responsable
3. Pré-condition : le responsable doit être connecté sur le site
4. Post-condition : le responsable envois le lien à un ou plusieurs participants
5. Le cas d’utilisation : le responsable envois le code de participation
6. Scénario principale :
— le responsable se connecte au site avec son compte d’utilisateur
— choisi une compétition parmi les compétitions privée
— envois le lien a un ou plusieurs compétitions

Description du cas d’utilisation « accepter ou refuser la participation»

1. Nom du cas : « accepter ou refuser la participation»

2. Acteur : Responsable
3. Pré-condition : le responsable doit être connecté sur le site
4. Post-condition : le responsable clic sur le bouton accepter ou refuser
5. Le cas d’utilisation : le responsable accepter ou refuse la participation

15
3.2.4-Diagramme de cas d’utilisation relatif à un Administrateur

Figure 3.4 Diagramme de cas d’utilisation de l’administrateur

16
 la figure 3.4 représente le diagramme de cas d’utilisation de l’administra-
teur composé minimum de quatre cas d’utilisation qui sont : gérer la sécurité
du site, mettre à jour une compétition, fermer une compétition et ajouter ou
supprimer des responsable. Ces cas seront détaillés dans ce qui suit.

Description du cas d’utilisation « mettre à jour une compétition»

1. Nom du cas : « mettre à jour une compétition »

2. Acteur Administrateur
3. Pré-condition : l’administrateur doit être connecté sur son interface
4. Post-condition : l’administrateur effectue la modification nécessaire à la
compétition.
5. . Le cas d’utilisation : l’administrateur met à jour la compétition

Description du cas d’utilisation « ajouter ou supprimer un respon-

sable »

1. Nom du cas : « ajouter ou supprimer un responsable »

2. Acteur Administrateur
3. Pré-condition : l’administrateur doit être connecté sur son interface
4. Post-condition : L’administrateur nomme un responsable parmi les utili-
sateurs ou supprime un responsable parmi les responsables.
5. Le cas d’utilisation : l’administrateur choisi un responsable parmi les utili-
sateurs (et lui donne le rôle de responsable) ou soit parmi les responsables
(et lui retire son rôle).

Description du cas d’utilisation « fermer une compétition »

1. Nom du cas : « fermer une compétition»

2. Acteur Administrateur
3. Pré-condition : l’administrateur doit être connecté sur son interface
4. Post-condition : l’administrateur sélectionne la ou les compétitions à fer-
mer

17
 5. Le cas d’utilisation : l’administrateur ferme une compétition parmi toutes
les compétitions (privées ou public).

3.3-Conception de la vue dynamique

3.3.1-Description de Classe : diagramme de classes

Le diagramme de classes présente les classes et les différentes relations entre

celle-ci :

18
La figure 3.5 décrit le diagramme de classe générale, conçu pour notre applica-
tion

19
Ce diagramme de classe contient sept classes :

1. La classe "Compétition" qui contient quatre attributs avec comme clé

primaire "Id_compétition" de type integer et une clé étrangère de la classe
"Responsable" d’après les cardinalités 1..* entre les deux classes.
2. La classe "Inscription" qui contient deux attributs avec comme clé
primaire "Id_Inscription" de type integer et une clé étrangère de la classe
"Compétition" d’après les cardinalités 1..* entre les deux classes.
3. La classe "Algorithme" qui contient trois attributs avec comme clé
primaire "Id_algo" de type integer.
4. La classe "Executable" qui contient trois attributs avec comme clé
primaire "Id_Executable" de type integer et deux clés étrangères de la
classe "Inscription","Algorithme" respectivement d’après les cardinalités
1..* entre ces classes.
5. La classe "Administrateur" présente deux attributs et hérite les attri-
buts de la classe "Responsable" qui contient quatre attributs dont ce der-
nier hérite aussi de la classe "Utilisateur" qui présente trois attributs avec
comme clée primaire "Id_utilisateur" de type integer et une clé étrangère
de la classe "Inscription","Algorithme" respectivement d’après les cardi-
nalités 1..* entre ces derniers.

20
 3.3.2-Diagramme de séquence relatif à une compétition

Les diagrammes de séquences sont la représentation graphique des in-

teractions entre les acteurs et le système selon un ordre chronologique dans la
formulation Unified Modeling Language.

La figure 3.6 décrit le diagramme de séquence relatif une compétition

21
figure 3.6 Diagramme de séquence relatif à une compétition

22
 3.4- Description de la base de données :

3.4.1 Description des tables :

Dans les bases de données, une table est un ensemble de données orga-
nisées sous forme d’un tableau où les colonnes correspondent à des catégories
d’information et les lignes à des enregistrements, également appelés entrées.
L’une des plus célèbres interfaces pour gérer une base de données sur un serveur
PHP est "phpmyadmin". Cette interface pratique permet d’exécuter, très faci-
lement et sans grandes connaissances en bases de données, des requêtes comme
les créations de table de données, insertions, mises à jour, suppressions et mo-
difications de structure de la base de données.

Dans notre projet nous avons besoin de spécifier cinq tables, la première
table est la table ‘Utilisateur’ qui va contenir toute les informations concer-
nant un utilisateur de l’application.

Cette table aura une colonne appelée ID qui est la clé primaire de la table. La
figure 3.7 décrit la table Utilisateur :

23
 Figure 3.7 Table Utilisateur

-La deuxième table est la table ‘Compétition’ qui contient toutes les in-
formations concernant une compétition, et sa structure sur phpmyadmin est
présentee dans la figure 3.8 :

Figure 3.8 Table Compétition

24
-La troisième table est la table ‘Inscription‘ dont la structure est décrite
par la figure 3.9 :

Figure 3.9 Table Inscription

25
-La quatrième table est la table ‘algorithme’ décrit l’algorithme qui est
utilisé par le participant. Cette table est présentée dans la figure 3.10.

Figure 3.10 Table Algorithme

-La cinquième table est la table ‘Exécutable’ va contenir le résultat de la

participation à une compétition :

Figure 3.11 Table Executable

26
 3.4.2-Le modèle Relationnel des données (MRD) :

Le modèle relationnel des données consiste à décrire la structure de don-

nées utilisée sans faire référence à un langage de programmation. Il s’agit donc
de préciser le type de données utilisées lors des traitements. Les identifiants de
la classe d’entité sont appelés clés de la table, tandis que les attributs standards
deviennent des attributs de la table, c’est-à-dire des colonnes :

Utilisateur(Id_Utilisateur,Nom,Prenom,Role,#Id_Inscription,#Id_algo)
Competition(Id_Competition,Nom,date_debut,date_fin,#Id_Responsable)
Inscription(Id_Inscription,date_dńscription,#Id_Competition)
Algorithme(Id_algo,Nom,codeAlgo)
Executable(Id_Execution,Score,Temps,#Id_algo,#Id_inscription)

3.4.3-Règles de gestion :

Parmi les règles de gestion définies au sein des contraintes d’intégrité qui
vont être représentées dans notre MRD, on distingue :

3.
4.
1.
5.
2.
1. la participation à des compétitions est ouverte à tout le monde.
2. l’utilisateur peut demander une ou plusieurs participations
3. une compétition peut contenir un ou plusieurs utilisateurs.
4. le responsable de chaque compétition peut envoyer à plusieurs utilisateurs
des codes de participation
5. Un utilisateur peut utiliser un seul algorithme pour la compétition choisie.
6. Un algorithme peut être utilisé par plusieurs utilisateurs.
7. un responsable peut s’occuper de plusieurs compétitions.
8. une compétion est gérée par un seul responsable
9. Un algorithme peut contenir plusieurs exécutions.
10. Une exécution est faite par un seul algorithme.
11. une exécution concerne une seule inscription.
12. une inscription peut concerner plusieurs exécutions.

27
 3.5-Comportement dynamique de l’application :

3.5.1 gérer les utilisateurs :

Pour gérer les utilisateurs avec leurs droits d’accès, il faut tout d’abord
s’authentifier entant qu’Administrateur, accéder à la création d’un nouveau uti-
lisateur en remplissant le nom et le prénom, le login, le mot de passe, l’email, le
Téléphone et indiquer si l’utilisateur est un responsable ou non. Finalement on
peut soit le valider et quitter le formulaire ou de valider et de créer un nouvel
utilisateur.

3.5.2 gérer les droits d’accès :

Concernant les droits d’accès, l’Administrateur accède à l’onglet de l’ap-

plication "gestion des droits" et sélectionne un utilisateur, modifie les droits
d’accès puis enregistre les modifications.

3.5.3 Attribuer un responsable à une compétition :

Cette activité sert à lier un responsable à une compétition. Pour effec-

tuer cette activité il faut que l’administrateur se connecte et sélectionne une
compétition puis cherche l’utilisateur disponible à le mettre comme étant un
responsable et valide le choix.

3.6-Conclusion

Au long de ce chapitre, nous avons présenté la conception de notre ap-

plication ainsi que son architecture. Le chapitre suivant intitulé « Réalisation»,
nous permettrai de présenter l’environnement matériel et logiciel de développe-
ment ainsi que des imprimés écrans détaillés de notre application

28
 Chapitre 4 : Réalisation
4.1 Introduction

Cette partie contient le dernier volet de ce rapport, elle a comme but

d’exposer notre travail achevé. Nous allons débuter par la présentation de l’en-
vironnement matériel et logiciel utilisé tout au long de la période de développe-
ment.

4.2 Environnement matériel :

Durant ce présent projet de fin d’études, tout le travail a été réalisé sur
deux ordinateurs portables qui ont les mêmes caractéristiques techniques sui-
vantes :

1. Processeur : Intel(R) Core(TM) i5-3230M CPU @2.60 GHz 2.60 GHz

2. Mémoire RAM : 4.00 GO
3. Système d’Exploitation : 64
4. Edition Windows : Windows 7 professionnel

4.3 Environnement logiciel :

Après avoir présenté le moyen matériel mis à notre disposition dans le

cadre de réalisation de ce travail, nous abordons dans cette partie les moyens
logiciels utilisés. Les logiciels utilisés pour la réalisation de ce projet ainsi que
pour la rédaction de ce rapport sont :

1. Symfony2 : pour le développement de notre application

2. WampServer : pour la création de la base de données.
3. modelio : pour la réalisation des différents diagrammes de modélisation.
4. latex : pour la rédaction de ce rapport.

-SYMFONY2

Est un Framework lancé en 2005 par une agence française (SensioLabs).Symfony

était à l’origine appelé Sensio Framework .lorsque Sensio a souhaité partagé son

29
code avec la communauté, elle a renommé symfony Framework [16] pour garder
les initiales SF. Avec le passage à la version 2.0, l’outil est simplement devenu
Symfony.

Et pour ce qui est de la modularité, Symfony2 a été jusqu’au bout de la logique :

chaque projet est découpé en modules appelé Bundle, les plus précis possible
et le Framework est lui-même est un groupe de modules que chacun est libre
d’utiliser ou non

Symfony est un kit des composants destinés à faciliter le développement des

sites internet riches ou d’application web. Pour cela le code est séparé en trois
couches selon un modèle appelé MVC qui sépare le modèle de donnée (M), l’in-
terface utilisateur ou vue (V) et le contrôleur (C) qui gère les événements, la
synchronisation, etc.

La figure 4.1 montre le logo de Symfony2 :

Figure 4.1 logo de Symfony2

-MVC

« MVC » : Model-View-Controller (model/Vue/contrôleur en français) est un

design pattern (patron de conception), c’est-à-dire un concept d’architecture
logiciel pour son application. Il permet d’avoir un code plus structuré, plus évo-
lutif, plus maintenable, permettant de profiter de plusieurs mécanismes, d’avoir
de la persistance de données et bien d’autres choses aussi

Le model(M) est la représentation interne des données. Il permet comme son

nom l’indique de modéliser les données que l’on va manipuler dans l’application.

30
Le modèle représente les véritables données avec toutes les informations qu’elles
véhiculent.

La ‘Vue ‘ quant à elle est la représentation visuelle de ces données à l’écran.

Le contrôleur enfin, sert à faire l’interface entre le modèle et la vue. En effet,
puisque les modèles et la vue sont sensés être au maximum indépendants, le
contrôleur sert à faire le lien pour faire communiquer l’un (M) avec l’autre (V).

La figure 4.2 montre le modél de fonctionnement du MVC :

Figure 4.2 le model de fonctionnement du MVC

31
-Doctrine

Doctrine est un objet Objet-Relationnel Mapping (ORM) composé d’énorme

fonctionnalités, à commencer par le DQL (doctrine query language).Finies les
requêtes SQL ! le DQL vous permet permet de créer et d’exécuter vos requêtes
via le paradigme de la programmation orienté Objet.

Il s’est beaucoup fait connaitre grâce au Framework Symfony qui, au fil de ver-
sion, l’intègres au mieux en mieux aux dépens de Propél dans la mesure où
doctrine est un projet toujours maintenu.

La figure 4.3 montre le logo de Doctrine :

Figure 4.3 logo de doctrine

32
-TWIG

Twig est un moteur de Template de PHP directement intégré dans Symfony2.

Très puissant, twig permet de gérer entre autre l’héritage entre Template et
layout, séparer les couches de présentation et couche métiers. . . etc.

La figure 4.4 montre le logo de TWIG :

Figure 4.4 logo de TWIG

-WampServer

est une plateforme de développement Web de type WAMP, permettant de faire

fonctionner localement (sans se connecter à un serveur externe)des scripts PHP.

La figure 4.5 montre le logo de WampServer :

33
 Figure 4.5 logo de WampServer

-Modelio

Modelio est un outil de modélisation UML disponible sur les plates-formes Win-
dows, Linux et Mac. Il intègre également la modélisation BPMN, et le support
de la modélisation des exigences, du dictionnaire, des règles métier et des ob-
jectifs.
Modelio propose une gamme d’outils étendant ses fonctionnalités permettant,
entre autres, la mise en œuvre de l’approche MDA.

La figure 4.6 montre le logo de Modelio :

Figure 4.6 logo de Modelio

-Latex

LATEX est un langage et un système de composition de documents créé par

Leslie Lamport en 1983. Plus exactement, il s’agit d’une collection de macro-
commandes destinées à faciliter l’utilisation du « processeur de texte » TeX de
Donald Knuth. Depuis 1993, il est maintenu par le LATEX3 Project team. La
première version utilisée largement, appelée LaTeX2.09, est sortie en 1984. Une
révision majeure, appelée LaTeX2, est sortie en 1991

34
La figure 4.7 montre le logo de Latex :

Figure 4.7 logo de Latex

4.4 Langages utilisés :

4.3.1 -PHP :

PHP : HyperText Preprocessor , plus connu sous son sigle PHP est un langage
de programmation libre, principalement utilisé pour produire des pages web dy-
namiques via un serveur HTTP, mais pouvant également fonctionner comme
n’importe quel langage interprété de façon locale. PHP est un langage oriente
objet. PHP a permis de créer un grand nombre de sites web célèbres, comme
Facebook, Wikipédia etc. Il est considéré comme la base de la création des sites
Internet dits dynamique Au lieu d’utiliser des tonnes de commandes a fin d’af-
ficher du HTML (comme en C ou en Perl), le code PHP est inclus entre une
balise de début < ? PHP et une balise de fin ?> qui permettant au serveur web
de passer en mode PHP. Ce qui distingue PHP des langages de script comme
JavaScript, est que le code est exécuté sur le serveur, générant ainsi le HTML,
qui sera ensuite envoyé au client. Le client ne reçoit que le résultat du script,
sans aucun moyen d’avoir accès au code qui a produit ce résultat.

35
Parmi les avantages de langage PHP :
1. Pas besoin de différencier les navigateurs du marché (le code fonctionne
sur tous dès qu’il fonctionne sur un)
2. Maîtrise du fonctionnement et du code
3. Le code source n’est pas visible
4. Nombreuses interactions avec le serveur (bases de données, fonctions avan-
cées d’images, de génération de PDF, d’exécution de scripts).

4.3.2 HTML :

L’HyperText Markup Language, généralement abrégé HTML, est le format de

donnée conçu pour représenter les pages web. C’est un langage de balisage per-
mettant 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édia dont des images, des formulaires de saisie, et des pro-
grammes informatiques. Il permet de créer des documents interopérable 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 programmations
(JS) (et des formats de présentation (feuilles de style en cascade).

L’HTML5 est le successeur de l’HTML 4.01 (et de l’XHTML 1.0), ça veut dire
qu’il s’agit toujours du HTML à la différence de quelques nouvelles balises. De
plus, la version 5 est aujourd’hui compatible avec la majorité des navigateurs et
répond aux normes W3C (C’est une communauté internationale où les membres
(une équipe à plein temps et le public) travaillent ensemble pour développer les
standards du web.)

36
4.3.3 CSS :

Les feuilles de style en cascade1, généralement appelées CSS de l’anglais Cas-

cading Style Sheets, forment un langage informatique qui décrit la présentation
des documents HTML et XLM Les standards définissant CSS sont publiés par
le Word 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 dans les années 2000.

Avantages de CSS

En séparant le plus possible (mais pas complètement) le contenu des pages

(code HTML) et les instructions de mise en page (CSS), les feuilles de style
permettent de réaliser un gain considérable :

1. Gestion simplifiée, centralisée et économique de la présentation d’un site

à l’aide d’un nombre limité de feuilles de style externes (fichiers .css) ai-
sément modifiables et utilisées par toutes les pages ;
2. Facilitation de la mise au point grâce à un code débarrassé d’un maximum
de balises HTML encombrantes ;
3. Allègement des coûts de développement, de maintenance et de transfor-
mation. En utilisant un petit nombre de feuilles de style externes (fichiers
.css) regroupées au même endroit (répertoire) du site, la mise à jour de
gros sites est facilitée : les changements effectués dans ces quelques feuilles
de style se répercutent sur la totalité des pages du site au lieu de nécessiter
de laborieuses corrections de tout le site entreprises page par page. Autre
avantage, on peut ainsi changer très rapidement tout le look d’un site ;
4. Allègement du code-source des pages Web, et donc économie de bande
passante : de plus une feuille de style n’est chargée qu’une fois par un
navigateur, qui l’applique sans délai si nécessaire aux pages visitées par la
suite ;
5. Possibilité de doter des pages par des feuilles de style externes (fichiers .css)
spécifiques selon les médias (navigateurs graphiques, lecteurs d’écran (pour
le mal voyant),. . . ). Par exemple, les feuilles de style print permettent
une impression immédiate d’une page depuis le navigateur, et dispensent
d’avoir à créer une version imprimable du document HTML ;
6. Possibilité de doter une page de présentations alternatives correspondant

37
 au choix de l’utilisateur.

4.5-Principales interfaces graphiques :

4.5.1-Authentification et Inscription

La première interface de notre apppliccaation est l’interface d’authentification

et Inscription ( voir figure 4.5.1)

figure 4.5.1-Interface d’Authentification et inscription

38
Dans l’espace utilisateur il y a deux interfaces :
1. La première "interface utilisateur 1" (voir figure 4.5.2 ) est la page d’accueil
de l’espace utilisateur
2. La deuxième "interface utilisateur 2" (voir figure 4.5.3) permet à l’utilisa-
teur de choisir une compétition parmi de la liste des compétitions dispo-
nibles

4.5.2-Espace <Utilisateur>

figure 4.5.2-Interface Utilisateur 1

39
Liste des compétitions disponibles

figure 4.5.3-Interface Utilisateur 2

40
 4.5.3-Espace <Responsable>

Dans l’espace responsable il y a deux interfaces :

1. La première interface "interface responsbale 1 "(voir figure 4.5.4) permet
à un responsable de jouer l’un des deux roles suivantes :
(a) Role Responsable
(b) Role Utilisateur
2. deuxieme interface "interface responsable 2" (voir figure 4.5.5) permet à
un responsable de bloquer une compétition parmi les compétitions dont il
est responsable.

figure 4.5.4-Interface Responsable 1

41
Fonction du Responsable

figure 4.5.5-Interface Responsable 2

42
 4.5.4-Espace <Administrateur>

Dans l’espace administrateur il y a deux interfaces :

1. la première interface "interface administrateur 1" (voir figure 4.5.6) permet
de rediriger l’administrateur vers son espace.
2. deuxieme interface "interface administrateur 2" (voir figure 4.5.7) permet
à l’administrateur soit d’ajouter un nouveau responsable, soit de suppri-
mer un responsable parmi les responsables déjà choisi

figure 4.5.6-Interface Administrateur 1

43
 Fonctions de l’Administateur

figure 4.5.7-Interface Administrateur 2

4.6-Conclusion

Dans ce dernier chapitre, nous avons présenté l’environnement matériel et

logiciel de l’application, notamment l’utilisation de Framework Symfony2, aussi
bien quelques captures d’écrans de l’application développée.

44
 Conclusion générale
L’objectif de notre projet consiste à concevoir et implémen-
ter une application web concernant la participation à des compéti-
tions sous le Framework Symfony2.

Pour commencer nous avons fait une étude détaillée du ca-

hier de charge. Ensuite nous avons identifié les différents besoins
auxquels se porte notre travail. Nous sommes passés à la conception
c’est-à-dire une description de notre base de données et de la vue
dynamique ( les diagrammes de séquence, diagramme de classes ).
Finalement nous avons réalisé notre application en présentant l’en-
vironnement logiciel utilisé, les différentes techniques de réalisation
et les différentes interfaces de l’application.

Les fonctionnalités offertes par cette application sont impor-

tantes, Néanmoins. cette application peut être améliorée par l’ajout
des compétitions privées visant un public précis, l’ajout d’un email
d’accusé de réception pour les compétitions privées, et bien d’autres
choses. Il existe toujours des améliorations envisageables pour rendre
l’application plus performante.

Ce travail nous a été une occasion d’appliquer dans un cadre

professionnel toutes nos connaissances acquises durant notre cycle
de formation.

45
 Webographie :
1. http ://fr.wikipedia.org (consulté le 17/5/2016)

2. https ://fr.wikipedia.org/wiki/Hypertext_Markup_Language (consulté le

18/5/2016)

3. http ://fr.slideshare.net/HBDJ10/rapport-pfe-384118872009 (consulté le

18/5/2016)

4. http ://www.via.ecp.fr/viaform/2004-05/formation-php.pdf (consulté le

20/5/2016)

5. https ://fr.wikipedia.org/wiki/Symfony (consulté le 20/5/2016)

6. https ://fr.wikipedia.org/wiki/PHP (consulté le 21/5/2016)

7. http ://symfony.com/doc/master/book/controller.htmlmanaging-the-session
(consulté le 22/5/2016)

8. https ://openclassrooms.com/courses/developpez-votre-site-web-avec-le-framework-
symfony2 (consulté le 23/5/2016)

9. https ://www.facebook.com/groups/842275332584866/ (consulté le 24/5/2016)

10. https ://fr.wikipedia.org/wiki/WampServer (consulté le 20/5/2016)

11. https ://fr.wikipedia.org/wiki/LaTeX (consulté le 25/5/2016)

12. https ://fr.wikipedia.org/wiki/Modelio (consulté le 27/5/2016)

13. http ://www.techno-science.net/ ?onglet=glossairedefinition=743 (consulté

le 27/5/2016)

14. https ://fr.wikipedia.org/wiki/PhpMyAdmin (consulté le 20/5/2016)

46
15. https ://www.ideematic.com/dictionnaire-web/application-web (consulté
le 28/5/2016)

16. http ://www.xm1math.net/doculatex/espacements.html (consulté le 20/06/2016)

17. http ://www.commentcamarche.net/contents/1013-le-modele-relationnel (consulté

le 03/6/2016)

47