Module 1Modéliser un projet web
Chapitre 2 sur 12
UML, les acteurs, les cas d'utilisation, les relations include, extend et généralisation, et la fiche textuelle d'un cas.
Objectifs
Avec ce chapitre, tu sauras…
<<include>>), d'extension (<<extend>>) et de généralisation ;Leçon 1
Le modèle accompagne tout le cycle de vie :
| Activité | Rôle du modèle |
|---|---|
| spécification des besoins | le système est vu comme une boîte noire ; on trace ses frontières et ses échanges avec l'extérieur (cas d'utilisation) |
| analyse | le modèle représente le système vu de l'intérieur, avec les concepts du métier (classes d'analyse : Livre, Client, Commande) ; il a une partie statique (structure) et une partie dynamique (comportement) |
| conception | le modèle correspond aux concepts informatiques (classes de conception, contrôleurs, interfaces) qui seront codés |
| Niveau | Diagrammes | Dans ce module |
|---|---|---|
| fonctionnel | diagramme de cas d'utilisation | chapitre 2 |
| structurel (statique) | classes, objets, composants, déploiement, paquetages, structures composites, profils | chapitre 3 (classes) |
| comportemental (dynamique) | activités, états-transitions, et les diagrammes d'interaction : séquence, communication, global d'interaction, temps | chapitres 4, 6 et 7 |
Vidéo · À regarder
FRDiagramme des Cas d'Utilisation : Cours Complet et Exercice Corrigé sur Astah UML
Prof. Fatimazahra BARRAMOU · YouTube
Leçon 2
Leçon 3
<<include>> | <<extend>> | |
|---|---|---|
| caractère | obligatoire : à chaque exécution | optionnel : sous condition |
| le cas de base fonctionne-t-il seul ? | non, il a besoin du cas inclus | oui |
Leçon 4
| Partie | Contenu |
|---|---|
| identification | nom (verbe à l'infinitif) ; objectif (résumé de l'intention) ; acteurs principaux et secondaires ; dates de création et de mise à jour ; responsable ; version |
| scénarios | préconditions (ce qui doit être vrai avant, tenu pour acquis) ; scénario nominal (tout se passe bien) ; scénarios alternatifs (variantes qui aboutissent) ; scénarios d'exception (erreurs qui font échouer) ; postconditions (ce qui est vrai après un succès) |
| exigences non fonctionnelles (optionnel) | performance, sécurité, ergonomie propres à ce cas ; on peut ajouter des captures de la maquette |
1UML est…
2Un acteur représente…
3« Valider le formulaire » est un mauvais nom de cas d'utilisation car…
4Le cas inclus avec <<include>> est exécuté…
5Dans <<extend>>, la flèche va…
6Un acteur secondaire se place de préférence…
7Ce qui doit être vrai avant le début du cas est…
8La généralisation se dessine avec…
L'essentiel du chapitre
<<include>> obligatoire, base → inclus ; <<extend>> optionnelle avec condition et point d'extension, extension → base ; généralisation (triangle vide) entre acteurs ou entre cas.Acteur
| Acteur principal | Acteur secondaire | |
|---|---|---|
| définition | celui pour qui le cas d'utilisation produit un résultat observable ; il déclenche souvent le cas | un participant sollicité pendant le cas, pour une information complémentaire ou un service |
| exemple dans « Passer commande » | l'Internaute | le Service de paiement (système bancaire), le Transporteur |
| position conseillée | à gauche du diagramme | à droite du diagramme |
Vidéo · À regarder
FRDiagramme des Cas d'Utilisation : Cours Complet et Exercice Corrigé sur Astah UML
Prof. Fatimazahra BARRAMOU · YouTube
| base → inclus |
| extension → base |
| usage | factoriser un comportement commun | isoler un comportement facultatif ou exceptionnel |
Vidéo · À regarder
FRDiagramme des Cas d'Utilisation : Cours Complet et Exercice Corrigé sur Astah UML
Prof. Fatimazahra BARRAMOU · YouTube
Une fiche bien écrite
Vidéo · À regarder
FRDiagramme des Cas d'Utilisation : Cours Complet et Exercice Corrigé sur Astah UML
Prof. Fatimazahra BARRAMOU · YouTube
UML (Unified Modeling Language) est un langage visuel standardisé pour spécifier, construire et documenter un système logiciel. Ce n'est pas une méthode (il ne dit pas dans quel ordre travailler) mais une notation commune. Il est né de la fusion de trois méthodes objet : Booch (Grady Booch), OMT (James Rumbaugh) et OOSE (Ivar Jacobson). L'OMG (Object Management Group) l'a adopté comme standard en novembre 1997 (UML 1.1) et en définit le métamodèle. La version actuelle est UML 2.5.1 (décembre 2017).
Le résumé annonce « treize types de diagrammes ». UML 2.0 en comptait treize ; depuis UML 2.2, le diagramme de profils s'y ajoute : UML 2.5 compte quatorze diagrammes. Et la frise du résumé date UML 2.5 de décembre 2017 : UML 2.5 est paru en 2015, la version de décembre 2017 est la 2.5.1.
Ce que tu vas voir (2 min) : les chapitres « Définition des diagrammes des cas d'utilisation », « Intérêt des diagrammes des cas d'utilisation ». La professeure définit le diagramme de cas d'utilisation et explique à quoi il sert avant de commencer la conception.
Le diagramme de cas d'utilisation (DCU) sert à la spécification des besoins. Il montre les interactions fonctionnelles entre les acteurs et le système étudié, du point de vue de l'utilisateur. Il répond à la question : qui utilise le système, et pour quoi faire ?
La démarche
Les acteurs
L'inclusion <<include>>
Le cas de base incorpore obligatoirement le comportement d'un autre cas, à chaque exécution. On l'utilise pour factoriser une fonctionnalité commune à plusieurs cas. La flèche pointillée va du cas de base vers le cas inclus.
@startuml
left to right direction
actor Internaute
rectangle "Librairie en ligne" {
usecase "Passer une commande" as A
usecase "Suivre sa commande" as B
usecase "S'authentifier" as C
}
Internaute -- A
Internaute -- B
A .> C : <<include>>
B .> C : <<include>>
@endumlL'extension <<extend>>
Le cas de base fonctionne tout seul ; un autre cas peut l'enrichir dans certaines conditions (comportement optionnel). La flèche pointillée va du cas qui étend vers le cas de base. Exemple du résumé : « Enregistrer un client » étend « Prendre une commande » : pendant la prise de commande, on enregistre le client seulement s'il est nouveau.
L'extension peut intervenir à un endroit précis du cas de base, le point d'extension : il porte un nom, inscrit dans un compartiment « points d'extension » du cas étendu. La condition est écrite dans une note attachée à la relation.
@startuml
left to right direction
actor Client
rectangle "Banque en ligne" {
usecase "Retirer de l'argent\n--\npoints d'extension :\nvérification du solde" as R
usecase "Vérifier le solde" as V
}
Client -- R
V .> R : <<extend>>
note right of V : condition : {montant > 200 DH}\npoint d'extension : vérification du solde
@endumlC'est la source d'erreur n° 1 : <<include>> part du cas de base (« Passer commande » inclut « S'authentifier ») ; <<extend>> arrive sur le cas de base (« Vérifier le solde » étend « Retirer de l'argent »). Astuce : la flèche part toujours du cas qui « fait l'action » du verbe : celui qui inclut, celui qui étend.
Le résumé écrit <<extends>> (avec un s) : le mot-clé UML est <<extend>>. De même, <<uses>> est l'ancien nom (UML 1.1) de <<include>>.
Le diagramme montre les grandes fonctions, mais pas le dialogue détaillé entre l'acteur et le système. On rédige donc une description textuelle de chaque cas, en trois parties.
Cas d'utilisation : S'authentifier
Acteurs : Administrateur et autres utilisateurs
Objectif : permettre à l'acteur de s'identifier par son login et son mot de passe
Précondition : la connexion avec le système est opérationnelle
Postconditions : l'acteur est authentifié ; la page d'accueil s'affiche
Scénario nominal
1. L'acteur ouvre l'application.
2. Le système affiche la page d'authentification.
3. L'acteur saisit son login et son mot de passe.
4. Le système vérifie l'existence des données.
5. Le système affiche la page d'accueil.
Scénarios alternatifs
4.a Login ou mot de passe non valide : le système affiche un message d'erreur ;
le scénario reprend au point 2.
4.b Champs obligatoires vides : le système affiche les champs à remplir ;
le scénario reprend au point 2.
Exigence non fonctionnelle
Au bout de 3 tentatives échouées, le système verrouille l'accès pour une durée limitée.À partir de ton cahier des charges (TP 1.5), dessine le diagramme de cas d'utilisation complet de la librairie Kitab : acteurs Visiteur, Client, Libraire, Administrateur, Service de paiement, Transporteur ; au moins dix cas ; au moins deux <<include>>, une <<extend>> avec sa condition et une généralisation. Rédige ensuite la fiche du cas « Passer une commande ».
« La plateforme de réservation d'un riad à Marrakech permet aux visiteurs de consulter les chambres et leurs disponibilités. Pour réserver, le visiteur doit créer un compte ; un client connecté peut réserver une chambre, payer en ligne par carte (le paiement est traité par le centre monétique) et annuler sa réservation jusqu'à 48 h avant l'arrivée. Le réceptionniste confirme les réservations et enregistre les arrivées. Le gérant consulte les statistiques d'occupation. » Liste les acteurs (principaux et secondaires) et les cas d'utilisation, puis dessine le diagramme.
Un acteur représente un rôle joué par une entité externe qui interagit directement avec le système : un utilisateur humain, un dispositif matériel ou un autre système. Il consulte ou modifie l'état du système, lui envoie ou en reçoit des messages.
Une même personne peut jouer plusieurs rôles : la gérante de la librairie est à la fois « Libraire » quand elle traite les commandes et « Administrateur » quand elle crée des comptes. Ce sont deux acteurs. À l'inverse, les trois vendeurs qui traitent les commandes sont un seul acteur « Libraire ».
Les acteurs humains sont dessinés par un bonhomme (stick man) ; les systèmes externes peuvent l'être par un rectangle avec le mot-clé <<actor>> (ou <<système>>).
Les cas d'utilisation
Un cas d'utilisation (use case) est un ensemble de séquences d'actions réalisées par le système, qui produit un résultat observable intéressant pour un acteur. Il modélise un service rendu par le système. On le représente par une ellipse dans le rectangle qui délimite le système.
Un verbe à l'infinitif suivi d'un complément, du point de vue de l'acteur : « Chercher des ouvrages », « Passer une commande », « Suivre sa commande ». Erreur fréquente : réduire un cas d'utilisation à une seule action (« Cliquer sur Valider », « Saisir l'adresse ») ; un cas d'utilisation est un but complet de l'acteur.
Pour découvrir les cas : délimiter le périmètre du système, lister les acteurs (qui utilisent le système, qui lui fournissent un service), puis, pour chaque acteur, ses buts.
@startuml
left to right direction
actor Internaute
actor Libraire
actor "Service de paiement" as P <<système>>
rectangle "Librairie en ligne" {
usecase "Chercher des ouvrages" as UC1
usecase "Gérer son panier" as UC2
usecase "Passer une commande" as UC3
usecase "Suivre sa commande" as UC4
usecase "Gérer le catalogue" as UC5
usecase "Traiter les commandes" as UC6
}
Internaute -- UC1
Internaute -- UC2
Internaute -- UC3
Internaute -- UC4
UC3 -- P
Libraire -- UC5
Libraire -- UC6
@endumlLa relation d'association
L'association relie un acteur à un cas d'utilisation : elle signifie « participe à ». Elle est en général dessinée par un simple trait. Une flèche peut indiquer le sens de l'échange : vers le système si l'acteur ne fait qu'envoyer des informations (un capteur), vers l'acteur s'il ne fait que recevoir (un système d'archivage).
Quand un acteur peut interagir plusieurs fois avec un cas en même temps, on ajoute une multiplicité côté cas d'utilisation : * (plusieurs), n (exactement n), n..m (entre n et m). Exemple : un utilisateur d'un logiciel de partage peut avoir plusieurs téléchargements en cours : Utilisateur —— * (Télécharger un fichier).
Ce que tu vas voir (7 min) : les chapitres « Éléments d'un diagramme des cas d'utilisation », « Définition d'Acteur », « Définition de Cas d'utilisation », « Relations entre acteurs ». Elle présente les éléments du diagramme : l'acteur, le cas d'utilisation, le système et les relations entre acteurs, comme dans cette section.
La généralisation entre acteurs
Un acteur A est une généralisation d'un acteur B si B peut faire tout ce que fait A, et plus. La flèche à triangle vide va de l'acteur spécialisé vers l'acteur général. Exemple du résumé : le directeur des ventes est un préposé aux commandes avec un pouvoir en plus (gérer le stock).
On peut aussi créer un acteur généralisé abstrait qui regroupe ce que plusieurs acteurs ont en commun : dans la librairie, le Visiteur et le Client partagent « Chercher des ouvrages » et « Gérer son panier » ; on crée l'acteur abstrait Internaute.
@startuml
left to right direction
actor Internaute
actor Visiteur
actor Client
Visiteur -|> Internaute
Client -|> Internaute
rectangle "Librairie en ligne" {
usecase "Chercher des ouvrages" as A
usecase "Gérer son panier" as B
usecase "Créer un compte" as C
usecase "Passer une commande" as D
}
Internaute -- A
Internaute -- B
Visiteur -- C
Client -- D
@endumlLa généralisation entre cas d'utilisation
Un cas A est une généralisation d'un cas B si B est un cas particulier de A. Exemple : « Faire un virement par Internet » et « Faire un virement en agence » sont des cas particuliers de « Faire un virement ». La flèche à triangle vide va du cas particulier vers le cas général.
Un exemple complet : la borne bancaire
@startuml
left to right direction
actor Client
actor "Système bancaire" as SB <<système>>
rectangle "Borne bancaire en ligne" {
usecase "S'authentifier" as Auth
usecase "Consulter son compte" as Cons
usecase "Faire un virement" as Vir
usecase "Virement national" as VN
usecase "Virement international" as VI
usecase "Imprimer un relevé" as Imp
}
Client -- Cons
Client -- Vir
Cons .> Auth : <<include>>
Vir .> Auth : <<include>>
VN -|> Vir
VI -|> Vir
Imp .> Cons : <<extend>>
Vir -- SB
Cons -- SB
@endumlCe que tu vas voir (5 min) : les chapitres « Relation d'inclusion », « Relation d'extension », « Relation de généralisation ». Elle montre les relations d'inclusion (« include »), d'extension (« extend ») et de généralisation entre cas d'utilisation, avec le sens des flèches.
Chaque étape commence par « L'acteur » ou « Le système » et décrit une action. Les scénarios alternatifs sont numérotés selon l'étape où ils se branchent (4.a, 4.b). Cette fiche servira directement à écrire les tests (chapitre 1) et le diagramme de séquence système (chapitre 4).
Ce que tu vas voir (jusqu'à la fin) : les chapitres « Exercice corrigé sur Astah UML ». Elle réalise un exercice complet sur Astah UML : repérer les acteurs et les cas, puis dessiner le diagramme. Fais-le en même temps qu'elle.
Choisis la relation entre les deux cas et précise le sens de la flèche : (1) « Payer en ligne » et « Payer par carte » ; (2) « Réserver une chambre » et « S'authentifier » ; (3) « Réserver une chambre » et « Ajouter un transfert depuis l'aéroport » (proposé seulement si le client arrive en avion) ; (4) « Annuler une réservation » et « Rembourser l'acompte » (seulement si l'annulation a lieu plus de 48 h avant) ; (5) « Consulter ses réservations » et « S'authentifier ».
Rédige la description textuelle complète du cas « Réserver une chambre » de l'exercice 2.2 : identification, préconditions, scénario nominal (8 à 10 étapes), deux scénarios alternatifs, un scénario d'exception, postconditions et une exigence non fonctionnelle.