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. Un acteur <<acteur>> Un autre acteur Il faut identifier de manière claire et concise le rôle et les responsabilités de chaque 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. acteur A acteur B 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. OpérateurMaintenance PorteurDeCarte Distributeur <<acteur>> SystèmeAutorisationBancaire ClientBanque <<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 Distributeur <<acteur>> SystAutorBancaire PorteurDeCarte Retirer argent Consulter solde <<acteur>> SystInfoBanque ClientBanque recharger Récupérer cartes avalées OpérateurMaintenance 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