Conception Orientée Objet

Partie III: Diagrammes (suite

et fin)
Mahamadou Abdou TOURE

1
2 Plan du Cours
► Diagrammes cas d’utilisation
► Diagrammes de séquences
3 I. Diagrammes cas d’utilisation
Objectif : Comprendre les besoins du client pour rédiger
le cahier des charges
Principe :
 Définir les limites du système
 Définir l'environnement du système : les utilisateurs ou
éléments qui interagissent avec le système
 Définir les utilisations principales du système : à quoi
sert-il ?
Éléments constitutifs :
 Diagrammes des cas d'utilisation
 Description textuelle des cas d'utilisation
 Diagrammes de séquence des scénarios d'utilisation
4 I. Diagrammes cas d’utilisation
1. Scénarios d'utilisation
Séquences d'étapes
 décrivant une interaction entre l'utilisateur et le système
 permettant à l'utilisateur de réaliser un objectif
Système : Guichet Automatique Bancaire
Scénario : Faire un retrait
Le client s'authentifie dans le système à travers sa carte
bancaire. Le système vérifie la validité de la carte en la
rejetant si elle ne l’est pas avec un reçu à l’appui pour inviter
le client à la changer. Si oui, le système affiche l’écran de
choix et de saisie des montants. Le client choisit ou saisit un
montant. Le système vérifie son compte et le montant autorisé
pour la carte. La machine éjecte la carte et le montant
demandé avec un remerciement.
5 I. Diagrammes cas d’utilisation
2. Définition
Le diagramme de cas d'utilisation est un diagramme UML utilisé pour
donner une vision globale du comportement fonctionnel d'un
système logiciel. Un cas d'utilisation représente une unité discrète
d'interaction entre un utilisateur (Humain ou Machine) et un system.
Il est une entité significative de travail Dans un diagramme de cas
d'utilisation il existe des acteurs (actors) qui interagissent avec des
cas d'utilisation (use case) UC.
Les use case permettent de structurer les besoins des utilisateurs et
les objectifs du système.
Une fois identifiés et structurés ces besoins :
 Définissent le contour du système à modéliser.
 Permettent d'identifier les fonctionnalités principales ou critiques
du système.
6 I. Diagrammes cas d’utilisation
2. Définition
Ensemble de scénarios réalisant un objectif de l'utilisateur
Cas d'utilisation : Faire un retrait au GAB
Scénario principal :
1. Le client s'authentifie dans le système;
2. Le système vérifie la validité de la carte;
3. Le système affiche l’écran de choix et de saisie des montants;
4. Le client choisit ou saisit un montant;
5. Le système vérifie le compte du client et le montant autorisé pour la carte;
6. La machine éjecte la carte et le montant demandé avec un
remerciement.
Cas particulier :
2a. Le système rejette la carte avec reçu pour inviter le client au
renouvellement.
7 I. Diagrammes cas d’utilisation
3. Formalisme
a. Notion de système :
Le système est un ensemble de cas d'utilisation, il contient les cas
d'utilisation mais pas des acteurs.
Un modèle de cas d'utilisation permet de définir :
 Les fonctions essentielles du système.
 Les limites du système.
 Le système par rapport a son environnement.
8 I. Diagrammes cas d’utilisation
3. Formalisme
a. Notion de système :
9 I. Diagrammes cas d’utilisation
3. Formalisme
b. L’acteur :
La première étape de modélisation consiste à définir le périmètre du
système. Toute entité en dehors de cette organisation et qui interagi
avec le système est appelé acteur selon UML.
Un acteur est un type stéréotypé représentant une abstraction qui
réside juste en dehors du système.
Remarque : Un acteur n'est pas forcement une personne physique,
elle peut être une société, un robot, un service, etc.
10 I. Diagrammes cas d’utilisation
3. Formalisme
b. L’acteur :
Il existe quatre types d'acteurs :
 Les acteurs principaux : Ce sont les acteurs qui vont réaliser le cas
d'utilisation.
 Les acteurs secondaires : Les acteurs secondaires ceux qui font
que recevoir des informations à l'issue de la réalisation d'un cas
d'utilisation.
 Périphériques externes : Les dispositifs matériaux incontournables
qui font partie du domaine de l'application et qui doivent
absolument être utilisés.
Ex : capteur, horloge externe, etc.
 Système externe : Les systèmes avec lesquels le système interagit.
Ex : Le système interbancaire, le fisc, l‘état.
11 I. Diagrammes cas d’utilisation
3. Formalisme
b. L’acteur :
N.B : Ne pas confondre entre Acteur et Utilisateur (personne qui utilise
le système)
Remarque :
 Une même personne peut jouer plusieurs rôles, ex : Yacouba est
Secrétaire mais joue aussi le rôle de comptable.
 Plusieurs personnes peuvent jouer un même rôle, ex : Dr
Souleymane OUATTARA et Dr Bourama COULIBALY sont des
enseignants du CERFITEX.
 Un acteur n'est pas forcement un être humain.
12 I. Diagrammes cas d’utilisation
3. Formalisme
c. Le cas d’utilisation :
Description détaillée d'un cas d'utilisation :
 Quand le cas d'utilisation commence ? Les préconditions.
 Quand le CU se termine ? Les post conditions.
 Le chemin correspondant au déroulement normal.
 Les variantes possibles et les cas d'erreurs
 Les informations entre le système et les acteurs.
 Les informations échangées
 Les éventuels besoins non fonctionnels.
13 I. Diagrammes cas d’utilisation
3. Formalisme
c. Le cas d’utilisation :
Exemple : Retirer de l'argent du distributeur :
Précondition : Avoir de l'argent disponible fonctionel
Début : Insertion de la carte bancaire par le client.
Fin : Retrait de l'argent + la carte
Postcondition:
 Mettre à jour le solde si retrait effectuer;
 Sinon opération annulé et solde tel qu'il est.
 Garder la carte si carte volée.
14 I. Diagrammes cas d’utilisation
3. Formalisme
c. Le cas d’utilisation :
Exemple : Retirer de l'argent du distributeur :
Déroulement normale :
 Client insère sa carte
 Système lit la carte et vérifie la validation
 Demande de code
 Vérification du code
 Choisir opération de retrait
 Système demande le montant
 Choix valide
 Le système fournit la carte, les billets et le ticket
15 I. Diagrammes cas d’utilisation
3. Formalisme
c. Le cas d’utilisation :
Exemple : Retirer de l'argent du distributeur :
Variantes :
 Carte invalide
 Carte erronée
 Panne
Contraintes non fonctionelles :
 Performances : Le système doit réagir dans un délai de 4
secondes, résistances aux pannes, résistance à la charge,
connexions en parallèle.
16 I. Diagrammes cas d’utilisation
4. Les relations
a. Les relations entre cas d’utilisation :
L'inclusion:
Dans ce type d'interaction (association), le premier cas englobe l'autre, et
son issue de la resolution du second.
Ce type de description est utile pour extraire un ensemble de sous
comportements communs. Plusieurs tâches.
Elle est représenté par une flèche en pointillé et le stéréotype « include ».
Exemple:

Retirer de l’argent

S’identifier

Retirer de l’argent
17 I. Diagrammes cas d’utilisation
4. Les relations
a. Les relations entre cas d’utilisation :
L'inclusion:
Exemple:
 18 I. Diagrammes cas d’utilisation
4. Les relations
a. Les relations entre cas d’utilisation :
L‘extension
Les extensions stéréotypes « extends » représente des prolongements logique
de certaines tâches sous certaines conditions.
Autrement dit, un cas d'utilisation A étant un cas d'utilisation B, lorsque le cas
d'utilisation A peut être appelé au cours de l'exécution du cas d'utilisation B
Il est représenté par une flèche en pointillés avec le terme « extend ». Ce
type de relations peut être utile pour traiter des cas particuliers.
« extends »
Créer Client Gérer Client
Cas
d’utilisation Si le client existe on n'a pas besoin de le créer.
optionnel
« extends »
Vérifier Solde Effectuer virement

Dans certain cas, on peut être appelé à vérifier le solde lors d'un virement.
19 I. Diagrammes cas d’utilisation
4. Les relations
a. Les relations entre cas d’utilisation :
La généralisation
Comme pour le diagramme de classe, le cas d'utilisation A est une
généralisation du cas d'utilisation B si B est un cas particulier de A, c'est à dire
lorsque A peut être substitué par B pour un cas précis.
Ces relations sont des traits pleins terminés par une flèche en triangle.
20 I. Diagrammes cas d’utilisation
4. Les relations
b. Les relations entre acteur et cas d’utilisation :
Représente une communication initié par l'utilisation. Elle représente un
échange de message potentiellement dans les deux sens.
Exemple:
21 I. Diagrammes cas d’utilisation
4. Les relations
c. Les relations entre acteurs
La seule relation possible entre acteurs est la relation de généralisation.
Exemple:
22 I. Diagrammes cas d’utilisation
4. Les relations
c. Les relations entre acteurs
ATTENTION:
23 I. Diagrammes cas d’utilisation
5. Application
Faire le diagramme de cas d’utilisation pour:
1. Un distributeur automatique;
2. Un magasin de vente de vêtement.
24 II. Diagrammes de séquences
1. Définition
 Les diagrammes de séquences sont la représentation graphique
des interactions entre les acteurs et le système selon un ordre
chronologique dans la formulation UML.
 Ils peuvent servir à illustrer un cas d'utilisation.
 L'ordre d'envoi d'un message est déterminé par sa position sur
l'axe vertical du diagramme ; le temps s'écoule "de haut en bas"
de cet axe.
 La disposition des objets sur l'axe horizontal n'a pas de
conséquence pour la sémantique du diagramme.
 Les diagrammes de séquences et ceux d'état-transitions sont les
vues dynamiques les plus importantes d'UML.
25 II. Diagrammes de séquences
1. Définition
Exemple:

Source wikipédia
26 II. Diagrammes de séquences
2. Types de messages
Comme vous pouvez le voir dans l'exemple ci-dessus, UML propose
un certain nombre de stéréotypes graphiques pour décrire la nature
du message (ces stéréotypes graphiques s'appliquent également
aux messages des diagrammes de collaborations) :
 message simple: Message dont on ne spécifie aucune
caractéristique d'envoi ou de réception particulière.
 message minuté (timeout): Bloque l'expéditeur pendant un temps
donné (qui peut être spécifié dans une contrainte), en attendant
la prise en compte du message par le récepteur. L'expéditeur est
libéré si la prise en compte n'a pas eu lieu pendant le délai
spécifié.
27 II. Diagrammes de séquences
2. Types de messages
 message synchrone: Bloque l'expéditeur jusqu'à prise en compte
du message par le destinataire. Le flot de contrôle passe de
l'émetteur au récepteur (l'émetteur devient passif et le récepteur
actif) à la prise en compte du message.
 message asynchrone: N'interrompt pas l'exécution de l'expéditeur.
Le message envoyé peut être pris en compte par le récepteur à
tout moment ou ignoré (jamais traité).
 message dérobant: N'interrompt pas l'exécution de l'expéditeur et
ne déclenche une opération chez le récepteur que s'il s'est
préalablement mis en attente de ce message.
28 II. Diagrammes de séquences
2. Types de messages
Exemple:
29 II. Diagrammes de séquences
3. Activation d’un objet
Sur un diagramme de séquence, il est aussi possible de représenter
de manière explicite les différentes périodes d'activité d'un objet au
moyen d'une bande rectangulaire superposée à la ligne de vie de
l'objet.
On peut aussi représenter des messages récursifs, en dédoublant la
bande d'activation de l'objet concerné.
Pour représenter de manière graphique une exécution
conditionnelle d'un message, on peut documenter un diagramme
de séquence avec du pseudo-code et représenter des bandes
d'activation conditionnelles.
30 II. Diagrammes de séquences
3. Activation d’un objet
Exemple:
31 II. Diagrammes de séquences
3. Activation d’un objet
Commentaires :
 Ne confondez la période d'activation d'un objet avec sa création ou sa
destruction. Un objet peut être actif plusieurs fois au cours de son
existence (voir exemple ci-dessus).
 Le pseudo-code peut aussi être utilisé pour indiquer des itérations (avec
incrémentation d'un paramètre d'un message par exemple).
 Le retour des messages asynchrones devrait toujours être matérialisé,
lorsqu'il existe.
 Notez qu'il est fortement recommandé de synchroniser vos messages,
comme sur l'exemple qui suit...
 L'exemple qui suit présente aussi une alternative intéressante pour la
représentation des branchements conditionnels. Cette notation est moins
lourde que celle utilisée dans l'exemple ci-dessus.
 Préférez aussi l'utilisation de contraintes à celle de pseudo-code, comme
dans l'exemple qui suit.