Heg Haute école de gestion de Neuchâtel 14/11/01UML 04 V1-1a1 Les cas dutilisation Les cas...

14/11/01 UML 04 V1-1a 1

hegHaute école de gestionde Neuchâtel

Les cas d’utilisation

Les cas d’utilisation (use cases) ont été formalisés par Ivar Jacobson. Les cas d’utilisation décrivent, sous la forme d’actions et de réactions, le comportement d’un système du point de vue d’un utilisateur.

Un cas d’utilisation est une manière spécifique d’utiliser un système. C’est l’image d’une fonctionnalité du système, déclenchée en réponse à la stimulation d’un acteur externe.

[PAM-00 p151]

14/11/01 UML 04 V1-1a 2


Intérêt des cas d’utilisation

[PAM-00 p152]

Ensemble des besoins

Utilisateur A Utilisateur B

Utilisateur C

Les cas d’utilisation partitionnent l’ensemble des besoins d’un système

Cahier des charges

14/11/01 UML 04 V1-1a 3


Le modèle des cas d’utilisation

Un acteur représente un rôle joué par une personne ou une chose qui interagit avec un système.

[PAM-00 p152]

Système

14/11/01 UML 04 V1-1a 4


Figure 3-125 / Exercice 1 - 1

[PAM-00 p153]

14/11/01 UML 04 V1-1a 5


4 grandes catégories d’acteurs

• Les acteurs principaux…les personnes qui utilisent les fonctions principales du système.

• Les acteurs secondaires…les personnes qui effectuent des tâches administratives ou de maintenance.

• Le matériel externe…les dispositifs matériels incontournables qui font partie du domaine de l’application et qui doivent être utilisés.

• Les autres systèmes… les systèmes avec lesquels le système doit interagir.

[PAM-00 p153]

14/11/01 UML 04 V1-1a 6


Les scénarios (1)

Les cas d’utilisation se déterminent en observant et en précisant, acteur par acteur, les séquences d’interaction -les scénarios- du point de vue de l’utilisateur.

Un cas d’utilisation regroupe une famille de scénarios d’utilisation selon un critère fonctionnel.

Les cas d’utilisation sont des abstractions du dialogue entre les acteurs et le système: ils décrivent des interactions potentielles, sans entrer dans le détail de chaque scénario.

[PAM-00 p155]

14/11/01 UML 04 V1-1a 7


Les scénarios (2)

[PAM-00 p155]

Les cas d’utilisation doivent être vus comme des classes dont les instances sont les scénarios. Chaque fois qu’un acteur interagit avec le système, le cas d’utilisation instantie un scénario; ce scénario correspond au flot de messages échangés par les objets durant l’interaction particulière qui correspond au scénario.

14/11/01 UML 04 V1-1a 8


Les relations dans un diagramme cas d’utilisation

• La relation de communication• La relation de généralisation• La relation d’inclusion• La relation d’extension

[PAM-00 p156]

Client distant

Virement par internet

Virement Identification

<<include>>

Vérification solde compte

montant > 500 frs

<<extend>>

14/11/01 UML 04 V1-1a 9


La relation d’inclusion

La relation d’inclusion a un caractère obligatoire, la source spécifiant à quel endroit le cas d’utilisation cible doit être inclus.

[PAM-00 p156]

Client distant



<<include>>


montant > 500 frs

<<extend>>

14/11/01 UML 04 V1-1a 10


La relation d’extension

Dans une relation d’extension entre cas d’utilisation, le cas d’utilisation source ajoute son comportement au cas d’utilisation destination (cible). L’extension peut être soumise à une condition.

[PAM-00 p156]

Client distant



<<include>>


montant > 500 frs

<<extend>>

14/11/01 UML 04 V1-1a 11


Figure 3-133 / Exercice 2 - 1

14/11/01 UML 04 V1-1a 12


Règles de mise en œuvre des cas d’utilisation

La description des cas d’utilisation comprend:– Le début du cas d’utilisation.– La fin du cas d’utilisation.– L’interaction entre le cas d’utilisation et les acteurs.– Les échanges d’informations (paramètres des

interactions).– La chronologie et l’origine des informations.– Les répétitions de comportement.– Les situations optionnelles.

[PAM-00 p158]

14/11/01 UML 04 V1-1a 13


Figure 3-134 / Cas d’utilisation et scénarios

Un cas d’utilisation décrit, de manière abstraite, une famille de scénarios.

Cas d’utilisation

Scénario 1 Scénario 3Scénario 2

[PAM-00 p160]

14/11/01 UML 04 V1-1a 14


Maquette

[PAM-97] Le maquettage à base de constructeurs d’interfaces utilisateur est très souvent le meilleur moyen d’aider l’utilisateur final à articuler ses désirs. L’examen des interactions(*) entre l’utilisateur et la maquette procure alors une source non négligeable de scénarios, et donc de moyens de valider le modèle de cas d’utilisation.[LMP-98 p61] Une maquette est un ensemble d’enchaînements d’écrans permettant de simuler un nombre limité de fonctionnalités du système. Elle s’appuie sur des objets métier simulés et des accès en bases de données fictifs.

[PAM-97 p131]

14/11/01 UML 04 V1-1a 15


La transition vers l’objet (collaboration)

[PAM-97 p133]

14/11/01 UML 04 V1-1a 16


Collaboration

[BRJ-00 p240] Un cas d’utilisation saisit le comportement attendu du système que l’on développe, sans que l’on ait besoin de préciser comment ce comportement est réalisé…Ensuite, il faut quand même implémenter les cas d’utilisation en créant une société de classes et d’autres éléments qui fonctionnent ensemble pour réaliser le comportement de ce cas d’utilisation. Cette société d’éléments, qui comporte à la fois une structure statique et dynamique, est modélisée en UML sous le nom de collaboration.On peut préciser explicitement la réalisation d’un cas d’utilisation par une collaboration. Pourtant, la plupart du temps, un cas d’utilisation donné est réalisé par une seule collaboration, sans que l’on ait à modéliser explicitement cette relation.

14/11/01 UML 04 V1-1a 17


Collaboration implicite / Exercice 3 -1

14/11/01 UML 04 V1-1a 18


La transition vers l’objet

Une approche objet réalise un cas d’utilisation au moyen d’une collaboration entre objets. Les scénarios, instances du cas d’utilisation, sont représentés par des diagrammes d’interaction (diagrammes de collaboration et diagrammes de séquence).

[PAM-00 p163]

14/11/01 UML 04 V1-1a 19


Les diagrammes d’objets

Les diagrammes d’objets, ou diagrammes d’instances, montrent des objets et des liens. Comme les diagrammes de classes, les diagrammes d’objets représentent la structure statique.

Les diagrammes d’objets s’utilisent principalement pour montrer un contexte, par exemple avant ou après une interaction, mais également pour faciliter la compréhension des structures complexes, comme les structures récursives.

[PAM-97 p134]

14/11/01 UML 04 V1-1a 20


Représentation des objets

L’objet « ObjetA » n’est pas classifié

L’objet « ObjetB » est instance de la classe « ClasseB »

L’objet « ClasseC » est une instance anonyme de la classe «ClasseC»

Rational Rose n’affiche pas les stéréotypes de classe

Rational Rose ne permet pas la saisie de valeurs d’attributsLes attributs peuvent être affichés avec la

fonction Edit Compartment du menu contextuel des

objets

[PAM-00 p164]

14/11/01 UML 04 V1-1a 21


Représentation des liens / Exercice 4 - 1

[PAM-00 p167]

Classe

Objets

14/11/01 UML 04 V1-1a 22


Les objets composites

[PAM-00 p168]

Classes

Objets

14/11/01 UML 04 V1-1a 23


Similitudes avec les diagrammes de classes (1)

[PAM-00 p169]

Classes

Objets

14/11/01 UML 04 V1-1a 24


Compréhension de structures complexes

[PAM-00 p169]

14/11/01 UML 04 V1-1a 25


Les objets actifs

[PAM-00 p170]

14/11/01 UML 04 V1-1a 26


Les diagrammes de collaboration

[PAM-97 p139]Les diagrammes de collaboration montrent des interactions entre objets, en insistant plus particulièrement sur la structure spatiale statique qui permet la mise en collaboration d’un groupe d’objets. Les diagrammes de collaboration expriment à la fois le contexte d’un groupe d’objets (au travers des objets et des liens) et l’interaction entre ces objets (par la représentation de l’envoi de messages). Les diagrammes de collaboration sont une extension des diagrammes d’objet.

[PAM-00 p171]

14/11/01 UML 04 V1-1a 27


Les envois de messages

UML utilise le terme de stimulis pour parler d’une communication entre deux objets qui déclenche l’invocation d’une opération, l’émission d’un signal ou la création et destruction d’un objet

[PAM-00 p178]

14/11/01 UML 04 V1-1a 28


Représentation des interactions

Les interactions comprennent principalement les éléments suivants:

– Les instances– Les liens– Les messages– Les rôles

Dans un diagramme de collaboration, le temps n’est pas représenté de manière implicite, comme dans un diagramme de séquence, de sorte que les différents messages sont numérotés pour indiquer l’ordre des envois.

[PAM-00 p179]

14/11/01 UML 04 V1-1a 29


Exercice 5 - 1

Classes

Collaboration

[PAM-00 p180]

14/11/01 UML 04 V1-1a 30


Figure 3-178 / Contraintes

[PAM-00 p181]

14/11/01 UML 04 V1-1a 31


Figure 3-179 / Itération d’un message

[PAM-00 p181]

Rational Rose prend le symbolisme de l’itération comme élément constitutif du nom du message.

14/11/01 UML 04 V1-1a 32


La place de l’utilisateur

[PAM-00 p182]

StéréotypeActeur

14/11/01 UML 04 V1-1a 33


Syntaxe des messages

Le message, ses arguments et valeurs de retour, son rang au sein de l’interaction, et diverses autres informations comme le degré d’emboîtement ou la synchronisation sont précisés lors de l’envoi.

SéquenceNiveau d’emboîtement du message au sein de l’interaction

RésultatListe de valeurs retournées par le message

Nom du message… Opération définie dans la classe de l’objet destinataire

ArgumentListe des paramètres du message

[PAM-00 p182]

14/11/01 UML 04 V1-1a 34


Les messages / Figure 3-183

Rational Rose ne supporte pas l’ensemble des enrichissements de messages que cite P.-A. Muller [PAM-00 p182-185].

Dans ses exemples avec Rational Rose, P.-A. Muller enrichit la sémantique des messages en utilisant la zone de nommage!

[PAM-97 p143]

14/11/01 UML 04 V1-1a 35


Enrichissement des messages (1)

14/11/01 UML 04 V1-1a 36


Opération conditionnelle

14/11/01 UML 04 V1-1a 37


Les « pattern »

[PAM-97 p146] Les collaborations existent également sous une forme générique (modèle), paramétrée par des classes, des relations, des attributs et des opérations. Une collaboration générique est appelée « pattern » ou schème et micro-architecture en français. Les patterns possèdent toujours un nom, contrairement aux collaborations qui peuvent être anonymes.

14/11/01 UML 04 V1-1a 38


Les diagrammes de séquence

[PAM-97 p148] Les diagrammes de séquence montrent des interactions entre objets selon un point de vue temporel. Le contexte des objets n’est pas représenté de manière explicite comme dans les diagrammes de collaboration. La représentation se concentre sur l’expression des interactions.Un diagramme de séquence représente une interaction entre objets en insistant sur la chronologie des envois de messages. La notation est dérivée des « Object Message Sequence du Siemens Pattern Group ».

[PAM-00 p186]

14/11/01 UML 04 V1-1a 39


1ère utilisation des diagrammes de séquence

La première utilisation des diagrammes de séquence correspond à la documentation des cas d’utilisation.

[PAM-00 p188]

14/11/01 UML 04 V1-1a 40


Figure 3-192 / Exercice 6 -1

14/11/01 UML 04 V1-1a 41


Catégories d’envoi de messages

[PAM-97 p149] Les diagrammes de séquence distinguent deux grandes catégories d’envoi de message:

– Les envois synchrones pour lesquels l’émetteur est bloqué et attend que l’appelé ait fini de traiter le message.

– Les envois asynchrones pour lesquels l’émetteur n’est pas bloqué et peut continuer son exécution.

14/11/01 UML 04 V1-1a 42


Les activations et envois de messages

Les diagrammes de séquence permettent de représenter les périodes d’activité des objets. Une période d’activité correspond au temps pendant lequel un objet effectue une action, soit directement, soit par l’intermédiaire d’un autre objet qui lui sert de sous-traitant. Les périodes d’activité se représentent par des bandes rectangulaires placées sur les lignes de vie. Le début et la fin d’une bande correspondent respectivement au début et à la fin d’une période d’activité.

[PAM-00 p189]

14/11/01 UML 04 V1-1a 43


Retour en fin d’exécution

Message synchrone

Retour impliciteMessage asynchrone

Retour explicite

[PAM-00 p190]

14/11/01 UML 04 V1-1a 44


Représentation des interactions

[PAM-00 p190-194]

3

4

1

2

14/11/01 UML 04 V1-1a 45


Les contraintes temporelles

[PAM-00 p192]

14/11/01 UML 04 V1-1a 46


Figure 3-204 / Exercice 7 -1

[PAM-00 p193]

14/11/01 UML 04 V1-1a 47


Contrôle centralisé

[KETT-98 Fig1-40]

Diagramme de séquence avec un objet contrôleur chef d’orchestre

14/11/01 UML 04 V1-1a 48


Contrôle décentralisé

[KETT-98 Fig1-41]

Diagramme de séquence avec délégation

14/11/01 UML 04 V1-1a 49


Diagramme de séquence à éviter!

[KETT-98 Fig1-42]

14/11/01 UML 04 V1-1a 50


Pseudo-code (1)

L’ajout de pseudo-code sur la partie gauche du diagramme permet la représentation des boucles et des branchements, de sorte que les diagrammes de séquence peuvent représenter la forme générale d’une interaction, au-delà de la seule prise en compte d’un scénario particulier.

[PAM-00 p194]

14/11/01 UML 04 V1-1a 51


Figure 3-209 / Pseudo-code (2)

[PAM-00 p195]

14/11/01 UML 04 V1-1a 52


Messages et opérations des classes

Utilisation des diagrammes de séquence:

• Documentation des cas d’utilisation

Messages propres au diagramme

• Spécification technique

Messages correspondants aux opérations des classes

14/11/01 UML 04 V1-1a 53


Exercice 7 - 1

Cet exercice est repris de [LMP-98 p71-73]Il s’agit d’un exemple de retrait d’argent à un guichet.Le but est de décrire un cas d’utilisation sous forme textuelle, sous forme de diagramme de séquence et de diagramme de collaboration.

Nous reproduirons ci-après:– L’introduction théorique de [LMP-98] relative à la description d’un

cas d’utilisation.– Le diagramme du cas d’utilisation.– La description textuelle d’une instance du cas d’utilisation.– Le (un) diagramme de scénario du cas d’utilisation.– Le (un) diagramme de collaboration du cas d’utilisation.

14/11/01 UML 04 V1-1a 54


Exercice 7 – 2 / Introduction théorique

[LMP-98 p71] La description des use case doit être synthétique, facilement compréhensible (comme tout modèle) et doit également rendre compte facilement d’un cas d’utilisation.

Un use case peut être décrit de différentes façons:– de façon informelle, il s’agit alors de texte libre, comme

peuvent l’être les spécifications. Il faut que les explications soient un minimum structurées et concises;

– de façon formelle, il peut alors s’agir de langages structurés, de pseudo-code, de diagrammes. Ces notations ne doivent pas être trop techniques, il ne faut pas commencer une ébauche d’implémentation à ce stade de l’analyse.

14/11/01 UML 04 V1-1a 55


Exercice 7 – 3 / Le cas d’utilisation

14/11/01 UML 04 V1-1a 56


Exercice 7 – 4 / Une représentation textuelle

• Le guichetier saisit le numéro de compte du client.

• L’application valide le compte auprès du système central.

• L’application demande le type d’opération au guichetier.

• Le guichetier sélectionne un retrait de 200 F.

• Le système « guichet » interroge le système central pour s’assurer que le compte est suffisamment approvisionné.

• Le système central effectue le débit du compte.

• Le système notifie au guichetier qu’il peut délivrer le montant demandé.

Use case « retrait en espèce »

14/11/01 UML 04 V1-1a 57


Exercice 7 – 5 / Un scénario

14/11/01 UML 04 V1-1a 58


Exercice 7 – 6 / Un diagramme de collaboration

14/11/01 UML 04 V1-1a 59


Exercice 7 – 7 / État du référentiel

Heg Haute école de gestion de Neuchâtel 14/11/01UML 04 V1-1a1 Les cas dutilisation Les cas...

Documents

Transcript of Heg Haute école de gestion de Neuchâtel 14/11/01UML 04 V1-1a1 Les cas dutilisation Les cas...