Remise 2

La deuxième remise a comme date le 25 octobre 2020.

Au cours de cette itération, nous avons :

• Continué notre documentation, soit ce présent rapport et la documentation d'API
• Complété les récits 6 à 8 de l'aventure 1
• Corrigé des erreurs de logique diverses suivant la remise 1
• Implémenté les concepts d'argent et de factures à l'application

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

Burndown chart

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

Burndown chart par récit

Lors de cette itération, chaque récit a été divisé en plus petites tâches. 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 terme de complexité et de travail à accomplir.

Avec du recul, on remarque que pour le récit 7, nos trois tâches n’étaient pas tout à fait indépendantes, ce qui explique pourquoi les trois tâches ont évolués en même temps. Pour la remise 3, il serait intéressant de porter une attention plus prononcée sur la complexité de chaque récit pour éviter ce genre de situation.

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 les couches :

• assemblers : Pont entre les DTOs et objets de domaines
• services : Orchestration du domaine, indications aux différentes classes dans un ordre précis
• exceptions : Les erreurs possibles dans l'application

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

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é. C’est aussi ce dont nous nous servons pour construire les requêtes filtrées dans la base de données (en mémoire).
• Observer : Pour l'envoi de courriel en écoutant ce qui se passe dans les services.
• Decorator : Au niveau des profits, un décorateur a été utilisé pour filtrer les requêtes. Nous nous en servons dans les cas d’utilisations pour les rapports de profits.

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 pour la remise 3, 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. Ceci est un changement à venir.

Considérés, mais pas retenus

Au courant de la remise 2, aucun patron de conception n'a été considéré mais pas 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, cela sera corrigé pour le livrable 3 pour permettre autant de flexibilité que désiré.
• Actuellement, dans la ressource pour les 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 null et si oui, retourner l’année courante.

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();