Dans ce labo, tu vas produire plusieurs diagrammes UML pour ton propre projet. L’objectif n’est pas seulement de « faire des dessins », mais de clarifier ton système et de préparer le travail des prochains sprints.

Tu dois respecter pour chaque type de diagramme les éléments demandés dans le Module 8, afin d’éviter des diagrammes trop simples ou incomplets.

Objectifs du labo

• Clarifier les fonctionnalités du système avec un diagramme de cas d’utilisation complet.
• Décrire un scénario important avec un diagramme d’activités.
• Modéliser la structure du domaine avec un diagramme de classes.
• Illustrer un cas concret avec un diagramme d’objets.
• Montrer les interactions au cours d’un scénario avec un diagramme de séquence.

Consignes générales

• Tous les diagrammes doivent être liés au même projet que celui utilisé dans les sprints.
• Les diagrammes doivent être lisibles, avec des noms clairs et une mise en page soignée (éviter les lignes qui se croisent dans tous les sens).
• Place toutes les images et fichiers sources de diagrammes dans docs/technique/diagrammes/ (ou un dossier équivalent) dans ton dépôt.
• Ajoute un fichier README.md dans ce dossier, qui liste les diagrammes produits et explique brièvement ce que montre chacun.

1. Diagramme de cas d’utilisation

Produis un diagramme de cas d’utilisation pour ton système, en respectant les exigences suivantes :

• Au moins deux acteurs (par exemple : utilisateur, administrateur, système externe).
• Plusieurs cas d’utilisation (pas un seul cas énorme qui fait tout).
• Une frontière de système clairement indiquée.
• Des relations entre acteurs et cas d’utilisation.
• Au moins un <<include>> pour un comportement commun.
• Au moins un <<extend>> pour un comportement optionnel ou exceptionnel.

Enregistre l’image (ou le fichier du logiciel de modélisation) dans le dossier des diagrammes, avec un nom parlant (par exemple use-case-principal.png).

2. Diagramme d’activités

Choisis un scénario important de ton application (par exemple « passer une commande », « créer un compte », « réserver une ressource ») et représente-le avec un diagramme d’activités.

• Un point de départ et au moins un point de fin.
• Des activités (actions) nommées clairement.
• Des flèches montrant l’ordre des étapes.
• Au moins un losange de décision avec des conditions sur les flèches.
• Si possible, un exemple de parallélisme (deux activités en parallèle).

Enregistre ce diagramme dans le dossier des diagrammes, par exemple sous le nom activite-scenario-principal.png.

3. Diagramme de classes

Produis un diagramme de classes pour le domaine principal de ton système. Il doit être cohérent avec les données réellement manipulées par ton application.

• Plusieurs classes avec un nom significatif.
• Pour chaque classe, quelques attributs importants (avec type si possible).
• Des opérations pour certaines classes (méthodes principales, pas tous les détails techniques).
• Des associations entre classes, avec multiplicités si possible.
• Au moins un exemple d’héritage si ton domaine s’y prête.

Enregistre ce diagramme dans le dossier des diagrammes, par exemple sous le nom classes-domaine.png.

4. Diagramme d’objets

À partir de ton diagramme de classes, construis un diagramme d’objets qui illustre un cas concret (par exemple « une commande avec plusieurs produits pour un client donné »).

• Plusieurs objets notés nomObjet : NomClasse.
• Des valeurs d’attributs pour certains objets (par exemple id, nom, statut).
• Des liens entre objets qui correspondent aux associations de ton diagramme de classes.

Enregistre ce diagramme dans le dossier des diagrammes, par exemple sous le nom objets-exemple.png.

5. Diagramme de séquence

Choisis un scénario clé (souvent le même que pour le diagramme d’activités) et produis un diagramme de séquence qui montre les interactions entre acteurs et objets.

• Un acteur et plusieurs objets alignés horizontalement (lifelines).
• Des messages nommés clairement envoyés dans un certain ordre (de haut en bas).
• Au moins un aller-retour complet (requête + réponse).
• Si possible, une condition ou une alternative (par exemple un bloc « alt » ou « loop » selon l’outil utilisé).

Enregistre ce diagramme dans le dossier des diagrammes, par exemple sous le nom sequence-scenario-principal.png.

Diagrammes optionnels (bonus)

Si tu le souhaites, tu peux produire un ou plusieurs diagrammes UML optionnels qui apportent une vraie valeur à ton projet (composants, déploiement, états-transitions, etc.).

Si tu en ajoutes, indique-les aussi dans ton fichier README.md avec une courte explication de leur utilité.

Remise du labo

Pour remettre ce labo, assure-toi que ton dépôt contient :

• Le dossier docs/technique/diagrammes/ avec les 5 diagrammes demandés (et éventuellement des diagrammes bonus).
• Un fichier README.md dans ce dossier qui indique :
  • la liste des diagrammes ;
  • pour chaque diagramme, le scénario ou la partie du système qu’il illustre.

Ton enseignant pourra te demander un court survol en classe ou en démonstration pour vérifier que tu comprends tes propres diagrammes.