Chap2 Diagrammes UML Présentant L'analyse Des Besoins Des Utilisateurs (2018)

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.
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 ?
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?
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?
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 ? »
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.
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
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.
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.
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.
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
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.
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
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 ?
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
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.
9
27/09/2018
Etude de cas: diagramme de contexte
à gauche
à droite
Diagramme de contexte
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.
10
27/09/2018
 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 ?
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.
11
27/09/2018
 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.
 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 ».
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
Etude de cas: diagramme de package
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 ».
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.
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
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.
15
27/09/2018
 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
 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
16
27/09/2018
Pour le package
«Gestion des
achats», on a une
version de
diagramme de cas
d’utilisation un peu
plus complète
 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».
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).
Récapitulatif des 3 diagrammes réalisés
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.
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
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.
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.
20
27/09/2018
Etude de cas: la création d’une boutique en ligne
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?
21
27/09/2018
 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)
 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 ».
22
27/09/2018
Diagramme de cas d’utilisation, package « Gestion des achats » v5
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.
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».
 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.
24
27/09/2018
 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 .
Le diagramme des cas d’utilisation du package

«Gestion des achats »
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 ».
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 ».
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 ».

«Gestion des achats » v8
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».
Diagramme de package modifié
28
27/09/2018

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
29
27/09/2018
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
 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.
30
27/09/2018
 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.

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.
Récapitulatif – 2ème partie
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
33

Chap2 Diagrammes UML Présentant L'analyse Des Besoins Des Utilisateurs (2018)

Încărcat de

Informații document

Titlu original

Drepturi de autor

Formate disponibile

Partajați acest document

Partajați sau inserați document

Opțiuni de partajare

Vi se pare util acest document?

Este necorespunzător acest conținut?

Drepturi de autor:

Formate disponibile

Chap2 Diagrammes UML Présentant L'analyse Des Besoins Des Utilisateurs (2018)

Încărcat de

Drepturi de autor:

Formate disponibile

27/09/2018

Chap2: Diagrammes UML présentant

Cours: Modélisation avec UML

 Etapes de l’analyse des besoins

 Diagramme des cas d’utilisations

 Les cas d’utilisations internes

N.Berbiche EST - Salé 2

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

N.Berbiche EST - Salé 3

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

N.Berbiche EST - Salé 4

Etapes de l’analyse des besoins

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

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

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

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

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

N.Berbiche EST - Salé 6

Etapes de l’analyse des besoins - suite

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

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

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

N.Berbiche EST - Salé 7

Les diagrammes UML nécessaires à l’analyse des

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

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

N.Berbiche EST - Salé 8

Les différents packages

Les différents diagrammes qui

N.Berbiche EST - Salé 9

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 ?

N.Berbiche EST - Salé 10

Etude de cas - suite

Pourquoi nous contacte-t-il ?

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

N.Berbiche EST - Salé 11

Etude de cas - suite

 Le service des livraisons doit pouvoir consulter les commandes pour

N.Berbiche EST - Salé 12

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

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

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

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

Le système, correspond à une

N.Berbiche EST - Salé 13

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

Deux types d’acteurs, nous distinguons :

N.Berbiche EST - Salé 14

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

Etude de cas: étape1- le contexte

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

 Relisez-bien les demandes de Monsieur El filali.

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

N.Berbiche EST - Salé 16

Etude de cas: les acteurs

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