Embed Size (px)
Citation preview
ISI1 – L3 Miage 1
2012-2013
UML - Diagramme de cas d’utilisation
1
Diagramme de cas d’utilisation
• Le développement ou l’amélioration d’un système doit toujours répondre à un ou plusieurs besoins
• Le travail de modélisation commence par l’identification des besoins – Le recueil des besoins implique une bonne
compréhension des métiers impliqués • Intégration des contraintes et des exigences de chaque
métier
– Le MOA intervient pour • Définir / identifier les besoins • Valider les solutions proposées et mises en œuvre par le
MOE
2
Diagramme de cas d’utilisation
• Analyse des besoins correspond au début de toute bonne modélisation – Phase « études des besoin » méthode en cascade
– Phase « spécification » méthode en « V »
– Phase « Business modeling » méthode RUP
• Quel aide UML apporte lors du recueil des besoins ? – Diagramme des cas d’utilisation
3
Diagramme de cas d’utilisation
• À cette étape de la modélisation (l’analyse des besoins), on souhaite – Identifier les frontières du système
– Spécifier les fonctionnalités qu’il doit offrir aux utilisateurs
• Diagramme de cas d’utilisation (Use Case diagram) – Recensement des grandes fonctionnalités du système
– Formalisation des besoins
– Représentation graphique des besoins
– Compréhensible par tous
– Point de vue utilisateur
4
ISI1 – L3 Miage 2
2012-2013
Distributeur Automatique
Eléments de base
• Cas d'utilisation, • Acteur, • Relations (entre un cas d’utilisation et un acteur,
entre acteurs, entre les cas d’utilisation )
frontière du système associations
cas d’utilisation
acteur
5
Retirer de l’argent
Consulter solde
Client
Cas d’utilisation
– Service (fonctionnalité) rendu par le système à un utilisateur / composé d'un ensemble d'actions (déclenché par un acteur) réalisé par le système et qui produisent un résultat significatif pour un acteur particulier.
– Exemples :
• Consulter un compte, Retirer de l’argent, Déposer un chèque…
– Formalisme graphique :
6
Verbe + complément Consulter le solde
Acteur
• Un acteur représente un rôle joué par une entité externe qui interagit directement avec le système étudié.
– Exemple : Client, Conseiller financier, SI Banque, …
• Un acteur est une entité appartenant à l'environnement du système
• Formalisme graphique
7
Acteur : formalisme
8
Client Acteur humain
<<actor>>
Acteur humain
« actor »
Client
Système externe Serveur Paypal
Formalisme Exemple
ISI1 – L3 Miage 3
2012-2013
Acteur
• Trois types d ’acteurs – les personnes : ce sont des utilisateurs du système – le matériel externe : dispositif utilisé par le système
• Une imprimante, un capteur de température
– les autres systèmes qui communiquent avec le système • Le groupement bancaire dans un système de distributeur de
billets
• Important – Même si on les représente dans les modèles, les
acteurs ne font pas partie du système puisqu’ils résident en dehors de celui ci.
9
Acteur principal / secondaire
• Un cas d'utilisation a toujours au moins un acteur principal pour qui le système produit un résultat observable, et éventuellement d'autres acteurs ayant un rôle secondaire.
– Un acteur principal déclenche un cas d’utilisation
– Un acteur secondaire consulte ou informe le système lors de la réalisation d’un cas d'utilisation.
10
Acteur principal / secondaire
11
Gestion des Inscriptions
Acteur secondaire Acteur principal
Valider inscription
Secrétaire Etudiant
Système bancaire
Consulter son compte
Traiter Prêt immobilier
Client Conseiller financier
Relations : cas et acteur
• Relation entre un cas d’utilisation et un acteur – Une relation nommée relation de communication permet
de relier un acteur et un cas d'utilisation par une relation qui signifie "participe à »
12
ISI1 – L3 Miage 4
2012-2013
Relations : cas et acteur
13
Un cas d’utilisation est un Un cas d’utilisation est un ensemble d’actions.
Pas une seule action !!!
Pas de notion temporelle Pas de notion temporelle Pas de détails
Association acteur cas Le signale le
Association acteur cas Le sens de la flèche signale le
sens de la transmission de l’information
DesLivres.fr
Relations : acteur et acteur
• Une seule relation est possible entre acteurs : la généralisation/spécialisation – Si A est une généralisation de B, tous les cas
d’utilisation accessibles à A le sont aussi à B, mais l’inverse n’est pas vrai
On peut généraliser plusieurs acteurs ayant des similitudes dans leurs cas d’utilisation par un acteur abstrait, qui modélise les aspects communs aux acteurs concrets
14
Relations : acteur et acteur
15
Seul un client peut gérer un compte client
Un visiteur peut créer un compte client, mais aussi
chercher des ouvrages DesLivres.fr
Relations : cas et cas
• Relations entre les cas d’utilisation
– Relation d’inclusion
– Relation d’extension
– Relation de spécialisation / généralisation
16
ISI1 – L3 Miage 5
2012-2013
Relations : inclusion
• Une relation d'inclusion représentée par le stéréotype « include » permet d’enrichir un cas d’utilisation (cas de base) par un autre cas d’utilisation (cas inclus).
• Le cas inclus est ajouté obligatoirement au cas de base
S’authentifier
Commander un chéquier
client
<<include>>
17
Cas inclus
Cas de base
BanqueEcureuil.fr
Consulter solde
Relations : inclusion
• L’inclusion permet généralement d'identifier une partie commune aux différents cas d'utilisation et de la factoriser dans un nouveau cas inclus dans ces derniers.
S’authentifier
Commander un chéquier
client <<include>>
BanqueEcureuil.fr
<<include>>
18
Relations : extension
• Une relation d'extension (représentée par le stéréotype « extend ») permet d’enrichir un cas d’utilisation par un autre, cependant, cet enrichissement est optionnel.
• L’extension se fait dans le cas d’utilisation de base, en un point précis appelé point d’extension
19
Créer un compte
Réaliser un virement vers un
autre compte
client
<<extend>>
Cas étendu
Cas de base
BanqueEcureuil.fr
Relations : généralisation/spécialisation
• Une relation de généralisation/spécialisation permet d'exprimer que les cas d'utilisation descendants héritent de la description de leur parent commun. Ils peuvent cependant comprendre chacune des interactions spécifiques supplémentaires, ou modifier les interactions dont ils ont hérités.
• Cette relation permet principalement de formaliser les variations importantes sur le même cas d’utilisation.
20
ISI1 – L3 Miage 6
2012-2013
Relations : généralisation/spécialisation
21
Rechercher des ouvrages
Client
DesLivres.fr
Rechercher par recherche
rapide
Rechercher par recherche
avancée
Relations: Exemple
22
BanqueEcureuil.fr
Cas d’utilisation interne Pas directement relié à
un acteur
Condition On peut ajouter des
conditions sur l’extension
Relations: Exemple
23
Association
Dépendances « include » « extend »
Généralisation Spécialisation
Indiquer l’existence des cas particuliers
dépendances. Cela risque de réduire la
Indiquer l’existence des cas particuliers lors du recueil de besoins apporte une information supplémentaire
pertinente.
Attention à ne pas abuser des
dépendances. Cela risque de réduire la
lisibilité.
Condition : { si montant > 20 }
Démarche
• Les étapes pour obtenir un modèle de cas d’utilisation
– Identifier les acteurs – Identifier les cas d’utilisation
• Se placer du point de vue de chaque acteur et déterminer comment il se sert du système
• Limiter le nombre de cas d’utilisation – Se placer au bon niveau d’abstraction
– Ajouter les relations entres les cas d’utilisation • Éviter les redondances
– Structurer l’ensemble des cas d’utilisations en paquetages – Finaliser un ou plusieurs diagrammes de cas d’utilisation
par paquetage
24
ISI1 – L3 Miage 7
2012-2013
Paquetages
• Les acteurs et leurs cas d’utilisation peuvent être regroupés par paquetage
25
UC Internautes
+ Internaute
+ Client
+ Visiteur
- + Chercher des ouvrages
- + Créer compte client
- + Effectuer une commande
- + Consulter ses commandes
- + Gérer son compte client
UC Employées
+ Libraire
+ Webmestre
- + Maintenir catalogue
- + Maintenir site
UC Support
- + S’authentifier
- + Consulter aide en ligne
Paquetages
26
Résumé
27 Source : uml.free.fr
Description des cas d’utilisation
• Une fois les cas d'utilisation identifiés, il faut les décrire. Cette description repose sur la notion de scénario. – Un scénario représente une succession particulière
d‘actions, s'exécutant du début à la fin du cas d'utilisation. – Un cas d'utilisation contient en général un scénario
nominal et plusieurs scénarios alternatifs (qui se terminent de façon normale) ou d'erreur (qui se terminent en échec).
28
Expression textuelle
du problème Cas d'utilisation Scénario
Scénario Scénario Cas d'utilisation
Cas d'utilisation Scénario
ISI1 – L3 Miage 8
2012-2013
Plan Type
Titre
Objectif
Acteurs
Pré-conditions
Post-conditions
Descriptif du scénario nominal
Descriptif des scénarios alternatifs
Descriptif des scénarios d’erreur
Acteur
Cas d’utilisation
Scénario: Exemple
29
LoueUneVoiture.fr
Titre : Réserver un véhicule
Objectif : ce cas d’utilisation permet à un client internaute de saisir une demande de réservation.
Acteurs : Client (principal), Système Bancaire (secondaire)
Pré-conditions : Des véhicules sont disponibles
Post-conditions : Une demande de réservation a été enregistrée par le système avec toutes les informations nécessaires.
Réserver un véhicule
Client
Scénario: Exemple
30
Système bancaire
Descriptif du scénario nominal
1. Le client saisit son code et son login d’identification
2. Le système vérifie le code et le login d’identification
3. Le système demande au client de saisir les informations sur la réservation
4. Le client saisit les informations sur la réservation
5. Le système interroge l’acteur système bancaire pour vérifier l’acompte
6. Le système bancaire donne une réponse favorable
7. Le système envoie au client, un message de confirmation de la demande
Scénario: Exemple
31
LoueUneVoiture.fr
Réserver un véhicule
Client Système bancaire
Descriptif des scénarios alternatifs
SA1 : code d’identification erroné pour la première ou la deuxième fois
SA1 démarre au point 2 du scénario nominal
3. Le système indique au client que le code est erroné, pour la première ou la deuxième fois.
Le scénario nominal reprend au point 1.
Scénario: Exemple
32
LoueUneVoiture.fr
Réserver un véhicule
Client Système bancaire
Descriptif des scénarios d’erreur
SE1 : code d’identification erroné pour la troisième fois
SE1 démarre au point 2 du scénario nominal
3. Le système indique au client que le code est erroné pour la troisième fois.
Le cas d’utilisation se termine en échec (l’objectif n’est pas atteint).
