Analyse des acteurs et cas d’utilisation pour Sysvote

Exercice 1 - Spécification des besoins

Question 1 - Acteurs de l'application

Voici l'identification des acteurs pour l'application "Sys_vote". Un acteur représente une entité externe (humain, matériel ou un autre système) qui interagit directement avec le système modélisé.

Nom	Statut	Justification (si non retenu) / Type (si retenu)
a. Appareil	Non retenu	Il s'agit du système informatique lui-même (ou de l'un de ses composants matériels), et non d'une entité externe qui interagit avec.
b. Administrateur	Acteur	Principal : Il configure et gère le système (ajout de partis, gestion technique).
c. Serveur Central	Acteur	Secondaire : Il reçoit les résultats ou fournit les listes électorales. C'est un système externe.
d. Directeur Général Des Élections	Acteur	Principal : Il interagit avec le système pour déclencher des actions globales ou consulter les résultats finaux.
e. Electeur	Acteur	Principal : Utilisateur direct du système dont le but est d'enregistrer son vote.
f. Partie Politique	Non retenu	C'est une donnée ou une information gérée par le système (une classe métier), mais le parti n'interagit pas physiquement avec la machine de vote.
g. Employé	Non retenu	Terme beaucoup trop vague. On préfèrera utiliser un rôle spécifique comme "Administrateur" ou "Scrutateur".
h. Bulletin	Non retenu	C'est un objet informatique (le résultat du vote) ou un concept, il n'a aucun comportement actif vis-à-vis du système.
i. Lecteur De L’appareil De Vote	Non retenu	C'est un composant matériel (interface) qui fait partie des frontières du système, pas un acteur externe.
j. Horloge	Acteur	Secondaire : Système externe autonome qui déclenche des événements temporels (ex: ouverture/fermeture automatique du scrutin).
k. Scrutateur	Acteur	Principal : Personne responsable d'un bureau de vote qui interagit avec l'application pour ouvrir, fermer ou auditer une machine.

Question 2 - Cas d'utilisation complémentaires

Un cas d'utilisation doit représenter un service complet rendu par le système à un acteur, apportant une valeur ajoutée observable.

Actions	Statut	Justifications
a. Consulter liste des partis politiques	Retenu	Service autonome pour un électeur ou un administrateur souhaitant s'informer avant le vote ou vérifier la base de données.
b. S’identifier	Retenu	Sous-fonctionnalité majeure, souvent modélisée comme un cas d'utilisation inclus (relation «include») dans le vote ou l'administration.
c. Compléter le bulletin	Non retenu	C'est une étape interne (une action ou un scénario) du cas d'utilisation principal "Voter pour un parti", pas un cas d'utilisation indépendant.
d. Modifier les informations sur un parti politique	Retenu	Action métier complète (CRUD) nécessaire pour l'administrateur afin de maintenir les données à jour.
e. Ajouter un nouveau parti politique	Retenu	Action métier complète (CRUD) de configuration initiale du système par l'administrateur.
f. Récupérer le résultat du vote	Retenu	Objectif métier fondamental pour le Scrutateur ou le Directeur à la fin de la période électorale.
g. Accéder aux données globales	Retenu	Cas d'utilisation de reporting global utile au Directeur Général des Élections ou au Serveur Central.
h. Enlever un parti politique existant	Retenu	Action métier complète (CRUD) de maintenance pour l'administrateur.

Question 3 - Diagramme de cas d'utilisation

Note : Le format texte ne permettant pas de tracer des diagrammes graphiques UML, voici la description structurelle exacte des éléments et de leurs relations que vous devez dessiner.

Acteurs :

• Électeur (Bonhomme allumette, placé à gauche)
• Scrutateur (Bonhomme allumette, placé à gauche ou à droite)

Cas d'utilisation et dépendances (à placer dans le cadre du système) :

• L'acteur Électeur est relié par une association simple au cas d'utilisation (Voter pour un parti politique).
• L'acteur Scrutateur est relié par une association simple au cas d'utilisation (Comptabiliser les votes).
• Le cas (Voter pour un parti politique) pointe vers le cas (S'identifier) avec une flèche en pointillés stéréotypée «include» (l'identification est obligatoire pour voter).
• Si le scrutateur doit aussi s'identifier, le cas (Comptabiliser les votes) pointe également vers (S'identifier) avec une flèche «include».

Question 4 - Spécification de l'ordre d'exécution

Un diagramme de cas d’utilisation uniquement permet-il de spécifier l’ordre d’exécution des cas ?

Non. Le diagramme de cas d'utilisation est un diagramme structurel d'exigences. Il décrit le "quoi" (les fonctionnalités offertes) et le "qui" (les acteurs impliqués), mais en aucun cas le "quand" ou le "comment". L'ordre chronologique d'exécution, la logique conditionnelle et les boucles doivent être modélisés par des diagrammes comportementaux, tels que les diagrammes de séquence (pour les échanges chronologiques de messages) ou les diagrammes d'activité (pour le flux de contrôle).

Question 5 - Scénarios du cas « voter pour un parti politique »

a. Pré-condition au cas : La machine de vote est dans l'état "scrutin ouvert", et l'électeur dispose de ses identifiants valides (carte d'électeur, code, ou biométrie) non encore utilisés.

b. Variantes de scénarios :

• Nominal : Le scénario idéal. L'électeur s'identifie avec succès, le système affiche la liste des partis. L'électeur sélectionne un parti, valide son choix. Le système enregistre le vote de manière anonyme, incrémente le compteur du parti, marque l'électeur comme "a voté" et affiche un message de confirmation.
• Alternatif : Le scénario qui atteint l'objectif par un chemin différent. L'électeur s'identifie, consulte la liste, mais décide de voter "Blanc". Il sélectionne l'option "Vote Blanc", valide. Le système enregistre un vote blanc, marque l'électeur comme "a voté" et confirme. (Un autre alternatif valable : l'électeur se trompe, annule sa sélection avant la validation finale, et choisit un autre parti).
• Exceptionnel : Le scénario d'échec. L'électeur insère sa carte, mais le système détecte qu'il est déjà marqué comme "a voté" dans la base de données. Le système refuse l'accès, génère une alerte d'anomalie, n'affiche pas les bulletins, et met fin au cas d'utilisation.

Question 6 - Scénarios du cas « comptabiliser les votes »

• Nominal : À l'heure de fermeture, le scrutateur lance la comptabilisation. Le système clôture définitivement les votes, fait la somme des bulletins pour chaque parti politique, génère un procès-verbal électronique chiffré, l'affiche à l'écran du scrutateur et l'envoie au serveur central.
• Alternatif : Durant la journée (si la loi l'autorise), le scrutateur demande une comptabilisation partielle (taux de participation). Le système calcule uniquement le nombre de votants par rapport aux inscrits sans dépouiller les bulletins pour préserver le secret, et affiche ce chiffre au scrutateur.

Exercice 2 : Analyse + Conception

Note concernant la source : L'énoncé original mentionne un "diagramme de classes suivant" à compléter, mais celui-ci est absent du document extrait. Les réponses suivantes sont basées sur les règles canoniques de modélisation UML d'un jeu d'échecs demandées par le texte.

Partie 1 : Analyse

Question 1 - Complétion du diagramme de classes (Jeu d'échecs)

Justifications des modifications :

1. Cardinalités manquantes :
   • JeuEchecs (1) --- (1) Echiquier : Un jeu ne possède qu'un seul plateau de jeu, et un plateau appartient à un seul jeu à la fois.
   • Echiquier (1) --- (64) Case : Un échiquier standard est obligatoirement composé de 64 cases fixes.
   • JeuEchecs (1) --- (32) Piece : Un jeu d'échecs standard débute avec exactement 32 pièces (16 blanches, 16 noires).
2. Associations avec la classe Coup :
   • Un Coup doit lier une Piece (celle qui bouge, multiplicité 1).
   • Un Coup doit lier une Case de départ (multiplicité 1) et une Case d'arrivée (multiplicité 1).
   • Un Coup appartient à l'historique du JeuEchecs (JeuEchecs 1 --- 0..* Coup).
3. Composition et Agrégation :
   • Composition (Losange plein) : Entre JeuEchecs et Echiquier / Case. Les cases n'ont pas d'existence propre en dehors de l'échiquier, et l'échiquier n'a pas de sens sans le jeu. La destruction du jeu détruit le plateau.
   • Agrégation (Losange vide) ou Association simple : Entre Case et Piece. Une pièce est "posée sur" une case (0..1 pièce par case, 1 case par pièce active), mais la pièce a une existence indépendante de la case.

Question 2 - Diagrammes d'objets

La consigne exige de représenter uniquement les cases occupées pour plus de clarté.

a. Disposition initiale (Extrait descriptif) : Le diagramme d'objets (instances) montrerait :

• Un objet j1 : JeuEchecs lié à e1 : Echiquier.
• L'objet e1 est composé de plusieurs objets Case (ex: c_e2 : Case, c_e7 : Case).
• Des instances de pièces : pB : Pion (avec attribut couleur = blanc), pN : Pion (couleur = noir).
• Des liens d'association : L'instance pB est liée à la case c_e2. L'instance pN est liée à la case c_e7.

b. Évolution après deux coups (Extrait descriptif) :

• Les instances j1, e1, c_e2, c_e7, c_e4, c_e5, pB, pN existent toujours.
• Le lien entre pB et c_e2 est détruit. Un nouveau lien relie pB à c_e4 (Pion blanc avance).
• Le lien entre pN et c_e7 est détruit. Un nouveau lien relie pN à c_e5 (Pion noir avance).
• Création de deux instances de Coup :
  • coup1 : Coup lié à pB, à c_e2 (départ) et à c_e4 (arrivée).
  • coup2 : Coup lié à pN, à c_e7 (départ) et à c_e5 (arrivée).
  • Ces deux instances coup1 et coup2 sont reliées à l'instance j1 : JeuEchecs.

Partie 2 : Conception

Question 1 - Contraintes sur les associations

• JeuEchecs-Piece : {frozen} (ou gelé).
  • Justification : Les 32 pièces créées lors de l'instanciation du jeu appartiennent à cette instance de jeu jusqu'à la fin. On n'ajoute pas de nouvelles pièces venues d'ailleurs pendant la partie (même la promotion remplace l'état de la pièce, elle ne crée généralement pas un objet d'un autre jeu).
• JeuEchecs-Coup : {ordered} et {addOnly}
  • Justification : Les coups forment un historique. {ordered} est indispensable car l'ordre chronologique dicte l'état de la partie. {addOnly} est pertinent car, dans le déroulement légal et le registre final de la partie, un coup joué ne s'efface pas.
• Echiquier-Case : {frozen}
  • Justification : Le lien structurel de l'échiquier est immuable. Les 64 cases sont créées à l'initialisation et ne sont jamais supprimées, retirées ou déplacées.

Question 2 - Structures de collections (C++ STL)

• JeuEchecs-Piece : std::array<Piece, 32> (ou un tableau statique classique Piece[32]).
  • Commentaire : La collection est de taille fixe et connue à la compilation. Un tableau statique est parfait pour la performance spatiale et temporelle.
• JeuEchecs-Coup : std::vector<Coup>
  • Commentaire : Le nombre total de coups dans une partie est variable et inconnu à l'avance. On ajoute constamment des éléments en fin de collection. Le vector offre un redimensionnement dynamique et préserve l'ordre séquentiel (parfait pour l'historique et la contrainte {ordered}).
• Echiquier-Case : std::array<std::array<Case, 8>, 8> (ou tableau 2D statique Case[8][8]).
  • Commentaire : Taille absolument fixe de 8x8. Permet un accès direct en O(1) via les index (ligne, colonne).

Question 3 - Ordre de navigation

• Savoir si une case est jouable ou non pour une pièce donnée :
  • Navigation : Piece → Case (actuelle) + Règles propres → Interroger l'Echiquier → Case (visée) → Vérifier association Case-Piece cible.
  • Commentaire : On part de la pièce pour obtenir ses règles de déplacement brutes. On interroge ensuite le plateau pour voir si la trajectoire vers la case visée est libre, puis on vérifie si la case d'arrivée est vide ou occupée par une pièce ennemie.

Savoir si une pièce est en risque d'attaque par une pièce de l'adversaire :

• Navigation : Echiquier → Liste des Piece adverses actives → Pour chaque Piece adverse, calculer ses mouvements possibles → Case visée = Case de notre pièce ?
• Commentaire : Pour évaluer un risque (notamment l'échec), il faut itérer de manière systématique depuis le plateau (ou le jeu) vers l'ensemble des pièces adverses, puis naviguer vers les cases qu'elles contrôlent.

Question 4 - Mémorisation des coordonnées dans la classe 'Case'

Avantage : Un objet Case se "connaît" lui-même. N'importe quel objet possédant une référence vers une Case peut demander directement sa position sans avoir besoin de faire une requête coûteuse au plateau (Echiquier) pour la chercher. L'accès est de complexité temporelle O(1).

Inconvénient : Redondance et risque d'incohérence. Si l'échiquier est implémenté sous forme de matrice (ex: Case[8][8]), les coordonnées sont déjà définies par les indices du tableau. Stocker x et y à l'intérieur de la classe duplique l'information, consomme plus de mémoire (faible impact ici, mais mauvais principe de conception) et risque de créer un état contradictoire (ex: l'objet en [0][0] prétend que ses coordonnées sont x=5, y=2).

Question 5 - Diagramme d'états/transitions de la classe JeuEchecs

Description textuelle du diagramme à modéliser :

1. État initial (Point noir plein) pointant vers l'état Initialisation.
2. État : Initialisation
   • Transition automatique (mise en place terminée) pointant vers Tour des Blancs.
3. État : Tour des Blancs
   • Transition "Coup valide joué par les Blancs" pointant vers Tour des Noirs.
4. État : Tour des Noirs
   • Transition "Coup valide joué par les Noirs" pointant vers Tour des Blancs.
5. État : Fin de partie (qui peut être divisé en sous-états Victoire Blancs, Victoire Noirs, Nulle/Pat).
   • Depuis Tour des Blancs, transition "Roi adverse échec et mat" ou "Abandon des Noirs" vers Fin de partie.
   • Depuis Tour des Noirs, transition "Roi adverse échec et mat" ou "Abandon des Blancs" vers Fin de partie.
   • Depuis n'importe quel tour, transition "Situation de Pat / 50 coups / Répétition / Accord mutuel" vers Fin de partie.
6. Depuis Fin de partie, flèche vers l'État final (Cercle contenant un point noir).

Méthode

Face à une épreuve d'Analyse et Conception (UML) :

1. Lisez l'énoncé comme un cahier des charges : Chaque nom correspond potentiellement à une classe ou un acteur, chaque verbe à une méthode, un cas d'utilisation ou une association. Ne sur-modélisez pas : tenez-vous strictement au périmètre du texte (ex: dans l'exercice 1, ne gardez que les acteurs qui interagissent numériquement avec le système décrit).
2. Maîtrisez le vocabulaire formel UML : La différence entre composition et agrégation est classique. Posez-vous toujours la question de la durée de vie : si "A" est détruit, "B" survit-il ? Si non, c'est une composition (losange plein).
3. Faites le pont entre Modèle et Implémentation : L'UML n'est pas qu'un dessin. Quand on vous demande de choisir une collection STL (Exercice 2, Partie 2), projetez la multiplicité UML (statique 1..* ou dynamique 0..*) directement dans le code source (tableau vs vecteur dynamique).
4. Assainissez les cas d'utilisation : Un cas d'utilisation n'est jamais une action unitaire basique de l'interface graphique ("cliquer sur bouton", "compléter un champ"). C'est un objectif métier ("Voter", "Comptabiliser"). Si vous identifiez une action technique, c'est probablement un fragment de scénario, pas une bulle sur le diagramme.