<!-- Slide number: 1 -->
Diagramme de cas d’utilisation
Mme CHALOUAH Anissa
I.S.E.T Bizerte
Département Technologies de l’informatique
<!-- Slide number: 2 -->
Modélisation des besoins
Modéliser les besoins permet de :
Faire l'inventaire des fonctionnalités attendues
Organiser les besoins entre eux, de manière à faire apparaître des relations (réutilisations possibles, ...).
Avec UML, on modélise les besoins au moyen de diagrammes de cas d'utilisation.
Avant de développer un système, il faut savoir précisément à QUOI il devra servir, c’est-à-dire, à quels besoins il devra répondre.
<!-- Slide number: 3 -->
Exigences fonctionnelles
Modèle construit en phase de définition des exigences fonctionnelles et enrichi pendant la phase d'analyse en utilisant d'autres modèles(entre-autres les modèles d'interaction)
Objectifs :
identifier les fonctionnalités du logiciel
en définir le périmètre
identifier les éléments externes en interaction directe
<!-- Slide number: 4 -->
Acteurs
Définition
Un acteurs est une entité extérieure au système modélisé, et qui interagit directement avec lui.
il peut consulter et/ou modifier l’état du système par messages.
Représentation
h
<!-- Slide number: 5 -->
Identification des acteurs
Les acteurs sont les utilisateurs du système.
Un acteur correspond à un rôle, pas à une personne physique.
Une même personne physique peut être représentée par plusieurs acteurs si elle a plusieurs rôles.
Si plusieurs personnes jouent le même rôle vis-à-vis du système, elles seront représentées par un seul acteur.
En plus des utilisateurs, les acteurs peuvent être :
Des périphériques manipulés par le système (imprimantes...)
Des logiciels déjà disponibles à intégrer dans le projet ;
Des systèmes informatiques externes au système mais qui interagissent avec lui, etc.
Pour faciliter la recherche des acteurs, on se fonde sur les frontières du système.
<!-- Slide number: 6 -->
Acteurs principaux et secondaires
Publicité
L'acteur est dit principal pour un cas d'utilisation lorsque l'acteur est à l'initiative des échanges nécessaires pour réaliser le cas d'utilisation.
Les acteurs secondaires sont ceux sollicités par le système.
Le plus souvent, les acteurs secondaires sont d'autres systèmes informatiques avec lesquels le système développé est interconnecté.
Le stéréotype « primary » vient orner l'association reliant un cas d'utilisation a son acteur principal.
Le stéréotype « secondary » est utilise pour les acteurs secondaires;
<!-- Slide number: 7 -->
Acteurs principaux et secondaires : Exemple
Le système étudié est un logiciel de partage de fichier qui permet à un internaute de télécharger des fichiers à partir d’un ordinateur connecté (serveur de fichiers).
<!-- Slide number: 8 -->
Relations entre acteurs
La seule relation possible entre deux acteurs est la généralisation.
un acteur A est une généralisation d'un acteur B si l'acteur A peut
être substitue par l'acteur B
tous les cas d'utilisation accessibles a A le sont aussi a B, mais
l'inverse n'est pas vrai.
<!-- Slide number: 9 -->
Cas d’utilisation
C’est un service rendu à l'utilisateur, il implique des séries d'actions plus élémentaires. (résultat observable pour un acteur).
Définit le comportement attendu (pas le mode de réalisation) :
ce que le futur système devra faire
pas comment il le fera
Un cas d'utilisation est l'expression d'un service réalisé de bout en bout, avec un déclenchement, un déroulement et une fin, pour l'acteur qui l'initie.
<!-- Slide number: 10 -->
Identification des cas d’utilisations
Ensemble des cas utilisation == exigences fonctionnelles du système
Un cas == fonction métier selon le point de vue des acteurs
Pour chaque acteur :
rechercher ses utilisations métiers
déterminer dans le cahier des charges les services attendus
Nommez les cas d'utilisation (point de vue acteur) :
verbe a l'infinitif + complément
<!-- Slide number: 11 -->
Relation entre cas d’utilisation et acteur
Les acteurs impliqués dans un cas d'utilisation lui sont liés par une association.
Un acteur peut utiliser plusieurs fois le même cas d'utilisation.
Publicité
<!-- Slide number: 12 -->
Orientation des interaction
En général, représente le sens de l’interaction
Absence d’orientation: double sens
<!-- Slide number: 13 -->
Relation entre cas d’utilisation
Inclusion : le cas A inclut le cas B
(B est une partie obligatoire de A).
Extension : le cas B étend le cas A
(B est une partie optionelle de A).
Généralisation : le cas A est une généralisation du cas du cas B.
(B est une sorte de A).
<!-- Slide number: 14 -->
Inclusion : Exemple
<!-- Slide number: 15 -->
Point d’extension
Points d’extension: partie ou point qui sera étendu par l’action d’un autre CU.
<!-- Slide number: 16 -->
Généralisation / Spécialisation
Un virement est un cas particulier de paiement.
Un virement est une sorte de paiement.
La flèche pointe vers l'élément général.
Cette relation de généralisation/spécialisation est présente dans la plupart des diagrammes UML .
Elle se traduit par le concept d'héritage dans les langages orientés objet.
<!-- Slide number: 17 -->
Réutilisation des CU
Les relations d’inclusion et d’extension permettent d’isoler un service réutilisable comme partie de plusieurs autres cas d’utilisation :
On parle alors de réutilisation.
Le code développé pour implémenter le cas d’utilisation réutilisé est d’emblée identifié comme ne devant être développé qu’une seule fois, puis réutilisé.
<!-- Slide number: 18 -->
Décomposition de CU
Un cas d’utilisation ne doit jamais se réduire à une seule action : il doit occasionner des traitements d’une complexité minimale.
Toutefois, il peut arriver qu’un cas d’utilisation recouvre un ensemble très important d’échanges et de traitements. Dans ce cas, on peut utiliser les relations d’inclusion et d’extension.
Publicité
Attention : ne jamais décomposer en première analyse, mais lorsqu’on a suffisamment avancé dans la conception ou le codage pour être certain que la décomposition est utile.
<!-- Slide number: 19 -->
Acteurs et cas d’utilisation
<!-- Slide number: 20 -->
Exemple de diagramme de CU
<!-- Slide number: 21 -->
Recenser les cas d’utilisations
Il n'y a pas une manière mécanique et totalement objective de repérer les cas d'utilisation.
Il faut se placer du point de vue de chaque acteur et déterminer :
Comment il se sert du système,
dans quels cas il l'utilise,
à quelles fonctionnalités il doit avoir accès.
Il faut éviter les redondances et limiter le nombre de cas en se situant au bon niveau d'abstraction (par exemple, ne pas réduire un cas à une seule action).
Il ne faut pas faire apparaître les détails des cas d'utilisation, mais il faut rester au niveau des grandes fonctions du système.
<!-- Slide number: 22 -->
Description des cas d'utilisation
Le diagramme de cas d'utilisation décrit les grandes fonctions d'un système du point de vue des acteurs, mais n'expose pas de façon détaillée le dialogue entre les acteurs et les cas d'utilisation.
Un simple nom est tout à fait insuffisant pour décrire un cas d'utilisation.
Chaque cas d'utilisation doit être documenté pour qu'il n'y ait aucune
ambiguïté concernant son déroulement et ce qu'il recouvre précisément.
<!-- Slide number: 23 -->
Description textuelle
Identification
Nom : Nom du CU étudié (Utiliser une tournure à l'infinitif).
Objectif : résumée permettant de comprendre le but principale du cas d’utilisation.
Acteurs principaux :Ceux qui vont réaliser le cas d’utilisation.
Acteurs secondaires :Ceux qui ne font que recevoir des informations à l’issue de la réalisation du cas d’utilisation.
Date : Dates de créations et de mise à jour de la description courante.
Responsables : Le nom des responsables.
Version : Numero de version
<!-- Slide number: 24 -->
Description textuelle
Description des scénarios
Pré-conditions :
Elles décrivent dans quel état doit être le système avant que ce cas d’utilisation puisse être déclenché.
Enchaînement nominal :
Enchainements d’actions s'exécutant du début à la fin du cas sans rencontrer de problème particulier .
Enchaînements alternatifs :
Publicité
Enchainements d’actions au cas ou le système rencontre des exceptions.
Enchaînements d’erreur :
(qui se terminent par un échec)
Post-conditions :
Elles décrivent l’état du système à l’issue des différents scénarii.
<!-- Slide number: 25 -->
Exemple : CU Payer CB
Identification
Nom du cas : Payer CB
Objectif : Détailler les étapes permettant à client de payer par carte bancaire
Acteurs : Client, Banque (secondaire)
Date : 18/09
Responsables : Toto
Version : 1.0
<!-- Slide number: 26 -->
Exemple : CU Payer CB
Description des scénarios:
Le cas d'utilisation commence lorsqu'un client demande le paiement par carte bancaire
Pré-conditions
Le client a validé sa commande
Enchaînement nominal
Le client saisit les informations de sa carte bancaire
Le système vérifie que le numéro de CB est correct
Le système vérifie la carte auprès du système bancaire
Le système demande au système bancaire de débiter le client
Le système notifie le client du bon déroulement de la transaction
<!-- Slide number: 27 -->
Exemple : CU Payer CB
Enchaînements alternatifs
En (2) : si le numéro est incorrect, le client est averti de l'erreur, et invité à recommencer
En (3) : si les informations sont erronées, elles sont redemandées au client
Post-conditions
La commande est validée
Le compte de l'entreprise est crédité
Rubriques optionnelles
Contraintes non fonctionnelles :
Fiabilité : les accès doivent être sécurisés
Confidentialité : les informations concernant le client ne doivent pas être divulgués
Contraintes liées à l'interface homme-machine :
Toujours demander la validation des opérations bancaires