user case cas d utilisation

1. MODULE: CONCEPTION DES
SYSTÈMES LOGICIELS
Réalisé par : Dr. Yassine Rhazali
Contact : rhazali.formations@gmail.com
Licence d'Université Spécialisée (LUS):
Développeurs d’Applications Web et Mobile
Année universitaire: 2020/2021

2. Sommaire
Partie 1: UML Partie 2: BPMN Partie 3: IFML
Chapitre 1: Diagramme
de Cas d’utilisation
Chapitre 2: Diagramme
Séquence
Chapitre 3: Diagramme
de classe
Diagramme de
processus métier
Diagramme d’IFML

3. PARTIE I: UML

4. UML
• UML(Unified Modeling Language) un langage de
modélisation unifié. (MERISE vs UML)
• Dans la génie logiciel avant de réaliser une
application (logiciel) il faut réaliser l’analyse et la
conception du logiciel ,c’est pareil au génie civil
avant de construire un bâtiment il faut réaliser le
plan du bâtiment.
• UML est le standard de modélisation de l’étape
d’analyse et de conception dans la génie logiciel.
4

5. Un peu du génie logiciel
Analyse
Conception
Développement
Test
Cahier de charge

6. Un peu du génie logiciel
Analyse: diagramme de
cas d’utilisation
Conception
Développement
Test
Cahier de charge

7. 7
CHAPITRE I: DIAGRAMME DE CAS
D’UTILISATION

8. Diagramme de cas d’utilisation
• Décrit, sous forme de fonctionnalités, le
comportement du système du point de vue
d’un utilisateur.
• Permet de définir les limites du système et ses
relations avec l’environnement.
8
Limites de systèmes

9. Diagramme de cas d'utilisation
• Permet de ressortir les acteurs (utilisateurs)
utilisant la futur application
• Permet de ressortir les fonctionnalités
offertes par la futur application.
• Son objectif c’est modéliser les exigences
(besoins du cahier de charge) du client d’une
manière formelle.
9

10. Diagramme de cas d'utilisation
Diagramme de cas d’utilisation Comportent
plusieurs éléments :
• Acteurs
• Cas d'utilisation
• Relations de dépendances, de généralisations
et d'associations
10

11. Acteurs
• UML n’emploi pas le terme d’utilisateur mais d’acteur.
• Le terme acteur ne désigne pas seulement des
utilisateurs humains mais également les autres
systèmes (machines, programmes, …).
– Exemple 1 : logiciel qui utilise le scanner pour importer les
documents.
– Exemple 2 : logiciel qui utilise l’imprimante pour imprimer
les documents exporter par le logiciel.
• Un acteur est un rôle joué par une entité externe qui
agit sur le système, en échangeant de l’information (en
entrée et en sortie).
11

12. Acteurs
Remarques
• La même personne physique peut jouer le rôle
de plusieurs acteurs (utilisateur d’un compte
facebook et administrateur d’une page
facebook).
• D’autres part, plusieurs personnes peuvent
jouer le même rôle, et donc agir comme un
même acteur (plusieurs personnes peuvent
jouer le rôle: utilisateur de facebook).
12

13. Acteurs
Peut être représenté de deux manières
différentes :
• Petit personnage (stick man)
• Classe stéréotypée
13
<<Acteur>>
Nom Acteur

14. Acteurs
Les acteurs peuvent être de trois types :
• Humains : utilisateurs du logiciel à travers son
interface graphique, par exemple.
• Logiciels : qui communiquent avec le système (
l’application facebook communique avec
l’application youtube: Ainsi on peut partager des
vidéos de l’application youtube dans l’application
facebook)
• Matériels : exploitant les données du système ou
qui sont pilotés par le système (Imprimante,
robots, automates, Scanner, …)
14

15. Acteurs
15

16. Acteurs
16

17. Acteurs
Mais du point de vue système on distingue deux
types :
• Acteurs principaux : utilisent les fonctions
principales du système. Par exemple, l’étudiant
pour le système de gestion de scolarité
• Acteurs secondaires : effectuent des tâches
secondaires pour le système. Par exemple, le site
web qui contient un lien vers le système,
l’imprimante qui imprime les documents PDF
produisent par le système.
17

18. Acteurs
Un acteur peut être une
spécialisation d'un autre
acteur déjà défini.
Dans ce cas, on utilise la
relation de
généralisation/spécialisation.
18

19. Acteurs
• Exemple de la relation de
généralisation/spécialisation.
:
• Un directeur est une sorte de
commercial : il peut faire
avec le système tout ce qu’il
peut faire un commercial,
plus d’autres choses.
19

20. Cas d'utilisation
Les cas d’utilisations
• Permettent de modéliser les attentes
(besoins) des utilisateurs
• Représentent les fonctionnalités du système
• L’image d’une fonctionnalité du système,
déclenchée en réponse à la stimulation d’un
acteur externe.
20

21. Cas d'utilisation
Un cas d'utilisation est représenté par une
ellipse en trait plein, contenant son nom.
21

22. Structuration des cas d'utilisation
Après avoir identifié les acteurs et les cas
d'utilisation, il est utile de restructurer l'ensemble
des cas d'utilisation
UML définit trois types de relations standardisées
entre cas d'utilisation :
• Une relation d'inclusion, formalisée par la
dépendance «include».
• Une relation d'extension, formalisée par la
dépendance «extend».
• Une relation de généralisation/spécialisation.
22

23. Relation d'inclusion
Lors de la description des cas d'utilisation, il
apparaît qu'il existe des sous-ensembles
communs à plusieurs cas d'utilisation.
23

24. Relation d'inclusion
• A inclut B : le cas A inclut obligatoirement le
comportement définit par le cas B; permet de
factoriser des fonctionnalités partagées.
• Le cas d'utilisation pointé par la flèche (dans
notre cas B) est une sous partie de l'autre cas
d'utilisation (A, dans notre exemple).
24

25. Relation d'inclusion
25
Les cas d'utilisation "Retirer de l'argent",
"Déposer de l'argent", "Effectuer des
virements" et "Consulter solde" utilise de
façon explicite le cas d'utilisation
"S'authentifier", à un endroit spécifié dans
leurs enchaînements.

26. Relation d'inclusion
On utilise cette relation pour éviter de décrire
plusieurs fois un même enchaînement d'actions.
Ainsi, on est amené à factoriser un
comportement commun à plusieurs cas
d'utilisation dans un cas d'utilisation à part.
Remarques
• La relation include n’a pour seul objectif que de
factoriser une partie de la description d’un cas
d’utilisation qui serait commune à d’autres cas
d’utilisation.
26

27. Relation d'extension
La relation «extend» permet d'étendre une
fonction décrite dans un cas d'utilisation, mais
sous certaines contraintes.
27

28. Relation d'extension
• Le CU source (B) ajoute, sous certaines
conditions, son comportement au CU destination
(A)
• En d’autres termes, le CU B peut être appelé au
cours de l’exécution du CU A
• Le comportement ajouté s’insère au niveau d’un
point d’extension définit dans le CU destination
28

29. Relation d'extension
Exemple :
Au moment de l'authentification, il se peut que
le guichet retient la carte.
29

30. Relation d'héritage
• Il peut également exister une relation
d'héritage entre cas d'utilisation.
• Cette relation exprime une relation de
spécialisation/généralisation au sens
classique.
30

31. Relation d'héritage : Exemple
Dans un système d'agence de voyage, un acteur
"Touriste" peut "Réserver un voyage". Une
réservation peut être réalisée par téléphone ou par
Internet.
31

32. Relation d'héritage : Exemple
32

33. Structuration entre cas d’utilisation
Résumé
Les cas peuvent être structurées par des relations :
• A inclut B : le cas A inclut obligatoirement le
comportement définit par le cas B; permet de
factoriser des fonctionnalités partagées
• A étend B : le cas A est une extension optionnelle
du cas B à un certain point de son exécution.
• A généralise B : le cas B est un cas particulier du
cas A.
33

34. Exercice 1 de synthèse
• Au sein un établissement scolaire, on désire gérer la
réservation des salles de cours ainsi que du matériel
pédagogique (ordinateur portable ou/et Vidéo projecteur).
Seuls les enseignants sont habilités à effectuer des
réservations (sous réserve de disponibilité de la salle ou du
matériel). Le planning des salles peut quant à lui être consulté
par tout le monde (enseignants et étudiants). Par contre, le
récapitulatif horaire par enseignant (calculé à partir du
planning des salles) ne peut être consulté que par les
enseignants. Enfin, il existe pour chaque formation un
enseignant responsable qui seul peut éditer le récapitulatif
horaire pour l’ensemble de la formation.
• Question : donner le diagramme de cas d’utilisation
correspondant.
34

35. Exercice 1 de synthèse
35

36. Exercice 2 de synthèse
• Les tâches d’une médiathèque sont la gestion des
ouvrages et la gestion des adhérents. Le prêt d'un
exemplaire d'un ouvrage donné est limité à trois
semaines.
• Si l'exemplaire n'est pas rapporté dans ce délai, un
gestionnaire des contentieux génère un contentieux. Si
l'exemplaire n'est toujours pas rendu au bout d'un an,
une procédure judiciaire est déclenchée.
• L'accès au système informatique est protégé par un
mot de passe
• Question : donner le diagramme de cas d’utilisation
correspondant.

37. Exercice 2 de synthèse