IFT2251: Introduction au génie logicieldift6803/Transparents/... · Chap.2, Sect.3, p.7 Introduction Acteur Représentation idéalisé d’une personne, d’un système, d’un processus,

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)


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.


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.


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.



(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)


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.



(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.


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 »)


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


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 »?


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


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.


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


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


Diagramme de cas d’utilisationExemple – Système de prêt dans une bibliothèque

Réserver un 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


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


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 »


Diagramme de cas d’utilisationExemple 1 – « INCLUDE »


« 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: ……


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)


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.


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 ».…


Diagramme de cas d’utilisationExemple – « EXTEND »

Refuser le prêt« extend »


emprunteur de livres


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.


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


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.


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 !


Diagramme de cas d’utilisationQuelques outils

Rational Requisite ProEnterprise ArchitectD’autres ?


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.