Version: Automne 2021 (1.0.1)
Si vous trouvez des incohérences ou vous avez des questions, créez un Issue.
Le laboratoire consiste à analyser, concevoir, implémenter et tester une solution pour satisfaire les besoins en ce qui concerne une application cliente. Voir le document des exigences du client
Le diagramme suivant décrit les différentes parties du système. Nous cherchons à simplifier les aspects techniques qui ne sont pas le sujet principal du cours: cadres d'application frontale, services REST, utilisation de bases de données, etc.
Il faut que la solution respecte la séparation des couches présentation et domaine. Les opérations système doivent être le mécanisme pour traverser ces deux couches (pas de logique applicative dans la couche présentation). Pour vérifier cet aspect, la figure suivante est utile:
Notez que la logique du routeur (web) est simple :
- décortiquer l'argument, p. ex. nom, de la requête et
- appeler une opération système, p. ex.
demarrerJeu(nom), qui est une méthode définie dans une classe (le contrôleur GRASP) dans la couche domaine.
Cette petite présentation vous donne d'autres astuces pour valider votre solution sur le plan de la séparation des couches.
En plus du squelette de démarrage de projet pour Node.js, des exemples de code supplémentaires pour vous aider dans votre projet sont aussi disponibles.
Les solutions impliquant les langages et technologies autres que ceux dans le squelette ne sont pas permises.
Beaucoup de cadres d'application Web sont faciles à utiliser pour une application simple, mais il n'est pas toujours possible d'appliquer une bonne conception lorsqu'il s'agit d'une application complexe. Pour le respect des aspects importants de la conception (séparation des couches, opérations système avec contrôleur indépendant, possibilité d'avoir des modèles du domaine complexes, etc.), vous ne pouvez pas utiliser les technologies/solutions suivantes :
- Cadre d'application d'interface utilisateur: Vue.js, React, Angular, etc.
- Base de données: SQL et NoSQL
Le système de gestion des bordereaux des étudiants (SGB) est un système externe utilisé par votre application pour récupérer les informations sur les enseignants, les cours, les étudiants ainsi que sauvegarder les notes obtenues par les étudiants lors de la réalisation d'un questionnaire ou la correction d'un devoir. Vous n'avez pas à modifier ce système.
SGB est une application ayant son propre modèle du domaine (comprenant les concepts comme l'université, les cours, les groupes-cours, les étudiants, les évaluations. Bien que votre application SGA ne traite que l'aspect pédagogique en ligne, votre analyse de SGA doit comprendre les classes conceptuelles de SGB.
Cliquez ici pour voir les détails sur le MDD du SGB
Veuillez noter que l'implémentation proposée de ce système n'a aucun mécanisme de persistance des données. Il possède une interface de configuration permettant de nettoyer le contenu correspondant aux notes.
L'API de SGB est disponible avec le code source. Lisez le README.md de SGB pour savoir comment générer cette documentation.
Ce texte est normalement un extrait du plan de cours:
Chaque membre d'équipe est responsable de la totalité du travail réalisé et remis par son équipe. Toutefois, les membres de l'équipe ayant réalisé un travail peuvent décider de ne pas mettre sur le rapport le nom d’un ou de plusieurs autres membres qui n'ont pas fait une contribution (conception et codage) significative à l’itération. Avant la remise du travail, un courriel doit être envoyé en copie conforme à tous les membres de l’équipe, aux auxiliaires d'enseignement ainsi qu’à l’enseignant pour indiquer les raisons du retrait du nom. Un membre de l'équipe dont son nom n'est pas sur un travail de laboratoire reçoit une note de "0" pour le travail.
Vous devez implémenter une interface utilisateur minimaliste pour la réalisation de chacun des cas d'utilisation. Le but du laboratoire étant d'appliquer la méthodologie d'analyse et de conception enseignée dans LOG210, le squelette à un mécanisme simple pour faire l'application frontale. Il s'agit des gabarits HTML (pug, etc.) plutôt qu'un cadriciel complexe comme Angular.js, React, Vue, etc. Pour la même raison, les technologies de bases de données ne sont pas proposées pour la solution. Il est possible de réaliser le laboratoire sans passer du temps sur ces aspects que vous verrez plus en profondeur dans d'autres cours spécialisés.
Les corrections interactives à chaque itération se déroulent selon le processus suivant. Les auxiliaires d'enseignement veillent au bon déroulement de la correction, mais ce sont les étudiants qui doivent prendre l'initiative de suivre ces étapes à la lettre.
L'objectif de cette partie est de montrer le fonctionnement de l'application au client et de documenter sa rétroaction dans la section Évaluation du plan d'itération. Dans le plan d'itération, vous identifiez des critères d'évaluation. Ces critères d'évaluation seront considérés lors de la démonstration. La démonstration se déroule selon les étapes suivantes :
L'objectif de cette partie et de montrer que l'application est conforme aux principes vus en classe et à la conception des étudiants. Elle suit les étapes suivantes :
- Vérifier correspondance code et RDCU
- une méthode avec le même nom est présente dans un routeur. Elle doit :
- commencer par /api/v1
- utiliser le verbe REST approprié
- extraire et convertir et vérifier la présence des paramètres de la requête HTTP
- faire un seul appel à la méthode du contrôleur et retourne sa réponse sous forme de JSON avec le code HTTP approprié
- intercepter et traiter les erreurs adéquatement
⚠️ Cette méthode ne doit pas retourner une vue. Pour ce faire, il faut faire une autre route qui appelle l'opération système.
- une méthode avec la même signature est présente dans un contrôleur.
- L'opération du contrôleur ne doit pas utiliser d'objets comme paramètres (exception: le réusinage "Introduce Parameter Object")
- Le retour d'opération correspond à une valeur primitive
- une méthode avec le même nom est présente dans un routeur. Elle doit :
- exécuter les tests
- des tests pour vérifier le scénario principal, les scénarios alternatifs et la gestion des erreurs de l'opération système sont présents. Ils doivent :
- être exécutés pour montrer leur fonctionnement
- appeler la route appropriée
- vérifier son code HTTP
- vérifier chacun des champs de la réponse
- des tests pour vérifier le scénario principal, les scénarios alternatifs et la gestion des erreurs de l'opération système sont présents. Ils doivent :
Le travail de laboratoire sera évalué en deux volets, soit la partie rapport et planification et la partie implémentation.
Voir la grille de correction pour plus de détails.
| Évaluation | Itération 1 | Itération 2 | Itération 3 | Total |
|---|---|---|---|---|
| Rapport et planification | a | b | c | (a + b + c) |
| Implémentation | - | - | d | d |
Les critères d'évaluation de chaque itération (a, b, c) sont documentés dans la section modalités d'évaluation.
Vous recevrez une rétroaction vers la fin de chaque itération, selon le processus itératif et évolutif. Notez que seulement l'évaluation (d) de la dernière itération comptera pour la note. De cette manière, on peut réduire les conséquences négatives des erreurs de planification et des difficultés avec la maîtrise des nouvelles technologies qui sont normales au début du projet.
Le calcul de la note pour cette évaluation est le suivant :
Le nombre de points minimal requis pour une note de 100% correspond au tableau suivant:
| Nombre d'étudiants | NbPoints | Évolution minimum Itération #1 |
Évolution minimum Itération #2 |
Évolution minimum Itération #3 |
|---|---|---|---|---|
| 2 | 5.50 | 1.50 | 1.50 | 2.00 |
| 3 | 8.25 | 2.25 | 2.25 | 3.00 |
| 4 | 11.00 | 3.00 | 3.00 | 4.00 |
| 5 | 13.75 | 3.75 | 3.75 | 5.00 |
| 6 | 16.50 | 4.50 | 4.50 | 6.00 |
Chaque itération nécessite un avancement (évolution) sur le plan des exigences par une valeur minimale.
Les points associés à chaque exigence sont définis dans la grille de correction
Cet avancement (évolution) est prévu dans les objectifs du plan d'itération et sera évalué lors de la démonstration.
Vous pouvez implémenter plus de points pour compenser les pertes durant la correction, mais pour les valeurs de d dépassant 100 %, le maximum est 110 %.
Si une équipe ne réussit pas à répondre adéquatement à une exigence (fonctionnalité, tests, correspondance aux artéfacts), cette dernière ne sera pas utilisée dans le calcul.
Notez que le calendrier des séances est différent pour chaque groupe-cours, mais les dates de remises suivent cette planification. Le rapport doit être prêt pour la démo afin de montrer la correspondance entre la conception et la solution.
| Itération | Plan d'itération | Démo / Rapport |
|---|---|---|
| 1 | Fin séance 3 du labo | Début séance 6 |
| 2 | Fin séance 7 du labo | Début séance 9 |
| 3 | Fin séance 10 du labo | Début séance 12 |
Note: le Plan d'itération doit être actualisé après l'évaluation et vous devez faire un "commit" dans le dépôt sur GitHub. C'est-à-dire qu'il faut compléter la section Évaluation du plan actuel et le remettre avant de faire le prochain plan.
Correction interactive du rapport de l'itération 1
À la deuxième semaine de l'itération 1, vous devrez présenter les artéfacts, l'implémentation et les tests des CU01a et CU01b à votre auxiliaire d'enseignement. Vous recevrez des commentaires pour vous aider avant la remise de votre premier rapport et de votre première démo. Cette activité est informelle, mais votre participation est notée et obligatoire.
Un plan d'itération doit être fait au début de chaque itération, suivant les conseils dans le gabarit de plan d'itération.
Après l'évaluation de votre itération, vous devez compléter la section Évaluation de votre plan.
Toutes les grilles d'évaluation se trouvent dans un chiffrier Google:
Vous pouvez faire une copie du chiffrier des grilles (pour les calculs hypothétiques) à partir de ce lien.
Vous ne devez implémenter que les cas d'utilisation que vous aurez spécifiés dans les objectifs de votre plan d'itération, mais vous pouvez utiliser le document d'exigences complet pour trouver l'information nécessaire à la réalisation de vos cas d'utilisation.
Assurez-vous que votre implémentation respecte la séparation des couches présentation et domaine.
Prenez note que nous sommes ouverts à toutes suggestions permettant d'apporter des améliorations au laboratoire. Nous analyserons chacune de vos suggestions.
Merci de votre participation et bon laboratoire.