Remarque: cette partie - entre autre - est le résultat d'un travail très coopératif mené avec un collègue et ami: Olivier Capuozzo qui fit un à mon goût un trop bref séjour au lycée Voillaume et qui est aujourd'hui enseignant à Melun  

                                       CAS D'UTILISATION

                  Les cas d'utilisation.

        Les cas d'utilisation servent à décrire les fonctionnalités du système,  perçues par ses utilisateurs. Il s'agit donc de décrire le comportement d'un système sans se soucier du " comment ".

                           Définitions

        Un cas d'utilisation spécifie une séquence d'actions, avec variantes éventuelles, réalisée par le système en interaction avec des acteurs du système.

        Un acteur représente un ensemble de rôles qu'un "utilisateur" d'une entité du système peut jouer lorsqu'il est en interaction celle-ci. Un acteur est considéré jouer un rôle particulier pour chaque cas d'utilisation auquel il participe.

        Un diagramme de cas d'utilisation  montre graphiquement les interactions entre acteurs et système.
 

D'autres définitions des cas d'utilisation apparaîtront dans ce document.
 

                            Positionnement

        Le terme use case (cas d'utilisation) a été introduit par I. Jacobson en 1992 et fait partie intégrante d'UML.
 

        Un processus de développement moderne qui s'appuie sur UML est en général:

        - Piloté par les cas d'utilisation
        - Centré sur l'architecture
        -  Itératif et incrémental.

        Ceci est particulièrement vrai pour UP (Unified Process) qui est une méthode générique de développement de logiciel présentée par I.Jacobson, G.Booch, J.Rumbaugh dans leur livre "The Unified Software Development Process" chez  Addison-Wesley (ISBN 0-201-57169-2).

        Les cas d'utilisation (use case) permettent de ne pas perdre de vue les objectifs du système en construction. Ils pilotent le projet tout au long de sa vie. Ils sont le fil conducteur de tous les acteurs du projets (analystes, architectes de classe, qualiticiens, managers, utilisateurs, clients, développeurs, testeurs…)

        Les cas d'utilisation modélisent les interactions du système avec l'extérieur. Ils donnent ainsi une vision externe du système.

        Certaines interactions sont partagées par plusieurs cas d'utilisation et peuvent ne pas être déclenchées directement par un acteur.
 

Exemple: distributeur automatique de boissons
 

        Le système sera le distributeur de boisson perçu par l'acteur principal - le client - comme une boite noire apte à lui fournir des services. Le cas d'utilisation " Servir " est le regroupement d'interactions atomiques:

                            1- Le client tape le code de la boisson
                            2- Le système affiche le prix à payer et est en attente de pièces.
                            3- Itérer            le client insère une pièce
                                                   Le système vérifie la pièce
                                                   Le système affiche le reste dû
                               Fin itérer
                              4- Le système rend la monnaie.
                              5- Le système délivre la boisson
                              6- Le système se réinitialise.

            Ce cas d'utilisation est déclenché par l'événement " Code de la boisson tapé "
 

            Ce cas d'utilisation pourra connaître plusieurs variantes, qualifiés de scénarios:

            Par exemple si l'utilisateur tape un code invalide ou le code d'une boisson non disponible, l'interaction 2 sera différente, de même si le client insère une pièce non acceptée une interaction supplémentaire serait " Rejet de la pièce "; le client peut également annuler la transaction.
            Ainsi ce cas d'utilisation pourra se décliner en une dizaine de scénarios.

            La relation entre cas d'utilisation et scénarios peut être rapproché des notions classes/instances.

Interprétation:

 

                               Recueillement des cas d'utilisation

            Les cas d'utilisation sont recueillis, organisés, décomposés dans la phase d'acquisition des besoins dynamiques du projet.

            Le formalisme clair permet de faire participer à cette phase des non informaticiens tels que utilisateurs (ou leur représentant), experts du domaine, managers, …

                                Représentation des cas d'utilisation

            Un cas d'utilisation peut être décrit sous une forme textuelle au format libre ou structuré selon une normalisation issue d'une démarche qualité (préférable). Voir en annexe A un exemple de modèle textuel. Ce format, lisible pour un non informaticien, peut séduire au début d'un projet. Toutefois sachant "qu'un dessin vaut mieux qu'un long discours", UML propose de représenter les cas d'utilisation sous une forme graphique nommée diagramme de cas d'utilisation. Les rôles sont définis pour chaque acteur . Une relation entre acteurs et cas représente une communication entre l'acteur et le cas. Le cas (d'utilisation) et représenté par une ellipse qui porte son nom (à l'intérieur ou en–dessous). Des notes peuvent être portées sur le diagramme afin d'y ajouter des informations.

            Un diagramme de cas d'utilisation montre acteurs et cas d'utilisation ensemble avec leur relations.

La relation entre un acteur et un cas d'utilisation est appelée association et correspond au fait que l'acteur participe à un cas d'utilisation.

Les cas d'utilisation représente les fonctionnalités d'un système, ou entité d'un système, telles qu'elles sont sollicitées en interaction avec des événements extérieurs. Ils donnent une vision "haute" et dynamique du système.

Exemple d'un cas d'utilisation : Consultation de compte

Description : Le système permet au client de consulter lui-même son compte.

Diagramme de cas d'utilisation : "Client" est un acteur, "Consulter un compte" un cas d'utilisation.

Éléments graphiques des diagrammes de cas d'utilisation

Acteur : un bonhomme en fil de fer

Cas d'utilisation : une ellipse

Association : (participation d'un acteur à un cas d'utilisation) un trait plein pouvant être orienté (pointe de flèche) et décoré (cardinalités).
 
 

                                   Granularité des cas d'utilisation.
 

            Un problème fréquent se pose concernant la "finesse" de description des fonctionnalités d'un système. Il faudra exclure toute conception basée sur une organisation purement hiérarchique des cas d'utilisation. Il ne faut pas oublier qu'un cas d'utilisation peut comprendre plusieurs scénarios, c'est à dire un ensemble d'interactions.

            Aussi un cas d'utilisation doit représenter une "grande fonctionnalité" du système perçu par l'utilisateur."Le guide de l'utilisateur UML " écrit par les trois concepteurs d'UML recommande qu'un système peu complexe comporte une douzaine de cas d'utilisation, déclinable chacun en une dizaine de scénarios. Dans l ' " Introduction au RUP ", P. Kruchten indique qu'un petit système peut s'exprimer en une demi-douzaine de cas d'utilisation comportant deux ou trois acteurs. De même P. Roques et Franck Vallée - de la société Valtech- dans "UML en action" mettent en garde contre un nombre trop important de cas d'utilisation: " Limitez à 20 le nombre de vos cas d'utilisation". Pierre-Alain muller in "Modélisation objet avec UML"  précise " un grand nombre de cas d'utilisation est le signe d'un manque d'abstraction "
 

              Les relations entre cas d'utilisation.
 

        Il existe (UML 1.3) trois types de relation entre cas d'utilisation, .<<include>>, <<extend>> et généralisation. Les deux premières sont représentées par un stéréotype de dépendance, l'autre étant la relation de généralisation représentée en UML par une flèche à pointe fermée.

                                relation include.

        <<include>> est le stéréotype représentant le fait qu'un cas d'utilisation inclut un autre cas d'utilisation. On utilise ce stéréotype lorsque que l'on souhaite factoriser un ensemble d'interactions partagé par plusieurs autres cas d'utilisation. Exemple. Une opération de retrait et une opération de transfert nécessite toutes deux une opération de vérification de l'identité du client.
 
 

            On remarquera que le cas d'utilisation "Vérifier identité" n'est de ce fait pas en contact direct avec l'acteur.

Remarque :
La relation <<uses>> UML 1.1 a fait place avec la version UML 1.3 à <<include>>. Voir la présentation de Martin Fowler sur ce thème à http://ourworld.compuserve.com/homepages/Martin_Fowler/.
La page "UML - Current Status for version 1.3"

    " On utilise une relation d'inclusion pour éviter de décrire le même flot d'événement plusieurs fois, et ce en rangeant le comportement commun dans un cas d'utilisation propre ( le cas d'utilisation inclus dans le cas principal )." in " Le guide de l'utilisateur UML".

Interprétation

        Ainsi la mise en évidence des relations d'inclusion relève souvent d'une seconde "passe" visant à factoriser un ensemble d'interactions factorisables.
 

                                Relation extend.

         Un cas d'utilisation peut déclarer des points d'extension. Un point d'extension localise une endroit (un point) unique dans le cas d'utilisation. C'est dans les limites de ce point que d'autre cas d'utilisation pourront étendre (extend) le comportement initial du cas d'utilisation. Par exemple. Vous concevez un site marchand pour un fabricant de produit de beauté et souhaitez proposer à certains  visiteurs de promouvoir la marque dans leur région.
 

            An extends relationship is used to show:
    * Optional behaviour
    * Behaviour that is only run under certain conditions,such as triggering an alarm
    * Several different flows which may be run based on Actor selection
(source Terry Quatrani: visual modeling with Rat. Rose and UML)
 

Diagramme.

    Le cas de base "Passer commande" peut éventuellement être étendu en son point d'extension "Fixer priorité " au cas " Passer commande urgente"  . A noter que le cas d'utilisation "Extend " est optionnel.

Interprétation:

                        Généralisation/spécialisation 

        Une relation de généralisation d'un cas d'utilisation A  vers un cas d'utilisation B signifie que A est une spécialisation de B. Contrairement aux deux autres relations, la relation de généralisation n'est pas un stéréotype. Elle indique qu'un cas d'utilisation est une variation d'un autre. Cette relation se différencie de <<extend>> par le fait que le cas d'utilisation peut varier en tout point de celui hérité. Par exemple reprenons notre UC "Retirer de l'argent". Si le compte n'est pas suffisamment approvisionné le comportement de notre UC peut être tout à fait différent et le client se voir refusé l'opération de retrait.

                 Classification des acteurs

    Les acteurs sont des entités en interaction avec le système. Le niveau de détail de présentation d'un cas d'utilisation correspond à la vision de l'acteur auquel il est relié.

Parmi les acteurs nous pouvons distinguer les acteurs principaux et secondaires. Les fonctionnalités principales du système ont été définies pour les acteurs principaux. Afin d'atteindre cet objectif, il est en général nécessaire de réaliser des opérations en amont et en aval de ces fonctions principales. Cela peut être par exemple la gestion des droits utilisateurs, sauvegarde de la base de donnée, etc. En fait par acteur secondaire on entend les acteurs jouant le plus souvent des rôles d'administration et d'exploitation du système.

Nous avons donné un exemple de classification en fonction des rôles joués par les acteurs, c'est à dire par quelque chose qui interagit avec le système. Cette chose peut être humaine ou de nature purement informatique (hardware ou software). On peut ainsi classer les acteurs selon leur nature (les acteurs sont des classificateurs) et les stéréotyper.
 

Dans les diagrammes de cas d'utilisation le lecteur s'attend à trouver les acteurs principaux à gauche du contexte des ellipses et les acteurs secondaires à droite.
 
 

                                        Cycle de vie des cas d'utilisation

En fait, là aussi une démarche itérative et incrémentale s'impose.
Une erreur courante : L'informaticien s'accapare (une bonne fois) les besoins utilisateurs et lui ressort formalisés, (trop) bien formatés qu'ils ne peut comprendre.
 

Il y a un grand risque que les utilisateurs, experts de domaine, ne puissent comprendre l'interprétation qui est faite de leurs besoins. Ainsi tout l'intérêt des cas d'utilisation tombe à l'eau.
 

                                        UC Exemple de démarche

1-) Identifier les acteurs principaux du système (ceux pour qui le système est construit)
2-) Relever les "grandes fonctionnalités" attendues du système. Ce sont les fonctionnalités situées à la "périphérie" du système, frontière entre utilisateurs principaux et système.
3-) Noter les associations entre acteurs et les cas d'utilisation principaux relevés précédemment.
4 ) Rédiger les documents descriptifs des cas d'utilisation
5-) Valider la modélisation auprès des représentants utilisateurs, experts de domaine, managers...

 6) Recommencer les étapes 1 à 5 en s'intéressant aux acteurs secondaires (administration du système, agent d'exploitation...)

X) Structurer si nécessaire le modèle en paquetages
XI) Puis itérer sur l'ensemble ou partie du modèle afin d'en affiner *éventuellement* le contenu (include, extend, généralisation).

Conclusion

Les cas d'utilisation donnent une vue d'altitude des interactions "visibles" d'un système, ils ne fournissent pas d'information sur la structure interne. Ils servent à mettre en évidence, à organiser les différentes interactions du système avec les utilisateurs, à catégoriser ces derniers, définir leurs attentes (objectifs du SI) et obligations (pilotage du SI).

La recherche des cas d'utilisation permet de formaliser les réponses aux questions : "Pourquoi" (les intentions du système) et "pour qui" (les acteurs).

les 3 ions - ou les 3 SOO

généralisation : Substitution
<<extend>> :  Option
<<include>> : Obligation
 
 

Citons Thierry Cros : Les cas d'utilisation permettent de créer le dialogue entre utilisateurs et informaticiens : tout le reste est à prendre avec circonspection. En effet, la phase suivante d'analyse est là pour affiner le "quoi" du système. De façon générale, elle met en jeu des outils bien plus complets : panoplie des diagrammes UML par exemple, qui sont très utiles aux informaticiens et aussi illisibles par les utilisateurs.
 

 
 
 
 

Cas d’utilisation		<identifiant><nom>
Acteurs		<liste des acteurs participants à ce cas>
But		<ce qu’apporte le cas d’utilisation à son acteur principal>
Description		<une présentation rapide et générale des interactions entre le systèmes et les acteurs>
Sources		<sources où sont exprimés les besoins; peut se référer à des exigences numérotées>
Pré-conditions		<décrit l'ensemble des prérequis nécessaires à la réalisation du cas d'utilisation>
Condition de déclenchement		<présente les différents déclencheurs possibles du cas d'utilisation>
Condition de succès		<décrit les situations correspondant à une réalisation réussie du cas d'utilisation>
Condition d'échec		<décrit les situations correspondant à un échec de réalisation du cas d'utilisation>
Niveau		<contextuel, primaire, secondaire ou système>
Priorité		<haute, moyenne ou basse selon l’impact sur l’architecture et la limitation des risques>
Suite typique d’échanges			Action de l’acteur	Action du système ou cas d'utilisation s'y référant
		1
		2
		3
		4
		5
		6
		7
		…
Variations
		1
		…
Performance	<combien de temps prend-il ?>
Fréquence	<nombre d’occurrences de ce cas>
Fiabilité
Commentaires