TD/TP 3 — Diagramme de classes
Correction complète du TD/TP 3 : la méthode « une méthode par cas d'utilisation » appliquée aux deux cas d'étude — la plateforme de financement participatif et le SI de l'atelier, diagrammes corrigés et associations expliquées.
PowerAMC : modèle de diagramme de classes
Fichier → Nouveau modèle → Modèle Orienté Objet → Diagramme de classes → nommer. Le critère principal : le diagramme doit permettre d'implémenter les fonctionnalités identifiées dans le diagramme de cas d'utilisation. Il fait donc figurer :
- pour chaque classe de données, ses attributs ;
- pour la classe principale, ses opérations et ses attributs ;
- des opérations dans les classes de données quand une fonctionnalité l'exige.
Ne pas faire figurer : constructeurs, getters et setters, ni la visibilité (PowerAMC impose d'en choisir une — prendre private). Pour les sujets du semestre, pas d'interfaces ni d'héritage : seuls les outils non rayés de la palette sont autorisés. Palette refermée par inadvertance : menu Outils → Personnaliser les barres d'outils → cocher Palette.
Éditer une association
Créée à la souris, une association sort navigable dans un sens avec des cardinalités
0..1 / 0..* par défaut — presque jamais adaptées. Double-clic sur l'association,
onglet Détails : enlever les cardinalités inutiles, donner les noms de rôles,
corriger la navigabilité.
Travail demandé
Capture d'écran sur Moodle avant la fin du TD/TP pour chacun :
- Plateforme de financement participatif — rouvrir le diagramme de cas d'utilisation rendu au TD/TP 1, puis faire le diagramme de classes.
- SI d'un atelier — rouvrir le diagramme de cas d'utilisation, puis le diagramme de classes en ignorant les fonctionnalités de connexion / authentification.
C'est exactement la méthode du cours : une méthode par cas d'utilisation dans la classe principale, et on enrichit le diagramme jusqu'à ce que chaque cas soit implémentable — ni plus, ni moins.
Corrigé 1 — Plateforme de financement participatif
On repart du diagramme de cas d'utilisation du TD/TP 1 (porteuse de projet, donatrice,
administrateur, service bancaire). Comme au cours, on liste d'abord les fonctions
principales — une par cas d'utilisation — et leurs données en entrée : c'est le
squelette de la classe principale Plateforme.
Fonction (classe Plateforme) | Données en entrée |
|---|---|
soumettreProjet | titre, description, montantCible, dateFin |
validerProjet | le projet proposé |
rechercherProjets | critère (thème, statut…) |
faireUnDon | le projet, le montant, la contrepartie (optionnelle) |
reverserDon | le don, le projet destinataire |
rembourserDon | le don |
consulterDonateurs | le projet |
Puis on enrichit : soumettreProjet exige de stocker les projets → classe Projet
avec son état de collecte ; faireUnDon exige de mémoriser chaque don et la
contrepartie choisie → Don et Contrepartie ; reverserDon et rembourserDon
exigent de retrouver les dons d'un projet en fin de collecte échouée → l'association
Projet—Don et le statut.
Plateforme—Projetprojets 0..★ : la classe principale connaît tous les projets — indispensable àrechercherProjetsetvaliderProjet.Donatrice—Donémet 0..★ : une donatrice émet plusieurs dons, un don a exactement une donatrice.Projet—Donreçoit 0..★ : c'est par là queconsulterDonateursetrembourserDonretrouvent les dons d'un projet.Don—Contrepartiechoisie 0..1 : le «extend» Choisir une contrepartie du TD/TP 1 devient une simple multiplicité optionnelle — le don peut exister sans contrepartie.Projet—Contrepartiepropose 1..★ : les contreparties et leurs seuils sont définis par projet.
- Pas de classe
Banque: le service bancaire est un acteur externe du diagramme de cas d'utilisation ; sa trace dans les classes tient en un attributnuméroTransaction : StringsurDon. - Pas de duplication en ligne ET par association : une donnée ne figure
qu'une seule fois —
statutest un attribut en ligne deProjetparce qu'un statut n'est pas une classe du diagramme. montantCollectéest dérivable (somme des dons) : on le garde parce que les fonctionnalités l'affichent en permanence — mais le diagramme minimal sans lui reste défendable, l'essentiel est l'associationProjet—Don.- En PowerAMC : donner les noms de rôles ci-dessus, corriger les
cardinalités par défaut (
0..1/0..*) et la navigabilité (flèche deDonversContrepartie— le don connaît sa contrepartie, pas l'inverse).
Corrigé 2 — SI de l'atelier (FabLab)
Deuxième cas d'étude du TD/TP 1 (secrétaire, cliente, machines, facturation), en
ignorant connexion et authentification comme le demande le sujet — donc aucun
attribut identifiant / motDePasse au diagramme. La classe principale Atelier
porte une méthode par cas d'utilisation :
Fonction (classe Atelier) | Données en entrée |
|---|---|
inscrireCliente | nom, prénom, adresse mail |
reserverMachines | la cliente, la séquence de machines, la date, la tranche horaire, les fichiers |
annulerReservation | la réservation |
éditerFacturesMensuelles | — (déclenché en fin de mois) |
Les réservations séquentielles de machines amènent Reservation, Machine et les
fichiers de description ; la facturation mensuelle amène Facture.
Atelier—Clienteclientes 0..★ : l'inscription sur place remplit cette collection ; l'adresseMailde la cliente sert à l'envoi des factures mensuelles.Cliente—Reservationeffectue 0..★ : une cliente réserve plusieurs fois ; une réservation appartient à une cliente.Reservation—Machineconcerne 1..★ : une réservation est une séquence ordonnée de machines/postes (menuiserie puis découpe laser puis peinture) — d'où la collection non vide.Reservation—FichierDescriptiondécrits 0..★ : les fichiers (vectoriels, 3D…) ne concernent que les machines qui en ont besoin, et leurtempsNécessairepermet au système de vérifier/ajuster la durée demandée (l'«extend» Ajuster la durée du TD/TP 1).Facture—Clientedestinataire 1 : les factures sont mensuelles et par cliente — c'est ce qui rendéditerFacturesMensuelles()implémentable.
- Aucune classe
SecrétaireniService facturation: ce sont des acteurs du diagramme de cas d'utilisation, pas des classes — les opérationsinscrireClienteetéditerFacturesMensuellessont dansAtelier. - Pas de classe
Machine réservéenon plus : la machine est une classe de données ; l'arrêt automatique en fin de créneau est un comportement du système, pas un attribut. - Pas d'
identifiantni demotDePassesurCliente: les cas de connexion / authentification sont ignorés — leurs attributs seraient des informations superflues, exactement ce que la méthode élimine. statutsurReservation(planifiée, honorée, annulée) rendannulerReservationimplémentable sans toucher au reste.- Toujours en PowerAMC : rôles nommés, cardinalités corrigées, navigabilité
de
ReservationversMachineetFichierDescription.
Sujet de DS 2022.pdf
R3.03 · Pour s'entraîner : la question 3 du DS 2022 demande le diagramme de classes de Sansouci
Chargement du document…
Dernière mise à jour le
TD/TP 2 — Scénarios (Fiches descriptives)
Correction complète du TD/TP 2 : fiches descriptives rigoureuses pour les cas d'étude du financement participatif, de l'atelier FabLab et du DS de révision.
DS 2022 — Société Sansouci
L'annale complète du DS du 28/09/2022 (1 h 30) : le cas de la société Sansouci, diagramme de cas d'utilisation, fiche descriptive de planification et diagramme de classes — démarche expliquée.