Remise 4

La quatrième remise a comme date le 13 décembre 2020.

Au cours de cette itération, nous avons :

• Complété le récit obligatoire
• Ajouté des descriptions précises pour les erreurs
• Amélioré la qualité de notre code

Récits

Les récits utilisateurs sont présentés sur notre wiki.

• Remise 1 : Aventure 1, récits 1 à 4
• Remise 2 : Aventure 1, récits 6 à 8
• Remise 3 : Aventure 1, récit 5, et aventure 2, récits 1 à 3
• Remise 4 : Aventure obligatoire, récit 1

Burndown chart

Burndown chart de tous les récits complétés

![Burndown Chart de tous les récits complétés]https://i.imgur.com/GKHjIVo.png)

Lors de cette itération, chaque récit a été divisé de la même manière que l’itération précédente, soit en plus petites tâches, car cette approche avait bien fonctionné à l’itération 3. L’objectif était d’avoir des tâches indépendantes des autres, ce qui permettait à plus d’une personne de travailler sur un récit en parallèle. Sur le burndown chart, nous avons assigné un point à chaque tâche de chaque récit, car nous avions estimé qu’ils étaient tous relativement égaux en termes de complexité et de travail à accomplir.

Architecture logicielle

Notre logiciel se définit selon une architecture hexagonale (ports and adapters architecture). Notre domaine est au centre de cette architecture.

Nos couches externes (les ports) sont :

• api : Les ressources REST
• infrastructure : La persistance dans la mémoire vive
• filesystem : La gestion des fichiers de système
• smtp : L'envoi de courriel
• console : L'écriture dans la console (pour remplacer l'envoi par la poste)
• systemtime : Le temps du système (pour les “schedulers”)

Entre les couches externes et le domaine se retrouvent la couche de service, qui contient les services de domaine, les assembleurs et les convertisseurs.

Notre structure de fichiers est composée d'abord en module (accounts, parkings, ...) puis en couche (api, domain, ...).

Documentation C4

Le diagramme C4 a été fait avec diagrams.net (ancien draw.io). Ce lien permet de visualiser ces diagrammes dans diagrams.net de façon interactive.

Context

Container

Component

Component (étudiant)

Component (gestionnaire)

Component (surveillant)

Patrons de conception

Utilisés dans le logiciel

• Service layer : Afin d'orchestrer les opérations dans notre domaine, nous utilisons des classes de service. Celles-ci s'occupent simplement d'administrer qui fait quoi et quand. Ces classes s'occupent de l'ordre logique des choses, plutôt que des algorithmes agissant directement sur les données.
• Repository : Pour accéder à notre persistance depuis le domaine, nous utilisons une interface de Repository injectée dans nos services. Notre persistance actuelle est simplement sauvegardée dans la mémoire vive.
• Assembler : Pour faire le pont entre nos objets de domaine et nos DTOs, nous utilisons des classes permettant d'assembler un objet d'une couche à une autre.
• Factory : Afin de construire un objet de domaine valide, nous utilisons des classes de création. Ces classes permettent de construire un objet en fonction de certains paramètres et/ou de lui donner un identifiant unique (id, code, ...).
• Object Mother : Nos tests utilisent des valeurs aléatoires. Ces dernières doivent être valides selon nos règles d'affaire. Pour cela nous utilisons des classes possédant des méthodes statiques de création pour différents attributs de nos objets de domaine.
• Builder : Afin de construire des objets de domaine avec des valeurs aléatoires toujours valides selon nos règles d'affaire, nos tests utilisent des classes de construction. Nous jumelons ce concept à celui d'Object Mother. Au sein de nos tests, on peut retrouver un objet de domaine avec Object Mother et sans Builder, mais jamais l'opposé.
• Observer : Pour l'envoi de courriel en écoutant ce qui se passe dans les services et pour l’ajout de crédit carbone lorsque l’initiative correspondante reçoit de l’argent.

Considérés, mais pas encore implantés

• Strategy : Pour le calcul du montant dû à cause d'infractions, nous avons pensé injecter une stratégie de calcul à l'objet de domaine Bill. Ceci était une amélioration prévue si d’autres itérations étaient à faire, mais qui n’a pas pu être implémentée tout de suite. Le même genre de logique pourrait être appliqué aux vignettes de stationnement et aux passes d’accès.
• Bridge : Afin d'obtenir le bon fichier, nous avons pensé utiliser le patron de conception Bridge, qui permettrait d'injecter dans nos classes de calcul une classe permettant de lire un fichier et d'en ressortir les données. Nous n'aurions ainsi pas à lier le concept de type de fichier à classe qui ne sert qu'à calculer. Ça serait à implémenter si d’autres itérations étaient à faire.

Considérés, mais pas retenus

Au courant de la remise 4, aucun patron de conception n'a été considéré et donc aucun n’a été retenu.

API

Les routes disponibles dans nos GitHub Pages. Ces pages sont générées via une représentation de notre API REST en RAML.

Dette technique

• Les crédits carbones ont une fréquence de rafraîchissement fixe pour l'instant.
• Actuellement, dans les ressources pour générer les rapports de profits, l’année par défaut est fixée dans le code à 2020. Il pourrait être intéressant d’avoir une fonction ou quelque chose qui regarde si le paramètre est nul et si oui, retourner l’année courante.
• Les rapport d’utilisation par zones de stationnements utilisent l’année courante comme période pour la création de rapport. Ceci n’est pas exactement tel que demandé dans le récit 5 de l’aventure 1 et doit donc être révisé.
• En créant le module de temps, nous avons supposé que le fuseau horaire était celui utilisé par le système. Une bonne amélioration serait de la définir dans une classe de configuration et de s’en servir partout dans l’application.
• Lors de l’accès à la guérite, l’utilisateur doit préciser la date et l’heure ainsi que le numéro de sa passe d’accès. Pour la création de rapports des zones de stationnement, à ce moment, il nous faut le code de la zone de stationnement. Nous avons donc ajouté un code de zone de stationnement optionnel, car il y a des piétons, à la création d’une passe d’accès. Ceci est sûrement à revoir.
• La validation d’infraction pour un temps d’accès dépassé n’est actuellement pas implémentée. Donc, si un utilisateur entre à la guérite et y reste plus longtemps que son temps permis, il ne recevra pas d’infraction si un agent vérifie sa vignette de stationnement. Ceci est dû à un problème d’architecture : il n’y a pas actuellement de façon d’obtenir la passe d’accès associée à une vignette de stationnement. Cette partie du domaine est donc à revoir.

Notes importantes

• Pour pouvoir envoyer les courriels, il faut que le fichier data/emailSmtp.properties soit bâti correctement. Un fichier d’exemple vous sera remis à cette fin.
• Changer la fréquence des achats mensuels de crédits carbones : Nous avons laissez différentes variables statiques dans src/main/java/ca/ulaval/glo4003/interfaces/systemtime/SchedulerBuilder.java afin de tester des fréquences variées. Il faut changer la variable à la création du Trigger :

Trigger trigger =
          newTrigger()
              .withSchedule(CronScheduleBuilder.cronSchedule(<ici>))
              .build();