TD1
Diagrammes de cas d'utilisation
Introduction
Bienvenue à ma troisième séance de travaux dirigés en COO, le premier TD porte sur les diagrammes de cas d'utilisation. Il se divise en quatre séances, chacune ayant pour objectif de présenter une notion supplémentaire à propos de ces diagrammes. Pendant ces quatre premières séances, il s'agit de comprendre comment fonctionnent les diagrammes de cas d'utilisation. La troisième séance a pour but d'introduire la description avancée des cas d'utilisation, et notamment les flots basiques et alternatifs.
cours
La semaine du 15 janvier, nous avons eu un cours magistral qui portait sur les diagrammes de cas d'utilisation. Vous pouvez retrouver le cours si besoin grâce au lien ci-dessous : Pour réviser c'est par ici !
Points-clé
Avant de commencer le TD, nous allons rappeler les points importants pour cette première séance. Pour cela, nous allons définir les notions clés que nous allons utiliser. Lors de cette troisième séance, nous allons aborder les notions de flots basiques et alternatifs. Ce qui va nous permettre de décrire chaque étape du cas d'utilisation par des phrases courtes, organisées séquentiellement. Pour cela, on structure le flot de base en étapes majeures, numérotées et nommées. Puis on identifie les flots alternatifs et les flots d'erreurs. Mais attention, tout cela se trouve dans un autre fichier à part.
Mais alors qu'est ce que le flot nominal, alternatif, d'erreurs ? Et bien voyons tout cela de plus près.
- Je ne vous ai pas dit, mais avant de commencer à décrire le flot nominal, on commence par rappeler les préconditions.On décrit ce que l'on doit respecter pour pouvoir entrer dans le flot nominal.
- Après avoir rempli les préconditions, on décrit le flot nominal qui correspond bon déroulement du cas d'utilisation, il n'y a donc aucun échec.
- Ensuite, viennent les folts alternatifs, qui correspondent au déroulement alternatif du cas d'utilisation.
- Pour finir par les flots d'erreurs, qui correspond quant à lui au déroulement des cas d'utilisation des flots nominaux et alternatifs quand il se produit une erreur dans ceux-ci.
- dernière chose, on n'oublie pas de rappeler les postconditions, soit le résultat de notre cas d'utilisation.
- Le coordinateur démarre un processus de gestion de crise.
- Le coordinateur saisit les informations de la crise (nom, prénom, numéro tél, type de crise).
- Le système vérifie l’adresse mail.
- Le système envoie le numéro de téléphone ainsi que le nom et le prénom au service de téléphonie.
- Le service de téléphonie valide le numéro les informations envoyées.
- Le système envoie un mail de confirmation.
- Le coordinateur valide son mail.
- Le système enregistre les informations.
- Le système propose de ressaisir les coordonnées du témoin.
- Le coordinateur accepte.
- Retour au point 2 du flot nominal
- Le système propose de stopper la saisie de la déclaration.
- Le flot termine sur un échec
- Le système affiche un message d’erreur.
- Retour au point 2 du flot nominal.
- Le système affiche un message d’erreur.
- Le système envoie un mail de suspicion à l’adresse entrée.
- Retour au point 2 du flot nominal.
- Le coordinateur appelle le service de vérification des numéros de téléphone.
- Le coordinateur ne parvient pas à contacter le service de vérification des numéros de téléphone.
- Le flot termine sur un échec.
étude de cas
exemple étude de cas
"Luke" initie le processus de gestion de crise en enregistrant la déclaration de "Leia". Il enregistre son prénom et son nom "Leia Organa", son téléphone "+100 1221211". Le système externe reconnait l'adéquation entre le nom et le numéro de téléphone. Puis Luke saisit sous une forme textuelle "Assaut de la station étoile située dans la galaxie. De nombreux blessés. …". L'application envoie cette déclaration à une IA externe qui analyse le texte et en retour identifie le type de crise.
consignes
Complétez le diagramme de cas d'utilisation si besoin.
Description détaillée du use case correspondant à l'étape "Un coordinateur initie le processus de gestion de crise en enregistrant la déclaration du témoin. etc." en tenant compte des informations additionnelles qui vous ont été données ci-dessus.
Description détaillée du cas où l'identification avec le numéro de téléphone échoue. Dans ce cas, vous proposez de saisir à nouveau les coordonnées du témoin ou de stopper la saisie de la déclaration.
Description détaillée du cas où vous ne parvenez pas à contacter le service de vérification des numéros de téléphone. Dans ce cas, vous continuez en mode "bris de glace", tout se passe pour vous comme si vous aviez stoppé le UC.
Complétez votre flot d'évènements pour tenir compte de l'exemple qui vous est donné comme une base de tests.
Finaliser de bout en bout, c'est à dire de la définition des cas d'utilisation à leur description en intégrant la prise en compte des données les 3 parties d'évaluations qui ont porté sur la gestion de crise dans les outils y compris.
Solution
Description des scénarios :
Scénario nominal :
Un coordinateur initie le processus de gestion de crise en enregistrant la déclaration du témoin. Il rentre les informations dans le système qui va pouvoir débuter son travail d’analyse.
Précondition :
Être connecté au système
Flot nominal :
Luke saisit « Leia ».
Luke saisit « Leia », « Organa », « +100 1221211 ».
Le système envoie les informations à l’IA externe.
Le système envoie les informations au système externe de téléphonie.
Le système externe de téléphonie vérifie les informations envoyées.
Le système envoie un mail de confirmation à l’adresse entrée.
Luke valide le mail de confirmation.
Le système envoie les informations dans une base de données.
Flot alternatif :
2.a) La vérification par le système des informations échoue lors de la première saisie.
Luke saisit des coordonnées « Leia », « Organa », « +100 1221211 » .
Luke valide les données saisies
Le système renvoie Luke à la page de saisie des coordonnées<
2.b) La vérification par le système des informations échoue lors de la deuxième saisie.
Luke valide le champ permettant de stopper la saisie de déclaration.
Le système arrête le processus de GC
3.a) L’adresse mail n’est pas valide
Affichage du message d’erreur « mail non valide ».
Le système renvoie Luke à la page de saisie des coordonnées.
3.b) L’adresse mail est déjà utilisée.
Affichage du message d’erreur « ce mail est déjà utilisé ».
Envoie d’un mail à l’adresse entrée.
Le système renvoie Luke à la page de saisie des coordonnées.
4.a) Le numéro de téléphone saisie est invalide.
Saisit du numéro de téléphone du service de vérification.
Luke tombe sur le répondeur et raccroche son téléphone.
Passage en mode « bris de glace ».
Le système arrête le processus de GC.
Post-condition :
Le témoignage a bien été enregistré
Glossaire :
Coordinateur : initie le processus de gestion de crise en enregistrant la déclaration du témoin et traite les missions en allouant des ressources (personnes, camions, etc.) appropriées à chaque tâche.
Travailleur : Personnel tenu de signaler auprès du système l’évolution de sa mission.
Gestion de crise : méthodologie d’action d’une entreprise permettant de résoudre dans les plus bref délais une situation problématique.
Super-observateur : expert dans le domaine (de crise dans ce cas).
Système externe de recommandations : système qui aide le super-observateur.
Système externe de téléphonie : système qui aide le coordinateur.
S’identifier : se connecter au système grâce aux identifiants donnés.
Tâche : travail donné au personnel (travailleur).
Fiche de révisions
Pour pouvoir réviser toutes les connaissances acquises à chaque TD, vous retrouverez un lien vers une fiche de révisions qui vous permettra de bien vous préparer au contrôle final.
Comme promis voici le lien de la fiche de révision pour les use cases :)