A qui s'adresse cette présentation ?
Ce document n'est pas destiné aux analystes
amenés à définir et décrire des cas
d'utilisation. Il s'adresse plutôt aux
lecteurs de diagrammes "cas
d'utilisation".
Les "cas d'utilisation" sont une technique
standard (UML standard OMG) d'expression de besoins dans le
cadre de développements de logiciels. Cette technique
est basée sur la définition des besoins
à partir des échanges ou interactions
envisagées entre les utilisateurs et le logiciel. Elle
repose sur deux premiers éléments de base :
- Acteurs
- Cas d'utilisation.
|
| Acteurs |
|
| Un acteur est un élément externe au
logiciel qui échange des informations avec lui. Il
interagit avec lui. Un acteur est un utilisateur du logiciel au
sens "style" d'utilisation du logiciel. Par
exemple, un logiciel de comptabilité est utilisé
par des comptables et des experts-comptables.
Pratiquement, une même personne peut jouer les deux
rôles par rapport au logiciel. Les acteurs peuvent
être les utilisateurs pour lesquels le logiciel est
développé. Ils peuvent aussi être des
utilisateurs nécessaires au logiciel. Un logiciel de
comptabilité nécessite une utilisation telle que
"sauvegarde" qui n'est pas forcément
du ressort du comptable ni de l'expert-comptable. Un acteur
exploitant peut être créé pour
représenter ce type d'utilisation du logiciel. |
| Cas d'utilisation |
 |
| Un cas d'utilisation est une fonctionnalité
du logiciel, de haut niveau. C'est une situation
d'utilisation du logiciel. C'est simplement une
réponse à la question: dans quel cas, dans quelle
situation, souhaitez-vous utiliser ce logiciel ? |
| Communication acteur - cas d'utilisation |
| Les acteurs et le logiciel "dialoguent".
C'est indiqué par une ligne qui relie les deux
éléments. |
 |
| Représentation des fonctionnalités du
logiciel |
| En combinant ces trois éléments, un diagramme
"cas d'utilisation" visualise les utilisateurs du
logiciel et les utilisations qu'ils en ont. |
 |
| Description textuelle des cas d'utilisation |
| Chaque cas d'utilisation est en fait un ensemble
d'échanges entre l'acteur et le logiciel. Le cas
est alors décrit textuellement sous forme de suite
d'interactions. |
Cas "bordereaux"
1. Ce cas d'utilisation est déclenché par le
Comptable lorsqu'il fait apparaître le menu
"bordereaux".
2. Le logiciel affiche la liste des dix derniers bordereaux
saisis
3. Le comptable choisit l'un des éléments
suivants, éventuellement plusieurs fois de suite:
a) création de bordereau, le logiciel
affiche une grille, le comptable saisit la
référence du bordereau
4. etc |
| Expression de besoins avec les cas
d'utilisation |
L'utilisateur et l'analyste dialoguent pour
établir
- les cas d'utilisation
- leurs descriptions textuelles.
L'utilisateur joue son rôle: se mettre en
situation d'utilisation du futur logiciel, sans
préjuger de la faisabilité de tel ou tel
aspect.
L'analyste joue son rôle: décrire le cas,
sans empiéter sur le domaine de l'utilisateur, mais
en le guidant.
|
| Lecture de diagrammes cas d'utilisation et
descriptions textuelles |
La première chose à lire est l'ensemble des
acteurs (figurines): qui utilise le logiciel ? Ensuite, les cas
d'utilisation (ellipses) : quelles sont les situations
d'utilisation ou les fonctionnalités majeures du
logiciel ?
La description textuelle est écrite en langue courante,
autrement dit sans "raccourcis" ou
"subtilités" informatiques. L'objectif est
justement de faciliter la communication entre analystes et
utilisateurs. Si un lecteur éprouve de la
difficulté à lire un cas, il faut peut-être
repenser la rédaction pour obtenir quelque chose de plus
abordable. |
| Qui doit lire ? |
| Tous les "actionnaires" du projet sont
amenés à lire ces documents. |
| Quand les lire ? |
| Un cycle auteur-lecteur permet de mettre au point les cas
d'utilisation et leurs descriptions textuelles, au fur et
à mesure de leur rédaction. |
| Quel intérêt ? |
Cette technique permet d'obtenir:
- les acteurs, autrement dit les utilisateurs du logiciel.
La question: "à qui est destiné le
logiciel que l'on construit ?" semble triviale...ce
n'est pas si sûr :o)
- L'expression de besoins au travers de mise en
situation d'utilisation du logiciel. Il ne s'agit pas
de spéculer sur des fonctionnalités mais de
placer les utilisateurs "devant" leur
logiciel.
|
| Le résultat est facilement lu par tous; cela
améliore la communication et les discussions autour des
besoins. Par ailleurs, les "développeurs" sont
guidés par ces descriptions tout au long des
développements. |
