UML

&

Design Patterns

mis à jour le 22/10/2024

Cédric BRASSEUR

Et vous ?

• Nom, prénom
• Etudes réalisées 
• Développeur depuis...
• Autres infos appréciées

Plan du cours

• Analyse et modélisation UML
  • Introduction UML en entreprise
  • Les différents diagrammes
  • Exemples & exercices
     
• Design Patterns
  • Rappels notions OO
  • Introduction aux Patterns
  • Présentation des différents Patterns
  • Exemples & exercices
     
• Architecture MVC

UML

Objectifs de la semaine

• Analyser et modéliser l’architecture logicielle d'une application avec UML
   
• Réaliser les différents modèles (diagramme UML)
   
• Optimiser l’architecture logicielle grace aux designs patterns
   
• Mettre en oeuvre et comprendre l'architecture MVC

Analyse et modélisation UML

U

M

L

nifed

odeling

anguage

Suite de diagrammes ayant chacun un but précis dans le but de modéliser l'intégralité d'un projet voire même d'un système d'information complet !

Since 1997

Pourquoi ?

Sur quels projets ?

• Projets orientés objets
• N'importe quel cycle de vie d'un projet (cycle en V, cascade, méthodes agiles,...) 

Comment ça se déroule ?

Une succession de diagrammes à réaliser selon la phase en cours du projet, la méthodologie propose de réaliser les diagrammes de composants et déploiement durant la conception. A mon sens, ils devraient être réalisés en phase d'analyse également.

Comment ça se déroule ?

La première étape pour réaliser notre phase de modélisation UML est de recueillir le besoin du client et d’en exprimer notre compréhension à travers des diagrammes UML.

Les diagrammes associés sont :

• Diagramme de contexte
• Diagramme de cas d’utilisation

Comment ça se déroule ?

La seconde étape est de réaliser une analyse du domaine, ici nous allons utiliser d’autres diagrammes pour définir le domaine.

Les diagrammes associés sont :

• Diagramme de cas d’utilisation détaillé 
• Diagramme d’activités

Comment ça se déroule ?

Ensuite vient l’analyse applicative, qui va nous permettre de définir via des diagrammes UML la structure de l’application que l’on va mettre à disposition au client.

Les diagrammes associés sont :

• Le diagramme de séquences
• Le diagramme d’état-transitions
• Le diagramme de collaborations
• Le diagramme de classes

Comment ça se déroule ?

Enfin vient le temps de la conception, ici, il s’agit donc d’utiliser les diagrammes réalisés et les affiner tout au long des développements.

Les diagrammes associés sont :

• Tous les diagrammes précédents

• Diagramme de composants

• Diagramme de déploiements 

Les diagrammes UML

Diagramme de contexte

• Le diagramme de contexte est un diagramme simple qui décrit uniquement les acteurs qui interviennent sur le SI.
• Le SI y est représenté comme une boite noire, l’objectif est uniquement de connaître les acteurs.
• Ce diagramme est le premier diagramme a réaliser.
• A noter qu’il ne fait pas partie des normes de bases de l’UML.

Exercice

Exercice (Réaliser un diagramme de contexte)

Pour toute la durée du cours, nous allons prendre le même système d’information cible. L’objectif est de réaliser tous les diagrammes sur ce contexte.

• Le contexte est simple, c’est un libraire qui souhaite concevoir un site web de vente / location de livres en ligne.
  • Le libraire souhaite pouvoir parcourir le catalogue, gérer le stock de son magasin et voir la liste des commandes pour en gérer leur statut.
  • Un visiteur peut créer un compte pour devenir lecteur.
  • Un lecteur peut commander / acheter des livres, parcourir le catalogue.
  • L’administrateur lui a accès à une interface à part pour pouvoir gérer le contenu du catalogue (ajouter des catégories, modifier les contenus etc…)

Exercice

Exercice (Réaliser un diagramme de contexte)

• Utilisez votre projet (RE)Sources Relationnelles pour réaliser le diagramme de context.

Diagramme de packages

• Le diagramme de packages permet de décomposer le système en catégories ou parties plus facilement observables, « packages ».

• C’est un diagramme de contexte avec une granularité plus forte concernant les composants du système d’information.

• Ça nous permet de savoir quels sont les différents ensembles qui composent le SI.

Plateforme formations

Exercice

Exercice (Réaliser un diagramme de packages)

Pour toute la durée du cours, nous allons prendre le même système d’information cible. L’objectif est de réaliser tous les diagrammes sur ce contexte. 

• Le contexte est simple, c’est un libraire qui souhaite concevoir un site web de vente / location de livres en ligne.
  • Le libraire souhaite pouvoir parcourir le catalogue, gérer le stock de son magasin et voir la liste des commandes pour en gérer leur statut.
  • Un visiteur peut créer un compte pour devenir lecteur.
  • Un lecteur peut commander / acheter des livres, parcourir le catalogue.
  • L’administrateur lui a accès à une interface à part pour pouvoir gérer le contenu du catalogue (ajouter des catégories, modifier les contenus etc…)

Exercice

Exercice (Réaliser un diagramme de packages)

• Utilisez votre projet (RE)Sources Relationnelles pour réaliser le diagramme de packages.

Diagramme de cas d'utilisations

• Le diagramme de cas d’utilisation représente les fonctionnalités (ou cas d’utilisation) pouvant être réalisées par les acteurs. Elles doivent TOUTES être présente dans le diagramme de cas d’utilisations.

• On peut faire un diagramme de cas d’utilisation pour le SI entier ou un pour chaque package ou par acteur.

Diagramme de cas d'utilisations

= use

<<exclude>>

= extends

Exercice

Exercice (Réaliser un diagramme de cas d'utilisations)

• Utilisez votre projet (RE)Sources Relationnelles pour réaliser le diagramme de cas d'utilisations.

Exercice

Exercice (Réaliser un diagramme de cas d’utilisations)

• Le contexte est simple, c’est un libraire qui souhaite concevoir un site web de vente / location de livres en ligne.
  • Un visiteur peut créer un compte pour devenir lecteur. Ou se connecter à son compte.
  • Le libraire souhaite pouvoir parcourir le catalogue, gérer le stock de son magasin et voir la liste des commandes pour en gérer leur statut.
  • Un lecteur peut commander / acheter des livres, parcourir le catalogue et se déconnecter.
  • L’administrateur lui a accès à une interface à part pour pouvoir gérer le contenu du catalogue (ajouter des catégories, modifier les contenus etc…). Avec connexion et déconnexion.
  • L’exercice ici est de réaliser le diagramme de cas d’utilisations pour ces règles métier. 

Diagramme de cas d'utilisations détaillé

Pour chaque cas d’utilisation, on va réaliser un tableau contenant ces informations :

• Cas d’utilisation
• Acteur(s)
• Cas d’utilisation déclencheur (Prédécesseur)
• Intérêts (Description du cas)
• Pré-conditions (données d'entrées)
• Post-conditions (données de sorties)
• Scénario nominal (le cas classique)
• Extensions (les cas spécifiques)
• Contraintes (Echec et résultat d'échec).

Diagramme d'activités

• Diagramme qui permet d’avoir une vision d’ensemble des actions qui peuvent être effectués sur le SI. Il développe les scénarios, que ce soit le scénario classique, les exceptions ou les scénarios alternatifs.
   

• Dans l'idéal chaque action fait office d’un diagramme a part entière
   

• C’est un diagramme qui a un début d’action, qui en défini les étapes et qui possède une fin. 

Début

Fin

Diagramme d'activité

Exercice

Exercice (Réaliser un diagramme d’activité)

• Le contexte est simple, c’est un libraire qui souhaite concevoir un site web de vente / location de livres en ligne.
  • Un visiteur peut créer un compte pour devenir lecteur. Ou se connecter à son compte.
  • Le libraire souhaite pouvoir parcourir le catalogue, gérer le stock de son magasin et voir la liste des commandes pour en gérer leur statut.
  • Un lecteur peut commander / acheter des livres, parcourir le catalogue et se déconnecter.
  • L’administrateur lui a accès à une interface à part pour pouvoir gérer le contenu du catalogue (ajouter des catégories, modifier les contenus etc…). Avec connexion et déconnexion.
• L’exercice ici est de réaliser le diagramme d’activité du processus de commande d’un livre (lecteur) + diagramme gestion de stock (libraire)

Diagramme d'états-transitions

• Le diagramme d’états-transitions a pour objectif de définir comment un objet change d’état au fil du temps. 
• Ce diagramme est plus spécifique que les précédents, il n’a d’intérêt que lorsque les états de l’objet et ses transitions doivent être connues et ont un impact sur le SI.
• Par exemple, imaginons que l’on a un employé qui peut évoluer au niveau de sa carrière, il aurait donc un statut (ou poste) qui peut évoluer au fil des années d’expérience. (Jeune développeur, développeur expérimenté, sénior, génie suprême,…)
• En réalité, ce diagramme est utilisé quasiment qu’en cas de besoin de décrire le fonctionnement d’un automate présent dans son SI.

Diagramme d'états-transitions

Exercice

Exercice (Réaliser un diagramme d'états-transitions)

• Le contexte est simple, c’est un libraire qui souhaite concevoir un site web de vente / location de livres en ligne.
  • Un visiteur peut créer un compte pour devenir lecteur. Ou se connecter à son compte.
  • Le libraire souhaite pouvoir parcourir le catalogue, gérer le stock de son magasin et voir la liste des commandes pour en gérer leur statut.
  • Un lecteur peut commander / acheter des livres, parcourir le catalogue et se déconnecter. Les lecteurs ont un rang de lecture (« Débutant », « confirmé », « expert », « indétrônable »). Les rangs ne sont pas linéaires et peuvent être sautés. Le rang d’un lecteur peut également régresser. Sauf s’il a atteint indétrônable.
  • L’administrateur lui a accès à une interface à part pour pouvoir gérer le contenu du catalogue (ajouter des catégories, modifier les contenus etc…). Avec connexion et déconnexion.

Diagramme de séquences

• Il permet de représenter des échanges entre les différents objets et acteurs du système en fonction du temps. Celui-ci représente les méthodes (en termes de développement).

• Il ajoute la notion d’acteurs et des informations « temporelles » au diagramme d’activités. 

Diagramme de séquences

Diagramme de séquences

Exercice

Exercice (Réaliser un diagramme de séquences)

• Le contexte est simple, c’est un libraire qui souhaite concevoir un site web de vente / location de livres en ligne.
  • Un visiteur peut créer un compte pour devenir lecteur. Ou se connecter à son compte.
  • Le libraire souhaite pouvoir parcourir le catalogue, gérer le stock de son magasin et voir la liste des commandes pour en gérer leur statut. Le libraire doit être alerté lorsqu’un livre atteint le seuil de réapprovisionnement, pouvoir modifier la quantité d'un livre et ajouter un nouveau livre avec son stock et seuil de réapprovisionnement.
  • Un lecteur peut commander / acheter des livres, parcourir le catalogue et se déconnecter. Les lecteurs ont un rang de lecture (« Débutant », « confirmé », « expert », « indétrônable »)
  • L’administrateur lui a accès à une interface à part pour pouvoir gérer le contenu du catalogue (ajouter des catégories, modifier les contenus etc…). Avec connexion et déconnexion.
• L’exercice ici est de réaliser le diagramme de séquences pour le cas d’utilisation « gestion du stock par le libraire » + Faire le diagramme de séquences pour la création de compte & authentification de l'utilisateur.

Diagramme de classes

Diagramme de classes

Exercice

Réalisez le diagramme de classes des informations ci-dessous

Exercice

Exercice (Réaliser un diagramme de classes)

• Le contexte est simple, c’est un libraire qui souhaite concevoir un site web de vente / location de livres en ligne.
  • Un visiteur peut créer un compte pour devenir lecteur. Ou se connecter à son compte.
  • Le libraire souhaite pouvoir parcourir le catalogue, gérer le stock de son magasin et voir la liste des commandes pour en gérer leur statut. Le libraire doit être alerté lorsqu’un livre atteint le seuil de réapprovisionnement.
  • Un lecteur peut commander / acheter des livres, parcourir le catalogue et se déconnecter. Les lecteurs ont un rang de lecture (« Débutant », « confirmé », « expert », « indétrônable »)
  • L’administrateur lui a accès à une interface à part pour pouvoir gérer le contenu du catalogue (ajouter des catégories, modifier les contenus etc…). Avec connexion et déconnexion.
• L’exercice ici est de réaliser le diagramme de classes le plus COMPLET possible pour le cas en cours de traitement.

Diagramme de composants

• Le diagramme de composants décrit le système modélisé sous forme de composants réutilisables pour mettent en évidence leurs relations de dépendance.
   
• Un composant peut être vu comme un ensemble d'éléments permettant de gérer une problématique.
   
• L’objectif du composant est de pouvoir être appelé de n’importe quelle source (il est donc abstrait par rapport à la technologie)

Diagramme de déploiement

• Le diagramme de déploiement se rapproche encore plus de la réalité physique, puisqu'ils identifient les éléments matériels (PC, Modem, Station de travail, Serveur, etc.), leur disposition physique (connexions) et la disposition des exécutables (représentés par des composants) sur ces éléments matériels.
   
• A utiliser pour les architectures complexes, peu de pertinence si c’est un projet qui n’a vocation de tourner sur votre poste. 

Présenter ses diagrammes

Chaque diagramme doit être présenté textuellement et faire partie intégrante de la réponse au besoin du client.
Pensez que certains lecteurs de votre réponse ne seront pas aussi à l’aise que vous en UML, un texte explicatif peut à la fois aider les non informaticiens mais aussi les informaticiens qui peuvent interpréter différemment vos diagrammes.

• Les diagrammes sont à réaliser dans l’ordre pour un bon déroulement du projet, chacun apporte un complément au précédent.
• Ces diagrammes sont cohérents les uns avec les autres.
• Lors de la phase de conception il est très fréquent que les diagrammes changent (légèrement) ou ne soient pas respectés à la lettre. L’idée est de maintenir les diagrammes à jour par rapport à vos développements.

UML 2.0 (2.2 en réalité)

D'autres diagrammes existent dans une version plus récente de l'UML, chacun ayant leurs propre intérêt pour compléter la modélisation avec les diagrammes abordés ensemble.

Conclusion

• L'UML est une suite de diagrammes décrivant le SI et le projet,
   
• L'UML permet de communiquer sur ces éléments entre toutes les parties prenantes,
   
• L'UML est nécessaire pour réaliser un projet en évitant les problèmes de compréhension du besoin,
   
• L'UML a encore évolué aujourd'hui et nous n'avons pas vu tous les diagrammes, seulement les principaux.

Exercice global

Pour cet exercice, je vous donne des règles métiers et vous devez réaliser 5 diagrammes correspondants (Cas d'utilisations, activités, états-transitions, séquences, classes). Prenez votre temps, posez des questions, sachez que vos compétences seront évaluées via un exercice complètement similaire, avec des règles métiers différentes.

Projet Cube

Si nous avons un peu de temps en fin de journée, nous allons prendre ce temps pour travailler sur l'UML du projet Cube. Mettez vous en groupe et commencez à réaliser les diagrammes dans l'ordre vu durant la formation.
Certains diagrammes sont peut-être optionnels, mais je vous conseil de tous les faire et tous les commenter !

Non noté (pour le moment) mais je pense que nous n'aurons pas le temps d'arriver à cette slide avant la fin de la première journée

Design Patterns

Kesako ?

• Solutions architecturales à des problèmes objets
• Réutilisable à des problèmes de dévs récurrents
• Peu d’algorithmique quand on isole, plus des schéma orientés-objet (UML!!)
• Façons d’organiser le code pour augmenter
  • Flexibilité du code
  • Maintenabilité du code
  • Extensibilité du code
  • Configurabilité du code
  • (Diminuer) Duplication de code
• Le plus souvent basé sur des interfaces et abstractions

Les design patterns : classification

• Patterns créateurs (Singleton, factory, abstract factory)

  • Patterns aidant à la gestion de la création d’objet

• Patterns structurants (Façade, proxy, decorator, composite, adapter)

  • On parle de travailler sur la partie externe des classes du pattern. L’extensibilité et l’encapsulation des classes.

• Patterns comportementaux (Strategy, iterator, observer, state)

  • Ici, on travaille sur la partie interne des classes du pattern. La dynamique des classes du pattern. Améliorer la qualité du code, éviter les duplications ou gérer des problématiques connues.

Principes à respecter

• Favoriser la composition (liens dynamiques, flexibles) sur l’héritage (lien statique, peu flexible) 
• Attention il s’agit juste de favoriser car l’héritage est également très utilisé dans les designs patterns

• Le code utilisateur d’un pattern doit en priorité TOUJOURS se lier à des abstractions (interfaces, classes abstraites) plutôt qu’à des implémentations concrètes (classes)

• Privilégier l’encapsulation faible / découplage fort.                   

Les différents patterns

Mais d'abord...

La mise en place de Design Pattern va nécessiter des notions objets simples mais importante pour la compréhension de ces derniers. Nous allons revoir rapidement : 

• Héritage
• Interface
• Composition
• Agrégation
• Classe abstraite

L'héritage

L'héritage permet de partager des propriétés et méthodes entre les classes, il suffit d'utiliser le mot clé extends pour que cette classe (fille) hérite de la classe de base (mère).

Le partage de code s'effectue de manière descendante uniquement.

L'héritage (code)

L'interface

Une interface est un contrat a respecter, il défini la signature des méthodes (définition de méthode sans leur implémentation) qui doivent être implémentées dans les classes respectant ce contrat d'interface.

Association / Agrégation

Une association traduit un lien entre une classe A et une classe B (appel de méthode par exemple).
L'agrégation est une association particulière : l'objet A possède une ou plusieurs instances de B.

La composition

Une composition est une agrégation particulière : toutes les instances de B contenues dans A sont supprimées lorsque A est supprimée.

La composition

Autre exemple plus complexe (pour revoir un peu d'orienté objet supplémentaire)

Exercice

Exercice Orienté Objet (pour prendre un peu de temps et aider ceux qui n'ont pas fait d'OO)

Réaliser une composition entre Author et Book.

• Author doit avoir
  • une propriété name et une propriété email,
  • vous devez créer un constructeur pour remplir ces propriétés.
  • Réalisez un getter par propriété.
• Book doit avoir
  • une propriété authors, price et name.
  • Un constructeur pour set name et price.
  • Un getter pour chaque propriété.
  • Un setter pour ajouter un auteur à la liste (ou tableau) d'authors.
• A vous de trouver comment réaliser une composition entre ces deux classes.
• Pour tester votre code voici ce qui doit fonctionner :

A mettre de côté et rendre également !

Les classes abstraites

Une classe abstraite (mère) permet de définir les signatures des méthodes et les propriétés qui seront partagés à la classe qui va étendre cette classe abstraite (fille)

Les classes abstraites

L'intérêt principal des classes abstraites est d’informer l’utilisateur (la classe fille) de cette classe qu’une instance de cette première n’a pas d’utilité a être instanciée. Exemple : vous devez gérer un centre de location de véhicules (voiture, camion, vélo ….). Vous avez très certainement une classe Vehicule, dont héritera Velo, Voiture, Camion…

Mais le centre de location n'aura jamais besoin d'instancier un Vehicule.

Les classes abstraites peuvent également posséder des méthodes abstraites. Ce sont des méthodes qui ne possèdent pas de corps, et qui devront obligatoirement être surchargée par les classes qui en hérite

Les classes abstraites

Un autre exemple pour mieux comprendre... Nous avons une classe abstraite Shape et deux classes filles Square & Circle. 

Impossible
d'instancier une forme,
Shape est un concept abstrait 

Hérite de Shape
Ce qui lui en donne les propriétés & force à redéfinir "Draw"

Définition

L'idée principale est de pouvoir mettre en place une certaine stratégie ou ce que l’on va régulièrement appeler un comportement afin de pouvoir en changer dynamiquement au runtime.
Sans pattern stratégie, on serait obligé de multiplier les classes en produit cartésien pour pouvoir avoir autant de combinaisons de comportements que nécessaire. (Horrible)

Problématique

L’héritage est puissant mais il ne permet de partager du code que de manière verticale, c’est-à-dire à ses enfants.

Par contre, si les enfants veulent partager du code entre eux, aucun moyen de le faire à part en dupliquant le code (Horrible).

Pattern Stratégie

UML : Pattern Stratégie

Exemple : Pattern Stratégie

Pattern Stratégie : Avantages

• Meilleure lisibilité du code. (Pas de duplication, pas de gros pavés de méthodes dans une seule classe)

   

• S’assurer que chaque élément à sa propre responsabilité (découplage fort)

   

• Et surtout avoir des algorithmes interchangeables au runtime sans avoir à multiplier les classes.

Exercice

Exercice (Réaliser un pattern Strategy)

Reprenez le pattern Stratégie pour l’appliquer à ce sujet :

Une interface StrategieInterface ayant pour contrat function reagir(PersonneInterface $personne);

Trois classes (Enerve, Geek, Heureux) chacune implémentant StrategieInterface et redéfinissant donc la méthode réagir:

• Enervé écrit en majuscule et ajoute des !!! à la fin.
• Geek remplace les o par des 0
• Heureux ajoute un :) à la fin

Une interface PersonneInteface ayant pour contrat function donnerPhrase();

Une classe Personne qui implémente PersonneInterface et donc redéfini donnerPhrase :

• return 'Bonjour';

Une classe Contexte qui a une stratégie en propriété.

• Un constructeur pour setter la stratégie
• une méthode exprimeReaction qui appel la méthode de la stratégie passée dans le constructeur

Réalisez le diagramme UML + le pseudo code amélioré

Définition

Définir une dépendance entre un objet observé et un ou plusieurs objets observants.

L’objectif étant de pouvoir notifier les objets observants lorsqu’un changement de statut est opéré sur l’objet observé.

Problématique

On a parfois besoin de connaître le changement de statut d’un autre objet. Il est possible d’interroger l’objet en continue pour connaître son statut et le mettre à jour si nécessaire.
Ceci est très gourmand s’il y’a plusieurs abonnés et surtout si on interroge toutes les secondes, alors que le statut change de manière aléatoire ?

Ceci n’est pas efficace. 

Pattern Observer

UML : Pattern Observer

* Optionnelle : Si on ne met pas de lien entre concreteSubject et ConcreteObserver, ça nous force à passer un objet ConcreteSubject dans la méthode update()

* Optionnelle

Pattern Observer : Avantages

• Eviter les opérations de PULL massives et simplement effectuer un push / pull lorsque c’est nécessaire.
   

• Plus concrètement, améliorer la logique métier
   

• Diminuer le coûts de l’observation
   

• Supprimer la question de l’intervalle d’interrogation

Exercice

Exercice (Réaliser un pattern Observer)

Reprenez le pattern Observer pour observer la modification d'une température et notifier des objets observants ce changement de température.

Chaque modification de température affiche (dans la console) la nouvelle température pour tous les objets observants.
Pensez bien à avoir plusieurs observants.
 

Réalisez le diagramme UML + le code complet du pattern

Définition

Comme son nom l’indique, il a pour objectif de rendre une interface non adaptée à une autre, compatible. En rajoutant un objet intermédiaire nommé « Adapter ».

Problématique

Les interfaces exposées ne sont pas toujours compatibles avec ce que nous avons, il nous faut donc réaliser une adaptation intermédiaire pour pouvoir coupler les deux. 

Pattern Adapter

UML : Pattern Adapter

Pattern Adapter : Avantages

• Adapter une interface pour qu’elle s’imbrique dans une autre, tout simplement.
   

• Découplage fort
   

• Peut-être facilement mis en place même après coup, à moindre coût (sauf pour le code client, qui va forcément devoir être adapté ou il ne sera pas homogène)

Définition

Permet d’ajouter dynamiquement des propriétés à un objet.

En pouvant empiler/décorer avec autant d’objets décorable que l’on souhaite.

L’objet décoré et le ou les objets décorants s’utilisent de la même façon, excepté que la plupart du temps, les objets décorants ne peuvent pas exister sans objet à décorer. 

Problématique

Duplication de code et multiplication des classes pour gérer toutes les possibilités (inutiles).

Pattern Decorator

UML : Pattern Decorator

Pattern Decorator : Avantages

• Simple à mettre en place

• Evite la multiplication des classes

• Permet d’ajouter des caractéristiques multiples sans limite (excepté celles définies par l’interface) à un objet de base.

• Le fait d’envelopper permet de facilement exécuter des opérations qui sont à effectuer sur chaque enveloppe pour en avoir un résultat global (prix d’une boisson par exemple)

• Attention, ça ne permet pas de connaître l'ordre de décoration !!!

Exercice : Pattern Decorator

• Adaptez le diagramme vu ensemble en utilisant la problématique suivante :

  • On a une boisson de plusieurs type : café, chocolat au lait, thé, …

  • Chaque boisson peut avoir plusieurs décorations : sucre, caramel, chocolat,…

  • L'objectif est de calculer le prix à la compilation en fonction de la décoration

• Réalisez le code (ou à minima pseudo code) permettant de mettre ceci en œuvre

• Décorez un café avec deux fois du caramel et une fois du sucre, par exemple.

Définition

Le pattern singleton est le plus simple des patterns, il permet de s’assurer qu’un objet est instancier qu’une et une seule fois dans toute votre application.

Ce sera toujours la MÊME instance de l’objet quelque soit depuis quel endroit l’objet est appelé. 

Problématique

On instancie un objet quelque part, on y fait des opérations dessus, puis on souhaite à nouveau réutiliser cet objet à un autre endroit.

Pour que les opérations soient gardées en mémoire, on ne peut pas le faire, car on devra réinstancier la classe puis réeffectuer les opérations dessus. (Ou alors rajouter des dépendances inutiles)

Pattern Singleton

UML : Pattern Singleton

Pattern Singleton: Avantages

• S’assurer qu’un objet est instancier qu’une seule fois et y avoir accès facilement depuis n’importe où dans votre application. 

• Certains estiment que le pattern singleton est un mauvais pattern (à ne pas confondre avec anti-pattern). Pour deux raisons, à ma connaissance :

  • 1. Le pattern singleton est utilisable uniquement en statique, les débats sont nombreux avec tout ce qui tourne autour du mot clé « static ». Je vous laisserai vous renseigner et vous faire votre propre opinion, mais sachez que pour ma part, je l’utilise très fréquemment.

  • 2. D’après certains développeurs, le fait de dire qu’on est certain que l’on veut une seule instance de son objet à tout jamais dans son application n’est pas en lien avec le fait de faire de son application une application évolutive à toute épreuve.
    Pour eux, afin que ça reste évolutif, on ne peut pas se limiter à une seule instanciation. Habituellement, l'autre possibilité est d'utiliser une Factory
    Je comprends le point de vue, mais je n’y adhère pas. J’utilise fréquemment le singleton pour instancier ma base de données par exemple. Dans 99,99% des cas, je sais à l’avance que je n’aurai qu’une instance de base de données et ceci n’évoluera pas au fil du temps.

Exercice

Réalisez un pattern Singleton sur un objet de base de données.
 

Réalisez le diagramme UML + le code qui met en place le pattern

Définition

Permet de gérer des états sur des objets tout en gardant la flexibilité d’opérer toutes les actions que voulues sur chaque état.
Sans avoir à enchainer les if (x.state === State.closed) {…}.
On change le state d’un objet et c’est ce state s’auto-gère en fonction des opérations qui sont proposées par l’interface State. 

Problématique

La gestion d’état sur des objets est gérable avec de simples conditions, mais dans le cas où l’on a beaucoup d’état qui peuvent changer en fonction de différentes opérations, le code devient une succession de condition.
D’une part, c’est incompréhensible à premier abord (surtout sans commentaire, ça peut prendre un certain temps) et d’autre part, lorsque l’on veut ajouter un state ou une opération on se retrouve a devoir modifier tout ça au risque de tout péter.

Pattern State

UML : Pattern State

Pattern State : Avantages

• Modularité du code
   
• Simplicité pour multiplier les opérations de changement de statut (flexibilité)
   
• Découplage fort

Exercice

Exercice (Réaliser un pattern State)

Si nous avons assez de temps, je vais vous demander de réaliser un pattern State, l’idée ici est de gérer les statut d’une porte :

• Une interface IGateState + une classe Gate + une classe OpenGateState (IGateState) + une classe ClosedGateState
• Les méthodes à implémenter sont
  • Enter, pay, payOk, payFailed : Ces méthodes doivent modifier le statut suivant l'action réalisée sur le statut courant.

Réalisez le diagramme UML + le pseudo code amélioré

Exercice

Exercice (Réaliser un pattern State)

Réalisez le code permettant d'implémenter un pattern State répondant aux besoins précisés par le diagramme d'états transitions envoyé. 

(Débutant, confirmé, expert, indétrônable, en pouvant sauter des niveaux que ce soit positivement ou non. Excepté quand on arrive à indétrônable)

• Réalisez le diagramme UML + le code d'implémentation du diagramme états-transitions

Définition

Le pattern command a pour objectif d’encapsuler une requête pour la rendre accessible depuis n’importe quel récepteur et la permettre d’être envoyée depuis n’importe quel émetteur.
L’idée est d’également de s’ajouter la possibilité de « undo » les commandes facilement. (Si en utilisation avec le pattern composite, on peut même effectuer des macro commandes qui exécute plusieurs petites commandes, sans en rendre plus compliqué le undo).

Problématique

Comment proposer un service d’exécution de requêtes à de multiples clients / sujets ?

Comment s’assurer que l’on nous demande pas d’exécuter quelque chose que l’on ne sait pas traiter ?

De manière générale, comment gérer la commande ? et l'inverser ?

Pattern Command

UML : Pattern Command

Pattern Command : Avantages

• Modularité
   
• Découplage du code et exposition de contrat à respecter pour utiliser le service
   
• Permet de réaliser les opérations inverses aisément
   
• Permet également de réaliser une succession d’opérations complexes (si utilisé avec le pattern composite, que l’on verra plus tard)

Exercice

Exercice (Réaliser un pattern Command)

Reprenez le pattern Command pour l’appliquer à ce sujet : Gestion du son, pour l’augmenter et le baisser. L’idée va être d’avoir une ICommand qui va pouvoir execute, unexecute une action.
Cette action est définie dans une classe Receiver.
L’Invoker va lui contenir les Command, ainsi que deux méthodes:

• Monter le son,
• Baisser le son,
• (Pour ceux qui veulent coder un peu, faites en sortes de pouvoir gérer un up / down du volume valorisé par un entier. Le unexecute doit pouvoir remettre le son de base à la bonne valeur)

Faites deux Invoker(Remote, Voice)  différents et deux Receiver différents (HiFiSystem, TV)

Réalisez le diagramme UML + le code d'implémentation

Définition

C’est sensiblement la même chose que le pattern façade, excepté que le pattern proxy exprime un but précis lors du passage par le proxy (équivalent façade).
3 types de proxys peuvent être utilisés :

• Remote : Simple proxy passe plat qui opère comme une simple substitution de l’objet de départ.
• Virtual : Proxy qui gère l’utilisation de ressources couteuses (en temps, en machine, ou même en argent)
• Protection : Proxy qui ajoute une couche de sécurité lors de l’appel à votre proxy.

J’insiste sur le fait que c’est plus une vision UML différente qu’une implémentation dans le code différente.

Problématique

Appel d’un composant externe qui nécessite un accès sécurisé, par exemple

Pattern Proxy

UML : Pattern Proxy

Pattern Proxy : Avantages

• Substitution d’objet, on fait semblant d’être autre chose pour pouvoir réaliser une certaine action
   
• Opérations coûteuses déléguées (potentiellement pour l'exporter dans un service distant),
   
• Contrôle d’accès à la ressource,
   
• Découplage fort

Exercice

Exercice (Réaliser un pattern Proxy)

Je vous demande de réaliser un pattern proxy, par exemple en utilisant le proxy pour valider un token d’authentification simple (un simple « toto » === « toto » suffit.

Pour ceux qui veulent développer un peu je propose de générer un fichier "Bonjour.txt" contenant 500 000 lignes d'enchaînement de mots générées aléatoirement, ou trouvez une idée d'opération couteuse à effectuer, je suis preneur de bonnes idées).
 

Réalisez le diagramme UML + le code d'implémentation

Définition

C’est simple, c’est un pont.
Un pont entre une classe abstraite et une interface permettant d’anticiper le problème de multiplication de classe vu dans le pattern adapter.
L’idée pour différencier les deux, concrètement, c’est que l’adapter corrige un problème de compatibilité alors que le pont l’anticipe pour ne jamais avoir le problème.

Problématique

Deux interfaces ne sont pas forcément compatibles si elles n’ont pas été pensées au départ pour l’être.

La gestion d’un produit cartésien de nos classes nécessite la multiplication des classes, pour un 3x3, le gain est de 3 classes, mais pour du 20x20, le gain est élevé. 

Pattern Bridge

UML : Pattern Bridge

UML : Pattern Bridge explication

Pattern Bridge : Avantages

• Anticiper les problèmes de compatibilité
   
• Gestion de produit cartésien entre nos classes (composition multiples de combinaisons) sans avoir à multiplier les classes.
   
• Modularité et extensibilité du code accrue
   
• On respecte le contrat de l’interface et de la classe abstraite et on est bon, on fait les combinaisons que l’on souhaite.

Exercice

Exercice (Réaliser un pattern Bridge)

Réaliser un pattern bridge, l’idée est de faire un bridge pour pouvoir lier une clé de voiture avec une clé de maison, ou une clé de garage par exemple :

• Une classe abstraite Door + une interface Key.
• Des implémentations concrètes de Key (HouseKey, CarKey)
• Des implémentations concrètes de Door (HouseDoor, CarDoor, GarageDoor)
• Les méthodes pour ouvrir et fermer
• Dans un cas, vous devez logger l'ouverture et la fermeture (HouseDoor), d'autres juste l'ouverture (CarDoor) et le dernier juste la fermeture (GarageDoor).

(J'ai un autre exercice si celui-ci ne vous parle pas trop)

Réalisez le diagramme UML + le code d'implémentation du pattern

Définition

Le pattern façade permet de gérer les multiples dépendances de manière regroupée dans une classe façade qui va nous permettre de définir un certain nombre de dépendances / instanciations à notre place.

Il peut également être utilisé comme gestionnaire de méthodes !

Problématique

Dans nos codes, les références à d’autres objets sont multiples et fréquentes. Parfois, il devient difficile ou pénible de devoir instancier les 10 objets dont dépendent l’objet que l’on souhaite. 

Pattern Façade

UML : Pattern Façade

Pattern Façade : Avantages

• Avantages du pattern :
  • Isoler les dépendances des sous systèmes
  • Packaging depuis une classe, c’est intéressant nan ?
• Attention par contre:
  • Un des principes peut très facilement être oublié lorsque l’on fait une façade : le principe qui dit qu’on doit connaître que ses voisins les plus proches.
  • Faites attention aux dépendances croisées et faites attention de ne pas multiplier les dépendances dans votre façade.
  • En gros : 
    • A connait B, B connait C, mais A ne DOIT PAS connaître C.

Exercice

Exercice (Réaliser un pattern Façade)

Réaliser un pattern façade, l'idée est de mettre en place une façade qui va gérer pour nous l'instanciation de sous classes.

• Une classe Facade qui va gérer l'ajout d'aliments nécessaires à la réalisation d'un Burger (une simple méthode suffit, ajouterPain, ajouterViande, ajouterTomate, ajouterOignon) en utilisant une classe de gestion du Burger
• On souhaite concrètement avoir une interface avec toutes les méthode d'ajouts d'aliments et une classe Burger qui implémente ces méthodes (de simple echo suffisent)
• Et il faut que notre Facade puisse gérer la réalisation de différents burgers, comme un burgerComplet, burgerClassic, burgerNoTomato, burgerNoOinons

Réalisez le diagramme UML + le code d'implémentation

Définition

Ce pattern propose une manière de gérer la composition d’objets qui contiennent des objets en arbre.

C’est-à-dire qu’un objet est composé d’un autre objet, qui peut être composé de plusieurs autres objets, etc…

On souhaite pouvoir utiliser les mêmes méthodes que l’on soit dans un nœud composite ou dans un nœud composant.

Problématique

Comment gérer de la récursivité de manière transparente pour le code utilisateur entre objet, sans utiliser de conditionnel sur le type de l’objet ? 

Pattern Composite

UML : Pattern Composite

I

Pattern Composite : Avantages

• Meilleure lisibilité du code. (Pas de duplication, pas de gros pavés de méthodes dans une seule classe)
   
• S’assurer que chaque élément à sa propre responsabilité (découplage fort)
   
• Et surtout avoir des algorithmes interchangeables au runtime sans avoir à multiplier les classes,
   
• Gérer la récursivité facilement.

Exercice

Exercice (Réaliser un pattern Composite)

Réaliser un pattern composite, l'idée est de pouvoir construire une arborescence de <ul> et de <li> imbriqués grâce au pattern composite. Il vous faut :

• Une interface commune (avec une méthode, par exemple : operation())
• Une classe pour le <li> (enfant) : Celle-ci contient une propriété en string qu'elle set depuis le constructeur. Ainsi qu'une méthode operation() retournant cette propriété.
• Une classe pour le <ul> (parent) : Celle-ci contient la propriété listant les classes <li>, ces sous éléments peuvent êtres setté depuis le constructeur & par des méthodes d'ajout et de suppression d'élément. Ici la méthode operation() va parcourir la liste des sous éléments pour réaliser l'affichage des <ul> / <li>

Réalisez le diagramme UML + le code d'implémentation

Définition

Le pattern factory a pour objectif de gérer la construction d’objet différemment qu’avec un « new ».

C’est la factory qui s’assure de la création / suppression de ces objets.

En général, une factory est utilisée lorsque l’on souhaite gérer la façon dont sont créer les objets via des méthodes (Par exemple, RandomCarFactory et RegularCarFactory)

Problématique

On veut parfois ne pas avoir à gérer via le client quel type d’objet sera créer. Ou alors, on souhaite gérer un ordre de création d’objet ou pouvoir le modifier à la volée (par exemple createMutableObject ou createImmutableObject)

Pattern Factory

UML : Pattern Factory

Pattern Factory: Avantages

• Instanciation dynamique des objets
   
• Découplage des classes
   
• Gestion externe de l’instanciation de nos objets, on peut lui faire suivre une logique particulière (toujours dynamiquement)

Exercice

Exercice (Réaliser un pattern Factory simple)

Réaliser un pattern Factory afin de pouvoir gérer la création de véhicules différemment à la volée dans le code. Vous allez implémenter :

• Une interface ICarFactory (qui peut être vide pour l'exo)
• Une interface ICar (qui peut aussi être vide)
• Une classe par marque de véhicule Renault, Audi, Mercedes,...
• Une classe par type d'instanciation de classe : RegularFactory & RandomFactory
• Dans un cas, la classe génère toujours les mêmes voitures, dans l'autre la classe génère des voitures de manière aléatoire.

A noter : Il n'est pas nécessaire de développer un vrai random pour cet exercice (mais ça rajoute un peu de code alors pourquoi pas !)

Optionnel : Faites une classe qui génère des voitures suivant la suite de Fibonacci. Donc, 1 Renault, 1 Audi, 2 Mercedes, 3 Renault, 5 Audi, 8 Mercedes, 13 Renault,...

Réalisez le diagramme UML + le code d'implémentation

Définition

Ici, l’objectif est de pouvoir parcourir une liste d’objets d’une manière algorithmique implémentée manuellement.
Aujourd’hui ça semble inutile comme pattern, car on a des structures qui utilise ce pattern pour nous. (ArrayList, List, Map, etc…) Tout ce qui est IEnumerable, en gros (IEnumerable c’est notre Iterator) avec les petites surcouches en LinQ qui vont bien…
Mais ça peut arriver que ceci ne soit pas disponible.

Problématique

Gestion d’un ensemble d’objet sans avoir accès à des types qui permettent d’itérer sur la liste.

Pattern Iterator

UML : Pattern Iterator

Pattern Iterator : Avantages

• Permet de gérer des listes de manière simple et implicite pour la personne qui va utiliser votre code.
   
• A savoir que vous n’aurez pas forcément toujours la possibilité d’utiliser un type qui gère les itérations pour vous
   
• On n’est pas obligé de s’arrêter à quelques opérations, on peut en implémenter autant qu’on le souhaite pour parcourir la liste. 

Exercice

Exercice (Réaliser un pattern Iterator)

Réaliser un pattern Iterator, ici l'objectif est de mettre en place un iterateur pour lister une collection d'items (WordsCollection implements \IteratorAggregate) en AlphabeticalOrderIterator (implements \Iterator) permettant de lister les items de collection.
A noter que PHP met déjà en place pour vous les interface Iterator & IteratorAggregate.
Vous devez donc :

• Avoir une collection d'items, un bool reverse et une position pour la classe AlphabeticalOrder et y implémenter les méthodes de IteratorAggregate.
• La classe WordCollection doit avoir un tableau d'items et proposer les méthodes pour ajouter des items, récupérer la liste des items et une méthode getIterator() ainsi qu'une méthode getReverseIterator().

Réalisez le diagramme UML + le code d'implémentation

Attention à la surutilisation des patterns

Petite attention particulière sur la surutilisation : même quand vous aurez l’habitude d’utiliser les design patterns…

Le but des patterns est de répondre à une problématique de code par une conception adaptée ET PAS rendre la conception plus complexe pour mettre des patterns juste parce qu’on veut absolument mettre des patterns partout.

 

C’est assez effrayant le nombre de développeurs en entreprise qui font ça, de mon expérience, je dirai qu’environ 10% des développeurs que j’ai connu avaient ce syndrome. Travailler avec eux était d’autant plus compliqué que leur syndrome était avancé !
Car ils ajoutent une complexité non négligeable à un projet et ensuite pour faire intervenir une ressource non expérimentée et bien… ça fini souvent avec quelqu'un en pleure avant même d’avoir écrit une ligne de code.

Attention à la surutilisation des patterns

Pour appuyer mes propos, imaginez, nous avons vu une architecture MVC (en 3 couches), y ajouter des patterns n’est déjà pas toujours évident, même si les patterns que l’on a vu s’adaptent bien à l’architecture MVC.

D’autres architectures existent, par exemple SOA, qui est une architecture orientée services. Cette architecture contient, en moyenne pour une utilisation normale, entre 10 et 12 couches. Là, on parle d’une complexité déjà impactante en termes d’architecture…

Ajoutez une surutilisation de patterns et seuls les développeurs séniors seront capables de travailler sur ce projet (mais ça ne donnera envie à personne…)

Evitez absolument la complexité dans vos développements, un pattern n'a d'avantage que s'il est employé correctement

L'architecture MVC

Comment fonctionne une architecture MVC ?

Chaque couche a son propre objectif et ces couches ne communiquent que d'une seule manière avec les autres. 

Modèle

• C’est la définition des structures de vos données et c’est dans les modèles que l’on implémente les méthodes de requêtage de la base de données.

Contrôleur

• C’est la logique de code qui prend des décisions et qui altère les données. Il est l’intermédiaire entre la vue et le modèle. Il va également contrôler les droits d’accès par exemple.

​Vue

• Les différents éléments qui vont composer votre interface, que ça soit la partie « html » (balises) ou la partie « css » (style) ainsi que les assets et autres ressources de votre interface.

Un schéma pour mieux comprendre

Exemple pratique

Créer une arborescence de dossier comme suit :

• controller
• model
• public
  • css
  • images
  • js
• view
• (Fichier à la racine) index.php (router principal)

Exemple pratique

Déjà, il faut installer wamp et créer une base,

• On se connecte, normalement avec ‘root’ et sans mot de passe.
• On créer une base « architecturemvc ».
• On vérifie le port utilisé (3306 ?)
• On créer une table « Livre » (id (primary key en auto_increment), titre, auteur, description, date de parution(date))
• On insère rapidement un ou plusieurs livre de test, mettez les données que vous voulez. Soit vous faites du SQL, soit vous insérez directement depuis phpmyadmin.

Exemple pratique

Maintenant qu’on a l’arborescence, on va rajouter quelques fichiers:

• controller/Livre.php
  • Ici, on veut require Model.php et on veut ajouter une condition sur une route isset($_GET[‘id’]). Si c’est le cas on rempli une variable $livre appelant la méthode du modèle getLivre($id). Si pas d’id, message d’erreur.
  • Pour finir on require livreVue.php.
• model/Model.php
  • Ici, on veut faire la requête en base, donc on fait une fonction getLivre($id) et une fonction $getLivres() retournant respectivement soit le livre $request->fetch() et les livres $request->fetchAll().
  • $db = new PDO('mysql:host=localhost;port=3306;dbname=architecturemvc', 'root', '');
  • $db->query OU $db->prepare le premier permettant de réaliser une query directement, le second de réaliser une requête préparée (pour une bonne gestion sécurisée des paramètres)
• view/accueilVue.php
  • Ici on fait du html pour afficher les éléments de tous les $livres.
• view/livreVue.php
  • Ici on fait du html pour afficher les infos d’un $livre.
• ./index.php (on va le mettre à la racine, même si on devrait l’avoir sous le dossier public. Mais on n’ira pas jusqu’à la phase d’url rewritting sur cet exercice)
  • Ici c’est un contrôleur également, donc comme pour Livre.php, sauf qu’on fait appel directement à getLivres après le require sur notre modèle sans conditionner sur les paramètres $_GET.

Exemple pratique

Faire un routing plus propre (quand on n’utilise pas de framework et qu’on aime faire tout soit même)

• Le but du routing va être de vous éviter de créer un contrôleur pour chaque cas d’utilisation de votre modèle. L’idée est d’avoir votre page index.php, ajouter un paramètre get « action » pour n’avoir qu’un seul fichier qui gère le routing.
  • Ici, le but est d’utiliser « Index.php » à la racine de notre projet comme routeur. Déjà on va faire le require vers le controller/Livre.php ensuite on va donc lui « ajouter » un paramètre $_GET[‘action’] pour lui donner une action, exemple « listeLivres » ou « livre ».
  • C’est lui qui vérifie les paramètres get pour notre id de livre si on demande l’action livre.
  • On lui mettra une action par défaut de listing des livres « listeLivres ».
• Le controlleur doit quand à lui maintenant contenir deux fonctions, une pour lister les livres, l’autre pour retrouver les infos d’un livre. (Il require tjr le modèle, ça ne bouge pas et il require également la vue pour affichage (dans chacune des fonctions, on met à dispo les infos dans une variable))

Schéma actualisé

Architecture MVC : Avantages

• Meilleure séparation et organisation du code,
• Diminution de la complexité lors de la conception (normalement),
• Conception claire et efficace,
• Possibilité de réutilisation de code dans d’autres applications et même dans d’autres langages si l’on s’y prend correctement !
• Un gain de temps en termes de maintenance et pour d’éventuels évolutions de l’application,
• Plus simple de séparer les tâches aux ressources sur le projet, on peut même faire en fonction des affinités de chacun (BDD, code métier, design,…)
• Plus de facilité pour implémenter des tests unitaires cohérents.

Architecture MVC : Inconvénients

• Éventuel cloisonnement et spécialisation des développeurs, ce qui les rends potentiellement incapable de corriger le bug d’un collègue, ou lorsqu’il y’a du turnover dans les équipes,...
• Architecture plus complexe, peu intéressante pour des petits projets,
• La multiplication du nombre de fichiers représente une charge de mise en place et de formation non négligeable dans un projet.

Les frameworks MVC

Ce sont des frameworks utilisant l’architecture MVC sur lesquels vous aller vous greffer pour réaliser vos développements.
C’est un gain de temps, mais parfois ça peut être contraignant :

• Fonctionnalités non disponible dans le framework ou mise à jour de framework,
• Complexité d’adaptation au framework, par exemple Laravel est complexe à prendre en main mais c’est assez puissant,
• Lourdeur du framework à prendre en considération systématiquement.

Exemples de Frameworks MVC :

• ASP.NET MVC,
• Ruby on rails,
• Laravel,
• Angular Js,
• React,
• Directus,
• Symfony,                                                                                                         

Exercice MVC

Réalisez un jeu du serpent (celui sur jeu de plateau) simple, en MVC :

• Une page pour démarrer une partie prenant 2 noms de joueurs (mini-formulaire)

• Déroulement de la partie :

  • 2 joueurs lancent un dé (1-6) au tour par tour en appuyant sur un bouton de l'IHM

• Affichez uniquement la position (en chiffre) du joueur (sauf si vous êtes vraiment bon en IHM)

• Le premier joueur arrivant à la case 50 gagne.

  • Si l'un des 2 joueur dépasse 50, ce joueur retourne directement à la case 25. Jusqu'à ce qu'un des deux gagne la partie.

• La page acclame le joueur qui réussi.

• Enregistrez chaque partie terminée dans une base de donnée (une simple table suffit).

• Affichez le nombre de parties totales terminées depuis le début du site

Exercice utilisé en workshop final

Evaluations

Partie théorique

Envoyer fichier modelisation_test

Partie pratique

(après c'est fini)

Evaluation UML + Design Pattern sur papier !

Workshop noté : choisissiez un sujet, réalisez les diagrammes UML (cas d'utilisation, activités, séquences, classes) et que vous implémentiez un Design Pattern, sur PAPIER :

• Explications de la problématique résolue par le Pattern
• UML du Design Pattern (classes)
• Code ou pseudo code du Design Pattern pour son utilisation

Iterator / Singleton / Proxy /  Adapter interdits pour le workshop.

Partie pratique

(après c'est fini)

Vous allez recevoir une expression de besoin et un sujet, avec 5 diagrammes à réaliser. 

Vous devez me rendre ces diagrammes au format .png (image).

Mettez vos diagrammes dans un dossier avec votre nom & prénom, mettez y les diagrammes et envoyez moi ce zip sur discord ou par email à cdric.brasseur@gmail.com