User Tools

Site Tools


2014_2015:s2:td:td_use_cases

Diagrammes de cas d'utilisation (Une séance)

Description Initiale : La galerie d'art

Nous prenons l'exemple d'une “galerie d'art virtuelle”.

Nous identifions à présent les principaux cas d'utilisation. Pour des raisons de simplification, nous partons de l'énoncé suivant qui est une extraction d'un cahier des charges.

(1) Nous voulons informatiser une galerie d'art, par laquelle nous souhaitons vendre des oeuvres d'arts à des clients1). Les paiements doivent être sécurisés en utilisant le système de paiement externe “chaimoinscheir”.
(2) Les oeuvres2) et les artistes3) sont gérés par les administrateurs4) via des interfaces adaptées.
(3) Un internaute doit pouvoir s'inscrire sur le site pour devenir client.
(4) Un internaute peut naviguer sur le site : retrouver un artiste par son nom, visualiser les oeuvres par artiste ou par catégorie5)).
(5) Les clients peuvent voter pour les oeuvres ou les artistes qu'ils préfèrent.
(6) Une fois par jour, un super-administrateur déclenche une opération de sauvegarde de la galerie.
(7) L'identification des clients fait partie du système de la galerie.
(8) Un client peut téléphoner à la secrétaire pour demander l'édition d'une facture consécutive à une vente passée.

Pour Visual Paradigm

Toutes les informations sont ici : Visual Paradigm

I. Diagramme de contexte statique

L'énoncé qui précède décrit votre étude de cas. Vous considérerez cette description comme exhaustive.

  1. En analysant chacune des phrases de l'énoncé identifiez les acteurs, et dessiner le diagramme de contexte statique (l'outil ne supporte pas directement le diagramme de contexte : mettre un cas d'utilisation dans le système pour pouvoir tracer les liens entre les acteurs et le “système”)
  2. Identifiez à tout moment, le nombre d'acteurs d'un rôle donné qui utilise le système

II. Identification des cas d'utilisation

  1. En analysant chacune des phrases de l'énoncé, déterminez les grands cas d'utilisation de la galerie d'art et les dessiner.

III. Description textuelle

Pour ajouter la description textuelle dans les cas d'utilisation, clique droit sur la cas d'utilisation → spécification → puis remplir la partie HTML ou voir ici comment faire

1) Décrivez le scénario nominal (flot nominal ou basique aussi appelé) correspondant au cas d'utilisation “Un internaute s'inscrit pour devenir client de la galerie d'art”

2) Décrivez les flots alternatifs correspondant au cas d'utilisation “Un internaute s'inscrit pour devenir client de la galerie d'art” lorsque les données saisies sont invalides ou que l'internaute est déjà inscrit.

3) Décrivez le cas d'utilisation “acheter des oeuvres” en respectant le format suivant :

  • Sommaire d'identification :
    • Titre
    • Résumé
    • Acteurs
    • Date de création
    • Date de mise à jour
    • Version
    • Responsable
  • Description des scénarios:
    • Préconditions
    • Flot Nominal (Flot/scenario de base qui correspond au cas où tout fonctionne bien)
    • Flots alternatifs (Vous vous limiterez à un cas).
    • Flots d'erreur (Vous vous limiterez à un cas).
    • Postconditions
    • Exigences non fonctionnelles

3') Préciser les informations sur les acteurs :

http://www.visual-paradigm.com/VPGallery/diagrams/UseCase.html#actor

4) NEW : Vous pouvez générer à partir des flots exprimés dans l'outil un diagramme de séquence, voir déroulement ici :

5) Associer à chaque étape du scénario “nominal”, les données correspondantes. Elles vous serviront (i) à identifier les types de données manipulées et (ii)à la fin du projet à “valider” cas d'utilisation. Voir ici comment le faire dans l'outil.

IV. Relations entre cas d'utilisation

Vous prendrez en compte les spécifications suivantes, si vous ne l'avez pas déjà fait :

  1. Pour acheter ou voter, un client doit s'être authentifié;
  2. Un internaute qui désire voter est invité à s'inscrire sur le site;
  3. La visualisation des oeuvres peut consister en une navigation “classique” dans les oeuvres, une navigation dans un espace virtuel en 3D où les oeuvres sont présentées par thèmes, un catalogue “virtuel”, ou des options de recherche avancées.
  4. Un super administrateur est un administrateur.
  5. Avant de valider sa commande un client peut consulter la popularité des oeuvres dans son panier.
Pour compléter un cas d'utilisation vous pouvez créer un autre diagramme par exemple pour la visualisation : clique droit sur le cas d'utilisation visualiser, puis sous-diagramme, puis cas d'utilisation. Vous pouvez alors prendre le cas d'utilisation dans la barre de gauche et le déposer dans votre nouveau diagramme et l'enrichir.

V. Organisations des cas d'utilisation

  1. Décomposer vos cas d'utilisation en vous basant sur un découpage dirigé par les acteurs principaux.<note tip>Vous pouvez utiliser les packages (voir comment) pour regrouper vos cas d'utilisation.</note>
  2. Choisissez les cas d'utilisation que vous considérez comme prioritaires : pour leur importance, pour le risque associé, … comment? en saisissant le "niveau".

TD noté

A rendre : —– A la fin de votre dernière séance de TD sur le sujet : remis à votre encadreur par mail ayant pour sujet “[S2] UC : Numero Groupe : Membres du binôme” avec en attachement votre projet : 10% de moins par heure de retard

  1. Une gestion de crise est généralement déclenchée par un témoin de la scène qui s'adresse à un coordinateur.
  2. Un coordinateur initie le processus de gestion de crise en enregistrant la déclaration du témoin. Lors de la saisie de la déclaration, le numéro de téléphone du témoin est vérifiée automatiquement auprès d’un service externe de téléphonie; En l'absence de numéro de téléphone, le numéro de sécurité sociale est vérifié automatiquement auprès de la SS qui expose un service dédié. Il est possible qu'un assistant se charge de vérifier l'identité d'un témoin en appelant la police au téléphone. Dans le cas, où l'identité n'a pas pu être vérifiée, les informations sont enregistrées mais le scénario est stoppé.
  3. Un manager assigne un expert à la crise.
  4. L'expert a la charge de contrôler la situation d'urgence. Il a la charge d'identifier les missions nécessaires pour faire face à la situation.
  5. Le coordinateur a alors la charge de traiter les missions en allouant des ressources (personnes, camions, etc.) appropriées à chaque tâche.
  6. Les travailleurs sont tenus de signaler auprès du système l’évolution de leur mission (arrivée sur place, camion installé, ..). Chaque signalement peut être suivi du signalement du succès ou de l'échec dans l'exécution de la mission.
  7. Seules les personnes identifiées ont accès au système. Elles peuvent s'authentifier par mot de passe ou par biométrie.

Définissez les cas d'utilisation correspondant à cette description:

  1. Diagramme de contexte;
  2. Vocabulaire nécessaire aux cas d'utilisation (Explicitez les synonymes éventuels utilisés dans le texte, mais vous n'utiliserez, vous, plus qu'un seul terme dans ces cas)
  3. Diagramme de cas d'utilisation
  4. Description détaillée du cas d'utilisation correspondant à la phrase 2.
  5. Expression de quelques données qui pourraient servir de jeux de tests.
  6. Organisez vos cas d'utilisation dans des packages.
Vous attachez à votre mail un document correspondant à votre projet. Il doit être bien formé : numéro de page, titre, auteurs, ….
Attention ne confondez pas! Les acteurs qui importent sont ceux qui interagissent avec le système. Ne vous trompez pas! Dans les cas d'utilisation vous ne pouvez utiliser que les relations extends, include et specialisation entre les cas d'utilisations.

Je sais répondre à

Je sais répondre à :

  • Quels sont les grands cas d'utilisation d'une application ? Attention, je ne m'intéresse qu'aux parties que j'aurais à développer.
  • Quels sont les acteurs d'un cas d'utilisation ? Quelles sont les limites de mon système? Les systèmes externes auxquels j'aurais besoin de me connecter sont des acteurs externes. Seuls les acteurs directement impliqués dans les cas d'utilisation sont pris en compte, les discussions extérieures à notre système ne sont pas modélisées.
  • Les tests de validation commencent à être préparés dès la détermination des cas d'utilisation. Ils permettent de mettre en relief, les bases des scénarios de tests, les limites, les données manipulées dans le système.
  • Les seules relations acceptées entre les cas d'utilisation sont : 'generalization“, “extend”, “include”
  • Je sais distinguer les différentes relations entre cas d'utilisation.

En savoir plus sur les diagrammes de cas d'utilisation

1)
Clients : Internautes identifiés par la galerie et sur lesquels nous disposons du nom, de l'adresse mail et de l'adresse postale.
2)
oeuvre: produit unique identifié exposé par la galerie.
3)
artiste: personne identifiée, auteur d'oeuvres.
4)
administrateurs : Personne identifiée ayant les droits de modification et maintenance du site
5)
rubriques exposées par la galerie, correspondant en général à une techniques caractérisant un artiste (peinture, sculpture…
2014_2015/s2/td/td_use_cases.txt · Last modified: 2015/03/03 16:20 by blay