Formation UML 2Titre -...

Ministère de l'Écologie, du Développement durable et de l’Énergie

TitreFormation UML 2Formation UML 2

Le diagramme de cas d'utilisation

Hervé DOMALAIN – CPII/DOSO/ED11 au 13 février 2014

- 2 -

Sommaire

Présentation sommaire du langage UML

Le diagramme de cas d’utilisation

✔ Première étape de construction d'un diagramme de CU : le diagramme de boundary

✔ Seconde étape de construction d'un diagramme de CU : le diagramme de CU initial

✔ Troisième étape de construction d'un diagramme de CU : le diagramme de CU optimisé

Comment décrire un cas d’utilisation ?

- 3 -

Contexte

- 4 -

La genèse d'UML

- 5 -

UML : un langage de modélisation

La traduction littérale de UML donne :

« langage unifié de modélisation » D’un projet d’unification de méthodes on est arrivé à un langage :

✔ Pour comprendre et décrire les besoins,

✔ Pour spécifier des systèmes simples ou complexes,

✔ Pour concevoir ou construire des solutions,

✔ Pour documenter un système d’information,

✔ Pour communiquer entre tous les niveaux d’une équipe projet... entre un client et un prestataire.

- 6 -

UML : un langage à usage général

Pour tous types de système : logiciel, matériel, organisationnel,

Pour tous domaines métier : gestion, ingénierie, télécoms,

Pour tous processus de développement : cascade, itératif.

- 7 -

Taxonomie des diagrammes UML 2

- 8 -

Sommaire







- 9 -

Positionnement du diagramme de cas d'utilisation

- 10 -

Problématique des cas d'utilisation

Les cas d’utilisation formalisent la spécification métier en langage naturel fournie en entrée.

Il faut décrire les fonctionnalités du point de vue de l’utilisateur.

Le système est considéré comme une boîte noire, ce qui implique :

✔ D'identifier le périmètre du système (ce qui existe dehors = les acteurs),

✔ De s’intéresser aux comportements externes visibles (ce qui doit être effectué par le système = cas d’utilisation).

- 11 -

La spécification informelle : point d’entrée des cas d’utilisation Exemple trivial de cahier des charges rédigé par une MOA :

✔ Un client, visitant le site Web d’une boutique électronique, peut obtenir de l’information (noms, descriptions, nombres d’unités en stock et prix unitaires) sur les produits disponibles.

✔ Lorsqu’un client décide d’acheter un produit, il l’ajoute en tant qu’article dans son panier. Il peut aussi indiquer la quantité de produits à acheter. Le nombre d’unités en stock de ce produit est réduit en conséquence.

✔ Le client peut aussi cliquer sur un lien pour voir les articles dans son panier. Dans ce cas, le prix total des articles sélectionnés jusque-là est calculé et affiché.

✔ Le client peut aussi enlever des articles de son panier et le nombre d’unités en stock de ce produit est augmenté en conséquence.

✔ Une fois ses achats complétés, le client transforme son panier en commande. Sont alors affichés : le numéro de la commande, la date et le coût total.

✔ Le client paye le contenu de son panier…

- 12 -

Sommaire







- 13 -

Première étape : identifier les acteurs

Un acteur interagit avec le système que l’on modélise : il a besoin d’échanger des informations avec ce système.

Chaque acteur possédant sa propre manière d’utiliser le système, il représente un rôle. On parle alors d’acteur humain.

Mais le système peut aussi communiquer avec un autre système d’information. On parle cette fois d’acteur non humain.

Attention de ne pas oublier les acteurs implicites non listés dans la spécification informelle.

- 14 -

Quels sont les acteurs identifiables dans le cahier des charges ?

- 15 -

Diagramme de boundary

Le diagramme ci-contre présente le système comme une boîte noire et les acteurs qui interagissent avec lui.

La limite externe du système, celle qui est « visible » par les acteurs, est représentée par le boundary (frontière en français).

Cette frontière délimite le périmètre cible du système d'information.

- 16 -

Sommaire







- 17 -

Seconde étape : identifier les cas d’utilisation candidats

Un cas d’utilisation correspond à une série d'étapes réalisées alternativement par un acteur particulier et un système d'information, produisant un résultat intéressant pour cet acteur.

Il spécifie les services que le système fournit à ses utilisateurs et les interactions acteurs-système (séquences d’interactions possibles entre un acteur initiateur et le système, pouvant faire intervenir d’autres acteurs).

Il définit un comportement du système sans révéler sa structure interne.

Un cas d’utilisation candidat se déduit directement du cahier des charges fourni en entrée.

Le premier diagramme de cas d’utilisation produit est une version non élaborée que l'on dénommera diagramme initial par la suite.

- 18 -

Quels sont les cas d'utilisation identifiables dans le cahier des

charges ?

- 19 -

Les cas d'utilisation candidats

Les CU sont mis en évidence dans le cahier des charges :✔ Un client, visitant le site Web d’une boutique électronique, peut obtenir

de l’information (noms, descriptions, nombres d’unités en stock et prix unitaires) sur les produits disponibles.

✔ Lorsqu’un client décide d’acheter un produit, il l’ajoute en tant qu’article dans son panier. Il peut aussi indiquer la quantité de produits à acheter. Le nombre d’unités en stock de ce produit est réduit en conséquence.

✔ Le client peut aussi cliquer sur un lien pour voir les articles dans son panier. Dans ce cas, le prix total des articles sélectionnés jusque-là est calculé et affiché.

✔ Le client peut aussi enlever des articles de son panier et le nombre d’unités en stock de ce produit est augmenté en conséquence.

✔ Une fois ses achats complétés, le client transforme son panier en commande. Sont alors affichés : le numéro de la commande, la date et le coût total.

✔ Le client paye le contenu de son panier…

- 20 -

Réf # Fonctionnalité

Ex 1.1 Obtenir de l’information sur les produits disponibles

Ex 1.2 Ajouter un produit en tant qu’article du panier

Ex 1.3 Voir les articles dans son panier

Ex 1.4 Enlever des articles de son panier

Ex 1.5 Transformer son panier en commande

Ex 1.6 Payer le contenu de son panier

Traçabilité des exigences fonctionnelles

Voici un exemple de matrice d’exigences fonctionnelles construite à partir des CU candidats du cahier des charges :

- 21 -

Diagramme de cas d'utilisation initial

- 22 -

Sommaire







- 23 -

Troisième étape : optimiser le diagramme de cas d’utilisation

Après avoir initialisé un diagramme avec les acteurs et les cas d’utilisation candidats, il convient :

✔ De mettre en évidence les cas d’utilisation implicites non définis dans les exigences, pour assurer l’exhaustivité du besoin fonctionnel, en utilisant les patterns de cas d’utilisation (cf. diapositive suivante),

✔ D’éviter la redondance de ces liens en utilisant l’héritage entre acteurs et/ou entre cas d’utilisation,

✔ D'associer les cas d’utilisation principaux et secondaires avec des dépendances de types « include » et « extend »,

✔ De s’assurer de la clarté et de la précision du nommage des cas d’utilisation (avec un verbe d’action à l’infinitif).

Quand le diagramme est lisible, la spécification est compréhensible.

- 24 -

Les patterns de cas d’utilisation

Deux patterns peuvent être appliqués pour optimiser le diagramme de CU :

✔ Le pattern « administrateur » suggère l’existence d’un acteur « administrateur » (ou gestionnaire) du système, en charge de la gestion des référentiels.

✔ Le pattern « gestion » permet, le cas échéant, de découpler un cas d’utilisation du type « Gérer… » en « Créer », « Modifier », Supprimer », « Annuler », « Lister », « Éditer », « Imprimer », « Consulter », « Rechercher », « Archiver », « Désarchiver »… Le niveau du découplage dépend de la complexité initiale du cas d’utilisation et de la granularité recherchée en sortie.

- 25 -

La relation de généralisation

Le cas d’utilisation enfant est une spécialisation du cas d’utilisation parent. Le cas d'utilisation parent est un CU abstrait car il n'est jamais directement instancié.

Ce type de relation est également applicable aux acteurs. Un acteur qui hérite d'un autre acteur « accède » alors à ses cas d'utilisation. L'héritage entre acteurs est transitif.

- 26 -

Notion de cas d’utilisation principaux et secondaires

Un cas d'utilisation permet de décrire une réalité selon différents niveaux :

✔ Niveau fonctionnalité :

• C'est l'objectif directement suivi par un acteur en interaction avec le système. Sa durée, de quelques dizaines de secondes à quelques dizaines de minutes, peut être réduite si le déclencheur est un acteur non humain.

• Exemples : S’inscrire à un module d'examen - Consulter un examen blanc - Calculer la note finale.

✔ Niveau sous-fonctionnalité :

• C’est un cas d'utilisation qui participe au bon déroulement ou complète les cas d'utilisation de niveau fonctionnalité.

• Exemples : S’identifier – Imprimer un examen blanc.

- 27 -

La relation d’inclusion

Cette relation est applicable entre un ou plusieurs CU principaux et un CU secondaire.

L'inclusion permet de définir des comportements partageables entre plusieurs cas d'utilisation (factorisation). Le CU source (principal) comprend le comportement du CU cible (secondaire).

L’inclusion est obligatoire : quand le CU source est instancié, le CU cible est obligatoirement instancié.

- 28 -

La relation d’extension

Cette relation est applicable entre un ou plusieurs CU principaux et un CU secondaire.

L'extension permet de définir des comportements partageables entre plusieurs cas d'utilisation (factorisation). Le CU source (secondaire) ajoute son comportement au CU cible (principal).

L’extension est optionnelle : quand le CU cible est instancié, le CU source est éventuellement instancié.

- 29 -

Diagramme de cas d'utilisation optimisé

- 30 -

Sommaire







- 31 -

Partir des principales fonctionnalités et se restreindre à la vision utilisateur.

Centrer son attention sur le scénario nominal. Préciser les parties prenantes et leurs intérêts. Utiliser des verbes au présent de l'indicatif et la

voie active. Le sujet doit être clairement localisable (en début

de phrase généralement). Rester concis et pertinent. Éviter les « si » et placer les comportements

alternatifs dans les extensions Signaler les cas d'utilisation secondaires qui sont

toujours représentés par la relation d'inclusion. Identifier le bon objectif. Signaler la portée. Laisser de côté l'interface utilisateur.

Les règles applicables

Un scénario décrit le déroulement d’une partie du cas d’utilisation. On parle aussi de chemin particulier au travers de la description abstraite et générale fournie par le CU.

Le scénario se décrit comme si l'on « racontait une histoire » : il alterne actions de l'acteur et réponses du système.

On distingue en général le scénario nominal (scénario typique de succès du CU), des scénarios alternatifs (autre cheminement que le scénario nominal conduisant au succès du CU) et des scénarios d'exception (autre cheminement que le scénario nominal conduisant à l'échec du CU).

Le format de présentation textuelle des cas d'utilisation est libre. Il est toutefois pertinent de respecter quelques règles (Alistair Cockburn, 2003) :

- 32 -

Modèle de fiche descriptive de cas d'utilisation

Titre Résumé Acteur(s) concerné(s) Description des enchaînements d'actions

✔ Pré-conditions✔ Scénario nominal✔ Scénario(s) alternatif(s)✔ Scénario(s) d’exception✔ Post-conditions

Besoins d’IHM Description des classes candidates Contraintes techniques (temps de réponse, fréquence,

confidentialité, concurrence, disponibilité, intégrité, …)

Informationsobligatoirespour l'analysedes besoins

Informationsobligatoirespour l'analysedes besoins

Informationscomplémentairespour la conceptionfonctionnelleet technique

Informationscomplémentairespour la conceptionfonctionnelleet technique

Les règles de gestionmétier doivent êtreréférencées dans letexte des scénarios

Les règles de gestionmétier doivent êtreréférencées dans letexte des scénarios

- 33 -

Exemple de fiche descriptive de cas d'utilisation

Titre : initialiser le panier. Résumé : initialiser son panier avec un article afin de passer sa commande. Acteur(s) concerné(s) : le client. Description des enchaînements d'actions :

✔ Pré-condition : le client a choisi un article.✔ Scénario nominal :

• 1. Le client sélectionne l'article (modèle et taille) et choisit une quantité.• 2. Le système vérifie que l'article est disponible.• 3. Le système vérifie que la quantité en stock est suffisante.• 4. Le système calcule le montant du panier (cf. RG xxxx) et affiche le panier.• 5. Le client valide son panier.

✔ 4a. Scénario alternatif : la quantité en stock est insuffisante.• 4a1. Le système indique la quantité disponible.• 4a2. Le client choisit la quantité voulue.• Retour à l’étape 3 du scénario nominal.

✔ 4b. Scénario d'exception : la quantité en stock n'est pas satisfaisante.• 4b1. Le système indique la quantité disponible.• 4b2. Le client abandonne son achat.• Sortie du cas d'utilisation.

✔ 5a. Scénario d'exception : le client sort du panier.• 5a1. Le client sort du panier pour continuer ses achats.• Sortie du cas d'utilisation.

✔ Post-condition : le client peut passer sa commande.

- 34 -

Représentation schématique des scénarios du CU

1 2 43

4a

4b5a

5

- 35 -

Le diagramme d'activités pour décrire un cas d'utilisation

Les étapes 4a1et 4b1 sont

mutualisées dans la même

activité.

Les étapes 4a1et 4b1 sont

mutualisées dans la même

activité.

Les étapes dela descriptiontextuelle sont

remplacées pardes activités.

Les étapes dela descriptiontextuelle sont

remplacées pardes activités.

- 36 -

Les règles de gestion métier

Les règles de gestion métier sont des formulations qui définissent les aspects métier impactant le comportement du système d'information.

Ces règles doivent être recensées, nommées, hiérarchisées et classées par domaine fonctionnel.

Elles doivent être référencées dans le texte des scénarios des cas d'utilisation.

Ministère de l'Écologie, du Développement durable et de l’Énergie

FIN

Formation UML 2Titre -...

Documents

Transcript of Formation UML 2Titre -...