TP MIAGE conception logicielle

Note	TP de deux slots de 1h20

Nom du(des) étudiant(e)(s) de ce monôme/binôme

Warning

NE PAS OUBLIER DE MENTIONNER LES DEUX NOMS SI VOUS ETES EN BINOME!

Paul-Adrien LECOQ et Matthias ROBERT

Commentaires éventuels des étudiants : XXXXXX

Pré-requis

• Disposer d’un PC d’au moins 6 Gio de RAM avec 20 Gio de disque disponible ;

• Disposer d’une version recente de VirtualBox ;

• Disposer d’un compte Github par personne (ou un pour deux personnes si vous êtes en binôme) ;

• Télécharger et décompresser l’image VirtualBox de l’environnement de développement ici (à faire avant le TP). Le login/mot de passe est : tp/tp.

Déroulement du TP

Répondre aux questions de la feuille de TP juste sous la question (en modifiant, commitant puis poussant le fichier README.adoc).

Nous fournissons différents projets Eclipse servant de base de travail aux exercices suivant. Cela permet un point de synchronisation de tous les étudiants à différents moments du TP.

Tip	Fermer chaque projet Eclipse (sans supprimer les sources) avant de passer à l’exercice suivant pour éviter de confondre les projets ex1 et ex2.

Exercice 1 - Etudier une API REST sans couches

Temps estimé : 40 mins

• Importer dans Eclipse les projets todolist-debut-ex1 et todolist-debut-ex2.

Faire File → Import → Projects from Git (with smart import) → Clone URI → URI: https://github.com/<x>/tp1-miage-2022.git (conserver les autres options inchangées) → 'Import projects from File System or Archives' : ne laisser cocher que tp1-miage-2022/tolist-debut-ex1 et tp1-miage-2022/tolist-debut-ex2 ('import as Maven') → Bouton 'Finish'.

Tip	[Rappel Git] Trois dépôts sont ici utilisés: le dépot Github de l’enseignant (bflorat/tp1-miage-2021), le dépot Github du binôme (<x>/tp1-miage-2021), le dépot local sur le portable de l’un ou des deux étudiants du binôme.

• Observer le code du projet todolist-debut-ex1

Le code est-il structuré en couches ? Quels problèmes ce code peut-il poser ? Non, ce code n’est pas structuré en couche. Cela entraîne plusieurs problèmes comme la difficulté à maintenir l’application ou ajouter de nouvelles fonctionnalités étant donné que les classes sont fortement dépendantes entre elles. Cette interdépendance peut aussi rendre difficile la création de tests unitaires dans l’application.

Où se trouve le code métier (voir la règle de gestion RG 1) ? Le code métier se touve dans la classe TodoItem.java. Elle contient un constructeur, des attributs et des accesseurs.

Cette règle est-elle facilement testable par un test unitaire ? Elle n’est pas testable car elle est implémentée dans le controlleur, elle n’est pas testable par un test unitaire.

• Lancer une base PostgreSQL en Docker dans un terminal (on lance ici la base en mode interactif pour visualiser son activité. Pour la lancer en tâche de fond, remplacer les options it par d comme 'daemon'):

docker run -it -e POSTGRES_PASSWORD=password -p 5432:5432 postgres

Expliquer cette ligne de commande (y compris les options utilisées) Cette commande permet de lancer un conteneur docker contenant la base de données postgres, l’option -d permet de lancer ce conteneur en tâche de fond. Nous ajoutons le mot de passe et l’identifiant de l’utilisateur ainsi que le port pour se connecter à cette base.

• Compléter le code manquant dans la méthode TodoListController.createTodoItem()

Pourquoi todoItemRepository est-il null ? Quelle est la meilleure façon de l’injecter ? La meilleure façon de l’injecter est d’utiliser les injections de dépendances.

• Modifier le code en conséquence.

• Tester vos endpoints avec un client REST.

Note	Les URL des endpoints sont renseignées dans le contrôleur via les annotation @…​Mapping Exemple de body JSON : { "id": "0f8-06eb17ba8d34", "time": "2020-02-27T10:31:43Z", "content": "Faire les courses" }

Note	Pour lancer l’application Spring, selectionner la classe TodolistApplication et faire bouton droit → 'Run as' → 'Java Application'.

• Quand le nouveau endpoint fonctionne, commiter, faire un push vers Github et fermer le projet Eclipse (ne pas le supprimer).

• Vérifier avec DBeaver que les donnnées sont bien en base PostgreSQL.

Exercice 2 - Refactoring en architecture hexagonale

Temps estimé : 1 h 20

• Partir du projet todolist-debut-ex2

Note	Le projet a été réusiné suivant les principes de l’architecture hexagonale :

Source : Tom Hombergs

• Nous avons découpé le coeur en deux couches :

  • la couche application qui contient tous les contrats : ports (interfaces) et les implémentations des ports d’entrée (ou "use case") et qui servent à orchestrer les entités.

  • la couche domain qui contient les entités (au sens DDD, pas au sens JPA). En général des classes complexes (méthodes riches, relations entre les entités)

Rappeler en quelques lignes les grands principes de l’architecture hexagonale. L’architecture hexagonale est un type d’architecture qui respecte la règle du couplage faible et cohérence forte. C’est à dire que le code est séparé en plusieurs composants pouvant être connectés à leur environnement à l’aide d’interfaces et d’adapteurs. Ce type d’architecture facilite l’utilisation de tests. L’architecture héxagonale repose sur 3 couches : le Domain,l’Application, l’Insfrastructure.

Compléter ce code avec une fonctionnalité de création de TodoItem persisté en base et appelé depuis un endpoint REST POST /todos qui :

• prend un TodoItem au format JSON dans le body (voir exemple de contenu plus haut);

• renvoie un code 201 en cas de succès.

La fonctionnalité à implémenter est contractualisée par le port d’entrée AddTodoItem.

Exercice 3 - Ecriture de tests

Temps estimé : 20 mins

• Rester sur le même code que l’exercice 2

• Implémenter (en junit) des TU sur la règle de gestion qui consiste à afficher [LATE!] dans la description d’un item en retard de plus de 24h.

Quels types de tests devra-t-on écrire pour les adapteurs ? Nous devrons écrire des tests unitaires afin de vérifier qu’un objet a été créé depuis au moins 10 jours ou il y a moins de 10 jours.

Que teste-on dans ce cas ? Nous testons la fonction dans le cadre des tests unitaires.

S’il vous reste du temps, écrire quelques uns de ces types de test.

Tip	Pour tester l’adapter REST, utiliser l’annotation @WebMvcTest(controllers = TodoListController.class) Voir cette documentation