chapitre 7.modélisation des cas d'utilisation Flashcards
Objectifs du MCU
- Définir le périmètre fonctionnel d’un système
- Spécifier son comportement
- Aider à identifier, comprendre et définir les besoins fonctionnels des utilisateurs du système
Principes du MCU
Modéliser le système de point de vue de ces utilisateurs - - comment les différents utilisateurs imaginent l’utilisation du système
- pour quel raison ils utiliseraient le système
- quel serait leur comportement en face du système
Décrire ce que le système doit faire – le comportement souhaité par ses utilisateurs
- pas comment réaliser ce comportement
- pas de détails de programmation, mise en œuvre, etc.
- indépendamment de la technologie de réalisation
Principaux concepts
Acteur : Un rôle joué par un utilisateur humain ou une
machine/automate qui interagit avec le système
Cas d’utilisation : Ce que les utilisateurs devraient être capables de faire avec le système
Relation entre les deux concepts
- L’ acteur déclenche un cas d’utilisation
- L’acteur intervient dans un cas d’utilisation d’un autre
acteur
Représentation des modèles
cf.cours
Acteur
Définition
- Ce qui existe en dehors du système et qui interagit avec le système pour une raison particulière
(Un humain, une machine, un autre système, une organisation)
- Ce qui doit échanger de l’information avec le système
- Correspond à un rôle générique que l’utilisateur joue
– une manière d’utiliser le système
(La même personne (machine, …) peut jouer plusieurs rôles)
Identification des acteurs
Une classification des acteurs comme aide à l’identification:
- Acteurs primaires – les personnes qui utilisent une ou plusieurs tâches principales du système
- Acteurs secondaires – les personnes qui supervisent et qui maintiennent le système
- Matériel externe – les dispositifs matériels périphériques qui font partie du domaine d’application et qui doivent être utilisés
- Autres systèmes – les systèmes/logiciels avec lesquels le système doit interagir
Qui sont les utilisateurs potentiels de la
bibliothèque?
=>Abonné
-Qui va superviser la bibliothèque?
=>Bibliothécaire
-Y aura t-il d’autres systèmes en connexion avec la bibliothèque?
=>Système de connexion entre plusieurs bibliothèques
Acteur ≠ Utilisateur
L’utilisateur est la personne qui utilise le système, tandis qu’un acteur représente un certain rôle qu’un utilisateur peut jouer
Cas d’utilisation
Définition
Une description d’un ensemble de séquences d’actions, incluant des variantes, qu’un système effectue pour
fournir un résultat observable et ayant une valeur pour un acteur
Un cas d’utilisation représente:
- Une utilisation du système par un acteur pour une raison particulière
- Quelque chose que l’acteur veut faire effectuer par le système
- Un service que le système doit rendre à ses utilisateurs - - Une suite complète de transactions entre l’acteur et le système
Identification des cas d’utilisation
Poser les questions:
- Quelles sont les principales tâches de chaque acteur?
- Pour quelle raison l’acteur aura besoin d’utiliser le système?
- L’acteur aura-t-il lire/écrire/modifier une information du système?
- L’acteur devra-t-il informer le système des modifications extérieures?
- L’acteur souhaite-t-il être informé de modifications inopinées?
(cf. Exemple slide)
Description des cas d’utilisation
Chaque cas d’utilisation peut être décrit par un scénario de base unique et plusieurs scénarios d’exception
- Scénario de base : le scénario principal donnant la meilleure compréhension du cas d’utilisation. L’acteur atteint son objectif en exécutant ce scénario.
- > : La procédure réussie pour enregistrer un emprunt par une bibliothécaire
- Scénario d’exception : le scénario décrivant une variante du scénario de base correspondant à un fonctionnement exceptionnel.
- > Ex. : La bibliothécaire ne peut pas enregistrer un emprunt car l’abonné est suspendu
- > : La bibliothécaire ne peut pas enregistrer un emprunt car le nombre d’emprunts autorisé est déjà atteint
Cas d’utilisation: Enregistrer un emprunt Scénario de base:
1) La bibliothécaire sélectionne la fonctionnalité ‘Enregistrer un emprunt’
2) Le système demande de scanner la carte de l’abonné
3) La bibliothécaire scanne la carte de l’abonné
4) Le système identifie l’abonné et affiche l’information concernant les emprunts en cours et l’état de l’abonné
5) Si l’abonné est actif est le nombre d’emprunts est inférieur au nombre maximal permis le système demande de scanner le code barre de l’ouvrage
6) La bibliothécaire scanne le code barre de l’ouvrage
7) Le système affiche le message ‘Emprunt enregistré’ et le nouveau emprunt est ajouté dans la liste des emprunts de l’abonné
Scénarios d’exception :Le nombre d’emprunts autorisé est atteint
5.1 Si l’abonné a déjà le nombre maximal d’emprunts, le système affiche le message ‘Interdiction d’emprunter d’autres ouvrages’.
(autre cas d’utilisation: cf Slide)
Règles d’écriture des scénarios
- Décrire l’activité : “quoi” pas “comment” Ex. le système vérifie l’identité de l’utilisateur
- Autonomie: Ne pas mélanger plusieurs cas d’utilisation.
Ex. Gérer le catalogue est trop abstrait, il faut décomposer en plusieurs cas d’utilisation: Ajouter un nouveau produit, Modifier le produit, Retirer le produit du catalogue - Un scénario est une transaction:
->Il y a un début et une fin
->Il est exécuté complètement ou pas du tout
- Donner un numéro de référence à chaque actions
- Utiliser des phrases simples et claires
- Utiliser un style direct
Moyens pour structurer un MCU
- Trois types de liens entre les cas d’utilisation:
- >Association d’extension – pour compléter le modèle
- >Association d’inclusion – pour structurer et organiser les cas d’utilisation dans un modèle, pour réutiliser les parties communes à plusieurs cas d’utilisation
- >Association d’abstraction – pour abstraire un comportement générique à partir des cas similaires
2.Lien de généralisation/spécialisation entre les acteurs
Association d’extension
L’association d’extension permet d’étendre un cas d’utilisation déjà complet pour modéliser:
- des parties optionnelles du cas d’utilisation
- des scénarios de remplacement qui n’arrivent que rarement
- des sous-scénarios qui ne s’exécutent que dans certains cas
Formalisation de l’extension:
- Point d’extension – définit l’endroit dans le cas principal où le cas d’extension peut être inséré
- Condition d’extension – précise sous quelle condition le cas d’extension peut être exécute
Comment se passe l’exécution d’un cas d’extension :
- L’exécution du cas de base est interrompu par le cas d’extension si la condition d’extension est satisfaite
- Le cas d’extension est exécuté complètement
- L’exécution du cas de base est repris à l’endroit où il a été interrompu
- Le cas de base est exécuté complètement
(cf. exemple)
Association d’inclusion
- Factorisation d’une partie de la description d’un cas d’utilisation qui serait commune à d’autres cas d’utilisation
- Décomposition d’un cas complexe en sous- cas plus simples
- A éviter une décomposition fonctionnelle du système !
(cf.exemple)
Généralisation/spécialisation des cas d’utilisation
- Abstraction à partir de plusieurs cas similaires un cas générique
- Modélisation de plusieurs variantes d’un cas d’utilisation
Un cas d’utilisation spécifique est une spécialisation d’un cas d’utilisation générique
(cf.exemple)
