Docstoc

4_Diagramme_de_cas_d_utilisation

Document Sample
4_Diagramme_de_cas_d_utilisation Powered By Docstoc
					Diagramme des cas d'utilisation



I. Rôle et objectif

C’est un diagramme très important qui permet de déterminer les frontières du système et de le
placer dans son contexte.

Il permet de représenter les fonctionnalités ou services attendus par le système du point de
vue de l’acteur.


II. Présentation du diagramme de cas d'utilisation

L'acteur

              Il représente dans le diagramme un élément externe qui interagit avec le système. Cet
              élément peut être un utilisateur ou un système tiers (autre ordinateur, autre
              programme,…).

           Tous les éléments extérieurs qui stimulent le système et tous les éléments extérieurs qui
sont utilisés par le système sont représentés par des acteurs.

Dans le cas d'acteurs non-humains il est possible de définir une « Interface » qui représente les
opérations offertes par cet acteur.

  <<actor>>      Il est possible de représenter un acteur sous forme d'un bonhomme à ou sous forme
    Client
                 d'un classeur.

La fonctionalité

Les cas d'utilisation se représentent par une ellipse contenant un nom
décrivant la fonctionnalité et éventuellement un stéréotype.

Remarque : Ce nom doit se composer d'un verbe à l'infinitif qui décrit
une action. Pour que l'ensemble du modèle soit cohérent il faut choisir tous les verbes soit du point
de vue du système soit du point de vue de l'utilisateur (ce qui est généralement préférable).

Ce diagramme est classé dans la catégorie des diagrammes comportementaux. En général il
est très mal compris, ce qui est normal car il n’est pas immédiat d’en saisir son sens. Il permet de
représenter les fonctionnalités ou services attendus par le système du point de vue de
l’acteur, donc d’un point de vue extérieur.

 Quand on parle de fonctionnalité, on ne parle pas de fonction au sens classique que l’on peut
trouver dans la SADT. On ne retrouve pas les fonctions d’un système dans une découpe
fonctionnelle.




Diagramme de cas d'utilisation, jltimin                                                            1
(source: pairformance)
A ce niveau, les fonctions internes du système ne nous intéressent pas et les solutions
constructives ne sont pas encore connues ou du moins pas dans les détails.

 « La recherche des cas d’utilisation consiste à trouver des cas dans lesquels le système
est utilisé pour mener à bien une tâche spécifique d’un acteur, c'est-à-dire un cas
d’utilisation. »( l’éditeur O’Reilly ).

Un cas d’utilisation, un service ou une fonctionnalité est donc:

         déclenché par un acteur,

         suit des étapes

         et se termine       (le service doit être rendu).

Si un cas d’utilisation ne respecte pas cette suite, alors cela n’en est certainement pas un !


III. Les "services" rendus par le système

La balance rend deux services :

         celui de peser des aliments,

         et celui de convertir la pesée en volume
          d’eau.

Ce sont ceux que l’utilisateur peut mettre en œuvre.
Elle ne rend aucun autre service. Le diagramme de
cas d’utilisation permet de bien le faire ressortir.

L’interaction est représentée ici par une ligne
appelée Association. Elle ne laisse présager ni du sens ni de la nature de l’interaction (elle peut
être monodirectionnelle ou bidirectionnelle).

Par une certaine action de l’acteur (non précisée encore à ce stade, dépose de quelque chose sur
le plateau ou bien appuie sur un bouton), le système va peser et afficher le résultat.

Précisions sur les acteurs : un acteur représente un rôle qui peut être tenu par un humain ou
n’importe quel autre système. Il indique avec quoi le système sera en interaction.


IV. Liens entre cas d'utilisation

On peut voir que le cas d’utilisation Convertir la pesée en volume d’eau est relié au cas Peser les
aliments avec un lien de type « extend ». Ce lien indique que dans toutes les étapes menant à
peser des aliments, il est possible mais pas obligatoire de demander une conversion à un
moment donné (attention au sens !). Cette précision permet de dégager des sous-fonctionnalités
et donc de mieux comprendre ce qui peut se faire.



Diagramme de cas d'utilisation, jltimin                                                           2
(source: pairformance)
Les autres liens :

         Lien de type Inclusion : permet de faire
          ressortir une sous-fonctionnalité. Toutes les
          étapes du cas d’utilisation inclus sont
          intégralement reprises dans le cas d’utilisation
          incluant. Ci-dessous le cas 1 inclut le cas 2.


                                                    Lien de type spécialisation/généralisation :
                                               montre qu’un cas d’utilisation est un cas particulier de
                                               l’autre. Il y a donc un cas général et un cas plus précis
                                               dans la description. Ci-dessous un exemple :


L’important dans ce type de diagramme est de faire ressortir les fonctionnalités principales, c’est-à-
dire ce qu’un acteur (utilisateur la plupart du temps) va pouvoir vérifier ou constater . Apporter de
la précision par la recherche de sous-fonctionnalités est louable mais peut-être source d’erreurs !


V. Traduction littérale des cas d'utilisations


                               L’analyse associée à la construction d’un diagramme de cas
                               d’utilisation permet de dégager les fonctionnalités que l’on retrouvera
                               sous forme d’ovales ainsi que les acteurs avec lesquels le système va
      interagir. Malheureusement cette description peut s’avérer un peu trop concise pour bien
      comprendre la fonctionnalité attendue. Pour cela, il est conseillé (si cela est pertinent bien sûr)
      de décrire le cas d’utilisation de manière plus explicite. Il n’y a pas de norme absolue sur ce
      point mais voici un exemple des renseignements que l’on peut y trouver :

Nom du cas d’utilisation          Commentaires

Exigences associées               Indiquent les exigences auxquelles ce cas d’utilisation répond
                                      partiellement ou totalement.

Conditions de succès              Indiquent les conditions qui mènent à un service effectivement rendu.

Conditions d’échec                Indiquent les conditions qui mènent à un service non rendu.

Déclencheur                       L’événement déclenché par un acteur qui provoque l’exécution du cas
                                      d’utilisation.

Flux principal                    Description de chaque étape importante de l’exécution normale du cas
                                     d’utilisation.

etc




Diagramme de cas d'utilisation, jltimin                                                                    3
(source: pairformance)
Voici ce que cela peut donner sur le cas d’utilisation de la balance :

Nom du cas d’utilisation          Peser des aliments

Exigences associées               Indiquent les exigences auxquelles ce cas d’utilisation répond
                                  partiellement ou totalement.

Conditions de succès              Le poids total ne doit pas dépasser 2 kg.

Conditions d’échec                Le poids dépasse 2 kg.

Déclencheur                       L’utilisateur appuie sur un bouton.

Flux principal                               L’utilisateur appuie sur le bouton de mise en marche.
                                             La balance se tare et affiche « 0 g ».
                                             L’utilisateur dépose sur le plateau ce qu’il souhaite.
                                             L’affichage se met à jour en temps réel.
Extensions                                   Après dépose d’un aliment l’utilisateur peut tarer la balance
                                              par appuie sur un bouton.
                                             L’utilisateur peut demander à convertir le poids en volume
                                              d’eau.


La forme est libre, l’objectif étant de faire ressortir le mieux possible ce que le cas réalise et dans
quelles conditions. Ce genre de tableau se fait en relation avec le client afin d’éclaircir tous les
points.


VI. Evolution du diagramme de cas d'utilisation de la balance HALO


Dans la description ci-dessus, il est évoqué que la balance peut être tarée à la demande de
l’utilisateur. Ceci peut être bien pratique lorsque vous ajoutez des ingrédients au fur et à mesure
dans un bol, sans avoir à additionner les poids successifs de ce que vous ajoutez afin de suivre la
recette. Dans ce cas, on peut le faire apparaitre sur le diagramme de cas d’utilisation afin de
préciser ce que le système sait faire. Ce qui donne :


                                   La première version du diagramme reste correcte mais moins précise.
                                   Le cas d’utilisation Convertir la pesée est indispensable pour montrer
                                   ce que le système permet de faire. L’ajout du cas d’utilisation Tarer
                                   n’est pas obligatoire mais permet de faire ressortir une sous-
                                   fonctionnalité. Ce choix est laissé au concepteur des diagrammes. Le
                                   lien d’inclusion (<<include>>) se justifie par le fait que le tarage est
                                   toujours utilisé par le cas Peser les aliments (ici au démarrage de la
                                   balance), son utilisation n’est donc pas optionnelle.




Diagramme de cas d'utilisation, jltimin                                                                       4
(source: pairformance)

				
DOCUMENT INFO
Shared By:
Categories:
Tags:
Stats:
views:23
posted:9/15/2012
language:Unknown
pages:4