SAÉ 3.01 - Développement d’une application

Après la conception d'un MCD (Modèle Conceptuel de Données), plusieurs solutions pour générer la structure de la BD s'offrent à nous. Nous pouvons utiliser la solution classique de la génération du script SQL à exécuter sur le SGBD choisi. Cependant, depuis quelques années, une nouvelle option est née : l'utilisation d'un ORM (« Object Relational Mapper »), comme Doctrine. Toutefois l'emploi d'un mapper peut impliquer de devoir s'écarter des règles et des normes d'une bonne modélisation et d'altérer le MCD. En effet, L'ORM ne permet pas de transposer immédiatement l'ensemble des possibilités offertes dans les MCD et quelques modifications s'imposent, pour adapter le MCD à la gestion et la compréhension de certains types d'associations du « mapper ».

La suite de ce document se concentre uniquement sur l'utilisation de l'ORM Doctrine.

Doctrine est un ORM très utilisé lors de développement de site web en PHP. L'un de ses intérêts est son intégration dans Symfony qui propose un générateur d'entités (via le « MarkerBundle »), qui comme son nom l'indique permet de générer simplement une classe en PHP représentant une entité (niveau conceptuel) et liée à une table (niveau physique dans la BD). En complément, pour éviter de devoir créer les relations à la main et éviter une écriture d'instructions trop complexe, le MCD a besoin d'être simplifié. Ainsi, tout type influençant les clefs primaires lors de leur traduction en MLD doit être simplifié, cela comprend les héritages, les associations « n,m » avec attributs et les liens identifiants. Nous allons donc étudier comment adapter un MCD pour le rendre compatible avec Doctrine.

Même si la solution de facilité serait de générer dès le début un MCD compatible Doctrine, ce dernier ne respecterait pas les bonnes règles de conception et vous iriez à l'encontre de la philosophie d'une bonne conception à savoir : Au niveau conceptuel, faire complètement abstraction de l'aspect technologique afin de pouvoir rester stable face à son évolution. Aussi, transformer un MCD pour le rendre compatible avec Doctrine est bien une dénormalisation en soi et doit impérativement être réalisé après la conception d'un MCD respectant les règles de l'art.

Vous mettrez en pratique la méthode agile pour la gestion de votre projet. Vous effectuerez la planification dans Microsoft Planner avec une suggestion forte pour cette organisation :

• Un à deux sprints par semaine
• Une à deux réunions de sprint par semaine (une heure) pour définir les objectifs et éventuellement faire un bilan du sprint précédent
• Daily (une réunion par jour comme son nom l'indique) pendant laquelle chaque membre présente :
  • Travail effectué
  • Travail à faire
  • Problèmes rencontrés
• Proposition de découpage des états du Kanban :
  • « Backlog »
  • À faire
  • En cours
  • « Merge request »
  • Revue de code en cours
  • Fait

Afin de leur permettre de suivre votre avancement, vous ajouterez les enseignants de la SAÉ dans votre planification Microsoft Planner dès le début du projet.

Vous devrez impérativement respecter les contraintes de réalisation suivantes :

• Votre application sera basée sur Symfony et respectera les bonnes pratiques vues en TP
• Vous utiliserez une base de données MySQL
• Votre projet comportera des données, factices ou non, sous formes de « fixtures »
• Les mises en forme CSS devront obligatoirement utiliser « flexbox », être pensées « mobile first » et faire usage des « media queries » pour proposer un affichage correct quelle que soit la largeur d'affichage
• Des tests permettront de vérifier a minima le bon fonctionnement de certaines parties de l'application

Les tâches proposées ci-dessous sont globalement triées par ordre chronologique de réalisation. Il est cependant tout à fait possible de mener un grand nombre d'entre elles en parallèle. Une bonne répartition des tâches vous permettra d'avancer rapidement sans engendrer de conflits dans l'édition des fichiers.

• Finalisation du MCD
• Adaptation du MCD pour pouvoir utiliser Doctrine facilement
• Création des entités avec le « MakerBundle »
  Information

  La construction des entités engendre possiblement des incohérences de versions de la base de données si elle est réalisée par plusieurs personnes. Utilisez méticuleusement les migrations pour éviter ces problèmes en faisant en sorte que la base de données soit toujours à jour.

• Construction de « fixtures » permettant le remplissage initial de la base de données
• Création du modèle de page (« template ») général de l'application
• Création de la feuille de style générale de l'application
• Création des modèles des pages spécifiques
• Mise en œuvre des fonctionnalités du cahier des charges
• Mise en place du « back-office »
• Mise en place de tests vérifiant sommairement certaines fonctionnalités
• Mise en production de l'application sur un serveur Web/BD configuré par vos soins

La précédente liste de réalisations constitue presque les livrables successifs. L'échéance principale est la soutenance du projet.

• Point hebdomadaire avec votre intervenant de « R3.04 - Qualité de développement » lors de la séance de TP
• Semaine numéro 2 : soutenance des projets par groupe de TD

La réalisation générale conduira à une note qui sera évidemment individualisée en fonction des contributions de chacun. La qualité du travail et le respect des consignes de réalisation sont tout aussi importants que la réalisation en elle-même.