Upload
others
View
10
Download
0
Embed Size (px)
Citation preview
Julie Vachon, Hiver 2003
IFT6803: Génie logiciel du commerce électronique
Chapitre 2: Analyse orientée objetSection 3: Cas d’utilisation
Chap.2, Sect.3, p.2
SommaireChapitre 2, Section 3« Cas d’utilisation »
2.3.1 IntroductionCas d’utilisationActeurScénario
2.3.2 Identification des cas d’utilisation2.3.3 Documentation des cas d’utilisation2.3.4 Diagramme de cas d’utilisation2.3.5 Étude de cas
Chap.2, Sect.3, p.3
2.3.1 IntroductionQu’est-ce qu’un cas d’utilisation ?
Technique permettant d’identifier et de noter les fonctionnalités du système qui sont significatives pour
ses utilisateurs (humains, matériels, logiciels, etc.)
Permet de décrire les interactions du système avec son environnement
Expression du comportement du système (actions et réactions) selon le point de vue des utilisateurs du systèmeDétermination des besoins fonctionnels des utilisateurs cibles.
Introduit par Ivar Jacobson en 1986.
Chap.2, Sect.3, p.4
IntroductionScénarios
Décrit une exécution possible d’un cas d’utilisation.Séquence spécifique d’actions et d’interactions entre les acteurs et le système.Instance d’un cas d’utilisation.Un cas d’utilisation est composé:
Un scénario principal (main flow).Aucun ou plusieurs scénarios secondaires (alternative flows).
Chap.2, Sect.3, p.5
IntroductionExemple (informel)
Système de prêt dans une bibliothèque
Cas d’utilisation: Prêt d’un livreDescription: …Acteur: Emprunteur de livresPré-conditions:
L’emprunteur de livres se présente avec un exemplaire de livre àemprunter et sa carte de lecteur.
Scénario principal.La carte de lecteur est lue.Le système vérifie si (1) l’emprunteur est un membre « en règle » de la bibliothèque et (2) s’il n’a pas dépassé le quota de livres en prêt autorisé.Les deux vérifications sont réussies. Le code de l’exemplaire à emprunter est entré et le système qui vérifie alors si l’exemplaire est réservé. L’exemplaire n’étant pas réservé, le système enregistre le prêt. Un ticket est émis indiquant la date de retour.
Chap.2, Sect.3, p.6
IntroductionExemple (informel)
Système de prêt dans une bibliothèque
Scénario secondaire (A).Une des vérification n’est pas réussie: (1) l’emprunteur n’est pas un membre « en règle » de la bibliothèque ou il a dépassé le quota de livres en prêt autorisé.Le système signale le problème et refuse la demande de prêt.
Scénario secondaire (B).Le code de l’exemplaire à emprunter est entré et le système signale que l’exemplaire est réservé. La demande de prêt est refusée.
Post-conditions: Si le cas d’utilisation s’est déroulé normalement, le prêt de l’exemplaire a été enregistré par le système et l’emprunteur détient un ticket lui indiquant l’échéance du prêt.
Chap.2, Sect.3, p.7
IntroductionActeur
Représentation idéalisé d’une personne, d’un système, d’un processus, d’une organisation ou d’une chose qui interagit (depuis l’extérieur) avec le système.Rôle joué par cette personne, système, etc.
L'acteur peut consulter ou modifier l'état du système. En réponse à l'action d'un acteur, le système fournit un service qui correspond à la fonctionnalité désirée.. Remarques
Une même personne (physique) peut être liée à plusieurs acteurs (rôles) dans le système.Un même acteur (rôle) peut être joué par plusieurs entités ou individus distincts.
L’acteur interagit avec un cas d’utilisation par envoie de message.Possibilité d’établir une relation de généralisation entre acteurs (rôles).
Chap.2, Sect.3, p.8
IntroductionActeur
Catégories d’acteurs:
a) Acteurs principaux. Bénéficiaires directs du service décrit par un cas d’utilisation. Ex. Emprunteur de livres.
b) Acteurs de support. Participant offrant un service qui contribue à la réalisation du cas d’utilisation. Ex. Libraire.
c) Acteurs de coulisse. Bénéficiaires indirects d’un cas d’utilisation, sans pour autant en être un bénéficiaire direct ou un contributeur. Ex. Gestionnaire de la bibliothèque.
Chap.2, Sect.3, p.9
2.3.2 Identification des cas d’utilisation
À la découverte des cas d’utilisation…
S’interroger sur les principaux buts et objectifs du système qui sont d’intérêt pour l’utilisateur
tentation à éviter: faire la liste des tâches et procédures du système.
A propos des sous-objectifs:Il est pertinent d’y penser, mais pas toujours nécessaire de lesexpliciter…A mettre en évidence si ces sous-objectifs se répètent et sont réutilisés dans le modèle. Ex. Authentifier un membre.
Savoir juger du bon niveau de granularité à adopter pour assurer une décomposition (en objectifs et sous-objectifs) qui demeure claire et compréhensible.
Chap.2, Sect.3, p.10
Identification des cas d’utilisationMéthode pour définir les cas d’utilisation
1. Bien définir les frontières du système. Cf. Ingénierie système, diagramme de contexte.
2. Identifier les acteurs principaux.Qui démarre et arrête le système ?Qui gère et/ou initie les mises à jour ?Le « temps » est-il un acteur (ex. si le système réagit aux événements temporels…) ?Qui administre le système ?Etc.
3. Pour chacun des acteurs, identifier les objectifs principaux qu’ils souhaitent voir réaliser puisqu’ils en sont les bénéficiaires directs.
4. Définir les cas d’utilisation à partir des objectifs principaux définis en 3. Utiliser un verbe d’action pour nommer chaque cas.
Chap.2, Sect.3, p.11
2.3.3 Documentation des cas d’utilisation
DocumentsEssentiel: Document textuel décrivant chaque cas d’utilisation
scénarios, acteurs, pré et post conditions, etc.Patrons proposés: usecases.org, variation sur deux colonnes (Wirfs-Brock1993)
Complémentaire: Diagramme de cas d’utilisation UML.Nom des cas d’utilisation, acteurs, relations.
Type de description (textuelle)Brève: Un paragraphe par scénario.Pratique: Quelques paragraphes pour décrire chaque scénario.Détaillée: Description de chacune des étapes composant chacun des scénarios, avec informations concernant les pré et post conditions, etc.
Chap.2, Sect.3, p.12
Documentation des cas d’utilisationPatron de description détaillée des cas d’utilisation
(usecases.org)
Cas utilisation <no> : <nom>1. INFORMATIONS CARACTÉRISTIQUES
Acteurs principaux: Objectifs contextuels: * Pour chaque partie impliquée, décrire les intérêts et bénéfices espérés par la réalisation de ce cas d'utilisation. Quels sont les objectifs de ce cas d'utilisation aux vues de chacune des parties ?Pré-conditions: * Spécifient quelles sont les conditions (importantes) qui doivent absolument être satisfaites avant de pouvoir exécuter l'un ou l'autre des scénarios du cas d'utilisation.Post-conditions: * Spécifient quelles sont le conditions qui doivent être satisfaites après l'exécution du cas d'utilisation.Déclencheur:* Action/événement qui déclenche l'exécution du cas d'utilisation.
Chap.2, Sect.3, p.13
Documentation des cas d’utilisationPatron de description détaillée des cas d’utilisation
(usecases.org)
2. SCÉNARIO PRINCIPAL (« Le cours normal des choses (sans branchements) »)
<Numéro de l'étape> <action>…
* Décrire chacune des étapes de ce scénario depuis l'événement déclencheur jusqu'à la réalisation du but.
- Pas de branchement conditionnel. - Ne pas faire d'hypothèses concernant les interfaces!
* Type d'action composant une étape:- interaction entre acteurs- validation (du système)- changement d'état du système (ex. enregistrement d'une donnée)
Chap.2, Sect.3, p.14
Documentation des cas d’utilisation
Patron de description détaillée des cas d’utilisation(usecases.org)
3. SCÉNARIOS SECONDAIRE (EXTENSIONS)<numéro étape modifiée/étendue> <numéro(lettre) extension> <condition> : <séquence d'actions>…
* Décrire les extensions (branchement du scénario principal. Chaque extension (i.e. scénario secondaire) réfère à une étape du scénario principal et décrit une séquence d’actions alternative.
Chap.2, Sect.3, p.15
Documentation des cas d’utilisationPatron de description détaillée des cas d’utilisation
(usecases.org)
4. EXIGENCES SPÉCIALES
Décrire les exigences non fonctionnelle (performance, fiabilité,contraintes de conception, etc.) directement liées à ce cas d'utilisation.
5. LISTE DE ALTERNATIVES ET CONTRAINTES TECHNOLOGIQUES
Décrire les outils, technologies, formats de données, etc. imposés ou suggérés pour la réalisation de ce cas d'utilisation.
Chap.2, Sect.3, p.16
Documentation des cas d’utilisation
Patron de description détaillée des cas d’utilisation(usecases.org)
Exemple: Purchase Order (tif ici)(tiré du livre de C. Larman « Applying UML and Patterns »)
Chap.2, Sect.3, p.17
2.3.4 Diagramme de cas d’utilisationUn diagramme de cas d’utilisation
est composé de…
Acteurs
Cas d’utilisation
Relations (entre cas d’utilisation, entre acteurs, entre acteurs et cas d’utilisation)
Nom_acteur
Cas d’utilisation
Chap.2, Sect.3, p.18
Diagramme de cas d’utilisationExemple 1 - Système de prêt dans une bibliothèque
Réserver un livre
Emprunter unexemplaire de livre
emprunteurde livres
bibliothécaire
Retourner un exemplaire de livre
Prolonger un prêt
Mettre à jourle catalogue
navigateurConsulter
le catalogue
Bibliothèque
Pourquoi le bibliothécaire
n’est pas acteur du cas « Réserver un
livre »?
Chap.2, Sect.3, p.19
Diagramme de cas d’utilisationExemple 2 – Vente par catalogue au téléphone
Vérifier disponibilité
objet
Déposer une commande
Exécuter lacommande
Vérifier solvabilité
client
vendeur
commis
superviseur
Vente par catalogue au téléphone
Chap.2, Sect.3, p.20
Diagramme de cas d’utilisationExemple 3 – Distributeur de billets
Consulter lesolde du compte
Retirer del’argent
Allumer/éteindrele distributeur
Ravitaillerle coffre
client technicien
visualise
débite
On ne peutretirer de l’argentque dans la limitedu stock du coffredu distributeur
Distributeur de billetsLe technicien de maintenance éteintle distributeur avantde ravitaillerle coffre.
Chap.2, Sect.3, p.21
Diagramme de cas d’utilisationRappel - Cas d’utilisation
Unité cohérente représentant une fonctionnalité du système visible de l’extérieur.Ensemble d'actions réalisées par le système, en réponse à une action d'un acteur. Représente un dialogue (une séquence de messages échangés) entre des acteurs et le système.Un cas d’utilisation doit être initié par au moins un acteur et avoir au moins avoir un acteur bénéficiaire i.e. qui a besoin du cas d’utilisation ou en tire profit.
Cas d’utilisation interne: cas d’utilisation présenté à une partie du système…Unité fonctionnelle indépendante (n.b. les cas d’utilisation s’exécutent de façon indépendante bien qu’ils puissent utiliser des objets communs.)Des relations (d’utilisation, d’extension, de généralisation) peuvent liés les cas d’utilisation entre eux.
Cas d’utilisation
Chap.2, Sect.3, p.22
Diagramme de cas d’utilisationRelation entre acteurs
Généralisation
emprunteurde livres
Toute personne autorisée à être emprunteur de journaux est autorisée à être emprunteur de livres.
emprunteurde journaux
Chap.2, Sect.3, p.23
Diagramme de cas d’utilisationExemple – Système de prêt dans une bibliothèque
Réserver un livre
Emprunter unexemplaire de livre
emprunteurde livres
bibliothécaire
Retourner un exemplaire de livre
Prolonger un prêt
Mettre à jourle catalogue
navigateurConsulter
le catalogue
Emprunter unjournal
Retourner un journal
emprunteurde journaux
Bibliothèque
Chap.2, Sect.3, p.24
Diagramme de cas d’utilisationRelations entre cas d’utilisation
Ces relations sont utilisées pour favoriser la modularitéla réutilisation.
Remarques:Éviter de se donner trop de mal à vouloir établir des relations entre cas d’utilisation. On les utilise pour clarifier et mettre en évidence certains comportements.La sémantique de ces relations en UML n’est pas standardisée…
1. « INCLUDE »2. « EXTEND »3. généralisation
Chap.2, Sect.3, p.25
Diagramme de cas d’utilisation« INCLUDE »
Le cas d’utilisation inclus est appelé à un endroit explicite dans le scénario principal du cas d’utilisation de base et s’insère dans celui-ci.est nécessairement exécuté si le cas de base est instancié.
On utilise la relation « include » pour Factoriser des sous-fonctions qui sont communes à d’autres cas d’utilisation.Décomposer en sous-unités un cas d’utilisation complexe.
Cas d’utilisation A(base)
Cas d’utilisation C(inclusion)
« include »
Cas d’utilisation B(base)
« include »
Chap.2, Sect.3, p.26
Diagramme de cas d’utilisationExemple 1 – « INCLUDE »
Système de prêt dans une bibliothèque
« include »Réserver un livre
emprunteurde livres
Vérifier réservation
« include »Emprunter unexemplaire de livre
Cas d’utilisation X « Réserver un livre »…Scénario principal:
1. …2: Inclure « Vérifier réservation ».3: ……
Chap.2, Sect.3, p.27
Diagramme de cas d’utilisation« EXTEND »
Permet d’étendre, de façon structurée, le comportement d’un cas d’utilisation de base en utilisant un autre cas d’utilisation à un point d’extension spécifique.Les points d’extension sont définis à l’intérieur d’un cas d’utilisation de base, là où un comportement/traitement particulier est nécessaire.Lorsqu’on atteint un point d’extension, on se branche sur le ou les cas d’utilisation traitant ce point d’extension.
Le cas d’utilisation d’extension doit offrir un traitement spécifique au point d’extension en question.Si plusieurs cas d’utilisation extension sont activés par un même point d’extension, l’ordre de leur exécution est non déterministe.
Cas d’utilisation A(extension)Cas d’utilisation C
(base)
extension pointsX, Y
« extend» (X)
Cas d’utilisation B(extension)
« extend» (X,Y)
Chap.2, Sect.3, p.28
Diagramme de cas d’utilisation« EXTEND »
Le cas d’utilisation d’extensionest appelé à un endroit explicite (point d’extension) dans le cas d’utilisation de base (cf. scénarios secondaires…).n’est pas nécessairement exécuté même si le cas de base est instancié. N’est exécuté que si un des points d’extension correspondants est atteint.
On utilise la relation « extend » pourMettre en évidence un scénario secondaire suffisamment complexe pour en faire un cas d’utilisation.
Chap.2, Sect.3, p.29
Diagramme de cas d’utilisationExemple – « EXTEND »
• Le cas d’utilisation « Refuser le prêt » est activé seulement si on atteint le point d’extension quota_atteint dans un des scénarios du cas d’utilisation « Emprunter un exemplaire d’un livre ». On revient ensuite au scénario du cas d’utilisation de base.
Emprunter un exemplaire d’un livre
Extension pointsquota_atteintemprunteur
de livres
Refuser le prêt« extend »
(quota_atteint)
Cas d’utilisation Y « Emprunter un exemplaire »…Scénario principal: …Scénarios secondaires (extensions):
…4a: Nombre de livres empruntés supérieur à la limite:
Point d’extension « quota atteint ».…
Chap.2, Sect.3, p.30
Diagramme de cas d’utilisationExemple – « EXTEND »
Refuser le prêt« extend »
Emprunter unexemplaire de livre
emprunteur de livres
Chap.2, Sect.3, p.31
Diagramme de cas d’utilisation« Include » vs « Extend »
Include
Sens de la relation: le cas de base référence le cas inclusExécution: Inconditionnelle.Le cas inclus est toujours exécuté par le cas de base (scénario principal).Dépendance: le cas de base n’est pas nécessairement autonome et bien formé si on omet le cas inclus.Visibilité: Le cas de base voit le cas inclus et peut dépendre de ses effets dans le cadre de son scénario principal.
Extend
Sens de la relation: le cas d’extension référence le cas de base.Exécution: Conditionnelle. Le cas d’extension n’est pas nécessairement exécuté par le cas de base.Dépendance: le cas de base est nécessairement autonome et bien formé même en l’absence du cas d’extension.Visibilité: Le cas de base ne voit pas le cas d’extension et ne doit pas dépendre de ces effets dans le cadre de son scénario principal.
Chap.2, Sect.3, p.32
Diagramme de cas d’utilisation
Généralisation
Permet à un sous cas d’utilisation de spécialiser le comportement d’un cas d’utilisation de base.
Emprunter un journal
Emprunter
Emprunterun livre
Chap.2, Sect.3, p.33
Diagrammes de cas d’utilisationComment construire un diagramme de cas
d’utilisation ?Approche dirigée par les cas d’utilisation
1. Identifier les tâches significatives du système visibles de l’extérieur. (cas d’utilisation).
2. Identifier quels sont les acteurs qui interagissent avec chacune de ces tâches.
3. Structurer les cas d’utilisation. Identifier les relations d’héritage, « include », « extend » et découvrir ainsi les éventuels cas d’utilisation internes (limiter la hauteur de la hiérarchie de relation à 2).
Variante: Approche dirigée par les acteurs.
Chap.2, Sect.3, p.34
Diagramme de cas d’utilisationRemarques
Les exigences d’un système sont essentiellement centrée sur les besoins de l’utilisateur.On se concentre ici sur les préoccupations réelles des utilisateurs ; pas de solutions d'implémentation, pas d’inventaire fonctionnel du système.
Les cas d’utilisation serviront de base à la validation et à la traçabilité du système. Ils seront le fil conducteur de
tout le développement.
Ils ne doivent pas chercher l'exhaustivité, mais clarifier, filtrer et organiser les besoins !
Chap.2, Sect.3, p.35
Diagramme de cas d’utilisationQuelques outils
Rational Requisite ProEnterprise ArchitectD’autres ?
Chap.2, Sect.3, p.36
2.3.5 Étude de casSystème d’achat en ligne
Une fabricant d’ordinateurs offre la possibilité d’acheter ses ordinateurs via Internet. Le client peut choisir un ordinateur sur la page web du fabricant. Les ordinateurs sot classés en trois catégories: les serveurs, les ordinateurs de table et les portables. Le client peut choisir une configuration standard ou peut spécifier, en ligne, la configuration désirée. Les composants configurables (tels la mémoire) sont présentés dans des listes d’options à choisir. Pour chaque nouvelle configuration, le système est capable de calculer le prix.Pour faire une commande, le client doit remplir un formulaire déterminant les modes d’expédition et de paiement. Les modes de paiement acceptés sont les cartes de crédit et les chèques visés. Une fois la commande entrée, le système envoie un courriel de confirmation au client avec les détails de sa commande. En attendant la livraison de son ordinateur, le client peut consulter, via Internet, l’état de sa commande à tout moment.Le traitement de la commande nécessite les étapes suivantes: vérifier la solvabilité du client, commander la configuration désirée à l’entrepôt, imprimer la facture et demander à l’entrepôt de livrer l’ordinateur au client.