Vous êtes sur la page 1sur 33

27/09/2018

Chap2: Diagrammes UML présentant


l’analyse des besoins des utilisateurs

Cours: Modélisation avec UML


Enseignante: Mme N.Berbiche

Plan

 Introduction

 Etapes de l’analyse des besoins

 Diagramme de contexte

 Diagramme de package

 Diagramme des cas d’utilisations

 Les cas d’utilisations internes

N.Berbiche EST - Salé 2

1
27/09/2018

introduction

Dans cette partie, nous allons partir d’une étude de cas, suivre
pas à pas l’analyse des besoins d’un projet en réalisant
différents diagrammes.

On tentera d’effectuer l’analyse des besoins d’un projet


commun : créer une boutique en ligne.

N.Berbiche EST - Salé 3

introduction

 Nous identifierons les premiers besoins grâce aux différents


échanges avec le client.
 On découvrira au fur et à mesure les différents besoins et actions que
le client souhaite intégrer dans son projet de logiciel, la boutique en
ligne.
 Notre première mission sera donc de décrypter son discours au fur et
à mesure afin de préciser ses besoins.
 C’est ce qu’on appelle la modélisation des besoins
fonctionnels.
 Nous essaierons donc de répondre aux questions suivantes :
 Qui sont les utilisateurs ?
 Que veulent-ils faire avec le logiciel ?

N.Berbiche EST - Salé 4

2
27/09/2018

Etapes de l’analyse des besoins

 Analyser les besoins, c’est découvrir des éléments de plus en


plus précis. On effectue cette analyse à travers des étapes :

Étape 1: On commence par décrire le contexte du logiciel à créer.

Le contexte, c’est l’environnement direct du logiciel. A cette


étape, il s’agit de décrire QUI devra utiliser le logiciel.

Il faut donc se poser la question : à qui le logiciel devra -t-il servir?

N.Berbiche EST - Salé 5

Etapes de l’analyse des besoins - suite

Etape2: On décompose ensuite le logiciel en plusieurs parties


distinctes, afin de ne pas avoir à analyser quelque chose de trop
énorme d’un coup.

 On appelle ça la décomposition en packages. La décomposition


peut se faire en réfléchissant à des « familles » de fonctionnalités
qui seraient nécessaires.
Les questions à se poser:
 Quelles sont les grandes parties qui doivent composer le
logiciel?
 Pour une partie précise, qui, parmi les acteurs identifiés (ou
utilisateurs) l’utilisera?

N.Berbiche EST - Salé 6

3
27/09/2018

Etapes de l’analyse des besoins - suite

Etape3: Chaque partie est alors analysée séparément, en précisant


QUI devra pouvoir faire QUOI dans cette partie du logiciel.

C’est ce qu’on appelle définir les cas d’utilisation.

La question à se poser: « dans la partie 3, qui devra faire quoi


avec le logiciel ? »

N.Berbiche EST - Salé 7

Les diagrammes UML nécessaires à l’analyse des


besoins

Pour illustrer chacune des étapes, on utilise un diagramme précis

 Pour décrire le contexte, on réalise un diagramme de contexte

 Pour expliquer la décomposition du logiciel en parties distinctes, on


se sert d’un diagramme de packages.

 Enfin, pour illustrer ce que le logiciel doit permettre de faire, on


utilise un diagramme des cas d’utilisation.

N.Berbiche EST - Salé 8

4
27/09/2018

Décomposition de l’analyse

Le système ou contexte

Les différents packages

Les différents diagrammes qui


illustrent un package

N.Berbiche EST - Salé 9

Etude de cas

Cas d’étude : créer la boutique en ligne d’une entreprise de papeterie.

Nous découvrirons pas à pas la démarche à suivre. Voici le projet:

Qui est notre client ?


Notre client, Monsieur El filali, est le directeur d’une entreprise
commerciale, El filali bureaux, spécialisée dans les produits de bureau.
Son entreprise est localisée à Tanger

Que vend-il ?
Voici la liste de produit qu’il vend sur place :
 Matériel de base : crayons, stylos, gommes, papier, cahiers, etc.
 Matériel électronique : ordinateurs, imprimantes, téléphones, etc.
 Mobilier : tables, bureaux, chaises, armoires, etc.

N.Berbiche EST - Salé 10

5
27/09/2018

Etude de cas - suite

Pourquoi nous contacte-t-il ?


 L’entreprise doit faire face à la concurrence de grandes enseignes,
Mr El Filali a le projet de moderniser toute la démarche commerciale
de l’entreprise. Il souhaite passer au e-commerce, c’est-à-dire vendre
ses produits sur Internet. La société espère ainsi obtenir une
meilleure visibilité et obtenir une augmentation des ventes.

Que souhaite-t-il faire sur le site de vente en ligne ?


Lors d’une première discussion avec le client Monsieur El filali, nous
avons pu obtenir les précisions suivantes :
 Le client (ou un acheteur potentiel) doit pouvoir consulter les
produits et éventuellement procéder à un achat en ligne.
 Les commerciaux de la société doivent pouvoir consulter le
catalogue des produits en ligne et enregistrer les achats des
clients.

N.Berbiche EST - Salé 11

Etude de cas - suite

 Le service des livraisons doit pouvoir consulter les commandes pour


préparer les colis et les livrer au client.
 Le technicien doit pouvoir vérifier d’éventuelles remarques ou
messages signalant un dysfonctionnement lors de l’achat en ligne.
 Le service administratif de la société doit pouvoir :
- ajouter de nouveaux produits au catalogue en ligne ;
- modifier les descriptions ou les prix des produits ;
- retirer si besoin des produits que l’on ne souhaite plus proposer.
 Le directeur, quant à lui, souhaite avoir une vision globale des ventes.
À travers le site, il souhaite pouvoir :
- faire un suivi du chiffre d’affaires par mois, sur une certaine durée ;
- voir quels produits sont les plus vendus sur une durée donnée.

N.Berbiche EST - Salé 12

6
27/09/2018

Etude de cas: étape 1- définition du contexte

 On commence par considérer que le futur logiciel correspond à une


boîte noire qui doit fournir des services à son environnement.

 Par environnement, on entend les utilisateurs qui ont besoin de ce


logiciel.

 Dans UML, on appelle ce qu’on doit analyser, concevoir et réaliser:


le système.
 Ici, le système est donc le site de vente en ligne.

Le système, correspond à une


boîte noire à cette étape

N.Berbiche EST - Salé 13

Les acteurs

 Les utilisateurs qui vont interagir avec le système sont appelés acteurs

 Un acteur correspond à une entité (humaine ou non) qui aura une


interaction avec le système.

Deux types d’acteurs, nous distinguons :


 les acteurs principaux: ils agissent directement sur le système. Il s’agit
d’entités qui ont des besoins d’utilisation du système. On peut donc
considérer que les futurs utilisateurs du logiciel sont les acteurs principaux.

 les acteurs secondaires: ils n’ont pas de besoin direct d’utilisation. Ils
peuvent être soit consultés par le système à développer, soit récepteur
d’informations de la part du système. Cela est généralement un autre
système (logiciel) avec lequel le nôtre doit échanger des informations.

N.Berbiche EST - Salé 14

7
27/09/2018

Les acteurs

 Certains acteurs sont de type humain. Ils sont représentés par un


bonhomme, leur rôle est indiqué en dessous.

Acteur
de type
humain

 Pour représenter un
acteur de type non-
humain, on peut utiliser
une représentation
graphique différente et/ou
ajouter une indication
supplémentaire appelé le
stéréotype.
Acteur de type non-humain
N.Berbiche EST - Salé 15

Etude de cas: étape1- le contexte

 Etape 1 : Décrire le contexte du logiciel, c’est-à-dire la


boutique en ligne de la société El filali bureaux.

 Relisez-bien les demandes de Monsieur El filali.

 Pouvez-vous identifier les acteurs de notre site de vente en


ligne ? Parmi ces acteurs, lesquels sont des acteurs
principaux et des acteurs secondaires ?

N.Berbiche EST - Salé 16

8
27/09/2018

Etude de cas: les acteurs

 Les acteurs: le client (internaute: client potentiel); les


commerciaux , le service des livraisons; le technicien; le
service administratif; le directeur
 Ces acteurs sont des acteurs principaux, puisqu’ils devront
tous utiliser le système pour des actions précises.

les acteurs principaux

N.Berbiche EST - Salé 17

Etude de cas: les acteurs

 Vous constaterez qu’on indique un seul acteur pour « client », alors qu’il très
souhaitable d’en avoir plusieurs ! Un acteur est bien plus un rôle qu’une
personne physique.

 Voilà, nous avons nos acteurs. Par contre, il en manque un, qui n’a pas été
clairement exprimé par Mr El filali

 Aujourd’hui, on n’imagine mal un site commercial sans paiement en ligne.


Même si le texte ne le mentionne pas, il faut évidemment le proposer au client.

 Pour cela, il nous faudra donc un échange avec un système externe : le


système bancaire, par exemple, Paypal ou un autre. Voilà, nous venons
d’identifier un acteur secondaire.

N.Berbiche EST - Salé 18

9
27/09/2018

Etude de cas: diagramme de contexte

à gauche
à droite

Diagramme de contexte

N.Berbiche EST - Salé 19

Etude de cas: étape 2 - décomposition en package

 Si les parties ne sont pas évidentes à voir au départ. On peut


réaliser le diagramme des cas d’utilisation pour le logiciel complet.
Le diagramme risque de devenir énorme, mais très souvent, on
constate alors des groupes de cas d’utilisation qui ont un lien. Il
suffit alors de revenir un petit peu en arrière afin de faire la
décomposition en packages. on fait de l’itération.

 Le but ici, est de ne pas réaliser des diagrammes énormes qui


deviendraient très vite illisibles. On décompose donc le logiciel à
développer en plusieurs packages, dès que possible.

N.Berbiche EST - Salé 20

10
27/09/2018

Etude de cas: étape 2 - décomposition en package

 Pour notre projet de boutique en ligne, on va essayez


d’identifier des parties bien distinctes parmi les
fonctionnalités de notre site.

 Pour cela, on se pose cette question : « Est-ce que le


logiciel comporte des parties différentes qui pourraient
être analysées séparément ?

N.Berbiche EST - Salé 21

Etude de cas: étape 2 - décomposition en package

Pour ce cas d’étude, il y a deux parties distinctes :

 La partie « Gestion de l’achat » qui contiendrait l’achat à


proprement parler, la préparation de la commande , la vérification
des remarques et problèmes liés à l’achat en ligne.

 La partie « Gestion administrative », incluant :


- les tâches liées au catalogue : ajouter ou retirer un produits,
modifier le produit, etc.
- les vérifications des ventes : chiffre d’affaires et produits les plus
vendus par exemple.

N.Berbiche EST - Salé 22

11
27/09/2018

Etude de cas: étape 2 - décomposition en package

 Nous aurons donc deux packages. Un package est représenté sous forme
de dossier

Les packages
du système

 Le but étant de trouver des parties qui regroupent des fonctionnalités qui ont
un lien ou qui font partie d’une même « famille » et que l’on peut analyser
séparément.

 On essaye autant que possible de trouver des parties qui n’ont pas trop de
liens entre elles.

N.Berbiche EST - Salé 23

Etude de cas: étape 2 - décomposition en package

 Il ne faut pas faire l’erreur de décomposer le


système en fonction des acteurs.

 Un package (ou une partie) peut être utilisé


par plusieurs acteurs !

 Il n’est donc pas utile de faire des packages


« client », « livraison », « technicien »,
«administration» et « directeur ».

N.Berbiche EST - Salé 24

12
27/09/2018

Etude de cas: diagramme de package

 Pour réaliser le diagramme de packages, on met en évidence les


acteurs qui interviennent dans chacun de ces packages.

 Pour cela, on représente au centre le Système, qui comprend les


deux packages que nous avons trouvés : la gestion des achats et la
Gestion administrative. Autour de cela, nous devons donc relier les
acteurs principaux et secondaires au package correspondant

 Ici, le Client, le Commercial, la Livraison et le Technicien sont les


acteurs principaux, et le système bancaire est l’acteur secondaire du
package Gestion des achats.

 L’administration et le directeur sont les acteurs principaux du


package Gestion administrative.
 On verra les relations entre les package plus tard dans le cours
suivants
N.Berbiche EST - Salé 25

Etude de cas: diagramme de package

N.Berbiche EST - Salé 26

13
27/09/2018

Etude de cas: étape3 – les cas d’utilisation

 Maintenant, il s’agit de définir plus en détail les besoins de chaque


acteur dans ces deux packages, en répondant à ces questions : QUI
devra pouvoir faire QUOI grâce au logiciel ? Par exemple, que
souhaite faire le technicien sur le site ? Que souhaite faire le client ?
Etc.

 Les cas d’utilisation sont les fonctionnalités ou lots d’actions que


devront réaliser les acteurs.

 Les acteurs principaux qui sont liés à un package auront besoin de


cette partie du logiciel pour réaliser une ou plusieurs lots d’actions.
Ces lots d’actions sont le contenu de la boîte « package ».

N.Berbiche EST - Salé 27

Etude de cas: étape3 – les cas d’utilisation

 Un cas d’utilisation est une fonctionnalité dont certains acteurs


principaux ont besoin. Cette fonctionnalité correspond à un lot
d’action

 Le diagramme des cas d’utilisations met donc en évidence de


quelle façon les acteurs utiliseront le logiciel : QUI doit pouvoir faire
QUOI ?

 L'ensemble des cas d’utilisations décrit les objectifs (les


fonctionnalités) du système.

N.Berbiche EST - Salé 28

14
27/09/2018

les cas d’utilisation

 Les cas d’utilisations sont


représentés par des
ellipses avec le nom des
cas d’utilisation à l’intérieur

 les cas d’utilisation


principaux sont liés aux
acteurs qui en ont besoin.
Ils détaillent les
diagrammes de packages.

Exemple de diagramme
de cas d’utilisation

N.Berbiche EST - Salé 29

Etude de cas: diagramme des cas d’utilisation

 Pour notre étude de cas, on va se concentrer


sur le package «Gestion des achats » pour
en réaliser le diagramme des cas
d’utilisation.

 Il faut donc identifier toutes les fonctionnalités


dont les différents acteurs concernés par le
package auront besoin.

 Dans notre projet de réalisation d’une


boutique en ligne, nous indiquons qu’un client
devra pouvoir utiliser le site pour consulter le
catalogue des produits. Nous pouvons en Diagramme de cas d’utilisation,
déduire que « Consulter le catalogue des package « Gestion des achats » v1
produits » est un cas d’utilisation.

N.Berbiche EST - Salé 30

15
27/09/2018

Etude de cas: diagramme des cas d’utilisation

 Un cas d’utilisation n’est pas


forcément lié à un seul acteur.

 Nous pouvons indiquer qu’un


commercial devra également pouvoir
consulter le catalogue des produits
(par exemple, pour montrer des
caractéristiques d’un produit lors
d’une visite chez son client) en
reliant cet acteur au même cas
d’utilisation

Diagramme de cas d’utilisation, package


« Gestion des achats » v2

N.Berbiche EST - Salé 31

Etude de cas: diagramme des cas d’utilisation

 Vous devez identifier les autres fonctionnalités liées à chacun des acteurs
du site? Pour rappel: il s’agit du : Client; Commercial; Livraison; Technicien

 En observant attentivement la demande de notre client, Monsieur El filali,


nous pouvons noter les besoins suivants :
 Le client souhaite… - Consulter le catalogue de produits
- Enregistrer un achat
 Le commercial doit pouvoir…- Consulter le catalogue de produits
- Enregistrer un achat
 La livraison (ou les membres du service) souhaite(nt)…Préparer une
livraison
 Le technicien souhaite…Consulter une remarque ou problème

N.Berbiche EST - Salé 32

16
27/09/2018

Etude de cas: diagramme des cas d’utilisation

Pour le package
«Gestion des
achats», on a une
version de
diagramme de cas
d’utilisation un peu
plus complète

N.Berbiche EST - Salé 33

Etude de cas: diagramme des cas d’utilisation

 Il nous manque encore un


élément.

 Dans le diagramme de
packages, on avait illustré
un lien entre le package
«Gestion des achats» et le
système externe qui est le
système bancaire.

 Il faut maintenant lier ce


système externe au cas
d’utilisation qui en a besoin.
Par conséquent, le cas
d’utilisation «Enregistrer
un achat».
N.Berbiche EST - Salé 34

17
27/09/2018

Récapitulatif

Une partie importante dans l’analyse des besoins a été réalisé

Nous avons :
 défini le contexte du futur logiciel, en identifiant les
différents acteurs (1) ;

 décomposé le système en packages, c’est-à-dire les


familles de fonctionnalités (2) ;

 illustré les fonctionnalités principales pour un des


packages, grâce aux cas d’utilisation (3).

N.Berbiche EST - Salé 35

Récapitulatif des 3 diagrammes réalisés

N.Berbiche EST - Salé 36

18
27/09/2018

Les cas d’utilisations internes

 Les cas d’utilisation que nous avons découvert précédemment


sont directement liés à un acteur et sont appelés des « cas
d’utilisation principaux ». On y décrit ce qu’un utilisateur doit
pouvoir faire grâce au logiciel à développer. On parle donc les
fonctionnalités principales du logiciel à développer.

 Chacun de ces cas d’utilisation nécessitera un certain nombre


d’actions. Il arrive que l’on doive regrouper certaines actions dans
un ou plusieurs cas d’utilisation complémentaires qui ne sont pas
directement liés à un acteur. On parle alors d’un cas d’utilisation
interne.

 Les cas d’utilisation principaux sont complétés par les cas


d’utilisation internes.

N.Berbiche EST - Salé 37

Les cas d’utilisations internes

 Les cas d’utilisation internes sont


reliés au cas d’utilisation initial
par des relations stéréotypées
de type «include» ou «extend»,
ou par une relation de
généralisation.

 Les cas d’utilisation internes


seront indiqués dans le
diagramme de cas d’utilisation.

 La particularité de ces cas


d’utilisation internes réside dans
le fait qu’ils ne seront pas
directement liés aux acteurs,
mais aux cas d’utilisation qui en
ont besoin
N.Berbiche EST - Salé 38

19
27/09/2018

Les cas d’utilisations interne

 Les généralisations peuvent se faire au niveau des acteurs et/ou au


niveau des cas d’utilisation.

 Une relation « include » permet d’indiquer qu’un cas d’utilisation a


toujours besoin du cas d’utilisation lié. Il contient toujours les actions
du cas d’utilisation lié sous forme de fragments de son propre
comportement. La relation pointe vers le cas d'utilisation à
inclure.

 Une relation «extend» c’est une relation qui est soumise à une
condition. Le cas d’utilisation initial (cas d’utilisation à étendre)
n’utilisera les actions du cas d’utilisation lié que dans certaines
circonstances. On doit toujours expliciter la condition qui doit être
rencontrée pour que le cas d’utilisation lié soit utile. Cette relation
pointe vers le cas d'utilisation à étendre.

N.Berbiche EST - Salé 39

Relation de généralisation

 La généralisation peut être indiquée à deux niveaux :


 au niveau des acteurs ;
 au niveau des cas d’utilisation principaux

 Un cas d’utilisation parent représente une séquence de


comportements générale.

 Les cas d’utilisation enfants spécialisent le parent en insérant des


étapes supplémentaires ou en affinant certains étapes

 La généralisation d'un cas d'utilisation se présente par un trait allant


du cas d'utilisation enfant vers le cas d'utilisation parent, équipé
d'une flèche pointant vers la terminaison parent.

N.Berbiche EST - Salé 40

20
27/09/2018

Etude de cas: la création d’une boutique en ligne

N.Berbiche EST - Salé 41

Généralisation des acteurs

 Regardons le diagramme
de package « Gestion des
achats» dans le détail. On
constate très vite qu’au
niveau des acteurs « Client
» et « Commercial », les
cas d’utilisation « Consulter
catalogue produits » et «
Enregistrer un achat »
s’entrecroisent.
 Il faut éviter les liens qui
s’entrecoupent, car cela
devient vite illisibles
lorsqu’il y a beaucoup de
cas d’utilisation. Alors, Diagramme de cas d’utilisation du package «Gestion des
comment remédier à ces achats» v4 (détail)
liens qui s’entrecoupent?
N.Berbiche EST - Salé 42

21
27/09/2018

Généralisation des acteurs

 La notion de généralisation au niveau de certains acteurs permet de


remédier aux problèmes de liens qui s’entrecoupent

 Cela se justifie si plusieurs acteurs ont besoin d’un ou de plusieurs


cas d’utilisation communs et qu’ils ont également besoin de cas
d’utilisation spécifiques.

On utilise alors :
 un acteur générique (parent) qui est lié aux cas d’utilisations
communs ;

 des acteurs spécialisés (enfant) qui sont liés à des cas


d’utilisation spécifiques (enfants)

N.Berbiche EST - Salé 43

Généralisation des acteurs

 On indique qu’un acteur est la


généralisation d’un autre en dessinant une
flèche à pointe fermée allant de l’acteur
spécialisé vers l’acteur principal.

 Dans notre étude de cas, on constate que


deux acteurs ont les mêmes cas
d’utilisation. Pour indiquer cela, nous
créons un nouvel acteur générique appelé
« Acheteur », dont « Client » et «
Commercial » sont des spécialisations.
Nous pouvons alors relier l’acteur
générique aux cas d’utilisation « Consulter
catalogue produits » et « Enregistrer un Diagramme illustrant la
spécialisation d’un acteur
achat ».

N.Berbiche EST - Salé 44

22
27/09/2018

Généralisation des acteurs

Diagramme de cas d’utilisation, package « Gestion des achats » v5

N.Berbiche EST - Salé 45

Les cas d’utilisations à inclure

 On s’intéresse au cas d’utilisation «Enregistrer un achat» du


package «Gestion des achats» . En détaillant les actions au sein de
cette fonctionnalité, on réalise qu’un acheteur qui enregistre un achat
doit forcément constituer un panier.

 La constitution du panier nécessitera plusieurs séquences d’actions :


 Une recherche de produits selon une catégorie ou un nom ;
 La consultation de la fiche produit ;
 La validation d’un produit à ajouter au panier ;
 etc.

N.Berbiche EST - Salé 46

23
27/09/2018

Les cas d’utilisation à inclure

 Pour le cas d’utilisation «Enregistrer un achat», réfléchissons aux


actions ou lots d’actions que doit faire le client ou que doit faire le
commercial.

Le client doit faire: Le commercial doit faire:


1. S’authentifier 1. S’authentifier
2. Sélectionner le client pour lequel on réalise
2. Constituer un panier
l’achat
3. Saisir les informations de livraison 3. Constituer un panier

4. Enregistrer le règlement de l’achat 4. Saisir les informations de livraison

5. Enregistrer le règlement de l’achat

 On remarque que dans les deux cas de figures , il y a l’action


Constituer un panier. Pour cela nous allons introduire un nouveau
cas d’utilisation, appelé «Constituer panier».

N.Berbiche EST - Salé 47

Les cas d’utilisations à inclure

 Le cas d’utilisation
«Constituer panier»
sera toujours nécessaire
pour la fonctionnalité
«Enregistrer un achat ».
 Le nouveau cas
d’utilisation interne sera
lié au cas d’utilisation
principal «Enregistrer un
achat » par la relation
«Include ».
 Cette relation est
représentée par une
flèche en pointillé allant
du cas d’utilisation
principal vers le cas
d’utilisation interne.
N.Berbiche EST - Salé 48

24
27/09/2018

Les cas d’utilisations à inclure

 Une relation « include » est utilisée pour indiquer que le cas d’utilisation
source (départ de la flèche) contient TOUJOURS le cas d’utilisation
inclus.

 Dans la figure précédente, le cas d’utilisation source « Enregistrer un


achat » contiendra TOUJOURS le cas d’utilisation «Constituer un panier»

 Pour représenter la relation d’inclusion, on dessine une flèche en pointillé


partant du cas d’utilisation principal vers le cas d’utilisation interne.
Puis, on indique le stéréotype « include » sur la flèche .

N.Berbiche EST - Salé 49

Le diagramme des cas d’utilisation du package


«Gestion des achats »

N.Berbiche EST - Salé 50

25
27/09/2018

Le diagramme des cas d’utilisation du package «Gestion des


achats »

 Dans cette version du diagramme, le cas d’utilisation «Enregistrer un


achat » a été complété par des cas d’utilisation internes, qui
permettent d’être plus précis. L’acteur secondaire « Système
bancaire » est maintenant lié au cas d’utilisation «Enregistrer un
règlement ».

 On remarque qu’il y a une relation, de type « Extend » entre le cas


d’utilisation « Enregistrer un achat » et « Sélectionner un client ».

N.Berbiche EST - Salé 51

La relation extend

 La relation «extend» est utilisée pour indiquer que le cas d’utilisation


source (à l’origine de la flèche) n’est pas toujours nécessaire au
cas d’utilisation principal, mais qu’il peut l’être dans certaines
situations. On doit alors préciser la condition qui fera que le cas
d’utilisation en «extend» est nécessaire.

 Pour réaliser l’achat, avant de constituer le panier, le commercial


devra sélectionner le client pour lequel il effectue l’achat. En
revanche, l’acteur client n’aura pas besoin de le faire car il sera déjà
identifié. Par conséquent, le cas d’utilisation interne « Sélectionner le
client » n’est pas une action obligatoire au cas d’utilisation principal
«Enregistrer un achat», on peut donc utiliser la relation « extend ».

N.Berbiche EST - Salé 52

26
27/09/2018

La relation extend

 La relation « extend » est représentée par une flèche en pointillé


portant le stéréotype « extend » au dessus. Elle part du cas
d’utilisation interne vers le cas d’utilisation principal.

 Dans une relation « extend », il faut toujours définir la condition, où


cette relation peut avoir lieu. Pour indiquer cela, il faut ajouter une
ligne « extension points » au cas d’utilisation principal et définir la
condition « EXT ».

 le cas d’utilisation «Sélectionner un client» est une relation «extend»


du cas d’utilisation principal «Enregistrer un achat». Cette action
n’est possible qu’à condition que l’acteur soit le «Commercial», et
non pas le « Client ».

N.Berbiche EST - Salé 53

Le diagramme des cas d’utilisation du package


«Gestion des achats » v8

N.Berbiche EST - Salé 54

27
27/09/2018

Affinement du diagramme de package

 Le cas d’utilisation « S’authentifier » peut devenir un package à lui


seul.
Pourquoi?

Parce qu’il sera nécessaire pour tous les cas d’utilisation principaux.
Il sera bien nécessaire de vérifier que l’acteur qui souhaite utiliser
une fonctionnalité de notre logiciel est bien connu et habilité à utiliser
la fonctionnalité en question.

Par exemple :
seul un utilisateur de type « Livraison » devra avoir accès à la
fonctionnalité « Préparer livraison ». Et le package « Gestion
administrative » aura également besoin de ce cas d’utilisation. On
peut donc dans ce cas créer un package spécifique à « Authentifier».

N.Berbiche EST - Salé 55

Diagramme de package modifié

N.Berbiche EST - Salé 56

28
27/09/2018

Le diagramme des cas d’utilisation du package


«Gestion des achats » v9

N.Berbiche EST - Salé 57

Généralisation des cas d’utilisation

Considérons les actions ou lots d’actions du cas d’utilisation «Enregistrer un


achat»:
Le client doit… Le commercial doit…
1. S’authentifier 1. S’authentifier
- soit en se connectant - en se connectant
- soit en s’inscrivant comme nouveau
client 2. Sélectionner le client pour lequel on réalise l’achat
2. Constituer un panier
- sélectionner le produit
- valider le panier 3. Constituer un panier
3. Saisir les informations de livraison
- sélectionner le produit
- valider le panier
4. Saisir les informations de livraison 5. Enregistrer le règlement de l’achat
5. Enregistrer le règlement de l’achat - soit par carte bancaire
- par carte bancaire - soit par chèque
N.Berbiche EST - Salé 58

29
27/09/2018

Généralisation des cas d’utilisation

Considérons le cas d’utilisation «Enregistrer un


règlement»:
 Pour le client: «Enregistrement règlement CB»
 Pour le commercial:
 « Enregistrement règlement par chèque »
 «Enregistrement règlement CB»

Il y a deux variantes du cas d’utilisation


«Enregistrement règlement », donc deux nouveaux
cas d’utilisation « Enregistrement règlement par
chèque » et «Enregistrement règlement CB» sont
créés, ce sont des spécialisations de
«Enregistrement règlement ».

Le cas d’utilisation « Enregistrement règlement »


est le cas général

N.Berbiche EST - Salé 59

Généralisation des cas d’utilisation

 Dans une généralisation des cas d’utilisations, les cas d’utilisation


spécialisés sont des versions différentes du cas d’utilisation
générique. Ils ont chacun un déroulement spécifique nécessitant
plusieurs actions.
Le cas d’utilisation «Enregistrement Le cas d’utilisation «Enregistrement
règlement CB» comprendra très règlement chèque» pourrait contenir
probablement aussi les actions suivantes :
1. le choix du type de carte (visa,
Mastercard,…) ; 1. la saisie de la banque et du guichet ;
2. la saisie du numéro de la carte ; 2. la saisie du numéro de chèque ;
3. la saisie de la date de validité ; 3. la saisie de la date de réception du
4. la saisie du cryptogramme ; chèque.
5. l’envoi des informations au système
bancaire ;
6. la réception de la réponse du
système bancaire et le traitement du
règlement.
N.Berbiche EST - Salé 60

30
27/09/2018

Généralisation des cas d’utilisation

 La généralisation de cas d’utilisation est représenté par une


flèche partant du cas d’utilisation spécialisé vers le cas
d’utilisation général et dont la pointe de la flèche se termine
par un triangle vide

 l’acteur « Système bancaire » n’est utile que dans un des


deux cas. Cet acteur n’interviendra que pour l’action «
Enregistrement règlement CB » car seul pour les CB, cet
acteur secondaire vérifiera l’exactitude des informations
fournies.

N.Berbiche EST - Salé 61

Le diagramme des cas d’utilisation du package


«Gestion des achats » v10

N.Berbiche EST - Salé 62

31
27/09/2018

Récapitulatif – 2ème partie

 Les cas d’utilisation principaux sont complétés par des cas d’utilisation
internes. Les cas d’utilisation internes sont des précisions d’autres cas
d’utilisation.
 Les cas d’utilisation internes sont reliés au cas initial par des relations
stéréotypées de type « include » ou « extend », ou par une relation de
généralisation.
 Les généralisations peuvent se faire au niveau des acteurs et/ou au
niveau des cas d’utilisation.
 Une relation « include » permet d’indiquer qu’un cas d’utilisation a
toujours besoin du cas d’utilisation lié.
 Une relation « extend » c’est une relation qui est soumise à une condition.
Le cas d’utilisation initial n’utilisera les actions du cas d’utilisation lié que
dans certaines circonstances. On doit toujours expliciter la condition qui
doit être rencontrée pour que le cas d’utilisation lié soit utile.

N.Berbiche EST - Salé 63

Récapitulatif – 2ème partie

N.Berbiche EST - Salé 64

32
27/09/2018

Références

1. Débutez l'analyse logicielle avec UML-


openclassrooms.com/courses/debutez-l-analyse-logicielle-avec-uml
- Carina Roels

2. UML2 par la pratique – Pascal Roques

3. Introduction à UML 2 - Eric Cariou

4. UML, Le langage de modélisation unifié - Stéphane Lopes -


stephane.lopes@prism.uvsq.fr

5. cours UML – Naoual Berbiche – version 2012

N.Berbiche EST - Salé 65

33