UML

Les cas d’utilisation (use cases)

2

Identification des acteurs et des cas d’utilisation

• Identification des acteurs– entité externe qui interagit avec le système

• Identification des cas d’utilisation– modélisation d’un service rendu par le système

• Construire le diagramme de cas d’utilisation

3

Les acteurs

• Entité externe qui interagit avec le système– attend des services de la part du système– l’interaction : envoi/réception de messages– peut être une personne ou un autre système

• Sont décrits par leur rôle et leur relation avec les cas d’utilisation

« acteur »autre système

4

Les cas d’utilisation

• Un CU modélise un service rendu par le système– exprime les interactions acteurs/système

– apporte une valeur ajoutée « notable » aux acteurs concernés

– la façon dont le système réalise le service est masquée

• Le déroulement du CU est contrôlé par les acteurs– l’événement déclencheur vient d’un acteur

– acteur principal : bénéficiaire du CU

5

Diagramme de cas d ’utilisation

Pilote

Conduire

Ravitailler

Mécanicien

Envoyer infos

Réparer

Formule 1

« acteur »système detélémesure

6

Identification des CU

• Pour chaque acteur identifié– rechercher les façons dont il utilise le système

– rechercher dans le cahier des charges les services attendus du système

• Pour chaque CU– vérifier qu’il fournit un service notable aux acteurs

– vérifier qu’il est déclenché par un événement externe

• Uniformiser le niveau d’abstraction des CU

7

Description d’un cas d’utilisation

• Description textuelle (non normalisée)– sommaire d ’identification (titre, résumé, acteurs,

responsable…)

– description des enchaînements (enchaînements nominaux, alternatifs, exceptions...)

• Un CU contient un ou plusieurs scénarios.– Les scénarios seront décrits par des diagrammes de

séquence, de collaboration etc.

8

Relations entre cas d’utilisation

VendreCalculer TVA

« inclut »

Faire rabais

«étend »Montant > 500 Francs

Vendre en gros

Points d ’extension•Faire rabais quand quantité déterminéePoints d ’inclusion•TVA suivant prix global

9

Exemple :le guichet automatique de banque

• Le guichet automatique offre les services suivants:– distribution d’argent pour tout porteur de carte de crédit

– consultation de compte, dépôt en numéraire et dépôt de chèques pour les porteurs d’une carte de cette banque

• Le guichet a besoin d’être rechargé régulièrement.

Construire le diagramme de cas d’utilisation pour le guichet automatique de banque

10

Diagramme de CU

Retirer de l’argent

Consulter le solde

Déposer du numéraire

Déposer deschèques

« acteur »SA Visa

« acteur »SI Banque

Porteur C.B. Visa

Client de la banque

11

Relations entre cas d ’utilisation

• Objectif : organiser les C.U., factoriser les parties communes

• Les types de relation standardisés :– inclusion

– extension

– généralisation/spécialisation

• Classification des acteurs

12

Inclusion

• Le cas de base incorpore explicitement un autre, à un endroit spécifié.

• Le CU inclus n’est jamais exécuté seul, mais seulement comme partie d’un cas de plus vaste

Retirer de l’argent

Authentifier client

Consulter le solde

« inclut » « inclut »

13

Extension

• Le cas de base incorpore implicitement un autre• Les deux cas peuvent fonctionner seuls• Le cas source ajoute son comportement au cas

destination– L’extension peut être soumise à une condition

d’extension

– point d’extension : décrit, dans le cas destination, l’emplacement ou le comportement du cas source est inséré.

14

Extension - suite

Consulter le solde

« étend »(vérification montant)Retirer argent

Point d ’extension: vérif montant, etc.

• Dans le cas « Retirer argent », le client peut vouloir vérifier son compte

• Attention au sens des flèches dans les relations inclut/étend

15

Généralisation/spécialisation

• Permet de hiérarchiser les CU– les CU descendants héritent le fonctionnement des

parents.

– le descendant peut ajouter ou modifier des interactions par rapport à son père.

Déposer des chèques

Déposer de l ’argent

Déposer du numéraire

16

Diagramme de CU - version 2

17

Diagrammes dynamiques pour les cas d’utilisation

• L’objectif des CU est de faciliter le dialogue avec les utilisateurs– la description textuelle peut devenir complexe,

ambiguë…

– description graphique : vue plus synthétique

• Quelques conditions :– description du système en tant que boite noire

– favoriser la lisibilité

18

Diagrammes dynamiques - suite• Le cas d’utilisation se décompose en scénarios

– scénario nominal, enchaînements alternatifs

– chaque scénario et chaque CU description textuelle

• Descriptions graphiques des CU– diagrammes d’activité (organigramme, compréhensible)

– diagrammes d’états (automates d’états; utilisé dans certains

cas)

• Descriptions graphiques des scénarios– diagramme de séquence (axe temporel, très simple)

– diagramme de collaboration (dimension « spatiale »)

19

Diagrammes de séquence

• Diagrammes de séquence « système »– illustre la succession temporelle des communications,

par messages acteurs/système

– acteur principal (à gauche), système, acteurs secondaires (à droite)

• Très facile a comprendre pour les utilisateurs

• On peut faire aussi des diagrammes de séquence entre objets

20

Différents flots

Objet A Objet B Objet C

message 1

message 2

Flèche pleine : messages synchrones, avec attente

Demi-flèche : messages asynchrones (environnement concurrent)

21

Différents flotsObjet A Objet B

Objet A Objet B

Objet

Récursion()

Objet

Message réflexif

22

Contraintes temporelles

{y-x<3s}x

y

23

Structures de contrôle

Objet A Objet B

while Xloop

end loop

Objet A Objet B

*[X] MessageMessage

Objet A Objet B

if

elseend if

Message

Objet C

Message

Objet A Objet B

[X]

[Y]

24

Diagramme d’activités

• Représente les étapes d’une procédure• Graphe : les sommets sont les activités, les arcs

sont les transitions• Des activités peuvent se dérouler en parallèle.

Afficher (i)/i=0

[i<10]/i++

[sinon]

25

Diagramme d’activité - travéesEnseignant Etudiant Jury

EcouterEnseigner

Composer

Apprendre

Contrôler

Evaluer

26

Diagramme d’états

• Représente les transformations des états d’un système ou d’un objet

• la classe Personne a un attribut Emploi qui vaut En Activité, Au chômage ou A la retraite.

En activité

Au chômage

A la retraitePerte emploi Embauche

Quand(Age>60)

Quand(Age>60)

27

Diagrammes de collaboration• Diagrammes d’interaction entre objets• Ensemble de rôles dans un contexte particulier• Liens entre les objets (complète le diagramme d’objets)

• Représentation d’envois de messages• Dimension spatiale plus que temporelle

– permet de fixer une partie du diagramme de classes,correspondant à la collaboration étudiée

28

Exemple/Locataire:Personne

:Coût

/Maison:Logement

:Lieu

/Propriétaire:Personne

*1

1

1

1

1

* 1

Loueur/Propriétaire:Personne

:Coût/Maison:

Logement

1:revenu location (pour les maisons)

1.1*[i=1..n]:loyer()

1.1.i:valeur()

:Conseiller

29

Notions complémentaires

appel procédure

asynchrone

1.2.1

1.2.2

1.2.a

1.2.b

consécutifs parallèles

[condition] *[itération] retour:=opération

1.2,2.4/5: op

30

Paquetages

• Partitionnement des éléments en ensembles– Couplage « fort »

• 4 Stéréotypes– Façade : vue simplifié d’un ensemble de paquetages– Framework– Souche (partie publique)– Racine (le + haut niveau)

31

Paquetages : notation

Nom paquet

32

Notions sur les paquetages• Espace de nommage

– ::

– unicité des noms

• Dépendances– « importe » import complet

• permet de redéfinir les visibilités (transitivité)

– « accède » possibilité de référencement

– Précaution• éviter les graphes cycliques

• Généralisation

33

Diagrammes de composants

Nom Stéréotypes :•« document »•« exécutable »•« fichier »•« bibliothèque »•« table »

34

Diagrammes de déploiement

Nœud Nœud Nœud« support »

Nœud 1 Nœud 2« RS232 »