Ce squelette est proposé pour commencer les projets en LOG210. Il possède les qualités suivantes:
- il est simple pour les débutants en LOG210
- il n'y a pas de framework pour le front-end ni pour la persistance, mais ça n'empêche pas d'ajouter ces dimensions.
- il est seulement REST niveau 1, mais ça n'empêche pas de modifier l'API pour qu'il soit REST niveau 3.
- il est orienté objet (avec TypeScript)
- il contient des tests pour l'API (avec Mocha)
- il fait une séparation entre les couches présentation et domaine, selon la méthodologie de conception du cours LOG210 (Larman)
- il fonctionne sur Windows 10 (et probablement d'autres systèmes d'exploitation avec Node)
NB: Il existe également une variante de ce squelette pour Python/Flask.
Le code original a été expliqué dans ce blog post.
Dans le cadre du cours LOG210 de l'ÉTS, nous utilisons la méthodologie documentée par Craig Larman dans son livre Applying UML and Patterns. Ce livre documente beaucoup de principes avec des exemples en Java, qui n'est plus à la mode comme à l'époque où le livre a été écrit.
Pourtant, il est encore possible de suivre cette méthodologie avec des technologies modernes comme JavaScript, Node.js, surtout en utilisant TypeScript. Cependant, il n'est pas évident de trouver des exemples de ces technologies qui respectent les éléments clés de la méthodologie de Larman: la séparation des couches (présentation, domaine) avec les opérations système et les classes du domaine.
Ce squelette montre ces aspects importants, dans le contexte du Jeu de dés, qui est l'exemple utilisé dans le chapitre 1 du livre du cours. Nous avons modifié l'exemple pour le rendre un peu plus complexe (plusieurs opérations système). Les diagrammes (faits avec PlantUML) sont présentés plus bas dans la partie Artefacts.
L'éditeur Visual Studio Code est très utile mais n'est pas nécessaire avec ce squelette.
-
(Créer une fork et) Cloner
-
Installer node
-
Installer les dépendences node -
npm install -
Compiler -
npm run build -
Lancer serveur de développement -
npm start -
Accéder à la page template de l'application -
http://localhost:3000Regarder exemple de la fonctionnalité
-
Lancer les tests (pas besoin de lancer le serveur d'abord) -
npm test
Plus de détails
Le développement piloté par les tests (Test-Driven Development, TDD) est une façon de développer des logiciels en commençant par les tests. Il y a plusieurs avantages de cette façon de faire et ce squelette supporte la méthodologie.
Le TDD suit un cycle particulier, comme vous pouvez voir à l'image plus haut:
- Écrire un nouveau test
- Exécuter le test (qui échouera)
- Écrire juste assez de code pour faire passer le test
- Refactoriser le code (et les tests) au besoin et recommencer
Il y a des tests pour tous les appels de l'API du serveur web, mais on devrait également faire des tests pour les autres classes (p.ex. au niveau test unitaire des classes du domaine).
Dans un bon design (selon Larman), on évite que la couche Présentation ait la responsabilité de gérer les évènements système (opérations système). Larman présente dans son livre un exemple avec un JFrame (en Java Swing) à la figure F16.24. On l'adapte ici au contexte d'un service Web dans le framework Express (Node.js):
Dans la figure ci-dessus, l'objet :JeuDeDes (qui est un objet en dehors de la couche présentation) reçoit l'opération système demarrerJeu(nom) selon le principe GRASP Contrôleur. Ce squelette respecte cette séparation.
- Le Joueur demande à démarrer le jeu en s'identifiant.
- Le Joueur demande à lancer les dés.
- Le Système affiche le nom du joueur et le résultat du lancer des dés, ainsi que le nombre de lancers et le nombre de fois que le Joueur a gagné. Pour un lancer, si le total est égal à sept, le Joueur a gagné. Dans tous les autres cas, il a perdu.
Le Joueur répète l’étape 3 jusqu’à ce qu’il ait fini.
- Le Joueur demande à terminer le jeu.
Le Système affiche un tableau de bord avec les noms des joueurs et le ratio des parties gagnées (nombre de fois gagné / nombre de lancers).