Chapitre I: Analyse fonctionnelle

11

PLAN PLAN

Diagramme de cas d’utilisation

•

17R

Relations

 Relation acteur-cas d’utilisation

 Relation d’association

 Relations cas d’utilisation-cas d’utilisation

 Dépendances explicitées par des stéréotypes

 Généralisation/spécialisation

 Relation acteur-acteur

 Généralisation/spécialisation

12

PLAN PLAN

Diagramme de cas d’utilisation

• 18 Relation  Cas d’utilisation – Acteur : relation d’association

Chemin de communication entre un acteur et un cas

Est représentée par un trait continu

 Cas d’utilisation – Acteur secondaire

Ajout du stéréotype « secondary » sur la relation

13

Diagramme de cas d'utilisation

Relation  Inclusion : le cas A inclut le cas B (B est une partie obligatoire de A).

 Extension : B étend le cas A (B est une partie optionnelle de A).

 Généralisation : le cas A est une généralisation du cas B (B est une sorte de A).

14

PLAN PLAN

Diagramme de cas d’utilisation

•

19

Relation  Cas d’utilisation - Cas d’utilisation : Inclusion

 Lorsqu’un cas d’utilisation a besoin de l’aide d’un autre cas  Permet d’identifier un sous-ensemble commun à plusieurs cas

C1 utilise C2 ⇒ toute activation de C1 entraîne une activation de C2

Exemple :

15

PLAN PLAN

Diagramme de cas d’utilisation

Relation

 Cas d’utilisation - Cas d’utilisation : Extension

 Un cas d’utilisation peut avoir besoin d’un autre cas d’utilisation.  L’extension permet d’identifier des comportements alternatifs optionnels.

C2 étend C1 ⇒ C2 est une façon particulière de réaliser C1

Exemple :

16

PLAN PLAN

Diagramme de cas d’utilisation

Relation

 Cas d’utilisation - Cas d’utilisation : Extension

Il est possible de définir un point d’extension: indique le moment/ la condition où intervient l’extension.

17

PLAN PLAN

Diagramme de cas d’utilisation

•

22

Relation

 Cas d’utilisation - Cas d’utilisation : Généralisation

 L’héritage est un concept fondamental en programmation, en analyse et en conception orientée

objet.

 Cette idée appliquée aux acteurs et aux cas d’utilisation est appelée généralisation/spécialisation

 Le cas général est considéré comme un cas abstrait

 Exemple :

18

PLAN PLAN

Diagramme de cas d’utilisation

•

23

Relation  Acteur – Acteur

 La seule relation possible entre deux acteurs est la généralisation/spécialisation

 Un acteur A est une généralisation d’un acteur B si l’acteur A peut être substitué par l’acteur B. Dans

ce cas, tous les cas d’utilisation accessibles à A le sont aussi à B, mais l’inverse n’est pas vrai.

 Le symbole de la flèche pointe vers l’acteur le plus général.

 Exemple :

19

PLAN PLAN

Diagramme de cas d’utilisation

Exemple

20

PLAN PLAN Etude de cas : Vente en ligne des ouvrages

Une société désire développer un site de vente de livres. La principale fonction offerte par le site est la recherche d'ouvrages. Le site doit offrir plusieurs méthodes de recherche : par titre, par N°ISBN ou par auteur. Le client doit pouvoir aussi accéder aux classements des meilleures ventes de livres. Il peut s’il le souhaite imprimer le classement. Le client a la possibilité de passer la commande en ligne. Le client effectue son paiement sur le web via sa carte bancaire. Le client doit pouvoir ensuite suivre ses commandes récentes et les détails de livraisons. Evidemment, différentes fonctionnalités.

le client doit s’authentifier pour pouvoir accéder aux

21

PLAN PLAN Etude de cas : Vente en ligne des ouvrages

« secondary»

22

PLAN PLAN Description textuelle d’un cas d’utilisation

 Description d’un cas d’utilisation.  Intérêt.  Scénarii d’un cas d’utilisation  Parties essentielles.

23

PLAN PLAN Description textuelle d’un cas d’utilisation

Description d’un cas d’utilisation

24

PLAN PLAN Description textuelle d’un cas d’utilisation

Intérêt

 Chaque cas d’utilisation doit être décrit en détail: description textuelle  Description utile:

 langue naturelle mais structurée compréhensible par les utilisateurs.  vocabulaire précis pour que les analystes et les concepteurs puissent s’en servir pour construire le programme.

25

PLAN PLAN Description textuelle d’un cas d’utilisation

28 scénarii d’un cas d’utilisation

 Un cas d’utilisation doit avoir un début et une fin clairement identifiés.  Chaque unité de description de séquence d’actions et d’échange de messages

entre un acteur et le système est appelée enchaînement.

 Un scénario représente une succession d’enchaînements qui s’exécute du

début à la fin du cas d’utilisation.

 Chaque résultat possible de l’exécution d’un cas d’utilisation représente un

scénario.

26

PLAN PLAN Description textuelle d’un cas d’utilisation

29 scénarii d’un cas d’utilisation

 Chaque cas d’utilisation possède :

 Un (et un seul) scénario nominal (se termine sans erreurs).  Zéro ou plusieurs scénarios alternatifs.  Zéro ou plusieurs scénarios d’exception (échec).

Début

Légende : ------ : scénario nominal ------ : scénario alternatif ------ : scénario d’échec

Echec

Fin

Illustration des scénarii d’un cas d’utilisation

27

PLAN PLAN

Description textuelle d’un cas d’utilisation

Parties essentielles

32

Sommaire d’identification. Description des enchainements. Spécification non fonctionnelle (optionnelle).

28

PLAN PLAN Description textuelle d’un cas d’utilisation

33

 Sommaire d’identification

Titre : Fonctionnalité rendue par le cas d’utilisation (CU). Résumé : Une description résumée permettant de comprendre

l’intention principale de ce cas d’utilisation.

Acteurs : Lister les acteurs et mentionner s’ils sont principaux

ou secondaires.

Date de création : Date de création de la description textuelle. Date de mise à jour : Date de mise à jour de la description

textuelle

Version : Le numéro de la version de la description textuelle Responsable : Le nom du responsable de la description

textuelle

29

PLAN PLAN Description textuelle d’un cas d’utilisation

34

 Description des enchainements

Pré-conditions : Ce qui doit être vérifié avant le déclenchement du cas

d’utilisation

Scénario nominal : Description du scénario nominal sous forme d’actions

(acteurs) et réactions (système)

Enchainements alternatifs : Description des scénarii alternatifs qui amènent le scénario nominal à une autre séquence de traitement et qui se termine de façon normale

Enchainements d’erreur : Description des scénarii d’exception qui décrivent

les cas d’erreurs

Post-conditions : ce qui est vrai après déroulement du cas d’utilisation

30

PLAN PLAN Description textuelle d’un cas d’utilisation

35

 Spécifications non fonctionnelles

Besoins d’IHM :

Expression de contraintes liées à l’interface

Contraintes non fonctionnelles :

Fréquences Volumétries QoS: Disponibilité, fiabilité, Performances Concurrence

31

PLAN PLAN

Etude de cas: vente des ouvrages en ligne

35 Une société désire développer un site de vente de livres. La principale fonction offerte par le site est la recherche d'ouvrages. Le site doit offrir plusieurs méthodes de recherche : par titre, par N°ISBN ou par auteur. Le client doit pouvoir aussi accéder aux classements des meilleures ventes de livres. Il peut s’il le souhaite imprimer le classement. Le client a la possibilité de passer la commande en ligne. Il dispose d’un panier virtuel à travers lequel il peut ajouter des ouvrages. La commande est enregistrée lorsque le client valide son panier d’achat. Après avoir rempli son panier, le client doit pouvoir accéder au formulaire de commande dans lequel il saisit ses coordonnées et les informations nécessaires au paiement. Le client effectue son paiement sur le web via sa carte bancaire. Le client doit pouvoir ensuite suivre ses commandes récentes et les détails de livraisons en donnant son mot de passe. Evidemment, le client doit s’authentifier pour pouvoir accéder aux différentes fonctionnalités.

32

PLAN PLAN

Etude de cas: vente des ouvrages en ligne

36 35

 Sommaire d’identification : Titre : Passer commande Résumé : Cas d’utilisation permettant à un client de passer une

commande

Acteur : Client (principal), système d’autorisation (secondaire) Date création : 01/09/2015 Date dernière mise à jour : 07/09/2015 Version : 1.2

33

PLAN PLAN

Etude de cas: vente des ouvrages en ligne

37  Description des enchaînements : 35

 Pré-conditions :

Stock mis à jour

Client authentifié

 Scénario nominal :

Action acteur

1. Le client ajoute des ouvrages

Action système

2. Le client valide le panier

3. Le système enregistre la commande

4. Le client saisit ses coordonnées

5. Le client saisit ses informations de paiement

6. Le système d’autorisation valide le paiement

7. Le système met à jour le stock et confirme l’achat au client

34

PLAN PLAN

Etude de cas: vente des ouvrages en ligne

38  37 35

Enchaînements alternatifs :

 A1:Aucun ouvrage n'est sélectionné.

L'enchaînement A1 démarre au point 2 du scénario nominal.

 Le système signale au client qu'aucun ouvrage n'est sélectionné.



Le scénario nominal reprend au point 1.



Enchainements d’erreurs

 E1 : paiement non validé.

L'enchaînement E1 démarre au point 6 du flot nominal.







Le système relâche

le contenu du panier

:

les ouvrages contenus dans

le panier ne sont plus réservés.

 Le système signale le problème au client.

 Le cas d'utilisation se termine par un échec.



Post-condition :

 Les ouvrages vendus ne sont plus en stock.

35