Cours5 Uml Dcu Exos PDF

Modélisation Conception
Objet des S.I.
Cours 5 – UML,
Diagramme des Cas
d’Utilisation (DCU)
Véronique DESLANDRES
UML, Master Miage Parcours SIGS
Plan de ce cours
• Diagrammes de cas d'utilisation
• Quelques exercices – s45
• Regroupement en packages
2
Diagrammes de cas d'utilisation, DCU
Use Case
3
Cas d’utilisation : présentation
• Les « use case » d’Ivar JACOBSON

• Décrire les différentes utilisations du système
par des acteurs particuliers
S I ON
VI E UR
I SA T
UT I L
4
UML V. Deslandres – IUT de LYON
Un Cas d’utilisation, c’est :
• Une fonctionnalité complète du système
• Exemple :
– Dans le système Guichet automatique d’une banque (GAB), « retirer
de l’argent » est un CU.
– C’est une fonctionnalité complète du système qui va de l’insertion de
la carte par le client, jusqu’à la récupération de la carte par le client.
5
Use Case / scénarios
• Un use case = un ensemble de scénarios, détaillant tous les cas
possibles
• Exemple pour le retrait, un scn d’exception :
– Dans le GAB, un client tente de retirer de l’argent mais son compte
est insuffisamment alimenté : refus
• Un scénario = une instance d’un CU, comme un Objet est une
instance de classe
6
Cas d’utilisation : les acteurs
l Un acteur = une abstraction d’un acteur
l Acteur concret = le client Mme Martin
l On parle de rôle : un même acteur concret

peut jouer différents rôles dans l’utilisation
du système
l Ex.: dans le GAB, l’agent de maintenance du

GAB peut aussi retirer de l’argent
7
Exercice :
quels sont les acteurs ?
Modélisation d’un garage
Monsieur Fiat est là un jour pour

vendre ses voitures, un autre jour
pour faire la vidange d’un client, une
autre fois pour faire les comptes du acteurs
garage.
Quels sont les acteurs et les cas

d’utilisation ?
Types d’acteurs
• Un acteur peut être une personne ou un système logiciel ou

un serveur externe
– Ex. GAB sollicite le serveur du consortium pour savoir quelle banque
est associée à la carte de retrait
• Acteur actif / passif Flèche vers l’acteur
passif
9
Acteurs : externes
• Le client est client de la banque
• Mais il est externe au système du GAB
10
Exercice : acteur interne ou externe ?
• Pour un système de pilotage d’un ascenseur : appeler

l’ascenseur, déplacer la cabine, définir le prochain arrêt, ouvrir
les portes, etc.
– Usager
– Portes de l’ascenseur
– Moteur des portes
– Agent de maintenance
– Moteur de cabine
Souvent acteur « interne » = composant du système

11
Acteur / événement
• Souvent un acteur (externe) génère un « événement »

qui se traduit par une action du système (réponse)
– ex.: Appel de l’ascenseur = événement, un bouton d’étage
transmet un signal au système de pilotage de l’ascenseur
– Le système enclenche le moteur de dépla-cement de la cabine
(action)
C’est la dynamique du système, qui sera modélisée par

un diagramme d’activité ou de séquence
12
Use Case : Gestion comptabilité
Facturation
Progiciel de
Comptabilité
Comptable Observez bien

cet acteur : c’est
un système
Suivi des Règlements externe
13
Cas d’utilisation : décrire le QUOI
l Diagramme de description du QUOI FAIRE
l Quelles sont les fonctionnalités : on décrit les cas précis d'utilisation
de l'application
Ex.: Utilisations d'un téléviseur

l Pour regarder la TV
l Comme 2ème écran de son PC
l Pour visionner avec son caméscope
l Pour aller sur internet
l Mais pas du COMMENT

l Ni manipulation d’IHM, ni gestion des erreurs matérielles
14
Relations entre cas d’utilisation : « include, extend »
X X
Cas de base Cas de base
<<include>> <<extend>>
Y
Cas inclus Y Extension
Le cas de base X passe L’extension Y est un

systématiquement par le cas Y extension possible du cas de
base X
Quand on est en X, on peut

être amené à faire Y (sous
certaines conditions)
15
Exemples de Relations « include, extend »
Saisie des Saisie des

commandes Commandes
<<include>> <<extend>>
Saisie
articles &
Gestion
quantités Client
La saisie d’une commande passe Le cas « Saisie des

systématiquement par la saisie Commandes » peut mener
des articles et quantités. à la création d’un Client
Le cas « Saisie de la commande
(article, qté) » ne se fera jamais tout S’il n’est pas connu de la
seul, mais depuis la saisie, et d’autres société
cas éventuellement. 16
Quand fait-on un include ?
• On pourrait en effet le considérer comme faisant partie du CU de
base…
• On met des CU inclus dans 3 cas :

1. Quand on pense que cela apporte un plus à la compréhension du
diagramme
2. Quand le CU inclus est partagé par plusieurs CU
– factorisation
3. Quand le CU inclus est aussi un CU pour un acteur
– Il peut souhaiter directement utiliser le système via ce cas
17
SIVEX : DCU Gestion des Commandes
Gestion
des Clients
<<extend>> Point d'extension :
nouveau client
Gestion de
Commande
Réceptionniste
Client
Consultation
(acteur secondaire)
d'en-cours
18
Exemples
Quelles relations utiliser ?
Modification
Modification include
? Vérification
Vérification
document
document droit
droit d’accès
d’accès
?
Retirer
Retirer
dede extend Editer
Editerunun
l’argent
l’argent ticket
ticket
Saisie
Saisie include
? Vérification
Vérification
commande
commande stock
stock
19
Relations : Acteurs / Cas
• Initialisation d’un CU, généralisation d’acteurs
• Généralisation : seule relation possible entre les acteurs dans un DCU !

20
Héritage entre Acteurs
Authentification
Utilisateur
Client Réceptionniste Comptable Répartiteur Chauffeur Opérateur de Responsable Administrateur

Quai Logistique Système
21
Use Case : généralisation des cas
SIVEX - Gestion des missions
secondaire Suivi de mission
secondaire
Répartiteur Chauffeur
Planification des missions
Planification des missions Planification des missions de

d'enlèvement traction
Planification des missions de
livraison
22
Exemple1 : diagnostic médical
Gestion des RDV
Règlement /
facturation
secrétaire
Analyse des
symptômes
patient
<< include >>
Élaboration d’un diagnostic

médecin
<< include >>
Proposition du traitement
23
Application du poste secrétaire
Un Cas d’utilisation =
un menu ou un bouton
de l’IHM
Application du poste médecin 24

Erreur type : diagnostic médical
NON
Gestion des RDV
Règlement /
secrétaire facturation
Analyse des
Demande symptômes
absence
patient
<< include >>
Élaboration d’un diagnostic
<< include >> On ne modélise que les

médecin
Proposition du traitement interactions avec le système
25
Exemple2 : une agence de banque
Ouvrir un compte
Effectuer
opérations sur
les comptes
Gérer les
rendez-vous
Gestion de
commande
Prospecter
responsable
Gérer les clients
clientèle
26
Exemple3: développement de logiciel
Définir les
Utilisateur besoins
Chef de projet
Piloter le processus
(maîtrise d'œuvre) Maître
dvpt Objet
d'ouvrage
Concevoir une
architecture
technique
Architecte Architecte
logiciel technique
Organiser le
développement
logiciel et les
tests
Tester
Utilisateur Développeur
27
Exemple 4 : eLearning
Chercher un cours
« include »
Récupérer les
Internaute
cours ouverts
Visualiser les pré
requis du cours
S’abonner
Télécharger un
cours
Extension : si l’abonné
« extends » n’est pas déjà connecté
Authentification Serveur de
Abonné Cours
28
Questions
sur l’ex 4
eLearning
Pourquoi ne voit-on pas le cas

« Visualiser le descriptif du cours »
(mais les pré-requis) ?
Pourquoi voit-on le cas « Chercher un

Cours » ?
Que représentent les cas inclus pour

l’application ? Pourquoi les isole-t-on ? Je réf
le ch i s

eLearning : corrigé (1)
• Le cas « Visualiser le descriptif du cours » n’a aucun effet de bord

sur le reste du logiciel
– C’est effectivement un besoin exprimé par le client, mais d’une façon
générale, on a toujours besoin de voir / consulter les objets manipulés par
un logiciel : ces visualisations existeront de toute façon
• On ne les mentionne pas, ce sont des cas d’utilisation « triviaux »
• On peut les mettre, mais ils surchargent les diagrammes
• Par contre la visualisation des pré-requis apporte une vraie plus-
value Métier
– Il est important pour celui qui souhaite suivre un cours, de connaître les
pré requis, donc on le mentionne
30
• Le cas « Chercher un Cours » requerra sans doute un filtre
– Recherche par critères : nom, matière, mot-clefs
• Il correspond à un traitement logiciel qu’il faudra développer
• Il répond à un besoin Métier
• Les cas inclus représentent une tâche effectuée par le
système, sans intervention directe par l’acteur
– Ce sont des Cas « informatiques » purs, utiles pour envisager la
façon dont va être développée l’application
– Souvent on isole ces cas (connexion, authentification) pour servir à
d’autres cas « Métier »
31
Questions
his
r éf
le c sur l’ex4
Je
Quel est le choix de

conception du Client pour ce
site ? (qui pourrait être
différent)
Les cas sont incomplets :

lesquels ajouter ?
• Choix de conception ici : ne demander
l’authentification qu’à partir du moment où
l’internaute télécharge un cours
– Ainsi le système peut contrôler qui télécharge,
éventuellement mettre en place un système de
paiement, etc.
• Cas supplémentaires possibles :
– contrôler le nb de cours téléchargés,
– déposer un commentaire,
– contacter un responsable,
– etc.
33
Cas d’utilisation : je retiens
• Acteurs = rôles
• Acteurs nécessairement externes à l’application
• Acteurs principaux : à gauche
• Un cas = une verbe ou un nom verbal
• « Traiter » ou « traitement »
Gérer les clients
• Un cas = un ensemble de séquences

• Scénario : nominal, d’erreurs, etc.
• Décrire les cas de haut en bas : des plus importants au
moins importants pour l’utilisateur
• Description textuelle associée aux cas
• (selon un formalisme bien défini)
34
Spécification des cas d’utilisation
Chaque cas d’utilisation est précisé de manière textuelle et
structurée en précisant :
- dans quelles conditions le cas peut démarrer (pré-conditions),

- dans quelles conditions le cas peut se terminer (post-conditions),
- les étapes du déroulement normal (‘nominal’),
- les variantes possibles et les cas d’erreurs d’erreurs,
- les informations échangées entre acteur et système,
- les éventuelles contraintes non fonctionnelles.
Le modèle de description le plus répandu est www.usecases.org
Exemple : Cas RetirerArgentDistributeur
RetirerArgent
Client Distributeur
Client
35
Description du Cas : RetirerArgentDistributeur
Précondition le distributeur contient des billets ; il est en attente d’une opération : il
n’est ni en panne, ni en maintenance.
Postcondition si de l’argent a pu être retiré, la somme d’argent sur le compte est égale
à la somme d’argent qu’il y avait avant moins le retrait. Sinon, la somme d’argent
sur le compte est inchangée.
Déroulement normal
Le cas d’utilisation démarre quand (1) le client introduit sa carte bancaire, (2) le
système lit la carte et vérifie si la carte est valide, (3) le système demande au client
de taper son code, (4) le client tape son code confidentiel, (5) le système vérifie que
le code correspond à la carte, (6) le client choisit une opération de retrait, (7) le
système demande le montant à retirer, etc.
Variantes
(A) Carte invalide : au cours de l’étape (2), si la carte est jugée invalide, le système
affiche un message d ’erreur, rejette la carte et le cas d’utilisation se termine.
(B) …
Contraintes non fonctionnelles
(A) Performance : le système doit réagir dans un délai inférieur à 4 secondes,
quelque soit l’action de l’utilisateur.
(B) Sécurité …
36
Exercice : validité des UC
• Soit un système d’eCommerce

• Les internautes consultent le catalogue; les clients, une fois
enregistrés, commandent des articles.
• Un responsable Produit fait de la veille et alimente le catalogue
tandis que le responsable Commercial met en place des campagnes
de promotion.
• Les clients peuvent poser des questions techniques sur les
produits ou sur le site.
37
Exercice : validité des UC
• Système d’eCommerce
• Que penser de ces cas d’utilisation ?
Se
Supprimer
connecter
un article
Traiter les
retours
Imprimer Négocier
un contrat
38
Validité des Use Case : éléments de réponse
• REGLE DE BASE : un cas =

plusieurs séquences
• Les activités élémentaires seront
décrites dans les diagrammes
d’activités associé au CU
• La question plutôt à se
poser est :
• À quel niveau faut-il exprimer un
cas d’utilisation de façon à ce qu’il
soit utile pour l’analyse des
besoins ?
• Une solution : penser en

termes de Processus métier
39
Illustration sur l’exercice
Supprime
r un
• « Supprimer un article » : activité
article élémentaire !
• Un cas "Gestion Articles" serait plus
approprié
Gérer les
articles è Généraliser le CU
• « Imprimer un document » : inutile

er
ici
prim
Im • activité technique, pas un besoin Métier
è Ce n’est pas un CU
40
Illustration sur l’exercice (2)
Se
• Ce n’est pas un processus métier
connecter • C’est un cas informatique
è C’est un CU inclus
• Il faudrait plutôt chercher pour quels

processus métier on va devoir se Commander
connecter
• Pour commander ? Obtenir les stat. du Obtenir les
mois ? Modifier le catalogue Produit ? statistiques
du mois
è Ajouter des CU Gérer les

articles
41
Illustration sur l’exercice (3)
Traiter les • C’est un processus métier

retours
• Il donne lieu à différents traitements
(famille de traitements)
• Il comporte bien une partie automatisée
par le logiciel
è c’est un CU
• C’est un processus métier

• Il donne lieu à différents traitements
(famille de traitements)
Négocier
• Mais il ne sera pas automatisé par le un contrat
logiciel, c’est un agent humain qui va
effectuer la tâche
è Ce n’est pas un CU 42
Risques associés au diagramme des Cas
d’Utilisation
• Les Cas d’utilisation ne sont pas une fin en soi

• Leur objectif est de :
• dialoguer avec le client, le rassurer sur ce qu’on a compris
• analyser les besoins métier prioritaires
• démarrer l’analyse en identifiant les classes candidates
• Envisager les tests d’acceptation
• Chaque cas d’utilisation peut être décrit par un diagramme
d’activités
43
Exercice du Site
eCommerce
Quels sont les acteurs ?
44
Un indice : ils sont plus que 5 et moins
que 8…
45
Exercice du Site
eCommerce
Elaborer le DCU
(il y a au moins 6 cas d’utilisation)
46
Site d’eCommerce, les acteurs
l Internaute : consulte Catalogue, s’inscrit

l Client : consulte, achète des produits, demande un renseignement,
souhaite obtenir un RV personnalisé, etc.
l Administrateur : ouvre comptes, etc.
l Responsable Produits : MàJ le catalogue, veille

l Responsable Commercial : gère promotions
l Technicien : répond aux questions techniques sur les produits
47
48
Packages
• Pour qu’un diagramme reste lisible, on regroupe les CU en
packages
• Souvent, regroupement par logique Métier : c’est le début de
l’architecture logicielle
• Ou par acteur, ou par lot de livraison
• Quels packages verriez-vous pour le site d’eCommerce ?
49
Un package Client
50
Un package BackOffice
51
Un package Admin
52
Dépendances entre packages
Diagramme de packages : il structure

l’application
Au sein de chq package, on modélise le DCU, le
DCL,… du package
53
Les erreurs classiques
• Mettre un acteur Système
Vérifier
Disponibilité produit
Système
Commander
Utilisateur
include
Il suffit de créer un cas

Vérifier
technique, et le relier par
Disponibilité produit
include
Montrer les interactions entre acteurs

Demande devis On modélise l’application à
implémenter, donc les interactions
qu’ont les acteurs AVEC l’appli
Client Guichetier
54
• Mettre des « activités atomiques » comme cas d’utilisation
Effectuer le Choisir paiement

règlement par CB
Client Client
Régler par Régler par

chèque CB
Trop détailler
Gérer les clients
Créer un client Commercial
Commercial Toujours penser CRUD

Create Rename Update Delete
UML V. Deslandres – IUT de LYON 55

• Mettre des acteurs qui n’interagissent pas directement avec
l’application. Par ex. pour un passage en caisse (manuelle) :
Acheter des Enregistrer

articles un article
Client Caissier Saisir le PU, la quantité,

afficher le libellé et le
montant
Mettre des séquences temporelles

Enregistrer
Enregistrer un article
un article
include
Caissier extends Caissier Signaler fin
vente
Demander si
autre article
include/extends = inclusions de
fonctionnalités, pas dépendance 56
temporelle
Modéliser le « fonctionnement réel » et pas les
interactions avec le logiciel
Ex. à la FNAC: Retourne

un article
Client
Enregistre extends
le retour
include
Opérateur SAV Obtenir un avoir
extends
Vérifier validité
Créer un avoir du retour
Autre exemple : Peut inclure des aléas
Livrer la Enregistrer
commande la livraison
Livreur Livreur
57
Les erreurs classiques (3)
• « Omettre » la gestion des entités métiers

• Ne penser qu’aux processus métiers
• Ex.: pour une application de gestion des Transports
Publics
58
Ex. : Gestion des entités Métier
pour une application de gestion des
Transports Publics
Affecter chauffeurs
sur les lignes CAS de « GESTION METIER »
Resp.
d’exploitation
Gérer les
Gérer les retards chauffeurs
sur une ligne
Gérer les
bus
(héritage)
Gérer les remplacements

Gérer les
de chauffeurs
lignes

de bus
59
Les erreurs classiques (fin)
Mentionner des acteurs internes au niveau du DCU
Annoncer un
retard
Bus
Gérer les
retards
Resp. d’exploitation
60
DCU : bonnes pratiques
• Recommandations d’I. Jacobson :
– N’abusez pas des relations entre cas d’utilisation (surtout extension et
généralisation)
– Pas plus de 20 cas de base pour tout le projet (hors cas inclus, extensions,
spécialisation)
– Un cas d’utilisation ne doit pas se réduire à une simple action
– Bien choisir les termes, exploiter les notes explicatives pour enlever toute
ambiguïté de lecture
• Un DCU = une table des matières graphique des besoins logiciels

– Il faut utiliser d’autres diagrammes pour modéliser plus en profondeur
61
À vous de jouer !
EXERCICES DCU
62
Agence de voyage / relations entre
cas d’utilisation
63
Agence de voyage / relations
entre cas d’utilisation
• Soit un système qui modélise une agence de voyage. Cette agence organise des
voyages avec un hébergement en hôtel. L’agence s’arrange pour que le client
dispose d’un taxi s’il arrive en train sur son séjour pour se rendre à l’hôtel.
• Le système modélisé est celui utilisé par l’agent de voyage.
• Quelles seraient les relations à utiliser entre les cas d’utilisation « Organiser un
voyage », « Réserver une chambre », « Réserver un billet de train » et « Réserver
un taxi » ?
• Certains clients demandent à l’agent d’établir une facture détaillée de la
prestation. Ajouter un cas « Établir une facture détaillée » et la mettre en relation
avec les autres cas.
• On apprend finalement que le voyage se fait soit par train, soit par avion.
Comment modéliser cela ?

Pizzeria
Lire et critiquer le Digramme des Cas

d’Utilisation proposé pour une application
permettant la gestion d’une pizzeria
66
Pizzeria
• D’après vous :
– Quelle a été votre 1ère impression en découvrant ce diagramme ?
– Combien il y a-t-il d’employés dans cette pizzeria ?
– Cette modélisation représente-t-elle un fonctionnement ou une
application logicielle ?
– Le lien « uses » signifie qu’un cas « utilise » un autre cas (montre une
dépendance fonctionnelle)
• Pensez-vous qu’ils sont utiles ici ?
67
Société d’intérimaires
68
Agence d’intérimaires
• Dans une agence d’intérimaires, le gestionnaire a comme objectif de placer
des intérimaires sur des missions qui lui sont proposées par des entreprises.
• C’est l’agence qui paye les intérimaires, en contre partie elle reçoit un
paiement pour sa prestation (sur laquelle elle prend une marge). L’agence
n’attend pas que les propositions lui arrivent, elle fait aussi de la
prospection.
• Le gérant suit régulièrement l’activité de son agence par divers reportings.
• Lister tout ce que devra faire le gestionnaire de la société d’intérimaires.

• On décide d’informatiser le SI de cette société : quels sont les acteurs qui
l’utiliseront ?
• Construire le diagramme des cas d’utilisation.

Librairie en ligne
70
Librairie en ligne
• Vous êtes chargés de mettre en place une librairie en ligne (style

Eyrolles, Amazon et autres, etc.).
• Cette application devra permettre aux internautes de :
– Chercher des ouvrages par thème, auteur, mot-clef, etc. ;
– Constituer un panier ;
– Commander et payer directement sur le Web : pour passer
commande l’internaute doit s’inscrire comme client.
– L’administrateur du site peut modifier tous les éléments du site :
articles, clients, commandes.
– Il peut aussi éditer des statistiques d’activités (nb de ventes par mois,
semaines, jours, etc. : reporting).
• Elaborer le diagramme des cas d’utilisation du SI de cette

librairie 71
Nota
• Quand on interroge un
client pour construire le
DCU, ne jamais lui
demander
– « Que voulez-vous que le
système fasse pour vous ? »
• Mais plutôt :
– « Décrivez-moi un service
que vous aimeriez effectuer
avec l’aide du système »
72
PACKAGES
Comment ranger / organiser les

cas d'utilisation
Structuration en packages
Package en UML = concept commun de regroupement
Regroupement :
l d’éléments d’un modèle
l de diagrammes de ces éléments
l d’autres packages
l Contraintes :
l tout élément n’appartient qu’à un seul paquetage
l Ensemble cohérent au niveau sémantique (expertise

métier)
l Représentation :
icône de dossier
Techniques de regroupement
l Par domaine d’expertise métier
l regroupement le plus intuitif et efficace
l permet de faciliter la spécialisation des analystes
l organiser facilement la répartition des experts
l Par acteur
l facile si chaque cas est relié à UN seul acteur
l Par lot de livraison client
l dans le cas d’un développement incrémental, c ’est
parfois un critère utilisé

Relations entre packages
include
import
use
76
Ex. SIVEX, lien entre
classes
<<category>>
<<category>>
Ressources
(from Logical View )
Missions
(from Logical View ) <<category>>
Commandes
Chauffeur (from Logical View )
(from Ressources) est affecté à
1 0..1
trai te 1..n Commande
Mission
(from Commandes)
0 ..1
est affecté à 1
0 ..1
1
Véhicule
1
(from Ressources)
1..n
est planifiée pour
Etape 0..1
77
UML © V. Deslandres – IUT de LYON
è Dépendance entre packages
<<category>>
Missions
+ Miss ion
+ Etape
<<import>> <<import>>
<<category>>
Ressources
<<c ategory>>
+ Chauffeur Commandes
+ Véhicule
+ Commande
78
Dépendances (1)
• Une dépendance existe entre 2 éléments si :
– Des changements apportés à la définition de l’un peuvent entraîner des
modifications dans l’autre
– Au niveau des classes, des dépendances peuvent exister pour plusieurs raisons :
• Une classe est en association avec une autre
• Une classe en a une autre dans ses attributs
• Une classe en utilise une autre comme paramètres de l’une de ses
opérations
• Surtout utilisées entre des classes appartenant à différents packages

– Au sein d’un même package, ce sont les associations qui traduisent les dépendances
79
Dépendances (2)
• Exemple : soit une application multi-couches (présentation, métier,
données) :
• La relation traduit par une dépendance de la Présentation vers la

logique Métier
– (et non l’inverse, on peut avoir n façons différentes d’afficher un compte)
80
Graphes de Dépendances
dans SIVEX
<<category>>
Transmission
Comptable
<<category>>
Comptabilité
<<category>> <<category>>
Missions Commandes
<<category>>
Clients
<<category>>
Colis
<<category>>
Ressources
<<category>>
Plan de
Transport
<<category>> <<category>>
Réseau
Exploitation
Informatique
81

Langue

Cours5 Uml Dcu Exos PDF

Transféré par

Informations du document

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Cours5 Uml Dcu Exos PDF

Transféré par

Droits d'auteur :

Formats disponibles

Modélisation Conception

Objet des S.I.

• Diagrammes de cas d'utilisation

• Quelques exercices – s45

• Les « use case » d’Ivar JACOBSON

l Un acteur = une abstraction d’un acteur

l Acteur concret = le client Mme Martin

l On parle de rôle : un même acteur concret

l Ex.: dans le GAB, l’agent de maintenance du

Modélisation d’un garage

Monsieur Fiat est là un jour pour

Quels sont les acteurs et les cas

• Un acteur peut être une personne ou un système logiciel ou

• Mais il est externe au système du GAB

• Pour un système de pilotage d’un ascenseur : appeler

Souvent acteur « interne » = composant du système

• Souvent un acteur (externe) génère un « événement »

C’est la dynamique du système, qui sera modélisée par

Comptable Observez bien

Ex.: Utilisations d'un téléviseur

l Mais pas du COMMENT

Le cas de base X passe L’extension Y est un

Quand on est en X, on peut

Saisie des Saisie des

La saisie d’une commande passe Le cas « Saisie des

• On met des CU inclus dans 3 cas :

• Généralisation : seule relation possible entre les acteurs dans un DCU !

Client Réceptionniste Comptable Répartiteur Chauffeur Opérateur de Responsable Administrateur

secondaire Suivi de mission

Planification des missions

Planification des missions Planification des missions de

Gestion des RDV

Élaboration d’un diagnostic

Application du poste médecin 24

Élaboration d’un diagnostic

<< include >> On ne modélise que les

Pourquoi ne voit-on pas le cas

Pourquoi voit-on le cas « Chercher un

Que représentent les cas inclus pour

UML V. Deslandres – IUT de LYON

• Le cas « Visualiser le descriptif du cours » n’a aucun effet de bord

Quel est le choix de

Les cas sont incomplets :

• Un cas = un ensemble de séquences

- dans quelles conditions le cas peut démarrer (pré-conditions),

Le modèle de description le plus répandu est www.usecases.org

Exemple : Cas RetirerArgentDistributeur

• Soit un système d’eCommerce

• REGLE DE BASE : un cas =

• Une solution : penser en

• « Imprimer un document » : inutile

• Il faudrait plutôt chercher pour quels

è Ajouter des CU Gérer les

Traiter les • C’est un processus métier

• C’est un processus métier

• Les Cas d’utilisation ne sont pas une fin en soi

l Internaute : consulte Catalogue, s’inscrit

l Administrateur : ouvre comptes, etc.

l Responsable Produits : MàJ le catalogue, veille

l Technicien : répond aux questions techniques sur les produits

• Quels packages verriez-vous pour le site d’eCommerce ?

Diagramme de packages : il structure

Montrer les interactions entre acteurs

Mettre des séquences temporelles

Autre exemple : Peut inclure des aléas