SlideShare une entreprise Scribd logo
1  sur  118
Analyse et Conception avec UML

  Les diagrammes
 de cas d’utilisation
          blay@unice.fr
     www.polytech.unice.fr/~blay
     IUT Nice-Sophia Antipolis
            Mars 2011

            Site web du module :
     http://anubis.polytech.unice.fr/iut/
                        1
Bibliographie

Principalement :
     • cours IBM : Writing Good Use Cases (2006)
•Voir sur le site web les autres cours.
•Méthodologie en Ingénierie du logiciel, Modélisation Orientée
objet, M.Grimaldi – janvier 2010




                               2
Dict.   U.C.        Process.        Compléments.


                    Plan du cours
   Utilisation d’un dictionnaire du domaine

   Des cas d’utilisations (Use-cases/UC)
      Acteurs, use-cases, system UML


   Processus de construction des Uses-case

   Compléments
                          3 /98
Dict.   U.C.                 Process.                 Compléments.

    UML au travail : Système                       d’inscriptions
    L’université ESU désire automatiser son système d’inscription
‣    Le chef du service des inscriptions établit le programme des cours pour un
     semestre
‣    Un cours peut être offert plusieurs fois
‣    Les étudiants doivent sélectionner 4 cours primaires et 2 cours secondaires
     dans le catalogue des cours proposés
‣    Dès qu’un étudiant s’est inscrit pour un semestre, le système de facturation
     est notifié
‣    Les étudiants peuvent utiliser le système pour modifier leurs choix pendant
     une certaine période de temps après leur inscription
‣    Les enseignants utilisent le système pour consulter leur emploi du temps
     (tableau d’activités en fonction des cours qui tournent)
‣    Les utilisateurs du système d’inscription reçoivent des mots de passe qui
     sont nécessaire à la procédure d’identification
                                          4 /98
Dict.   U.C.             Process.              Compléments.

UML au travail : Guichet      automatique de banque
Le guichet automatique d’une banque (GAB) offre les
services suivants :
    Distribution d’argent à partir d’une carte de la banque
    ou d’une carte Visa.
    Consultation de solde de compte, dépôt en numéraire et
    dépôt de chèques pour les clients de la banque porteurs
    d’une carte de la banque.
De plus,
    Toutes les transactions sont sécurisées.
    Il est parfois nécessaire de recharger le distributeur, .

                               5 /82   Voir UML2 par la pratique
Dict.   U.C.                Process.               Compléments.


     UML au travail : Une                     galerie d’art
(1) Nous voulons informatiser une galerie d'art, par laquelle nous
souhaitons vendre des oeuvres d'arts à des clients. Les paiements
doivent être sécurisés en utilisant le système de paiement externe
“chaimoinscheir”.
(2) Les oeuvres et les artistes sont gérés par les administrateurs 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 catégorie.
(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.
                                    6 /82
Dict.    U.C.          Process.           Compléments.


          Intérêt du dictionnaire
 Outil de dialogue
 Informel, évolutif, simple a réaliser

 Etablir et figer la terminologie
      –   Permet de figer la terminologie du domaine
          d'application.
      –   Constitue le point d'entrée et le référentiel
          initial de l'application ou du système.
 Homonymie
    Synonymie
    Polysémie                  7 /98
Dict.   U.C.               Process.                 Compléments.

    UML au travail : Système                       d’inscriptions
    L’université ESU désire automatiser son système d’inscription
‣    Le chef du service des inscriptions établit le programme des cours pour
     un semestre
         ‣   Un cours peut être offert plusieurs fois
‣    Les étudiants doivent sélectionner 4 cours primaires et 2 cours
     secondaires dans le catalogue des cours proposés
‣    Dès qu’un étudiant s’est inscrit pour un semestre, le système de facturation
     est notifié
‣    Les étudiants peuvent utiliser le système pour modifier leurs choix pendant
     une certaine période de temps après leur inscription
‣    Les enseignants utilisent le système pour consulter leur emploi du temps
     (tableau d’activités en fonction des cours qui tournent)
‣    Les utilisateurs du système d’inscription reçoivent des mots de passe qui
     sont nécessaire à la procédure d’identification
                                          8 /98
Dict.   U.C.             Process.             Compléments.


Les diagrammes de cas d ’utilisation
   Une des notations d ’UML (use-cases)
   But :
    ‣ définir le système du point de vue des utilisateurs

    ‣ définir les limites précises du système

   Notation très simple, compréhensible par tous
   Permet de structurer :
   ‣   les besoins (cahier des charges)
   ‣   le reste du développement
   ‣  la progression d ’un cycle en spirale
   Les cas d'utilisation sont nommés en utilisant la
   terminologie décrite dans le dictionnaire       Jean-Marie Favre
                              9 /98
Dict.      U.C.                          Process.                         Compléments.


Les diagrammes de cas d ’utilisation
    Une Notation très simple, compréhensible par tous




   cf. http://linformalibre.f2lt.fr/index.php?title=Comprendre_Joomla_%C3%A0_l%27aide_d%27UML

                                              10 /98
Dict.     U.C.   ✓Conclusion   Process.          Compléments.



    Bénéfices des use-cases
Organisent les exigences d’un point de vue utilisateur
Définissent les exigences du système comme des
séquences logiques,
Permettent de vérifier que toutes les exigences sont
capturées et qu’elles correspondent à ce qu’attend le
demandeur.
Facilitent l’adéquation des demandeurs
‣           mais aussi des cas de tests, la documentation et la
            réutilisation des exigences.

                                   11 /98
Dict.   U.C.   ✓Conclusion   Process.   Compléments.



Des use-cases, pour qui?
Demandeurs (décrire et approuver)
Utilisateurs (comprendre)
Architectes logiciels (identification
des fonctions)
Concepteurs et développeurs
Testeurs (identifier les tests)
Managers (Planifier)
Rédacteurs de documentation
(prendre un point de vue utilisateur)
                              12 /98
Dict.   U.C.   ✓Conclusion   Process.   Compléments.


Dev. logiciel dirigé par les use-cases




                                13 /98
Dict.   U.C.               Process.                      Compléments.


Processus d’écriture des UC
Trouver les acteurs                      Etudiant     Catalogue
                                                      des cours
                                  Enregistrer des cours
                      Brève description: Ce UC permet à un étudiant
Trouver les UC        d’enregistrer ses cours... Seuls les formations bien
                      construites sont acceptés. Le catalogue des cours est
                      notifié des inscriptions.


                      Description de «Enregistrer des cours»
Décrire les UC        -Flot d’évènements
                           -Pas à pas


                      Specification de «Enregistrer des cours»
Détailler les UC      - Flot d’évènements détaillés
                      - Exigences spéciales
                      - Pre/Postconditions
                               14 /98
Dict.   U.C.          Process.     Compléments.


Processus d’écriture des UC
  Trouver les acteurs

                              Important
  Trouver les UC          C’est un processus
                                 itératif
    Décrire les UC


   Détailler les UC
                        15 /98
Dict.   U.C.          Process.   ✓1. acteurs   Compléments.


Processus d’écriture des UC
  Trouver les acteurs                       Nommer et
                                             brièvement
                                             décrire les
  Trouver les UC                             acteurs
                                             trouvés


    Décrire les UC


   Détailler les UC
                        16 /98
Dict.     U.C.   ✓acteurs   Process.   Compléments.


Définir le périmètre du SI : Acteurs
   Définir les acteurs externes
    ‣           physiques et logiques
    ‣           rôle et entité concrète
« Un acteur est une personne ou une chose qui
  va interagir avec le système »




                                    17 /98
Dict.     U.C.   ✓acteurs   Process.     Compléments.


Définir le périmètre du SI : Acteurs
   Définir les acteurs externes
    ‣           physiques et logiques
    ‣           rôle et entité concrète
« Un acteur est une personne ou une chose qui
  va interagir avec le système »



                                      Etudiant




                                    17 /98
Dict.     U.C.   ✓acteurs   Process.     Compléments.


Définir le périmètre du SI : Acteurs
   Définir les acteurs externes
     ‣           physiques et logiques
     ‣           rôle et entité concrète
« Un acteur est une personne ou une chose qui
  va interagir avec le système »



                                       Etudiant
    Chef du
  Service des
  inscriptions
                                     17 /98
Dict.     U.C.   ✓acteurs     Process.               Compléments.


Définir le périmètre du SI : Acteurs
   Définir les acteurs externes
     ‣           physiques et logiques
     ‣           rôle et entité concrète
« Un acteur est une personne ou une chose qui
  va interagir avec le système »


                                                      Système
                          Enseignant     Etudiant   de facturation
    Chef du
  Service des
  inscriptions
                                       17 /98
Dict.     U.C.   ✓acteurs   Process.                Compléments.



Client
                                Acteurs
         Un Acteur =
         ‣        élément externe qui interagit avec le système
         ‣        rôle qu’un utilisateur joue par rapport au système
              ex: un enseignant, un guichetier
         Une même personne peut jouer plusieurs rôles
              ex: Marie est enseignante et étudiante
                  Maurice est directeur mais peut faire le guichetier
         Plusieurs personnes peuvent jouer un même rôle
              ex: Paul et Pierre sont deux clients
         Un acteur n’est pas forcément un être humain
              ex: un distributeur de billet peut être vu comme un acteur; un
                gestionnaire de mot de passes
                                       18 /98
Dict.      U.C.   ✓acteurs        Process.                   Compléments.


               Description des acteurs
      Client


           Pour chaque acteur :
               ‣   choisir un identificateur représentatif de son rôle
                   (un bon nom décrit la responsabilité des acteurs)
               ‣   donner une brève description textuelle
                              Un guichetier est un employé de la banque chargé
                              de faire l’interface entre le système informatique et
                             les clients qu’il reçoit au comptoir. Le guichetier peut
                               réaliser les opérations courantes : création d ’un
     Guichetier
                                       compte, dépôt et retrait d ’argent, etc.
Jean-Marie Favre                             19 /98
Dict.   U.C.          Process.   ✓1. acteurs   Compléments.



         Trouver les acteurs
Qui ou quoi utilise le système?
Qui ou quoi obtient de l'information de ce système ?
Qui ou quoi fournit des informations au système ?
Où dans la compagnie le système est-il utilisé ?
Qui ou quoi supporte et maintient le système?
Quels autres systèmes utilisent ce système?


                       20 /98
Dict.   U.C.               Process.                 Compléments.

    UML au travail : Système                       d’inscriptions
    L’université ESU désire automatiser son système d’inscription
‣    Le chef du service des inscriptions établit le programme des cours pour un
     semestre
         ‣   Un cours peut être offert plusieurs fois
‣    Les étudiants doivent sélectionner 4 cours primaires et 2 cours secondaires
     dans le catalogue des cours proposés
‣    Dès qu’un étudiant s’est inscrit pour un semestre, le système de facturation
     est notifié
‣    Les étudiants peuvent utiliser le système pour modifier leurs choix pendant
     une certaine période de temps après leur inscription
‣    Les enseignants utilisent le système pour consulter leur emploi du temps
     (tableau d’activités en fonction des cours qui tournent)
‣    Les utilisateurs du système d’inscription reçoivent des mots de passe qui
     sont nécessaire à la procédure d’identification
                                         21 /98
Dict.   U.C.               Process.               Compléments.

    UML au travail : Système                       d’inscriptions
    L’université ESU désire automatiser son système d’inscription
‣    Le chef du service des inscriptions établit le programme des cours pour
     un semestre
         ‣   Un cours peut être offert plusieurs fois
‣ Les étudiants doivent sélectionner 4 cours primaires et 2 cours secondaires
dans le catalogue des cours proposés
Dès qu’un étudiant s’est inscrit pour un semestre, le système de facturation
est notifié
‣ Les étudiants peuvent utiliser le système pour modifier leurs choix pendant
   une certaine période de temps après leur inscription
‣Les enseignants utilisent le système pour consulter leur emploi du temps
(tableau d’activités en fonction des cours qui tournent)
‣ Les utilisateurs du système d’inscription reçoivent des mots de passe qui
   sont nécessaire à la procédure d’identification
                                        22 /98
Dict.   U.C.                 Process.    ✓1. acteurs      Compléments.



 Décrire les acteurs
Student :
    A person who signs
      up for a course                                         Student


- Qu'est-ce ou que l'acteur représente
- Pourquoi l'acteur est nécessaire
- Quel est l’intérêt de l’acteur dans le UC ?
                                                   Professor        Registrar




                                     23 /98
Dict.   U.C.                 Process.    ✓1. acteurs      Compléments.



 Décrire les acteurs
Student :
    A person who signs
      up for a course                                         Student


- Qu'est-ce ou que l'acteur représente
- Pourquoi l'acteur est nécessaire
- Quel est l’intérêt de l’acteur dans le UC ?
                                                   Professor        Registrar



                                                          Course Catalog
                                                             System

                                     23 /98
Dict.   U.C.             Process.              Compléments.

UML au travail : Guichet      automatique de banque
Le guichet automatique d’une banque (GAB) offre les
services suivants :
    Distribution d’argent à partir d’une carte de la banque
    ou d’une carte Visa.
    Consultation de solde de compte, dépôt en numéraire et
    dépôt de chèques pour les clients de la banque porteurs
    d’une carte de la banque.
De plus,
    Toutes les transactions sont sécurisées.
    Il est parfois nécessaire de recharger le distributeur, .

                              24 /98   Voir UML2 par la pratique
Identification des acteurs
Quelles sont les entités externes qui interagissent avec le GAB ?
                                     •     Porteur de carte
Phrase 1                             •     Carte de crédit
                                     •     Lecteur de carte
                                     •     Distributeur de billets



Phrase 2                         •       Porteur de carte
                                         client de la banque


Phrase 3                          Le système est sécurisé (par
                                       quoi?)
                                        1. Le système
                                             d’autorisation
                                        2. Le système
                                             d’information de
                                             la banque
Phrase 4                             •      Opérateur de
                                            maintenance
Dict.   U.C.                Process.   ✓1. acteurs   Compléments.

     UML au travail : Une                     galerie d’art
(1) Nous voulons informatiser une galerie d'art, par laquelle nous
souhaitons vendre des oeuvres d'arts à des clients. Les paiements
doivent être sécurisés en utilisant le système de paiement externe
“chaimoinscheir”.
(2) Les oeuvres et les artistes sont gérés par les administrateurs 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 catégorie.
(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.

                                   26 /82
Dict.   U.C.   Process.   ✓1. acteurs   Compléments.



Diagramme de contexte




               27 /98
Le GAB est un système fondamentalement
mono-utilisateur: à tout instant, il n’y a qu’une
instance de chaque acteur (au maximum)
connecté au système!




Pour simplifier, nous utiliserons le terme Client banque pour
l’acteur Porteur de carte client de la banque.
Diagramme de contexte statique
Les acteurs humains Client banque et Porteur de carte sont
mutuellement exclusifs, ce qui n’est pas implicite d’après les
multiplicités des associations. On peut ajouter une contrainte
{XOR} (ou exclusif)
Une autre solution, un peu plus élaborée, consiste à
considérer que Client banque est une spécialisation de
Porteur de carte (héritage entre acteurs)
Dict.   U.C.                Process.   ✓1. acteurs   Compléments.

     UML au travail : Une                     galerie d’art
(1) Nous voulons informatiser une galerie d'art, par laquelle nous
souhaitons vendre des oeuvres d'arts à des clients. Les paiements
doivent être sécurisés en utilisant le système de paiement externe
“chaimoinscheir”.
(2) Les oeuvres et les artistes sont gérés par les administrateurs 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 catégorie.
(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.

                                   32 /82
Dict.   U.C.          Process.   ✓2. U.C.   Compléments.


Processus d’écriture des UC
  Trouver les acteurs              Nommer et
                                    brièvement décrire
                                    les UC trouvés
  Trouver les UC                   Créer un
                                    diagramme de UC
                                   Etablir la plus-
                                    value métier et les
    Décrire les UC                  risques techniques
                                    des UC

   Détailler les UC
                        33 /98
Dict.   U.C. ✓cas d’utilisat.   Process.   Compléments.


 Cas d’utilisation (UC)




                                34 /98
Dict.   U.C. ✓cas d’utilisat.   Process.     Compléments.


     Cas d’utilisation (UC)
Un cas d’utilisation est un motif cohérent de comportement
‣     réalisé par le système.




                                    34 /98
Dict.   U.C. ✓cas d’utilisat.   Process.           Compléments.


        Cas d’utilisation (UC)
  Un cas d’utilisation est un motif cohérent de comportement
   ‣     réalisé par le système.
Chaque cas d’utilisation est décrit par une séquence d’actions
connectées, effectuées par un dialogue entre des acteurs et le
système
   ‣     qui produit un résultat observable
   ‣     d’intérêt pour un ou plusieurs acteurs du système.
   ‣     ne révèle pas la structure interne du système.




                                       34 /98
Dict.   U.C. ✓cas d’utilisat.   Process.           Compléments.


        Cas d’utilisation (UC)
  Un cas d’utilisation est un motif cohérent de comportement
   ‣     réalisé par le système.
Chaque cas d’utilisation est décrit par une séquence d’actions
connectées, effectuées par un dialogue entre des acteurs et le
système
   ‣     qui produit un résultat observable
   ‣     d’intérêt pour un ou plusieurs acteurs du système.
   ‣     ne révèle pas la structure interne du système.
  Chaque cas d’utilisation est un flot complet et faisant du sens
  du point de vue d’un acteur particulier.


                                       34 /98
Dict.    U.C.              Process.   ✓2. U.C.    Compléments.


           Trouver les use-cases
Quels sont les objectifs de chaque acteur?
‣ Pourquoi l'acteur utiliserait-il le système?

‣ Est-ce que l'acteur créera, stockera, modifiera,
  supprimera ou lira des données dans le système? Si
  oui, pourquoi?
‣ Est-ce que l'acteur nécessite d'informer le système sur
  des événements externes ou des changements?
‣ Est-ce que l'acteur doit être informé de certains
  événements dans le système?
     Quels buts dois-je
  atteindre en utilisant le
         système?                           Acteur
                              35 /98
Dict.   U.C.               Process.               Compléments.

    UML au travail : Système                       d’inscriptions
    L’université ESU désire automatiser son système d’inscription
‣    Le chef du service des inscriptions établit le programme des cours pour
     un semestre
         ‣   Un cours peut être offert plusieurs fois
‣ Les étudiants doivent sélectionner 4 cours primaires et 2 cours secondaires
dans le catalogue des cours proposés
Dès qu’un étudiant s’est inscrit pour un semestre, le système de facturation
est notifié
‣ Les étudiants peuvent utiliser le système pour modifier leurs choix pendant
   une certaine période de temps après leur inscription
‣Les enseignants utilisent le système pour consulter leur emploi du temps
(tableau d’activités en fonction des cours qui tournent)
‣ Les utilisateurs du système d’inscription reçoivent des mots de passe qui
   sont nécessaire à la procédure d’identification
                                        36 /98
Dict.   U.C. ✓cas d’utilisat.   Process.         Compléments.

    UML au travail : Système                            d’inscriptions
    L’université ESU désire automatiser son système d’inscription
‣    Le chef du service des inscriptions établit le programme des cours pour
     un semestre
         ‣   Un cours peut être offert plusieurs fois
 Les étudiants doivent sélectionner 4 cours primaires et 2 cours secondaires
dans le catalogue des cours proposés
Dès qu’un étudiant s’est inscrit pour un semestre, le système de facturation
est notifié
Les étudiants peuvent utiliser le système pour modifier leurs choix pendant
une certaine période de temps après leur inscription
Les enseignants utilisent le système pour consulter leur emploi du temps
(tableau d’activités en fonction des cours qui tournent)
‣ Les utilisateurs du système d’inscription reçoivent des mots de passe qui
  sont nécessaire à la procédure d’identification
                                             37 /98
Dict.   U.C. ✓cas d’utilisat.   Process.                      Compléments.


   Nommer un use-case




                                            Enregistrer des Cours



                                ?
                                            Enregistrement de cours
                                            Cours
                                            Utiliser le système d’enregistrement
                                            Accuser réception des cours
                                38 /98
Dict.   U.C. ✓cas d’utilisat.   Process.                      Compléments.


    Nommer un use-case
Le nom doit être unique, intuitif et auto-explicatif




                                             Enregistrer des Cours



                                 ?
                                             Enregistrement de cours
                                             Cours
                                             Utiliser le système d’enregistrement
                                             Accuser réception des cours
                                 38 /98
Dict.   U.C. ✓cas d’utilisat.   Process.                      Compléments.


    Nommer un use-case
Le nom doit être unique, intuitif et auto-explicatif
Il doit commencer par un verbe et utiliser une simple
combinaison verbe-nom




                                             Enregistrer des Cours



                                 ?
                                             Enregistrement de cours
                                             Cours
                                             Utiliser le système d’enregistrement
                                             Accuser réception des cours
                                 38 /98
Dict.   U.C. ✓cas d’utilisat.   Process.                      Compléments.


    Nommer un use-case
Le nom doit être unique, intuitif et auto-explicatif
Il doit commencer par un verbe et utiliser une simple
combinaison verbe-nom
Définir clairement et sans ambiguïté le gain des résultats
observables




                                             Enregistrer des Cours



                                 ?
                                             Enregistrement de cours
                                             Cours
                                             Utiliser le système d’enregistrement
                                             Accuser réception des cours
                                 38 /98
Dict.   U.C. ✓cas d’utilisat.   Process.                      Compléments.


    Nommer un use-case
Le nom doit être unique, intuitif et auto-explicatif
Il doit commencer par un verbe et utiliser une simple
combinaison verbe-nom
Définir clairement et sans ambiguïté le gain des résultats
observables
Placez vous du point de vue de l'acteur qui déclenche le
cas d'utilisation


                                             Enregistrer des Cours



                                 ?
                                             Enregistrement de cours
                                             Cours
                                             Utiliser le système d’enregistrement
                                             Accuser réception des cours
                                 38 /98
Dict.   U.C. ✓cas d’utilisat.   Process.                      Compléments.


    Nommer un use-case
Le nom doit être unique, intuitif et auto-explicatif
Il doit commencer par un verbe et utiliser une simple
combinaison verbe-nom
Définir clairement et sans ambiguïté le gain des résultats
observables
Placez vous du point de vue de l'acteur qui déclenche le
cas d'utilisation
Décrire le comportement fournit par le cas d'utilisation
                                             Enregistrer des Cours



                                 ?
                                             Enregistrement de cours
                                             Cours
                                             Utiliser le système d’enregistrement
                                             Accuser réception des cours
                                 38 /98
Dict.     U.C. ✓cas d’utilisat.     Process.             Compléments.


            Diagramme des UC
  Objectif : visualiser les relations entre acteurs et cas
  d’utilisation (communication)



            Enregistrer ses cours            Consulter
                                        tableau de service
Etudiant                                                      Enseignant

                  S’inscrire


Système de                                                Etablir le
facturation                                          Programme Scolaire
                                  Chef du Service
                                  Des Inscriptions
                                         39 /98
Dict.    U.C. ✓cas d’utilisat.       Process.                     Compléments.


       Communication : un dialogue
L’étudiant se connecte au système
Le système approuve la connexion.
L’étudiant requiert des informations


                                                             Enregistrer
                                          Etudiant           ses cours            Catalogue
                                                                                  des cours




   Le système affiche la liste des cours                 Le système transmet la requête
     L’étudiant selectionne les cours                    Le Catalogue des cours retourne
                                                          des informations sur les cours.
    Le système affiche l’edt approuvé

                                               40 /98
Dict.   U.C. ✓cas d’utilisat.   Process.   Compléments.

     Diagramme des cas d’utilisation
Porteur de carte:
     Retirer de l’argent
Client banque:
     Retirer de l’argent (bien sûr!)
                                                      Acteurs
     Consulter le solde de son compte courant        primaires
     Déposer du numéraire
     Déposer de l’argent (numéraire ou chèque)
Opérateur de maintenance
     Recharger le distributeur
     Maintenir l’état opérationnel
Système d’autorisation (Sys.Auto)
                                                     Acteurs
     Néant                                         secondaires
Système d’information de la banque (SI banque)
     Néant
                                        /82
Dict.   U.C. ✓cas d’utilisat.   Process.   Compléments.


Diagramme des cas d’utilisation




                                  /82
Dict.   U.C. ✓cas d’utilisat.   Process.   Compléments.


Diagramme des cas d’utilisation
       amélioration




                                   /82
Dict.   U.C. ✓cas d’utilisat.   Process.           Compléments.

     UML au travail : Une                         galerie d’art
(1) Nous voulons informatiser une galerie d'art, par laquelle nous
souhaitons vendre des oeuvres d'arts à des clients. Les paiements
doivent être sécurisés en utilisant le système de paiement externe
“chaimoinscheir”.
(2) Les oeuvres et les artistes sont gérés par les administrateurs 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 catégorie.
(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.

                                       44 /82
Dict.   U.C.   ✓Système   Process.     Compléments.



                  Le système
Le système est un ensemble de cas d’utilisation
Le système contient :
 ‣   les cas d ’utilisation,
 ‣   mais pas les acteurs.
Un modèle de cas d ’utilisation permet de définir :
 ‣   les fonctions essentielles du système,
 ‣   les limites du système,
 ‣   le système par rapport à son environnement.

                           45 /98
Dict.      U.C.   ✓Système           Process.            Compléments.


                            System
                                                   Frontière du système
                             Etablir
                            un emploi
                            du temps

Etudiant                             Enregistrer
                                     ses cours
                                                       Catalogue
                     S’inscrire
                                                       des cours


                        Demander
                                                                   Système de
                            un
                        tableau de                                 facturation
                          service

Système de                                         Enseignant
facturation           Maintenir le
                      Programme
                                                      Chef du Service
                                        46 /98        Des Inscriptions
Dict.   U.C.   ✓Desc.   Process.   Compléments.



Description succincte d’un UC
 Sommaire d'identification :
 ■ Titre
 ■ Résumé
 ■ Acteurs
 ■ Date de création
 ■ Date de mise à jour
 ■ Version
 ■ Responsable
                          47 /98
Dict.     U.C.   ✓Desc.         Process.                  Compléments.


     Description textuelle du cas d'utilisation:
               « RETIRER DE L’ARGENT »   
Sommaire d'identification
Titre : Retirer de l'argent
Résumé : ce cas d'utilisation permet à un porteur de carte, qui n'est pas
client de la banque, de retirer de l'argent, si son crédit hebdomadaire le
permet.
Acteurs : Porteur de carte non client (principal), Sys. Auto. (secondaire).
Date de création : 03/01/07      Date de mise à jour : 09/02/07
Version : 1.0            Responsable : Pierre DUMONT




                                         /82
Dict.   U.C.    Process.   ✓2. U.C.   Compléments.



         Bilan sur les UC




                49 /98
Dict.   U.C.         Process.   ✓2. U.C.   Compléments.



Faire le point sur les acteurs
 Est-ce chacun des acteurs est impliqué dans au
 moins un cas d'utilisation?
  Est-ce que des acteurs jouent des rôles similaires
 du point de vue du système? Dans l'affirmative, les
 fusionner en un seul acteur.
 «Avez-vous trouvé tous les acteurs?»
 «Avez-vous pris en compte et modélisé tous les
 rôles dans l'environnement du système?»
                        50 /98
Dict.   U.C.             Process.   ✓2. U.C.   Compléments.


Faire le point sur les Use-cases(1)
  Le modèle de cas d'utilisation présente le
  comportement du système, il est facile de comprendre
  ce que le système fait en passant en revue le modèle.
  Tous les cas d'utilisation ont été identifiés; les cas
  d'utilisation représentent l’ensemble des
  comportements requis.
  Le modèle de cas d'utilisation ne contient pas de
  comportement superflu; A chaque cas d'utilisation
  correspond une exigence fonctionnelle.

                             51 /98
Dict.   U.C.           Process.   ✓2. U.C.   Compléments.


Faire le point sur les Use-cases(2)
  Le cas d'utilisation ont des noms uniques, intuitifs, et
  des noms explicites de sorte qu'ils ne peuvent pas être
  confondus à un stade ultérieur. Sinon, changer leurs
  noms.
  Les demandeurs et les utilisateurs comprennent les
  noms et les descriptions des cas d'utilisation.
  La brève description donne une image fidèle du cas
  d'utilisation.
  Chaque cas d'utilisation implique au moins un acteur.
  Les cas d'utilisation n’ont pas de comportements ou
  des flux d'événements très similaires.
                            52 /98
Dict.    U.C.             Process.   ✓2. U.C.    Compléments.


Évaluer la valeur commerciale et les risques
  Pour chaque cas d'utilisation identifié, obtenir
  un consensus avec les parties prenantes quant à
  sa valeur commerciale et les risques techniques
   ‣       L’équipe métier décide ce qui a de l’importance
           et ce qui n’en a pas.
   ‣       L'équipe technique décide de ce qui est risqué
       -     Degré de complexité de dev. pressentie,
             intégration, indéterminisme.
  Utilisez : haute, moyen, faible
                                        En déduire les use cases
                                         à détailler en premier
                              53 /98
Dict.   U.C.          Process.   ✓3.décrire.   Compléments.


Processus d’écriture des UC
  Trouver les acteurs              Décrire les flots
                                    d’évènements
                                    (bref)
  Trouver les UC                   Saisir les scenarii
                                   Collecter les
                                    exigences
                                    additionnelles
    Décrire les UC


   Détailler les UC
                        54 /98
Dict.   U.C.               Process.   ✓3.décrire.   Compléments.


           Décrire une UC
Décrire chaque étape du UC par des phrases
courtes, organisées séquentiellement.
                Use Case Name
                Brief Description
                Basic Flow
                   1. First step
                   2. Second step
                   3. Third step
                Alternative Flows
                   1. Alternative flow 1
                   2. Alternative flow 2
                   3. Alternative flow 3
                            55 /98
Dict.    U.C.               Process.   ✓3.décrire.   Compléments.


                Décrire une UC
    Décrire chaque étape du UC par des phrases
    courtes, organisées séquentiellement.
                     Use Case Name
                     Brief Description                    Structurer
                     Basic Flow                           le flot de
Numéroter                                                 base en
                        1. First step
et nommer               2. Second step                    étapes
les étapes.             3. Third step                     majeures
                     Alternative Flows
                        1. Alternative flow 1             Identifier
                        2. Alternative flow 2             les flots
                        3. Alternative flow 3             alternatifs.
                                 55 /98
Dict.   U.C.                Process.   ✓3.décrire.   Compléments.


Pas à pas : enregistrer ses cours
 Basic Flow
 ‣ 1.
 L’étudiant se connecte.

 ‣ 2.
 L’étudiant choisit d’enregistrer ces choix de cours.

 ‣ 3.
 L’étudiant obtient des informations sur les cours.

 ‣ 4.
 L’étudiant sélectionne les cours.

 ‣ 5.
 L’étudiant soumet ses choix.
                                                       D’autres
 ‣ 6.
 Le système valide les choix.                 alternatives?
 Alternative Flows
 ‣ A1. Etudiant non identifié

 ‣ A2. L’étudiant quitte l’application avant soumission

 ‣ A3. Les choix ne sont pas valides

 ‣ A4. Le catalogue des Cours est non accessible.
                                56 /98
Dict.   U.C.         Process.   ✓3.décrire.   Compléments.



            Décrire les UC
Un processus itératif : ne pas tout détailler, pas
trop tôt
Un processus de découverte : Décrire vous aide
à découvrir ce que vous ne connaissez pas. Une
brève description sert de point de départ.
Un processus d’évaluation : UC trop petit ou
trop gros ? partagé?


                      57 /98
Dict.   U.C.        Process.   ✓3.décrire.   Compléments.




Exigences additionnelles

Collecter les exigences système qui ne
peuvent pas être allouées à des UC
spécifiques dans des documents
additionnels.



                     58 /98
Dict.   U.C.          Process.   ✓4.détailler   Compléments.


Processus d’écriture des UC
  Trouver les acteurs              Détailler les flots
                                    d'événements
                                   Structurer les flots
  Trouver les UC                    d'événements
                                   Spécifier les
                                    propriétés
                                    additionnelles
    Décrire les UC


   Détailler les UC
                        59 /98
Dict.   U.C.   ✓Système   Process.   ✓4.détailler   Compléments.


Description détaillée d’un UC
 ■ Description des scénarios:
   ■ Préconditions
   ■ Scénario Nominal
   ■ Flots alternatifs
   ■ Flots d'erreur
   ■ Postconditions
   ■ Exigences non fonctionnelles
 ■ Besoins d'IHM
                             60 /98
Dict.   U.C.                    Process.   ✓4.détailler     Compléments.


                       Préconditions
 Décrire l'état dans lequel doit être le système avant que le UC
  puisse commencer.
    Simples déclarations qui définissent l'état du système,
     exprimées comme ses conditions qui doivent être remplies
    Il ne faut jamais se référer à d'autres UC qui doivent être
     effectuées avant cet UC
    Devraient être énoncées clairement et devraient être
     facilement vérifiables
 Facultatif: Utilisez uniquement si nécessaire pour clarifier
 Exemple
    UC «Inscription à des cours»
    Préconditions
      La liste des offres de cours pour le semestre a été créée et est disponible au
       service d’inscription.
      L'élève a ouvert une session d’inscription dans le système
                                         61 /98
Dict.   U.C.   ✓Système   Process.   ✓4.détailler   Compléments.


Description détaillée d’un UC
 ■ Description des scénarios:
   ■ Préconditions
   ■ Scénario Nominal
   ■ Flots alternatifs
   ■ Flots d'erreur
   ■ Postconditions
   ■ Exigences non fonctionnelles
 ■ Besoins d'IHM
                             62 /98
Dict.   U.C.               Process.      ✓4.détailler   Compléments.


       Détailler le flot de base
                                            Register for Courses
                      1.1     Basic Flow
                      1.      Log On.
                         This use case starts when someone accesses the
Décrire les étapes.    Course Registration System and chooses to register for
                       courses. The system validates that the person accessing
                       the system is an authorized student.
                      2.      Select “Create a Schedule ”.
                         The system displays the functions available to the
    <Acteur>           student. The student selects “Create a Schedule ”.
                      3.      Obtain Course Information.
     <fait>              The system retrieves a list of available course offerings
                       from the Course Catalog System and displays the list to
                       the student .The student can search the list by
                       department, professor, or topic to obtain the desired
                       course information .
   <Système>          4.      Select Courses.
                         The student selects four primary course offerings and
     <fait>            two alternate course offerings from the list of available
                       offerings course offerings.
                                   63 /98
Dict.   U.C.            Process.   ✓4.détailler   Compléments.


                     Formulation
 Utilisez la voix active
    Dire: “Le Professeur attribue des notes à chaque étudiant”
    Au lieu de : “Quand le Professeur a attribué les notes”
 Dire ce qui déclenche l’étape
    Dire: “Le UC commence quand le Prof. choisit de donner
      une note.”
    Au lieu de : “Le UC commence quand le Prof. décide de ....
 Dire qui fait quoi (utiliser le nom d'acteur)
    Dire: “L'étudiant choisit ... …”
    Au lieu de: "L'utilisateur choisit ...…"
    Dire: “Le Système valide …”
    Au lieu de: "Le choix est validé …"
                              64 /98
Description textuelle du cas d'utilisation:
                 « RETIRER DE L’ARGENT »   
Description des scénarios
Pré conditions
    •La caisse du GAB est alimentée (il reste au moins un billet !).
    •Aucune carte ne se trouve déjà coincée dans le lecteur.

Scénario nominal
1. Le porteur de carte introduit sa carte dans le lecteur de cartes du GAB.
2. Le GAB vérifie que la carte introduite est bien une carte bancaire.
3. Le GAB demande au porteur de carte de saisir son code d'identification.
4. Le porteur de carte saisit son code d'identification.
5. Le GAB compare le code d'identification avec celui qui est codé sur la
     puce de la carte.
6. Le GAB demande une autorisation au système d'autorisation.
7. Le système d'autorisation donne son accord et indique le solde
     hebdomadaire.
8. Le GAB demande au porteur de carte de saisir le montant désiré du
     retrait.
9. Le porteur de carte saisit le montant désiré du retrait.
10. Le GAB contrôle le montant demandé par rapport au solde
     hebdomadaire.
11. Le GAB demande au porteur de carte s'il veut un ticket.
12. Le porteur de carte demande un ticket.
13. Le GAB rend sa carte au porteur de carte.
14. Le porteur de carte reprend sa carte.
15. Le GAB délivre les billets et un ticket.
16. Le porteur de carte prend les billets et le ticket.
17. Le GAB enregistre la transaction de retrait.
Description textuelle du cas d'utilisation:
          RETIRER DE L’ARGENT  (Représentation de C.Larman)
Une autre présentation dite de Larman consiste à séparer les
actions des acteurs et du système en deux colonnes:

       Action d’acteur                         Action Système
1. Le porteur de carte introduit sa     2. Le GAB vérifie que la carte
   carte dans le lecteur de cartes du       introduite est bien une carte
   GAB.                                     bancaire.
                                        3. Le GAB demande au porteur de
                                            carte de saisir son code
                                            d'identification.
4. Le porteur de carte saisit son 5. Le GAB compare le code
   code d'identification.            d’identification avec celui qui est
                                     codé sur la puce de la carte.
                                        6. Le GAB demande une autorisation
                                           au système d'autorisation global.
7. Le système donne son accord et 8. Le GAB de mande au porteur de
   indique le solde                  carte de saisir le montant désiré
   hebdomadaire.                     du retrait.
9. Le porteur de carte saisie le 10. Le GAB contrôle le montant
   montant désiré                   demandé par rapport au solde
                                    hebdomadaire
                                11. Le GAB demande au porteur de
                                   carte s’il veut un ticket
12. Le porteur de carte demande 13. Le GAB rend sa carte au porteur
    un ticket.                     de carte.

14. Le porteur de carte reprend sa 15. Le GAB délivre des billets et un
   carte                              ticket.

16. Le porteur de carte prend les 17. Le GAB enregistre la transaction
   billets et le ticket.             de retrait.
Dict.   U.C.   ✓Système   Process.   ✓4.détailler   Compléments.


Description détaillée d’un UC
 ■ Description des scénarios:
   ■ Préconditions
   ■ Scénario Nominal
   ■ Flots alternatifs
   ■ Flots d'erreur
   ■ Postconditions
   ■ Exigences non fonctionnelles
 ■ Besoins d'IHM
                             69 /98
Enchaînements alternatifs*
Al : code d'identification provisoirement erroné
L'enchaînement Al démarre au point 5 du scénario nominal.
6. Le GAB indique au porteur de carte que le code est erroné, pour la
   première ou deuxième fois.
7. Le GAB enregistre l'échec sur la carte.
Le scénario nominal reprend au point 3.

A2 : montant demandé supérieur au solde hebdomadaire
L'enchaînement A2 démarre au point 10 du scénario nominal.
11. Le GAB indique au porteur de carte que le montant demandé est
    supérieur au solde hebdomadaire.
Le scénario nominal reprend au point 8.

* Nous distinguons les enchaînements alternatifs (Ax) qui reprennent ensuite à
une étape du scénario nominal des enchaînements d'erreur (Ey) qui terminent
brutalement le cas d'utilisation en échec. L'objectif de l'acteur principal est donc
atteint par les scénarios nominaux et alternatifs mais pas par ceux d'erreur.
A3 : ticket refusé
L'enchaînement A3 démarre au point 11 du scénario nominal.
12. Le porteur de carte refuse le ticket.
13. Le GAB rend sa carte au porteur de carte.
14. Le porteur de carte reprend sa carte.
15. Le GAB délivre les billets.
16. Le porteur de carte prend les billets.
17. Le GAB enregistre la transaction de retrait.



            Enchaînements d’erreur
El : carte non-valide
L'enchaînement El démarre au point 2 du scénario nominal.
3. Le GAB indique au porteur que la carte n'est pas valide (illisible,
   périmée, etc.), la confisque ; le cas d'utilisation se termine en échec.
E2 : code d'identification définitivement erroné
L'enchaînement E2 démarre au point 5 du scénario nominal.
6. Le GAB indique au porteur de carte que le code est erroné, pour la
   troisième fois.
7. Le GAB confisque la carte.
8. Le système d'autorisation est informé ; le cas d'utilisation se termine
   en échec.

E3 : retrait non autorisé
L'enchaînement E3 démarre au point 6 du scénario nominal.
7. Le système d'autorisation interdit tout retrait.
8. Le GAB éjecte la carte ; le cas d'utilisation se termine en échec.

E4 : carte non reprise
L'enchaînement E4 démarre au point 13 du scénario nominal.
14. Au bout de 15 secondes, le GAB confisque la carte.
15. Le système d'autorisation est informé ; le cas d'utilisation se termine
    en échec.
E5 : billets non pris
L'enchaînement E5 démarre au point 15 du scénario nominal.
16. Au bout de 30 secondes, le GAB reprend les billets.
17. Le système d'autorisation est informé ; le cas d'utilisation se termine
   en échec.

E6 : annulation de la transaction
L'enchaînement E6 peut démarrer entre les points 4 et 12 du scénario
     nominal.
4 à 12. Le porteur de carte demande l'annulation de la transaction en
     cours.
Le GAB éjecte la carte ; le cas d'utilisation se termine en échec.

E4 : carte non reprise
L'enchaînement E4 démarre au point 13 du scénario nominal.
14. Au bout de 15 secondes, le GAB confisque la carte.
15. Le système d'autorisation est informé ; le cas d'utilisation se termine
    en échec.
Dict.   U.C.                Process.   ✓3.décrire.       Compléments.


Décrire les flots d'événements
    Flot de base
‣   Quel événement déclenche le cas d'utilisation?
‣   Comment le cas d'utilisation se termine-t-il?
‣   Comment le cas d'utilisation répète-t-il certains comportements?
    Flots d’exceptions
‣   Y-a-t-il des situations facultatives dans le cas d'utilisation?
‣   Quel cas étrange pourrait se produire?                 Etape de
‣   Quelles variantes pourraient arriver?            communication avec
    Qu’est-ce qui peut mal tourner?                     les utilisateurs
‣

‣   Qu’est-ce qui ne peut pas se produire?
‣   Quels types de ressources peuvent être bloqués?
                                                           Pas dans le détail
                                   74 /98
Dict.   U.C.   ✓Système   Process.   ✓4.détailler   Compléments.


Description détaillée d’un UC
 ■ Description des scénarios:
   ■ Préconditions
   ■ Scénario Nominal
   ■ Flots alternatifs
   ■ Flots d'erreur
   ■ Postconditions
   ■ Exigences non fonctionnelles
 ■ Besoins d'IHM
                             75 /98
Dict.    U.C.                     Process.   ✓4.détailler      Compléments.


                     Postconditions
 Décrire l'état dans lequel doit être le système à la fin du UC
    Utiliser lorsque l'état du système est une condition préalable
     à un autre UC, ou lorsque les résultats possibles du UC ne
     sont pas évidents pour le lecteur
    Il ne faut jamais se référer à d'autres UC qui doivent être
     effectués avant cet UC
    Devraient être énoncées clairement et devraient être
     facilement vérifiables
 Facultatif: Utilisez uniquement si nécessaire pour clarifier
 Exemple                                   on peut commencer par les
                                          postconditions avant même les
    UC «Inscription à des cours»
                                                      flots.
    Postconditions
      À la fin de ce cas d'utilisation, soit l'étudiant a été inscrit à des cours, soit
       l’inscription a échoué et aucune modification n'a été apportée à aux cours...
                                           76 /98
Dict.      U.C.                   Process.   ✓4.détailler   Compléments.


  Exemple de description détaillée d’un UC
                                             Précondition :
                     Le distributeur contient des billets, il est en attente d ’une
                         opération, il n’est ni en panne, ni en maintenance


                    Début : lorsqu ’un client introduit sa carte bancaire dans le
   Retirer
 DeLArgent                                  distributeur.
AuDistributeur

                      Fin : lorsque la carte bancaire et les billets sont sortis.

                                          Postcondition :
                     Si de l ’argent a pu être retiré la somme d’argent sur le
                    compte est égale à la somme d ’argent qu’il y avait avant,
                   moins le montant du retrait. Sinon la somme d ’argent sur le
                                  compte est la même qu’avant.
Jean-Marie Favre                          77 /98
Dict.   U.C.   ✓Système   Process.   ✓4.détailler   Compléments.


Description détaillée d’un UC
 ■ Description des scénarios:
   ■ Préconditions
   ■ Scénario Nominal
   ■ Flots alternatifs
   ■ Flots d'erreur
   ■ Postconditions
   ■ Exigences non fonctionnelles
 ■ Besoins d'IHM
                             78 /98
Dict.      U.C.                   Process.   ✓4.détailler   Compléments.

      Exemple de description détaillée d’un UC
                                   Contraintes non fonctionnelles :


                       (A) Performance : le système doit réagir dans un délai
                    inférieur à 4 secondes, quelque soit l ’action de l ’utilisateur.
   Retirer
 DeLArgent
AuDistributeur      (B) Résistance aux pannes : si une coupure de courant ou
                    une autre défaillance survient au cours du cas d ’utilisation,
                    la transaction sera annulée, l ’argent ne sera pas distribué.
                       Le système doit pouvoir redémarrer automatiquement
                        dans un état cohérent et sans intervention humaine.


                     (C) Résistance à la charge : le système doit pouvoir gérer
                           plus de 1000 retraits d ’argent simultanément
                                                 ...
Jean-Marie Favre                          79 /98
Description textuelle du cas d'utilisation:
               « RETIRER DE L’ARGENT » 
                   informations optionnelles
Exigences non fonctionnelles

    Contraintes                            Descriptif
Temps de réponse    L’interface du GAB doit réagir en l’espace de 2
                    secondes au maximum. Une transaction nominale
                    de retrait doit durer moins de 2 minutes
Concurrence         Non applicable (mono-utilisateur)

Disponibilité       Le GAB est accessible 7j/7, 24h/24 . L’absence de
                    papier pour les tickets ne doit pas empêcher les
                    retraits.
Intégrité           Les interface du GAB doivent être très robustes
                    pour prévenir le vandalisme

Confidentialité     La vérification du code saisi doit être fiable à 10-6
Dict.   U.C.   ✓Système   Process.   ✓4.détailler   Compléments.


Description détaillée d’un UC
 ■ Description des scénarios:
   ■ Préconditions
   ■ Scénario Nominal
   ■ Flots alternatifs
   ■ Flots d'erreur
   ■ Postconditions
   ■ Exigences non fonctionnelles
 ■ Besoins d'IHM
                             81 /98
Description textuelle du cas d'utilisation:
              « RETIRER DE L’ARGENT » 
                  informations optionnelles
Besoins d’IHM
Les dispositifs d'entrée/sortie à la disposition du porteur
   de carte doivent être :
• Un lecteur de carte bancaire.
• Un clavier numérique (pour saisir son code), avec des
   touches «validation », « correction » et « annulation ».
• Un écran pour l'affichage des messages du GAB.
• Des touches autour de l'écran pour sélectionner un
   montant de retrait parmi ceux qui sont proposés.
• Un distributeur de billets.
• Un distributeur de tickets.
Dict.   U.C.        Process.   ✓4.détailler   Compléments.



Faire le point sur les UC
Les interactions entre le système et les acteurs
sont claires
Les séquence de communication sont conformes
aux attentes de l'utilisateur
Quand/comment les UC commencent/se
terminent est clair
Le flot de base de base donne un résultat
observable pour un ou plusieurs acteurs
                     83 /98
Dict.   U.C.              Process.   ✓4.détailler   Compléments.


      Quel niveau de détail?
✓   Saisir toutes les                     X Pas de détail des
    exigences pour tous les               interfaces utilisateurs
    demandeurs
                                          X Pas de détail des
                                          processus internes non
                                          liés à une exigence
✓   Informations et
    événements                            X Pas les formats de
                                          données, ni les contrôles

           How much detail in a use case?
 Enough to satisfy all stakeholders that their interests
(requirements) will be satisfied in the delivered system.
                              84 /98
Dict.      U.C.               Process.                Compléments.


         Ecrire des UC : Défis
1.       Comment garder les UC précis et concis?
2.       Comment traiter les interfaces utilisateur?
3.       Comment traiter un flux quand
     a.     Un acteur doit choisir parmi différentes options?
     b.     Un acteur peut répéter des actions avant de passer à
            la suite?
     c.     Les étapes ne sont pas nécessairement séquentielles?
4.       Comment gérer le comportement conditionnelle dans les
         cas d'utilisation?


                                85 /98
Dict.     U.C.                Process.                    Compléments.


 1.Comment garder les UC précis et concis?(1)
✓ Capturer le vocabulaire commun dans un
   glossaire
    ➡ Définir les termes utilisés dans le projet dans le glossaire,
             pas dans les flux
    ➡ Aide à éviter les malentendus
                 Use Case                                     Glossary
 5. Enter Customer Information                   Customer Details Information
                                                 that uniquely identifies and
    The system prompts the Customer to           provides contact information
    enter their Customer Details.                for a customer located in the
    The Customer enters the Customer             U.S.A. The information
                                                 consists of Name, two address
    Details.                                     lines, city, state, ZIP code, and
    The Customer creates the account.            daytime phone number.
                                              Implementation

                                   86 /98
Dict.    U.C.                   Process.                    Compléments.


 1.Comment garder les UC précis et concis? (2)
✓ Visualiser le glossaire par un modèle du
   domaine
   Student       1          0..*    Schedule     0..*        0..4 Course Offering


                                                                 0..*       0..*



                                                    0..1                    1
 Part-time Student   Full-time Student           Professor              Course




                                         87/98
Dict.    U.C.       Process.     Compléments.

           Relations entre UC :
        Include, Extend, Specialize




                     88 /98
Dict.    U.C.               Process.                Compléments.

               Relations entre UC :
            Include, Extend, Specialize
Au fur et à mesure que les cas d’utilisation sont documentés,
des relations peuvent apparaître
‣     Une relation include : utilisation systématique
‣     Une relation extend dénote un comportement optionnel




                                 88 /98
Dict.   U.C.          Process.             Compléments.



                                    Extends
                                    Les deux UC sont
                                     indépendants.

                                Permettre au client de
                               consulter son solde avant
                                 de saisir le montant :
                                extension optionnelle.

Flot enrichi
       8. Le GAB demande au client de saisir le montant
             Point d’extension : Vérification du solde
       9. Le client saisit le montant désiré de retrait
                          89 /98
La relation <<include>>   ou <<uses>>
La relation <<include>>                  ou <<uses>>
La relation d’include a pour seul objectif de factoriser une
partie de la description d’un cas d’utilisation qui est
commune à d’autres cas d’utilisation.
La relation <<include>>                  ou <<uses>>
La relation d’include a pour seul objectif de factoriser une
partie de la description d’un cas d’utilisation qui est
commune à d’autres cas d’utilisation.
Le cas d’utilisation inclus dans les autres cas d’utilisation
n’est pas à proprement parler un vrai cas d’utilisation car il
n’a pas d’acteur déclencheur ou receveur d’évènement.
La relation <<include>>                  ou <<uses>>
La relation d’include a pour seul objectif de factoriser une
partie de la description d’un cas d’utilisation qui est
commune à d’autres cas d’utilisation.
Le cas d’utilisation inclus dans les autres cas d’utilisation
n’est pas à proprement parler un vrai cas d’utilisation car il
n’a pas d’acteur déclencheur ou receveur d’évènement.
Il est juste un artifice pour faire de la réutilisation d’une
portion de texte.
Généralisation

   L'association de généralisation entre cas d'utilisation a la
    même sémantique que pour les classes


                          Valider usager




                  Vérifier              Scanner
                mot de passe             rétine


                                                         91
Dict.   U.C.   Process.   Compléments.

La galerie




                    /98
Dict.   U.C.             Process.      Compléments.

Structuration des UC en packages




     Scanner p 43 et 44 de UML par la pratique
On peut alors, si nécessaire,
 détailler certains de cas
       d’utilisation.        /98
Dict.     U.C.                  Process.               Compléments.


  2. Comment traiter les interfaces utilisateur?
✓Laissez l'interface utilisateur hors des UC
    ➡ Les UC sont indépendants de l'interface utilisateur
    ➡ Décrire les interfaces utilisateur avec des modèles dédiés
             ou des prototypes
          Words to Avoid                          Words to Use
 Click          Drag     Form                   Prompts        Chooses
 Open           Close    Drop                   Initiates
 Button         Field    Drop-down              Specifies
 Pop-up         Scroll   Browse                 Submits        Selects
 Record         Window                          Starts         Displays
                                                Informs


 “Le système fait sonner le téléphone.”
                                     94 /98
Dict.     U.C.                  Process.               Compléments.


  2. Comment traiter les interfaces utilisateur?
✓Laissez l'interface utilisateur hors des UC
    ➡ Les UC sont indépendants de l'interface utilisateur
    ➡ Décrire les interfaces utilisateur avec des modèles dédiés
             ou des prototypes
          Words to Avoid                          Words to Use
 Click          Drag     Form                   Prompts        Chooses
 Open           Close    Drop                   Initiates
 Button         Field    Drop-down              Specifies
 Pop-up         Scroll   Browse                 Submits        Selects
 Record         Window                          Starts         Displays
                                                Informs


 “Le système fait sonner le téléphone.”
                                     94 /98
Dict.     U.C.                  Process.               Compléments.


  2. Comment traiter les interfaces utilisateur?
✓Laissez l'interface utilisateur hors des UC
    ➡ Les UC sont indépendants de l'interface utilisateur
    ➡ Décrire les interfaces utilisateur avec des modèles dédiés
             ou des prototypes
          Words to Avoid                          Words to Use
 Click          Drag     Form                   Prompts        Chooses
 Open           Close    Drop                   Initiates
 Button         Field    Drop-down              Specifies
 Pop-up         Scroll   Browse                 Submits        Selects
 Record         Window                          Starts         Displays
                                                Informs


 “Le système fait sonner le téléphone.”
                                     94 /98
Dict.     U.C.                  Process.               Compléments.


  2. Comment traiter les interfaces utilisateur?
✓Laissez l'interface utilisateur hors des UC
    ➡ Les UC sont indépendants de l'interface utilisateur
    ➡ Décrire les interfaces utilisateur avec des modèles dédiés
             ou des prototypes
          Words to Avoid                          Words to Use
 Click          Drag     Form                   Prompts        Chooses
 Open           Close    Drop                   Initiates
 Button         Field    Drop-down              Specifies
 Pop-up         Scroll   Browse                 Submits        Selects
 Record         Window                          Starts         Displays
                                                Informs


 “Le système fait sonner le téléphone.”
                 notifie              94 /98
Si c’est nécessaire...Après...
• avec l’addon Firefox :
• http://pencil.evolus.vn/en-US/Downloads/Application.aspx




                                               95
Résumé
       et
    conseils
méthodologiques
       96
Dict.   U.C.            Process.          Compléments.



  Cas d’utilisation : résumé
 Se   servir des Cas d’Utilisation UML pour identifier les
                   exigences fonctionnelles.




                            97 /98
Dict.   U.C.   Process.   Compléments.



Cas d’utilisation : résumé




               98 /98

Contenu connexe

Tendances

Présentation finale
Présentation finalePrésentation finale
Présentation finaleheniBa
 
Application de gestion, suivi,et de sécurité des chantiers en temps réels.
Application  de gestion, suivi,et de sécurité des chantiers en temps réels.Application  de gestion, suivi,et de sécurité des chantiers en temps réels.
Application de gestion, suivi,et de sécurité des chantiers en temps réels.Sabri El gharbi El yahmadi
 
Rapport Projet de fin d'etude sur le parc informatique
Rapport Projet  de fin d'etude sur le parc informatiqueRapport Projet  de fin d'etude sur le parc informatique
Rapport Projet de fin d'etude sur le parc informatiqueHicham Ben
 
TD4-UML-Correction
TD4-UML-CorrectionTD4-UML-Correction
TD4-UML-CorrectionLilia Sfaxi
 
Conception et Réalisation Application Web Laravel PFE BTS
Conception et Réalisation Application Web Laravel PFE BTSConception et Réalisation Application Web Laravel PFE BTS
Conception et Réalisation Application Web Laravel PFE BTSFaissoilMkavavo
 
Rapport PFE : Développement D'une application de gestion des cartes de fidéli...
Rapport PFE : Développement D'une application de gestion des cartes de fidéli...Rapport PFE : Développement D'une application de gestion des cartes de fidéli...
Rapport PFE : Développement D'une application de gestion des cartes de fidéli...Riadh K.
 
Presentation d'un logiciel de GRH
Presentation d'un logiciel de GRHPresentation d'un logiciel de GRH
Presentation d'un logiciel de GRHRiadh K.
 
presentation_PFE.pptx
presentation_PFE.pptxpresentation_PFE.pptx
presentation_PFE.pptxFazaFoudhaili
 
Gestion des Chercheurs d’Emploi
Gestion des Chercheurs d’EmploiGestion des Chercheurs d’Emploi
Gestion des Chercheurs d’EmploiAzzeddine Elouadi
 
Rapport PFE Développent d'une application bancaire mobile
Rapport PFE Développent d'une application bancaire mobileRapport PFE Développent d'une application bancaire mobile
Rapport PFE Développent d'une application bancaire mobileNader Somrani
 
Rapport gestion de stock.pdf
Rapport gestion de stock.pdfRapport gestion de stock.pdf
Rapport gestion de stock.pdfAchrafAntri2
 
rapport de projet de fin d'étude_PFE
rapport de projet de fin d'étude_PFErapport de projet de fin d'étude_PFE
rapport de projet de fin d'étude_PFEDonia Hammami
 
Rapport de stage PFE - Mémoire master: Développement d'une application Android
Rapport de stage PFE - Mémoire master: Développement d'une application AndroidRapport de stage PFE - Mémoire master: Développement d'une application Android
Rapport de stage PFE - Mémoire master: Développement d'une application AndroidBadrElattaoui
 
PFE :: Application de gestion des dus d'enseignement
PFE :: Application de gestion des dus d'enseignementPFE :: Application de gestion des dus d'enseignement
PFE :: Application de gestion des dus d'enseignementNassim Bahri
 
UML Part2- diagramme des uses cases_mansouri
UML Part2- diagramme des uses cases_mansouriUML Part2- diagramme des uses cases_mansouri
UML Part2- diagramme des uses cases_mansouriMansouri Khalifa
 
Projet PFE corrigé latest
Projet PFE corrigé latestProjet PFE corrigé latest
Projet PFE corrigé latestahed bf
 
Projet de fin d’études
Projet de fin d’études  Projet de fin d’études
Projet de fin d’études TombariAhmed
 

Tendances (20)

Présentation finale
Présentation finalePrésentation finale
Présentation finale
 
Application de gestion, suivi,et de sécurité des chantiers en temps réels.
Application  de gestion, suivi,et de sécurité des chantiers en temps réels.Application  de gestion, suivi,et de sécurité des chantiers en temps réels.
Application de gestion, suivi,et de sécurité des chantiers en temps réels.
 
Rapport Projet de fin d'etude sur le parc informatique
Rapport Projet  de fin d'etude sur le parc informatiqueRapport Projet  de fin d'etude sur le parc informatique
Rapport Projet de fin d'etude sur le parc informatique
 
TD4-UML-Correction
TD4-UML-CorrectionTD4-UML-Correction
TD4-UML-Correction
 
Conception et Réalisation Application Web Laravel PFE BTS
Conception et Réalisation Application Web Laravel PFE BTSConception et Réalisation Application Web Laravel PFE BTS
Conception et Réalisation Application Web Laravel PFE BTS
 
2 TUP
2 TUP2 TUP
2 TUP
 
Rapport PFE : Développement D'une application de gestion des cartes de fidéli...
Rapport PFE : Développement D'une application de gestion des cartes de fidéli...Rapport PFE : Développement D'une application de gestion des cartes de fidéli...
Rapport PFE : Développement D'une application de gestion des cartes de fidéli...
 
Presentation d'un logiciel de GRH
Presentation d'un logiciel de GRHPresentation d'un logiciel de GRH
Presentation d'un logiciel de GRH
 
presentation_PFE.pptx
presentation_PFE.pptxpresentation_PFE.pptx
presentation_PFE.pptx
 
Gestion des Chercheurs d’Emploi
Gestion des Chercheurs d’EmploiGestion des Chercheurs d’Emploi
Gestion des Chercheurs d’Emploi
 
Rapport PFE Développent d'une application bancaire mobile
Rapport PFE Développent d'une application bancaire mobileRapport PFE Développent d'une application bancaire mobile
Rapport PFE Développent d'une application bancaire mobile
 
Rapport gestion de stock.pdf
Rapport gestion de stock.pdfRapport gestion de stock.pdf
Rapport gestion de stock.pdf
 
rapport de projet de fin d'étude_PFE
rapport de projet de fin d'étude_PFErapport de projet de fin d'étude_PFE
rapport de projet de fin d'étude_PFE
 
présentation PFE (2)
présentation PFE (2)présentation PFE (2)
présentation PFE (2)
 
Rapport de stage PFE - Mémoire master: Développement d'une application Android
Rapport de stage PFE - Mémoire master: Développement d'une application AndroidRapport de stage PFE - Mémoire master: Développement d'une application Android
Rapport de stage PFE - Mémoire master: Développement d'une application Android
 
PFE :: Application de gestion des dus d'enseignement
PFE :: Application de gestion des dus d'enseignementPFE :: Application de gestion des dus d'enseignement
PFE :: Application de gestion des dus d'enseignement
 
UML Part2- diagramme des uses cases_mansouri
UML Part2- diagramme des uses cases_mansouriUML Part2- diagramme des uses cases_mansouri
UML Part2- diagramme des uses cases_mansouri
 
Projet PFE corrigé latest
Projet PFE corrigé latestProjet PFE corrigé latest
Projet PFE corrigé latest
 
Projet de fin d’études
Projet de fin d’études  Projet de fin d’études
Projet de fin d’études
 
Rapport PFE
Rapport PFERapport PFE
Rapport PFE
 

En vedette

Introduction rapide à 'objet et à UML
Introduction rapide à 'objet et  à UML Introduction rapide à 'objet et  à UML
Introduction rapide à 'objet et à UML Mireille Blay-Fornarino
 
Methodes de gestion de projets - introduction au processus unifié
Methodes de gestion de projets - introduction au processus unifiéMethodes de gestion de projets - introduction au processus unifié
Methodes de gestion de projets - introduction au processus unifiéMireille Blay-Fornarino
 
Modélisation par Objets - Introduction - De Merise à UML
Modélisation par Objets - Introduction - De Merise à UMLModélisation par Objets - Introduction - De Merise à UML
Modélisation par Objets - Introduction - De Merise à UMLMireille Blay-Fornarino
 
Analyse et conception des systèmes d’information
Analyse et conception des systèmes d’informationAnalyse et conception des systèmes d’information
Analyse et conception des systèmes d’informationMireille Blay-Fornarino
 
Chp5 - Diagramme d'Etat Transition
Chp5 - Diagramme d'Etat TransitionChp5 - Diagramme d'Etat Transition
Chp5 - Diagramme d'Etat TransitionLilia Sfaxi
 
Cours : Le droit commercial Marocain
Cours : Le droit commercial Marocain Cours : Le droit commercial Marocain
Cours : Le droit commercial Marocain Sami Oublal
 
MaestríA Diversidad 1 Presentacion Comparacion
MaestríA Diversidad 1 Presentacion ComparacionMaestríA Diversidad 1 Presentacion Comparacion
MaestríA Diversidad 1 Presentacion ComparacionAdalberto
 
Representantes De Cada Distrito Fisica, Artistica, Ciudadana
Representantes De Cada Distrito Fisica, Artistica, CiudadanaRepresentantes De Cada Distrito Fisica, Artistica, Ciudadana
Representantes De Cada Distrito Fisica, Artistica, CiudadanaAdalberto
 
Maestria Siendo Objetivos Contenido
Maestria Siendo Objetivos   ContenidoMaestria Siendo Objetivos   Contenido
Maestria Siendo Objetivos ContenidoAdalberto
 
El Negro y la Leonilda
El Negro y la LeonildaEl Negro y la Leonilda
El Negro y la LeonildaPUPOVISION
 
Les entreprises en Poitou-Charentes : Bilan 2009-Perspectives 2010
Les entreprises en Poitou-Charentes : Bilan 2009-Perspectives 2010Les entreprises en Poitou-Charentes : Bilan 2009-Perspectives 2010
Les entreprises en Poitou-Charentes : Bilan 2009-Perspectives 2010guest28ebe7
 
This Is Beautiful
This Is BeautifulThis Is Beautiful
This Is Beautifulcattaneo17
 

En vedette (20)

Uml classes Par les exemples
Uml classes Par les exemplesUml classes Par les exemples
Uml classes Par les exemples
 
Uml interactions
Uml interactionsUml interactions
Uml interactions
 
Introduction à Uml
Introduction à UmlIntroduction à Uml
Introduction à Uml
 
Introduction rapide à 'objet et à UML
Introduction rapide à 'objet et  à UML Introduction rapide à 'objet et  à UML
Introduction rapide à 'objet et à UML
 
De l'analyse à la conception
De l'analyse à la conceptionDe l'analyse à la conception
De l'analyse à la conception
 
Methodes de gestion de projets - introduction au processus unifié
Methodes de gestion de projets - introduction au processus unifiéMethodes de gestion de projets - introduction au processus unifié
Methodes de gestion de projets - introduction au processus unifié
 
Modélisation par Objets - Introduction - De Merise à UML
Modélisation par Objets - Introduction - De Merise à UMLModélisation par Objets - Introduction - De Merise à UML
Modélisation par Objets - Introduction - De Merise à UML
 
Uml & cas d'utilisation
Uml & cas d'utilisationUml & cas d'utilisation
Uml & cas d'utilisation
 
Diagramme d'activité en UML
Diagramme d'activité en UMLDiagramme d'activité en UML
Diagramme d'activité en UML
 
Diagrammes de classes
Diagrammes de classesDiagrammes de classes
Diagrammes de classes
 
Analyse et conception des systèmes d’information
Analyse et conception des systèmes d’informationAnalyse et conception des systèmes d’information
Analyse et conception des systèmes d’information
 
Analyse et cahier des charges
Analyse et cahier des chargesAnalyse et cahier des charges
Analyse et cahier des charges
 
Chp5 - Diagramme d'Etat Transition
Chp5 - Diagramme d'Etat TransitionChp5 - Diagramme d'Etat Transition
Chp5 - Diagramme d'Etat Transition
 
Cours : Le droit commercial Marocain
Cours : Le droit commercial Marocain Cours : Le droit commercial Marocain
Cours : Le droit commercial Marocain
 
MaestríA Diversidad 1 Presentacion Comparacion
MaestríA Diversidad 1 Presentacion ComparacionMaestríA Diversidad 1 Presentacion Comparacion
MaestríA Diversidad 1 Presentacion Comparacion
 
Representantes De Cada Distrito Fisica, Artistica, Ciudadana
Representantes De Cada Distrito Fisica, Artistica, CiudadanaRepresentantes De Cada Distrito Fisica, Artistica, Ciudadana
Representantes De Cada Distrito Fisica, Artistica, Ciudadana
 
Maestria Siendo Objetivos Contenido
Maestria Siendo Objetivos   ContenidoMaestria Siendo Objetivos   Contenido
Maestria Siendo Objetivos Contenido
 
El Negro y la Leonilda
El Negro y la LeonildaEl Negro y la Leonilda
El Negro y la Leonilda
 
Les entreprises en Poitou-Charentes : Bilan 2009-Perspectives 2010
Les entreprises en Poitou-Charentes : Bilan 2009-Perspectives 2010Les entreprises en Poitou-Charentes : Bilan 2009-Perspectives 2010
Les entreprises en Poitou-Charentes : Bilan 2009-Perspectives 2010
 
This Is Beautiful
This Is BeautifulThis Is Beautiful
This Is Beautiful
 

Similaire à Uml Cas Utilisation introduction

atam guide de developpement v1.3
atam guide de developpement v1.3atam guide de developpement v1.3
atam guide de developpement v1.3Abdessamad Hamouch
 
Chapitre 1 - Introcution & cycles de développement - Etudiant.pptx
Chapitre 1 - Introcution & cycles de développement - Etudiant.pptxChapitre 1 - Introcution & cycles de développement - Etudiant.pptx
Chapitre 1 - Introcution & cycles de développement - Etudiant.pptxssuserec8501
 
Rapport de projet symphony
Rapport de projet symphonyRapport de projet symphony
Rapport de projet symphonyTonySARR1
 
Resume theorique-m106-partie1-1401-620cd8a160396 (1)
Resume theorique-m106-partie1-1401-620cd8a160396 (1)Resume theorique-m106-partie1-1401-620cd8a160396 (1)
Resume theorique-m106-partie1-1401-620cd8a160396 (1)MounirAlaoui4
 
Expression des besoins pour le SI
Expression des besoins pour le SIExpression des besoins pour le SI
Expression des besoins pour le SINouhaila ALAMI
 
resume-theorique-m106-partie1-v2-6228baed03113 (1).pptx
resume-theorique-m106-partie1-v2-6228baed03113 (1).pptxresume-theorique-m106-partie1-v2-6228baed03113 (1).pptx
resume-theorique-m106-partie1-v2-6228baed03113 (1).pptxZakariaLabay
 
resume-theorique-m106-partie1-v2-6228baed03113 (1).pptx
resume-theorique-m106-partie1-v2-6228baed03113 (1).pptxresume-theorique-m106-partie1-v2-6228baed03113 (1).pptx
resume-theorique-m106-partie1-v2-6228baed03113 (1).pptxFootballLovers9
 
Unified Modeling Language Intro 2021-2022 VF
Unified Modeling Language Intro 2021-2022 VFUnified Modeling Language Intro 2021-2022 VF
Unified Modeling Language Intro 2021-2022 VFcifaf13039
 
Génie Logiciel.pptx
Génie Logiciel.pptxGénie Logiciel.pptx
Génie Logiciel.pptxLatifaBen6
 
Es20 g formation-z-os-system-services-structure
Es20 g formation-z-os-system-services-structureEs20 g formation-z-os-system-services-structure
Es20 g formation-z-os-system-services-structureCERTyou Formation
 
Cours Génie Logiciel 2016
Cours Génie Logiciel 2016Cours Génie Logiciel 2016
Cours Génie Logiciel 2016Erradi Mohamed
 
2.2 cycles de vie
2.2 cycles de vie2.2 cycles de vie
2.2 cycles de vieHarun Mouad
 
Xtensus catalogue pfe-2018
Xtensus catalogue pfe-2018Xtensus catalogue pfe-2018
Xtensus catalogue pfe-2018. WATCOM
 
Présentation agreg 2015 épreuve tp
Présentation agreg 2015 épreuve tpPrésentation agreg 2015 épreuve tp
Présentation agreg 2015 épreuve tpthibault13600
 
Chp2 - Cahier des Charges
Chp2 - Cahier des ChargesChp2 - Cahier des Charges
Chp2 - Cahier des ChargesLilia Sfaxi
 
application de gestion de station service .pdf
application de gestion de station service .pdfapplication de gestion de station service .pdf
application de gestion de station service .pdfmuhamedvallmed2
 
Introduction module IHM Polytech Sophia Dept Info SI3
Introduction module IHM Polytech Sophia Dept Info SI3Introduction module IHM Polytech Sophia Dept Info SI3
Introduction module IHM Polytech Sophia Dept Info SI3Anne-Marie Pinna-Dery
 

Similaire à Uml Cas Utilisation introduction (20)

atam guide de developpement v1.3
atam guide de developpement v1.3atam guide de developpement v1.3
atam guide de developpement v1.3
 
Chapitre 1 - Introcution & cycles de développement - Etudiant.pptx
Chapitre 1 - Introcution & cycles de développement - Etudiant.pptxChapitre 1 - Introcution & cycles de développement - Etudiant.pptx
Chapitre 1 - Introcution & cycles de développement - Etudiant.pptx
 
Rapport de projet symphony
Rapport de projet symphonyRapport de projet symphony
Rapport de projet symphony
 
Intro ihm
Intro ihmIntro ihm
Intro ihm
 
Resume theorique-m106-partie1-1401-620cd8a160396 (1)
Resume theorique-m106-partie1-1401-620cd8a160396 (1)Resume theorique-m106-partie1-1401-620cd8a160396 (1)
Resume theorique-m106-partie1-1401-620cd8a160396 (1)
 
Expression des besoins pour le SI
Expression des besoins pour le SIExpression des besoins pour le SI
Expression des besoins pour le SI
 
resume-theorique-m106-partie1-v2-6228baed03113 (1).pptx
resume-theorique-m106-partie1-v2-6228baed03113 (1).pptxresume-theorique-m106-partie1-v2-6228baed03113 (1).pptx
resume-theorique-m106-partie1-v2-6228baed03113 (1).pptx
 
resume-theorique-m106-partie1-v2-6228baed03113 (1).pptx
resume-theorique-m106-partie1-v2-6228baed03113 (1).pptxresume-theorique-m106-partie1-v2-6228baed03113 (1).pptx
resume-theorique-m106-partie1-v2-6228baed03113 (1).pptx
 
Unified Modeling Language Intro 2021-2022 VF
Unified Modeling Language Intro 2021-2022 VFUnified Modeling Language Intro 2021-2022 VF
Unified Modeling Language Intro 2021-2022 VF
 
Génie Logiciel.pptx
Génie Logiciel.pptxGénie Logiciel.pptx
Génie Logiciel.pptx
 
Es20 g formation-z-os-system-services-structure
Es20 g formation-z-os-system-services-structureEs20 g formation-z-os-system-services-structure
Es20 g formation-z-os-system-services-structure
 
Cours Génie Logiciel 2016
Cours Génie Logiciel 2016Cours Génie Logiciel 2016
Cours Génie Logiciel 2016
 
2.2 cycles de vie
2.2 cycles de vie2.2 cycles de vie
2.2 cycles de vie
 
Xtensus catalogue pfe-2018
Xtensus catalogue pfe-2018Xtensus catalogue pfe-2018
Xtensus catalogue pfe-2018
 
Présentation agreg 2015 épreuve tp
Présentation agreg 2015 épreuve tpPrésentation agreg 2015 épreuve tp
Présentation agreg 2015 épreuve tp
 
Chp2 - Cahier des Charges
Chp2 - Cahier des ChargesChp2 - Cahier des Charges
Chp2 - Cahier des Charges
 
Lecon 1.1
Lecon 1.1Lecon 1.1
Lecon 1.1
 
Plasticitérecherche2015 2
Plasticitérecherche2015 2Plasticitérecherche2015 2
Plasticitérecherche2015 2
 
application de gestion de station service .pdf
application de gestion de station service .pdfapplication de gestion de station service .pdf
application de gestion de station service .pdf
 
Introduction module IHM Polytech Sophia Dept Info SI3
Introduction module IHM Polytech Sophia Dept Info SI3Introduction module IHM Polytech Sophia Dept Info SI3
Introduction module IHM Polytech Sophia Dept Info SI3
 

Dernier

La Base unique départementale - Quel bilan, au bout de 5 ans .pdf
La Base unique départementale - Quel bilan, au bout de 5 ans .pdfLa Base unique départementale - Quel bilan, au bout de 5 ans .pdf
La Base unique départementale - Quel bilan, au bout de 5 ans .pdfbdp12
 
Pas de vagues. pptx Film français
Pas de vagues.  pptx      Film   françaisPas de vagues.  pptx      Film   français
Pas de vagues. pptx Film françaisTxaruka
 
Pas de vagues. pptx Film français
Pas de vagues.  pptx   Film     françaisPas de vagues.  pptx   Film     français
Pas de vagues. pptx Film françaisTxaruka
 
Vulnérabilité numérique d’usage : un enjeu pour l’aide à la réussitepdf
Vulnérabilité numérique d’usage : un enjeu pour l’aide à la réussitepdfVulnérabilité numérique d’usage : un enjeu pour l’aide à la réussitepdf
Vulnérabilité numérique d’usage : un enjeu pour l’aide à la réussitepdfSylvianeBachy
 
Apprendre avec des top et nano influenceurs
Apprendre avec des top et nano influenceursApprendre avec des top et nano influenceurs
Apprendre avec des top et nano influenceursStagiaireLearningmat
 
Chana Orloff.pptx Sculptrice franco-ukranienne
Chana Orloff.pptx Sculptrice franco-ukranienneChana Orloff.pptx Sculptrice franco-ukranienne
Chana Orloff.pptx Sculptrice franco-ukranienneTxaruka
 
Potentiel du Maroc en Produits du Terroir et Stratégie Adoptée pour le dévelo...
Potentiel du Maroc en Produits du Terroir et Stratégie Adoptée pour le dévelo...Potentiel du Maroc en Produits du Terroir et Stratégie Adoptée pour le dévelo...
Potentiel du Maroc en Produits du Terroir et Stratégie Adoptée pour le dévelo...NaimDoumissi
 
Bibdoc 2024 - L’Éducation aux Médias et à l’Information face à l’intelligence...
Bibdoc 2024 - L’Éducation aux Médias et à l’Information face à l’intelligence...Bibdoc 2024 - L’Éducation aux Médias et à l’Information face à l’intelligence...
Bibdoc 2024 - L’Éducation aux Médias et à l’Information face à l’intelligence...Bibdoc 37
 
Bibdoc 2024 - Ecologie du livre et creation de badge.pdf
Bibdoc 2024 - Ecologie du livre et creation de badge.pdfBibdoc 2024 - Ecologie du livre et creation de badge.pdf
Bibdoc 2024 - Ecologie du livre et creation de badge.pdfBibdoc 37
 
PIE-A2-P 5- Supports stagiaires.pptx.pdf
PIE-A2-P 5- Supports stagiaires.pptx.pdfPIE-A2-P 5- Supports stagiaires.pptx.pdf
PIE-A2-P 5- Supports stagiaires.pptx.pdfRiDaHAziz
 
Faut-il avoir peur de la technique ? (G. Gay-Para)
Faut-il avoir peur de la technique ? (G. Gay-Para)Faut-il avoir peur de la technique ? (G. Gay-Para)
Faut-il avoir peur de la technique ? (G. Gay-Para)Gabriel Gay-Para
 
Présentation - Initiatives - CECOSDA - OIF - Fact Checking.pptx
Présentation - Initiatives - CECOSDA - OIF - Fact Checking.pptxPrésentation - Initiatives - CECOSDA - OIF - Fact Checking.pptx
Présentation - Initiatives - CECOSDA - OIF - Fact Checking.pptxJCAC
 
Cours de Management des Systèmes d'information
Cours de Management des Systèmes d'informationCours de Management des Systèmes d'information
Cours de Management des Systèmes d'informationpapediallo3
 
Bernard Réquichot.pptx Peintre français
Bernard Réquichot.pptx   Peintre françaisBernard Réquichot.pptx   Peintre français
Bernard Réquichot.pptx Peintre françaisTxaruka
 
PIE-A2-P4-support stagiaires sept 22-validé.pdf
PIE-A2-P4-support stagiaires sept 22-validé.pdfPIE-A2-P4-support stagiaires sept 22-validé.pdf
PIE-A2-P4-support stagiaires sept 22-validé.pdfRiDaHAziz
 
Bibdoc 2024 - Les maillons de la chaine du livre face aux enjeux écologiques.pdf
Bibdoc 2024 - Les maillons de la chaine du livre face aux enjeux écologiques.pdfBibdoc 2024 - Les maillons de la chaine du livre face aux enjeux écologiques.pdf
Bibdoc 2024 - Les maillons de la chaine du livre face aux enjeux écologiques.pdfBibdoc 37
 
DIGNITAS INFINITA - DIGNITÉ HUMAINE; déclaration du dicastère .pptx
DIGNITAS INFINITA - DIGNITÉ HUMAINE; déclaration du dicastère .pptxDIGNITAS INFINITA - DIGNITÉ HUMAINE; déclaration du dicastère .pptx
DIGNITAS INFINITA - DIGNITÉ HUMAINE; déclaration du dicastère .pptxMartin M Flynn
 

Dernier (18)

La Base unique départementale - Quel bilan, au bout de 5 ans .pdf
La Base unique départementale - Quel bilan, au bout de 5 ans .pdfLa Base unique départementale - Quel bilan, au bout de 5 ans .pdf
La Base unique départementale - Quel bilan, au bout de 5 ans .pdf
 
Pas de vagues. pptx Film français
Pas de vagues.  pptx      Film   françaisPas de vagues.  pptx      Film   français
Pas de vagues. pptx Film français
 
Bulletin des bibliotheques Burkina Faso mars 2024
Bulletin des bibliotheques Burkina Faso mars 2024Bulletin des bibliotheques Burkina Faso mars 2024
Bulletin des bibliotheques Burkina Faso mars 2024
 
Pas de vagues. pptx Film français
Pas de vagues.  pptx   Film     françaisPas de vagues.  pptx   Film     français
Pas de vagues. pptx Film français
 
Vulnérabilité numérique d’usage : un enjeu pour l’aide à la réussitepdf
Vulnérabilité numérique d’usage : un enjeu pour l’aide à la réussitepdfVulnérabilité numérique d’usage : un enjeu pour l’aide à la réussitepdf
Vulnérabilité numérique d’usage : un enjeu pour l’aide à la réussitepdf
 
Apprendre avec des top et nano influenceurs
Apprendre avec des top et nano influenceursApprendre avec des top et nano influenceurs
Apprendre avec des top et nano influenceurs
 
Chana Orloff.pptx Sculptrice franco-ukranienne
Chana Orloff.pptx Sculptrice franco-ukranienneChana Orloff.pptx Sculptrice franco-ukranienne
Chana Orloff.pptx Sculptrice franco-ukranienne
 
Potentiel du Maroc en Produits du Terroir et Stratégie Adoptée pour le dévelo...
Potentiel du Maroc en Produits du Terroir et Stratégie Adoptée pour le dévelo...Potentiel du Maroc en Produits du Terroir et Stratégie Adoptée pour le dévelo...
Potentiel du Maroc en Produits du Terroir et Stratégie Adoptée pour le dévelo...
 
Bibdoc 2024 - L’Éducation aux Médias et à l’Information face à l’intelligence...
Bibdoc 2024 - L’Éducation aux Médias et à l’Information face à l’intelligence...Bibdoc 2024 - L’Éducation aux Médias et à l’Information face à l’intelligence...
Bibdoc 2024 - L’Éducation aux Médias et à l’Information face à l’intelligence...
 
Bibdoc 2024 - Ecologie du livre et creation de badge.pdf
Bibdoc 2024 - Ecologie du livre et creation de badge.pdfBibdoc 2024 - Ecologie du livre et creation de badge.pdf
Bibdoc 2024 - Ecologie du livre et creation de badge.pdf
 
PIE-A2-P 5- Supports stagiaires.pptx.pdf
PIE-A2-P 5- Supports stagiaires.pptx.pdfPIE-A2-P 5- Supports stagiaires.pptx.pdf
PIE-A2-P 5- Supports stagiaires.pptx.pdf
 
Faut-il avoir peur de la technique ? (G. Gay-Para)
Faut-il avoir peur de la technique ? (G. Gay-Para)Faut-il avoir peur de la technique ? (G. Gay-Para)
Faut-il avoir peur de la technique ? (G. Gay-Para)
 
Présentation - Initiatives - CECOSDA - OIF - Fact Checking.pptx
Présentation - Initiatives - CECOSDA - OIF - Fact Checking.pptxPrésentation - Initiatives - CECOSDA - OIF - Fact Checking.pptx
Présentation - Initiatives - CECOSDA - OIF - Fact Checking.pptx
 
Cours de Management des Systèmes d'information
Cours de Management des Systèmes d'informationCours de Management des Systèmes d'information
Cours de Management des Systèmes d'information
 
Bernard Réquichot.pptx Peintre français
Bernard Réquichot.pptx   Peintre françaisBernard Réquichot.pptx   Peintre français
Bernard Réquichot.pptx Peintre français
 
PIE-A2-P4-support stagiaires sept 22-validé.pdf
PIE-A2-P4-support stagiaires sept 22-validé.pdfPIE-A2-P4-support stagiaires sept 22-validé.pdf
PIE-A2-P4-support stagiaires sept 22-validé.pdf
 
Bibdoc 2024 - Les maillons de la chaine du livre face aux enjeux écologiques.pdf
Bibdoc 2024 - Les maillons de la chaine du livre face aux enjeux écologiques.pdfBibdoc 2024 - Les maillons de la chaine du livre face aux enjeux écologiques.pdf
Bibdoc 2024 - Les maillons de la chaine du livre face aux enjeux écologiques.pdf
 
DIGNITAS INFINITA - DIGNITÉ HUMAINE; déclaration du dicastère .pptx
DIGNITAS INFINITA - DIGNITÉ HUMAINE; déclaration du dicastère .pptxDIGNITAS INFINITA - DIGNITÉ HUMAINE; déclaration du dicastère .pptx
DIGNITAS INFINITA - DIGNITÉ HUMAINE; déclaration du dicastère .pptx
 

Uml Cas Utilisation introduction

  • 1. Analyse et Conception avec UML Les diagrammes de cas d’utilisation blay@unice.fr www.polytech.unice.fr/~blay IUT Nice-Sophia Antipolis Mars 2011 Site web du module : http://anubis.polytech.unice.fr/iut/ 1
  • 2. Bibliographie Principalement : • cours IBM : Writing Good Use Cases (2006) •Voir sur le site web les autres cours. •Méthodologie en Ingénierie du logiciel, Modélisation Orientée objet, M.Grimaldi – janvier 2010 2
  • 3. Dict. U.C. Process. Compléments. Plan du cours  Utilisation d’un dictionnaire du domaine  Des cas d’utilisations (Use-cases/UC)  Acteurs, use-cases, system UML  Processus de construction des Uses-case  Compléments 3 /98
  • 4. Dict. U.C. Process. Compléments. UML au travail : Système d’inscriptions L’université ESU désire automatiser son système d’inscription ‣ Le chef du service des inscriptions établit le programme des cours pour un semestre ‣ Un cours peut être offert plusieurs fois ‣ Les étudiants doivent sélectionner 4 cours primaires et 2 cours secondaires dans le catalogue des cours proposés ‣ Dès qu’un étudiant s’est inscrit pour un semestre, le système de facturation est notifié ‣ Les étudiants peuvent utiliser le système pour modifier leurs choix pendant une certaine période de temps après leur inscription ‣ Les enseignants utilisent le système pour consulter leur emploi du temps (tableau d’activités en fonction des cours qui tournent) ‣ Les utilisateurs du système d’inscription reçoivent des mots de passe qui sont nécessaire à la procédure d’identification 4 /98
  • 5. Dict. U.C. Process. Compléments. UML au travail : Guichet automatique de banque Le guichet automatique d’une banque (GAB) offre les services suivants : Distribution d’argent à partir d’une carte de la banque ou d’une carte Visa. Consultation de solde de compte, dépôt en numéraire et dépôt de chèques pour les clients de la banque porteurs d’une carte de la banque. De plus, Toutes les transactions sont sécurisées. Il est parfois nécessaire de recharger le distributeur, . 5 /82 Voir UML2 par la pratique
  • 6. Dict. U.C. Process. Compléments. UML au travail : Une galerie d’art (1) Nous voulons informatiser une galerie d'art, par laquelle nous souhaitons vendre des oeuvres d'arts à des clients. Les paiements doivent être sécurisés en utilisant le système de paiement externe “chaimoinscheir”. (2) Les oeuvres et les artistes sont gérés par les administrateurs 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 catégorie. (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. 6 /82
  • 7. Dict. U.C. Process. Compléments. Intérêt du dictionnaire  Outil de dialogue  Informel, évolutif, simple a réaliser  Etablir et figer la terminologie – Permet de figer la terminologie du domaine d'application. – Constitue le point d'entrée et le référentiel initial de l'application ou du système. Homonymie Synonymie Polysémie 7 /98
  • 8. Dict. U.C. Process. Compléments. UML au travail : Système d’inscriptions L’université ESU désire automatiser son système d’inscription ‣ Le chef du service des inscriptions établit le programme des cours pour un semestre ‣ Un cours peut être offert plusieurs fois ‣ Les étudiants doivent sélectionner 4 cours primaires et 2 cours secondaires dans le catalogue des cours proposés ‣ Dès qu’un étudiant s’est inscrit pour un semestre, le système de facturation est notifié ‣ Les étudiants peuvent utiliser le système pour modifier leurs choix pendant une certaine période de temps après leur inscription ‣ Les enseignants utilisent le système pour consulter leur emploi du temps (tableau d’activités en fonction des cours qui tournent) ‣ Les utilisateurs du système d’inscription reçoivent des mots de passe qui sont nécessaire à la procédure d’identification 8 /98
  • 9. Dict. U.C. Process. Compléments. Les diagrammes de cas d ’utilisation Une des notations d ’UML (use-cases) But : ‣ définir le système du point de vue des utilisateurs ‣ définir les limites précises du système Notation très simple, compréhensible par tous Permet de structurer : ‣ les besoins (cahier des charges) ‣ le reste du développement ‣ la progression d ’un cycle en spirale Les cas d'utilisation sont nommés en utilisant la terminologie décrite dans le dictionnaire Jean-Marie Favre 9 /98
  • 10. Dict. U.C. Process. Compléments. Les diagrammes de cas d ’utilisation Une Notation très simple, compréhensible par tous cf. http://linformalibre.f2lt.fr/index.php?title=Comprendre_Joomla_%C3%A0_l%27aide_d%27UML 10 /98
  • 11. Dict. U.C. ✓Conclusion Process. Compléments. Bénéfices des use-cases Organisent les exigences d’un point de vue utilisateur Définissent les exigences du système comme des séquences logiques, Permettent de vérifier que toutes les exigences sont capturées et qu’elles correspondent à ce qu’attend le demandeur. Facilitent l’adéquation des demandeurs ‣ mais aussi des cas de tests, la documentation et la réutilisation des exigences. 11 /98
  • 12. Dict. U.C. ✓Conclusion Process. Compléments. Des use-cases, pour qui? Demandeurs (décrire et approuver) Utilisateurs (comprendre) Architectes logiciels (identification des fonctions) Concepteurs et développeurs Testeurs (identifier les tests) Managers (Planifier) Rédacteurs de documentation (prendre un point de vue utilisateur) 12 /98
  • 13. Dict. U.C. ✓Conclusion Process. Compléments. Dev. logiciel dirigé par les use-cases 13 /98
  • 14. Dict. U.C. Process. Compléments. Processus d’écriture des UC Trouver les acteurs Etudiant Catalogue des cours Enregistrer des cours Brève description: Ce UC permet à un étudiant Trouver les UC d’enregistrer ses cours... Seuls les formations bien construites sont acceptés. Le catalogue des cours est notifié des inscriptions. Description de «Enregistrer des cours» Décrire les UC -Flot d’évènements -Pas à pas Specification de «Enregistrer des cours» Détailler les UC - Flot d’évènements détaillés - Exigences spéciales - Pre/Postconditions 14 /98
  • 15. Dict. U.C. Process. Compléments. Processus d’écriture des UC Trouver les acteurs Important Trouver les UC C’est un processus itératif Décrire les UC Détailler les UC 15 /98
  • 16. Dict. U.C. Process. ✓1. acteurs Compléments. Processus d’écriture des UC Trouver les acteurs Nommer et brièvement décrire les Trouver les UC acteurs trouvés Décrire les UC Détailler les UC 16 /98
  • 17. Dict. U.C. ✓acteurs Process. Compléments. Définir le périmètre du SI : Acteurs Définir les acteurs externes ‣ physiques et logiques ‣ rôle et entité concrète « Un acteur est une personne ou une chose qui va interagir avec le système » 17 /98
  • 18. Dict. U.C. ✓acteurs Process. Compléments. Définir le périmètre du SI : Acteurs Définir les acteurs externes ‣ physiques et logiques ‣ rôle et entité concrète « Un acteur est une personne ou une chose qui va interagir avec le système » Etudiant 17 /98
  • 19. Dict. U.C. ✓acteurs Process. Compléments. Définir le périmètre du SI : Acteurs Définir les acteurs externes ‣ physiques et logiques ‣ rôle et entité concrète « Un acteur est une personne ou une chose qui va interagir avec le système » Etudiant Chef du Service des inscriptions 17 /98
  • 20. Dict. U.C. ✓acteurs Process. Compléments. Définir le périmètre du SI : Acteurs Définir les acteurs externes ‣ physiques et logiques ‣ rôle et entité concrète « Un acteur est une personne ou une chose qui va interagir avec le système » Système Enseignant Etudiant de facturation Chef du Service des inscriptions 17 /98
  • 21. Dict. U.C. ✓acteurs Process. Compléments. Client Acteurs Un Acteur = ‣ élément externe qui interagit avec le système ‣ rôle qu’un utilisateur joue par rapport au système ex: un enseignant, un guichetier Une même personne peut jouer plusieurs rôles ex: Marie est enseignante et étudiante Maurice est directeur mais peut faire le guichetier Plusieurs personnes peuvent jouer un même rôle ex: Paul et Pierre sont deux clients Un acteur n’est pas forcément un être humain ex: un distributeur de billet peut être vu comme un acteur; un gestionnaire de mot de passes 18 /98
  • 22. Dict. U.C. ✓acteurs Process. Compléments. Description des acteurs Client Pour chaque acteur : ‣ choisir un identificateur représentatif de son rôle (un bon nom décrit la responsabilité des acteurs) ‣ donner une brève description textuelle Un guichetier est un employé de la banque chargé de faire l’interface entre le système informatique et les clients qu’il reçoit au comptoir. Le guichetier peut réaliser les opérations courantes : création d ’un Guichetier compte, dépôt et retrait d ’argent, etc. Jean-Marie Favre 19 /98
  • 23. Dict. U.C. Process. ✓1. acteurs Compléments. Trouver les acteurs Qui ou quoi utilise le système? Qui ou quoi obtient de l'information de ce système ? Qui ou quoi fournit des informations au système ? Où dans la compagnie le système est-il utilisé ? Qui ou quoi supporte et maintient le système? Quels autres systèmes utilisent ce système? 20 /98
  • 24. Dict. U.C. Process. Compléments. UML au travail : Système d’inscriptions L’université ESU désire automatiser son système d’inscription ‣ Le chef du service des inscriptions établit le programme des cours pour un semestre ‣ Un cours peut être offert plusieurs fois ‣ Les étudiants doivent sélectionner 4 cours primaires et 2 cours secondaires dans le catalogue des cours proposés ‣ Dès qu’un étudiant s’est inscrit pour un semestre, le système de facturation est notifié ‣ Les étudiants peuvent utiliser le système pour modifier leurs choix pendant une certaine période de temps après leur inscription ‣ Les enseignants utilisent le système pour consulter leur emploi du temps (tableau d’activités en fonction des cours qui tournent) ‣ Les utilisateurs du système d’inscription reçoivent des mots de passe qui sont nécessaire à la procédure d’identification 21 /98
  • 25. Dict. U.C. Process. Compléments. UML au travail : Système d’inscriptions L’université ESU désire automatiser son système d’inscription ‣ Le chef du service des inscriptions établit le programme des cours pour un semestre ‣ Un cours peut être offert plusieurs fois ‣ Les étudiants doivent sélectionner 4 cours primaires et 2 cours secondaires dans le catalogue des cours proposés Dès qu’un étudiant s’est inscrit pour un semestre, le système de facturation est notifié ‣ Les étudiants peuvent utiliser le système pour modifier leurs choix pendant une certaine période de temps après leur inscription ‣Les enseignants utilisent le système pour consulter leur emploi du temps (tableau d’activités en fonction des cours qui tournent) ‣ Les utilisateurs du système d’inscription reçoivent des mots de passe qui sont nécessaire à la procédure d’identification 22 /98
  • 26. Dict. U.C. Process. ✓1. acteurs Compléments. Décrire les acteurs Student : A person who signs up for a course Student - Qu'est-ce ou que l'acteur représente - Pourquoi l'acteur est nécessaire - Quel est l’intérêt de l’acteur dans le UC ? Professor Registrar 23 /98
  • 27. Dict. U.C. Process. ✓1. acteurs Compléments. Décrire les acteurs Student : A person who signs up for a course Student - Qu'est-ce ou que l'acteur représente - Pourquoi l'acteur est nécessaire - Quel est l’intérêt de l’acteur dans le UC ? Professor Registrar Course Catalog System 23 /98
  • 28. Dict. U.C. Process. Compléments. UML au travail : Guichet automatique de banque Le guichet automatique d’une banque (GAB) offre les services suivants : Distribution d’argent à partir d’une carte de la banque ou d’une carte Visa. Consultation de solde de compte, dépôt en numéraire et dépôt de chèques pour les clients de la banque porteurs d’une carte de la banque. De plus, Toutes les transactions sont sécurisées. Il est parfois nécessaire de recharger le distributeur, . 24 /98 Voir UML2 par la pratique
  • 29. Identification des acteurs Quelles sont les entités externes qui interagissent avec le GAB ? • Porteur de carte Phrase 1 • Carte de crédit • Lecteur de carte • Distributeur de billets Phrase 2 • Porteur de carte client de la banque Phrase 3 Le système est sécurisé (par quoi?) 1. Le système d’autorisation 2. Le système d’information de la banque Phrase 4 • Opérateur de maintenance
  • 30. Dict. U.C. Process. ✓1. acteurs Compléments. UML au travail : Une galerie d’art (1) Nous voulons informatiser une galerie d'art, par laquelle nous souhaitons vendre des oeuvres d'arts à des clients. Les paiements doivent être sécurisés en utilisant le système de paiement externe “chaimoinscheir”. (2) Les oeuvres et les artistes sont gérés par les administrateurs 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 catégorie. (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. 26 /82
  • 31. Dict. U.C. Process. ✓1. acteurs Compléments. Diagramme de contexte 27 /98
  • 32. Le GAB est un système fondamentalement mono-utilisateur: à tout instant, il n’y a qu’une instance de chaque acteur (au maximum) connecté au système! Pour simplifier, nous utiliserons le terme Client banque pour l’acteur Porteur de carte client de la banque.
  • 34. Les acteurs humains Client banque et Porteur de carte sont mutuellement exclusifs, ce qui n’est pas implicite d’après les multiplicités des associations. On peut ajouter une contrainte {XOR} (ou exclusif)
  • 35. Une autre solution, un peu plus élaborée, consiste à considérer que Client banque est une spécialisation de Porteur de carte (héritage entre acteurs)
  • 36. Dict. U.C. Process. ✓1. acteurs Compléments. UML au travail : Une galerie d’art (1) Nous voulons informatiser une galerie d'art, par laquelle nous souhaitons vendre des oeuvres d'arts à des clients. Les paiements doivent être sécurisés en utilisant le système de paiement externe “chaimoinscheir”. (2) Les oeuvres et les artistes sont gérés par les administrateurs 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 catégorie. (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. 32 /82
  • 37. Dict. U.C. Process. ✓2. U.C. Compléments. Processus d’écriture des UC Trouver les acteurs Nommer et brièvement décrire les UC trouvés Trouver les UC Créer un diagramme de UC Etablir la plus- value métier et les Décrire les UC risques techniques des UC Détailler les UC 33 /98
  • 38. Dict. U.C. ✓cas d’utilisat. Process. Compléments. Cas d’utilisation (UC) 34 /98
  • 39. Dict. U.C. ✓cas d’utilisat. Process. Compléments. Cas d’utilisation (UC) Un cas d’utilisation est un motif cohérent de comportement ‣ réalisé par le système. 34 /98
  • 40. Dict. U.C. ✓cas d’utilisat. Process. Compléments. Cas d’utilisation (UC) Un cas d’utilisation est un motif cohérent de comportement ‣ réalisé par le système. Chaque cas d’utilisation est décrit par une séquence d’actions connectées, effectuées par un dialogue entre des acteurs et le système ‣ qui produit un résultat observable ‣ d’intérêt pour un ou plusieurs acteurs du système. ‣ ne révèle pas la structure interne du système. 34 /98
  • 41. Dict. U.C. ✓cas d’utilisat. Process. Compléments. Cas d’utilisation (UC) Un cas d’utilisation est un motif cohérent de comportement ‣ réalisé par le système. Chaque cas d’utilisation est décrit par une séquence d’actions connectées, effectuées par un dialogue entre des acteurs et le système ‣ qui produit un résultat observable ‣ d’intérêt pour un ou plusieurs acteurs du système. ‣ ne révèle pas la structure interne du système. Chaque cas d’utilisation est un flot complet et faisant du sens du point de vue d’un acteur particulier. 34 /98
  • 42. Dict. U.C. Process. ✓2. U.C. Compléments. Trouver les use-cases Quels sont les objectifs de chaque acteur? ‣ Pourquoi l'acteur utiliserait-il le système? ‣ Est-ce que l'acteur créera, stockera, modifiera, supprimera ou lira des données dans le système? Si oui, pourquoi? ‣ Est-ce que l'acteur nécessite d'informer le système sur des événements externes ou des changements? ‣ Est-ce que l'acteur doit être informé de certains événements dans le système? Quels buts dois-je atteindre en utilisant le système? Acteur 35 /98
  • 43. Dict. U.C. Process. Compléments. UML au travail : Système d’inscriptions L’université ESU désire automatiser son système d’inscription ‣ Le chef du service des inscriptions établit le programme des cours pour un semestre ‣ Un cours peut être offert plusieurs fois ‣ Les étudiants doivent sélectionner 4 cours primaires et 2 cours secondaires dans le catalogue des cours proposés Dès qu’un étudiant s’est inscrit pour un semestre, le système de facturation est notifié ‣ Les étudiants peuvent utiliser le système pour modifier leurs choix pendant une certaine période de temps après leur inscription ‣Les enseignants utilisent le système pour consulter leur emploi du temps (tableau d’activités en fonction des cours qui tournent) ‣ Les utilisateurs du système d’inscription reçoivent des mots de passe qui sont nécessaire à la procédure d’identification 36 /98
  • 44. Dict. U.C. ✓cas d’utilisat. Process. Compléments. UML au travail : Système d’inscriptions L’université ESU désire automatiser son système d’inscription ‣ Le chef du service des inscriptions établit le programme des cours pour un semestre ‣ Un cours peut être offert plusieurs fois Les étudiants doivent sélectionner 4 cours primaires et 2 cours secondaires dans le catalogue des cours proposés Dès qu’un étudiant s’est inscrit pour un semestre, le système de facturation est notifié Les étudiants peuvent utiliser le système pour modifier leurs choix pendant une certaine période de temps après leur inscription Les enseignants utilisent le système pour consulter leur emploi du temps (tableau d’activités en fonction des cours qui tournent) ‣ Les utilisateurs du système d’inscription reçoivent des mots de passe qui sont nécessaire à la procédure d’identification 37 /98
  • 45. Dict. U.C. ✓cas d’utilisat. Process. Compléments. Nommer un use-case  Enregistrer des Cours ?  Enregistrement de cours  Cours  Utiliser le système d’enregistrement  Accuser réception des cours 38 /98
  • 46. Dict. U.C. ✓cas d’utilisat. Process. Compléments. Nommer un use-case Le nom doit être unique, intuitif et auto-explicatif  Enregistrer des Cours ?  Enregistrement de cours  Cours  Utiliser le système d’enregistrement  Accuser réception des cours 38 /98
  • 47. Dict. U.C. ✓cas d’utilisat. Process. Compléments. Nommer un use-case Le nom doit être unique, intuitif et auto-explicatif Il doit commencer par un verbe et utiliser une simple combinaison verbe-nom  Enregistrer des Cours ?  Enregistrement de cours  Cours  Utiliser le système d’enregistrement  Accuser réception des cours 38 /98
  • 48. Dict. U.C. ✓cas d’utilisat. Process. Compléments. Nommer un use-case Le nom doit être unique, intuitif et auto-explicatif Il doit commencer par un verbe et utiliser une simple combinaison verbe-nom Définir clairement et sans ambiguïté le gain des résultats observables  Enregistrer des Cours ?  Enregistrement de cours  Cours  Utiliser le système d’enregistrement  Accuser réception des cours 38 /98
  • 49. Dict. U.C. ✓cas d’utilisat. Process. Compléments. Nommer un use-case Le nom doit être unique, intuitif et auto-explicatif Il doit commencer par un verbe et utiliser une simple combinaison verbe-nom Définir clairement et sans ambiguïté le gain des résultats observables Placez vous du point de vue de l'acteur qui déclenche le cas d'utilisation  Enregistrer des Cours ?  Enregistrement de cours  Cours  Utiliser le système d’enregistrement  Accuser réception des cours 38 /98
  • 50. Dict. U.C. ✓cas d’utilisat. Process. Compléments. Nommer un use-case Le nom doit être unique, intuitif et auto-explicatif Il doit commencer par un verbe et utiliser une simple combinaison verbe-nom Définir clairement et sans ambiguïté le gain des résultats observables Placez vous du point de vue de l'acteur qui déclenche le cas d'utilisation Décrire le comportement fournit par le cas d'utilisation  Enregistrer des Cours ?  Enregistrement de cours  Cours  Utiliser le système d’enregistrement  Accuser réception des cours 38 /98
  • 51. Dict. U.C. ✓cas d’utilisat. Process. Compléments. Diagramme des UC Objectif : visualiser les relations entre acteurs et cas d’utilisation (communication) Enregistrer ses cours Consulter tableau de service Etudiant Enseignant S’inscrire Système de Etablir le facturation Programme Scolaire Chef du Service Des Inscriptions 39 /98
  • 52. Dict. U.C. ✓cas d’utilisat. Process. Compléments. Communication : un dialogue L’étudiant se connecte au système Le système approuve la connexion. L’étudiant requiert des informations Enregistrer Etudiant ses cours Catalogue des cours Le système affiche la liste des cours Le système transmet la requête L’étudiant selectionne les cours Le Catalogue des cours retourne des informations sur les cours. Le système affiche l’edt approuvé 40 /98
  • 53. Dict. U.C. ✓cas d’utilisat. Process. Compléments. Diagramme des cas d’utilisation Porteur de carte: Retirer de l’argent Client banque: Retirer de l’argent (bien sûr!) Acteurs Consulter le solde de son compte courant primaires Déposer du numéraire Déposer de l’argent (numéraire ou chèque) Opérateur de maintenance Recharger le distributeur Maintenir l’état opérationnel Système d’autorisation (Sys.Auto) Acteurs Néant secondaires Système d’information de la banque (SI banque) Néant /82
  • 54. Dict. U.C. ✓cas d’utilisat. Process. Compléments. Diagramme des cas d’utilisation /82
  • 55. Dict. U.C. ✓cas d’utilisat. Process. Compléments. Diagramme des cas d’utilisation amélioration /82
  • 56. Dict. U.C. ✓cas d’utilisat. Process. Compléments. UML au travail : Une galerie d’art (1) Nous voulons informatiser une galerie d'art, par laquelle nous souhaitons vendre des oeuvres d'arts à des clients. Les paiements doivent être sécurisés en utilisant le système de paiement externe “chaimoinscheir”. (2) Les oeuvres et les artistes sont gérés par les administrateurs 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 catégorie. (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. 44 /82
  • 57. Dict. U.C. ✓Système Process. Compléments. Le système Le système est un ensemble de cas d’utilisation Le système contient : ‣ les cas d ’utilisation, ‣ mais pas les acteurs. Un modèle de cas d ’utilisation permet de définir : ‣ les fonctions essentielles du système, ‣ les limites du système, ‣ le système par rapport à son environnement. 45 /98
  • 58. Dict. U.C. ✓Système Process. Compléments. System Frontière du système Etablir un emploi du temps Etudiant Enregistrer ses cours Catalogue S’inscrire des cours Demander Système de un tableau de facturation service Système de Enseignant facturation Maintenir le Programme Chef du Service 46 /98 Des Inscriptions
  • 59. Dict. U.C. ✓Desc. Process. Compléments. Description succincte d’un UC Sommaire d'identification : ■ Titre ■ Résumé ■ Acteurs ■ Date de création ■ Date de mise à jour ■ Version ■ Responsable 47 /98
  • 60. Dict. U.C. ✓Desc. Process. Compléments. Description textuelle du cas d'utilisation: « RETIRER DE L’ARGENT »    Sommaire d'identification Titre : Retirer de l'argent Résumé : ce cas d'utilisation permet à un porteur de carte, qui n'est pas client de la banque, de retirer de l'argent, si son crédit hebdomadaire le permet. Acteurs : Porteur de carte non client (principal), Sys. Auto. (secondaire). Date de création : 03/01/07 Date de mise à jour : 09/02/07 Version : 1.0 Responsable : Pierre DUMONT /82
  • 61. Dict. U.C. Process. ✓2. U.C. Compléments. Bilan sur les UC 49 /98
  • 62. Dict. U.C. Process. ✓2. U.C. Compléments. Faire le point sur les acteurs Est-ce chacun des acteurs est impliqué dans au moins un cas d'utilisation? Est-ce que des acteurs jouent des rôles similaires du point de vue du système? Dans l'affirmative, les fusionner en un seul acteur. «Avez-vous trouvé tous les acteurs?» «Avez-vous pris en compte et modélisé tous les rôles dans l'environnement du système?» 50 /98
  • 63. Dict. U.C. Process. ✓2. U.C. Compléments. Faire le point sur les Use-cases(1) Le modèle de cas d'utilisation présente le comportement du système, il est facile de comprendre ce que le système fait en passant en revue le modèle. Tous les cas d'utilisation ont été identifiés; les cas d'utilisation représentent l’ensemble des comportements requis. Le modèle de cas d'utilisation ne contient pas de comportement superflu; A chaque cas d'utilisation correspond une exigence fonctionnelle. 51 /98
  • 64. Dict. U.C. Process. ✓2. U.C. Compléments. Faire le point sur les Use-cases(2) Le cas d'utilisation ont des noms uniques, intuitifs, et des noms explicites de sorte qu'ils ne peuvent pas être confondus à un stade ultérieur. Sinon, changer leurs noms. Les demandeurs et les utilisateurs comprennent les noms et les descriptions des cas d'utilisation. La brève description donne une image fidèle du cas d'utilisation. Chaque cas d'utilisation implique au moins un acteur. Les cas d'utilisation n’ont pas de comportements ou des flux d'événements très similaires. 52 /98
  • 65. Dict. U.C. Process. ✓2. U.C. Compléments. Évaluer la valeur commerciale et les risques Pour chaque cas d'utilisation identifié, obtenir un consensus avec les parties prenantes quant à sa valeur commerciale et les risques techniques ‣ L’équipe métier décide ce qui a de l’importance et ce qui n’en a pas. ‣ L'équipe technique décide de ce qui est risqué - Degré de complexité de dev. pressentie, intégration, indéterminisme. Utilisez : haute, moyen, faible En déduire les use cases à détailler en premier 53 /98
  • 66. Dict. U.C. Process. ✓3.décrire. Compléments. Processus d’écriture des UC Trouver les acteurs Décrire les flots d’évènements (bref) Trouver les UC Saisir les scenarii Collecter les exigences additionnelles Décrire les UC Détailler les UC 54 /98
  • 67. Dict. U.C. Process. ✓3.décrire. Compléments. Décrire une UC Décrire chaque étape du UC par des phrases courtes, organisées séquentiellement. Use Case Name Brief Description Basic Flow 1. First step 2. Second step 3. Third step Alternative Flows 1. Alternative flow 1 2. Alternative flow 2 3. Alternative flow 3 55 /98
  • 68. Dict. U.C. Process. ✓3.décrire. Compléments. Décrire une UC Décrire chaque étape du UC par des phrases courtes, organisées séquentiellement. Use Case Name Brief Description Structurer Basic Flow le flot de Numéroter base en 1. First step et nommer 2. Second step étapes les étapes. 3. Third step majeures Alternative Flows 1. Alternative flow 1 Identifier 2. Alternative flow 2 les flots 3. Alternative flow 3 alternatifs. 55 /98
  • 69. Dict. U.C. Process. ✓3.décrire. Compléments. Pas à pas : enregistrer ses cours Basic Flow ‣ 1. L’étudiant se connecte. ‣ 2. L’étudiant choisit d’enregistrer ces choix de cours. ‣ 3. L’étudiant obtient des informations sur les cours. ‣ 4. L’étudiant sélectionne les cours. ‣ 5. L’étudiant soumet ses choix. D’autres ‣ 6. Le système valide les choix. alternatives? Alternative Flows ‣ A1. Etudiant non identifié ‣ A2. L’étudiant quitte l’application avant soumission ‣ A3. Les choix ne sont pas valides ‣ A4. Le catalogue des Cours est non accessible. 56 /98
  • 70. Dict. U.C. Process. ✓3.décrire. Compléments. Décrire les UC Un processus itératif : ne pas tout détailler, pas trop tôt Un processus de découverte : Décrire vous aide à découvrir ce que vous ne connaissez pas. Une brève description sert de point de départ. Un processus d’évaluation : UC trop petit ou trop gros ? partagé? 57 /98
  • 71. Dict. U.C. Process. ✓3.décrire. Compléments. Exigences additionnelles Collecter les exigences système qui ne peuvent pas être allouées à des UC spécifiques dans des documents additionnels. 58 /98
  • 72. Dict. U.C. Process. ✓4.détailler Compléments. Processus d’écriture des UC Trouver les acteurs Détailler les flots d'événements Structurer les flots Trouver les UC d'événements Spécifier les propriétés additionnelles Décrire les UC Détailler les UC 59 /98
  • 73. Dict. U.C. ✓Système Process. ✓4.détailler Compléments. Description détaillée d’un UC ■ Description des scénarios: ■ Préconditions ■ Scénario Nominal ■ Flots alternatifs ■ Flots d'erreur ■ Postconditions ■ Exigences non fonctionnelles ■ Besoins d'IHM 60 /98
  • 74. Dict. U.C. Process. ✓4.détailler Compléments. Préconditions  Décrire l'état dans lequel doit être le système avant que le UC puisse commencer.  Simples déclarations qui définissent l'état du système, exprimées comme ses conditions qui doivent être remplies  Il ne faut jamais se référer à d'autres UC qui doivent être effectuées avant cet UC  Devraient être énoncées clairement et devraient être facilement vérifiables  Facultatif: Utilisez uniquement si nécessaire pour clarifier  Exemple  UC «Inscription à des cours»  Préconditions  La liste des offres de cours pour le semestre a été créée et est disponible au service d’inscription.  L'élève a ouvert une session d’inscription dans le système 61 /98
  • 75. Dict. U.C. ✓Système Process. ✓4.détailler Compléments. Description détaillée d’un UC ■ Description des scénarios: ■ Préconditions ■ Scénario Nominal ■ Flots alternatifs ■ Flots d'erreur ■ Postconditions ■ Exigences non fonctionnelles ■ Besoins d'IHM 62 /98
  • 76. Dict. U.C. Process. ✓4.détailler Compléments. Détailler le flot de base Register for Courses 1.1 Basic Flow 1. Log On. This use case starts when someone accesses the Décrire les étapes. Course Registration System and chooses to register for courses. The system validates that the person accessing the system is an authorized student. 2. Select “Create a Schedule ”. The system displays the functions available to the <Acteur> student. The student selects “Create a Schedule ”. 3. Obtain Course Information. <fait> The system retrieves a list of available course offerings from the Course Catalog System and displays the list to the student .The student can search the list by department, professor, or topic to obtain the desired course information . <Système> 4. Select Courses. The student selects four primary course offerings and <fait> two alternate course offerings from the list of available offerings course offerings. 63 /98
  • 77. Dict. U.C. Process. ✓4.détailler Compléments. Formulation  Utilisez la voix active  Dire: “Le Professeur attribue des notes à chaque étudiant”  Au lieu de : “Quand le Professeur a attribué les notes”  Dire ce qui déclenche l’étape  Dire: “Le UC commence quand le Prof. choisit de donner une note.”  Au lieu de : “Le UC commence quand le Prof. décide de ....  Dire qui fait quoi (utiliser le nom d'acteur)  Dire: “L'étudiant choisit ... …”  Au lieu de: "L'utilisateur choisit ...…"  Dire: “Le Système valide …”  Au lieu de: "Le choix est validé …" 64 /98
  • 78. Description textuelle du cas d'utilisation: « RETIRER DE L’ARGENT »    Description des scénarios Pré conditions •La caisse du GAB est alimentée (il reste au moins un billet !). •Aucune carte ne se trouve déjà coincée dans le lecteur. Scénario nominal 1. Le porteur de carte introduit sa carte dans le lecteur de cartes du GAB. 2. Le GAB vérifie que la carte introduite est bien une carte bancaire.
  • 79. 3. Le GAB demande au porteur de carte de saisir son code d'identification. 4. Le porteur de carte saisit son code d'identification. 5. Le GAB compare le code d'identification avec celui qui est codé sur la puce de la carte. 6. Le GAB demande une autorisation au système d'autorisation. 7. Le système d'autorisation donne son accord et indique le solde hebdomadaire. 8. Le GAB demande au porteur de carte de saisir le montant désiré du retrait. 9. Le porteur de carte saisit le montant désiré du retrait. 10. Le GAB contrôle le montant demandé par rapport au solde hebdomadaire. 11. Le GAB demande au porteur de carte s'il veut un ticket. 12. Le porteur de carte demande un ticket. 13. Le GAB rend sa carte au porteur de carte. 14. Le porteur de carte reprend sa carte. 15. Le GAB délivre les billets et un ticket. 16. Le porteur de carte prend les billets et le ticket. 17. Le GAB enregistre la transaction de retrait.
  • 80. Description textuelle du cas d'utilisation: RETIRER DE L’ARGENT  (Représentation de C.Larman) Une autre présentation dite de Larman consiste à séparer les actions des acteurs et du système en deux colonnes: Action d’acteur Action Système 1. Le porteur de carte introduit sa 2. Le GAB vérifie que la carte carte dans le lecteur de cartes du introduite est bien une carte GAB. bancaire. 3. Le GAB demande au porteur de carte de saisir son code d'identification. 4. Le porteur de carte saisit son 5. Le GAB compare le code code d'identification. d’identification avec celui qui est codé sur la puce de la carte. 6. Le GAB demande une autorisation au système d'autorisation global.
  • 81. 7. Le système donne son accord et 8. Le GAB de mande au porteur de indique le solde carte de saisir le montant désiré hebdomadaire. du retrait. 9. Le porteur de carte saisie le 10. Le GAB contrôle le montant montant désiré demandé par rapport au solde hebdomadaire 11. Le GAB demande au porteur de carte s’il veut un ticket 12. Le porteur de carte demande 13. Le GAB rend sa carte au porteur un ticket. de carte. 14. Le porteur de carte reprend sa 15. Le GAB délivre des billets et un carte ticket. 16. Le porteur de carte prend les 17. Le GAB enregistre la transaction billets et le ticket. de retrait.
  • 82. Dict. U.C. ✓Système Process. ✓4.détailler Compléments. Description détaillée d’un UC ■ Description des scénarios: ■ Préconditions ■ Scénario Nominal ■ Flots alternatifs ■ Flots d'erreur ■ Postconditions ■ Exigences non fonctionnelles ■ Besoins d'IHM 69 /98
  • 83. Enchaînements alternatifs* Al : code d'identification provisoirement erroné L'enchaînement Al démarre au point 5 du scénario nominal. 6. Le GAB indique au porteur de carte que le code est erroné, pour la première ou deuxième fois. 7. Le GAB enregistre l'échec sur la carte. Le scénario nominal reprend au point 3. A2 : montant demandé supérieur au solde hebdomadaire L'enchaînement A2 démarre au point 10 du scénario nominal. 11. Le GAB indique au porteur de carte que le montant demandé est supérieur au solde hebdomadaire. Le scénario nominal reprend au point 8. * Nous distinguons les enchaînements alternatifs (Ax) qui reprennent ensuite à une étape du scénario nominal des enchaînements d'erreur (Ey) qui terminent brutalement le cas d'utilisation en échec. L'objectif de l'acteur principal est donc atteint par les scénarios nominaux et alternatifs mais pas par ceux d'erreur.
  • 84. A3 : ticket refusé L'enchaînement A3 démarre au point 11 du scénario nominal. 12. Le porteur de carte refuse le ticket. 13. Le GAB rend sa carte au porteur de carte. 14. Le porteur de carte reprend sa carte. 15. Le GAB délivre les billets. 16. Le porteur de carte prend les billets. 17. Le GAB enregistre la transaction de retrait. Enchaînements d’erreur El : carte non-valide L'enchaînement El démarre au point 2 du scénario nominal. 3. Le GAB indique au porteur que la carte n'est pas valide (illisible, périmée, etc.), la confisque ; le cas d'utilisation se termine en échec.
  • 85. E2 : code d'identification définitivement erroné L'enchaînement E2 démarre au point 5 du scénario nominal. 6. Le GAB indique au porteur de carte que le code est erroné, pour la troisième fois. 7. Le GAB confisque la carte. 8. Le système d'autorisation est informé ; le cas d'utilisation se termine en échec. E3 : retrait non autorisé L'enchaînement E3 démarre au point 6 du scénario nominal. 7. Le système d'autorisation interdit tout retrait. 8. Le GAB éjecte la carte ; le cas d'utilisation se termine en échec. E4 : carte non reprise L'enchaînement E4 démarre au point 13 du scénario nominal. 14. Au bout de 15 secondes, le GAB confisque la carte. 15. Le système d'autorisation est informé ; le cas d'utilisation se termine en échec.
  • 86. E5 : billets non pris L'enchaînement E5 démarre au point 15 du scénario nominal. 16. Au bout de 30 secondes, le GAB reprend les billets. 17. Le système d'autorisation est informé ; le cas d'utilisation se termine en échec. E6 : annulation de la transaction L'enchaînement E6 peut démarrer entre les points 4 et 12 du scénario nominal. 4 à 12. Le porteur de carte demande l'annulation de la transaction en cours. Le GAB éjecte la carte ; le cas d'utilisation se termine en échec. E4 : carte non reprise L'enchaînement E4 démarre au point 13 du scénario nominal. 14. Au bout de 15 secondes, le GAB confisque la carte. 15. Le système d'autorisation est informé ; le cas d'utilisation se termine en échec.
  • 87. Dict. U.C. Process. ✓3.décrire. Compléments. Décrire les flots d'événements Flot de base ‣ Quel événement déclenche le cas d'utilisation? ‣ Comment le cas d'utilisation se termine-t-il? ‣ Comment le cas d'utilisation répète-t-il certains comportements? Flots d’exceptions ‣ Y-a-t-il des situations facultatives dans le cas d'utilisation? ‣ Quel cas étrange pourrait se produire? Etape de ‣ Quelles variantes pourraient arriver? communication avec Qu’est-ce qui peut mal tourner? les utilisateurs ‣ ‣ Qu’est-ce qui ne peut pas se produire? ‣ Quels types de ressources peuvent être bloqués? Pas dans le détail 74 /98
  • 88. Dict. U.C. ✓Système Process. ✓4.détailler Compléments. Description détaillée d’un UC ■ Description des scénarios: ■ Préconditions ■ Scénario Nominal ■ Flots alternatifs ■ Flots d'erreur ■ Postconditions ■ Exigences non fonctionnelles ■ Besoins d'IHM 75 /98
  • 89. Dict. U.C. Process. ✓4.détailler Compléments. Postconditions  Décrire l'état dans lequel doit être le système à la fin du UC  Utiliser lorsque l'état du système est une condition préalable à un autre UC, ou lorsque les résultats possibles du UC ne sont pas évidents pour le lecteur  Il ne faut jamais se référer à d'autres UC qui doivent être effectués avant cet UC  Devraient être énoncées clairement et devraient être facilement vérifiables  Facultatif: Utilisez uniquement si nécessaire pour clarifier  Exemple on peut commencer par les postconditions avant même les  UC «Inscription à des cours» flots.  Postconditions  À la fin de ce cas d'utilisation, soit l'étudiant a été inscrit à des cours, soit l’inscription a échoué et aucune modification n'a été apportée à aux cours... 76 /98
  • 90. Dict. U.C. Process. ✓4.détailler Compléments. Exemple de description détaillée d’un UC Précondition : Le distributeur contient des billets, il est en attente d ’une opération, il n’est ni en panne, ni en maintenance Début : lorsqu ’un client introduit sa carte bancaire dans le Retirer DeLArgent distributeur. AuDistributeur Fin : lorsque la carte bancaire et les billets sont sortis. Postcondition : Si de l ’argent a pu être retiré la somme d’argent sur le compte est égale à la somme d ’argent qu’il y avait avant, moins le montant du retrait. Sinon la somme d ’argent sur le compte est la même qu’avant. Jean-Marie Favre 77 /98
  • 91. Dict. U.C. ✓Système Process. ✓4.détailler Compléments. Description détaillée d’un UC ■ Description des scénarios: ■ Préconditions ■ Scénario Nominal ■ Flots alternatifs ■ Flots d'erreur ■ Postconditions ■ Exigences non fonctionnelles ■ Besoins d'IHM 78 /98
  • 92. Dict. U.C. Process. ✓4.détailler Compléments. Exemple de description détaillée d’un UC Contraintes non fonctionnelles : (A) Performance : le système doit réagir dans un délai inférieur à 4 secondes, quelque soit l ’action de l ’utilisateur. Retirer DeLArgent AuDistributeur (B) Résistance aux pannes : si une coupure de courant ou une autre défaillance survient au cours du cas d ’utilisation, la transaction sera annulée, l ’argent ne sera pas distribué. Le système doit pouvoir redémarrer automatiquement dans un état cohérent et sans intervention humaine. (C) Résistance à la charge : le système doit pouvoir gérer plus de 1000 retraits d ’argent simultanément ... Jean-Marie Favre 79 /98
  • 93. Description textuelle du cas d'utilisation: « RETIRER DE L’ARGENT »  informations optionnelles Exigences non fonctionnelles Contraintes Descriptif Temps de réponse L’interface du GAB doit réagir en l’espace de 2 secondes au maximum. Une transaction nominale de retrait doit durer moins de 2 minutes Concurrence Non applicable (mono-utilisateur) Disponibilité Le GAB est accessible 7j/7, 24h/24 . L’absence de papier pour les tickets ne doit pas empêcher les retraits. Intégrité Les interface du GAB doivent être très robustes pour prévenir le vandalisme Confidentialité La vérification du code saisi doit être fiable à 10-6
  • 94. Dict. U.C. ✓Système Process. ✓4.détailler Compléments. Description détaillée d’un UC ■ Description des scénarios: ■ Préconditions ■ Scénario Nominal ■ Flots alternatifs ■ Flots d'erreur ■ Postconditions ■ Exigences non fonctionnelles ■ Besoins d'IHM 81 /98
  • 95. Description textuelle du cas d'utilisation: « RETIRER DE L’ARGENT »  informations optionnelles Besoins d’IHM Les dispositifs d'entrée/sortie à la disposition du porteur de carte doivent être : • Un lecteur de carte bancaire. • Un clavier numérique (pour saisir son code), avec des touches «validation », « correction » et « annulation ». • Un écran pour l'affichage des messages du GAB. • Des touches autour de l'écran pour sélectionner un montant de retrait parmi ceux qui sont proposés. • Un distributeur de billets. • Un distributeur de tickets.
  • 96. Dict. U.C. Process. ✓4.détailler Compléments. Faire le point sur les UC Les interactions entre le système et les acteurs sont claires Les séquence de communication sont conformes aux attentes de l'utilisateur Quand/comment les UC commencent/se terminent est clair Le flot de base de base donne un résultat observable pour un ou plusieurs acteurs 83 /98
  • 97. Dict. U.C. Process. ✓4.détailler Compléments. Quel niveau de détail? ✓ Saisir toutes les X Pas de détail des exigences pour tous les interfaces utilisateurs demandeurs X Pas de détail des processus internes non liés à une exigence ✓ Informations et événements X Pas les formats de données, ni les contrôles How much detail in a use case? Enough to satisfy all stakeholders that their interests (requirements) will be satisfied in the delivered system. 84 /98
  • 98. Dict. U.C. Process. Compléments. Ecrire des UC : Défis 1. Comment garder les UC précis et concis? 2. Comment traiter les interfaces utilisateur? 3. Comment traiter un flux quand a. Un acteur doit choisir parmi différentes options? b. Un acteur peut répéter des actions avant de passer à la suite? c. Les étapes ne sont pas nécessairement séquentielles? 4. Comment gérer le comportement conditionnelle dans les cas d'utilisation? 85 /98
  • 99. Dict. U.C. Process. Compléments. 1.Comment garder les UC précis et concis?(1) ✓ Capturer le vocabulaire commun dans un glossaire ➡ Définir les termes utilisés dans le projet dans le glossaire, pas dans les flux ➡ Aide à éviter les malentendus Use Case Glossary 5. Enter Customer Information Customer Details Information that uniquely identifies and The system prompts the Customer to provides contact information enter their Customer Details. for a customer located in the The Customer enters the Customer U.S.A. The information consists of Name, two address Details. lines, city, state, ZIP code, and The Customer creates the account. daytime phone number. Implementation 86 /98
  • 100. Dict. U.C. Process. Compléments. 1.Comment garder les UC précis et concis? (2) ✓ Visualiser le glossaire par un modèle du domaine Student 1 0..* Schedule 0..* 0..4 Course Offering 0..* 0..* 0..1 1 Part-time Student Full-time Student Professor Course 87/98
  • 101. Dict. U.C. Process. Compléments. Relations entre UC : Include, Extend, Specialize 88 /98
  • 102. Dict. U.C. Process. Compléments. Relations entre UC : Include, Extend, Specialize Au fur et à mesure que les cas d’utilisation sont documentés, des relations peuvent apparaître ‣ Une relation include : utilisation systématique ‣ Une relation extend dénote un comportement optionnel 88 /98
  • 103. Dict. U.C. Process. Compléments. Extends Les deux UC sont indépendants. Permettre au client de consulter son solde avant de saisir le montant : extension optionnelle. Flot enrichi 8. Le GAB demande au client de saisir le montant Point d’extension : Vérification du solde 9. Le client saisit le montant désiré de retrait 89 /98
  • 104. La relation <<include>> ou <<uses>>
  • 105. La relation <<include>> ou <<uses>> La relation d’include a pour seul objectif de factoriser une partie de la description d’un cas d’utilisation qui est commune à d’autres cas d’utilisation.
  • 106. La relation <<include>> ou <<uses>> La relation d’include a pour seul objectif de factoriser une partie de la description d’un cas d’utilisation qui est commune à d’autres cas d’utilisation. Le cas d’utilisation inclus dans les autres cas d’utilisation n’est pas à proprement parler un vrai cas d’utilisation car il n’a pas d’acteur déclencheur ou receveur d’évènement.
  • 107. La relation <<include>> ou <<uses>> La relation d’include a pour seul objectif de factoriser une partie de la description d’un cas d’utilisation qui est commune à d’autres cas d’utilisation. Le cas d’utilisation inclus dans les autres cas d’utilisation n’est pas à proprement parler un vrai cas d’utilisation car il n’a pas d’acteur déclencheur ou receveur d’évènement. Il est juste un artifice pour faire de la réutilisation d’une portion de texte.
  • 108. Généralisation  L'association de généralisation entre cas d'utilisation a la même sémantique que pour les classes Valider usager Vérifier Scanner mot de passe rétine 91
  • 109. Dict. U.C. Process. Compléments. La galerie /98
  • 110. Dict. U.C. Process. Compléments. Structuration des UC en packages Scanner p 43 et 44 de UML par la pratique On peut alors, si nécessaire, détailler certains de cas d’utilisation. /98
  • 111. Dict. U.C. Process. Compléments. 2. Comment traiter les interfaces utilisateur? ✓Laissez l'interface utilisateur hors des UC ➡ Les UC sont indépendants de l'interface utilisateur ➡ Décrire les interfaces utilisateur avec des modèles dédiés ou des prototypes Words to Avoid Words to Use Click Drag Form Prompts Chooses Open Close Drop Initiates Button Field Drop-down Specifies Pop-up Scroll Browse Submits Selects Record Window Starts Displays Informs “Le système fait sonner le téléphone.” 94 /98
  • 112. Dict. U.C. Process. Compléments. 2. Comment traiter les interfaces utilisateur? ✓Laissez l'interface utilisateur hors des UC ➡ Les UC sont indépendants de l'interface utilisateur ➡ Décrire les interfaces utilisateur avec des modèles dédiés ou des prototypes Words to Avoid Words to Use Click Drag Form Prompts Chooses Open Close Drop Initiates Button Field Drop-down Specifies Pop-up Scroll Browse Submits Selects Record Window Starts Displays Informs “Le système fait sonner le téléphone.” 94 /98
  • 113. Dict. U.C. Process. Compléments. 2. Comment traiter les interfaces utilisateur? ✓Laissez l'interface utilisateur hors des UC ➡ Les UC sont indépendants de l'interface utilisateur ➡ Décrire les interfaces utilisateur avec des modèles dédiés ou des prototypes Words to Avoid Words to Use Click Drag Form Prompts Chooses Open Close Drop Initiates Button Field Drop-down Specifies Pop-up Scroll Browse Submits Selects Record Window Starts Displays Informs “Le système fait sonner le téléphone.” 94 /98
  • 114. Dict. U.C. Process. Compléments. 2. Comment traiter les interfaces utilisateur? ✓Laissez l'interface utilisateur hors des UC ➡ Les UC sont indépendants de l'interface utilisateur ➡ Décrire les interfaces utilisateur avec des modèles dédiés ou des prototypes Words to Avoid Words to Use Click Drag Form Prompts Chooses Open Close Drop Initiates Button Field Drop-down Specifies Pop-up Scroll Browse Submits Selects Record Window Starts Displays Informs “Le système fait sonner le téléphone.” notifie 94 /98
  • 115. Si c’est nécessaire...Après... • avec l’addon Firefox : • http://pencil.evolus.vn/en-US/Downloads/Application.aspx 95
  • 116. Résumé et conseils méthodologiques 96
  • 117. Dict. U.C. Process. Compléments. Cas d’utilisation : résumé  Se servir des Cas d’Utilisation UML pour identifier les exigences fonctionnelles. 97 /98
  • 118. Dict. U.C. Process. Compléments. Cas d’utilisation : résumé 98 /98

Notes de l'éditeur

  1. \n
  2. \n
  3. \n
  4. \n
  5. s&amp;#xE9;curi&amp;#xE9;s&amp;#xE9; par qui ?\n\nComment cela se passe pour les cliensts qui ne sont pas de la banque a ton pens&amp;#xE9; au S de consultation des cartes bleues?\n\n
  6. \n
  7. Le dictionnaire est un outil m&amp;#xE9;thodologique important. Il permet de r&amp;#xE9;unir utilisateurs et informaticiens autour d&apos;un objectif commun. La communication et donc la qualit&amp;#xE9; de l&apos;expression des besoins s&apos;en trouvent am&amp;#xE9;lior&amp;#xE9;es.\nLa terminologie issue du cahier des charges doit &amp;#xEA;tre reprise et pr&amp;#xE9;cis&amp;#xE9;e, afin d&apos;en extraire le dictionnaire. \nLes concepts de ce dictionnaire (noms communs) sont candidats &amp;#xE0; &amp;#xEA;tre des classes, relations ou attributs, alors que les actions (verbes) sont candidats &amp;#xE0; &amp;#xEA;tre des op&amp;#xE9;rations.\nLe cahier des charges peut comporter des manques et des incoh&amp;#xE9;rences. Un premier objectif du dictionnaire est de clarifier ces aspects.\nLe dictionnaire est un document de r&amp;#xE9;f&amp;#xE9;rence, qui fait foi au cours du projet.\nLes d&amp;#xE9;finitions pr&amp;#xE9;cises des termes du dictionnaire doivent permettre de r&amp;#xE9;gler les cas des synonymes (plusieurs termes ont la m&amp;#xEA;me d&amp;#xE9;finition) et des polys&amp;#xE9;mies (un m&amp;#xEA;me terme &amp;#xE0; plusieurs s&amp;#xE9;mantiques).\n\n\n\nLa polys&amp;#xE9;mie est la qualit&amp;#xE9; d&apos;un mot ou d&apos;une expression qui a deux voire plusieurs sens diff&amp;#xE9;rents (on le qualifie de polys&amp;#xE9;mique).\nIl ne faut pas confondre polys&amp;#xE9;mie et homonymie. Deux mots homonymes ont la m&amp;#xEA;me forme (phonique ou graphique) mais sont des mots totalement diff&amp;#xE9;rents. Ils ont deux entr&amp;#xE9;es distinctes dans le dictionnaire. Polys&amp;#xE9;mie et homonymie sont des cas particulier d&apos;ambigu&amp;#xEF;t&amp;#xE9;.\nSommaire\n[masquer]\n1 Exemples\n2 Cha&amp;#xEE;nes s&amp;#xE9;mantiques\n3 Cas particulier des math&amp;#xE9;matiques\n4 Voir aussi\n 4.1 Articles connexes\n 4.2 Liens externes\nExemples [modifier]\nBlanc, la couleur, l&apos;espace, le vin, la viande, la couleur de peau\nRouge, la couleur, le vin, la race, la col&amp;#xE8;re, le communiste\nVivre, exister, subsister, habiter, exp&amp;#xE9;rimenter, traverser\nIndien, habitant de l&apos;Inde, autochtones des Am&amp;#xE9;riques\nam&amp;#xE9;ricain, qui vient de l&apos;Am&amp;#xE9;rique, qui vient des &amp;#xC9;tats-Unis\nClart&amp;#xE9;, lumi&amp;#xE8;re, transparence, intelligibilit&amp;#xE9;, blancheur\nSouris&amp;#xA0;: tipex, souris d&apos;ordinateur, l&apos;animal, la viande d&apos;agneau, sourire.\n\n\n
  8. Another important part of beginning a project is to start identifying the common vocabulary. Look at the Glossary for a sample.\nThere should be one Glossary for a system. This document is important to all stakeholders, especially when they need to understand and use terms that are specific to the project. There is a sample glossary RUCS2 section of the Student Workbook.\nAll textual descriptions of the system, especially use-case descriptions should use and refer to the terms defined in the glossary. \nIn some cases, you may build a domain model to further visualize the terms in the glossary.\n\n\n \nA partir des documents r&amp;#xE9;cup&amp;#xE9;r&amp;#xE9;s en \nr&amp;#xE9;alisant le sch&amp;#xE9;ma des acteurs et des \nflux. \n&amp;#xF06E;Recenser et analyser l&amp;#x2019;ensemble des \ndonn&amp;#xE9;es pr&amp;#xE9;sentes sur les documents. \n&amp;#xF06E;Avoir un support &amp;#xE9;crit d&amp;#xE9;crivant \nclairement les donn&amp;#xE9;es manipul&amp;#xE9;es par \nl&amp;#x2019;entreprise.\n \n&amp;#xF06E;Une donn&amp;#xE9;e est la repr&amp;#xE9;sentation \nd&amp;#x2019;une information sous une forme \npermettant d&amp;#x2019;en faire le traitement \nautomatique. \n&amp;#xF06E;Une donn&amp;#xE9;e &amp;#xE9;l&amp;#xE9;mentaire doit &amp;#xEA;tre \ninitialis&amp;#xE9;e pour pouvoir &amp;#xEA;tre utilis&amp;#xE9;e. \n&amp;#xF06E;Une donn&amp;#xE9;e calculable peut &amp;#xEA;tre \nd&amp;#xE9;duite d&amp;#x2019;autres donn&amp;#xE9;es. \n&amp;#xF06E;L&amp;#x2019;analyse des donn&amp;#xE9;es se fait &amp;#xE0; travers \ndes rubriques pr&amp;#xE9;sentes dans le \ndictionnaire des donn&amp;#xE9;es.\n \n&amp;#xF06E;Le nom de la donn&amp;#xE9;e : le plus proche \nde celui utilis&amp;#xE9; dans l&amp;#x2019;entreprise. \n&amp;#xF06E;La d&amp;#xE9;finition : celle-ci doit &amp;#xEA;tre libell&amp;#xE9;e \nde fa&amp;#xE7;on compr&amp;#xE9;hensible pour tout le \nmonde. \n&amp;#xF06E;La structure : c&amp;#x2019;est le &amp;#xAB;&amp;#xA0;type&amp;#xA0;&amp;#xBB; de la \ndonn&amp;#xE9;e alphab&amp;#xE9;tique, num&amp;#xE9;rique, date, \n&amp;#x2026; On compl&amp;#xE9;tera si possible par le \nnombre de caract&amp;#xE8;res n&amp;#xE9;cessaire. \n&amp;#xF06E;Le type : &amp;#xE9;l&amp;#xE9;mentaire ou calculable\n&amp;#xF06E;La quantification : une estimation si \npossible du nombre de valeurs \ndiff&amp;#xE9;rentes que peut prendre la donn&amp;#xE9;e. \n&amp;#xF06E;Des exemples : de valeurs que peut \nprendre la donn&amp;#xE9;e. \n&amp;#xF06E;Les commentaires : tout ce qui est \nint&amp;#xE9;ressant de savoir sur la donn&amp;#xE9;e et \nque l&amp;#x2019;on n&amp;#x2019;a pas mis dans une autre \nrubrique.\n \n
  9. En tant que r&amp;#xE9;f&amp;#xE9;rentiel, le dictionnaire doit &amp;#xEA;tre mis &amp;#xE0; jour, afin de garantir la tra&amp;#xE7;abilit&amp;#xE9; entre les besoins exprim&amp;#xE9;s et le syst&amp;#xE8;me d&amp;#xE9;velopp&amp;#xE9;.\n
  10. Au d&amp;#xE9;but d&amp;#x2019;un semestre les &amp;#xE9;tudiants consultent un catalogue des cours propos&amp;#xE9;s. Le catalogue contient des informations sur le cours tels que le professeur responsable, les intervenants ainsi que les pr&amp;#xE9;-requis pour aider les &amp;#xE9;tudiants dans leur choix.\n\nLe syst&amp;#xE8;me doit permettre aux &amp;#xE9;tudiants de choisir quatre cours. De plus, les &amp;#xE9;tudiants doivent donner deux autres choix au cas o&amp;#xF9; un cours est complet ou est supprim&amp;#xE9;. Il ne peut y avoir plus de 15 &amp;#xE9;l&amp;#xE8;ves inscrits dans chaque cours mais un cours ne peut ouvrir s&amp;#x2019;il n&amp;#x2019;a pas au moins 6 inscrits.\n\nQuand l&amp;#x2019;inscription d&amp;#x2019;un &amp;#xE9;tudiant est termin&amp;#xE9;e, le syst&amp;#xE8;me des inscriptions envoie des informations au service comptable pour &amp;#xE9;mettre une facture.\n\nLes professeurs doivent pouvoir acc&amp;#xE9;der au syst&amp;#xE8;me pour indiquer les cours qu&amp;#x2019;ils sont en mesure d&amp;#x2019;assurer et pour conna&amp;#xEE;tre les &amp;#xE9;tudiants qui se sont inscrits &amp;#xE0; leur cours.\n\nLes &amp;#xE9;tudiants disposent d&amp;#x2019;une p&amp;#xE9;riode pendant laquelle ils peuvent changer leur choix, ils peuvent en outre ajouter ou abandonner certains cours.\n
  11. \n
  12. \n
  13. \n
  14. The use-case model consists of both diagrams and text. The diagrams give a visual overview of the system. The text gives descriptions of the actors and the use cases.\nUse cases involve writing text. Drawing the pictures is only a small part of the effort. Typically, more than 80 percent of all effort during requirements capture is to write the textual description of what happens in each use case, the non-functional requirements, and rules. The description of what happens is called the flow of events.\nActivity diagrams (previously known as flow charts) are another useful tool you can use to describe a use case. It is quite common to use an activity diagram to describe complex flows of events. When using activity diagrams, it is advisable to use swimlanes to represent each actor and the system. Without swimlanes, the activities float in a &amp;#x201C;semantic emptiness&amp;#x201D; and quickly become meaningless.\nThe following diagram is an example from a Withdraw Cash use case for an ATM.\n
  15. Use cases are a way to organize requirements from a user perspective. All the requirements for a user to accomplish a particular task are gathered together in a single use case. The benefits of use cases include:\nUse cases show why the system is needed. Use cases show what goals the users can accomplish by using the system.\nSystem requirements are placed in context. Each requirement is part of a logical sequence of actions to accomplish a goal of a user. \nUse cases are easy to understand. They express requirements from a user perspective and in the user&amp;#x2019;s own vocabulary. Traditional forms of requirements capture need some translation to make them accessibly by different stakeholders. When you translate something, information is often lost or misinterpreted. Use cases require no such translation. Therefore, they provide a more consistent and reliable form of requirement capture. \nUse cases are a means to communicate requirements between customers and developers to ensure that the system that is built is what the customer wants.\n
  16. Use cases are a way to organize requirements from a user perspective. All the requirements for a user to accomplish a particular task are gathered together in a single use case. The benefits of use cases include:\nUse cases show why the system is needed. Use cases show what goals the users can accomplish by using the system.\nSystem requirements are placed in context. Each requirement is part of a logical sequence of actions to accomplish a goal of a user. \nUse cases are easy to understand. They express requirements from a user perspective and in the user&amp;#x2019;s own vocabulary. Traditional forms of requirements capture need some translation to make them accessibly by different stakeholders. When you translate something, information is often lost or misinterpreted. Use cases require no such translation. Therefore, they provide a more consistent and reliable form of requirement capture. \nUse cases are a means to communicate requirements between customers and developers to ensure that the system that is built is what the customer wants.\n
  17. Functional requirements describe the behaviors (functions or services) of the system that support user goals, tasks, or activities. Functional requirements may include feature sets, capabilities, and security.\nUsability is the ease with which software can be learned and operated by the intended users. Usability requirements may include such subcategories as human factors, aesthetics, consistency in the user interface, online and context-sensitive help, wizards and agents, user documentation, and training materials.\nReliability is the ability for the software to behave consistently in a user-acceptable manner. Reliability requirements to be considered are frequency and severity of failure, recoverability, predictability, accuracy, and mean time between failure (MTBF). \nPerformance is a measure of speed or efficiency of the running system. It imposes conditions on functional requirements. For example, for a given action, it may specify performance parameters for speed, efficiency, availability, accuracy, throughput, response time, recovery time, and resource usage.\nSupportability is the ability of the software to be easily modified to accommodate enhancements and repairs. Supportability requirements may include testability, extensibility, adaptability, maintainability, compatibility, configurability, serviceability, installability, and localizability (internationalization).\nUse cases mainly capture the functional requirements of the system.\n\nA design requirement, often called a design constraint, specifies or constrains the design of a system. \n\n\n\n\n\n
  18. Use cases defined for a system are the basis for the entire development process. They provide the unifying thread through the system and define the behavior performed by a system. Use cases play a role in each of the core process disciplines:\nThe use-case model is a result of the requirements workflow. It models what the system should do from the user&apos;s perspective. \nIn analysis and design, use cases are realized in a design model. You create use-case realizations, which describe how the use case is performed in terms of interacting objects in the design model. This model describes, in terms of design objects, the different parts of the implemented system and how the parts should interact to perform the use cases. \nDuring implementation, the design model is the implementation specification. Because use cases are the basis for the design model, they are implemented in terms of design classes. \nDuring testing, the use cases constitute a basis for identifying test cases and test procedures. The system is verified by performing each use case.\nUse cases have other roles as well: \nBasis for planning iterative development.\nFoundation for what is described in user manuals.\nDefinition of ordering units. For example, a customer can get a system configured with a particular set of use cases.\n
  19. To write use cases, you must find actors and use cases, outline the use cases, and then detail the use cases.\nYou must go through these activities, but the process is rarely as linear as the graphic suggests. Use-case writing is an iterative process.\n
  20. In all but the most trivial of systems, use cases are not written in one sitting. As with any iterative process, a use case evolves from the spark of an idea to a fully detailed description of how your system behaves.\n1. First, you find the actors of the system.\n2. Next, you find and briefly describe the use case. A brief description describes the goal in two or three sentences. When finding use cases, you may find additional actors that require you to refine the list of actors.\n3. The next stage of evolution is to outline the use case. This can be a bulleted list of just the basic flow. You may also choose to identify (not outline) possible alternate flows. This enables you to gain an understanding of the potential size and complexity of the use case. When outlining the use case, you may end up merging or splitting use cases.\n4. Finally, you fully detail the use case, but iteratively. You identify particular flows for development in an iteration and then fully describe and implement just those flows. You then identify flows for subsequent iterations and fully detail and implement those during that iteration. At the end of the project, you have all of your use cases fully detailed.\nRemember, the use case writing process is an iterative process. You will likely go through many cycles of refinement before you complete your use case.\n
  21. In all but the most trivial of systems, use cases are not written in one sitting. As with any iterative process, a use case evolves from the spark of an idea to a fully detailed description of how your system behaves.\n1. First, you find the actors of the system.\n2. Next, you find and briefly describe the use case. A brief description describes the goal in two or three sentences. When finding use cases, you may find additional actors that require you to refine the list of actors.\n3. The next stage of evolution is to outline the use case. This can be a bulleted list of just the basic flow. You may also choose to identify (not outline) possible alternate flows. This enables you to gain an understanding of the potential size and complexity of the use case. When outlining the use case, you may end up merging or splitting use cases.\n4. Finally, you fully detail the use case, but iteratively. You identify particular flows for development in an iteration and then fully describe and implement just those flows. You then identify flows for subsequent iterations and fully detail and implement those during that iteration. At the end of the project, you have all of your use cases fully detailed.\nRemember, the use case writing process is an iterative process. You will likely go through many cycles of refinement before you complete your use case.\n
  22. Un acteur se repr&amp;#xE9;sente soit sous la forme d&amp;#x2019;une classe avec le st&amp;#xE9;r&amp;#xE9;otype &amp;#xAB;Actor&amp;#xBB; o&amp;#xF9; le nom de l&amp;#x2019;acteur appara&amp;#xEE;t &amp;#xE0; la place du nom de la classe, soit sous la forme d&amp;#x2019;une figure stylis&amp;#xE9;e d&amp;#x2019;un homme avec le nom de l&amp;#x2019;acteur en dessous, soit encore comme un combin&amp;#xE9; des deux.\nLe conducteur est un acteur primaire\nLe garagiste est un acteur secondaire\nLa notion de syst&amp;#xE8;me se repr&amp;#xE9;sente par un rectangle vide incluant son nom (nom de l&amp;#x2019;application ou du syst&amp;#xE8;me). Les acteurs sont ext&amp;#xE9;rieurs au syst&amp;#xE8;me, ils ne font qu&amp;#x2019;interargir avec.\n
  23. Un acteur se repr&amp;#xE9;sente soit sous la forme d&amp;#x2019;une classe avec le st&amp;#xE9;r&amp;#xE9;otype &amp;#xAB;Actor&amp;#xBB; o&amp;#xF9; le nom de l&amp;#x2019;acteur appara&amp;#xEE;t &amp;#xE0; la place du nom de la classe, soit sous la forme d&amp;#x2019;une figure stylis&amp;#xE9;e d&amp;#x2019;un homme avec le nom de l&amp;#x2019;acteur en dessous, soit encore comme un combin&amp;#xE9; des deux.\nLe conducteur est un acteur primaire\nLe garagiste est un acteur secondaire\nLa notion de syst&amp;#xE8;me se repr&amp;#xE9;sente par un rectangle vide incluant son nom (nom de l&amp;#x2019;application ou du syst&amp;#xE8;me). Les acteurs sont ext&amp;#xE9;rieurs au syst&amp;#xE8;me, ils ne font qu&amp;#x2019;interargir avec.\n
  24. Un acteur se repr&amp;#xE9;sente soit sous la forme d&amp;#x2019;une classe avec le st&amp;#xE9;r&amp;#xE9;otype &amp;#xAB;Actor&amp;#xBB; o&amp;#xF9; le nom de l&amp;#x2019;acteur appara&amp;#xEE;t &amp;#xE0; la place du nom de la classe, soit sous la forme d&amp;#x2019;une figure stylis&amp;#xE9;e d&amp;#x2019;un homme avec le nom de l&amp;#x2019;acteur en dessous, soit encore comme un combin&amp;#xE9; des deux.\nLe conducteur est un acteur primaire\nLe garagiste est un acteur secondaire\nLa notion de syst&amp;#xE8;me se repr&amp;#xE9;sente par un rectangle vide incluant son nom (nom de l&amp;#x2019;application ou du syst&amp;#xE8;me). Les acteurs sont ext&amp;#xE9;rieurs au syst&amp;#xE8;me, ils ne font qu&amp;#x2019;interargir avec.\n
  25. Un acteur se repr&amp;#xE9;sente soit sous la forme d&amp;#x2019;une classe avec le st&amp;#xE9;r&amp;#xE9;otype &amp;#xAB;Actor&amp;#xBB; o&amp;#xF9; le nom de l&amp;#x2019;acteur appara&amp;#xEE;t &amp;#xE0; la place du nom de la classe, soit sous la forme d&amp;#x2019;une figure stylis&amp;#xE9;e d&amp;#x2019;un homme avec le nom de l&amp;#x2019;acteur en dessous, soit encore comme un combin&amp;#xE9; des deux.\nLe conducteur est un acteur primaire\nLe garagiste est un acteur secondaire\nLa notion de syst&amp;#xE8;me se repr&amp;#xE9;sente par un rectangle vide incluant son nom (nom de l&amp;#x2019;application ou du syst&amp;#xE8;me). Les acteurs sont ext&amp;#xE9;rieurs au syst&amp;#xE8;me, ils ne font qu&amp;#x2019;interargir avec.\n
  26. Un acteur se repr&amp;#xE9;sente soit sous la forme d&amp;#x2019;une classe avec le st&amp;#xE9;r&amp;#xE9;otype &amp;#xAB;Actor&amp;#xBB; o&amp;#xF9; le nom de l&amp;#x2019;acteur appara&amp;#xEE;t &amp;#xE0; la place du nom de la classe, soit sous la forme d&amp;#x2019;une figure stylis&amp;#xE9;e d&amp;#x2019;un homme avec le nom de l&amp;#x2019;acteur en dessous, soit encore comme un combin&amp;#xE9; des deux.\nLe conducteur est un acteur primaire\nLe garagiste est un acteur secondaire\nLa notion de syst&amp;#xE8;me se repr&amp;#xE9;sente par un rectangle vide incluant son nom (nom de l&amp;#x2019;application ou du syst&amp;#xE8;me). Les acteurs sont ext&amp;#xE9;rieurs au syst&amp;#xE8;me, ils ne font qu&amp;#x2019;interargir avec.\n
  27. Un acteur se repr&amp;#xE9;sente soit sous la forme d&amp;#x2019;une classe avec le st&amp;#xE9;r&amp;#xE9;otype &amp;#xAB;Actor&amp;#xBB; o&amp;#xF9; le nom de l&amp;#x2019;acteur appara&amp;#xEE;t &amp;#xE0; la place du nom de la classe, soit sous la forme d&amp;#x2019;une figure stylis&amp;#xE9;e d&amp;#x2019;un homme avec le nom de l&amp;#x2019;acteur en dessous, soit encore comme un combin&amp;#xE9; des deux.\nLe conducteur est un acteur primaire\nLe garagiste est un acteur secondaire\nLa notion de syst&amp;#xE8;me se repr&amp;#xE9;sente par un rectangle vide incluant son nom (nom de l&amp;#x2019;application ou du syst&amp;#xE8;me). Les acteurs sont ext&amp;#xE9;rieurs au syst&amp;#xE8;me, ils ne font qu&amp;#x2019;interargir avec.\n
  28. Un acteur se repr&amp;#xE9;sente soit sous la forme d&amp;#x2019;une classe avec le st&amp;#xE9;r&amp;#xE9;otype &amp;#xAB;Actor&amp;#xBB; o&amp;#xF9; le nom de l&amp;#x2019;acteur appara&amp;#xEE;t &amp;#xE0; la place du nom de la classe, soit sous la forme d&amp;#x2019;une figure stylis&amp;#xE9;e d&amp;#x2019;un homme avec le nom de l&amp;#x2019;acteur en dessous, soit encore comme un combin&amp;#xE9; des deux.\nLe conducteur est un acteur primaire\nLe garagiste est un acteur secondaire\nLa notion de syst&amp;#xE8;me se repr&amp;#xE9;sente par un rectangle vide incluant son nom (nom de l&amp;#x2019;application ou du syst&amp;#xE8;me). Les acteurs sont ext&amp;#xE9;rieurs au syst&amp;#xE8;me, ils ne font qu&amp;#x2019;interargir avec.\n
  29. \n
  30. Actor is a role, not a particular person or thing. The name of the actor should represent, as clearly as possible, the actor&amp;#x2019;s role.\nMake sure that there is little risk of confusing one actor&amp;#x2019;s name with another at a future stage of the work. Also, try to avoid an actor called &amp;#x201C;User&amp;#x201D;, rather, try to figure out the role of that particular user.\nIn most instances, some person or some other system does something to trigger the start of the use case. If a use case in your system is initiated at a certain time, for example, at the end of the day or the end of the month, this can be modeled with a special actor, such as the &amp;#x201C;scheduler&amp;#x201D; or &amp;#x201C;time.&amp;#x201D; &amp;#x201C;Scheduler&amp;#x201D;, as opposed to &amp;#x201C;time&amp;#x201D;, is a useful name for such an actor because scheduler may be human or non-human. \n
  31. \n
  32. Attention jefais le choix de transforemer le catalogue comme qq d&amp;#x2019;existant d&amp;#x2019;ou l&amp;#x2019;acteur.\n\nAu d&amp;#xE9;but d&amp;#x2019;un semestre les &amp;#xE9;tudiants consultent un catalogue des cours propos&amp;#xE9;s. Le catalogue contient des informations sur le cours tels que le professeur responsable, les intervenants ainsi que les pr&amp;#xE9;-requis pour aider les &amp;#xE9;tudiants dans leur choix.\n\nLe syst&amp;#xE8;me doit permettre aux &amp;#xE9;tudiants de choisir quatre cours. De plus, les &amp;#xE9;tudiants doivent donner deux autres choix au cas o&amp;#xF9; un cours est complet ou est supprim&amp;#xE9;. Il ne peut y avoir plus de 15 &amp;#xE9;l&amp;#xE8;ves inscrits dans chaque cours mais un cours ne peut ouvrir s&amp;#x2019;il n&amp;#x2019;a pas au moins 6 inscrits.\n\nQuand l&amp;#x2019;inscription d&amp;#x2019;un &amp;#xE9;tudiant est termin&amp;#xE9;e, le syst&amp;#xE8;me des inscriptions envoie des informations au service comptable pour &amp;#xE9;mettre une facture.\n\nLes professeurs doivent pouvoir acc&amp;#xE9;der au syst&amp;#xE8;me pour indiquer les cours qu&amp;#x2019;ils sont en mesure d&amp;#x2019;assurer et pour conna&amp;#xEE;tre les &amp;#xE9;tudiants qui se sont inscrits &amp;#xE0; leur cours.\n\nLes &amp;#xE9;tudiants disposent d&amp;#x2019;une p&amp;#xE9;riode pendant laquelle ils peuvent changer leur choix, ils peuvent en outre ajouter ou abandonner certains cours.\n\n\n\nAu d&amp;#xE9;but d&amp;#x2019;un semestre les &amp;#xE9;tudiants consultent un catalogue des cours propos&amp;#xE9;s. Le catalogue contient des informations sur le cours tels que le professeur responsable, les intervenants ainsi que les pr&amp;#xE9;-requis pour aider les &amp;#xE9;tudiants dans leur choix.\n\nLe syst&amp;#xE8;me doit permettre aux &amp;#xE9;tudiants de choisir quatre cours. De plus, les &amp;#xE9;tudiants doivent donner deux autres choix au cas o&amp;#xF9; un cours est complet ou est supprim&amp;#xE9;. Il ne peut y avoir plus de 15 &amp;#xE9;l&amp;#xE8;ves inscrits dans chaque cours mais un cours ne peut ouvrir s&amp;#x2019;il n&amp;#x2019;a pas au moins 6 inscrits.\n\nQuand l&amp;#x2019;inscription d&amp;#x2019;un &amp;#xE9;tudiant est termin&amp;#xE9;e, le syst&amp;#xE8;me des inscriptions envoie des informations au service comptable pour &amp;#xE9;mettre une facture.\n\nLes professeurs doivent pouvoir acc&amp;#xE9;der au syst&amp;#xE8;me pour indiquer les cours qu&amp;#x2019;ils sont en mesure d&amp;#x2019;assurer et pour conna&amp;#xEE;tre les &amp;#xE9;tudiants qui se sont inscrits &amp;#xE0; leur cours.\n\nLes &amp;#xE9;tudiants disposent d&amp;#x2019;une p&amp;#xE9;riode pendant laquelle ils peuvent changer leur choix, ils peuvent en outre ajouter ou abandonner certains cours.\n
  33. Au d&amp;#xE9;but d&amp;#x2019;un semestre les &amp;#xE9;tudiants consultent un catalogue des cours propos&amp;#xE9;s. Le catalogue contient des informations sur le cours tels que le professeur responsable, les intervenants ainsi que les pr&amp;#xE9;-requis pour aider les &amp;#xE9;tudiants dans leur choix.\n\nLe syst&amp;#xE8;me doit permettre aux &amp;#xE9;tudiants de choisir quatre cours. De plus, les &amp;#xE9;tudiants doivent donner deux autres choix au cas o&amp;#xF9; un cours est complet ou est supprim&amp;#xE9;. Il ne peut y avoir plus de 15 &amp;#xE9;l&amp;#xE8;ves inscrits dans chaque cours mais un cours ne peut ouvrir s&amp;#x2019;il n&amp;#x2019;a pas au moins 6 inscrits.\n\nQuand l&amp;#x2019;inscription d&amp;#x2019;un &amp;#xE9;tudiant est termin&amp;#xE9;e, le syst&amp;#xE8;me des inscriptions envoie des informations au service comptable pour &amp;#xE9;mettre une facture.\n\nLes professeurs doivent pouvoir acc&amp;#xE9;der au syst&amp;#xE8;me pour indiquer les cours qu&amp;#x2019;ils sont en mesure d&amp;#x2019;assurer et pour conna&amp;#xEE;tre les &amp;#xE9;tudiants qui se sont inscrits &amp;#xE0; leur cours.\n\nLes &amp;#xE9;tudiants disposent d&amp;#x2019;une p&amp;#xE9;riode pendant laquelle ils peuvent changer leur choix, ils peuvent en outre ajouter ou abandonner certains cours.\n
  34. to describe each actor in detail . \nInclude this information in each brief description for each actor:\nWhat or whom the actor represents\nWhy the actor is needed\nWhat the actor&amp;#x2019;s area of responsibility is \nWhat interests the actor has in the system\nSome information about the actors is also shown on use-case diagrams, which show the name of the actor and the actor&amp;#x2019;s relationships with use cases.\n
  35. actuers externes : porteurs de carte \nDistribut et lecteur sont interne pas des acteurs : sauf si nous ne gerons que la partie interne.\ncarte : oui et non. C&amp;#x2019;est un acteur physique que l&amp;#x2019;on garde ou non...\nmais aussi des clients...\nSyst&amp;#xE8;me d&amp;#x2019;autorisation\nSysteme d&amp;#x2019;information de la banque\n\n\n\n\n\n\n
  36. \n
  37. \n
  38. Attention jefais le choix de transforemer le catalogue comme qq d&amp;#x2019;existant d&amp;#x2019;ou l&amp;#x2019;acteur.\n\nAu d&amp;#xE9;but d&amp;#x2019;un semestre les &amp;#xE9;tudiants consultent un catalogue des cours propos&amp;#xE9;s. Le catalogue contient des informations sur le cours tels que le professeur responsable, les intervenants ainsi que les pr&amp;#xE9;-requis pour aider les &amp;#xE9;tudiants dans leur choix.\n\nLe syst&amp;#xE8;me doit permettre aux &amp;#xE9;tudiants de choisir quatre cours. De plus, les &amp;#xE9;tudiants doivent donner deux autres choix au cas o&amp;#xF9; un cours est complet ou est supprim&amp;#xE9;. Il ne peut y avoir plus de 15 &amp;#xE9;l&amp;#xE8;ves inscrits dans chaque cours mais un cours ne peut ouvrir s&amp;#x2019;il n&amp;#x2019;a pas au moins 6 inscrits.\n\nQuand l&amp;#x2019;inscription d&amp;#x2019;un &amp;#xE9;tudiant est termin&amp;#xE9;e, le syst&amp;#xE8;me des inscriptions envoie des informations au service comptable pour &amp;#xE9;mettre une facture.\n\nLes professeurs doivent pouvoir acc&amp;#xE9;der au syst&amp;#xE8;me pour indiquer les cours qu&amp;#x2019;ils sont en mesure d&amp;#x2019;assurer et pour conna&amp;#xEE;tre les &amp;#xE9;tudiants qui se sont inscrits &amp;#xE0; leur cours.\n\nLes &amp;#xE9;tudiants disposent d&amp;#x2019;une p&amp;#xE9;riode pendant laquelle ils peuvent changer leur choix, ils peuvent en outre ajouter ou abandonner certains cours.\n
  39. Attention jefais le choix de transforemer le catalogue comme qq d&amp;#x2019;existant d&amp;#x2019;ou l&amp;#x2019;acteur.\n\nAu d&amp;#xE9;but d&amp;#x2019;un semestre les &amp;#xE9;tudiants consultent un catalogue des cours propos&amp;#xE9;s. Le catalogue contient des informations sur le cours tels que le professeur responsable, les intervenants ainsi que les pr&amp;#xE9;-requis pour aider les &amp;#xE9;tudiants dans leur choix.\n\nLe syst&amp;#xE8;me doit permettre aux &amp;#xE9;tudiants de choisir quatre cours. De plus, les &amp;#xE9;tudiants doivent donner deux autres choix au cas o&amp;#xF9; un cours est complet ou est supprim&amp;#xE9;. Il ne peut y avoir plus de 15 &amp;#xE9;l&amp;#xE8;ves inscrits dans chaque cours mais un cours ne peut ouvrir s&amp;#x2019;il n&amp;#x2019;a pas au moins 6 inscrits.\n\nQuand l&amp;#x2019;inscription d&amp;#x2019;un &amp;#xE9;tudiant est termin&amp;#xE9;e, le syst&amp;#xE8;me des inscriptions envoie des informations au service comptable pour &amp;#xE9;mettre une facture.\n\nLes professeurs doivent pouvoir acc&amp;#xE9;der au syst&amp;#xE8;me pour indiquer les cours qu&amp;#x2019;ils sont en mesure d&amp;#x2019;assurer et pour conna&amp;#xEE;tre les &amp;#xE9;tudiants qui se sont inscrits &amp;#xE0; leur cours.\n\nLes &amp;#xE9;tudiants disposent d&amp;#x2019;une p&amp;#xE9;riode pendant laquelle ils peuvent changer leur choix, ils peuvent en outre ajouter ou abandonner certains cours.\n\n\n\nAu d&amp;#xE9;but d&amp;#x2019;un semestre les &amp;#xE9;tudiants consultent un catalogue des cours propos&amp;#xE9;s. Le catalogue contient des informations sur le cours tels que le professeur responsable, les intervenants ainsi que les pr&amp;#xE9;-requis pour aider les &amp;#xE9;tudiants dans leur choix.\n\nLe syst&amp;#xE8;me doit permettre aux &amp;#xE9;tudiants de choisir quatre cours. De plus, les &amp;#xE9;tudiants doivent donner deux autres choix au cas o&amp;#xF9; un cours est complet ou est supprim&amp;#xE9;. Il ne peut y avoir plus de 15 &amp;#xE9;l&amp;#xE8;ves inscrits dans chaque cours mais un cours ne peut ouvrir s&amp;#x2019;il n&amp;#x2019;a pas au moins 6 inscrits.\n\nQuand l&amp;#x2019;inscription d&amp;#x2019;un &amp;#xE9;tudiant est termin&amp;#xE9;e, le syst&amp;#xE8;me des inscriptions envoie des informations au service comptable pour &amp;#xE9;mettre une facture.\n\nLes professeurs doivent pouvoir acc&amp;#xE9;der au syst&amp;#xE8;me pour indiquer les cours qu&amp;#x2019;ils sont en mesure d&amp;#x2019;assurer et pour conna&amp;#xEE;tre les &amp;#xE9;tudiants qui se sont inscrits &amp;#xE0; leur cours.\n\nLes &amp;#xE9;tudiants disposent d&amp;#x2019;une p&amp;#xE9;riode pendant laquelle ils peuvent changer leur choix, ils peuvent en outre ajouter ou abandonner certains cours.\n
  40. \n
  41. \n
  42. \n
  43. \n
  44. \n
  45. \n
  46. \n
  47. actuers externes : porteurs de carte \nDistribut et lecteur sont interne pas des acteurs : sauf si nous ne gerons que la partie interne.\ncarte : oui et non. C&amp;#x2019;est un acteur physique que l&amp;#x2019;on garde ou non...\nmais aussi des clients...\nSyst&amp;#xE8;me d&amp;#x2019;autorisation\nSysteme d&amp;#x2019;information de la banque\n\n\n\n\n\n\n
  48. In all but the most trivial of systems, use cases are not written in one sitting. As with any iterative process, a use case evolves from the spark of an idea to a fully detailed description of how your system behaves.\n1. First, you find the actors of the system.\n2. Next, you find and briefly describe the use case. A brief description describes the goal in two or three sentences. When finding use cases, you may find additional actors that require you to refine the list of actors.\n3. The next stage of evolution is to outline the use case. This can be a bulleted list of just the basic flow. You may also choose to identify (not outline) possible alternate flows. This enables you to gain an understanding of the potential size and complexity of the use case. When outlining the use case, you may end up merging or splitting use cases.\n4. Finally, you fully detail the use case, but iteratively. You identify particular flows for development in an iteration and then fully describe and implement just those flows. You then identify flows for subsequent iterations and fully detail and implement those during that iteration. At the end of the project, you have all of your use cases fully detailed.\nRemember, the use case writing process is an iterative process. You will likely go through many cycles of refinement before you complete your use case.\n
  49. This definition of a use case comes from the Object Management Group (OMG), which is a non-profit computer industry specifications consortium.\nThe Unified Modeling Language is a standard visual modeling language managed and maintained by members of the OMG.\nTo learn more about UML and to access UML resources, go to www.ulm.org or to the IBM Rational software UML Resource Center www.ibm.com/sofware/rational/uml/.\nFor example, in a university-based course registration system, use cases might include: Register for Courses, Request Course Catalog, and Get Class List for a Course.\n\nA use-case model describes a system&apos;s functional requirements in terms of use cases. \nIt is a model of the system&apos;s intended functionality (use cases) and its environment (actors). \nThink of a use-case model as a menu, much like the menu you would find in a restaurant. By looking at the menu, you know what is available to you, the individual dishes as well as their prices. You also know what kind of cuisine the restaurant serves: Italian, Mexican, Chinese, and so on. By looking at the menu, you get an overall impression of the dining experience that awaits you in that restaurant. The menu, in effect, &quot;models&quot; the restaurant&apos;s behavior. \nBecause it is a very powerful planning instrument, the use-case model is generally used in all phases of the development lifecycle by all team members.\n
  50. This definition of a use case comes from the Object Management Group (OMG), which is a non-profit computer industry specifications consortium.\nThe Unified Modeling Language is a standard visual modeling language managed and maintained by members of the OMG.\nTo learn more about UML and to access UML resources, go to www.ulm.org or to the IBM Rational software UML Resource Center www.ibm.com/sofware/rational/uml/.\nFor example, in a university-based course registration system, use cases might include: Register for Courses, Request Course Catalog, and Get Class List for a Course.\n\nA use-case model describes a system&apos;s functional requirements in terms of use cases. \nIt is a model of the system&apos;s intended functionality (use cases) and its environment (actors). \nThink of a use-case model as a menu, much like the menu you would find in a restaurant. By looking at the menu, you know what is available to you, the individual dishes as well as their prices. You also know what kind of cuisine the restaurant serves: Italian, Mexican, Chinese, and so on. By looking at the menu, you get an overall impression of the dining experience that awaits you in that restaurant. The menu, in effect, &quot;models&quot; the restaurant&apos;s behavior. \nBecause it is a very powerful planning instrument, the use-case model is generally used in all phases of the development lifecycle by all team members.\n
  51. This definition of a use case comes from the Object Management Group (OMG), which is a non-profit computer industry specifications consortium.\nThe Unified Modeling Language is a standard visual modeling language managed and maintained by members of the OMG.\nTo learn more about UML and to access UML resources, go to www.ulm.org or to the IBM Rational software UML Resource Center www.ibm.com/sofware/rational/uml/.\nFor example, in a university-based course registration system, use cases might include: Register for Courses, Request Course Catalog, and Get Class List for a Course.\n\nA use-case model describes a system&apos;s functional requirements in terms of use cases. \nIt is a model of the system&apos;s intended functionality (use cases) and its environment (actors). \nThink of a use-case model as a menu, much like the menu you would find in a restaurant. By looking at the menu, you know what is available to you, the individual dishes as well as their prices. You also know what kind of cuisine the restaurant serves: Italian, Mexican, Chinese, and so on. By looking at the menu, you get an overall impression of the dining experience that awaits you in that restaurant. The menu, in effect, &quot;models&quot; the restaurant&apos;s behavior. \nBecause it is a very powerful planning instrument, the use-case model is generally used in all phases of the development lifecycle by all team members.\n
  52. This slide lists several questions that can help you find the use cases in your system. The best way to find use cases is to consider what each actor requires of the system. Go through all of the actors and identify the particular needs of each actor.\nWhen you have made your first list of use cases, verify that all required functionality has been addressed. Include special use cases for system startup, termination, or maintenance. Also, include use cases for automatically scheduled events. For example, a time-initiated job may run the payroll at midnight on the last day of each month. Use cases that concern automatically scheduled events are usually initiated by a special actor: the Scheduler.\nTry to keep all use cases at approximately the same level of importance. The notion of use-case levels as popularized by some authors is not recommended, because it can lead to a functionally decomposed system. \nThese questions can help you get to the appropriate level of granularity (also see the definition of a use case). Ask yourself:\nWould you ever want to perform a particular activity as an end result in itself?\nAre there any activities that should be kept together, so you can review, modify, test, and document them together?\nIs the use case too complex? If it is, you may want to split it (a use-case report significantly longer than 10 pages may be a candidate).\nDoes it deliver something of value to multiple actors? If so, it may be too large.\n\nAfter you have identified the actors, finding the use cases is the next step in developing your use-case model. Use cases describe what an actor wants a system to do that provides some value to the actor. \nUse this process to identify the use cases for each actor.\nStart with the highest-priority actor. For all actors, but individually, ask:\nWhat goals are they trying to achieve with the system?\nHow will the solution help them do their jobs?\nHow will the solution change their jobs?\n
  53. \n
  54. Au d&amp;#xE9;but d&amp;#x2019;un semestre les &amp;#xE9;tudiants consultent un catalogue des cours propos&amp;#xE9;s. Le catalogue contient des informations sur le cours tels que le professeur responsable, les intervenants ainsi que les pr&amp;#xE9;-requis pour aider les &amp;#xE9;tudiants dans leur choix.\n\nLe syst&amp;#xE8;me doit permettre aux &amp;#xE9;tudiants de choisir quatre cours. De plus, les &amp;#xE9;tudiants doivent donner deux autres choix au cas o&amp;#xF9; un cours est complet ou est supprim&amp;#xE9;. Il ne peut y avoir plus de 15 &amp;#xE9;l&amp;#xE8;ves inscrits dans chaque cours mais un cours ne peut ouvrir s&amp;#x2019;il n&amp;#x2019;a pas au moins 6 inscrits.\n\nQuand l&amp;#x2019;inscription d&amp;#x2019;un &amp;#xE9;tudiant est termin&amp;#xE9;e, le syst&amp;#xE8;me des inscriptions envoie des informations au service comptable pour &amp;#xE9;mettre une facture.\n\nLes professeurs doivent pouvoir acc&amp;#xE9;der au syst&amp;#xE8;me pour indiquer les cours qu&amp;#x2019;ils sont en mesure d&amp;#x2019;assurer et pour conna&amp;#xEE;tre les &amp;#xE9;tudiants qui se sont inscrits &amp;#xE0; leur cours.\n\nLes &amp;#xE9;tudiants disposent d&amp;#x2019;une p&amp;#xE9;riode pendant laquelle ils peuvent changer leur choix, ils peuvent en outre ajouter ou abandonner certains cours.\n
  55. Au d&amp;#xE9;but d&amp;#x2019;un semestre les &amp;#xE9;tudiants consultent un catalogue des cours propos&amp;#xE9;s. Le catalogue contient des informations sur le cours tels que le professeur responsable, les intervenants ainsi que les pr&amp;#xE9;-requis pour aider les &amp;#xE9;tudiants dans leur choix.\n\nLe syst&amp;#xE8;me doit permettre aux &amp;#xE9;tudiants de choisir quatre cours. De plus, les &amp;#xE9;tudiants doivent donner deux autres choix au cas o&amp;#xF9; un cours est complet ou est supprim&amp;#xE9;. Il ne peut y avoir plus de 15 &amp;#xE9;l&amp;#xE8;ves inscrits dans chaque cours mais un cours ne peut ouvrir s&amp;#x2019;il n&amp;#x2019;a pas au moins 6 inscrits.\n\nQuand l&amp;#x2019;inscription d&amp;#x2019;un &amp;#xE9;tudiant est termin&amp;#xE9;e, le syst&amp;#xE8;me des inscriptions envoie des informations au service comptable pour &amp;#xE9;mettre une facture.\n\nLes professeurs doivent pouvoir acc&amp;#xE9;der au syst&amp;#xE8;me pour indiquer les cours qu&amp;#x2019;ils sont en mesure d&amp;#x2019;assurer et pour conna&amp;#xEE;tre les &amp;#xE9;tudiants qui se sont inscrits &amp;#xE0; leur cours.\n\nLes &amp;#xE9;tudiants disposent d&amp;#x2019;une p&amp;#xE9;riode pendant laquelle ils peuvent changer leur choix, ils peuvent en outre ajouter ou abandonner certains cours.\n
  56. The use-case model consists of both diagrams and text. The diagrams give a visual overview of the system. The text gives descriptions of the actors and the use cases.\nThe majority of the work in writing use cases is spent writing the textual portion of the use case. \nUse cases involve writing text. Drawing the pictures is only a small part of the effort. Typically, more than 80 percent of all effort during requirements capture is writing the textual description of what happens in each use case, the non-functional requirements, and rules. \nUML does NOT specify how the text of a use case should be structured, organized, or written.\nHow you write use cases will have a large impact on how easy they are to read, use, and test.\n\nEach use case should have a name that indicates what is achieved by its interactions with the actor(s).\nA good rule of thumb (but not dictated by any standard) is to attach the actor&amp;#x2019;s name (of the primary actor) at the beginning of the use-case name to see if it makes a meaningful sentence. For example, does it make sense to say &amp;#x201C;The student registers for a course?&amp;#x201D; Does it make sense to say, &amp;#x201C;The student takes a course?&amp;#x201D; \nAnother approach is to ask, &amp;#x201C;Why does the actor want to use the system?&amp;#x201D;\nBe focused on identifying the goal that is trying to be attained by using the system.\n
  57. The use-case model consists of both diagrams and text. The diagrams give a visual overview of the system. The text gives descriptions of the actors and the use cases.\nThe majority of the work in writing use cases is spent writing the textual portion of the use case. \nUse cases involve writing text. Drawing the pictures is only a small part of the effort. Typically, more than 80 percent of all effort during requirements capture is writing the textual description of what happens in each use case, the non-functional requirements, and rules. \nUML does NOT specify how the text of a use case should be structured, organized, or written.\nHow you write use cases will have a large impact on how easy they are to read, use, and test.\n\nEach use case should have a name that indicates what is achieved by its interactions with the actor(s).\nA good rule of thumb (but not dictated by any standard) is to attach the actor&amp;#x2019;s name (of the primary actor) at the beginning of the use-case name to see if it makes a meaningful sentence. For example, does it make sense to say &amp;#x201C;The student registers for a course?&amp;#x201D; Does it make sense to say, &amp;#x201C;The student takes a course?&amp;#x201D; \nAnother approach is to ask, &amp;#x201C;Why does the actor want to use the system?&amp;#x201D;\nBe focused on identifying the goal that is trying to be attained by using the system.\n
  58. The use-case model consists of both diagrams and text. The diagrams give a visual overview of the system. The text gives descriptions of the actors and the use cases.\nThe majority of the work in writing use cases is spent writing the textual portion of the use case. \nUse cases involve writing text. Drawing the pictures is only a small part of the effort. Typically, more than 80 percent of all effort during requirements capture is writing the textual description of what happens in each use case, the non-functional requirements, and rules. \nUML does NOT specify how the text of a use case should be structured, organized, or written.\nHow you write use cases will have a large impact on how easy they are to read, use, and test.\n\nEach use case should have a name that indicates what is achieved by its interactions with the actor(s).\nA good rule of thumb (but not dictated by any standard) is to attach the actor&amp;#x2019;s name (of the primary actor) at the beginning of the use-case name to see if it makes a meaningful sentence. For example, does it make sense to say &amp;#x201C;The student registers for a course?&amp;#x201D; Does it make sense to say, &amp;#x201C;The student takes a course?&amp;#x201D; \nAnother approach is to ask, &amp;#x201C;Why does the actor want to use the system?&amp;#x201D;\nBe focused on identifying the goal that is trying to be attained by using the system.\n
  59. The use-case model consists of both diagrams and text. The diagrams give a visual overview of the system. The text gives descriptions of the actors and the use cases.\nThe majority of the work in writing use cases is spent writing the textual portion of the use case. \nUse cases involve writing text. Drawing the pictures is only a small part of the effort. Typically, more than 80 percent of all effort during requirements capture is writing the textual description of what happens in each use case, the non-functional requirements, and rules. \nUML does NOT specify how the text of a use case should be structured, organized, or written.\nHow you write use cases will have a large impact on how easy they are to read, use, and test.\n\nEach use case should have a name that indicates what is achieved by its interactions with the actor(s).\nA good rule of thumb (but not dictated by any standard) is to attach the actor&amp;#x2019;s name (of the primary actor) at the beginning of the use-case name to see if it makes a meaningful sentence. For example, does it make sense to say &amp;#x201C;The student registers for a course?&amp;#x201D; Does it make sense to say, &amp;#x201C;The student takes a course?&amp;#x201D; \nAnother approach is to ask, &amp;#x201C;Why does the actor want to use the system?&amp;#x201D;\nBe focused on identifying the goal that is trying to be attained by using the system.\n
  60. The use-case model consists of both diagrams and text. The diagrams give a visual overview of the system. The text gives descriptions of the actors and the use cases.\nThe majority of the work in writing use cases is spent writing the textual portion of the use case. \nUse cases involve writing text. Drawing the pictures is only a small part of the effort. Typically, more than 80 percent of all effort during requirements capture is writing the textual description of what happens in each use case, the non-functional requirements, and rules. \nUML does NOT specify how the text of a use case should be structured, organized, or written.\nHow you write use cases will have a large impact on how easy they are to read, use, and test.\n\nEach use case should have a name that indicates what is achieved by its interactions with the actor(s).\nA good rule of thumb (but not dictated by any standard) is to attach the actor&amp;#x2019;s name (of the primary actor) at the beginning of the use-case name to see if it makes a meaningful sentence. For example, does it make sense to say &amp;#x201C;The student registers for a course?&amp;#x201D; Does it make sense to say, &amp;#x201C;The student takes a course?&amp;#x201D; \nAnother approach is to ask, &amp;#x201C;Why does the actor want to use the system?&amp;#x201D;\nBe focused on identifying the goal that is trying to be attained by using the system.\n
  61. Relationships between actors and use cases are called communicates-associations. A communicates-association between an actor and a use case indicates that they interact: The actor participates in and communicates with the system containing the use case. A communicates-association is represented on UML diagrams as a solid line.\n
  62. Relationships between actors and use cases are called communicates-associations. A communicates-association between an actor and a use case indicates that they interact: The actor participates in and communicates with the system containing the use case. A communicates-association is represented on UML diagrams as a solid line.\n
  63. \n
  64. \n
  65. \n
  66. On ne sait pas distinguerle SI Automatique et de la nanque en fonction de qui fait le retrait, cela pose un prbem, du coup on passe &amp;#xE0; la mod&amp;#xE9;lisation suivante\n
  67. distingue bien les acteurs secondaires\n
  68. Each use case should have a name that indicates what is achieved by its interactions with the actor(s).\nA good rule of thumb (but not dictated by any standard) is to attach the actor&amp;#x2019;s name (of the primary actor) at the beginning of the use-case name to see if it makes a meaningful sentence. For example, does it make sense to say &amp;#x201C;The student registers for a course?&amp;#x201D; Does it make sense to say, &amp;#x201C;The student takes a course?&amp;#x201D; \nAnother approach is to ask, &amp;#x201C;Why does the actor want to use the system?&amp;#x201D;\nBe focused on identifying the goal that is trying to be attained by using the system.\n
  69. Au d&amp;#xE9;but d&amp;#x2019;un semestre les &amp;#xE9;tudiants consultent un catalogue des cours propos&amp;#xE9;s. Le catalogue contient des informations sur le cours tels que le professeur responsable, les intervenants ainsi que les pr&amp;#xE9;-requis pour aider les &amp;#xE9;tudiants dans leur choix.\n\nLe syst&amp;#xE8;me doit permettre aux &amp;#xE9;tudiants de choisir quatre cours. De plus, les &amp;#xE9;tudiants doivent donner deux autres choix au cas o&amp;#xF9; un cours est complet ou est supprim&amp;#xE9;. Il ne peut y avoir plus de 15 &amp;#xE9;l&amp;#xE8;ves inscrits dans chaque cours mais un cours ne peut ouvrir s&amp;#x2019;il n&amp;#x2019;a pas au moins 6 inscrits.\n\nQuand l&amp;#x2019;inscription d&amp;#x2019;un &amp;#xE9;tudiant est termin&amp;#xE9;e, le syst&amp;#xE8;me des inscriptions envoie des informations au service comptable pour &amp;#xE9;mettre une facture.\n\nLes professeurs doivent pouvoir acc&amp;#xE9;der au syst&amp;#xE8;me pour indiquer les cours qu&amp;#x2019;ils sont en mesure d&amp;#x2019;assurer et pour conna&amp;#xEE;tre les &amp;#xE9;tudiants qui se sont inscrits &amp;#xE0; leur cours.\n\nLes &amp;#xE9;tudiants disposent d&amp;#x2019;une p&amp;#xE9;riode pendant laquelle ils peuvent changer leur choix, ils peuvent en outre ajouter ou abandonner certains cours.\n
  70. Use cases are a way to organize requirements from a user perspective. All the requirements for a user to accomplish a particular task are gathered together in a single use case. The benefits of use cases include:\nUse cases show why the system is needed. Use cases show what goals the users can accomplish by using the system.\nSystem requirements are placed in context. Each requirement is part of a logical sequence of actions to accomplish a goal of a user. \nUse cases are easy to understand. They express requirements from a user perspective and in the user&amp;#x2019;s own vocabulary. Traditional forms of requirements capture need some translation to make them accessibly by different stakeholders. When you translate something, information is often lost or misinterpreted. Use cases require no such translation. Therefore, they provide a more consistent and reliable form of requirement capture. \nUse cases are a means to communicate requirements between customers and developers to ensure that the system that is built is what the customer wants.\n
  71. The above is an example use case in a fire alarm monitoring system. The Supervisor is the person who administers the system and starts the monitoring. \nA passive sensor is a smoke detector that requires the system to ask for its status. An active sensor is a smoke detector that automatically sends its status to the system every 60 seconds. A hybrid sensor is a smoke detector that sends its status every 60 seconds, but it can also receive status requests from the system. In this system, if the system does not hear from it in 75 seconds then the system asks the sensor for its status.\nObserve how the top example conveys important characteristics of the actors surrounding the system. The information describing who starts the use case would be contained in the use-case description. For example: &amp;#x201C;This use case starts when the Supervisor activates the alarm monitoring.&amp;#x201D;\nThe bottom example only shows the actor that starts the use case. This means the way the actors communicate with the system is relegated to the description of the actor. But this form is usually more palatable for non-UML savvy stakeholders.\nArrowheads are optional in UML, only use them if they help to clarify the diagrams. Whatever standard you adopt, it should be clearly specified in Use-Case-Modeling Guidelines for the project. The Golden Rule for use-case-model guidelines: to effectively communicate the requirements to ALL stakeholders.\nNote: It is the exception to see two navigation arrows pointing towards a use case. Most of the time you have one arrow pointing in and the rest pointing out. The top example is present to reinforce that the navigation arrow is about indicating who initiates each interaction, not who obtains the goal or who initiates the use case.\n
  72. Attention jefais le choix de transforemer le catalogue comme qq d&amp;#x2019;existant d&amp;#x2019;ou l&amp;#x2019;acteur.\n\nAu d&amp;#xE9;but d&amp;#x2019;un semestre les &amp;#xE9;tudiants consultent un catalogue des cours propos&amp;#xE9;s. Le catalogue contient des informations sur le cours tels que le professeur responsable, les intervenants ainsi que les pr&amp;#xE9;-requis pour aider les &amp;#xE9;tudiants dans leur choix.\n\nLe syst&amp;#xE8;me doit permettre aux &amp;#xE9;tudiants de choisir quatre cours. De plus, les &amp;#xE9;tudiants doivent donner deux autres choix au cas o&amp;#xF9; un cours est complet ou est supprim&amp;#xE9;. Il ne peut y avoir plus de 15 &amp;#xE9;l&amp;#xE8;ves inscrits dans chaque cours mais un cours ne peut ouvrir s&amp;#x2019;il n&amp;#x2019;a pas au moins 6 inscrits.\n\nQuand l&amp;#x2019;inscription d&amp;#x2019;un &amp;#xE9;tudiant est termin&amp;#xE9;e, le syst&amp;#xE8;me des inscriptions envoie des informations au service comptable pour &amp;#xE9;mettre une facture.\n\nLes professeurs doivent pouvoir acc&amp;#xE9;der au syst&amp;#xE8;me pour indiquer les cours qu&amp;#x2019;ils sont en mesure d&amp;#x2019;assurer et pour conna&amp;#xEE;tre les &amp;#xE9;tudiants qui se sont inscrits &amp;#xE0; leur cours.\n\nLes &amp;#xE9;tudiants disposent d&amp;#x2019;une p&amp;#xE9;riode pendant laquelle ils peuvent changer leur choix, ils peuvent en outre ajouter ou abandonner certains cours.\n\n\n\nAu d&amp;#xE9;but d&amp;#x2019;un semestre les &amp;#xE9;tudiants consultent un catalogue des cours propos&amp;#xE9;s. Le catalogue contient des informations sur le cours tels que le professeur responsable, les intervenants ainsi que les pr&amp;#xE9;-requis pour aider les &amp;#xE9;tudiants dans leur choix.\n\nLe syst&amp;#xE8;me doit permettre aux &amp;#xE9;tudiants de choisir quatre cours. De plus, les &amp;#xE9;tudiants doivent donner deux autres choix au cas o&amp;#xF9; un cours est complet ou est supprim&amp;#xE9;. Il ne peut y avoir plus de 15 &amp;#xE9;l&amp;#xE8;ves inscrits dans chaque cours mais un cours ne peut ouvrir s&amp;#x2019;il n&amp;#x2019;a pas au moins 6 inscrits.\n\nQuand l&amp;#x2019;inscription d&amp;#x2019;un &amp;#xE9;tudiant est termin&amp;#xE9;e, le syst&amp;#xE8;me des inscriptions envoie des informations au service comptable pour &amp;#xE9;mettre une facture.\n\nLes professeurs doivent pouvoir acc&amp;#xE9;der au syst&amp;#xE8;me pour indiquer les cours qu&amp;#x2019;ils sont en mesure d&amp;#x2019;assurer et pour conna&amp;#xEE;tre les &amp;#xE9;tudiants qui se sont inscrits &amp;#xE0; leur cours.\n\nLes &amp;#xE9;tudiants disposent d&amp;#x2019;une p&amp;#xE9;riode pendant laquelle ils peuvent changer leur choix, ils peuvent en outre ajouter ou abandonner certains cours.\n
  73. \n
  74. \n
  75. Here is an example that raises questions that need to be answered by the customer or user:\nAre the use cases too small?\nDoes the diagram cover all activities? \nHow do you know what is done in each use case?\nYou might notice that the Student and the Professor interact with the system during Close Registration. Does this mean that they have to be present when registration closes? No, it doesn&amp;#x2019;t. They are informed of the outcome through e-mail or postal mail. Another technique is to make the e-mail server or the postal service an actor. There is no right or wrong answer; both are correct. Use whichever method more clearly conveys your requirements.\n
  76. The use-case model consists of both diagrams and text. The diagrams give a visual overview of the system. The text gives descriptions of the actors and the use cases.\nThe majority of the work in writing use cases is spent writing the textual portion of the use case. \nUse cases involve writing text. Drawing the pictures is only a small part of the effort. Typically, more than 80 percent of all effort during requirements capture is writing the textual description of what happens in each use case, the non-functional requirements, and rules. \nUML does NOT specify how the text of a use case should be structured, organized, or written.\nHow you write use cases will have a large impact on how easy they are to read, use, and test.\n
  77. \n
  78. \n
  79. actuers externes : porteurs de carte \nDistribut et lecteur sont interne pas des acteurs : sauf si nous ne gerons que la partie interne.\ncarte : oui et non. C&amp;#x2019;est un acteur physique que l&amp;#x2019;on garde ou non...\nmais aussi des clients...\nSyst&amp;#xE8;me d&amp;#x2019;autorisation\nSysteme d&amp;#x2019;information de la banque\n\n\n\n\n\n\n
  80. \n
  81. \n
  82. \n
  83. \n
  84. \n
  85. This list of actor checkpoints is a summary of the list in the IBM&amp;#xAE; Rational Unified Process&amp;#xAE; (RUP &amp;#xAE;&amp;#xF87F;). \n\n
  86. This list of actor checkpoints is a summary of the list in the IBM&amp;#xAE; Rational Unified Process&amp;#xAE; (RUP &amp;#xAE;&amp;#xF87F;). \n\n
  87. This list of actor checkpoints is a summary of the list in the IBM&amp;#xAE; Rational Unified Process&amp;#xAE; (RUP &amp;#xAE;&amp;#xF87F;). \n\n\n Tous les CRUD use cases ont &amp;#xE9;t&amp;#xE9; &amp;#xE9;limin&amp;#xE9;s.\n Create, Retrieve, Update, Delete\n
  88. This list of actor checkpoints is a summary of the list in the IBM&amp;#xAE; Rational Unified Process&amp;#xAE; (RUP &amp;#xAE;&amp;#xF87F;). \n\n\nUn diagramme de cas d&apos;utilisation doit toujours rester simple\n Donner un nom parlant (verbe) &amp;#xE0; chaque cas d&apos;utilisation\n Compl&amp;#xE9;ter la sp&amp;#xE9;cification du cas d&apos;utilisation\n Par une description textuelle\n Eventuellement &amp;#xE0; l&apos;aide du diagramme d&apos;activit&amp;#xE9;\n\n Ne pas mod&amp;#xE9;liser &amp;#xE0; un niveau de d&amp;#xE9;tail trop pr&amp;#xE9;cis\n\n\n\n\n Ne pas mod&amp;#xE9;liser en dehors de l&apos;application\n
  89. This list of actor checkpoints is a summary of the list in the IBM&amp;#xAE; Rational Unified Process&amp;#xAE; (RUP &amp;#xAE;&amp;#xF87F;). \n\n\nUn diagramme de cas d&apos;utilisation doit toujours rester simple\n Donner un nom parlant (verbe) &amp;#xE0; chaque cas d&apos;utilisation\n Compl&amp;#xE9;ter la sp&amp;#xE9;cification du cas d&apos;utilisation\n Par une description textuelle\n Eventuellement &amp;#xE0; l&apos;aide du diagramme d&apos;activit&amp;#xE9;\n\n Ne pas mod&amp;#xE9;liser &amp;#xE0; un niveau de d&amp;#xE9;tail trop pr&amp;#xE9;cis\n\n\n\n\n Ne pas mod&amp;#xE9;liser en dehors de l&apos;application\n
  90. Business value is based on increased revenues, decreased expenses, or intangible benefits. Where disagreements occur, quantify and compare dollar values.\nRisk is based on the known architectural risks associated with implementing the functionality in the use case, the degree of complexity of development, or the amount of uncertainty about the solution. For packaged or commercial off-the-shelf (COTS) solutions, consider integration risks as primary.\nTime-limit the sessions for assessing business values and technical risks.\nAssign a value of high, medium, or low to the business value or risk.\nAs a result of assessing business value and technical risk, you will know which use cases to outline and define in detail first. \n
  91. This list of actor checkpoints is a summary of the list in the IBM&amp;#xAE; Rational Unified Process&amp;#xAE; (RUP &amp;#xAE;&amp;#xF87F;). \n\n\nUn diagramme de cas d&apos;utilisation doit toujours rester simple\n Donner un nom parlant (verbe) &amp;#xE0; chaque cas d&apos;utilisation\n Compl&amp;#xE9;ter la sp&amp;#xE9;cification du cas d&apos;utilisation\n Par une description textuelle\n Eventuellement &amp;#xE0; l&apos;aide du diagramme d&apos;activit&amp;#xE9;\n\n Ne pas mod&amp;#xE9;liser &amp;#xE0; un niveau de d&amp;#xE9;tail trop pr&amp;#xE9;cis\n\n\n\n\n Ne pas mod&amp;#xE9;liser en dehors de l&apos;application\n
  92. This list of actor checkpoints is a summary of the list in the IBM&amp;#xAE; Rational Unified Process&amp;#xAE; (RUP &amp;#xAE;&amp;#xF87F;). \n\n\nUn diagramme de cas d&apos;utilisation doit toujours rester simple\n Donner un nom parlant (verbe) &amp;#xE0; chaque cas d&apos;utilisation\n Compl&amp;#xE9;ter la sp&amp;#xE9;cification du cas d&apos;utilisation\n Par une description textuelle\n Eventuellement &amp;#xE0; l&apos;aide du diagramme d&apos;activit&amp;#xE9;\n\n Ne pas mod&amp;#xE9;liser &amp;#xE0; un niveau de d&amp;#xE9;tail trop pr&amp;#xE9;cis\n\n\n\n\n Ne pas mod&amp;#xE9;liser en dehors de l&apos;application\n
  93. Here is an example that raises questions that need to be answered by the customer or user:\nAre the use cases too small?\nDoes the diagram cover all activities? \nHow do you know what is done in each use case?\nYou might notice that the Student and the Professor interact with the system during Close Registration. Does this mean that they have to be present when registration closes? No, it doesn&amp;#x2019;t. They are informed of the outcome through e-mail or postal mail. Another technique is to make the e-mail server or the postal service an actor. There is no right or wrong answer; both are correct. Use whichever method more clearly conveys your requirements.\n
  94. In all but the most trivial of systems, use cases are not written in one sitting. As with any iterative process, a use case evolves from the spark of an idea to a fully detailed description of how your system behaves.\n1. First, you find the actors of the system.\n2. Next, you find and briefly describe the use case. A brief description describes the goal in two or three sentences. When finding use cases, you may find additional actors that require you to refine the list of actors.\n3. The next stage of evolution is to outline the use case. This can be a bulleted list of just the basic flow. You may also choose to identify (not outline) possible alternate flows. This enables you to gain an understanding of the potential size and complexity of the use case. When outlining the use case, you may end up merging or splitting use cases.\n4. Finally, you fully detail the use case, but iteratively. You identify particular flows for development in an iteration and then fully describe and implement just those flows. You then identify flows for subsequent iterations and fully detail and implement those during that iteration. At the end of the project, you have all of your use cases fully detailed.\nRemember, the use case writing process is an iterative process. You will likely go through many cycles of refinement before you complete your use case.\n
  95. Developing a use-case sequence of actions is an iterative process. Start by developing an outline or draft, such as the one on this page. Later, add the descriptions. The outlines are not official documents, but merely a start toward developing a document. \nThe basic flow shows the major steps in accomplishing the goal of the use case.\n The alternative flows show alternatives behavior (what may go wrong and optional behavior). At this point in the process, it is enough to identify the most significant alternatives without describing them in detail.\n\nThe outline of the flow of events for a use case has two main sections:\nBasic Flow of Events\nAlternative Flow of Events\nThe outline is used as a base when you start to write the full use-case specification.\nStructure the flows in such a way that it is easy to follow the different scenarios and to be able to understand what happens when alternatives occur and where they pick up and finish.\nThe basic flow of events should be relatively short and easy to read, like a single story line. The basic flow should show the steps needed to achieve the main goal of the use case. \nMost of the other details go into alternative flows. You can think of the alternative flows as &amp;#x201C;detours&amp;#x201D; from the basic flow of events, some that return to the basic flow of events and some that end the execution of the use case. In the diagram on the slide, the straight arrow represents the basic flow and the curves represent alternative paths in relation to the basic flow. Examples of different kinds of alternative flows for the Register for Courses use case are:\nRegular variants: Handle freshman enrollments differently.\nOdd cases: Handle registering for more than 25 credit hours differently.\nExceptional (error) flows: Invalid student ID number.\nNote: The diagram on the slide is informational only and is not a valid UML diagram.\n
  96. Developing a use-case sequence of actions is an iterative process. Start by developing an outline or draft, such as the one on this page. Later, add the descriptions. The outlines are not official documents, but merely a start toward developing a document. \nThe basic flow shows the major steps in accomplishing the goal of the use case.\n The alternative flows show alternatives behavior (what may go wrong and optional behavior). At this point in the process, it is enough to identify the most significant alternatives without describing them in detail.\n\nThe outline of the flow of events for a use case has two main sections:\nBasic Flow of Events\nAlternative Flow of Events\nThe outline is used as a base when you start to write the full use-case specification.\nStructure the flows in such a way that it is easy to follow the different scenarios and to be able to understand what happens when alternatives occur and where they pick up and finish.\nThe basic flow of events should be relatively short and easy to read, like a single story line. The basic flow should show the steps needed to achieve the main goal of the use case. \nMost of the other details go into alternative flows. You can think of the alternative flows as &amp;#x201C;detours&amp;#x201D; from the basic flow of events, some that return to the basic flow of events and some that end the execution of the use case. In the diagram on the slide, the straight arrow represents the basic flow and the curves represent alternative paths in relation to the basic flow. Examples of different kinds of alternative flows for the Register for Courses use case are:\nRegular variants: Handle freshman enrollments differently.\nOdd cases: Handle registering for more than 25 credit hours differently.\nExceptional (error) flows: Invalid student ID number.\nNote: The diagram on the slide is informational only and is not a valid UML diagram.\n
  97. Developing a use-case sequence of actions is an iterative process. Start by developing an outline or draft, such as the one on this page. Later, add the descriptions. The outlines are not official documents, but merely a start toward developing a document. \nThe basic flow shows the major steps in accomplishing the goal of the use case.\n The alternative flows show alternatives behavior (what may go wrong and optional behavior). At this point in the process, it is enough to identify the most significant alternatives without describing them in detail.\n\nThe outline of the flow of events for a use case has two main sections:\nBasic Flow of Events\nAlternative Flow of Events\nThe outline is used as a base when you start to write the full use-case specification.\nStructure the flows in such a way that it is easy to follow the different scenarios and to be able to understand what happens when alternatives occur and where they pick up and finish.\nThe basic flow of events should be relatively short and easy to read, like a single story line. The basic flow should show the steps needed to achieve the main goal of the use case. \nMost of the other details go into alternative flows. You can think of the alternative flows as &amp;#x201C;detours&amp;#x201D; from the basic flow of events, some that return to the basic flow of events and some that end the execution of the use case. In the diagram on the slide, the straight arrow represents the basic flow and the curves represent alternative paths in relation to the basic flow. Examples of different kinds of alternative flows for the Register for Courses use case are:\nRegular variants: Handle freshman enrollments differently.\nOdd cases: Handle registering for more than 25 credit hours differently.\nExceptional (error) flows: Invalid student ID number.\nNote: The diagram on the slide is informational only and is not a valid UML diagram.\n
  98. Developing a use-case sequence of actions is an iterative process. Start by developing an outline or draft, such as the one on this page. Later, add the descriptions. The outlines are not official documents, but merely a start toward developing a document. \nThe basic flow shows the major steps in accomplishing the goal of the use case.\n The alternative flows show alternatives behavior (what may go wrong and optional behavior). At this point in the process, it is enough to identify the most significant alternatives without describing them in detail.\n\nThe outline of the flow of events for a use case has two main sections:\nBasic Flow of Events\nAlternative Flow of Events\nThe outline is used as a base when you start to write the full use-case specification.\nStructure the flows in such a way that it is easy to follow the different scenarios and to be able to understand what happens when alternatives occur and where they pick up and finish.\nThe basic flow of events should be relatively short and easy to read, like a single story line. The basic flow should show the steps needed to achieve the main goal of the use case. \nMost of the other details go into alternative flows. You can think of the alternative flows as &amp;#x201C;detours&amp;#x201D; from the basic flow of events, some that return to the basic flow of events and some that end the execution of the use case. In the diagram on the slide, the straight arrow represents the basic flow and the curves represent alternative paths in relation to the basic flow. Examples of different kinds of alternative flows for the Register for Courses use case are:\nRegular variants: Handle freshman enrollments differently.\nOdd cases: Handle registering for more than 25 credit hours differently.\nExceptional (error) flows: Invalid student ID number.\nNote: The diagram on the slide is informational only and is not a valid UML diagram.\n
  99. Developing a use-case sequence of actions is an iterative process. Start by developing an outline or draft, such as the one on this page. Later, add the descriptions. The outlines are not official documents, but merely a start toward developing a document. \nThe basic flow shows the major steps in accomplishing the goal of the use case.\n The alternative flows show alternatives behavior (what may go wrong and optional behavior). At this point in the process, it is enough to identify the most significant alternatives without describing them in detail.\n\nThe outline of the flow of events for a use case has two main sections:\nBasic Flow of Events\nAlternative Flow of Events\nThe outline is used as a base when you start to write the full use-case specification.\nStructure the flows in such a way that it is easy to follow the different scenarios and to be able to understand what happens when alternatives occur and where they pick up and finish.\nThe basic flow of events should be relatively short and easy to read, like a single story line. The basic flow should show the steps needed to achieve the main goal of the use case. \nMost of the other details go into alternative flows. You can think of the alternative flows as &amp;#x201C;detours&amp;#x201D; from the basic flow of events, some that return to the basic flow of events and some that end the execution of the use case. In the diagram on the slide, the straight arrow represents the basic flow and the curves represent alternative paths in relation to the basic flow. Examples of different kinds of alternative flows for the Register for Courses use case are:\nRegular variants: Handle freshman enrollments differently.\nOdd cases: Handle registering for more than 25 credit hours differently.\nExceptional (error) flows: Invalid student ID number.\nNote: The diagram on the slide is informational only and is not a valid UML diagram.\n
  100. Developing a use-case sequence of actions is an iterative process. Start by developing an outline or draft, such as the one on this page. Later, add the descriptions. The outlines are not official documents, but merely a start toward developing a document. \nThe basic flow shows the major steps in accomplishing the goal of the use case.\n The alternative flows show alternatives behavior (what may go wrong and optional behavior). At this point in the process, it is enough to identify the most significant alternatives without describing them in detail.\n\nThe outline of the flow of events for a use case has two main sections:\nBasic Flow of Events\nAlternative Flow of Events\nThe outline is used as a base when you start to write the full use-case specification.\nStructure the flows in such a way that it is easy to follow the different scenarios and to be able to understand what happens when alternatives occur and where they pick up and finish.\nThe basic flow of events should be relatively short and easy to read, like a single story line. The basic flow should show the steps needed to achieve the main goal of the use case. \nMost of the other details go into alternative flows. You can think of the alternative flows as &amp;#x201C;detours&amp;#x201D; from the basic flow of events, some that return to the basic flow of events and some that end the execution of the use case. In the diagram on the slide, the straight arrow represents the basic flow and the curves represent alternative paths in relation to the basic flow. Examples of different kinds of alternative flows for the Register for Courses use case are:\nRegular variants: Handle freshman enrollments differently.\nOdd cases: Handle registering for more than 25 credit hours differently.\nExceptional (error) flows: Invalid student ID number.\nNote: The diagram on the slide is informational only and is not a valid UML diagram.\n
  101. Developing a use-case sequence of actions is an iterative process. Start by developing an outline or draft, such as the one on this page. Later, add the descriptions. The outlines are not official documents, but merely a start toward developing a document. \nThe basic flow shows the major steps in accomplishing the goal of the use case.\n The alternative flows show alternatives behavior (what may go wrong and optional behavior). At this point in the process, it is enough to identify the most significant alternatives without describing them in detail.\n\nThe outline of the flow of events for a use case has two main sections:\nBasic Flow of Events\nAlternative Flow of Events\nThe outline is used as a base when you start to write the full use-case specification.\nStructure the flows in such a way that it is easy to follow the different scenarios and to be able to understand what happens when alternatives occur and where they pick up and finish.\nThe basic flow of events should be relatively short and easy to read, like a single story line. The basic flow should show the steps needed to achieve the main goal of the use case. \nMost of the other details go into alternative flows. You can think of the alternative flows as &amp;#x201C;detours&amp;#x201D; from the basic flow of events, some that return to the basic flow of events and some that end the execution of the use case. In the diagram on the slide, the straight arrow represents the basic flow and the curves represent alternative paths in relation to the basic flow. Examples of different kinds of alternative flows for the Register for Courses use case are:\nRegular variants: Handle freshman enrollments differently.\nOdd cases: Handle registering for more than 25 credit hours differently.\nExceptional (error) flows: Invalid student ID number.\nNote: The diagram on the slide is informational only and is not a valid UML diagram.\n
  102. This is an example of a step-by-step outline for the Register for Courses use case. The basic flow shows the major steps. The alternative flows show optional or conditional behavior.\nNotice the level of detail in this example. Remember, this is just a brief step-by-step outline to help you understand what functions are contained in the use case. These steps are described further in a later module.\n\nThis is an example of a step-by-step outline for the Register for Courses use case. The basic flow shows the major steps. The alternative flows show optional or conditional behavior.\nNotice the level of detail in this example. Remember, this is just a brief step-by-step outline to help you understand what functions are contained in the use case. These steps are described further in a later module.\n
  103. Reasons to outline your use cases:\nIterative development reduces risk. For the same reason that you do not implement the whole system at once, you do not develop the detailed requirements all at once.\nAvoid writing too much detail too early.\nYou do not know everything at first. Outlining helps you discover what you don&amp;#x2019;t know.\nOutlining use cases creates a rough draft to use as a starting point for fully specifying your use cases.\nOutlining helps determine whether the use case is too small on its own or too big to be just one use case. It might also help you decide whether the use case is actually more than just one use case. \nAfter you outline your steps, you might find that they really belong in another use case. Also, if the outline shows that the use case does not have much to it, it may not be a use case at all. \nOutlining adds value to finding all possible alternate flows.\n
  104. This is an example of a step-by-step outline for the Register for Courses use case. The basic flow shows the major steps. The alternative flows show optional or conditional behavior.\nNotice the level of detail in this example. Remember, this is just a brief step-by-step outline to help you understand what functions are contained in the use case. These steps are described further in a later module.\n
  105. A use-case scenario describes an instance of using the system (an instance of a use case). It is one path through a use case that flows from its beginning to one of its end points.\nEach use case has a web of flows of events, with a scenario as just one description of a particular path through the web. The scenario might involve the basic flow and any number of alternative flows in any number of combinations.\nQuestion: How many scenarios do you need? \nSimple answer: As many as you need to understand the system that you are developing. \n
  106. Note: The RUP use-case specification template contains a section for listing key scenarios. \nDocumenting scenarios is useful because, although you write flows (basic, alternative, subflows) in a use case, you implement and test scenarios.\nEach scenario captures a family of test cases. Each test case in the family follows the same path through the use case, but uses different data values to ensure that all of the boundary conditions are tested.\nIn iterative development, when software architects propose the technical contents and the order of successive iterations, they select a certain number of architecturally significant scenarios and use cases to analyze and design first.\nAccording to Use Case Modeling, a book by Kurt Bittner and Ian Spence, capturing scenarios is useful for these reasons:\nThe scenarios will match your test cases.\nScenarios are what actually gets performed, so they are useful for discussing what the system will do in practice.\nScenarios are useful for analysis and design, because they help the developers think about how the system will be used.\n
  107. Capture scenarios in a separate section of your use-case specification or as part of your test cases. The benefit of capturing the scenarios in the use-case specification is that all of the information required for analysis, design, and testing is then included with the use-case specification.\nGive the scenario a descriptive name and list the flows (in order) that make up the scenario.\nIt&amp;#x2019;s a good practice to elaborate the scenarios of the interesting and high-risk use cases. You can use scenarios to understand, as well as to validate, the use-case flows of events. \nSome people write scenarios first and then extract use cases, but others find use cases first and validate those use cases by writing scenarios. Scenarios make excellent test cases.\nScenarios do not contain details of the system input or output data. That information forms part of your test cases.\n
  108. This is an example of a step-by-step outline with some key scenarios identified for the Register for Courses use case. \n
  109. In the process of writing use cases, functional and non-functional requirements specific to a use case will be captured in the use-case specification. For those that cannot be applied to specific use cases, you can put them in a document such as the Supplementary Specifications.\nAlthough many of the functional requirements will be documented in use cases, there are some functional requirements that cannot be applied to specific use cases. \n\nAmong those are reporting, auditing, printing, security, licensing support or enforcement, and authentication requirements. Document these functional requirements in the Supplementary Specification. \n
  110. In the process of writing use cases, functional and non-functional requirements specific to a use case will be captured in the use-case specification. For those that cannot be applied to specific use cases, you can put them in a document such as the Supplementary Specifications.\nAlthough many of the functional requirements will be documented in use cases, there are some functional requirements that cannot be applied to specific use cases. Among those are reporting, auditing, printing, security, licensing support or enforcement, and authentication requirements. Document these functional requirements in the Supplementary Specification. \n
  111. \n
  112. \n
  113. \n
  114. \n
  115. \n
  116. \n
  117. \n
  118. \n
  119. \n
  120. \n
  121. \n
  122. \n
  123. \n
  124. \n
  125. Detailing the use-case description is where the &amp;#x201C;real work&amp;#x201D; in use-case modeling occurs. The outline of the flow of events in each use case that you developed earlier lacks important details. The main purpose of detailing a use case is to elaborate the step-by-step outline of the flow of events. \nWithout a detailed description of the flows of events, it is nearly impossible to implement a solution. The reason is that the use-case outline does not contain any real software requirements. Instead, the outline just contains a high-level description of the flows.\nThe detailed flow of events includes what the actor does and what the system does in response. \n
  126. \n
  127. A precondition for a use case is a condition in the system that must be true before the use case can begin. For example, the list of course offerings must be available before a student can register for courses. Otherwise, the student could not select from the course list.\nA precondition is not the event that starts the use case. For example, if a use case is written in such a way that logging on to the system is the first event in the use case, then logging on is not a precondition. But if a use case is written so that logging on must happen before the use case begins, then &amp;#x201C;The user has logged on to the system&amp;#x201D; would be a precondition.\nPreconditions reduce the need for validation inside the use-case flows. In this example, you do not need to test whether the course offerings are available anywhere in the use-case flows of events, because, by definition, they must have been available or the use case could not execute.\nPreconditions do not describe things outside of the system. For example, &amp;#x201C;The customer has a valid PIN&amp;#x201D; would be an invalid precondition. Validating the PIN is something that the system does in the use case.\nPreconditions are optional. They are used only if they are needed for clarification.\nNote: Preconditions can also be used at the beginning of an alternative flow or subflow. More commonly, they are used only on the basic flow. An example of using a precondition on an alternative flow is to describe security. If only certain actors can perform a given flow, you could attach a precondition to that flow to ensure that the user has the appropriate authentication to perform the flow.\n
  128. \n
  129. This is a template for a Use-Case Specification.\nFor each use case, start with the step-by-step outline and gradually add detail to each step. You want to understand what really happens so you do not miss anything. Typically, you begin with refining the basic flow, and then refine the alternative flows. \nWork with system users to revise and detail the outline. Expect to revise the outline and the details many times.\nThere is no minimum or maximum size for a Use-Case Specification. It needs to be big enough to contain an unambiguous description of how the system behaves, yet short enough to be as concise as you can . Be sure that your description is complete and that you have answered all of the questions that people may have about the events in the use case. \nThe Use-Case Specification describes the details of a particular use case. In addition to the Flow of Events, there are other properties that detail a use case. It is best to use a standard template for your use cases, such as the one shown here (from the IBM&amp;#xAE; Rational Unified Process&amp;#xAE;). Regardless of whether you have any properties within the section, use the standard outline.\n
  130. When you detail each step in the outline, be sure to describe the flow of events, not only what the system is doing. A suggestion for how to enforce this is to start every step with &amp;#x201C;When the [actor] ....&amp;#x201D; \nWhen possible, make each step in the flow of events show a roundtrip of events, usually in the form of messages: \nWhat the actor does: &lt;Actor&gt; sends a message to &lt;System&gt;, and....\nWhat the system does in response: &lt;System&gt; sends a message to &lt;An Actor&gt;....\nMaking each step a roundtrip ensures testability, ensures adherence to the purpose of a use case, and makes sequence diagrams easier to develop and read. \nSome interactions are system-controlled. That is, after the user&amp;#x2019;s request that begins the use case, the system controls the interaction: The system asks for information and the user supplies information, and so on. In these cases, a roundtrip within a step would begin with system actions and then have the user respond.\n
  131. The distinction between chooses and decides: \nDecides can be totally unrelated to the system. For example, the Professor can decide to submit grades while eating breakfast or while driving to campus. \nChooses, on the other hand, implies an interaction with the system.\n
  132. \n
  133. \n
  134. \n
  135. \n
  136. \n
  137. \n
  138. \n
  139. \n
  140. \n
  141. Here is a list of questions to help you make decisions about the details in the flow of events.\nAlternative flows describe how the system should behave when things go wrong or when unusual things happen. \nWhen working on the alternative flows, questions regarding the behavior of the system are bound to surface. List these questions and have the system users answer what the system is supposed to do, and how they expect to interact with the system in each scenario. Understanding the alternatives is an important step in clarifying the requirements. \nAt this point in the process, however, it is enough to identify the alternatives without describing them in detail.\n
  142. \n
  143. A postcondition defines the state that the system is in at the end of a use case. In many cases, you can omit the postcondition entirely when the result of the use case is obvious or when there is no significant state change in the system. \nWhen you need to call attention to the different conditions that may exist when a use case completes, you can enumerate all the postconditions. \nPostconditions can be a powerful tool for developing use cases. You must first define what the use case is supposed to achieve (the postcondition). Then describe the different ways to reach this condition (the flow of events needed).\n
  144. \n
  145. \n
  146. \n
  147. \n
  148. \n
  149. \n
  150. A use-case scenario describes an instance of using the system (an instance of a use case). It is one path through a use case that flows from its beginning to one of its end points.\nEach use case has a web of flows of events, with a scenario as just one description of a particular path through the web. The scenario might involve the basic flow and any number of alternative flows in any number of combinations.\nQuestion: How many scenarios do you need? \nSimple answer: As many as you need to understand the system that you are developing. \n\nNote: The RUP use-case specification template contains a section for listing key scenarios. \nDocumenting scenarios is useful because, although you write flows (basic, alternative, subflows) in a use case, you implement and test scenarios.\nEach scenario captures a family of test cases. Each test case in the family follows the same path through the use case, but uses different data values to ensure that all of the boundary conditions are tested.\nIn iterative development, when software architects propose the technical contents and the order of successive iterations, they select a certain number of architecturally significant scenarios and use cases to analyze and design first.\nAccording to Use Case Modeling, a book by Kurt Bittner and Ian Spence, capturing scenarios is useful for these reasons:\nThe scenarios will match your test cases.\nScenarios are what actually gets performed, so they are useful for discussing what the system will do in practice.\nScenarios are useful for analysis and design, because they help the developers think about how the system will be used.\n
  151. A use-case instance describes one particular path through the flows of events described in a use case. It is a specific sequence of actions that illustrates the behavior of the system. This is also called a scenario. In the example here, the sketch of Scenario 1 for the Register for Courses use case shows a Student interacting with the Course Registration System and successfully enrolling in a course the first time. Scenario 2 shows a Student interacting with the Course Registration System and entering an invalid subject; that student must re-enter the subject before successfully getting the course list.\nA use case defines a set of related scenarios. A use case represents all the possible sequences that might happen until the resulting value is achieved or until the system terminates the attempt. The Register for Courses use case represents both of these sequences, and all the other possible sequences of interactions that may occur when a Student tries to enroll in a course.\nUsers and stakeholders can often identify the sequence of actions they want to perform to obtain a result. Asking stakeholders for the sequence of actions they perform is a good way to start identifying the steps in a use case.\n
  152. Use cases typically have a great deal of cross-referenced information within them. The overhead of maintaining this cross-referencing is what typically causes use cases to become out of date. To make maintenance easier, refer to a use case step by its label rather than by number. If you change the text of the label, then the location that references the label also needs to be updated.\nWord processors and page layout software , such as Microsoft&amp;#xAE; Word and Adobe&amp;#xAE; FrameMaker&amp;#xAE;, have book-marking and cross-referencing capabilities that can make the maintenance of cross-references easier. \n\nThis is an example of how to write a subflow. Notice that subflows are in a separate section in the Use-Case Specification. In this style, the subflow names have an identifier in front of them (S1, S2 , and so on) to help identify them as subflows.\nUnlike alternative flows, subflows do not need a line that says where they return to, because they always return to the line after the line from which they were called. \nIn this example, when the subflow S1: Obtain Course Information completes, the flow will resume at 4. Select Courses.\n\n\nA complex flow of events should be further structured into subflows. The main goal should be to improve the readability of the text. Subflows can be invoked many times from many places. Remember that the use case can perform subflows in optional sequences, in loops, or even several at the same time.\nThe difference between an alternative flow and a subflow is that alternative flows are insert themselves into another flow. The flow it inserts itself into has no knowledge of the alternative flow. An alternative flow may also resume at any place within the use case.\nA subflow is explicitly called from a flow. When a subflow completes, it always returns to the line after the line that it was called from. It is similar in concept to a subroutine call in some programming languages.\nSubflows are not listed as part of a scenario. By definition, if the calling flow is in the scenario, the subflow is also in the scenario.\nAs with any other flow, a subflow may have alternative flows.\n\n
  153. \n
  154. \n
  155. \n
  156. A postcondition defines the state that the system is in at the end of a use case. In many cases, you can omit the postcondition entirely when the result of the use case is obvious or when there is no significant state change in the system. \nWhen you need to call attention to the different conditions that may exist when a use case completes, you can enumerate all the postconditions. \nPostconditions can be a powerful tool for developing use cases. You must first define what the use case is supposed to achieve (the postcondition). Then describe the different ways to reach this condition (the flow of events needed).\n
  157. One of the most difficult aspects of writing good use cases is capturing the correct level of detail.\nIt is important to capture all of the requirements but not stray into designing the system or the user interface.\nBoth end users and subject-matter experts are stakeholders of the system, thus they can drive requirements from different perspectives. When using an ATM to withdraw cash, end users may be interested only that the machine dispenses the right amount of money and prints a receipt. But a subject-matter expert is interested in far more. For instance, the banking subject-matter expert is interested in what the ATM does to ensure that the transaction is recorded correctly and that the transaction is communicated to the bank for processing. Therefore, a use case should capture requirements from different stakeholders. (Bittner and Spence, 2002)\n
  158. There are many reasons why a project may be pushed or pulled toward a specific level of detail with use cases.\nDevelopers&amp;#x2019; demands &amp;#x2013; Developers rely on use cases as their only user interface or business rule definition, thus they demand more and more detail in them so they can develop effectively.\nTransition from old requirements process &amp;#x2013; Most older styles of gathering requirements for software projects involve substantial hierarchies of more and more decomposed requirements. \nWaterfall approaches &amp;#x2013; In waterfall methods, analysts are pressured early in the project lifecycle to capture all of the requirements to 100% completeness that anyone might need downstream. This leads to large, very detailed requirement sets.\nLow modeling sophistication of the team &amp;#x2013; Object-Oriented Analysis and Design (OOAD) associates responsibilities with components in the design processes through use case realizations in sequence diagrams and class models. User interface design can be similarly broken down using more systematic approaches. Use cases often include information that should be in the intermediate design artifacts.\nExperienced analysts &amp;#x2013; The more experienced the analysts are in multiple aspects of software development, the better they understand the implications of inappropriate level of detail.\nExperienced architects &amp;#x2013;Software architects who understand the appropriate level of detail for use cases as input to their fundamental work will be the most powerful force for better practices.\nBetter techniques and methods &amp;#x2013; If the method calls for useful intermediate work products and artifacts and provides guidance on how and when to create them, that&amp;#x2019;s a powerful force for appropriate level of detail.\n
  159. User Story vs Use Case\n\nOn m&amp;#x2019;a souvent pos&amp;#xE9; la question :C&amp;#x2019;est quoi la diff&amp;#xE9;rence entre un use case et une user story? La r&amp;#xE9;ponse n&amp;#x2019;est pas simple pour moi. Bien que la diff&amp;#xE9;rence de concept semble claire, dans les faits, c&amp;#x2019;est plus complexe.On r&amp;#xE9;vise:Definition wikipedia:User Story&amp;#xAB; Une user story (histoire utilisateur) est une exigence logicielle formul&amp;#xE9;e en une ou plusieurs phrases dans le langage de tous les jours ou celui li&amp;#xE9; au m&amp;#xE9;tier l&amp;#x2019;utilisateur. Les user stories sont utilis&amp;#xE9;es dans le d&amp;#xE9;veloppement logiciel dit Agile comme sp&amp;#xE9;cifications (en m&amp;#xEA;me temps que les tests d&amp;#x2019;acceptance). Le formalisme est limit&amp;#xE9; &amp;#xE0; un carte de type post-it. &amp;#xBB;Use Case&amp;#xAB; Un use case (cas d&amp;#x2019;utilisation) dans l&amp;#x2019;ing&amp;#xE9;nierie logicielle et syst&amp;#xE8;me est une description du comportement d&amp;#x2019;un syst&amp;#xE8;me en r&amp;#xE9;ponse &amp;#xE0; une requ&amp;#xEA;te externe au syst&amp;#xE8;me lui-m&amp;#xEA;me. En d&amp;#x2019;autres termes, le use case d&amp;#xE9;crit &amp;#xAB; qui &amp;#xBB; fait &amp;#xAB; quoi &amp;#xBB; avec le syst&amp;#xE8;me en question. La technique des use case est utilis&amp;#xE9;e pour d&amp;#xE9;finir les exigences de comportement d&amp;#x2019;un syst&amp;#xE8;me en d&amp;#xE9;taillant les exigences fonctionnelles avec un approche sc&amp;#xE9;narios. &amp;#xBB;Wikipedia en propose m&amp;#xEA;me la comparaison:&amp;#xAB; Bien que les use cases et user stories proposent tous les deux une solution de d&amp;#xE9;finition des exigences utilisateur en terme d&amp;#x2019;interactions entre celui-ci et le syst&amp;#xE8;me, il y a des diff&amp;#xE9;rences majeures entre eux.Les user stories proposent un format l&amp;#xE9;ger et facile &amp;#xE0; comprendre de l&amp;#x2019;information. Elles sont la plus part du temps formul&amp;#xE9;es dans le langage de tous les jours de l&amp;#x2019;utilisateur et contiennent peu de d&amp;#xE9;tail. Elles doivent aider le lecteur &amp;#xE0; comprendre ce que le logiciel doit faire.Les use cases, eux, d&amp;#xE9;crivent un process et le d&amp;#xE9;taillent pas &amp;#xE0; pas, ils sont plus formels. Un use case doit fournir le niveau d&amp;#xE9;tail suffisant pour &amp;#xEA;tre compris seul. Un use case est d&amp;#xE9;crit comme &amp;#xAB; une description g&amp;#xE9;n&amp;#xE9;rale des interactions entre le syst&amp;#xE8;me et un ou plusieurs acteurs, les acteurs pouvant &amp;#xEA;tre des personnes ou d&amp;#x2019;autres syst&amp;#xE8;mes. &amp;#xBB;&amp;#xBB;(Traduction par mes soins, donc soyez indulgents et surtout vigilants.)Bon, avec tout &amp;#xE7;a, on est bien avanc&amp;#xE9; !\nUse case, forte connotation proc&amp;#xE9;durale, merci UML\nUser story, pas assez formel, mais bien test&amp;#xE9;.\n\n\n\nDans son livre d&amp;#xE9;di&amp;#xE9; &amp;#xE0; Scrum[1], Claude Aubry propose (en &amp;#xA7;13.5.5) une facette int&amp;#xE9;ressante sur ce d&amp;#xE9;bat :\n&amp;#xAB; La technique des user stories n&amp;#x2019;est pas une technique de sp&amp;#xE9;cification &amp;#xBB;, ce en quoi il a tout &amp;#xE0; fait raison, puisque les exigences dans scrum sont d&amp;#xE9;finies et d&amp;#xE9;taill&amp;#xE9;es lors de la r&amp;#xE9;union de planification du sprint et non pas avant: cqfd.\nEt &amp;#xAB; il est pr&amp;#xE9;f&amp;#xE9;rable de dialoguer&amp;#x2026; &amp;#xBB; combin&amp;#xE9; avec &amp;#xAB; r&amp;#xE9;diger des tests fonctionnels et les passer&amp;#x2026; &amp;#xBB;\nOn voit l&amp;#xE0; bien l&amp;#x2019;approche radicalement diff&amp;#xE9;rente, qui est plus dans le processus global de construction du projet que dans l&amp;#x2019;&amp;#xE9;l&amp;#xE9;ment m&amp;#xEA;me du use case ou de la user story.\n\nUn autre point indiqu&amp;#xE9; par Claude est le fait que par d&amp;#xE9;finition un use case ne peut &amp;#xEA;tre utilis&amp;#xE9; dans un backlog, puisqu&amp;#x2019;il ne rempli pas les conditions d&amp;#x2019;entr&amp;#xE9;e dans un sprint. Encore une fois, je suis enti&amp;#xE8;rement d&amp;#x2019;accord, mais c&amp;#x2019;est plus discutable, en tout cas, il faut un peu plus d&amp;#x2019;exp&amp;#xE9;rience &amp;#xAB; agile &amp;#xBB; pour comprendre ce point. Je vais essayer d&amp;#x2019;expliquer plus clairement ce point l&amp;#xE0; : Ne peuvent entrer dans un sprint que des &amp;#xE9;l&amp;#xE9;ments suffisamment fins au regard de la v&amp;#xE9;locit&amp;#xE9; de l&amp;#x2019;&amp;#xE9;quipe (A&amp;#xEF;, a&amp;#xEF;, j&amp;#x2019;en ai perdu en route). Comme nous l&amp;#x2019;avons vu pr&amp;#xE9;c&amp;#xE9;demment, une user story est par d&amp;#xE9;finition succincte et utilise un format l&amp;#xE9;ger, cela entraine une granularit&amp;#xE9; assez fine et donc une complexit&amp;#xE9;/charge relativement petite la plus part du temps. Dans le cas o&amp;#xF9; une user story ne serait pas assez &amp;#xAB; fine &amp;#xBB;, alors elle ne pourrait &amp;#xEA;tre &amp;#xE0; consid&amp;#xE9;rer dans le prochain sprint.\nPour les use cases, la notion de complexit&amp;#xE9;/charge n&amp;#x2019;intervient jamais dans leur cr&amp;#xE9;ation. En cons&amp;#xE9;quence leur niveau de granularit&amp;#xE9; n&amp;#x2019;est pas adapt&amp;#xE9; aux sprints. Bien sur, il est possible de d&amp;#xE9;couper les use cases en scenarios, puis en diagrammes d&amp;#x2019;&amp;#xE9;tats et ainsi avoir une granularit&amp;#xE9; suffisante pour &amp;#xEA;tre utilis&amp;#xE9; dans un backlog. Mais on perd la vision utilisateur dans ce cas.\n\n\n\nJe rajouterai pour ma part et pour vous aidez &amp;#xE0; faire le choix, les quelques id&amp;#xE9;es et conseils suivants :\n\nPour moi, la vraie diff&amp;#xE9;rence est dans la construction du logiciel lui-m&amp;#xEA;me.\nLes use cases d&amp;#xE9;crivent un syst&amp;#xE8;me entier et d&amp;#xE9;j&amp;#xE0; pre-pens&amp;#xE9; (cahier des charges, appel d&amp;#x2019;offres,&amp;#x2026;).\n\nLes use cases ne supportent pas tr&amp;#xE8;s bien le mode it&amp;#xE9;ratif, ou alors comme l&amp;#x2019;avait &amp;#xE9;voqu&amp;#xE9; Pascal Roques lors de sa pr&amp;#xE9;sentation sur la mod&amp;#xE9;lisation Agile (SigmaT 8), il ne faut pas avoir peur de jeter son mod&amp;#xE8;le &amp;#xE0; la poubelle et ne pas chercher d&amp;#xE9;sesp&amp;#xE9;r&amp;#xE9;ment &amp;#xE0; le maintenir.\nLes use cases &amp;#xE0; eux seuls ne servent &amp;#xE0; rien, il faut toute la suite des 13 sch&amp;#xE9;mas UML et outils associ&amp;#xE9;s.\nC&amp;#x2019;est trop orient&amp;#xE9; architecture, et moi je m&amp;#x2019;en fiche de savoir si mon logiciel est en java ou en C# avec un poisson givr&amp;#xE9;, un patron-java ou un flexible dans&amp;#x2026;, Je veux qu&amp;#x2019;il marche !\n\nLes user stories sont faites pour d&amp;#xE9;crire simplement la mani&amp;#xE8;re dont l&amp;#x2019;utilisateur pourra utiliser son logiciel. On pourra lui ajouter pleins de nouvelles fonctions super utiles, les user stories se compl&amp;#xE8;tent les unes aux autres, pas besoin d&amp;#x2019;un processus lourd, d&amp;#x2019;un outil de mod&amp;#xE9;lisation, le backlog est l&amp;#xE0; (je parle de post-it, au mieux un fichier, pas d&amp;#x2019;outils de gestion de projet). Les user stories ont par d&amp;#xE9;finition aussi cette notion d&amp;#x2019;utilit&amp;#xE9; et/ou de priorit&amp;#xE9; que n&amp;#x2019;ont pas les use cases.\n\nJe pr&amp;#xE9;f&amp;#xE8;re l&amp;#x2019;utilisation des user stories dans le contexte de d&amp;#xE9;marrage de nouveaux projets. L&amp;#x2019;aspect &amp;#xAB; quelle solution me propose mon logiciel pour faire &amp;#xE7;a &amp;#xBB; me plait pas mal, le logiciel orient&amp;#xE9; service &amp;#xE0; son utilisateur ! Plus facile pour discuter avec le client du client (SSII et sous traitance obligent) lors d&amp;#x2019;un atelier sans qu&amp;#x2019;il ait eu besoin d&amp;#x2019;apprendre UML.\n\nEncore un point, on ne peut pas tous d&amp;#xE9;finir en use case :\n&amp;#xAB; En tant qu&amp;#x2019;utilisateur, je veux que l&amp;#x2019;icone clignote quand je re&amp;#xE7;ois un mail &amp;#xBB;, vous traduisez &amp;#xE7;a comment en use case ? C&amp;#x2019;est, &amp;#xE0; la limite, une des 2000 exigences du use case &amp;#xAB; Recevoir un message &amp;#xBB;\n\nEt puis si vous ne savez toujours pas quoi prendre, reste la solutio Mac ou Windows ?\no &amp;#xAB; Je veux acheter un nouvel ordinateur, c&amp;#x2019;est bien Max ? &amp;#xBB;\no &amp;#xAB; bein, t&amp;#x2019;as quoi pour l&amp;#x2019;instant ?\no &amp;#xAB; un pc ! &amp;#xBB;\no &amp;#xAB; Ah, et t&amp;#x2019;as du temps &amp;#xE0; perdre &amp;#xBB;\no &amp;#xAB; non ! &amp;#xBB;\no &amp;#xAB; alors reste sur pc &amp;#xBB;\nSi vous avez l&amp;#x2019;habitude des use cases, gardez les, sinon \nOsez le changement.\n\n
  160. Review the example on the slide:\nWhat is good about the way the use case is written?\nWhat is not good about the way the use case is written?\nIs this the right level of detail? \nHow would you write it differently?\n
  161. Review the example on the slide:\nWhat is good about the way the use case is written?\nWhat is not good about the way the use case is written?\nIs this the right level of detail? \nHow would you write it differently?\n
  162. Review the example on the slide:\nWhat is good about the way the use case is written?\nWhat is not good about the way the use case is written?\nIs this the right level of detail? \nHow would you write it differently?\n
  163. Review the example on the slide:\nWhat is good about the way the use case is written?\nWhat is not good about the way the use case is written?\nIs this the right level of detail? \nHow would you write it differently?\n
  164. Review the example on the slide:\nWhat is good about the way the use case is written?\nWhat is not good about the way the use case is written?\nIs this the right level of detail? \nHow would you write it differently?\n
  165. Au d&amp;#xE9;but d&amp;#x2019;un semestre les &amp;#xE9;tudiants consultent un catalogue des cours propos&amp;#xE9;s. Le catalogue contient des informations sur le cours tels que le professeur responsable, les intervenants ainsi que les pr&amp;#xE9;-requis pour aider les &amp;#xE9;tudiants dans leur choix.\n\nLe syst&amp;#xE8;me doit permettre aux &amp;#xE9;tudiants de choisir quatre cours. De plus, les &amp;#xE9;tudiants doivent donner deux autres choix au cas o&amp;#xF9; un cours est complet ou est supprim&amp;#xE9;. Il ne peut y avoir plus de 15 &amp;#xE9;l&amp;#xE8;ves inscrits dans chaque cours mais un cours ne peut ouvrir s&amp;#x2019;il n&amp;#x2019;a pas au moins 6 inscrits.\n\nQuand l&amp;#x2019;inscription d&amp;#x2019;un &amp;#xE9;tudiant est termin&amp;#xE9;e, le syst&amp;#xE8;me des inscriptions envoie des informations au service comptable pour &amp;#xE9;mettre une facture.\n\nLes professeurs doivent pouvoir acc&amp;#xE9;der au syst&amp;#xE8;me pour indiquer les cours qu&amp;#x2019;ils sont en mesure d&amp;#x2019;assurer et pour conna&amp;#xEE;tre les &amp;#xE9;tudiants qui se sont inscrits &amp;#xE0; leur cours.\n\nLes &amp;#xE9;tudiants disposent d&amp;#x2019;une p&amp;#xE9;riode pendant laquelle ils peuvent changer leur choix, ils peuvent en outre ajouter ou abandonner certains cours.\n
  166. Start identifying the common vocabulary at the beginning of a project. \nThere should be one glossary for a system. This document is important to all stakeholders, especially when they need to understand and use terms that are specific to the project. \nAll text descriptions of the system, especially Use-Case Specifications, should use and refer to the terms defined in the glossary. \nIn some cases, you may build a domain model to further visualize the terms in the glossary.\n\n=======\nDescribing how actors interact with forms is common in use cases. There are many techniques that writers use, such as placing them in the flow or in the Special Requirements.\nFor example \n5. Enter Customer Information\nThe system prompts the Customer to enter name, address (two lines), city, state, zip code, and phone number.\nThe Customer enters the information.\nThe Customer creates the account.\nThis style has a tendency to distract the reader from the flows of events and is harder to maintain. \nThe safest method is to use the glossary. This ensures that there is only a single place to maintain the information. It ensures consistency if the same data is used in multiple use cases. It also makes the use-case description cleaner and easier to read. The glossary can be used by your database and user interface designers more effectively.\nWhile you should always strive to use the glossary, an alternative approach is to specify the detailed data requirements in the Special Requirements section of a Use-Case Specification or place them in the Supplementary Specification. \n
  167. A domain model provides a visual model of key business objects that are captured in the glossary. The benefit of a domain model is that the relationships between the glossary terms can be represented visually, thereby improving the stakeholders&amp;#x2019; understanding of the domain .\nThis is an example of part of a domain model for a course registration system. It shows that there are student, schedule, course offering, course, and professor. There are two types of students: full-time students and part-time students.\nThe numbers on associations between objects indicate how many objects that a particular object can be related to. This diagram shows\nA student can have zero-to-many schedules. A schedule must be associated with a student. \nA schedule is associated with zero-to-four course offerings. A course offering can exist in zero-to-many schedules.\nA course offering is associated with zero-to-one professor. A professor can teach zero-to-many course offerings. \nA course offering is associated with a course. A course can have zero-to-many course offerings. \n
  168. \n
  169. \n
  170. \n
  171. \n
  172. \n
  173. \n
  174. \n
  175. \n
  176. \n
  177. \n
  178. \n
  179. \n
  180. \n
  181. \n
  182. \n
  183. \n
  184. \n
  185. On peut regrouper sur les acteurs, par domaine, ...\n\nScanner p 43 et 44 de UML par la pratique\n\nOn peut alors, si n&amp;#xE9;cessaire, d&amp;#xE9;tailler certains de cas d&amp;#x2019;utilisation.\n
  186. On peut regrouper sur les acteurs, par domaine, ...\n
  187. \n
  188. \n
  189. \n
  190. \n
  191. \n
  192. \n
  193. \n
  194. \n
  195. \n
  196. \n
  197. \n
  198. \n
  199. \n
  200. Use cases were never intended to describe a user interface. Describing a visual thing with words is always open to interpretation and very hard to review. For example, picture a bucket. You may imagine that it is a plastic container with an open top and a handle. But someone else may imagine it as being made of metal, with a handle, painted red, and with the word &amp;#x201C;Fire&amp;#x201D; written on it. Everyone interprets descriptions differently. For the same reason, user interfaces are best described visually.\nAnother reason to keep a user interface out of a Use-Case Specification is that the requirements of the system may be the same regardless of the technology used.\nConsider the Use-Case Specification for a mobile phone. One of the use cases may be Receive Call. In this use case, the system needs to notify the user that there is an incoming call. Typically, use-case authors would write &amp;#x201C;The system rings the phone.&amp;#x201D; But with modern phones, the ring tone could be turned off. In fact, the phone could ring, vibrate, display a message on the screen, or any combination of the three, depending on which features have been enabled. In this case, the use-case description should be &amp;#x201C;The system notifies the user of an incoming call. Refer to the special requirements for a description of how the system can notify the user.&amp;#x201D; In the Special Requirements, there would be a matrix of how the system can notify the user, depending on the features that have been enabled in the system. This tells the implementer and tester that this is configurable and that the notification method is based on the system&amp;#x2019;s configuration.\nEven if you know what your system&amp;#x2019;s interface is going to be, your use cases should still be as interface-independent as possible. Put interface specific information in the user-interface specifications or user experience models. \n
  201. Use cases were never intended to describe a user interface. Describing a visual thing with words is always open to interpretation and very hard to review. For example, picture a bucket. You may imagine that it is a plastic container with an open top and a handle. But someone else may imagine it as being made of metal, with a handle, painted red, and with the word &amp;#x201C;Fire&amp;#x201D; written on it. Everyone interprets descriptions differently. For the same reason, user interfaces are best described visually.\nAnother reason to keep a user interface out of a Use-Case Specification is that the requirements of the system may be the same regardless of the technology used.\nConsider the Use-Case Specification for a mobile phone. One of the use cases may be Receive Call. In this use case, the system needs to notify the user that there is an incoming call. Typically, use-case authors would write &amp;#x201C;The system rings the phone.&amp;#x201D; But with modern phones, the ring tone could be turned off. In fact, the phone could ring, vibrate, display a message on the screen, or any combination of the three, depending on which features have been enabled. In this case, the use-case description should be &amp;#x201C;The system notifies the user of an incoming call. Refer to the special requirements for a description of how the system can notify the user.&amp;#x201D; In the Special Requirements, there would be a matrix of how the system can notify the user, depending on the features that have been enabled in the system. This tells the implementer and tester that this is configurable and that the notification method is based on the system&amp;#x2019;s configuration.\nEven if you know what your system&amp;#x2019;s interface is going to be, your use cases should still be as interface-independent as possible. Put interface specific information in the user-interface specifications or user experience models. \n
  202. Use cases were never intended to describe a user interface. Describing a visual thing with words is always open to interpretation and very hard to review. For example, picture a bucket. You may imagine that it is a plastic container with an open top and a handle. But someone else may imagine it as being made of metal, with a handle, painted red, and with the word &amp;#x201C;Fire&amp;#x201D; written on it. Everyone interprets descriptions differently. For the same reason, user interfaces are best described visually.\nAnother reason to keep a user interface out of a Use-Case Specification is that the requirements of the system may be the same regardless of the technology used.\nConsider the Use-Case Specification for a mobile phone. One of the use cases may be Receive Call. In this use case, the system needs to notify the user that there is an incoming call. Typically, use-case authors would write &amp;#x201C;The system rings the phone.&amp;#x201D; But with modern phones, the ring tone could be turned off. In fact, the phone could ring, vibrate, display a message on the screen, or any combination of the three, depending on which features have been enabled. In this case, the use-case description should be &amp;#x201C;The system notifies the user of an incoming call. Refer to the special requirements for a description of how the system can notify the user.&amp;#x201D; In the Special Requirements, there would be a matrix of how the system can notify the user, depending on the features that have been enabled in the system. This tells the implementer and tester that this is configurable and that the notification method is based on the system&amp;#x2019;s configuration.\nEven if you know what your system&amp;#x2019;s interface is going to be, your use cases should still be as interface-independent as possible. Put interface specific information in the user-interface specifications or user experience models. \n
  203. \n
  204. \n
  205. \n
  206. \n
  207. People differ on how to deal with choices in use cases alternative flows or separate use cases?\nIf the choices are reasonably simple, keep them in the same use case. Include one choice in the basic flow, and put other choices in the alternative flows. If they have their own very different flows, you may want to consider putting them in separate use cases. However, avoid having too many fragmented use cases, because this makes it very difficult to understand the key functionality of the system. Also, avoid creating CRUD use cases. \n
  208. \n
  209. \n
  210. If steps can occur in parallel, state this in the use case. Avoid inadvertently placing additional constraints on the design by ignoring optional ordering of steps. \n
  211. It is common to see conditional statements such as IF-THEN-ELSE-ENDIF in Use-Case Specifications. The primary reason for including conditional statements in a use case flow is that they are very natural and convenient to write. However, every time you include a conditional statement, you add a level of complexity to the use case. The readers need to keep in mind the condition that got them to the subflow. With one level of condition, this is easy. But as you add more conditions, the level of complexity goes up an order of magnitude.\nFor example\nIF a THEN\n do something\n IF b THEN\n do something else\n When ELSE\n do something else again\n ENDIF\nENDIF\nImplementing and writing test scripts for use cases that make excessive use of conditional statements is difficult and prone to error. A far better approach is to use alternative flows.\nThere are tradeoffs. A use case with many alternative flows becomes difficult to read because the flows are fragmented throughout the document. The side effects of overuse of conditional statements far outweigh this problem.\n
  212. It is common to see conditional statements such as IF-THEN-ELSE-ENDIF in Use-Case Specifications. The primary reason for including conditional statements in a use case flow is that they are very natural and convenient to write. However, every time you include a conditional statement, you add a level of complexity to the use case. The readers need to keep in mind the condition that got them to the subflow. With one level of condition, this is easy. But as you add more conditions, the level of complexity goes up an order of magnitude.\nFor example\nIF a THEN\n do something\n IF b THEN\n do something else\n When ELSE\n do something else again\n ENDIF\nENDIF\nImplementing and writing test scripts for use cases that make excessive use of conditional statements is difficult and prone to error. A far better approach is to use alternative flows.\nThere are tradeoffs. A use case with many alternative flows becomes difficult to read because the flows are fragmented throughout the document. The side effects of overuse of conditional statements far outweigh this problem.\n
  213. \n
  214. Functional decomposition is breaking down a problem into small, isolated parts. The parts work together to provide the functionality of the system. Often, the parts do not make sense in isolation because they lose their context.\nUse cases allow you to capture requirements at the same level of detail as functional decomposition, but the requirements are put into context with one another. Use cases enable you to develop requirements that are more likely to be understood by your stakeholders, and that deliver end-to-end functionality of the system.\n
  215. \n
  216. \n
  217. \n
  218. \n
  219. \n
  220. \n
  221. \n
  222. \n
  223. \n
  224. \n
  225. \n
  226. \n
  227. \n
  228. \n
  229. \n
  230. \n
  231. \n
  232. Au d&amp;#xE9;but d&amp;#x2019;un semestre les &amp;#xE9;tudiants consultent un catalogue des cours propos&amp;#xE9;s. Le catalogue contient des informations sur le cours tels que le professeur responsable, les intervenants ainsi que les pr&amp;#xE9;-requis pour aider les &amp;#xE9;tudiants dans leur choix.\n\nLe syst&amp;#xE8;me doit permettre aux &amp;#xE9;tudiants de choisir quatre cours. De plus, les &amp;#xE9;tudiants doivent donner deux autres choix au cas o&amp;#xF9; un cours est complet ou est supprim&amp;#xE9;. Il ne peut y avoir plus de 15 &amp;#xE9;l&amp;#xE8;ves inscrits dans chaque cours mais un cours ne peut ouvrir s&amp;#x2019;il n&amp;#x2019;a pas au moins 6 inscrits.\n\nQuand l&amp;#x2019;inscription d&amp;#x2019;un &amp;#xE9;tudiant est termin&amp;#xE9;e, le syst&amp;#xE8;me des inscriptions envoie des informations au service comptable pour &amp;#xE9;mettre une facture.\n\nLes professeurs doivent pouvoir acc&amp;#xE9;der au syst&amp;#xE8;me pour indiquer les cours qu&amp;#x2019;ils sont en mesure d&amp;#x2019;assurer et pour conna&amp;#xEE;tre les &amp;#xE9;tudiants qui se sont inscrits &amp;#xE0; leur cours.\n\nLes &amp;#xE9;tudiants disposent d&amp;#x2019;une p&amp;#xE9;riode pendant laquelle ils peuvent changer leur choix, ils peuvent en outre ajouter ou abandonner certains cours.\n
  233. This definition of a use case comes from the Object Management Group (OMG), which is a non-profit computer industry specifications consortium.\nThe Unified Modeling Language is a standard visual modeling language managed and maintained by members of the OMG.\nTo learn more about UML and to access UML resources, go to www.ulm.org or to the IBM Rational software UML Resource Center www.ibm.com/sofware/rational/uml/.\nFor example, in a university-based course registration system, use cases might include: Register for Courses, Request Course Catalog, and Get Class List for a Course.\n\nA use-case model describes a system&apos;s functional requirements in terms of use cases. \nIt is a model of the system&apos;s intended functionality (use cases) and its environment (actors). \nThink of a use-case model as a menu, much like the menu you would find in a restaurant. By looking at the menu, you know what is available to you, the individual dishes as well as their prices. You also know what kind of cuisine the restaurant serves: Italian, Mexican, Chinese, and so on. By looking at the menu, you get an overall impression of the dining experience that awaits you in that restaurant. The menu, in effect, &quot;models&quot; the restaurant&apos;s behavior. \nBecause it is a very powerful planning instrument, the use-case model is generally used in all phases of the development lifecycle by all team members.\n
  234. This definition of a use case comes from the Object Management Group (OMG), which is a non-profit computer industry specifications consortium.\nThe Unified Modeling Language is a standard visual modeling language managed and maintained by members of the OMG.\nTo learn more about UML and to access UML resources, go to www.ulm.org or to the IBM Rational software UML Resource Center www.ibm.com/sofware/rational/uml/.\nFor example, in a university-based course registration system, use cases might include: Register for Courses, Request Course Catalog, and Get Class List for a Course.\n\nA use-case model describes a system&apos;s functional requirements in terms of use cases. \nIt is a model of the system&apos;s intended functionality (use cases) and its environment (actors). \nThink of a use-case model as a menu, much like the menu you would find in a restaurant. By looking at the menu, you know what is available to you, the individual dishes as well as their prices. You also know what kind of cuisine the restaurant serves: Italian, Mexican, Chinese, and so on. By looking at the menu, you get an overall impression of the dining experience that awaits you in that restaurant. The menu, in effect, &quot;models&quot; the restaurant&apos;s behavior. \nBecause it is a very powerful planning instrument, the use-case model is generally used in all phases of the development lifecycle by all team members.\n
  235. Use cases are a way to organize requirements from a user perspective. All the requirements for a user to accomplish a particular task are gathered together in a single use case. The benefits of use cases include:\nUse cases show why the system is needed. Use cases show what goals the users can accomplish by using the system.\nSystem requirements are placed in context. Each requirement is part of a logical sequence of actions to accomplish a goal of a user. \nUse cases are easy to understand. They express requirements from a user perspective and in the user&amp;#x2019;s own vocabulary. Traditional forms of requirements capture need some translation to make them accessibly by different stakeholders. When you translate something, information is often lost or misinterpreted. Use cases require no such translation. Therefore, they provide a more consistent and reliable form of requirement capture. \nUse cases are a means to communicate requirements between customers and developers to ensure that the system that is built is what the customer wants.\n
  236. Relationships between actors and use cases are called communicates-associations. A communicates-association between an actor and a use case indicates that they interact: The actor participates in and communicates with the system containing the use case. A communicates-association is represented on UML diagrams as a solid line.\n
  237. \n
  238. The use-case model consists of both diagrams and text. The diagrams give a visual overview of the system. The text gives descriptions of the actors and the use cases.\nThe majority of the work in writing use cases is spent writing the textual portion of the use case. \nUse cases involve writing text. Drawing the pictures is only a small part of the effort. Typically, more than 80 percent of all effort during requirements capture is writing the textual description of what happens in each use case, the non-functional requirements, and rules. \nUML does NOT specify how the text of a use case should be structured, organized, or written.\nHow you write use cases will have a large impact on how easy they are to read, use, and test.\n
  239. The use-case model consists of both diagrams and text. The diagrams give a visual overview of the system. The text gives descriptions of the actors and the use cases.\nThe majority of the work in writing use cases is spent writing the textual portion of the use case. \nUse cases involve writing text. Drawing the pictures is only a small part of the effort. Typically, more than 80 percent of all effort during requirements capture is writing the textual description of what happens in each use case, the non-functional requirements, and rules. \nUML does NOT specify how the text of a use case should be structured, organized, or written.\nHow you write use cases will have a large impact on how easy they are to read, use, and test.\n
  240. The use-case model consists of both diagrams and text. The diagrams give a visual overview of the system. The text gives descriptions of the actors and the use cases.\nThe majority of the work in writing use cases is spent writing the textual portion of the use case. \nUse cases involve writing text. Drawing the pictures is only a small part of the effort. Typically, more than 80 percent of all effort during requirements capture is writing the textual description of what happens in each use case, the non-functional requirements, and rules. \nUML does NOT specify how the text of a use case should be structured, organized, or written.\nHow you write use cases will have a large impact on how easy they are to read, use, and test.\n
  241. The use-case model consists of both diagrams and text. The diagrams give a visual overview of the system. The text gives descriptions of the actors and the use cases.\nThe majority of the work in writing use cases is spent writing the textual portion of the use case. \nUse cases involve writing text. Drawing the pictures is only a small part of the effort. Typically, more than 80 percent of all effort during requirements capture is writing the textual description of what happens in each use case, the non-functional requirements, and rules. \nUML does NOT specify how the text of a use case should be structured, organized, or written.\nHow you write use cases will have a large impact on how easy they are to read, use, and test.\n
  242. The use-case model consists of both diagrams and text. The diagrams give a visual overview of the system. The text gives descriptions of the actors and the use cases.\nThe majority of the work in writing use cases is spent writing the textual portion of the use case. \nUse cases involve writing text. Drawing the pictures is only a small part of the effort. Typically, more than 80 percent of all effort during requirements capture is writing the textual description of what happens in each use case, the non-functional requirements, and rules. \nUML does NOT specify how the text of a use case should be structured, organized, or written.\nHow you write use cases will have a large impact on how easy they are to read, use, and test.\n
  243. The use-case model consists of both diagrams and text. The diagrams give a visual overview of the system. The text gives descriptions of the actors and the use cases.\nThe majority of the work in writing use cases is spent writing the textual portion of the use case. \nUse cases involve writing text. Drawing the pictures is only a small part of the effort. Typically, more than 80 percent of all effort during requirements capture is writing the textual description of what happens in each use case, the non-functional requirements, and rules. \nUML does NOT specify how the text of a use case should be structured, organized, or written.\nHow you write use cases will have a large impact on how easy they are to read, use, and test.\n
  244. \n
  245. \n
  246. Use cases are a way to organize requirements from a user perspective. All the requirements for a user to accomplish a particular task are gathered together in a single use case. The benefits of use cases include:\nUse cases show why the system is needed. Use cases show what goals the users can accomplish by using the system.\nSystem requirements are placed in context. Each requirement is part of a logical sequence of actions to accomplish a goal of a user. \nUse cases are easy to understand. They express requirements from a user perspective and in the user&amp;#x2019;s own vocabulary. Traditional forms of requirements capture need some translation to make them accessibly by different stakeholders. When you translate something, information is often lost or misinterpreted. Use cases require no such translation. Therefore, they provide a more consistent and reliable form of requirement capture. \nUse cases are a means to communicate requirements between customers and developers to ensure that the system that is built is what the customer wants.\n
  247. Use cases are a way to organize requirements from a user perspective. All the requirements for a user to accomplish a particular task are gathered together in a single use case. The benefits of use cases include:\nUse cases show why the system is needed. Use cases show what goals the users can accomplish by using the system.\nSystem requirements are placed in context. Each requirement is part of a logical sequence of actions to accomplish a goal of a user. \nUse cases are easy to understand. They express requirements from a user perspective and in the user&amp;#x2019;s own vocabulary. Traditional forms of requirements capture need some translation to make them accessibly by different stakeholders. When you translate something, information is often lost or misinterpreted. Use cases require no such translation. Therefore, they provide a more consistent and reliable form of requirement capture. \nUse cases are a means to communicate requirements between customers and developers to ensure that the system that is built is what the customer wants.\n
  248. Functional requirements describe the behaviors (functions or services) of the system that support user goals, tasks, or activities. Functional requirements may include feature sets, capabilities, and security.\nUsability is the ease with which software can be learned and operated by the intended users. Usability requirements may include such subcategories as human factors, aesthetics, consistency in the user interface, online and context-sensitive help, wizards and agents, user documentation, and training materials.\nReliability is the ability for the software to behave consistently in a user-acceptable manner. Reliability requirements to be considered are frequency and severity of failure, recoverability, predictability, accuracy, and mean time between failure (MTBF). \nPerformance is a measure of speed or efficiency of the running system. It imposes conditions on functional requirements. For example, for a given action, it may specify performance parameters for speed, efficiency, availability, accuracy, throughput, response time, recovery time, and resource usage.\nSupportability is the ability of the software to be easily modified to accommodate enhancements and repairs. Supportability requirements may include testability, extensibility, adaptability, maintainability, compatibility, configurability, serviceability, installability, and localizability (internationalization).\nUse cases mainly capture the functional requirements of the system.\n\nA design requirement, often called a design constraint, specifies or constrains the design of a system. \n\n\n\n\n\n
  249. Use cases defined for a system are the basis for the entire development process. They provide the unifying thread through the system and define the behavior performed by a system. Use cases play a role in each of the core process disciplines:\nThe use-case model is a result of the requirements workflow. It models what the system should do from the user&apos;s perspective. \nIn analysis and design, use cases are realized in a design model. You create use-case realizations, which describe how the use case is performed in terms of interacting objects in the design model. This model describes, in terms of design objects, the different parts of the implemented system and how the parts should interact to perform the use cases. \nDuring implementation, the design model is the implementation specification. Because use cases are the basis for the design model, they are implemented in terms of design classes. \nDuring testing, the use cases constitute a basis for identifying test cases and test procedures. The system is verified by performing each use case.\nUse cases have other roles as well: \nBasis for planning iterative development.\nFoundation for what is described in user manuals.\nDefinition of ordering units. For example, a customer can get a system configured with a particular set of use cases.\n
  250. \n
  251. \n
  252. Un (ou un ensemble) de diagramme de plus haut niveau\n Placement des acteurs\n Pas de raffinements des cas d&apos;utilisation\n G&amp;#xE9;n&amp;#xE9;ralement pas de d&amp;#xE9;pendances entre cas d&apos;utilisation (sauf cas d&apos;utilisation de plus haut niveau)\n\n\n Pour chaque cas d&apos;utilisation du diagramme de plus haut niveau, si n&amp;#xE9;cessaire, d&amp;#xE9;composition dans un diagramme de plus bas niveau\n Inutile de r&amp;#xE9;p&amp;#xE9;ter les acteurs\n R&amp;#xE9;p&amp;#xE9;ter le cas d&apos;utilisation &amp;#xE0; raffiner\n Relations de d&amp;#xE9;pendance entre cas d&apos;utilisation obligatoires\n\n Plusieurs niveaux de diagramme possibles\n\n
  253. \n
  254. Sommaire d&amp;#xA0;&amp;#x2019;identification\nDescription des encha&amp;#xEE;nements\npr&amp;#xE9;conditions\npostconditions\nBesoins d&amp;#xA0;&amp;#x2019;IHM\nContraintes non fonctionnelles\nservira &amp;#xE0; &amp;#xE9;valuer les contraintes techniques\nCompl&amp;#xE9;ter avec des diagrammes dynamiques simples (vus plus loin)\ndiagrammes d&amp;#xA0;&amp;#x2019;activit&amp;#xE9; global et sc&amp;#xE9;narios \n(Comment le cas d&amp;#x2019;utilisation commence et comment il finit) \n
  255. n Actors: traveler, client account db, airline reservation system\nn Preconditions:\n&amp;#x2022; Traveler has logged on to the system and selected &amp;#x2018;change flight itinerary&amp;#x2019; option\nn Basic course\n&amp;#x2022; System retrieves traveler&amp;#x2019;s account and flight itinerary from client account database\n&amp;#x2022; System asks traveler to select itinerary segment she wants to change;traveler selects itinerary segment.\n&amp;#x2022; System asks traveler for new departure and destination information;traveler provides information.\n&amp;#x2022; If flights are available then\n&amp;#x2022; &amp;#x2026;\n&amp;#x2022; System displays transaction summary.\nn Alternative courses\n&amp;#x2022; If no flights are available then &amp;#x2026;\n
  256. \n
  257. An actor represents a role that interacts with the system.\nA use case describes a sequence of interactions between actors and the system that occur when an actor uses the system to achieve a certain business goal.\nA use case describes: \nThe system, its environment, and the relationship between them. \nHow things outside the system interact with the system.\nThe desired behavior for the system.\nUse cases are containers for contextually related requirements of the system under development. They are containers because they group all requirements related to achieving a particular goal into a single story of how that is achieved.\nA use case is shown as an ellipse containing the name of the use case. An optional presentation is to place the use case name under the ellipse.\n
  258. A use case describes a set of possible executions of the system. It describes a complete flow through the system until the resulting value is achieved for some actor. \n&amp;#x201C;Sequence of actions&amp;#x201D;: Atomic activities, decisions, and requests. Each action is performed fully or not at all.\n&amp;#x201C;Performed by a system&amp;#x201D;: The actions performed by the system are the functional requirements.\n&amp;#x201C;Observable result of value&amp;#x201D;: Make sure that the use case results in an observable value. Why would anybody use the system if it does not achieve a result of value? If nobody receives value from the use case, then the use case is probably too small. It needs to be combined with other use cases to provide a complete set of steps for achieving some goal for an actor.\n&amp;#x201C;To an actor&amp;#x201D;: Decide which particular actor receives the value and helps avoid use cases that are too large. If more than one actor receives value from a use case, it might indicate that the use case is too big; it tries to do too much for too many actors. For example, in the Course Registration System, there could be just one use case, called &amp;#x201C;Operate the Registration System.&amp;#x201D; It would achieve a variety of results for a variety of actors. It would be so big that it is hard to understand. It needs to be broken into smaller use cases. Use cases that do not deliver something of value are too small and usually describe individual functions of the system. These use cases do not make sense on their own and must be avoided.\nOften the sequence of interactions in a use case involves several actors. But one actor receives the result of value. The actor receiving the value is sometimes called the primary actor. The actor receiving the value is usually, but not necessarily, the one who initiated the use case. \n
  259. A use case describes a set of possible executions of the system. It describes a complete flow through the system until the resulting value is achieved for some actor. \n&amp;#x201C;Sequence of actions&amp;#x201D;: Atomic activities, decisions, and requests. Each action is performed fully or not at all.\n&amp;#x201C;Performed by a system&amp;#x201D;: The actions performed by the system are the functional requirements.\n&amp;#x201C;Observable result of value&amp;#x201D;: Make sure that the use case results in an observable value. Why would anybody use the system if it does not achieve a result of value? If nobody receives value from the use case, then the use case is probably too small. It needs to be combined with other use cases to provide a complete set of steps for achieving some goal for an actor.\n&amp;#x201C;To an actor&amp;#x201D;: Decide which particular actor receives the value and helps avoid use cases that are too large. If more than one actor receives value from a use case, it might indicate that the use case is too big; it tries to do too much for too many actors. For example, in the Course Registration System, there could be just one use case, called &amp;#x201C;Operate the Registration System.&amp;#x201D; It would achieve a variety of results for a variety of actors. It would be so big that it is hard to understand. It needs to be broken into smaller use cases. Use cases that do not deliver something of value are too small and usually describe individual functions of the system. These use cases do not make sense on their own and must be avoided.\nOften the sequence of interactions in a use case involves several actors. But one actor receives the result of value. The actor receiving the value is sometimes called the primary actor. The actor receiving the value is usually, but not necessarily, the one who initiated the use case. \n
  260. A use case describes a set of possible executions of the system. It describes a complete flow through the system until the resulting value is achieved for some actor. \n&amp;#x201C;Sequence of actions&amp;#x201D;: Atomic activities, decisions, and requests. Each action is performed fully or not at all.\n&amp;#x201C;Performed by a system&amp;#x201D;: The actions performed by the system are the functional requirements.\n&amp;#x201C;Observable result of value&amp;#x201D;: Make sure that the use case results in an observable value. Why would anybody use the system if it does not achieve a result of value? If nobody receives value from the use case, then the use case is probably too small. It needs to be combined with other use cases to provide a complete set of steps for achieving some goal for an actor.\n&amp;#x201C;To an actor&amp;#x201D;: Decide which particular actor receives the value and helps avoid use cases that are too large. If more than one actor receives value from a use case, it might indicate that the use case is too big; it tries to do too much for too many actors. For example, in the Course Registration System, there could be just one use case, called &amp;#x201C;Operate the Registration System.&amp;#x201D; It would achieve a variety of results for a variety of actors. It would be so big that it is hard to understand. It needs to be broken into smaller use cases. Use cases that do not deliver something of value are too small and usually describe individual functions of the system. These use cases do not make sense on their own and must be avoided.\nOften the sequence of interactions in a use case involves several actors. But one actor receives the result of value. The actor receiving the value is sometimes called the primary actor. The actor receiving the value is usually, but not necessarily, the one who initiated the use case. \n
  261. A use case describes a set of possible executions of the system. It describes a complete flow through the system until the resulting value is achieved for some actor. \n&amp;#x201C;Sequence of actions&amp;#x201D;: Atomic activities, decisions, and requests. Each action is performed fully or not at all.\n&amp;#x201C;Performed by a system&amp;#x201D;: The actions performed by the system are the functional requirements.\n&amp;#x201C;Observable result of value&amp;#x201D;: Make sure that the use case results in an observable value. Why would anybody use the system if it does not achieve a result of value? If nobody receives value from the use case, then the use case is probably too small. It needs to be combined with other use cases to provide a complete set of steps for achieving some goal for an actor.\n&amp;#x201C;To an actor&amp;#x201D;: Decide which particular actor receives the value and helps avoid use cases that are too large. If more than one actor receives value from a use case, it might indicate that the use case is too big; it tries to do too much for too many actors. For example, in the Course Registration System, there could be just one use case, called &amp;#x201C;Operate the Registration System.&amp;#x201D; It would achieve a variety of results for a variety of actors. It would be so big that it is hard to understand. It needs to be broken into smaller use cases. Use cases that do not deliver something of value are too small and usually describe individual functions of the system. These use cases do not make sense on their own and must be avoided.\nOften the sequence of interactions in a use case involves several actors. But one actor receives the result of value. The actor receiving the value is sometimes called the primary actor. The actor receiving the value is usually, but not necessarily, the one who initiated the use case. \n
  262. A use case describes a set of possible executions of the system. It describes a complete flow through the system until the resulting value is achieved for some actor. \n&amp;#x201C;Sequence of actions&amp;#x201D;: Atomic activities, decisions, and requests. Each action is performed fully or not at all.\n&amp;#x201C;Performed by a system&amp;#x201D;: The actions performed by the system are the functional requirements.\n&amp;#x201C;Observable result of value&amp;#x201D;: Make sure that the use case results in an observable value. Why would anybody use the system if it does not achieve a result of value? If nobody receives value from the use case, then the use case is probably too small. It needs to be combined with other use cases to provide a complete set of steps for achieving some goal for an actor.\n&amp;#x201C;To an actor&amp;#x201D;: Decide which particular actor receives the value and helps avoid use cases that are too large. If more than one actor receives value from a use case, it might indicate that the use case is too big; it tries to do too much for too many actors. For example, in the Course Registration System, there could be just one use case, called &amp;#x201C;Operate the Registration System.&amp;#x201D; It would achieve a variety of results for a variety of actors. It would be so big that it is hard to understand. It needs to be broken into smaller use cases. Use cases that do not deliver something of value are too small and usually describe individual functions of the system. These use cases do not make sense on their own and must be avoided.\nOften the sequence of interactions in a use case involves several actors. But one actor receives the result of value. The actor receiving the value is sometimes called the primary actor. The actor receiving the value is usually, but not necessarily, the one who initiated the use case. \n
  263. A use case describes a set of possible executions of the system. It describes a complete flow through the system until the resulting value is achieved for some actor. \n&amp;#x201C;Sequence of actions&amp;#x201D;: Atomic activities, decisions, and requests. Each action is performed fully or not at all.\n&amp;#x201C;Performed by a system&amp;#x201D;: The actions performed by the system are the functional requirements.\n&amp;#x201C;Observable result of value&amp;#x201D;: Make sure that the use case results in an observable value. Why would anybody use the system if it does not achieve a result of value? If nobody receives value from the use case, then the use case is probably too small. It needs to be combined with other use cases to provide a complete set of steps for achieving some goal for an actor.\n&amp;#x201C;To an actor&amp;#x201D;: Decide which particular actor receives the value and helps avoid use cases that are too large. If more than one actor receives value from a use case, it might indicate that the use case is too big; it tries to do too much for too many actors. For example, in the Course Registration System, there could be just one use case, called &amp;#x201C;Operate the Registration System.&amp;#x201D; It would achieve a variety of results for a variety of actors. It would be so big that it is hard to understand. It needs to be broken into smaller use cases. Use cases that do not deliver something of value are too small and usually describe individual functions of the system. These use cases do not make sense on their own and must be avoided.\nOften the sequence of interactions in a use case involves several actors. But one actor receives the result of value. The actor receiving the value is sometimes called the primary actor. The actor receiving the value is usually, but not necessarily, the one who initiated the use case. \n
  264. Use cases contain the detailed functional software requirements. Every time a use case says, &amp;#x201C;The system &amp;#x2026;,&amp;#x201D; is a detailed requirement of what the system must do.\nAlso, remember the definition: &amp;#x201C;A sequence of actions performed by a system that yields a measurable result of value for a particular actor.&amp;#x201D;\n
  265. Do you have any problems in these areas with your current requirement process?\nUse cases are a way to organize requirements from a user perspective. All the requirements for a user to accomplish a particular task are gathered together in a single use case. The use-case model is the collection of all the individual use cases.\nAdvantages of use-case modeling include:\nUse cases show why the system is needed. Use cases show what goals the users can accomplish by using the system.\nSystem requirements are placed in context. Each requirement is part of a logical sequence of actions to accomplish a goal of a user. \nUse cases are easy to understand. The model expresses requirements from a user perspective and in the user&amp;#x2019;s own vocabulary. The model shows how users think of the system and what the system should do. Traditional forms of requirements capture need some translation to make them useable to different stakeholder types. When you translate something, information is often lost or misinterpreted. Use cases require no such translation and therefore provide a more consistent and reliable form of requirement capture. \nThe model is a means to communicate requirements between customers and developers to make sure that the system we build is what the customer wants.\nUse-case modeling is the best tool (so far) to capture requirements and put them in context. \n
  266. In all but the most trivial of systems, use cases are not written in one sitting. As with any iterative process, a use case evolves from the spark of an idea to a fully described description of how your system behaves.\nInitially you &amp;#x201C;discover&amp;#x201D; a use case. This is done when you identify and name the goal that the actor is trying to achieve. A use case is discovered once you have named it.\nImmediately after discovering a use case (usually while you are discussing the name), you create a brief description of the use case. A brief description describes the goal in two or three sentences. For example, the Close Registration Use Case&amp;#x2019;s brief description is: This use case allows a Registrar to close the registration process. Course offerings that do not have enough students are cancelled. The Billing System is notified for each student in each course offering that is not cancelled, so the student can be billed for the course offering.\nThe next stage of evolution is to outline the use case. This can be a bulleted list of just the basic flow. You may also choose to identify identify (not outline) possible alternate flows. This enables you to identify scenarios and also gain an understanding of the possible size and complexity of the use case.\nFinally, you fully describe the use case. This is done iteratively. You identify particular flows for development in an iteration and then fully describe and implement just those flows. You then identify flows for subsequent iterations and fully describe and implement those during that iteration. At the end of the project, you have all of your use cases fully described.\nPrioritization of flows is done during the Manage the Scope of the System workflow detail.\n
  267. The difference between an actor and an individual system user is that an actor represents a particular class of user rather than an actual user. Several users can play the same role, meaning they can be the same actor. In that case, each user constitutes an instance of the actor. \nHowever, in some situations, only one person plays the role modeled by an actor. For example, there may be only one individual playing the role of system administrator for a rather small system.\n
  268. A use-case model shows what the system is supposed to do (use cases), the system&apos;s surroundings (actors), and the relationship between actors and use cases.\nThe use-case diagram is a graphical description of the use-case model. Can you tell at a glance what users can do with an ATM? \nWhat do you think the priorities for the use cases above would be? The diagram already helps to determine these priorities; without the first one we do not have an ATM, so we better get it right, (e.g. during elaboration); other use cases like deposit funds are nice to have, but would also have quite an architectural impact.\nIt is also useful to distinguish between primary use case and secondary use cases: Primary use cases support the customers/actors and business. Secondary use cases we get, because we decided on a particular technical solution and thus have to specify &quot;extra&quot; functionality to run this technical solution; thus, Maintain ATM, Print logs, Start, Stop, Backup the System, etc are required. These could be also be organized in a separate diagram.\n
  269. The use-case diagram shown here is a graphic description of the use-case model for an online Course Registration System. It shows two of the actors (Student and Course Catalog System) and one use case (Register for Courses) that they participate in. \nThe diagram is incomplete. You use the online course registration system as a case study in this module. You develop the use-case model for this example as we go through the module. \nTake some time to look at the use-case model for an online Course Registration System in the Student Workbook. This example gives you an idea of what a use-case model looks like before you begin to develop one.\nThe use-case model for an online Course Registration System in the Student Workbook is incomplete. It contains only enough artifacts for the purpose of this module: Introduction to Use-Case Modeling. A larger, much more fully developed case study is presented later in the course.\n
  270. Creating a use-case model involves putting the pieces you have learned together. First, the actors and the use cases are found by using the requirements of customers and potential users as vital information. As they are discovered, the use cases and the actors are identified and illustrated in a use-case diagram. Next, the steps in a use case are outlined to get a sketch of the flow. \nThe actor&apos;s name must clearly denote the actor&apos;s role. Make sure there is little risk at a future stage of confusing one actor&apos;s name with another.\nDefine each actor by writing a brief description that includes the actor&apos;s area of responsibility and what the actor needs the system for. Because actors represent things outside the system, you need not describe them in detail. \nEach use case should have a name that indicates what is achieved by its interactions with the actor(s). The name may have to be several words to be understood. No two use cases can have the same name. \nDefine each use case by writing a brief description of it. As you write the description, refer to the glossary and, if you need to, define new terms. \nWhen the actors and use cases have been found, each use case is described in detail. These descriptions show how the system interacts with the actors and what the system does in each individual case. In an iterative development environment, you select a set of use case flows to be detailed in each iteration. These are prioritized in such a way that technical risk is mitigated early and the customer gets important functionality before less important functionality.\n
  271. Your use cases will go through brief iterations during development. At this point in development, you are concerned with identifying and briefly describing your use cases. Later, when you refine the system definition, you will detail and structure the use cases&amp;#x2019; flows of events.\nWhen writing the brief description for a use case you should strive to capture the purpose of the use case and the value it provides to its actors or stakeholders. A brief description should really be no longer than two paragraphs. If it is longer, you may have invested too much time in it.\nFor each brief description, ensure that it captures:\nBusiness justification for its existence &amp;#x2013; the value it provides to the actors and stakeholders.\nAn overview of a couple of the key scenarios.\nAfter reading a brief description a reviewer should be able to describe the business reason for its existence as well as a brief overview of some of the key scenarios.\nAn example for the Register for Courses use case is:\nThis use case enables the Student to register for courses at the beginning of a semester.\nThe system allows students to select from a variety of courses that the student has prerequisites for. During the registration process the student can browse current course listings, and add and remove courses from their enrolment list. Once the student has submitted their selections the student cannot make any more changes.\n
  272. Here is a sample (not necessarily optimal) solution, which brings up a lot of questions that need to be answered by the customer or user:\nAre the use cases too small? For example, should you combine the Manage Portfolio Use Case and Review Account Use Case?\nDoes the diagram cover all activities? For example, in which use case do you think notifying the IRS of sale of stock is done?\nHow do you know what is done in each use case?\n\nNote It is not a complete solution; it covers only the goals mentioned in the initial requests. The complete sample solution can be found in the Student Workbook, RUCS4: Use-Case Model Survey.\n
  273. There are a number of iterations that your use cases go through during development. At this point, you are concerned with outlining the use cases. Later, when you refine the system definition, you detail and structure the use case flows of events.\nA useful first step when outlining use cases is to capture the &amp;#x201C;Essential Use Case&amp;#x201D; as described by Larry Constantine and Lucy A.D. Lockwood 1999. Software for Use. Reading, MA: Addison Wesley Longman.\nThe idea behind the essential use case is to capture the essence of the intention of using the system for the intended purpose. An example for the ubiquitous ATM Withdraw Cash use case would be:\n
  274. Some of the reasons to outline your use cases are:\nIterative development reduces risk. For the same reason we do not implement the whole system in one hit, we do not develop the detailed requirements all at once.\nAvoid getting bogged down in too much detail too early.\nYou do not know everything at once. Outlining helps you discover what you don&amp;#x2019;t know.\nOutlining use cases creates a rough draft for fully specifying your use cases.\nOutlining helps determine whether the use case is too small on its own or too big to be just one use case. It might also help decide whether the use case is actually more than just one use case. \nOnce you write out your steps, you might find that they really belong in another use case. If the outline shows that the use case does not have much to it, it may not be a use case at all. \nOutlining adds value to finding all possible alternate flows.\n
  275. The outline of the flow of events for a use case has two main sections:\nBasic Flow of Events.\nAlternative Flow of Events. \nThe outline is used as a base when you start to write the full use-case specification.\nStructure the flows in such a way that it is easy to follow the different scenarios and to be able to understand what happens when alternatives occur and where they pick up or finish.\nThe basic flow of events should be relatively short and very easy to read, like a single story line. The basic flow should show the steps needed to achieve the main goal of the use case. \nMost of the other details go into alternative flows. You can think of the alternative flows as &amp;#x201C;detours&amp;#x201D; from the basic flow of events, some that return to the basic flow of events and some that end the execution of the use case. In the diagram on the slide, the straight arrow represents the basic flow and the curves represent alternative paths in relation to the basic flow. Examples of different kinds of alternative flows for the Register for Courses use case are:\nRegular variants: Handle freshman enrollments differently.\nOdd cases: Handle registering for over 25 credit-hours differently.\nExceptional (error) flows: Invalid student ID Number.\nYou develop both the basic and alternative flows in the outline you make in the Find Actors and Use Cases activity.\nNote, the diagram above is informational only and is not a valid UML diagram.\n
  276. Here is a list of questions to help you make decisions about the details in the flow of events.\nAlternative flows describe how the system should behave when things go wrong or when unusual things happen. \nWhen working on the alternative flows, questions regarding the behavior of the system are bound to surface. List these questions and have the users answer what the system is supposed to do, and how they expect to interact with the system in each scenario. Understanding the alternatives is an important step in clarifying the requirements. \nAt this point in the process, however, it is enough to identify the alternatives without describing them in detail.\n
  277. This is an example of a step-by-step outline for a use case. It shows a step-by-step outline for the Get Quote use case from the RU e-st system. The basic flow shows the major steps. The alternative flows show optional behavior.\nNotice the level of detail in this example. Remember, this is just a brief step-by-step outline to help understand what functions are contained in the use case. Further describe these steps in Module 8, Refine the System Definition.\n
  278. A package is a general-purpose grouping mechanism in UML.\nIf your model is too large to view as a single unit, you can break your model into packages. A package in a use-case model may contain use cases, actors and relationships; and perhaps other, smaller packages. \nThere are many ways to organize your packages. For example, one package might contain a particular actor and all the use cases that the particular actor can perform. Another popular grouping is to have each package contain all the use cases related to a particular feature.\nIf you are using packages, the Use-Case-Model Survey has a separate subsection in Section 3 for each package. Each subsection contains an overview of the package and the lists of Actors and Use Cases in the package.\nIn the book Use Case Modeling, a suggested guideline for organizing your model is:\nEach use-case package should contain 3 to 10 smaller units (use cases, actors, or other packages).\n0-15 units: No use-case packages needed.\n10-50 units: Use one level of use-case packages.\n&gt;25 units: Use two levels of use-case packages.\nNote: The quantities overlap because it is impossible to give exact guidelines.\n
  279. The approach to business modeling presented in the Rational Unified Process&amp;#xAE;&amp;#xF87F; includes a concise and straightforward way to generate requirements on supporting information systems. A good understanding of business processes helps you to build the right systems. \nA business model consists primarily of two parts. Each part plays an important role in understanding stakeholder needs.\nA Business use-case model shows the business intended functions. The business use-case model is used as an essential input to identify roles and deliverables in the organization. In requirements elicitation, the business use-case model helps develop the system use-case model of a particular system being developed.\nA Business object model describes things handled by the business, workers, and responsibilities; and the relationships between them. The business object model captures the vocabulary of objects in the business. The business object model is also used in the Design Workflow to help develop class diagrams and other parts of the system design.\nHaving a business model as input into the requirements management workflow is particularly useful if you intend to build one of the following systems: \nCustomized systems for one or more companies in a particular type of industry (banks, insurance companies)\nA family of applications for the open market (order handling systems, billing systems, air-traffic control systems)\n
  280. This example is from the RUP Business Modeling Guidelines: Going from Business Models to Systems. \nThe diagram above shows how there is a clear mapping between things found in a business model and the things in your system model. In this particular example, it is showing how a system can automate the responsibilities of a business worker. It is also showing how key business entities are candidates for automation.\nA business use case describes how the business delivers something of value to an actor of the business. The Business Object Model describes how the things inside the business collaborate to deliver the value described in the business use-case model. There are two important concepts in a business object model &amp;#x2013; the business worker and the business entity. A business worker represents a person or computer system that does work in the business. A business entity represents the information that the workers use in performing the business process.\nUse-Case Model Step 1 shows how a system can help with the business process. The workers in the business are the actors for the system.\nUse-Case Model Step 2 shows an example of replacing a customer-facing worker with a system. The customer is now the actor for the system.\nThe Analysis Model shows how the business entities map to classes in the system analysis model. These classes represent the &amp;#x201C;data&amp;#x201D; that the system will work with.\n
  281. The above list of use-case checkpoints is a summary of the list in the Rational Unified Process&amp;#xAE;&amp;#xF87F;.\n