11
Alexis
Alexis LAMANDE edited this page 2 years ago
Retour Accueil
Alexis LAMANDÉ
Nombre d'heures total : ~ 135 heures
Concevoir le diagramme de cas d'utilisation (~ 2 heures):
- Afin de pouvoir démarrer le projet, il faut tout d'abord réaliser un diagramme de cas d'utilisation. Celui-ci doit retracer toutes les possibilités offertes aux utilisateurs. Cela nous permet d'avoir la liste des acteurs, des actions et des différentes vues à créer. J'ai utilisé StarUML pour cette tâche.
Concevoir le MCD (~ 2 heures) :
- Concernant la conception au niveau de la base de données, j'ai tout d'abord réalisé un Modèle Conceptuel des Données. J'ai donc réalisé les principales tables permettant de stocker et décrire nos données. Grâce à ce modèle, on peut réaliser un MLD.
Concevoir le MLD (~ 3 heures) :
- Au niveau de la conception du Modèle Logique des Données, je l'ai crée à partir du MCD, en réaliser de nouvelles tables permettant de modéliser des listes de données associés à une table. Par exemple, un formulaire va être composé d'une liste de questions.
Concevoir l'UML (~ 8 heures) :
- D'un point de vue conception d'UML. J'ai réalisé la version finale de ce dernier en ajoutant des patrons de conception. J'ai repris les classes Controller et Model. J'ai crée une hiérarchie au niveau des business class afin de profiter du polymorphisme offert par le langage orienté objet. J'ai Ajouter deux patrons de conception Stratégie nous permettant de définir pour chaque type de question la manière de les afficher et des traiter les réponses associées.
Coder les classes métiers (~ 3 heures) :
La classe Keyword :
- Cette classe contient simplement un id et une chaine de caractères associées.
La classe Response :
- Cette classe est composée d'une liste de question et une liste de réponse. Dans le bonne ordre, cela permet d'associé ces deux éléments. Nous pouvons alors avoir une liste de question réponse permettant ainsi de crée une réponse complète à un formulaire.
La classe mère Question :
- Cette classe permet de définir les informations que contiendront nos questions de manière générale et obligatoire. Nous pourrons ensuite définir plus précisement la nature des questions tout en conservant les propriétés basiques grâce à un héritage sur cette classe Question.
Les classes filles de Question :
- TextQuestion, ListBoxQuestion et CheckBoxQuestion sont les trois classe filles concrètes de notre classe abstraites Question. Elle permette de changer le comportement des différents types de question en profitant du polymorphisme.
La classe Form :
- La classe Form contient une liste de questions, nous pouvons ensuite traiter chaque réponse de manière différentes pour chaque question en fonction des choix de l'administrateur.
Coder un Front Controller provisoire (~ 6 heures) :
- Afin de remplacer le routing, il fallait trouver une solution efficace. J'ai donc développer un moyen générique qui peut être réintégrer à n'importe quel projet PHP. Le Front Controller va récupérer l'action passé dans l'URL et va vérifier si celle ci correspond à une fonction d'un des controllers. Si oui, elle sera alors appelé et le Model gérera la suite.
Implémenter la stratégie IPrintQuestionStrategy (~ 6 heures) :
- Grâce au patron de conception Stratégie, nous avons pu définir une manière d'afficher une question en fonction de sa nature. Par exemple, une TextQuestion ne devra pas être afficher de la même manière qu'une CheckBoxQuestion. J'ai donc réalisé cela grâce de l'intégration de code HTML de manière dynamique en fonction du type de question, tout ça en profitant du polymorphisme offert par la programmation orientée objets.
Réaliser le rendu de gestion (~ 8 heures) :
- Rédaction intégrale de la partie 1
- Réalisation de la partie 2 à l'exception des PERT charges et des GANTT
- Réalisation intégrale de la partie 3 (sauf les parties individuelles)
Coder la classe ModelCandidate (~ 8 heures)
- Cette classe contient la récupération du code HTML d'un formulaire et l'envoie des réponses d'un utilisateurs en faisant appel à notre API. J'ai codé ce Model en utilisant la stratégie IPrintQuestionStrategy. De cette manière, j'obtient facilement le code à intégrer. Concernant la réponse d'un utilisateur pour un formulaire, je récupère à l'aide d'un tableau "answers" présent dans chaque attributs "name" de mes balises "input" les réponses et les catégories associées à chaque questions. Je réalisé cela grâce à la division, d'une chaine de caractères au préalable concaténer de manière simple, en différents éléments permettant de décrire une réponse.
Coder la classe ControllerCandidate (~ 4 heures)
- Dans cette classe, on retrouve la gestion d'appel des vues et du model d'un candidat afin d'arriver au bon résultat lors de l'affichage du contenu dans notre page HTML. Cela est gérer avec les actions que l'utilisateurs transmet dans l'URL avec les formulaires présent dans notre application.
Coder la classe ModelAdmin (~ 10 heures) :
- Dans cette classe, on retrouve toutes les actions possible en tant qu'administrateur. Premièrement, concernant l'ajout d'une question à un formulaire, je récupère le type de la question (TextQuestion, CheckBoxQuestion...), le contenu, les réponses possibles et les catégories associées à chacune. Je les ajoute ensuite en base de données grâce à l'API. J'ai également codé l'ajout de catégories et la création d'un nouveau formulaire.
Coder la classe ControllerAdmin (~ 4 heures)
- Dans cette classe, on retrouve la gestion d'appel des vues et du model d'un administrateur afin d'arriver au bon résultat lors de l'affichage du contenu dans notre page HTML. Cela est gérer avec les actions que l'utilisateurs transmet dans l'URL avec les formulaires présent dans notre application. Il peut également ajouter, modifier et supprimer des éléments de notre base de données.
Coder l'interface Front-End JavaScript pour l'administrateur (~ 4 heures)
- J'ai réaliser des actions associés à un click afin de modifier la vue en fonction des choix de l'administrateur. Il peut ainsi afficher ou non les différentes données présente dans notre application. Cela rend l'interface beaucoup plus simple à utiliser et beaucoup plus compréhensible.
Correction de Bugs, CodeSmells... (~ 20 heures)
Coder les vues avec BootStrap (~ 8 heures)
Coder les Controllers de la deuxième application (~ 2 heures)
Coder les Models de la deuxième application (~ 4 heures)
Coder les Gateways de la deuxième application (~ 1 heure)
Intégrer une vidéo en HTML provenant de UCA Media Manager (~ 1 heure)
Réalisation du rapport (~ 12 heures)
Coder la fonction qui permet de conseiller à l'administrateur les profils intéressants (~ 4 heures)
Réalisation du diaporama de la soutenance (~ 15 heures)
Table of Contents
- Nombre d'heures total : ~ 135 heures
- Concevoir le diagramme de cas d'utilisation (~ 2 heures):
- Concevoir le MCD (~ 2 heures) :
- Concevoir le MLD (~ 3 heures) :
- Concevoir l'UML (~ 8 heures) :
- Coder les classes métiers (~ 3 heures) :
- La classe Keyword :
- La classe Response :
- La classe mère Question :
- Les classes filles de Question :
- La classe Form :
- Coder un Front Controller provisoire (~ 6 heures) :
- Implémenter la stratégie IPrintQuestionStrategy (~ 6 heures) :
- Réaliser le rendu de gestion (~ 8 heures) :
- Coder la classe ModelCandidate (~ 8 heures)
- Coder la classe ControllerCandidate (~ 4 heures)
- Coder la classe ModelAdmin (~ 10 heures) :
- Coder la classe ControllerAdmin (~ 4 heures)
- Coder l'interface Front-End JavaScript pour l'administrateur (~ 4 heures)
- Correction de Bugs, CodeSmells... (~ 20 heures)
- Coder les vues avec BootStrap (~ 8 heures)
- Coder les Controllers de la deuxième application (~ 2 heures)
- Coder les Models de la deuxième application (~ 4 heures)
- Coder les Gateways de la deuxième application (~ 1 heure)
- Intégrer une vidéo en HTML provenant de UCA Media Manager (~ 1 heure)
- Réalisation du rapport (~ 12 heures)
- Coder la fonction qui permet de conseiller à l'administrateur les profils intéressants (~ 4 heures)
- Réalisation du diaporama de la soutenance (~ 15 heures)
- Gestion du travail
- Compte rendu des réunions
- Diagrammes
- Documentation technique