SlideShare une entreprise Scribd logo
1  sur  28
Télécharger pour lire hors ligne
7/10/13
1
IUT de LYON
Module Analyse et Conception avec
UML (Unified Modelling Language)
Les Cas
d’Utilisation
(Use Case)
2
Cas d’utilisation : présentation
  les « use case » d’Ivar JACOBSON
  Décrire une utilisation du système (ensemble
de séquences d’actions) par un acteur
particulier
  Acteurs externes à l’application
  Un acteur = un rôle
  Modélise l’un des aspects (comportement /
service) du système par rapport à cet acteur
  doit renseigner sur le rôle particulier de l’acteur
(VA)
UML V. Deslandres – IUT de LYON
7/10/13
2
3
Cas d’utilisation : présentation
  Diagramme de description du QUOI FAIRE
  Quelles sont les fonctionnalités : on décrit les cas précis
d'utilisation de l'application
Ex.: Utilisations d'un téléviseur
  Pour regarder les chaînes publiques
  Pour regarder le câble
  Pour programmer/enregistrer avec son magnéto-cassette
  Pour visionner avec son caméscope
  Pour faire de l'internet
  Comme miroir ou porte aquarium !
  Mais pas du COMMENT
  ni manipulation d’IHM, ni gestion des erreurs
matérielles
UML V. Deslandres – IUT de LYON
4
Cas d’utilisation (2)
  L’ensemble des cas d’utilisation doit décrire
exhaustivement les exigences attendues du
système
  Expression des besoins fonctionnels
  Chaque « cas » = une fonction Métier du
système selon le point de vue d’un des acteurs
  C’est un ensemble d’échanges entre l’acteur et le
système : un acteur demande des traitements, le
système fournit des services
  Représentation : acteurs et patates !
  Chaque « patate » est un « cas d’utilisation » du
système
UML V. Deslandres – IUT de LYON
7/10/13
3
5
Exemple : diagnostic médical
médecin
patient
secrétaire
Règlement / facturation
Élaboration d’un diagnostic
Proposition du traitement
Analyse des symptômes
Gestion des RDV
<< include >>
<< include >>
UML V. Deslandres – IUT de LYON
6
Exemple : agence de banque
guichetier
client
responsable
clientèle
Effectuer opérations sur
Les comptes
Gérer les clients
Planifier des rendez-vous
Gestion de commande
Ouvrir un compte
Prospecter
UML V. Deslandres – IUT de LYON
7/10/13
4
7
Cas d’utilisation : construction
  On part des acteurs identifiés dans l’étude
préliminaire
  chercher les intentions (métier) avec lesquelles il
utilise le système
  déterminer dans le CdesCh les services fonctionnels
attendus
UML V. Deslandres – IUT de LYON
8
Construction des cas
  On utilise les échanges de messages identifiés
dans le contexte dynamique
  Distinguer l’acteur principal des acteurs
secondaires
  Acteur principal: pour lequel le Cas produit la plus-
value métier (souvent : le déclencheur)
  L'acteur secondaire ne fait que recevoir le résultat
obtenu à l'issue de la réalisation de l'utilisation
envisagée (en général placé à droite)
UML V. Deslandres – IUT de LYON
7/10/13
5
9
Validation
  Pour chaque cas d’utilisation candidat :
  vérifier qu’il fournit une VA notable à l’acteur
  contrôler qu’un événement externe en déclenche l’exécution
  Ne pas descendre trop bas : un UC n’est ni une
transaction, ni une fonction du système !
  Ex.: saisie des commandes, elles peuvent l’être via le web, via les
feuilles issues du service commercial, ou manuellement après
contacts téléphoniques.
  Ca conduit donc à 3 séquences d’actions différentes mais pour un
seul cas d’utilisation : la saisie des commandes.
  REGLE : un cas d’utilisation doit regrouper au moins 2
séquences (sans compter les exceptions)
  Séquence principale + alternative
UML V. Deslandres – IUT de LYON
UML V. Deslandres – IUT de LYON
10
Etude de cas SIVEX
  On part du diagramme de contexte dynamique
  Chercher l’« intention fonctionnelle » de
chaque acteur dans son intéraction avec le
système
  Quelle fonctionnalité le concerne dans
l'application ?
  S’inspirer des messages
  Regrouper les intentions en unités cohérentes
7/10/13
6
11
Ex. Planification missions
  Acteur principal = répartiteur
  Intentions
  planifier les missions d’une agence, permettant la
réalisation des commandes en cours
  Actions :
  créer une nouvelle mission :
  regrouper des commandes, affecter des ressources
disponibles, établir un parcours, évaluer les durées, le
volume nécessaire pour la camionette, etc…
  modifier ou annuler une mission existante
UML V. Deslandres – IUT de LYON
12
  Acteur principal =
Ex. Suivi de mission
chauffeur
• Intentions
• Actions
Informer en temps réel de l’état d’avancement de la
mission en cours
- Transmettre chaque arrêt et départ d’étape
- Signaler les événements de mission
acquittement client, panne, retard, absence client...
UML V. Deslandres – IUT de LYON
7/10/13
7
13
Use Case : Gestion des missions
UML V. Deslandres – IUT de LYON
14
Formalisme des cas d’utilisation
  Différents types de relations
  Relation entre un acteur et un cas :
- trait simple : l'acteur déclenche le cas
- flèche vers acteur :
l'acteur reçoit le résultat du cas (acteur secondaire)
  Relation d’héritage entre cas : un cas d'utilisation (une
fonctionnalité) dérive d'une fonctionnalité plus générale
  ex.: « Sélection d'une location de vacances » et
« Sélection d'une péniche pour un séjour »
Relation d’héritage entre cas
UML V. Deslandres – IUT de LYON
7/10/13
8
15
Héritage entre Acteurs
UML V. Deslandres – IUT de LYON
16
Relations « includes, extends »
Cas de base Cas de base
Cas inclus extension
<<include>> <<extend>>
UML V. Deslandres – IUT de LYON
7/10/13
9
17
Autres relations entre cas
  Relation d’inclusion « include » :
  La réalisation d’un cas de base passe
obligatoirement par celle d’un cas spécifique inclus
  (objectif : factorisation)
  Ex. : procédure d’authentification
  Relation d’extension « extend » :
  Cas de base incorpore une extension, à un point
d’extension prévu
  (obj.: représenter un comportement optionnel)
  Ex. : la prise de commande peut conduire à la création
d’un nouveau client
UML V. Deslandres – IUT de LYON
18
Exemples
Quelles relations utiliser ?
UML V. Deslandres – IUT de LYON
Modification
document
Vérification
droit d’accès
?
Saisie
commande
Vérification
stock
?
Développement
pages d’un site
web
Définition
charte
graphique
?
Modification
document
Vérification
droit d’accès
include
Développement
pages d’un site
web
Définition
charte
graphique
extends
Saisie
commande
Vérification
stock
include
7/10/13
10
19
Corrigés des exemples
Quelles relations utiliser ?
UML V. Deslandres – IUT de LYON
Modification
document
Vérification
droit d’accès
include
Développement
pages d’un site
web
Définition
charte
graphique
extends
Saisie
commande
Vérification
stock
include
20
Use Case SIVEX : Gestion des Commandes
Consultation
d'en-cours
Client
Réceptionniste
Gestion de
Commande secondaire
Gestion
des
Clients
(nouveau client)
<<extend>> Point d'extension :
nouveau client
UML V. Deslandres – IUT de LYON
7/10/13
11
21
Use Case : Gestion comptabilité
UML V. Deslandres – IUT de LYON
7/10/13
12
23
Package en UML = concept commun de regroupement :
Structuration des cas d’utilisation
Structuration par package
  d’éléments d’un modèle
  de diagrammes de ces éléments
  d’autres packages
  Contraintes :
  tout élément n’appartient qu’à un seul paquetage
  Ensemble cohérent au niveau sémantique
(expertise métier)
  Représentation : icône de dossier
UML V. Deslandres – IUT de LYON
24
Techniques de regroupement
  Par domaine d’expertise métier
  regroupement le plus intuitif et efficace
  permet de faciliter la spécilisation des analystes
  organiser facilement la répartition des experts
  Par acteur
  facile si chaque cas est relié à UN seul acteur
  Par lot de livraison client
  dans le cas d’un développement incrémental, c ’est
parfois un critère utilisé
UML V. Deslandres – IUT de LYON
7/10/13
13
Relations entre packages
import
include
use
UML V. Deslandres – IUT de LYON
26
Regroupement en packages : SIVEX
- Par domaine d’expertise
métier
- Ensembles d’acteurs
fortement liés
Définition du plan
de transport, et des
ressources
Acteurs: resp.
logistique
Définition des profils utilisateur
Acteur: administrateur
Gestion clients, gestion des
commandes, consultation des
en-cours
Acteurs : réceptionniste, client
UML V. Deslandres – IUT de LYON
7/10/13
14
1. Contexte d'apprentissage d'UML
2. Développement logiciel
3. Application de téléchargement de Cours
28
Exemple 1 : cas d’utilisation décrivant un
fonctionnement
  Cas d'utilisation décrivant le contexte dans lequel vous
allez apprendre à concevoir avec UML à l'IUT…
Impétrant
assister
aux cours
lire
ouvrages
rechercher
informations
Présenter le
formalisme
UML
Proposer des
exercices
Evaluer
impétrants
Enseignant
UML V. Deslandres – IUT de LYON
7/10/13
15
29
Exemple 2 : cas d’utilisation de
fonctionnement
  Cas d'utilisation de développement de logiciel
Chef de projet
(maîtrise d'œuvre)
Maître
d'ouvrage
Architecte
logiciel
Architecte
technique
Utilisateur
Développeur
Piloter le processus
développement
Objet
Concevoir une
architecture
technique
Organiser le
développement
logiciel et les tests
Définir les
besoins
Tester
UML V. Deslandres – IUT de LYON
30
Exemple 3 : cas d’utilisation d’une
application informatique
  Décrivant le téléchargement d’un Cours
Internaute
BD Users /
droits
Chercher un
cours
Sélectionner un
ou plusieurs
cours
Télécharger un
cours
Ouvrir
l’application
Authentification
Serveur
de Cours
Connexion
include
extends
UML V. Deslandres – IUT de LYON
Abonné
S’abonner
extends
7/10/13
16
Questions sur l’ex. 3
•  Pourquoi ne voit-on pas le cas « Visualiser un
cours » (description, pré requis, etc.) ?
▫  Pourquoi voit-on le cas « Rechercher un Cours » ?
•  Que représentent les cas inclus pour l’application ?
Pourquoi les isole-t-on ?
•  Quel est le choix de conception du Client pour ce
site ? (qui pourrait être différent)
•  Les cas sont incomplets : lesquels ajouter ?
- Contrôler le nb de cours téléchargés
- Déposer un commentaire
UML V. Deslandres – IUT de LYON
32
Description des Cas d’utilisation
On décrit les cas d’utilisation avec des
diagrammes d’abord, et éventuellement sous
forme textuelle.
  Structure de description des cas d’utilisation
  qui permet de mieux les exploiter par la suite :
  sommaire d’identification (titre, but, résumé, acteurs,
dates, version, responsable)
  description des enchaînements (nominaux,
exceptionnels, pré-post conditions)
  éventt : besoins d’IHM
  éventt : contraintes non-fonctionnelles (fréquence,
volumétrie, disponibilité, confidencialité, performances…)
UML V. Deslandres – IUT de LYON
7/10/13
17
33
Quel format de description ?
  Il existe différents modèles de cas d’utilisation détaillé
  Le plus répandu est celui de www.usecases.org
  (cf SIVEX, et ex. ici)
  Description :
  Titre, acteur principal, parties prenantes et intérêts, pré et
post conditions, scénario principal (happy path, succès) sans
condition ni branchement, extensions (scénarios
d’exception);
  Spécifications particulières (hors contraintes fonctionnelles :
interface, langue, temps de réponse);
  Technologies envisagées ou évolutions à MT (ex.
actuellement chèque accepté, en Juin 2003, plus de
chèque), questions à se poser.
UML V. Deslandres – IUT de LYON
34
Exercice : quelle validité des UC
  Soit un système de vente en ligne
  Lesquels de ces cas d’utilisation seraient
valides ?
  Supprimer un article
  Négocier un contrat avec un fournisseur
  Traiter les retours
  Se connecter
  Imprimer un document
UML V. Deslandres – IUT de LYON
7/10/13
18
35
Use Cases : réponse
  Les 3 cas du milieu sont utiles à différents niveaux
d’abstraction, en fonction des acteurs et des objectifs.
  La question plutôt à se poser est :
  À quel niveau faut-il exprimer un cas d’utilisation de
façon à se qu’il soit utile pour l’analyse des besoins ?
  Il faut pour cela identifier les Processus métier
élémentaires
UML V. Deslandres – IUT de LYON
36
Quels cas d’utilisation créer
  Identifier les Processus Métier pour lesquels il
y a valeur ajoutée observable et mesurable
  Qui laissent le système dans un état stable et
cohérent
  Définir les acteurs externes et internes et se
concentrer sur leurs intentions
  Notamment ne pas raisonner en interface
utilisateur
UML V. Deslandres – IUT de LYON
7/10/13
19
37
Exemple sur l’exercice
  « Se connecter » : processus Métier ? plus value ?
  Non, but secondaire
  « se connecter pour commander » : OK ( traiter vente)
  « se connecter pour enregistrer les ventes du mois » : OK
( enrichir statistiques)
  « se connecter pour mettre à jour le catalogue » : OK
( gérer articles)
  « Supprimer un article » : secondaire aussi !
  Gestion Article plus appropriée
  « Imprimer un document » : inutile ici
  activité technique, pas un besoin Métier
  (L’étape d’authentification n’est jamais un processus métier,
sauf pour une modélisation purement informatique !)
UML V. Deslandres – IUT de LYON
38
Risques associés aux Cas
  Ne pas réinventer la décomposition
fonctionnelle !
  On fait de l’analyse ORIENTEE OBJET !!
  Ne pas aller trop loin dans le détail, on en est
à la capture des besoins fonctionnels.
  Limiter à 10 le nombre de (« grands ») CU, rester
synthétique
  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,
  démarrer l’analyse en identifiant les classes candidates.
UML V. Deslandres – IUT de LYON
7/10/13
20
39
Autres risques
  Ne pas mélanger l’IHM et le fonctionnel
  on décrit le métier des acteurs, indépendamment
des choix d’interface qui pourront évoluer…
– ex.: préférer « lors d’une 1ère commande, le
réceptionniste enregistre les caractéristiques du nouveau
client dans le système » à :
– « le réceptionniste saisit le nom du client en 8 car.
max, en majuscules, appuie sur ENTER, puis saisit le
prénom en minuscules » ou à
– « le réceptionniste enregistre par un syst. de
reconnaissance vocale les nom, prénom, adresse et
code postal du client »
UML V. Deslandres – IUT de LYON
DEMARCHE UML
•  On part d’une étude de contexte
▫  Diagramme de contexte statique
▫  Diagramme de contexte dynamique
•  On construit les diagrammes de Cas d’utilisation
•  On les regroupe en packages si besoin
•  On en déduit les classes, on fait de premiers
diagrammes de classes
▫  partiels ou global
UML V. Deslandres – IUT de LYON
7/10/13
21
41
Démarche détaillée
Cas d’Utilisation / Diagramme de Classes
(1) Présentation du contexte et du sujet
(2) Identifier les acteurs externes du système à
l’aide d’un diagramme de contexte statique
  Acteurs = rôles joués par des personnes ou
systèmes externes
  Les acteurs internes (ex.: comptables, serveur
de BD… ) apparaîtront plus tard dans la
modélisation
  Penser à l’environnement humain et informatique
  Nommer ces acteurs
UML V. Deslandres – IUT de LYON
42
Démarche Cas d’utilisation (2)
(3) Ajouter les échanges d'informations acteurs / système
  les nommer, éventuellement les définir par une phrase
  créer ainsi le diagramme de contexte dynamique
(4) Construire le diagramme des cas d'utilisation :
identifier les services rendus aux acteurs par le
système (tâches)
  étude plus fine des interactions acteurs / système, en
dissociant les grandes fonctions
  nommer les services rendus, les définir par une phrase
  Règle : avoir plusieurs séquences d’actions par CU
(« enregistrer un client » = si c’est juste une saisie, ça n’est
pas un CU; préférer « Gestion Client »)
UML V. Deslandres – IUT de LYON
7/10/13
22
43
(5) Pour chaque cas d'utilisation :
  Détailler son fonctionnement par un diagramme d’activités
  Chaque activité peut être élémentaire
  On peut montrer les séquences et les alternatives
(6) Associés aux activités, définir les objets partagés
entre acteurs et système :
  Objets traités, mémorisés, produits, transformés
  objets du monde modélisé
  objets importants pour les acteurs
  objets persistants ou pas
  Cela va aider à identifier les classes candidates
Démarche Cas d’utilisation / diag Classes (3)
UML V. Deslandres – IUT de LYON
44
  Lister et nommer les objets (avec le
vocabulaire des acteurs), les définir par une
phrase
  Identifier ensuite les classes candidates et
construire un diagramme de classes
  par package
  Relier les objets, nommer les liens, les définir
par une phrase
Pour chaque cas d’utilisation (suite)
UML V. Deslandres – IUT de LYON
7/10/13
23
45
6.  Si nécessaire, réunir les objets des
différents cas dans un unique
diagramme de classes
(bien entendu un même objet peut intervenir
dans les différents cas d’utilisation envisagés :
Ex. dans une application de type « Editeur logiciel », un
document sera déposé, validé, fusionné, chaque action
correspond à un CU)
Démarche Cas d’utilisation / Diag Classes (4)
UML V. Deslandres – IUT de LYON
46
Exercice : site vente en ligne
  Client : consulte, achète des produits, demande un
renseignement, souhaite obtenir un RV
personnalisé, etc.
  Administrateur : ouvre comptes, etc.
  Responsable Produits : MàJ le catalogue, veille
  Technicien : répond aux questions techniques sur
les produits
UML V. Deslandres – IUT de LYON
7/10/13
24
47
Site vente en ligne
Client
Maintenance site
Gestion des
Clients
Consultation
Catalogue
Gestion des
Commandes
MàJ
Catalogue
extends
extends
Veille technologique
Renseignements
techniques
Authentification
includes
Administrateur
Resp. Produits
Technicien
UML V. Deslandres – IUT de LYON
Exemple de Cas d’Utilisation SIVEX
SIVEX: Planification des missions (fiche de
description)
7/10/13
25
49
Use Case : Gestion des missions
UML V. Deslandres – IUT de LYON
50
Ex SIVEX Description du Cas
« Planification des missions » (1/5)
  BUT : planification des missions d’enlèvement, de
transport ou de livraison, d’une agence à partir du plan
de transport, des commandes à assurer
quotidiennement et des ressources disponibles
• RESUME : création d’une nouvelle mission à partir des cdes
confirmées, modification et annulation d’une mission existante.
• ACTEURS :
• PRE-CONDITIONS :
- le répartiteur est authentifié
- les commandes à planifer sont confirmées
répartiteur (ppal), chauffeur (sec.)
UML V. Deslandres – IUT de LYON
7/10/13
26
51
DEF Enchaînements
  Enchaînement nominal = fonctionnement normal
  ex.: dans le processus d’appel téléphonique, fonctionnement
nominal =
  Enchaînement exceptionnel = fonctionnement
anormal, traitement des événements exceptionnels
  ex.: dans le processus d’appel téléphonique,
fonctionnement exceptionnel =
Décrocher combiné, entendre sonnerie attente, composer numéro,
attendre sonnerie appel, communiquer, raccrocher
Décrocher combiné, pas de sonnerie d’attente, vérifier
branchement ligne, (suite)
UML V. Deslandres – IUT de LYON
52
« Planification des missions » (2/5)
  Enchaînements identifiés :
– créer une mission en attente
– affecter des commandes à une mission
– affecter les ressources
– modifier une mission en attente (désaffecter une commande,
modification des chauffeurs ou véhicule, modification des étapes…)
– valider une mission en attente
– modifier une mission validée
– annuler une mission (en attente ou validée)
– éditer les bordereaux de mission
UML V. Deslandres – IUT de LYON
7/10/13
27
53
« Planification des missions » (3/5)
  Exceptions identifiées :
– Pour une mission donnée, dépassement de tonnage véhicule
– Chauffeur sélectionné non qualifié pour conduire le véhi-cule choisi
pour la mission
– Tonnage de réserve entammé (chaque agence doit se réser-ver un
certain tonnage pour pouvoir répondre à des comman-des prioritaires ou
de dépannage)
– Estimation de temps incomplète pour une étape donnée donc pour la
mission comportant cette étape
UML V. Deslandres – IUT de LYON
54
« Planification des missions » (4/5)
  Post-conditions
– Tout ce qui est connu à l’issue du cas
– Pour lister les commandes de l’agence, le répartiteur doit
pouvoir répertorier les commandes de l’agence par type,
poids, site desservi, affectée/non affectée, tarification urgent/
non urgent
– Les commandes non affectées doivent être de couleur
différente
  Besoins d’IHM
UML V. Deslandres – IUT de LYON
7/10/13
28
55
« Planification des missions » (5/5)
  Contraintes non fonctionnelles : temps de
réponse
– Interface répartiteur : moins de 2 secondes
– Concurrence : les validations de mission doivent être
notifiées aux lecteurs potentiels par un message
d’avertissement en TR
– Disponibilité : le système doit être accessible au répartiteurs
6 jours sur 7, aux heures d’ouverture des agences
  Autres contraintes :
UML V. Deslandres – IUT de LYON

Contenu connexe

Tendances

Projet de fin d’études
Projet de fin d’études  Projet de fin d’études
Projet de fin d’études TombariAhmed
 
Presentation stage Tunisie Telecom
Presentation stage Tunisie TelecomPresentation stage Tunisie Telecom
Presentation stage Tunisie Telecomlitayem bechir
 
Rapport application web (Spring BOOT,angular4) et mobile(ionc3) gestion des a...
Rapport application web (Spring BOOT,angular4) et mobile(ionc3) gestion des a...Rapport application web (Spring BOOT,angular4) et mobile(ionc3) gestion des a...
Rapport application web (Spring BOOT,angular4) et mobile(ionc3) gestion des a...MOHAMMED MOURADI
 
Rapport pfe Conceptionet Developpement d'une Application web et Mobile
Rapport pfe Conceptionet Developpement d'une Application web et  Mobile Rapport pfe Conceptionet Developpement d'une Application web et  Mobile
Rapport pfe Conceptionet Developpement d'une Application web et Mobile Raoua Bennasr
 
Présentation (Mémoire fin étude )
Présentation (Mémoire  fin étude )Présentation (Mémoire  fin étude )
Présentation (Mémoire fin étude )Ramzi Noumairi
 
Présentation pfe - Etude, conception et réalisation d'une application web de ...
Présentation pfe - Etude, conception et réalisation d'une application web de ...Présentation pfe - Etude, conception et réalisation d'une application web de ...
Présentation pfe - Etude, conception et réalisation d'une application web de ...Ayoub Mkharbach
 
Rapport de projet de fin d'étude licence informatique et multimédia
Rapport de projet de fin d'étude licence informatique et multimédiaRapport de projet de fin d'étude licence informatique et multimédia
Rapport de projet de fin d'étude licence informatique et multimédiaNazih Heni
 
Conception et réalisation d'une application de gestion intégrée au sein de la...
Conception et réalisation d'une application de gestion intégrée au sein de la...Conception et réalisation d'une application de gestion intégrée au sein de la...
Conception et réalisation d'une application de gestion intégrée au sein de la...Addi Ait-Mlouk
 
2015 07 14_presentation-pfe-gestion-parc-informatique
2015 07 14_presentation-pfe-gestion-parc-informatique2015 07 14_presentation-pfe-gestion-parc-informatique
2015 07 14_presentation-pfe-gestion-parc-informatiqueUsmiste Rosso
 
Rapport final pfe_systeme_de_gestion _de_cabinet_de_formation_mobile_web
Rapport final pfe_systeme_de_gestion _de_cabinet_de_formation_mobile_webRapport final pfe_systeme_de_gestion _de_cabinet_de_formation_mobile_web
Rapport final pfe_systeme_de_gestion _de_cabinet_de_formation_mobile_webSalma Gouia
 
Conception et réalisation d'une application web et mobile de e-commerce
Conception et réalisation d'une application web et mobile de e-commerceConception et réalisation d'une application web et mobile de e-commerce
Conception et réalisation d'une application web et mobile de e-commerceAHMEDBELGHITH4
 
Soutenance PFE ingénieur génie logiciel
Soutenance PFE ingénieur génie logicielSoutenance PFE ingénieur génie logiciel
Soutenance PFE ingénieur génie logicielSiwar GUEMRI
 
Plateforme e-learning PHP
Plateforme e-learning PHP Plateforme e-learning PHP
Plateforme e-learning PHP Saâd Zerhouni
 
diagramme de séquence UML
diagramme de séquence UMLdiagramme de séquence UML
diagramme de séquence UMLAmir Souissi
 
Rapport PFE : Réalisation d'une application web back-office de gestion pédago...
Rapport PFE : Réalisation d'une application web back-office de gestion pédago...Rapport PFE : Réalisation d'une application web back-office de gestion pédago...
Rapport PFE : Réalisation d'une application web back-office de gestion pédago...Anas Riahi
 
rapport de projet de fin d'étude_PFE
rapport de projet de fin d'étude_PFErapport de projet de fin d'étude_PFE
rapport de projet de fin d'étude_PFEDonia Hammami
 
rapport PFE ingénieur génie logiciel INSAT
rapport PFE ingénieur génie logiciel INSATrapport PFE ingénieur génie logiciel INSAT
rapport PFE ingénieur génie logiciel INSATSiwar GUEMRI
 
Projet Fin D'étude Application Mobile
Projet Fin D'étude Application MobileProjet Fin D'étude Application Mobile
Projet Fin D'étude Application MobileRim ENNOUR
 

Tendances (20)

Projet de fin d’études
Projet de fin d’études  Projet de fin d’études
Projet de fin d’études
 
Presentation stage Tunisie Telecom
Presentation stage Tunisie TelecomPresentation stage Tunisie Telecom
Presentation stage Tunisie Telecom
 
Rapport application web (Spring BOOT,angular4) et mobile(ionc3) gestion des a...
Rapport application web (Spring BOOT,angular4) et mobile(ionc3) gestion des a...Rapport application web (Spring BOOT,angular4) et mobile(ionc3) gestion des a...
Rapport application web (Spring BOOT,angular4) et mobile(ionc3) gestion des a...
 
Rapport pfe Conceptionet Developpement d'une Application web et Mobile
Rapport pfe Conceptionet Developpement d'une Application web et  Mobile Rapport pfe Conceptionet Developpement d'une Application web et  Mobile
Rapport pfe Conceptionet Developpement d'une Application web et Mobile
 
Présentation (Mémoire fin étude )
Présentation (Mémoire  fin étude )Présentation (Mémoire  fin étude )
Présentation (Mémoire fin étude )
 
Présentation pfe - Etude, conception et réalisation d'une application web de ...
Présentation pfe - Etude, conception et réalisation d'une application web de ...Présentation pfe - Etude, conception et réalisation d'une application web de ...
Présentation pfe - Etude, conception et réalisation d'une application web de ...
 
Rapport de projet de fin d'étude licence informatique et multimédia
Rapport de projet de fin d'étude licence informatique et multimédiaRapport de projet de fin d'étude licence informatique et multimédia
Rapport de projet de fin d'étude licence informatique et multimédia
 
Conception et réalisation d'une application de gestion intégrée au sein de la...
Conception et réalisation d'une application de gestion intégrée au sein de la...Conception et réalisation d'une application de gestion intégrée au sein de la...
Conception et réalisation d'une application de gestion intégrée au sein de la...
 
2015 07 14_presentation-pfe-gestion-parc-informatique
2015 07 14_presentation-pfe-gestion-parc-informatique2015 07 14_presentation-pfe-gestion-parc-informatique
2015 07 14_presentation-pfe-gestion-parc-informatique
 
Rapport final pfe_systeme_de_gestion _de_cabinet_de_formation_mobile_web
Rapport final pfe_systeme_de_gestion _de_cabinet_de_formation_mobile_webRapport final pfe_systeme_de_gestion _de_cabinet_de_formation_mobile_web
Rapport final pfe_systeme_de_gestion _de_cabinet_de_formation_mobile_web
 
gestion de projet
gestion de projetgestion de projet
gestion de projet
 
Conception et réalisation d'une application web et mobile de e-commerce
Conception et réalisation d'une application web et mobile de e-commerceConception et réalisation d'une application web et mobile de e-commerce
Conception et réalisation d'une application web et mobile de e-commerce
 
Soutenance PFE ingénieur génie logiciel
Soutenance PFE ingénieur génie logicielSoutenance PFE ingénieur génie logiciel
Soutenance PFE ingénieur génie logiciel
 
Plateforme e-learning PHP
Plateforme e-learning PHP Plateforme e-learning PHP
Plateforme e-learning PHP
 
diagramme de séquence UML
diagramme de séquence UMLdiagramme de séquence UML
diagramme de séquence UML
 
Diagramme d'activité en UML
Diagramme d'activité en UMLDiagramme d'activité en UML
Diagramme d'activité en UML
 
Rapport PFE : Réalisation d'une application web back-office de gestion pédago...
Rapport PFE : Réalisation d'une application web back-office de gestion pédago...Rapport PFE : Réalisation d'une application web back-office de gestion pédago...
Rapport PFE : Réalisation d'une application web back-office de gestion pédago...
 
rapport de projet de fin d'étude_PFE
rapport de projet de fin d'étude_PFErapport de projet de fin d'étude_PFE
rapport de projet de fin d'étude_PFE
 
rapport PFE ingénieur génie logiciel INSAT
rapport PFE ingénieur génie logiciel INSATrapport PFE ingénieur génie logiciel INSAT
rapport PFE ingénieur génie logiciel INSAT
 
Projet Fin D'étude Application Mobile
Projet Fin D'étude Application MobileProjet Fin D'étude Application Mobile
Projet Fin D'étude Application Mobile
 

En vedette

¿Dónde empieza y donde acaba la protección de los trabajadores de edad avanza...
¿Dónde empieza y donde acaba la protección de los trabajadores de edad avanza...¿Dónde empieza y donde acaba la protección de los trabajadores de edad avanza...
¿Dónde empieza y donde acaba la protección de los trabajadores de edad avanza...Universidad Autónoma de Barcelona
 
Plan de estudios 2011 educacion basica
Plan de estudios 2011 educacion basicaPlan de estudios 2011 educacion basica
Plan de estudios 2011 educacion basicaJuli C
 
Mettreenplaceunestrategiewebmarketing 150115102019-conversion-gate01 (1)
Mettreenplaceunestrategiewebmarketing 150115102019-conversion-gate01 (1)Mettreenplaceunestrategiewebmarketing 150115102019-conversion-gate01 (1)
Mettreenplaceunestrategiewebmarketing 150115102019-conversion-gate01 (1)Claude-Diane Bergeron
 
Présentation NSim Contour à Geomatique 2009
Présentation NSim Contour à Geomatique 2009Présentation NSim Contour à Geomatique 2009
Présentation NSim Contour à Geomatique 2009NSim Technology
 
Silvia Aguilar Pérez
Silvia Aguilar PérezSilvia Aguilar Pérez
Silvia Aguilar PérezEufemia Rosso
 
Unidad 7:Energia electrica
Unidad 7:Energia electricaUnidad 7:Energia electrica
Unidad 7:Energia electricaguesta9a8d7
 
Tperr la christanisation
Tperr la christanisationTperr la christanisation
Tperr la christanisationtheoperring
 
Cilss atelier réserves cedeao 3 5 oct 2011(2)
Cilss atelier réserves cedeao 3 5 oct 2011(2)Cilss atelier réserves cedeao 3 5 oct 2011(2)
Cilss atelier réserves cedeao 3 5 oct 2011(2)Hub Rural AOC
 
Lecture publique md77
Lecture publique   md77Lecture publique   md77
Lecture publique md77asreydy
 
Bilan chantiers éducatifs 2011
Bilan chantiers éducatifs 2011Bilan chantiers éducatifs 2011
Bilan chantiers éducatifs 2011sjpalby
 
Ultraactividad. Convenio de artes gráficas de Bizkaia. El TSJ desestima el re...
Ultraactividad. Convenio de artes gráficas de Bizkaia. El TSJ desestima el re...Ultraactividad. Convenio de artes gráficas de Bizkaia. El TSJ desestima el re...
Ultraactividad. Convenio de artes gráficas de Bizkaia. El TSJ desestima el re...Universidad Autónoma de Barcelona
 
Aplicación de airocide en hospitales
Aplicación de airocide en hospitalesAplicación de airocide en hospitales
Aplicación de airocide en hospitalesrobertolorente
 
Supprimer les paiements directs des soins en Afrique subsaharienne (soutenanc...
Supprimer les paiements directs des soins en Afrique subsaharienne (soutenanc...Supprimer les paiements directs des soins en Afrique subsaharienne (soutenanc...
Supprimer les paiements directs des soins en Afrique subsaharienne (soutenanc...Emilie Robert
 

En vedette (20)

Padres2ºcicloeso2trimestre
Padres2ºcicloeso2trimestrePadres2ºcicloeso2trimestre
Padres2ºcicloeso2trimestre
 
¿Dónde empieza y donde acaba la protección de los trabajadores de edad avanza...
¿Dónde empieza y donde acaba la protección de los trabajadores de edad avanza...¿Dónde empieza y donde acaba la protección de los trabajadores de edad avanza...
¿Dónde empieza y donde acaba la protección de los trabajadores de edad avanza...
 
Plan de estudios 2011 educacion basica
Plan de estudios 2011 educacion basicaPlan de estudios 2011 educacion basica
Plan de estudios 2011 educacion basica
 
LE BIM
LE BIMLE BIM
LE BIM
 
Mettreenplaceunestrategiewebmarketing 150115102019-conversion-gate01 (1)
Mettreenplaceunestrategiewebmarketing 150115102019-conversion-gate01 (1)Mettreenplaceunestrategiewebmarketing 150115102019-conversion-gate01 (1)
Mettreenplaceunestrategiewebmarketing 150115102019-conversion-gate01 (1)
 
Présentation NSim Contour à Geomatique 2009
Présentation NSim Contour à Geomatique 2009Présentation NSim Contour à Geomatique 2009
Présentation NSim Contour à Geomatique 2009
 
Silvia Aguilar Pérez
Silvia Aguilar PérezSilvia Aguilar Pérez
Silvia Aguilar Pérez
 
Unidad 7:Energia electrica
Unidad 7:Energia electricaUnidad 7:Energia electrica
Unidad 7:Energia electrica
 
Conace
ConaceConace
Conace
 
Tperr la christanisation
Tperr la christanisationTperr la christanisation
Tperr la christanisation
 
Cilss atelier réserves cedeao 3 5 oct 2011(2)
Cilss atelier réserves cedeao 3 5 oct 2011(2)Cilss atelier réserves cedeao 3 5 oct 2011(2)
Cilss atelier réserves cedeao 3 5 oct 2011(2)
 
Lecture publique md77
Lecture publique   md77Lecture publique   md77
Lecture publique md77
 
Dia del patrimonio
Dia del patrimonioDia del patrimonio
Dia del patrimonio
 
Bilan chantiers éducatifs 2011
Bilan chantiers éducatifs 2011Bilan chantiers éducatifs 2011
Bilan chantiers éducatifs 2011
 
Ultraactividad. Convenio de artes gráficas de Bizkaia. El TSJ desestima el re...
Ultraactividad. Convenio de artes gráficas de Bizkaia. El TSJ desestima el re...Ultraactividad. Convenio de artes gráficas de Bizkaia. El TSJ desestima el re...
Ultraactividad. Convenio de artes gráficas de Bizkaia. El TSJ desestima el re...
 
Llombai 2ºeva.
Llombai 2ºeva.Llombai 2ºeva.
Llombai 2ºeva.
 
guatemala
guatemalaguatemala
guatemala
 
Aplicación de airocide en hospitales
Aplicación de airocide en hospitalesAplicación de airocide en hospitales
Aplicación de airocide en hospitales
 
Supprimer les paiements directs des soins en Afrique subsaharienne (soutenanc...
Supprimer les paiements directs des soins en Afrique subsaharienne (soutenanc...Supprimer les paiements directs des soins en Afrique subsaharienne (soutenanc...
Supprimer les paiements directs des soins en Afrique subsaharienne (soutenanc...
 
Deya[1]
Deya[1]Deya[1]
Deya[1]
 

Similaire à Cours2 uml usecase

Fondamentaux d'architecture d'une application Flex
Fondamentaux d'architecture d'une application FlexFondamentaux d'architecture d'une application Flex
Fondamentaux d'architecture d'une application Flexdavid deraedt
 
Fondamentaux d'architecture d'une application Flex
Fondamentaux d'architecture d'une application FlexFondamentaux d'architecture d'une application Flex
Fondamentaux d'architecture d'une application Flexdavid deraedt
 
Cours1IntroUseCaseDiagram.pdf
Cours1IntroUseCaseDiagram.pdfCours1IntroUseCaseDiagram.pdf
Cours1IntroUseCaseDiagram.pdfbahajzouhair
 
Initiation à UML: Partie 2
Initiation à UML: Partie 2Initiation à UML: Partie 2
Initiation à UML: Partie 2DIALLO Boubacar
 
Rapport mini projet JAVA du module Programmation avancée Java
Rapport mini projet JAVA du module Programmation avancée JavaRapport mini projet JAVA du module Programmation avancée Java
Rapport mini projet JAVA du module Programmation avancée JavaAhmam Abderrahmane
 
Cas Pratique Du Mode DéConnecté De Silverlight
Cas Pratique Du Mode DéConnecté De SilverlightCas Pratique Du Mode DéConnecté De Silverlight
Cas Pratique Du Mode DéConnecté De SilverlightArnaud Auroux
 
Diagramme de cas d_utilisation.pptx
Diagramme de cas d_utilisation.pptxDiagramme de cas d_utilisation.pptx
Diagramme de cas d_utilisation.pptxPingdwendeChristophe
 
Unified Modeling Language Intro 2021-2022 VF
Unified Modeling Language Intro 2021-2022 VFUnified Modeling Language Intro 2021-2022 VF
Unified Modeling Language Intro 2021-2022 VFcifaf13039
 
Chp2 - Cahier des Charges
Chp2 - Cahier des ChargesChp2 - Cahier des Charges
Chp2 - Cahier des ChargesLilia Sfaxi
 
Uml2 a formation-uml-2-perfectionnement
Uml2 a formation-uml-2-perfectionnementUml2 a formation-uml-2-perfectionnement
Uml2 a formation-uml-2-perfectionnementCERTyou Formation
 
Architectures n-tiers
Architectures n-tiersArchitectures n-tiers
Architectures n-tiersHeithem Abbes
 
Uml2 i formation-uml-2-les-bases
Uml2 i formation-uml-2-les-basesUml2 i formation-uml-2-les-bases
Uml2 i formation-uml-2-les-basesCERTyou Formation
 
Application web Gestion RH ASP.NET MVC5
Application web Gestion RH ASP.NET MVC5Application web Gestion RH ASP.NET MVC5
Application web Gestion RH ASP.NET MVC5YounessLaaouane
 

Similaire à Cours2 uml usecase (20)

7 diagramme de cas d'utilisation
7 diagramme de cas d'utilisation7 diagramme de cas d'utilisation
7 diagramme de cas d'utilisation
 
diagramme de cas d'utilisation
diagramme de cas d'utilisationdiagramme de cas d'utilisation
diagramme de cas d'utilisation
 
Uml Cas Utilisation introduction
Uml Cas Utilisation introductionUml Cas Utilisation introduction
Uml Cas Utilisation introduction
 
CM CU-cockburn
CM CU-cockburnCM CU-cockburn
CM CU-cockburn
 
Uml & cas d'utilisation
Uml & cas d'utilisationUml & cas d'utilisation
Uml & cas d'utilisation
 
Fondamentaux d'architecture d'une application Flex
Fondamentaux d'architecture d'une application FlexFondamentaux d'architecture d'une application Flex
Fondamentaux d'architecture d'une application Flex
 
Fondamentaux d'architecture d'une application Flex
Fondamentaux d'architecture d'une application FlexFondamentaux d'architecture d'une application Flex
Fondamentaux d'architecture d'une application Flex
 
Cours1IntroUseCaseDiagram.pdf
Cours1IntroUseCaseDiagram.pdfCours1IntroUseCaseDiagram.pdf
Cours1IntroUseCaseDiagram.pdf
 
UML Diagrammes Dynamiques
UML Diagrammes DynamiquesUML Diagrammes Dynamiques
UML Diagrammes Dynamiques
 
Initiation à UML: Partie 2
Initiation à UML: Partie 2Initiation à UML: Partie 2
Initiation à UML: Partie 2
 
Rapport mini projet JAVA du module Programmation avancée Java
Rapport mini projet JAVA du module Programmation avancée JavaRapport mini projet JAVA du module Programmation avancée Java
Rapport mini projet JAVA du module Programmation avancée Java
 
Cas Pratique Du Mode DéConnecté De Silverlight
Cas Pratique Du Mode DéConnecté De SilverlightCas Pratique Du Mode DéConnecté De Silverlight
Cas Pratique Du Mode DéConnecté De Silverlight
 
Diagramme de cas d_utilisation.pptx
Diagramme de cas d_utilisation.pptxDiagramme de cas d_utilisation.pptx
Diagramme de cas d_utilisation.pptx
 
Unified Modeling Language Intro 2021-2022 VF
Unified Modeling Language Intro 2021-2022 VFUnified Modeling Language Intro 2021-2022 VF
Unified Modeling Language Intro 2021-2022 VF
 
Chp2 - Cahier des Charges
Chp2 - Cahier des ChargesChp2 - Cahier des Charges
Chp2 - Cahier des Charges
 
Uml2 a formation-uml-2-perfectionnement
Uml2 a formation-uml-2-perfectionnementUml2 a formation-uml-2-perfectionnement
Uml2 a formation-uml-2-perfectionnement
 
2 TUP
2 TUP2 TUP
2 TUP
 
Architectures n-tiers
Architectures n-tiersArchitectures n-tiers
Architectures n-tiers
 
Uml2 i formation-uml-2-les-bases
Uml2 i formation-uml-2-les-basesUml2 i formation-uml-2-les-bases
Uml2 i formation-uml-2-les-bases
 
Application web Gestion RH ASP.NET MVC5
Application web Gestion RH ASP.NET MVC5Application web Gestion RH ASP.NET MVC5
Application web Gestion RH ASP.NET MVC5
 

Plus de vangogue

Boutique en ligne
Boutique en ligneBoutique en ligne
Boutique en lignevangogue
 
EXPOSE SUR L’ALGORITHME DU TRI À BULLES (BUBBLE SORT).
EXPOSE SUR L’ALGORITHME DU TRI À BULLES (BUBBLE SORT).EXPOSE SUR L’ALGORITHME DU TRI À BULLES (BUBBLE SORT).
EXPOSE SUR L’ALGORITHME DU TRI À BULLES (BUBBLE SORT).vangogue
 
Edilivre les-fleurs-grises-de-midi-dieudonne-francois-ndje-man-preview
Edilivre les-fleurs-grises-de-midi-dieudonne-francois-ndje-man-previewEdilivre les-fleurs-grises-de-midi-dieudonne-francois-ndje-man-preview
Edilivre les-fleurs-grises-de-midi-dieudonne-francois-ndje-man-previewvangogue
 
Owasp top-10-2013-french
Owasp top-10-2013-frenchOwasp top-10-2013-french
Owasp top-10-2013-frenchvangogue
 
Rattrapage uml
Rattrapage umlRattrapage uml
Rattrapage umlvangogue
 
Scbd cg conception
Scbd cg conceptionScbd cg conception
Scbd cg conceptionvangogue
 
B4 tab calc excel
B4 tab calc excelB4 tab calc excel
B4 tab calc excelvangogue
 
Correction examen-java-avancé-1
Correction examen-java-avancé-1Correction examen-java-avancé-1
Correction examen-java-avancé-1vangogue
 
java BDD jdbc
java BDD jdbcjava BDD jdbc
java BDD jdbcvangogue
 
1 la-demarche-merise-le-schema-directeur
1 la-demarche-merise-le-schema-directeur1 la-demarche-merise-le-schema-directeur
1 la-demarche-merise-le-schema-directeurvangogue
 
Chap7 developpement modele statique
Chap7 developpement modele statiqueChap7 developpement modele statique
Chap7 developpement modele statiquevangogue
 
2010.th16419.durand.arnaud
2010.th16419.durand.arnaud2010.th16419.durand.arnaud
2010.th16419.durand.arnaudvangogue
 

Plus de vangogue (15)

Boutique en ligne
Boutique en ligneBoutique en ligne
Boutique en ligne
 
EXPOSE SUR L’ALGORITHME DU TRI À BULLES (BUBBLE SORT).
EXPOSE SUR L’ALGORITHME DU TRI À BULLES (BUBBLE SORT).EXPOSE SUR L’ALGORITHME DU TRI À BULLES (BUBBLE SORT).
EXPOSE SUR L’ALGORITHME DU TRI À BULLES (BUBBLE SORT).
 
Edilivre les-fleurs-grises-de-midi-dieudonne-francois-ndje-man-preview
Edilivre les-fleurs-grises-de-midi-dieudonne-francois-ndje-man-previewEdilivre les-fleurs-grises-de-midi-dieudonne-francois-ndje-man-preview
Edilivre les-fleurs-grises-de-midi-dieudonne-francois-ndje-man-preview
 
Owasp top-10-2013-french
Owasp top-10-2013-frenchOwasp top-10-2013-french
Owasp top-10-2013-french
 
Rattrapage uml
Rattrapage umlRattrapage uml
Rattrapage uml
 
Scbd cg conception
Scbd cg conceptionScbd cg conception
Scbd cg conception
 
B4 tab calc excel
B4 tab calc excelB4 tab calc excel
B4 tab calc excel
 
Correction examen-java-avancé-1
Correction examen-java-avancé-1Correction examen-java-avancé-1
Correction examen-java-avancé-1
 
Vb bdd
Vb bddVb bdd
Vb bdd
 
java BDD jdbc
java BDD jdbcjava BDD jdbc
java BDD jdbc
 
1 la-demarche-merise-le-schema-directeur
1 la-demarche-merise-le-schema-directeur1 la-demarche-merise-le-schema-directeur
1 la-demarche-merise-le-schema-directeur
 
Chap7 developpement modele statique
Chap7 developpement modele statiqueChap7 developpement modele statique
Chap7 developpement modele statique
 
2010.th16419.durand.arnaud
2010.th16419.durand.arnaud2010.th16419.durand.arnaud
2010.th16419.durand.arnaud
 
Chap2
Chap2Chap2
Chap2
 
Chap10
Chap10Chap10
Chap10
 

Cours2 uml usecase

  • 1. 7/10/13 1 IUT de LYON Module Analyse et Conception avec UML (Unified Modelling Language) Les Cas d’Utilisation (Use Case) 2 Cas d’utilisation : présentation   les « use case » d’Ivar JACOBSON   Décrire une utilisation du système (ensemble de séquences d’actions) par un acteur particulier   Acteurs externes à l’application   Un acteur = un rôle   Modélise l’un des aspects (comportement / service) du système par rapport à cet acteur   doit renseigner sur le rôle particulier de l’acteur (VA) UML V. Deslandres – IUT de LYON
  • 2. 7/10/13 2 3 Cas d’utilisation : présentation   Diagramme de description du QUOI FAIRE   Quelles sont les fonctionnalités : on décrit les cas précis d'utilisation de l'application Ex.: Utilisations d'un téléviseur   Pour regarder les chaînes publiques   Pour regarder le câble   Pour programmer/enregistrer avec son magnéto-cassette   Pour visionner avec son caméscope   Pour faire de l'internet   Comme miroir ou porte aquarium !   Mais pas du COMMENT   ni manipulation d’IHM, ni gestion des erreurs matérielles UML V. Deslandres – IUT de LYON 4 Cas d’utilisation (2)   L’ensemble des cas d’utilisation doit décrire exhaustivement les exigences attendues du système   Expression des besoins fonctionnels   Chaque « cas » = une fonction Métier du système selon le point de vue d’un des acteurs   C’est un ensemble d’échanges entre l’acteur et le système : un acteur demande des traitements, le système fournit des services   Représentation : acteurs et patates !   Chaque « patate » est un « cas d’utilisation » du système UML V. Deslandres – IUT de LYON
  • 3. 7/10/13 3 5 Exemple : diagnostic médical médecin patient secrétaire Règlement / facturation Élaboration d’un diagnostic Proposition du traitement Analyse des symptômes Gestion des RDV << include >> << include >> UML V. Deslandres – IUT de LYON 6 Exemple : agence de banque guichetier client responsable clientèle Effectuer opérations sur Les comptes Gérer les clients Planifier des rendez-vous Gestion de commande Ouvrir un compte Prospecter UML V. Deslandres – IUT de LYON
  • 4. 7/10/13 4 7 Cas d’utilisation : construction   On part des acteurs identifiés dans l’étude préliminaire   chercher les intentions (métier) avec lesquelles il utilise le système   déterminer dans le CdesCh les services fonctionnels attendus UML V. Deslandres – IUT de LYON 8 Construction des cas   On utilise les échanges de messages identifiés dans le contexte dynamique   Distinguer l’acteur principal des acteurs secondaires   Acteur principal: pour lequel le Cas produit la plus- value métier (souvent : le déclencheur)   L'acteur secondaire ne fait que recevoir le résultat obtenu à l'issue de la réalisation de l'utilisation envisagée (en général placé à droite) UML V. Deslandres – IUT de LYON
  • 5. 7/10/13 5 9 Validation   Pour chaque cas d’utilisation candidat :   vérifier qu’il fournit une VA notable à l’acteur   contrôler qu’un événement externe en déclenche l’exécution   Ne pas descendre trop bas : un UC n’est ni une transaction, ni une fonction du système !   Ex.: saisie des commandes, elles peuvent l’être via le web, via les feuilles issues du service commercial, ou manuellement après contacts téléphoniques.   Ca conduit donc à 3 séquences d’actions différentes mais pour un seul cas d’utilisation : la saisie des commandes.   REGLE : un cas d’utilisation doit regrouper au moins 2 séquences (sans compter les exceptions)   Séquence principale + alternative UML V. Deslandres – IUT de LYON UML V. Deslandres – IUT de LYON 10 Etude de cas SIVEX   On part du diagramme de contexte dynamique   Chercher l’« intention fonctionnelle » de chaque acteur dans son intéraction avec le système   Quelle fonctionnalité le concerne dans l'application ?   S’inspirer des messages   Regrouper les intentions en unités cohérentes
  • 6. 7/10/13 6 11 Ex. Planification missions   Acteur principal = répartiteur   Intentions   planifier les missions d’une agence, permettant la réalisation des commandes en cours   Actions :   créer une nouvelle mission :   regrouper des commandes, affecter des ressources disponibles, établir un parcours, évaluer les durées, le volume nécessaire pour la camionette, etc…   modifier ou annuler une mission existante UML V. Deslandres – IUT de LYON 12   Acteur principal = Ex. Suivi de mission chauffeur • Intentions • Actions Informer en temps réel de l’état d’avancement de la mission en cours - Transmettre chaque arrêt et départ d’étape - Signaler les événements de mission acquittement client, panne, retard, absence client... UML V. Deslandres – IUT de LYON
  • 7. 7/10/13 7 13 Use Case : Gestion des missions UML V. Deslandres – IUT de LYON 14 Formalisme des cas d’utilisation   Différents types de relations   Relation entre un acteur et un cas : - trait simple : l'acteur déclenche le cas - flèche vers acteur : l'acteur reçoit le résultat du cas (acteur secondaire)   Relation d’héritage entre cas : un cas d'utilisation (une fonctionnalité) dérive d'une fonctionnalité plus générale   ex.: « Sélection d'une location de vacances » et « Sélection d'une péniche pour un séjour » Relation d’héritage entre cas UML V. Deslandres – IUT de LYON
  • 8. 7/10/13 8 15 Héritage entre Acteurs UML V. Deslandres – IUT de LYON 16 Relations « includes, extends » Cas de base Cas de base Cas inclus extension <<include>> <<extend>> UML V. Deslandres – IUT de LYON
  • 9. 7/10/13 9 17 Autres relations entre cas   Relation d’inclusion « include » :   La réalisation d’un cas de base passe obligatoirement par celle d’un cas spécifique inclus   (objectif : factorisation)   Ex. : procédure d’authentification   Relation d’extension « extend » :   Cas de base incorpore une extension, à un point d’extension prévu   (obj.: représenter un comportement optionnel)   Ex. : la prise de commande peut conduire à la création d’un nouveau client UML V. Deslandres – IUT de LYON 18 Exemples Quelles relations utiliser ? UML V. Deslandres – IUT de LYON Modification document Vérification droit d’accès ? Saisie commande Vérification stock ? Développement pages d’un site web Définition charte graphique ? Modification document Vérification droit d’accès include Développement pages d’un site web Définition charte graphique extends Saisie commande Vérification stock include
  • 10. 7/10/13 10 19 Corrigés des exemples Quelles relations utiliser ? UML V. Deslandres – IUT de LYON Modification document Vérification droit d’accès include Développement pages d’un site web Définition charte graphique extends Saisie commande Vérification stock include 20 Use Case SIVEX : Gestion des Commandes Consultation d'en-cours Client Réceptionniste Gestion de Commande secondaire Gestion des Clients (nouveau client) <<extend>> Point d'extension : nouveau client UML V. Deslandres – IUT de LYON
  • 11. 7/10/13 11 21 Use Case : Gestion comptabilité UML V. Deslandres – IUT de LYON
  • 12. 7/10/13 12 23 Package en UML = concept commun de regroupement : Structuration des cas d’utilisation Structuration par package   d’éléments d’un modèle   de diagrammes de ces éléments   d’autres packages   Contraintes :   tout élément n’appartient qu’à un seul paquetage   Ensemble cohérent au niveau sémantique (expertise métier)   Représentation : icône de dossier UML V. Deslandres – IUT de LYON 24 Techniques de regroupement   Par domaine d’expertise métier   regroupement le plus intuitif et efficace   permet de faciliter la spécilisation des analystes   organiser facilement la répartition des experts   Par acteur   facile si chaque cas est relié à UN seul acteur   Par lot de livraison client   dans le cas d’un développement incrémental, c ’est parfois un critère utilisé UML V. Deslandres – IUT de LYON
  • 13. 7/10/13 13 Relations entre packages import include use UML V. Deslandres – IUT de LYON 26 Regroupement en packages : SIVEX - Par domaine d’expertise métier - Ensembles d’acteurs fortement liés Définition du plan de transport, et des ressources Acteurs: resp. logistique Définition des profils utilisateur Acteur: administrateur Gestion clients, gestion des commandes, consultation des en-cours Acteurs : réceptionniste, client UML V. Deslandres – IUT de LYON
  • 14. 7/10/13 14 1. Contexte d'apprentissage d'UML 2. Développement logiciel 3. Application de téléchargement de Cours 28 Exemple 1 : cas d’utilisation décrivant un fonctionnement   Cas d'utilisation décrivant le contexte dans lequel vous allez apprendre à concevoir avec UML à l'IUT… Impétrant assister aux cours lire ouvrages rechercher informations Présenter le formalisme UML Proposer des exercices Evaluer impétrants Enseignant UML V. Deslandres – IUT de LYON
  • 15. 7/10/13 15 29 Exemple 2 : cas d’utilisation de fonctionnement   Cas d'utilisation de développement de logiciel Chef de projet (maîtrise d'œuvre) Maître d'ouvrage Architecte logiciel Architecte technique Utilisateur Développeur Piloter le processus développement Objet Concevoir une architecture technique Organiser le développement logiciel et les tests Définir les besoins Tester UML V. Deslandres – IUT de LYON 30 Exemple 3 : cas d’utilisation d’une application informatique   Décrivant le téléchargement d’un Cours Internaute BD Users / droits Chercher un cours Sélectionner un ou plusieurs cours Télécharger un cours Ouvrir l’application Authentification Serveur de Cours Connexion include extends UML V. Deslandres – IUT de LYON Abonné S’abonner extends
  • 16. 7/10/13 16 Questions sur l’ex. 3 •  Pourquoi ne voit-on pas le cas « Visualiser un cours » (description, pré requis, etc.) ? ▫  Pourquoi voit-on le cas « Rechercher un Cours » ? •  Que représentent les cas inclus pour l’application ? Pourquoi les isole-t-on ? •  Quel est le choix de conception du Client pour ce site ? (qui pourrait être différent) •  Les cas sont incomplets : lesquels ajouter ? - Contrôler le nb de cours téléchargés - Déposer un commentaire UML V. Deslandres – IUT de LYON 32 Description des Cas d’utilisation On décrit les cas d’utilisation avec des diagrammes d’abord, et éventuellement sous forme textuelle.   Structure de description des cas d’utilisation   qui permet de mieux les exploiter par la suite :   sommaire d’identification (titre, but, résumé, acteurs, dates, version, responsable)   description des enchaînements (nominaux, exceptionnels, pré-post conditions)   éventt : besoins d’IHM   éventt : contraintes non-fonctionnelles (fréquence, volumétrie, disponibilité, confidencialité, performances…) UML V. Deslandres – IUT de LYON
  • 17. 7/10/13 17 33 Quel format de description ?   Il existe différents modèles de cas d’utilisation détaillé   Le plus répandu est celui de www.usecases.org   (cf SIVEX, et ex. ici)   Description :   Titre, acteur principal, parties prenantes et intérêts, pré et post conditions, scénario principal (happy path, succès) sans condition ni branchement, extensions (scénarios d’exception);   Spécifications particulières (hors contraintes fonctionnelles : interface, langue, temps de réponse);   Technologies envisagées ou évolutions à MT (ex. actuellement chèque accepté, en Juin 2003, plus de chèque), questions à se poser. UML V. Deslandres – IUT de LYON 34 Exercice : quelle validité des UC   Soit un système de vente en ligne   Lesquels de ces cas d’utilisation seraient valides ?   Supprimer un article   Négocier un contrat avec un fournisseur   Traiter les retours   Se connecter   Imprimer un document UML V. Deslandres – IUT de LYON
  • 18. 7/10/13 18 35 Use Cases : réponse   Les 3 cas du milieu sont utiles à différents niveaux d’abstraction, en fonction des acteurs et des objectifs.   La question plutôt à se poser est :   À quel niveau faut-il exprimer un cas d’utilisation de façon à se qu’il soit utile pour l’analyse des besoins ?   Il faut pour cela identifier les Processus métier élémentaires UML V. Deslandres – IUT de LYON 36 Quels cas d’utilisation créer   Identifier les Processus Métier pour lesquels il y a valeur ajoutée observable et mesurable   Qui laissent le système dans un état stable et cohérent   Définir les acteurs externes et internes et se concentrer sur leurs intentions   Notamment ne pas raisonner en interface utilisateur UML V. Deslandres – IUT de LYON
  • 19. 7/10/13 19 37 Exemple sur l’exercice   « Se connecter » : processus Métier ? plus value ?   Non, but secondaire   « se connecter pour commander » : OK ( traiter vente)   « se connecter pour enregistrer les ventes du mois » : OK ( enrichir statistiques)   « se connecter pour mettre à jour le catalogue » : OK ( gérer articles)   « Supprimer un article » : secondaire aussi !   Gestion Article plus appropriée   « Imprimer un document » : inutile ici   activité technique, pas un besoin Métier   (L’étape d’authentification n’est jamais un processus métier, sauf pour une modélisation purement informatique !) UML V. Deslandres – IUT de LYON 38 Risques associés aux Cas   Ne pas réinventer la décomposition fonctionnelle !   On fait de l’analyse ORIENTEE OBJET !!   Ne pas aller trop loin dans le détail, on en est à la capture des besoins fonctionnels.   Limiter à 10 le nombre de (« grands ») CU, rester synthétique   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,   démarrer l’analyse en identifiant les classes candidates. UML V. Deslandres – IUT de LYON
  • 20. 7/10/13 20 39 Autres risques   Ne pas mélanger l’IHM et le fonctionnel   on décrit le métier des acteurs, indépendamment des choix d’interface qui pourront évoluer… – ex.: préférer « lors d’une 1ère commande, le réceptionniste enregistre les caractéristiques du nouveau client dans le système » à : – « le réceptionniste saisit le nom du client en 8 car. max, en majuscules, appuie sur ENTER, puis saisit le prénom en minuscules » ou à – « le réceptionniste enregistre par un syst. de reconnaissance vocale les nom, prénom, adresse et code postal du client » UML V. Deslandres – IUT de LYON DEMARCHE UML •  On part d’une étude de contexte ▫  Diagramme de contexte statique ▫  Diagramme de contexte dynamique •  On construit les diagrammes de Cas d’utilisation •  On les regroupe en packages si besoin •  On en déduit les classes, on fait de premiers diagrammes de classes ▫  partiels ou global UML V. Deslandres – IUT de LYON
  • 21. 7/10/13 21 41 Démarche détaillée Cas d’Utilisation / Diagramme de Classes (1) Présentation du contexte et du sujet (2) Identifier les acteurs externes du système à l’aide d’un diagramme de contexte statique   Acteurs = rôles joués par des personnes ou systèmes externes   Les acteurs internes (ex.: comptables, serveur de BD… ) apparaîtront plus tard dans la modélisation   Penser à l’environnement humain et informatique   Nommer ces acteurs UML V. Deslandres – IUT de LYON 42 Démarche Cas d’utilisation (2) (3) Ajouter les échanges d'informations acteurs / système   les nommer, éventuellement les définir par une phrase   créer ainsi le diagramme de contexte dynamique (4) Construire le diagramme des cas d'utilisation : identifier les services rendus aux acteurs par le système (tâches)   étude plus fine des interactions acteurs / système, en dissociant les grandes fonctions   nommer les services rendus, les définir par une phrase   Règle : avoir plusieurs séquences d’actions par CU (« enregistrer un client » = si c’est juste une saisie, ça n’est pas un CU; préférer « Gestion Client ») UML V. Deslandres – IUT de LYON
  • 22. 7/10/13 22 43 (5) Pour chaque cas d'utilisation :   Détailler son fonctionnement par un diagramme d’activités   Chaque activité peut être élémentaire   On peut montrer les séquences et les alternatives (6) Associés aux activités, définir les objets partagés entre acteurs et système :   Objets traités, mémorisés, produits, transformés   objets du monde modélisé   objets importants pour les acteurs   objets persistants ou pas   Cela va aider à identifier les classes candidates Démarche Cas d’utilisation / diag Classes (3) UML V. Deslandres – IUT de LYON 44   Lister et nommer les objets (avec le vocabulaire des acteurs), les définir par une phrase   Identifier ensuite les classes candidates et construire un diagramme de classes   par package   Relier les objets, nommer les liens, les définir par une phrase Pour chaque cas d’utilisation (suite) UML V. Deslandres – IUT de LYON
  • 23. 7/10/13 23 45 6.  Si nécessaire, réunir les objets des différents cas dans un unique diagramme de classes (bien entendu un même objet peut intervenir dans les différents cas d’utilisation envisagés : Ex. dans une application de type « Editeur logiciel », un document sera déposé, validé, fusionné, chaque action correspond à un CU) Démarche Cas d’utilisation / Diag Classes (4) UML V. Deslandres – IUT de LYON 46 Exercice : site vente en ligne   Client : consulte, achète des produits, demande un renseignement, souhaite obtenir un RV personnalisé, etc.   Administrateur : ouvre comptes, etc.   Responsable Produits : MàJ le catalogue, veille   Technicien : répond aux questions techniques sur les produits UML V. Deslandres – IUT de LYON
  • 24. 7/10/13 24 47 Site vente en ligne Client Maintenance site Gestion des Clients Consultation Catalogue Gestion des Commandes MàJ Catalogue extends extends Veille technologique Renseignements techniques Authentification includes Administrateur Resp. Produits Technicien UML V. Deslandres – IUT de LYON Exemple de Cas d’Utilisation SIVEX SIVEX: Planification des missions (fiche de description)
  • 25. 7/10/13 25 49 Use Case : Gestion des missions UML V. Deslandres – IUT de LYON 50 Ex SIVEX Description du Cas « Planification des missions » (1/5)   BUT : planification des missions d’enlèvement, de transport ou de livraison, d’une agence à partir du plan de transport, des commandes à assurer quotidiennement et des ressources disponibles • RESUME : création d’une nouvelle mission à partir des cdes confirmées, modification et annulation d’une mission existante. • ACTEURS : • PRE-CONDITIONS : - le répartiteur est authentifié - les commandes à planifer sont confirmées répartiteur (ppal), chauffeur (sec.) UML V. Deslandres – IUT de LYON
  • 26. 7/10/13 26 51 DEF Enchaînements   Enchaînement nominal = fonctionnement normal   ex.: dans le processus d’appel téléphonique, fonctionnement nominal =   Enchaînement exceptionnel = fonctionnement anormal, traitement des événements exceptionnels   ex.: dans le processus d’appel téléphonique, fonctionnement exceptionnel = Décrocher combiné, entendre sonnerie attente, composer numéro, attendre sonnerie appel, communiquer, raccrocher Décrocher combiné, pas de sonnerie d’attente, vérifier branchement ligne, (suite) UML V. Deslandres – IUT de LYON 52 « Planification des missions » (2/5)   Enchaînements identifiés : – créer une mission en attente – affecter des commandes à une mission – affecter les ressources – modifier une mission en attente (désaffecter une commande, modification des chauffeurs ou véhicule, modification des étapes…) – valider une mission en attente – modifier une mission validée – annuler une mission (en attente ou validée) – éditer les bordereaux de mission UML V. Deslandres – IUT de LYON
  • 27. 7/10/13 27 53 « Planification des missions » (3/5)   Exceptions identifiées : – Pour une mission donnée, dépassement de tonnage véhicule – Chauffeur sélectionné non qualifié pour conduire le véhi-cule choisi pour la mission – Tonnage de réserve entammé (chaque agence doit se réser-ver un certain tonnage pour pouvoir répondre à des comman-des prioritaires ou de dépannage) – Estimation de temps incomplète pour une étape donnée donc pour la mission comportant cette étape UML V. Deslandres – IUT de LYON 54 « Planification des missions » (4/5)   Post-conditions – Tout ce qui est connu à l’issue du cas – Pour lister les commandes de l’agence, le répartiteur doit pouvoir répertorier les commandes de l’agence par type, poids, site desservi, affectée/non affectée, tarification urgent/ non urgent – Les commandes non affectées doivent être de couleur différente   Besoins d’IHM UML V. Deslandres – IUT de LYON
  • 28. 7/10/13 28 55 « Planification des missions » (5/5)   Contraintes non fonctionnelles : temps de réponse – Interface répartiteur : moins de 2 secondes – Concurrence : les validations de mission doivent être notifiées aux lecteurs potentiels par un message d’avertissement en TR – Disponibilité : le système doit être accessible au répartiteurs 6 jours sur 7, aux heures d’ouverture des agences   Autres contraintes : UML V. Deslandres – IUT de LYON