Apprentissages critiques ¶
- Élaborer et implémenter les spécifications fonctionnelles et non fonctionnelles à partir des exigences
- Appliquer des principes d’accessibilité et d’ergonomie
- Adopter de bonnes pratiques de conception et de programmation
- Choisir des structures de données complexes adaptées au problème
- Concevoir et développer des applications communicantes
- Utiliser des serveurs et des services réseaux virtualisés
- Organiser la restitution de données à travers la programmation et la visualisation
- Manipuler des données hétérogènes
- Formaliser les besoins du client et de l'utilisateur
- Identifier les critères de faisabilité d’un projet informatique
- Définir et mettre en œuvre une démarche de suivi de projet
- Appliquer une démarche pour intégrer une équipe informatique au sein d’une organisation
- Mobiliser les compétences interpersonnelles pour travailler dans une équipe informatique
- Rendre compte de son activité professionnelle
Introduction ¶
Cette SAÉ demande, après avoir collecté et formalisé les besoins d'un client, de développer une application de qualité répondant à ces besoins. L'application devra s'appuyer sur une base de données et sur un serveur. Le volume de travail par étudiant est fixé à 125 heures en dehors des séances de TP/TD.
Vous avez réalisé, en vous appuyant sur la ressource « R3.10 - Management des systèmes d'information », un cahier des charges et tous les documents d'analyse nécessaires à la réalisation concrète du projet que vous avez choisi. Nous estimons que cette partie représente environ 45 heures de travail personnel hors TP/TD.
La présente partie de la SAÉ vous donne la méthodologie de travail à respecter et les grandes étapes à réaliser. La réalisation de l'application s'appuie sur la ressource « R3.04 - Qualité de développement » et c'est donc votre intervenant de TP qui sera votre référent. Vous devriez y consacrer environ 80 heures de travail personnel, soit 10 heures par étudiant et par semaine.
Versionnage du projet ¶
Vous travaillerez en équipe de 4 à 5. L'un des membres aura la charge de créer le dépôt GitLab qui sera nommé « sae3-01 ». La collaboration entre les membres du groupe suivra les mêmes règles que celles présentées dans le TP « Collaboration avec Gitlab » :
- Un fichier «
README.md» présentera le nom, prénom et login des membres du groupe ainsi que les grandes lignes du projet et de sa mise en place - La branche principale sera protégée, aucun
commitdirect ne sera autorisé - Vos productions seront faites sous forme de branches qui seront soumises à la revue de code de vos partenaires et fusionnées lorsqu'elles sont considérées admissibles Information
Veillez à rebaser votre branche avant de la soumettre à la fusion (« merge request ») afin de limiter les conflits.
- L'équilibre entre les contributions des membres du groupe sera considéré Remarque importante
La note de chacun des partenaires sera proportionnelle à la quantité et la qualité de ses contributions.
- Chaque
commitsera le plus ciblé possibleRemarque importanteTout
commitqui ne respecte pas les règles, car il apporte trop de fichiers et/ou trop de nouveautés en une seule fois, sera sanctionné.En dehors de la mise en place du projet et de l'ajout des classes fournies, un
commitdoit introduire en une fois un seul des éléments suivants :- Une installation de bundle
- Une modification de configuration
- Une entité
- Un jeu d'essai (« fixtures », forge)
- Un jeu de tests
- La création d'un contrôleur et de la vue associée
- Une fonctionnalités particulière
- …
L'interface de gestion de versions
PhpStormpropose d'effectuer uncommitsur une partie des fichiers modifiés. Utilisez cette fonctionnalité pour structurer voscommits. - Chaque message de
commitsera clair et explicite - Vous veillerez à ce que vos nom et prénom réels et mail universitaire soient configurés dans
gitde façon identique à l'IUT et sur votre ordinateur personnel
Mise en place du projet ¶
Tout comme en TP, vous utiliserez Symfony pour réaliser votre projet.
Vous documenterez systématiquement les fonctionnalités, programmes, scripts Composer ou autres fichiers de configuration dans le fichier « README.md ».
Base de données ¶
Votre application va interagir avec une base de données MySQL. Cette base de données sera gérée automatiquement par Doctrine. Pour cela, vous devez transposer votre MCD en entités et relations Doctrine. Cette étape va demander quelques adaptations de votre MCD qui ont été décrites par Mme Prévost et qui sont reprises ci-après.
Introduction ¶
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.
Comment rendre Doctrine compatible avec un MCD
¶
Entité ¶
Doctrine est conçu pour gérer la persistance d'entités. Les entités sont des objets PHP qui peuvent être identifiés de manière unique par un identifiant (ou une clef primaire dans la table correspondante). Dans le cas d'utilisation courant du « MakerBundle » pour générer les entités, leur identifiant est construit automatiquement et s'appelle « id ».
Étudions, à présent, un à un les types de relations à adapter.
Association « n,m » porteuse d'attributs
¶
Toute association n,m porteuse d'attributs devra être transformée en entité, dans laquelle un identifiant interne sera ajouté. Les attributs portés se retrouveront alors dans la nouvelle entité. Les pattes d'association seront transformées en association de type « 1,n » avec le « 1 » du côté de l'association devenue entité.
Ces propos sont illustrés avec le MCD de la figure 1 et de sa version adaptée à Doctrine en figure 2.
n,m » porteuse d'attributs.
Doctrine.
Héritage ¶
Dans le cas d'un héritage, des 4 types de passage en MLD existants, seuls 2 sont compatibles : génération uniquement des entités filles et génération uniquement de l'entité parente. Comme à l'accoutumée, le choix entre ces 2 types se doit d'être guidé par le contexte de votre modélisation/application et des traitements que vous devrez réaliser.
- Dans le cas de la traduction « génération uniquement des entités filles », n'oubliez pas de gérer correctement les relations en lien avec le parent.
- Dans le cas de la traduction « génération uniquement de l'entité parente », n'oubliez pas de gérer correctement les relations en lien avec les filles, sans omettre l'évolution des cardinalités minimum et les contraintes null/notNull des attributs.
Par exemple, si la figure 3 représente MCD original alors la version adaptée par la traduction « génération uniquement de l'entité parente » donnerait le MCD de la figure 4, tandis que la version modifiée par la traduction « génération uniquement des entités filles » donnerait le MCD de la figure 5.
Doctrine de la figure 3 avec génération uniquement de l'entité parente.
Doctrine de la figure 3 avec génération uniquement des entités filles.
Puisqu'il est assez probable de rencontrer de l'héritage dans la gestion des utilisateurs, une preuve de concept liant héritage d'utilisateurs et authentification vous est proposée sous forme d'un dépôt GitLab.
Lien identifiant ¶
Dans le cas d'un lien identifiant, l'entité dépendante recevra un identifiant interne, tandis que les attributs qui étaient des identifiants explicites deviennent de simples attributs. L'association LI devient alors une simple relation de type « 1,n ». Ces propos sont illustrés avec l'évolution de idB et de l'association LI dans l'exemple de la figure 6 et de son MCD adapté à Doctrine en figure 7.
De plus, un index unique devra être créé sur la clef primaire de l'entité dépendante avant adaptation, dans notre exemple « (idA, idB) ».
Doctrine.
Conclusion ¶
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.
Réalisations demandées et progression suggérée ¶
Vous devez réaliser l'application décrite dans votre cahier des charges.
Méthode de travail : agile ¶
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
Contraintes de réalisation ¶
Vous devrez impérativement respecter les contraintes de réalisation suivantes :
- Votre application sera basée sur
Symfonyet 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
CSSdevront 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
Réalisations demandées ¶
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
Doctrinefacilement - Création des entités avec le «
MakerBundle»InformationLa 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
Échéances ¶
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
Évaluation ¶
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.
Pour vous évaluer, nous devons cloner votre dépôt GitLab, installer les dépendances, créer la base de données, charger les « fixtures » puis lancer les tests et démarrer le serveur Web. Veillez donc à ce que votre dépôt soit accessible et que les instructions pour installer et lancer votre application soient claires et précises. De plus, nous devons savoir ce que propose votre application. Ainsi, sans un minimum d'instructions sur les fonctionnalités présentes, sur les identifiants de connexion, sur les jeux de données disponibles et les procédures à réaliser, nous ne pourrons pas évaluer votre travail. Toutes ces informations doivent figurer clairement dans le fichier « README.md ».