DS 2022 — Société Sansouci

• En tant que cliente, je dois pouvoir planifier une intervention (choisir catégorie, date, durée, puis un créneau proposé).
• En tant que service planification, je dois pouvoir établir l'emploi du temps hebdomadaire des agents.
• En tant que service paye, je dois pouvoir établir le salaire mensuel de chaque agent.
• En tant que service facturation, je dois pouvoir éditer les factures mensuelles des clientes.

• L'agent n'a pas de fonctionnalité propre dans la description : il est destinataire de l'emploi du temps — pas un acteur qui démarre un cas d'utilisation.
• La catégorie est une donnée (évolutive), pas un acteur.
• La connexion/authentification : c'est une précondition du cas « Planifier une intervention » (ou un cas d'utilisation « Se connecter » relié — le sujet de TP précise qu'on peut l'ignorer dans le diagramme de classes).
• Temps pourrait être acteur des traitements mensuels/hebdomadaires s'ils sont automatiques — la description les attribue à des services, donc des acteurs humains.

• Categorie : nom : String, tauxHoraireFacture : double, salaireHoraire : double — le taux dépend de la catégorie.
• Agent : identité + competences (multiplicité 1..★ vers Categorie).
• Cliente : identité, compte.
• Intervention : date : Date, heureDebut, heureFin, liée à une Cliente, un Agent et une Categorie (par association).

Sansouci (ou SystemeInformation) avec une opération par cas d'utilisation : etablirEmploiDuTemps(…) pour la semaine, proposerCreneaux(…) / planifierIntervention(…) pour le site, etablirSalaires(…) et editerFactures(…). Pour que chaque opération soit implémentable, il faut pouvoir retrouver les interventions par agent, par cliente et par mois — d'où les associations et multiplicités (0..★ du côté des interventions).

• Ignorer la connexion (explicitement exclu de la question 3).
• Le taux horaire dépend de la catégorie, pas de l'agent : ne pas le mettre en attribut de Agent.
• Une intervention relie une cliente, un agent, une date, deux heures et une catégorie — les multiplicités sont toutes 1 de ce côté.
• Ne pas dupliquer la catégorie en attribut en ligne ET par association : si Categorie est dans le diagramme, c'est par association.

La méthode ne change jamais : extraire les phrases « En tant que …, je dois pouvoir … », l'acteur à gauche, le verbe d'action dans l'encadré. Ce qui est systématiquement piégé :

• une donnée (la catégorie de service, le produit, le film) n'est pas un acteur — c'est une classe du diagramme de classes ;
• un destinataire (l'agent qui reçoit son emploi du temps) n'initie rien : il ne porte aucun cas d'utilisation ;
• connexion / authentification : précondition du cas concerné (ou cas « Se connecter » relié), jamais une fonctionnalité métier à elle seule ;
• les traitements périodiques automatiques (fin de mois, chaque semaine) réveillent l'acteur Temps quand le sujet ne les attribue pas à un service ;
• les services externes (banque, facturation) sont des acteurs secondaires, dessinés de l'autre côté de la limite du système ;
• acteurs = des rôles (jamais de noms propres), cas d'utilisation = des verbes d'action avec l'acteur comme sujet actif.

Le squelette complet : système, cas d'utilisation, acteur principal, autres acteurs, déclencheur (si déclenchement automatique), préconditions, garanties en cas de succès, garanties minimales, scénario nominal, scénarios alternatifs. Les cinq règles du nominal, chacune vaut des points à chaque épreuve :

1. étape 1 : « L'acteur sélectionne la fonctionnalité … » ;
2. alternance stricte acteur / système ;
3. dernière étape réalisée par le système ;
4. rester abstrait : pas de bouton, de menu déroulant, de QR code — « sélectionne », « saisit », « valide » ;
5. garanties minimales : si le scénario n'aboutit pas, l'état du système reste inchangé. Les scénarios alternatifs se numérotent depuis l'étape du nominal qui dévie (4(A)…) avec reprise explicite (« revient à l'étape 2 du scénario nominal ») ou arrêt. Le DS 2022 n'en demandait pas — le prochain sujet peut les exiger.

La démarche attendue : classe Main (du nom du système), une méthode par cas d'utilisation, puis enrichir les classes de données jusqu'à ce que chaque méthode soit implémentable — sans rien de superflu. Ce qui est systématiquement piégé :

• attribut en ligne vs par association : si le type fait partie du diagramme, c'est par association — jamais les deux à la fois ;
• les multiplicités se justifient (les interventions d'un agent : 0..★ ; une intervention relie une cliente, un agent et une catégorie : 1) ;
• les valeurs qui dépendent d'une autre classe vont sur cette classe : le taux horaire facturé et le salaire dépendent de la catégorie ;
• ignorer la connexion quand le sujet l'exclut explicitement ;
• pas de visibilité, pas de getters/setters — trois zones par classe.

• Les calculs périodiques sont automatiques : l'acteur initiateur est Temps (déclencheurs : chaque semaine, chaque fin de mois), sur le modèle de la fiche Groupin du cours. Le service financier devient simple destinataire des résultats — comme l'agent de Sansouci, il n'initie plus rien et sort du diagramme.
• La vérification de capacité accompagne toutes les ventes, sans exception : c'est un «include» depuis Vendre des tickets. Un «extend» serait faux — l'extension est optionnelle, ici la vérification est obligatoire.
• Enregistrer un nouveau film, Planifier les séances et Vendre des tickets ne changent pas : mêmes acteurs, mêmes associations.

Scénarios alternatifs (complément à la fiche de la question 2) :

A : aucun créneau disponible — à l'étape 4, aucun agent compétent n'est
    disponible pour la catégorie, la date et la durée demandées.
4(A). Le système informe la cliente qu'aucun créneau ne correspond et
      propose de modifier la date ou la durée.
5(A). La cliente modifie sa demande ou abandonne.
6(A). Le système revient à l'étape 2 du scénario nominal.

B : créneau devenu indisponible — à l'étape 5, le créneau choisi vient
    d'être réservé par une autre cliente.
5(B). Le système détecte le conflit, retire le créneau et affiche les
      créneaux restants.
6(B). La cliente choisit un nouveau créneau ou abandonne.
7(B). Le système revient à l'étape 5 du scénario nominal.

Les deux alternatifs dévient depuis une étape système (4) et une étape acteur (5) : la numérotation suit l'étape du nominal, la reprise cite explicitement l'étape de retour, et chaque alternatif garde l'alternance acteur/système.

• Classe principale Plateforme, une méthode par cas d'utilisation : creerProjet(…), validerProjet(…), rechercherProjets(…), faireUnDon(…), reverserDon(…), obtenirRemboursement(…), consulterDonateurs(…).
• Classes de données : Projet (titre, description, montantCible, montantCollecte, dateFinCollecte, statut : String), Don (montant, date, numeroTransaction : String), Contrepartie (description, seuilMontant), Donatrice (identité).
• Associations : Donatrice — Don (émet, 0..★) ; Projet — Don (reçoit, 0..★) ; Don — Contrepartie (choisit, 0..1 — l'optionnalité du «extend» du TD/TP 1 devient une multiplicité) ; Plateforme — Projet (0..★).
• Les pièges :
  • pas de classe Banque : le service bancaire est un acteur externe du diagramme de cas d'utilisation ; dans les classes, la trace du paiement tient en un attribut numeroTransaction : String sur Don ;
  • le «extend» Choisir une contrepartie se traduit en multiplicité 0..1 sur l'association Don — Contrepartie, pas en cas supplémentaire ;
  • statut sur Projet (en cours, réussie, échouée) est ce qui permet d'implémenter Reverser son don et Obtenir le remboursement (déclenchés à l'échec de la collecte) ;
  • pas de visibilité, pas de getters/setters : trois zones par classe, attributs en ligne avec type et multiplicité.