Afin de bien visualiser les dépendances entre vos classes et vos couches, vous devez fournir un diagramme d'architecture simplifié. Pour ce faire, voici quelques directives :
Pas besoin des méthodes ni des attributs, seulement besoin des noms des classes
Pas besoin des classes de type value-object (ex: Email, PhoneNumber, SellerId, etc.) sauf si vraiment pertinent
N'inclure aucune classe que vous n'avez pas crées (ex: les classes de la librairie standard ou de Jakarta)
Reliez chaque classe aux autres classes avec une flèches si cette classe utilise (uses), reçoit (receives), créer (creates), trouve/sauvegarde (finds/saves), se transforme en (maps to), valide (validates), modifie (modifies), implémente (implements) etc. cette autre classe (pensez aux actions générale et non pas aux actions spécifiques comme "modifie le nom")
Indiquez clairement la couche d'appartenance de chaque classe (ex: à l'aide de couleurs et d'une légende)
Vous devez également, dans un cours texte associé :
Décrire les rôles des classes principales
Expliquer vos choix
Noter les endroits où les relations semblent suspectes et trouver des solutions potentielles
Autres conseils:
Pas d'annotations UML, seulement des flèches et des boîtes de base
Pour améliorer la lisibilité, vous pouvez faire 1 diagramme par objet central (Seller, Product, etc.) ou par action principale ("création produit", "obtention produits", etc.). Par contre, plus vous séparez en petits diagrammes, plus vous cachez les problèmes potentiels de votre architecture.
Évitez le plus possible les croisements et superpositions
Exportez votre diagramme en PNG, de qualité suffisante pour être très lisible
Français ou anglais, idéalement pas un mélange des deux
Diagrammes
Afin de bien visualiser les dépendances entre vos classes et vos couches, vous devez fournir un diagramme d'architecture simplifié. Pour ce faire, voici quelques directives :
Email,PhoneNumber,SellerId, etc.) sauf si vraiment pertinentVous devez également, dans un cours texte associé :
Autres conseils:
Seller,Product, etc.) ou par action principale ("création produit", "obtention produits", etc.). Par contre, plus vous séparez en petits diagrammes, plus vous cachez les problèmes potentiels de votre architecture.Exemple de diagramme pour une feature très simple de "gestion des utilisateurs" (incomplet) :