les cas d`utilisation

Détermination et analyse des besoins : les cas d’utilisation
Le premier critère de qualité d’un logiciel est avant tout de répondre aux exigences
du client et aux besoins de ses futurs utilisateurs. Comme nous l’avons vu, les cahiers
des charges sont souvent confus et incomplets. Avec la complexité croissante des
applications , le problème d’une détermination et d’une compréhension à la fois
correcte et complète des besoins est ainsi devenu de plus en plus difficile. C’est dans
ce contexte que la technique des cas d’utilisation a été introduite puis formalisée par
Ivar Jacobson.
Les cas d’utilisation décrivent le comportement d’un système du point de vue
utilisateur. Ils permettent de définir les limites du système , c’est à dire ce qui relève
ou non de sa responsabilité, et les relations entre le système et son environnement.
Chaque cas d’utilisation décrit une fonctionnalité du système pour une catégorie
d’utilisateurs. On construit ainsi une partition de l’ensemble des besoins, ce qui
réduit considérablement la complexité de leur analyse.
De plus, comme nous l’avons déjà souligné, ils sont des instruments de tests et de
validation tout au long du processus de développement logiciel.
A. Les acteurs
1. Identification des acteurs
Les acteurs sont des personnes ou des choses extérieures au système (matériels,
autres systèmes) qui interagissent avec lui en échangeant de l’information (entrées /
sorties). On distingue différentes catégories d’acteurs :
- Les acteurs principaux : ce sont les
personnes pour qui le logiciel a été
conçu, c’est à dire qui utilisent celles
qui utilisent les fonctions
principales du système.
- Les acteurs secondaires : On
regroupe en général dans cette
catégorie les personnes intervenant
dans les tâches administratives ou
dans les opérations de maintenance.
- Le matériel externe (périphériques
utilisés …)
- Les autres systèmes avec lesquels le
logiciel interagit, échange des
informations.
Il faut identifier de manière claire et concise le rôle et les responsabilités de chaque
acteur.
Un acteur
<<acteur>>
Un autre acteur

2. Relation de généralisation / spécialisation entre acteurs
Un acteur B peut avoir accès aux mêmes
fonctionnalités qu’un autre acteur A, et en disposer de
nouvelles. On peut alors établir une relation de
généralisation entre acteurs. Cela clarifiera l’analyse
en évitant les redondances.
3. Exemples
Exemple 1: distributeur automatique de billets (DAB)
Un distributeur automatique de billets offre les services suivants :
- distribution d’argent à tout porteur de cartes de crédit
- consultation de solde pour les clients de la banque adossée au distributeur.
Toutes les opérations sont sécurisées.
acteur A
acteur B
Distributeur
PorteurDeCarte
ClientBanque
OpérateurMaintenance
<<acteur>>
SystèmeAutorisationBancaire
<<acteur>>
SystèmeInformationBanque

Exemple 2: un projet de nouvelle génération de cartes vitales …
La caisse primaire d’assurance maladie (CPAM) délivre les cartes vitales aux assurés
sociaux. Celles-ci comportent des informations administratives (nom, numéro INSEE,
régime d’assurance …) et un volet médical contenant des informations
confidentielles sur le dossier médical des patients (maladies, prescriptions …). En cas
de changements de statut (adresse, régime d’assurance, maternité …), c’est la CPAM
qui enregistre les modifications, mais les assurés devront mettre leur carte à jour
auprès des bornes mises à leur disposition dans les centres de sécurité sociale ou
dans les pharmacies. Une carte de professionnel de santé (CPS) est attribuée aux
différents professionnels de santé (médecins, pharmaciens …). Cette carte leur
permet de réaliser des feuilles de soins électroniques. Les deux cartes (carte vitale du
patient et CPS) doivent alors être insérées dans le lecteur. La consultation du dossier
médical est sécurisée et ne peut se faire qu’avec l’accord du patient qui possède pour
cela un mot de passe.
L’assurance maladie réceptionne les FSE et traite les remboursements.
Les acteurs principaux sont la CPAM, les assurés sociaux et les professionnels de
santé.
…
B. Les diagrammes de cas d’utilisation
Chaque cas d’utilisation décrit une fonctionnalité du système pour une catégorie
d’utilisateurs.
Une fois les différents acteurs identifiés, il faut pour chacun d’eux, répertorier les cas
d’utilisation auxquels il peut ou doit participer.
Les diagrammes de cas d’utilisation représentent :
- Les acteurs
- Les cas d’utilisation
- Les relations entre acteurs et cas d’utilisation (quels acteurs participent à quels cas
d’utilisation ?)

Exemple 1 : le DAB
Figure 1 : diagramme de cas d'utilisation préliminaire du DAB
C. Les relations entre cas d’utilisation
Afin d’ affiner et de clarifier les diagrammes, il peut être utile d’organiser et de
détailler les cas d’utilisation, éventuellement en les décomposant.
1. La relation d’inclusion
Certains cas d’utilisation ont une partie commune qui sera systématiquement
exécutée. On peut alors isoler cette partie et la factoriser dans un nouveau cas
d’utilisation qui sera inclus dans les précédents. Cela permet de décomposer les
comportements et de définir des enchaînements d’actions partageables par plusieurs
cas. Cela évite donc de décrire plusieurs fois le même enchaînement.
La relation d’inclusion a un caractère obligatoire.
2. La relation d’extension
3. La relation de généralisation
Distributeur
PorteurDeCarte
ClientBanque
OpérateurMaintenance
<<acteur>>
SystAutorBancaire
<<acteur>>
SystInfoBanque
Retirer argent
Consulter solde
recharger
Récupérer cartes avalées