PerezLuc .pdf


À propos / Télécharger Aperçu
Nom original: PerezLuc.pdf

Ce document au format PDF 1.5 a été envoyé sur fichier-pdf.fr le 09/02/2018 à 14:15, depuis l'adresse IP 83.193.x.x. La présente page de téléchargement du fichier a été vue 292 fois.
Taille du document: 5.8 Mo (56 pages).
Confidentialité: fichier public


Aperçu du document


Perez Luc

Dossier de Synthèse

Titre professionnel développeur logiciel
Développement logiciel niveau III
Année 2016

Entreprise prestataire : Nalta Systems
Entreprise cliente : Idelis

SOMMAIRE
1. ​Présentation de l’entreprise prestataire
1.1. Activité
1.2. Organigramme

2 ​Présentation de l'entreprise cliente

1.1. Activité
3. ​Présentation du projet
3.1 Le contexte
3.2 L'existant et les ressources disponibles au commencement du projet
3.3 Le site web
3.4 Les contraintes
3.5 Cas d’utilisation
4. ​Maquettage, évolutions graphiques et responsive design
4.1 la page planning
4.2 Une page d’administration
5. ​Conception et modélisation de la base de données
5.1 Modèle Conceptuel des Données :
5.2 Explication des étapes ayant permis l’aboutissement de la structure de la
base de données
5.3 Présentation d’un extrait du script de structure de la base de donnée
MySQL
6. ​Intégration du planning en html et CSS
6.1​ ​Structure de la page planning
6.2 La disposition spatiale des événements dans le planning
6.3 intégration du slider de création d’activités et interaction javascript
6.4 Responsive et media query
7. ​Architecture MVC et design patterns
7.1 Exemple de fonctionnement pour la récupération de la liste des salariés
7.2 Principe de fonctionnement et du cheminement de l’information dans le
code
7.3 Connexion à la base de données avec le Singleton
8. ​Récupération et traitement des évènements du planning
8.1 La récupération des événements
8.2 le traitement des événements
9. ​Le panneau d'informations avec Ajax
9.1 présentation du panneau d'information
9.2 structure HTML du panneau d’information
9.3 la requête Ajax en détail
10. ​Authentification, accès aux pages et sécurité
10.1 Authentification
10.2 accès aux pages et sécurité
11. ​Manuel de déploiement
12. ​Annexes
12.1 Compétences validés
12.2 Diagramme de classe
12.3 Cahier des charges

Résumé
Dans le cadre de ma formation titre professionnel développeur logiciel, j’ai dû réaliser un
stage en milieu professionnel et mener à bien un projet durant toute cette période. J’ai eu
la chance d’avoir pu travailler avec l’entreprise Nalta Systems qui m’a apporté un bon
cadre de travail ainsi que des conseils précieux dans la mise en oeuvre de ce projet. J’ai
pu ainsi assimiler toute les parties de conception d’un site web, que ce soit la conception
du cahier des charges, l’analyse à travers différents diagrammes UML, le maquettage, la
conception de la base de données, l’intégration ainsi que le développement.
Le projet est né d’une idée marketing, l’entreprise prestataire voulant proposer au client
une refonte complète du site qu’ils utilisent actuellement. Le site web doit alors être plus
ergonomique et accessible sur smartphone, l'aspect visuel sera aussi un changement
majeur par rapport à l’ancienne version.

Abstract
Within the framework of my training as a software developper I had to do an intership in
professional circles and carry out a project throughout this period. I was fortunate to have
been able to work with Nalta Systems, which provided me with a good framework and
valuable advice in the implementation of this project. I have then assimilated all the parts
of the conception of a web site, whether it be about the conception of technical
specification​s, the analysis through different UML diagrams, the web design, the database
conception, as well as the intégration or development.
The project comes from a marketing idea. The supplier entreprise wanted to propose to
the customer a complete overhaul of the current web site. The website must be more
user-friendly and accessible on a smartphone. The visual aspect will also be a major
change in comparison with the former version.

1 ​Présentation de l’entreprise
prestataire
Nalta Systems

1.1. Activité
L’entreprise Nalta Systems, est une PME située au nord de Pau, c’est un prestataire
spécialisé dans le développement informatique, l’hébergement ainsi que l’installation de
serveurs pour les entreprises clientes. Cette structure répond aux besoins de
développement de sites web, logiciel clients lourd ou encore gestion de Parcs
informatiques.
1.2. Organigramme

2 ​Présentation de l'entreprise
cliente
Idelis

Activité 2.1
IDELIS​ assure les déplacements en bus dans l'agglomération paloise grâce à un réseau
structurant. Cette structure assure les déplacements scolaires, ainsi que les
déplacements dans l'agglomération grâce aux lignes régulières.

3. ​Présentation du projet
3.1 Le contexte :
Ce projet est une anticipation du besoin du client, il s'agit d’une démarche commerciale
qui a pour but de proposer au client (Idelis) une nouvelle version plus ergonomique et
fonctionnelle du site actuel se faisant vieillissant. Une refonte graphique complète est
aussi souhaitée afin de remettre au goût du jour le site web existant. Enfin n’étant pas
exploitable pour le moment sur un smartphone, cette refonte permettra de rendre le site
responsive.
3.2 L'existant et les ressources disponibles au commencement du projet :

Capture d’écran du planning.

La fenêtre de création d’évènements

Page d’administration des salariés

Suite aux exigences de mon tuteur encadrant ce projet, je ne dispose pas d’un accès aux
sources de l'existant, que ce soit au code ou à la structure de la base de données
actuelles, les seules pistes à ma disposition sont donc quelques communiqués oraux sur
le fonctionnement global du site actuel ainsi que des captures d’écrans de celui-ci. Le but
étant d’entreprendre une refonte entière du projet actuel et non une simple mise à jour. Le
maquettage, développement ainsi la conception de la base de données ont donc
entièrement été réalisées par mes soins.

3.3 Le site web :
Ce site web permettra aux employés chargés de la gestion des incidents d’alimenter un
planning commun d’information. Ce planning sera consultable en ligne par tous les
employés ce qui leurs permettra de prendre connaissance des informations utiles à leur
journée. Le planning est constitué “d’activités” disposées dans le temps et représentant
visuellement les différentes informations à différents moments de la journées. Par exemple
une “activité” pourra contenir des informations utiles aux utilisateurs tel que le salarié
concerné, la ligne et l’arrêt de bus en rapport avec l’incident.
Chaque activité sera affectée à un certain type permettant d’identifier rapidement par un
code couleur les informations relatives à un certain domaine.
Tout une partie administration sera aussi disponible permettant la création de comptes
utilisateurs ou administrateurs ainsi que d’ajouter des salariés, des bus ou encore des
arrêts associés à des lignes. Ces données gérées par les administrateurs serviront donc
de ressources pour la création d'activités par les utilisateurs.
Enfin ce nouveau site web sera accessible seulement en intranet pour les employés en
relation avec la gestion des incidents sur le réseau de transport en commun idelis.
3.4 Les contraintes :
Les langages exigés dans le cadre de ce projet :
● PHP
● HTML
● Javascript
● MySQL
Les Frameworks utilisés :
● jQuery
● Bootstrap
Aucun Framework ou CMS n'est exigé, j’ai néanmoins pris la décision d’utiliser jQuery
pour les animations côté client et Bootstrap pour l’aspect responsive, le site est développé
en PHP et suivra une architecture MVC, ainsi que plusieurs autres designs patterns
permettant une organisation du code afin de le rendre cohérent et exploitable par la suite.

3.5 Cas d’utilisation

4. ​Maquettage, évolutions graphiques et
responsive design
4.1 La page planning :
1- La maquette :

Le planning avec le slider de création d’évènements ouvert
2- Site final :

Afin de rendre le site plus ergonomique et étant libre sur la disposition des fonctionnalités
du planning, j’ai décidé de réaliser un affichage de celui-ci par tranches de 12h. La
navigation entre les deux demi-journées (de minuit à midi et de midi à minuit) s'effectue en
cliquant sur la barre d’heure pour passer d’une demi journée à l’autre.
Afin de rendre la lecture du planning plus simple il me paraissait aussi plus cohérent
d’avoir un affichage des activités dans le temps horizontalement plutôt que verticalement.
La fenêtre de création d’activités est à présent directement intégrée dans le planning sous
forme d’un slider translucide permettant de conserver un visuelle du planning durant la
création d’une activité.
Un panneau latéral est à présent aussi disponible permettant d’afficher dynamiquement
les informations relatives à l’activité sélectionnée.
3- Site final sur un smartphone :
Sur une taille d’écran réduit, le panneau latéral d’information devient dynamique et peut
être affiché ou masqué ce qui permet d’étendre le planning sur toute la largeur et gagner
en lisibilité sur les formats plus petit.

Le slider de création d’activités quant à lui prendra tout l'espace disponible et viendra
recouvrir complètement le planning toujours dans le soucis de garder une utilisation
confortable sur un espace limité.

4.2 Une page d’administration :
1- La maquette :

2- Le site final :

Les pages d’administrations suivent toute un template html similaire responsive, il est géré
à l’aide du framework Bootstrap. Les boutons sont volontairement grands permettant une
meilleure accessibilité.

5. ​Conception et modélisation de la
base de données
5.1 Modèle Conceptuel des Données :

5.2 Explication des étapes ayant permis l’aboutissement de la structure de la base
de données :
Disposant d’aucune information sur l’ancienne structure et n’étant pas contraint par la
migration des anciennes données j’ai donc commencé par identifier les différentes
données à stocker et leurs relations.

1- Les informations récoltées sont les suivantes :
Caractéristiques d’un salarié
Un salarié dispose d’un nom, d’un prénom et d’une fonction.
Caractéristiques d’un utilisateur
-Un utilisateur est caractérisé par un identifiant, un email ainsi qu’un mot de passe (Crypté
en sha1).
-L’utilisateur peut être Administrateur ou non ce qui définira ses droits et actions possibles
sur le site.
Caractéristiques d’une ligne de bus et de ses arrêts
-Une ligne de bus est composée d’un nom de ligne
-Une ligne de bus contient des arrêts
Caractéristiques d’un arrêt de bus
-Un arrêt dispose d’un nom d’arrêt
-Il peut être associé à plusieurs lignes de bus
Caractéristiques d’un bus
-Un bus n’est défini que par son nom.
-Un bus n’appartient pas à une ligne en particulier.
Caractéristiques d’une activité
-Le planning dispose “d’activités” s'étendant sur une plage horaire.
-chaque activité peut être associée à un bus, un salarié, une ligne et un arrêt permettant
de mettre en relation le lieu de l’évènement ainsi que le salarié concerné par l’activité.
-Les activités disposent aussi d’un auteur (L’utilisateur connecté lors de sa création) d’un
titre, d’un type, d’une solution et d’un service.
2- Conception du modèle de données :
Pour concevoir le schéma de données menant au script SQL final j’ai utilisé l’outil Jmerise
permettant de modéliser graphiquement la structure des données.
Pour commencer, j’ai créé chaque entité avec les propriétés nécessaires définies
précédemment. La liaison entre ces entités et les cardinalités ont ensuite étaient trouvées
par raisonnement logique (Par exemple un Salarié peut être associé à un événement, ils
sont donc liés avec une cardinalité 0,1 car un événement n’est associé qu'à un salarié au
maximum et 0,n pour matérialiser le fait qu’un salarié peut être lié à plusieurs
évènements).

5.3 Présentation d’un extrait du script de structure de la base de donnée MySQL :
Le moteur de stockage utilisé pour cette base de donnée sera InnoDB.
Ci-dessous, la table “Evenements” stockant les informations relatives aux activités du
planning. Chaque évènement est composé d’un identifiant auto incrémenté et non nul. La
durée de l'événement pouvant s'étendre sur plusieurs jours et devant être précis à la
minute elle est donc définie par deux champs “dateDebut” et “dateFin” ce qui permettra de
définir la durée d’un événement.
Les clés étrangères “identifiantLigne”, “identifiantBus”, “idUtilisateur” et “identifiantSalarie”
permettent de lier les événements aux autres tables.

La table “Utilisateur” contenant le mot de passe crypté en sha1 ainsi que le statut de
l’utilisateur (administrateur ou non).

La table “Salaries” permettant de stocker les informations relatives à un salarié.

5.3 Présentation d’un extrait du script du jeu de test de la base de données MySQL :
Afin de permettre une première utilisation simplifiée du site livrable, voici un extrait du
script contenant quelques requêtes d’insertion de données dans la base :
-Insertion d’un premier compte Administrateur par défaut qui permettra de créer les futurs
comptes Utilisateurs et donc le déploiement du site
-insertion d’un bus
-insertion d’un salarié
Ces deux insertions suivantes permettent d’avoir les ressources minimum pour la création
d’un évènement le formulaire PHP exigeant un bus associé et un Salarié concerné pour la
création d’un évènement.

6. ​Intégration du planning en html et
CSS
6.1​ ​Structure de la page planning

Le template planning est constitué d’une div en haut de page contenant les éléments
nécessaires à la navigation temporel ainsi que les boutons d’options d’affichages des
événements. Les marqueurs précédés et suivis de “%%%” permettent d’être facilement
ciblés et remplacés dans le template par des éléments générés dynamiquement par PHP.
La div principale “calendrier” contiendra l’ensemble des activités générés par la vue PHP.

extrait du template html de la page planning

6.2 La disposition spatial des événements dans le planning
Le premier problème rencontré a été la disposition des activités dans le planning, en effet
la matérialisation graphique d’une activité dépend de la durée ainsi que de la date de
début, elle doit donc suivre des règles simples permettant de faciliter son placement. Il faut
aussi prendre en compte le fait que les activités doivent s’adapter selon la taille d’écran
afin de conserver la cohérence de la durée. Les activités seront donc positionnées avec la
propriété CSS absolute ce qui permettra leurs placements indépendamment les unes des
autres.

1-​ : La largeur de l’évènement est calculé en pourcentage
Les événements sont affiché sur une plage de 12h (une demi journée).
un élément de 100% de largeur équivaut donc à une durée de 12h.
et ​une heure correspond à 8.33%
La largeur de l’événement est calculé selon le principe suivant :
(durée en heure de l’événement)x8.33
Exemple : Un événement dure 6h.
6*8.33 = 50% la ​propriété CSS width sera donc de 50%​ pour cette activité.
Un événement de 6h fait donc bien 50% de la demi journée affichée.

2- : Le décalage horizontal de l’événement est calculé en fonction de sa date de début, on
multiplie le nombre d’heure par 8.33 afin d'obtenir le décalage correspondant par rapport à
la demi-journée consulté.
Exemple : L'événement commence à 2h30 du matin soit 2.5h on à donc 2.5x(100/12) =
21%, le décalage de cette activité sera donc de 21% vers la droite. cet activité aura donc
une ​propriété CSS right de 21%​.

3- : Le décalage horizontal s’appuie sur un algorithme codé en PHP permettant de prendre
en compte les événements qui sont simultanés afin de les décaler verticalement pour
éviter leurs chevauchements. Cet algorithme sera détaillé dans la partie technique du
dossier.
Par exemple si un événement s’étend de 14h à 22h et un autre de 12h à 17h il faut donc
en décaler un vers le bas afin d’éviter leurs superpositions dans le planning.
Exemple de propriétés CSS d’une activité :

6.3 Intégration du slider de création d’activités et interaction javascript

Le slider de création contient un menu accordéon composé de plusieurs panneaux
contenant les différentes étapes de création d’un évènement. Ce système me paraissait
pratique car il propose un affichage du formulaire par étapes et permet de gagner en
espace.

Par défaut le slider est masqué avec la ​propriété CSS hidden​ il est affiché au moment du
clic dans le calendrier avec une animation grâce à slideToggle.
La fonction combodate permet d’activer les “datetime picker” sur les champ input contenus
dans le slider.

6.4 Responsive et media query
Afin d’adapter le calendrier lors du passage sur un écran de taille réduit, les media query
sont utilisés. La feuille de style principale est chargée en premier “calendrier.css”, si la
largeur de l’écran passe sous les 768px alors on ajoute la feuille de style
“small_calendrier.css” enfin si la hauteur est inférieur à 400 px on ajoute la feuille de style
“vertical_small_calendrier.css”.

Ci-dessous un extrait de la feuille de style “small_calendrier.css”. Le calendrier ainsi que
les deux barres passent à 100% de la largeur afin de gagner en lisibilité le panneau
d’information latéral devient masqué et s'affichera à l’aide de javascript lors du clique sur
une activité.

7. ​Architecture MVC et design
patterns
7.1 Exemple de fonctionnement pour la récupération de la liste des salariés

Le fonctionnement Modèle Vue Contrôleur permet de séparer les différentes tâches du
code, la vue va gérer tout ce qui est affichage en renvoyant un code html, le modèle
interroge la base de donnée et les transmet au contrôleur, ce dernier traite les données
reçues, effectue les différents calculs et transmet à la vue les donnée à afficher.

7.2 Principe de fonctionnement et du cheminement de l’information dans le code
1-

Lorsque l’utilisateur accède à la page d’administration des données, le contrôleur
d'événement est inclus puis le fichier de template est chargé avec la fonction
“file_get_contents”​.
Pour obtenir la liste des salariés contenus dans la base de données la fonction de
remplacement ​“str_replace” récupère le contenu html final renvoyé par la méthode
“control_get_salaries”​ et remplace le marqueur du template par ce contenu.
2-

La méthode ​“control_get salaries” récupère le tableau de salarié grâce au manager et le
transmet à la vue afin de générer le code HTML puis retourne le résultat : ​“return
$html_out”​.

3-

La méthode ​“get_all_salaries” du manager exécute la requête sur la base de données et
récupère les données dans la variable ​“$données_salaries”​. La boucle se charge ensuite
de créer les objet ​“salaries”​ en transmettant les données au constructeur de celui-ci.

La classe ​“Salarie” est ainsi hydratée avec les données transmises à son constructeur,
celui-ci fait appel à la méthode d’hydratation des attributs et les initialise avec les données
récoltées précédemment sur la base de données.

4-

Les salariés sont à présent créés dans un tableau d’objets ​“$salaries”, le contrôleur les a
transmis à la vue. La vue se charge maintenant de générer le code HTML avec la fonction
“vue_liste_salarie” elle reçoit donc en paramètre le tableau de salariés et commence par
créer la structure html suivante :
-Le nom de la liste en question avec la balise ​<label>​.
-La div contenant la liste.
-La liste est générée avec une boucle foreach sur le tableau de salariés. Cette boucle
générera le contenu de la liste avec la balise ​<option>. L’option de balise ​“value”
correspond à l’identifiant du salarié récupéré à l’aide de la méthode
“get_identifiant_salarie”​, l’affichage est une concaténation des attributs nom, prénom et
fonction récupérés grâce aux getter de la classe Salarie.
Enfin, le code HTML final est envoyé au contrôleur.

7.3 Connexion à la base de données avec le Singleton

La connexion à la base de données s'effectue en passant par le ​Singleton Connexion​, j’ai
choisi ce design pattern car la connexion doit être effectuée qu’une seule fois dans le
déroulement du programme. Les ​“define” permettent de renseigner facilement les
paramètres nécessaires à la connexion.
l’attribut ​“_cnx” est static car il est commun à toute les instances de la classe, aucun
constructeur n’est défini obligeant l'appelle de l’unique méthode ​“get_connexion”​.
Cette méthode se chargera soit de créer une nouvelle connexion si elle n’existe pas
“if(!isset(self::$_cnx))” à l’aide de l’objet PDO, soit de renvoyer la connexion actuelle si
elle a déjà était créée.

Chaques modèles sont ensuites initialisés avec l’objet de connexion ​“$cnx” pour pouvoir
communiquer avec la base de données.

8. ​Récupération et traitement des
évènements du planning
8.1 La récupération des évènements

1- Sélection de la demi-journée à récupérer
Pour récupérer les évènements sur une demi-journée précise à une date précise, la
méthode commence par définir deux variables contenant le “datetime” du début de la
demi-journée ​“$datetime_debut_demi_j” et le “datetime” de fin de la demi-journée
“$datetime_fin_demi_j”​. Ces deux variables sont créés selon une condition afin de définir
les variables en fonction de la demi journée ciblé.
Par exemple si l’on veut récupérer tous les évènements qui ont eu lieu le 2014-01-07 de
midi à minuit on concatène cette date avec “00:00:00” et “12:00:00” ce qui donnera la
plage horaire suivante : ​“2014-01-07 00:00:00” à “2014-01-07 12:00:00”​.

2- la requête en détaille

-On sélectionne l’id, le type, le titre, la date de début et de fin de l’évènement
-La fonction ​TIMESTAMPDIFF permet de calculer la différence de deux datetime ce qui
permettra ensuite de les ordonner selon leur durée.
-Afin de ne récupérer que les événements dans la plage horaire définie on commence par
cibler seulement ceux dont leur date de fin est supérieur ou égale au début de la
demi-journée sélectionné et dont leur date de début est inférieure ou égale à la fin de la
demi-journée à afficher
Exemple d’une sélection :

Enfin on les trie par ordre ascendant de la date de début des évènements afin de les
remonter du plus tôt ce qui permettra de faciliter leurs traitements plus tard.

Une fois la requête effectuée, les événements sont créés sur le même principe que les
salariés par hydratation des attributs d’un nouvelle évènement à chaque tour de boucle.
Enfin si le tableau d’événements existe on le renvoie et on sort de la méthode sinon on
renvoie la valeur NULL pour indiquer qu’aucun évènement n’existe sur cette demi-journée.

8.2 Le traitement des événements

Ci-dessus la méthode la boucle principale de traitement des événements. (Extrait du
contrôleur d’événements)
Les évènements à présent récupérés il faut les traiter avant de les envoyer à la vue, c’est
à dire définir leurs caractéristiques visuels : position de début, longueur, hauteur dans le
planning, couleur selon leurs types. Afin de traiter chaque événement on boucle sur le
tableau d'évènements renvoyé et on récupère la vue généré dans la variable ​“htm_out”​.

Le traitement pour un évènement.
1On stock chaques attributs de la classe “Evenement” dans de nouvelles variables.

2La couleur de l’événement est définie à l’aide de la fonction ​“couleur_type”​, la couleurs est
définie en css en fonction du numéro correspondant au type.

3On convertit chaques datetime en ​“timestamp”​ afin d'effectuer des calculs ensuite.

4-

Ces deux lignes de code servent à retirer la partie de l’événement qui est en dehors de la
demi-journée sélectionnée en effectuant une comparaison comme l'explique le schéma
suivant.

On retient la valeur maximum entre le début de la demi-journée à afficher et le début de
l'événement. Idem pour la fin, on retient la valeur minimum entre la fin de la demi-journée
et la fin de l’événement ce qui permettra de tronquer la partie qui sort de l’affichage.

5On extrait à présent l’heure et les minutes des ​“timestamp”​ à l’aide de la fonction ​“date”
afin de pouvoir finir le traitement. La fonction ​“date”​ renvoie une chaîne de caractère il faut
donc utiliser la fonction ​“intval”​ pour obtenir le nombre entier correspondant dans le but de
pouvoir effectuer des calculs plus tard.

La méthode privée de conversion des minutes en heures est ensuite appelée pour obtenir
l’heure à partir des minutes. Par exemple si “$heure_debut” vaut 4 et “$minute_debut”
vaut 30 alors la méthode convertira le tout en heure et renverra 4.5 correspondant bien à
4H30.

ci-dessous, la méthode de conversion.

6A présent il faut calculer la longueur en pourcentage ainsi que la marge droite pour définir
la position et la taille de la div représentant une ​“activité”​ dans le planning.
Pour cela on calcul la durée de l’évènement en faisant la différence entre l’heure de fin et
l’heure de début et on multiplie le tout par 8.33% qui correspond à une heure sur les 12 de
la demi-journée.
la position est calculée en faisant la différence entre l’heure de début de l’événement et
l’heure de début de la demi-journée à afficher on multiplie ensuite le tout par 8.33% pour
décaler la div en pourcentage correspondant au nombre d’heures entre le début de
l'événement et le début de la demi-journée à afficher .

Exemple : On demande au planning d’afficher la deuxième demi-journée c’est à dire tout
les événements situés entre 12h et 24h, on a un événement dans cette plage horaire qui
commence à 18h et fini à 24h. On a donc la configuration suivante :
$heure_demi_j = 12
$heure_d = 18
$heure_f = 24
$duree = 24 - 18 = 6
$taille = 6*8.33 = 50
L’événement dure 6h c’est bien 50% de l’affichage sur 12h
$position_début = (18-12)*8.33 = 50
l’événement commence bien au millieux du planning c’est à dire avec une marge à
droite de 50%

7La dernière étape consiste à positionner les événements verticalement dans le planning
pour ne pas qu’ils se superposent. Concrètement on définit la hauteur de chaque activité
en multipliant le numéro de ligne par la hauteur de la div représentant une activité.
Principe de fonctionnement​ :
rappel : les événements sont triés par la requête du plus tôt au plus tard.
1- On place le premier événement sur la première ligne et on stock l’heure de fin (17h).

2- l’heure de l’événement qui se termine le plus tard sur la première ligne est 17h et le
nouvel événement que l’on veut placer commence à 14h50 et se termine à 19h il ne peut
donc pas être placé sur la première ligne qui est occupée jusqu’à 17h on crée donc une
nouvelle ligne et on stock l’heure de fin du nouvel événement dans le tableau pour la ligne
numéro 2.

3- Le dernier événement à placer commence à 18h30 et la première ligne est libre à partir
de 17h on peut donc placer l’événement sur la première ligne et on change la valeur de la
première ligne en lui donnant la valeur de l’heure de fin de l’événement qui vient d'être
placé

La méthode de décalage vertical :

8On dispose à présent de tout les données nécessaires : l'identifiant, le titre, la position de
début, la taille, la hauteur ainsi que la couleur de l’événement. Ces données peuvent être
passées en paramètre à la vue pour générer le code html de l’activité.

9. ​Le panneau d'informations avec
Ajax
9.1 Présentation du panneau d'information
Le panneau d’information est situé à droite du
planning, il sert à afficher le détail d’une
activité sélectionnée. Il faut donc pouvoir le
consulter facilement et sans recharger la
page, c’est pour cette raison qu’Ajax est
utilisé pour cette fonctionnalité.

​Le panneau d'informations

9.2 Structure HTML du panneau d’information
Ci-dessous, un extrait de la vue générant le panneau d’informations. Les balises <p>
portant la classe html “affichage” ne contiennent aucun texte pour l’instant, c’est au
moment de la requête Ajax que les données seront attribuées avec les valeurs récoltées
sur la base de données selon l’événement cliqué.

9.3 La requête Ajax en détail

1- On commence par détecter le
$(“.activites”).on(“click”, function { … } )​.

clic

sur

une activité dans

le planning

2- ​La propriété CSS “border” de l’activité sélectionnée est modifiée afin de mettre celle-ci
en évidence.
3- L’identifiant de l’activité sélectionnée est récupéré : ​$(this).attr(“id”)​.
4- On effectue la requête sur la page planning.php en lui transmettant l’identifiant de
l’activité avec GET.
5- La page planning reçoit l’identifiant dans la variable ​$_GET[‘activite’]​. Celui-ci est
envoyé au contrôleur d'événements qui va se charger d’appeler la méthode du manager
afin de récupérer les informations d’un événement avec son identifiant. Le tableau est
ensuite encodé en ​JSON ce qui permettra à javascript de récupérer facilement les
données récupérées en data.

6- La data récupérée en ​JSON​ est convertie en tableau par javascript afin d'extraire et
stocker chaque valeur dans des variables.

7- Les données sont ensuite directement exploitées pour mettre à jour le panneau
d’information.

10. ​Authentification, accès aux
pages et sécurité
10.1 Authentification

La page d’authentification dispose d’un formulaire comportant l’identifiant et le mot de
passe. Ils sont envoyés à la page d’accueil qui va traiter le formulaire et créer les variables
de session si l’identifiant et le mot de passe correspondent à un utilisateur dans la base de
données.

La méthode d’authentification du contrôleur d'utilisateur reçoit en paramètre un objet
utilisateur préalablement hydraté avec les données du formulaire de login :

La méthode de controle d’authentification commence par crypter le mot de passe en ​sha1
en modifiant directement l’attribut de l’utilisateur reçu. L’utilisateur est ensuite passé au
manager :

la manager se charge ensuite d'effectuer la requête à la base de données en
sélectionnant le privilège de l’utilisateur ainsi que son identifiant puis renvoi le résultat.

Si le résultat n’est pas NULL c’est que la requête a fonctionné et que l’utilisateur existe
bien dans la base de données, on instancie donc un nouvel utilisateur avec ses privilèges
(administrateur ou non) ainsi que son identifiant. Si le résultat est null le contrôleur
renverra ​“false”​.

la condition test si le contrôleur renvoie NULL dans ce cas la session est directement
fermée. Sinon les variables de sessions sont créées avec les données de l’utilisateur qui
vient d’être authentifié.

10.2 Accès aux pages et sécurité
Le html de la page n’est généré que si l’utilisateur est authentifié, une condition commence
par vérifier si la variable de session contenant le privilège existe. Si cette variable existe
on est authentifié, on vérifie donc à présent si l’utilisateur est administrateur, si c’est le cas
on génère le contenu html de la page stockée dans la variable ​“$html” avec ​“echo” sinon
on indique à l’utilisateur que la page n’est pas accessible avec ces privilèges.

11. ​Manuel de déploiement
1 - Pré-requis :
- Serveur Apache
- Serveur Mysql
- phpmyadmin
2 - Créer une nouvelle base de données vide et un utilisateur php my admin(à ré-utiliser
au point 5.).
3 - Mettre en place la structure de la base de données à l’aide du fichier script :
structure.sql
4 - Insérer le jeu de données minimum à l’aide du fichier script : ressources.sql
5 - Copier le répertoire « planning_idelis » à la racine apache du serveur.
6 - Renseigner les paramètres suivant dans le fichier (racine
dusite)/modele/Connexion.php
- HOST : localhost
- BASE : nom de la base de données
- UTILISATEUR : nom d’utilisateur de la base de données
- PASS : Mot de passe de la base de données
7 - Accéder au site avec le nom de domaine sur lequel il se trouve en se connectant à
l’aide des identifiants de l’utilisateur par défaut :
- Utilisateur : root
- Mot de passe : toor

12. ​Annexes

12.1 Compétences acquises en milieux professionnel
CPP1 : Développer une application client-serveur
-Maquetter une application ​✓

-Concevoir une base de données ✓

-Mettre en place une base de données ✓

-Développer une interface utilisateur ✓

-Développer des composants d'accès aux données ✓

CPP2 : Développer une application web
-Développer des pages web en lien avec une base de données ✓

-Développer une application simple de mobilité numérique​ ✓
-Utiliser l’anglais dans son activité professionnelle en informatique​✓

12.2 Diagramme de classe


Aperçu du document PerezLuc.pdf - page 1/56

 
PerezLuc.pdf - page 2/56
PerezLuc.pdf - page 3/56
PerezLuc.pdf - page 4/56
PerezLuc.pdf - page 5/56
PerezLuc.pdf - page 6/56
 




Télécharger le fichier (PDF)


PerezLuc.pdf (PDF, 5.8 Mo)



Sur le même sujet..





Ce fichier a été mis en ligne par un utilisateur du site. Identifiant unique du document: 00573638.
⚠️  Signaler un contenu illicite
Pour plus d'informations sur notre politique de lutte contre la diffusion illicite de contenus protégés par droit d'auteur, consultez notre page dédiée.