Langage de modélisation (UML)

Etude de cas 1 : Réseau social

Question 1 - Diagramme de cas d'utilisation

Puisque nous sommes dans un format textuel, je vais décrire précisément les éléments constitutifs de votre diagramme de cas d'utilisation. Pour dessiner ce diagramme sur votre copie, il suffit de placer les acteurs à l'extérieur du cadre du système et de relier ces acteurs aux bulles (cas d'utilisation) comme décrit ci-dessous.

1. Les Acteurs

• Internaute : Acteur principal (placé généralement à gauche).
• Membre : Acteur principal. Astuce de modélisation : Le texte indique "Tout comme l’internaute, un membre a la possibilité de...". Cela suggère une relation de généralisation. Le Membre hérite de l'Internaute.
• Administrateur : Acteur principal ou secondaire (gère les validations).

2. Les Cas d'utilisation et leurs relations

• Pour l'Internaute :

  • Consulter la rubrique Aide (Le Membre en hérite automatiquement).
  • S'inscrire : L'Internaute interagit avec ce cas. L'Administrateur interagit également avec ce cas (ou avec un cas inclus Valider inscription) pour valider le compte.

• Pour le Membre :

  • S'authentifier : Cas d'utilisation central.
  • Gérer ses amis : Le texte mentionne le traitement des demandes, l'invitation et le retrait. Ce sont des spécialisations de la gestion d'amis.
    • Relation : Gérer ses amis <<include>> S'authentifier.
    • Sous-cas (liés par héritage/généralisation ou <<extend>> vers Gérer ses amis) : Traiter une demande d'ajout, Inviter un membre, Retirer un ami.
  • Chercher un membre : <<include>> S'authentifier.
  • Publier du contenu : <<include>> S'authentifier. L'Administrateur interagit avec ce cas pour la validation.
    • Relation d'extension : Identifier un ami <<extend>> Publier du contenu (car le texte précise "s'il le souhaite", c'est donc optionnel).

Question 2 - Description textuelle du cas d'utilisation « Publier du contenu »

Voici la fiche de description textuelle complète, structurée selon les standards UML.

• Nom du cas d'utilisation : Publier du contenu
• Acteur principal : Membre
• Acteurs secondaires : Administrateur
• Préconditions : Le membre est authentifié sur l'application Web.
• Garanties en cas de succès (Post-conditions) : Le contenu est publié sur le réseau et visible.
• Scénario nominal (Suite d'événements normale) :
  1. Le membre choisit le type ou le contenu à publier.
  2. Le membre sélectionne la publication (soumission au système).
  3. Le système enregistre la demande et envoie une notification de validation à l'administrateur.
  4. L'administrateur consulte et valide (accepte) la publication.
  5. Le système enregistre la validation et publie le contenu sur le profil du membre.
• Scénarios alternatifs et d'exception :
  • 4a. Refus de la publication par l'administrateur : Si le contenu n'est pas conforme au règlement, l'administrateur refuse la publication. Le système notifie le membre du refus et annule la publication. Le cas d'utilisation se termine.
  • 5a. Identification d'un ami (Extension) : Une fois la publication acceptée (ou pendant la préparation), le membre choisit d'identifier un ami. Le système attache l'identification de l'ami à la publication.

Etude de cas 2 : L'Instance Supérieure Indépendante pour les Élections (ISIE)

Question 1 - Diagramme de cas d'utilisation

Identifions d'abord les composants du système pour structurer le diagramme.

1. Les Acteurs

• Administrateur : Acteur principal (gestionnaire avant les élections).
• Electeur : Acteur principal (utilisateur le jour J).
• Scrutateur : Acteur principal (utilisateur après les élections).
• Système de validation externe : Acteur secondaire (système informatique externe, généralement placé à droite du diagramme).
• Note sur l'Employé d'élection : Bien qu'il remette un bulletin, il n'interagit pas directement avec le système informatisé dans ce texte (il n'utilise pas l'appareil). Il est hors du périmètre informatique, il n'est donc pas strictement nécessaire de le modéliser comme acteur du système informatique, mais on peut le mentionner pour être exhaustif.

2. Les Cas d'utilisation et leurs relations

• Pour l'Administrateur (Avant le jour des élections) :

  • Gérer les partis politiques : Cas général.
  • Spécialisations ou extensions de la gestion des partis : Consulter la liste des partis, Ajouter un parti, Supprimer un parti, Modifier un parti. (La généralisation de cas d'utilisation est ici la méthode la plus élégante : ces 4 actions sont des sortes de "Gestion").

• Pour l'Electeur (Le jour des élections) :

  • Consulter la liste des partis politiques
  • Enregistrer vote : L'acteur Système de validation externe interagit également avec ce cas (ou avec le cas inclus S'authentifier).
    • Relation : Enregistrer vote <<include>> S'authentifier par carte.

• Pour le Scrutateur (Après les élections) :

  • Récupérer les résultats du vote
    • Relation d'extension : Imprimer les résultats <<extend>> Récupérer les résultats du vote (le texte indique "s'il le souhaite").
    • Spécialisations : Récupérer par ville et Récupérer par parti héritent de Récupérer les résultats.

Question 2 - Description textuelle du cas d'utilisation « Enregistrer vote »

• Nom du cas d'utilisation : Enregistrer vote
• Acteur principal : Electeur
• Acteurs secondaires : Système de validation externe (et indirectement l'Employé d'élection pour la procédure physique).
• Préconditions : L'appareil de vote est fonctionnel et l'électeur possède une carte d'électeur et un bulletin remis par l'employé.
• Post-conditions : Le vote de l'électeur est enregistré, la carte est marquée comme utilisée.
• Scénario nominal :
  1. L'électeur introduit sa carte d'électeur dans l'appareil de vote.
  2. Le système lit le numéro d'identification unique et l'envoie au système de validation externe (Inclusion du cas S'authentifier).
  3. Le système de validation externe confirme la validité de la carte.
  4. Le système déverrouille l'appareil de vote.
  5. L'électeur remplit son bulletin (action manuelle) et l'insère dans le lecteur de l'appareil.
  6. Le système lit et enregistre le vote en base de données.
• Scénarios alternatifs et d'exception :
  • 3a. Carte non valide (déjà utilisée ou erronée) : Le système de validation externe renvoie une erreur. Le système de vote bloque la carte. Le système informe l'électeur qu'il ne peut pas poursuivre. Le cas d'utilisation s'arrête (échec).

Méthode

Pour réussir ce type d'exercice d'analyse fonctionnelle (UML), voici les étapes systématiques à appliquer lors de votre lecture du sujet :

1. Identifier la frontière du système : Posez-vous toujours la question "Qui ou quoi interagit directement avec le logiciel ?". Cela vous évite de transformer des actions purement humaines (comme un employé qui tend un bout de papier) en cas d'utilisation informatiques.
2. Repérer les Acteurs : Cherchez les noms désignant des personnes (Internaute, Administrateur) ou des systèmes tiers (Système de validation externe). Séparez bien les acteurs principaux (ceux qui déclenchent l'action, à gauche) des acteurs secondaires (ceux qui sont sollicités par le système, à droite).
3. Lister les Cas d'utilisation : Soulignez les verbes d'action dans le texte (Consulter, S'inscrire, Ajouter, Récupérer). Un cas d'utilisation s'écrit toujours avec un verbe à l'infinitif.
4. Déduire les relations :
   • Le mot-clé "doit" ou "pour cela, il faut d'abord" indique généralement un <<include>> (ex: pour publier, il doit s'authentifier).
   • Les expressions "s'il le souhaite", "a la possibilité de", "peut également" (suite à une action principale) indiquent souvent un <<extend>>.
   • L'expression "Tout comme [Acteur A], [Acteur B] peut..." indique un héritage (généralisation) entre acteurs.
5. Rédiger la description textuelle : Restez factuel et linéaire. Numérotez vos étapes. Séparez de manière stricte le scénario où "tout se passe bien" (nominal) des cas où des erreurs surviennent (alternatifs/exceptions), en reprenant la numérotation de l'étape du scénario nominal où l'erreur se produit (ex: 3a, 4b).