Analyse et Conception Orientée Objet

Pr. Hatim HAFIDDI – INPT

INE 2 – Filière ICCN

I – Introduction
II – Point de vue fonctionnel
III – Point de vue statique
IV – Point de vue dynamique
V – Point de vue de déploiement

A.U : 2023 – 2024

OBJECTIFS

o Maitriser le langage UML

o Savoir analyser et concevoir avec UML
o Présenter des éléments méthodologiques des principaux types de
diagrammes

o Traduire des modèles UML en implémentation

o Introduire quelques aspects avancés de la modélisation avec UML
(Composants, déploiement, etc.)

Analyser, concevoir et (implémenter)

un système logiciel en utilisant UML

ACOO 2
MODALITÉS

o Cours o Travaux Dirigés / Travaux

► Concepts théoriques Pratiques
► Etudes de cas ► PV fonctionnel (DCU)
► Illustration par un outil ► PV statique (DC)
► PV dynamique (DS, DE)

o Alternance Cours et TD/TP

o Examen

ACOO 3
INTRODUCTION
Activités de création de logiciel

Support par la création de modèles :

Modèles d’exigences, Modèles de
structure, Modèles d’intégration, etc.

ACOO 4
INTRODUCTION
Modélisation / Modèle
Modeling, in the broadest sense, is the cost-effective use of something in place of something else for
some cognitive purpose. It allows us to use something that is simpler, safer, or cheaper than reality
instead of reality for some purpose
A Model represents reality for the given purpose; the model is an abstraction of reality in the sens
that is cannont represent all aspects of reality. This allows us to deal with the world in a simplified
manner, avoding the complexity, danger and ireversibility of reality.
(Jeff Rothenberg)

o Modélisation = Construire une représentation abstraite de la réalité

o Abstraction
► Ne garder que les détails les plus importants
► Décider de ce qui est signifiant dépend de l’objectif visé
o Simplification VS Abstraction
► Simplifier la compréhension et communication autour du problème
pas le problème lui-même
o # Modèles pour # aspects
ACOO 5
INTRODUCTION
Notion de vue - Exemples
o Google Maps avec différentes vues et différents niveaux
d’abstraction

Vue plan

StreetView

Vue satellite

Vue trafic

Un autre niveau d’abstraction

ACOO 6
INTRODUCTION
Modèle – Intérêts et nature

o Gérer la complexité
► Applications de plus en plus énormes
► Séparer les préoccupations / les aspects étudiés
o Communiquer
► # acteurs dans un projet (e.g., clients, manager, marketing,
programmeurs, etc.)
► Communication difficile sur le code
► Gros projets multisites (e.g., offshoring) avec parfois des centaines de
personnes
o Documenter (Logiciel != code)
► Logiciel = Documentation + Modèles + Code
► De la doc générée en partie des modèles
o Raisonner / Vérifier
► Modèle moins couteux que le système!
► Omissions, erreurs, choix conceptuels, etc.

ACOO 7
INTRODUCTION
Modèle – Intérêts et nature

o Construire
► Guider la construction du logiciel
o Pérenniser et produire (Vision MDE/MDA)
► Capitaliser un savoir faire indépendant des technologies
► Capturer le métier sans se soucier des détails techniques
► Génération de code à partir de modèles

o Pourquoi de nombreux modèles ?

► Cycle de vie => # phases/activités
► Séparation des préoccupations : Typiquement plusieurs vues
pour un système donné (# aspects)
► Raffinement (différents niveaux d’abstraction / de précision)

ACOO 8
INTRODUCTION
Modéliser – Quel langage ?
o Plusieurs langages existaient / existent (e.g., OMT, Booch,
OOSE, etc.)
o En réalité un seul a réussi à s’imposer comme le LANGAGE
pour la modélisation des applications OO

o UML (Unified Modeling Language)

► Un standard mondialement utilisé (plus de 80% des projets)
► Standardisé par l’OMG (Object Management Group)
► Très bien documenté (livres, tutos, forums, etc.)
► Et très bien outillé (e.g., MagicDraw, Enterprise Architect,
Rational Rose, Objecteering, Together J, ArgoUML, Poseidon, …)
► Des outils permettent même de générer du code à partir des
diagrammes UML
ACOO 9
INTRODUCTION
UML – Naissance et évolution

o 1989 – 1994 : Passage du nombre de méthodes OO de 10 à plus

de 50 méthodes
► Chaque méthode proposait son propre langage de modélisation
► Points communs entre méthodes (objets, méthodes, paramètres, etc.)
► Trois principales méthodes :
OMT (Object Modeling Technique) de James Rumbaugh
OOSE (Objetc-Oriented Software Engineering) de Ivar Jacobson
Booch de Grady Booch

o Milieu des années 90

► Les 3 principaux auteurs Booch, Jacobson et Rumbaugh ont chacun
commencé à adopter les idées des autres
► Souhait de la création d’un langage unifié

o 1994 – 1996 : Booch + Rumbaugh, puis Jacobson (1995) : UML 0.9

(Juin 96)

ACOO 10
INTRODUCTION
UML – Naissance et évolution

o Janvier 1997 : Soumission initiale de l’UML 1.0 à l’OMG suite à son

RFP (Request For Proposal) de 1996

o Fin 1997 : Normalisation de l’UML 1.1 (Standard OMG)

o Standard toujours en évolution

o L’histoire n’a retenu que les trois principaux auteurs alors que tant
d’autres ont y participé
► Harel : Automates (Statecharts)
► Meyer : Conception par contrat (Design by contract)
► Shlaer-Mellor : Cycle de vie des objets
► etc.

ACOO 11
INTRODUCTION
UML – Naissance et évolution (Récap)

ACOO 12
INTRODUCTION
UML – Quèsaco ?

UML = Unified Modeling Language

Standard OMG 1 pour un langage de modélisation OO
1http://www.omg.org/spec/UML/

o UML est actuellement en version 2.5.1 (Dec. 2017)

o Fusion de infrastructure et superstructure en un seul document (~
800 pages)
► Infrastructure : Définition du langage (métamodèles + sémantique)
► Superstructure : Utilisation du langage
o UML est un langage graphique de modélisation et non de
programmation (Vision MDA !)
o UML s’applique à plusieurs domaines : OO, RT, déploiement,
requirements, etc.

ACOO 13
INTRODUCTION
UML – Quèsaco ?
o UML est un langage unifié
► Fusions de plusieurs notations antérieures
► Unification des connaissances acquises dans l’orienté objet
► Indépendance par rapport aux plateformes et processus de
développement
► Standard de l’OMG
o UML est un langage (i.e., notation) et non une méthode
► Langage = Syntaxe (règles de construction) + Sémantique
► Méthode = Langage + Démarche
o UML est un langage semi-formel (juste milieu)
► Langage informel (naturel) : ambiguë, pas d’analyse systématique, …
► Langage formel (repose sur un formalisme mathématique): précis,
analysable, etc. Par contre, apprentissage et maitrise difficiles
o UML : des diagrammes et des points de vue
► Ensemble de diagrammes permettant une modélisation selon
différentes vues et à différents niveaux d’abstraction

ACOO 14
INTRODUCTION
UML – Un langage extensible

o Avec UML vous pouvez créer votre propre DSL (Domain Specific
Language) à travers le mécanisme de profil
o Un profil et le mécanisme d’adaptation d’UML à :
► Un domaine particulier
► Une plateforme donnée
o Des profils UML sont déjà préétablis
► SoaML pour la modélisation des architectures SOA
► MARTE pour le temps réel et l’embarqué
► UTP2 pour les tests
► Etc.
o Spécification d’un profil en précisant trois constructions :
► Les Stéréotypes étendent le vocabulaire (mots-clés) de UML
► Les Tagged values (valeurs marquées) ajoutent des attributs
► Les Contraintes étendent la sémantique d’UML

ACOO 15
INTRODUCTION
Diagrammes UML

ACOO 16
INTRODUCTION
Diagrammes UML - Exemples

ACOO 17
INTRODUCTION
Diagrammes structurels

o Diagramme de classes : structure interne du système

o Diagramme d’objets : état interne du système à un instant donné

o Diagramme de composants : composants physiques du système

o Diagramme de déploiement : organisation matériel du système

o Diagramme de paquetages : organisation logique du système

o Diagramme de structure composite : structure interne d’un

élément statique complexe

ACOO 18
INTRODUCTION
Diagrammes comportementaux

o Diagramme de cas d’utilisation : besoins des utilisateurs

o Diagramme d’états : évolution de l’état d’un objet

o Diagramme d’activité : enchaînement d'actions représentant un

comportement du système

ACOO 19
INTRODUCTION
Diagrammes d’interaction

o Diagramme de séquence : scénarios d'interactions avec les

utilisateurs ou au sein du système

o Diagramme de communication : décrit les messages

communiqués au sein d’une interaction en faisant ressortir les
relations entre ces objets

o Diagramme global d’interaction : vue globale du fonctionnement

du système (fusion des diagrammes d’activité et de séquence)

o Diagramme de temps : montre l’évolution de l’état d’un objet au

cours du temps et les messages qui modifient cet état (fusion des
diagrammes d’états et de séquence)

ACOO 20
INTRODUCTION
UML – Phases couvertes

Expression Diagramme de cas d’utilisation

Diagramme d’activité
des besoins

Analyse et
spécification

Conception
Diagramme de classes
Diagramme d’objets Diagramme de déploiement
Diagramme de séquence Diagramme de composants
Diagramme d’états Implémentation

Vision MDA Tests

UML comme langage de
programmation!
Génération de tests, etc.
Déploiement et
maintenance

ACOO 21
 INTRODUCTION
UML – Différents points de vue
Aspects fonctionnels
- Diagramme de cas d’utilisation
- Diagramme de séquence
- Diagramme d’activité
- Diagramme global d’interaction

Aspects dynamiques Aspects statiques

- Diagramme de séquence
- Diagramme de classes
- Diagramme d’états
- Diagramme de packages
- Diagramme d’activité
- Diagramme de structure
- Diagramme de communication
composite
- Diagramme de temps

Aspects de déploiement
- Diagramme de composants
- Diagramme de déploiement
ACOO 22
POINT DE VUE FONCTIONNEL
Diagramme de cas d’utilisation
o Un diagramme centré utilisateur
► Un système est mis en place pour les utilisateurs
► Ils savent ce qu’ils attendent du système !
o Permet de modéliser les fonctionnalités du système telles qu’elles
apparaissent aux utilisateurs externes sans en révéler la structure
► Définir les utilisations principales du systèmes : identifier les besoins
► Définir l’environnement du système : qui va l’utiliser et interagir avec lui
► Délimiter les frontières du système : où s’arrête sa responsabilité
o Permet de dialoguer avec le client
o Peut servir à concevoir des tests fonctionnels
o Un diagramme de cas d’utilisation définit :
► Les cas d’utilisation
► Les acteurs
► Le système
► Les relations entre ces différents éléments

ACOO 23
DIAG. DE CAS D’UTILISATION
Acteur
o Un acteur représente un rôle joué par une entité externe qui
interagit directement avec le système
► Identifié par le nom de rôle
► Une même entité peut jouer plusieurs rôles => plusieurs acteurs
► Plusieurs entités peuvent jouer le même rôle => 1 seul acteur

o Différentes catégories :
► Utilisateurs humains (e.g., client, chef de projet, internaute, etc.)
► Dispositifs matériels (e.g., serveur, imprimante, etc.)
► D’autres systèmes (e.g., système de pointage, etc.)

o # notations graphiques possibles :

ACOO 24
DIAG. DE CAS D’UTILISATION
Cas d’utilisation

o Un cas d’utilisation représente l’ensemble des séquence d’actions

qui sont réalisées par le système et qui produisent un résultat
observable intéressant pour un acteur particulier (déf. UML 2.0,
OMG)
► Un cas d’utilisation représente un service (fonctionnalité) rendu par le
système à un acteur donné
► Il correspond à une suite d’interactions entre un acteur et le système

o Il permet de décrire ce que le futur système devra faire, sans

spécifier comment il le fera

Nommer avec un verbe à l'infinitif + (complément)

Retirer argent Fournir argent

ACOO 25
DIAG. DE CAS D’UTILISATION
Système
o Le système représente les frontières (limites) du système considéré
et regroupe un ensemble de cas d’utilisation
► Acteurs à l’extérieur du système
► Cas d’utilisation à l’intérieur du système

ACOO 26
DIAG. DE CAS D’UTILISATION
Relations : A <-> CU

o Les acteurs sont liés aux cas d’utilisation par une association de
participation
► La seule relation possible entre acteurs et cas d’utilisation
► Représente la possibilité pour l’acteur de déclencher le cas
d’utilisation
► Un cas d’utilisation doit être relié à au moins un acteur sauf pour les
cas d’utilisation internes
► Un cas d’utilisation interne est un cas d’utilisation qui est relié à un
autre cas d’utilisation sans être directement relié à un acteur

Cas d’utilisation

Acteur
Association de
participation

ACOO 27
DIAG. DE CAS D’UTILISATION
Relations : A <-> CU

o Une association de participation et par défaut navigable dans les

deux sens (interaction bidirectionnelle)
o Le sens de navigation peut être spécifié en fonction des besoins
► Cas 1 – Association unidirectionnelle de l’acteur vers le système :
stimulus, message entrant pour le système
► Cas 2 : Association unidirectionnelle du système vers l’acteur :
message sortant (notification)

Cas 1 Cas 2

CU 1 CU 2

Acteur 1 Acteur 2

ACOO 28
DIAG. DE CAS D’UTILISATION
A <-> CU : Exemples
GAB

Retirer argent
Porteur de carte

Système industriel

Sonner alarme
Capteur
Système des absences

Prévenir absence répétée

Tuteur
ACOO 29
DIAG. DE CAS D’UTILISATION
A <-> CU : Types d’acteurs
o La finalité de l’interaction Acteur / Cas d’utilisation renseigne sur le
type d’acteur
o Deux types d’acteurs :
► Acteur principal : Utilise les fonctionnalités principales du système. Ils
sont le plus souvent à l’initiative des échanges avec le système
► Acteur secondaire : Sollicité en général par le système dans le
contexte de la réalisation d’un cas d’utilisation principal (e.g.,
vérification, infos complémentaires, etc.)

GAB

« actor »
Consulter son solde
SI banque
Porteur CB

ACOO 30
DIAG. DE CAS D’UTILISATION
Exemple
GAB

Porteur de carte

ACOO 31
 DIAG. DE CAS D’UTILISATION
Relations : A <-> A
o La généralisation(/spécialisation) est la seule relation possible entre
acteurs
► Permet d’indiquer qu’un acteur est un cas spécial (particulier) d’un
autre acteur (cas général)
► De acteur 1 vers acteur 2 : spécialisation. Le sens inverse représente la
généralisation
► L’acteur 2 est un acteur 1
► L’acteur 2 peut faire tout ce que fait
l’acteur 1
► « Héritage » est un terme propre aux Acteur 1 (e.g., Porteur de CB)
langages de programmation !
► Exemple : un client de la banque est
aussi un porteur de CB

Acteur 2 (e.g., Client de la banque)

ACOO 32
DIAG. DE CAS D’UTILISATION
Exemple : amélioration ?
GAB

Porteur de carte

ACOO 33
DIAG. DE CAS D’UTILISATION
A <-> A : Exemple
GAB

Porteur de carte

ACOO 34
DIAG. DE CAS D’UTILISATION
Scénarios d’un CU
enchainements erreur

début fin
normale

o Cas d’utilisation = ensemble des scénarios ayant le même but

pour l’utilisateur
► Un scénario est un exemple d’interactions entre le système et un ou
plusieurs acteurs
► Les scénarios sont des instances de cas d’utilisation

o Un cas d’utilisation contient en général :

► Un scénario nominal (chemin optimal !)
► Des scénarios alternatifs (autres chemins qui se terminent de façon
normale)
► Des scénarios d’erreur (qui se terminent en échec)

ACOO 35
DIAG. DE CAS D’UTILISATION
Scénarios d’un CU

o Souvent décrits en langage naturel puis formalisés à l’aide de

diagrammes de séquence (système) ou d’activité (cf. point de vue
dynamique)
► Séquence d’actions décrivant les échanges entre système et
utilisateur(s)

o Les scénarios font partie de la documentation des cas d’utilisation

► Une fiche de description textuelle par cas d’utilisation
► Le standard UML ne préconise rien quant à cette fiche

o La documentation des CU est très conseillée voir indispensable

► Un simple nom est tout à fait insuffisant pour décrire un cas d’utilisation
► Le diagramme de cas d’utilisation à lui seul n’est pas suffisant pour les
autres stakeholders (concepteur, programmeurs, testeurs, etc.)
► Eviter les ambiguïtés quant au déroulement d’un cas d’utilisation tout
en précisant ce qu’il recouvre

ACOO 36
DIAG. DE CAS D’UTILISATION
Description textuelle

Canevas pour la description d’un CU

ACOO 37
DIAG. DE CAS D’UTILISATION
Description textuelle : Exemple

Identification
o Titre : Retirer de l’argent
o Résumé : Ce cas d’utilisation permet à un Porteur de carte, qui
n’est pas client de la banque, de retirer de l’argent si son
crédit hebdomadaire le permet
o Acteur principal : Porteur de carte
o Acteur secondaire : Système d’autorisation
o Date de création : 24-01-2019
o Date de mise à jour : 17-04-2019
o Version : 1.6
o Responsable : ...

ACOO 38
DIAG. DE CAS D’UTILISATION
Description textuelle : Exemple (suite)

Préconditions
o Le GAB contient des billets
o Aucune carte ne se trouve déjà coincée dans le lecteur
o La connexion avec le Système d’autorisation est opérationnelle

Postconditions
o Le GAB contient moins de billets qu’au début du cas d’utilisation
o Une transaction de retrait a été enregistrée par le GAB avec
toutes les informations pertinentes (montant, numéro de carte,
date, etc.). Les détails de la transaction doivent être enregistrés
aussi bien en cas de succès que d’échec.

ACOO 39
DIAG. DE CAS D’UTILISATION
Description textuelle : Exemple (suite)
Scénario nominal
2. Le GAB vérifie que la carte est bien
1. Le Porteur de CB introduit sa carte une CB.
dans le lecteur du GAB. 3. Le GAB demande au Porteur de CB
de saisir son code d’identification.
5. Le GAB vérifie le code.
4. Le Porteur de CB saisit son code. 6. Le GAB demande une autorisation
au Système d’autorisation
7. Le Système d’autorisation donne son 8. Le GAB demande au Porteur de CB
accord et indique le solde hebdomadaire. de saisir le montant désiré du retrait.
10. Le GAB contrôle le montant
par rapport au solde hebdomadaire.
9. Le Porteur de CB saisit le montant.
11. Le GAB demande au Porteur de carte
s’il veut un ticket.
12. Le Porteur de CB veut un ticket. 13. Le GAB éjecte la carte.
14. Le Porteur CB reprend sa carte. 15. Le GAB délivre ticket/billets.
16. Le Porteur de CB prend son ticket et
ses billets.

ACOO 40
DIAG. DE CAS D’UTILISATION
Description textuelle : Exemple (suite)

Enchaînements alternatifs
A1 : Code d’identification provisoirement erroné
Démarre au point 5
6. Le GAB indique au Porteur de CB que le code est erroné, pour la première ou
deuxième fois,
7. Le GAB enregistre l’échec sur la carte
Le scénario reprend au point 3.

A2 : Montant demandé supérieur au solde hebdomadaire

Démarre au point 10
11. Le GAB indique au Porteur de carte que le montant demandé est supérieur au
solde hebdomadaire.
Le scénario nominal reprend au point 8.

A3 : Ticket refusé
Démarre au point 11 : ...

ACOO 41
DIAG. DE CAS D’UTILISATION
Description textuelle : Exemple (suite)
Enchaînements d’erreur
E1 : Carte non-valide
Démarre au point 2
3. Le GAB indique au Porteur de CB que sa carte n’est
pas valide (illisible, périmée, etc.), la confisque. Le CU se termine en échec.

E2 : Code d’identification définitivement erroné

Démarre au point 5 :
6. Le GAB indique au Porteur de CB que le code est erroné, pour la troisième fois.
7. Le GAB confisque la carte.
8. Le Système d’autorisation est informé ; le cas d’utilisation se termine en échec.

E3 : Retrait non autorisé

Démarre au point 6
Le Système d’autorisation interdit tout retrait.
Le GAB éjecte la carte ; le CU se termine en échec.

E4 : Carte non reprise ...

E5 : Billets non pris ...
E6 : Annulation de la transaction
Démarre entre points 4 et 12 : ...

ACOO 42
DIAG. DE CAS D’UTILISATION
Description textuelle : Exemple (suite)

Rubriques optionnelles
o Contraintes non fonctionnelles (NF requirements)
► Temps de réponse : l’interface du GAB doit réagir en l’espace de 2
secondes au maximum. Une transaction nominale de retrait doit durer
moins de 2 minutes
► Confidentialité : les informations concernant le client ne doivent pas
être divulguées
► Disponibilité : le GAB est accessible 7/7 et 24/24

o Contraintes liées à l’IHM (Interface Homme-Machine)

► Toujours demander la validation des opérations bancaires

ACOO 43
DIAG. DE CAS D’UTILISATION
Description CU : Diag. séquence système

Ax Sys_X
Message (data 1 , data n)

réponse

o Représentation de la chronologie des échanges de messages

o Description (à l’analyse) des scénario possibles d’un CU

► Message informels (!= appels de méthodes)
► Données utiles aux scénarios
► Montrer les relations avec les # cas d’utilisation

ACOO 44
Diag. séquence système : Retirer argent

ACOO 45
 DIAG. DE CAS D’UTILISATION
Relations CU <-> CU : Généralisation
o Généralisation (/spécialisation) entre cas d’utilisation
► Permet d’indiquer qu’un cas d’utilisation est un cas spécial (particulier)
d’un autre cas d’utilisation (cas général)
► Le cas d’utilisation particulier (CU 2 ou CU 3) hérite de la sémantique du
cas d’utilisation général (CU 1). Il peut comprendre des interactions
spécifiques supplémentaires, ou modifier les interactions héritées
► CU 1 est le cas d’utilisation père, CU 2 et CU 3 sont les cas d’utilisation fils
► CU 2 (CU 3) est une sorte (variante) de CU 1
► CU 1 peut être abstrait

(e.g., Déposer argent)

(e.g., Déposer des (e.g., déposer du

chèques) numéraire)

ACOO 46
 DIAG. DE CAS D’UTILISATION
Relations CU <-> CU : Extension
o Extension : CU 2 « extend » CU 1
► Le cas CU 2 peut être déclenché au cours de
l’exécution de CU 1 sous certaine (s) condition(s)
et à certain(s) point(s) particulier(s) de son flot
d’exécution (points d’extension)
► CU 2 est optionnel pour CU 1
► Condition : acteur à l’initiative de l’action,
changement d’état du système, etc.
► # de extends (héritage) de Java

(e.g. Retirer argent)

« extend »
Extension points : expt1 (e.g., Consulter solde)
(e.g., Vérification montant) (condition : conds
Extension points : extpts)
(e.g.,
Condition : client choisit consultation
solde
Extension points : Vérification montant)
ACOO 47
 DIAG. DE CAS D’UTILISATION
Relations CU <-> CU : Inclusion

o Inclusion : CU 1 « include » CU 2
► Le cas CU 2 déclenché nécessairement
au cours de l’exécution de CU 1
► CU 2 est obligatoire pour CU 1 -> une
sous partie de CU 1
► Factoriser des CU communs à plusieurs
CU -> Réutilisation

« include »
(e.g., Déposer argent) (e.g., S’authentifier

ACOO 48
DIAG. DE CAS D’UTILISATION
Description textuelle : Exemple

Scénario nominal (appel d’un CU factorisé)

2. Le GAB demande une autorisation
1. Appel du cas « S’authentifier ».
au Système d’autorisation.
3. Le Système d’autorisation donne son 4. Le GAB demande au Porteur de CB
accord et indique le solde hebdomadaire. de saisir le montant désiré du retrait.
6. Le GAB contrôle le montant
par rapport au solde hebdomadaire.
5. Le Porteur de CB saisit le montant.
7. Le GAB demande au Porteur de carte
s’il veut un ticket.
8. Le Porteur de CB veut un ticket. 9. Le GAB éjecte la carte.
10. Le Porteur de CB reprend sa carte. 11. Le GAB délivre ticket/billets.
12. Le Porteur de CB prend son ticket et
ses billets.

ACOO 49
DIAG. DE CAS D’UTILISATION
Description textuelle : Exemple (suite)
Enchaînements alternatifs
A1 : Montant demandé supérieur au solde hebdomadaire
Démarre au point 6
7. Le GAB indique au Porteur de carte que le montant demandé est supérieur au solde
hebdomadaire.
Le scénario nominal reprend au point 4.
A2 : Ticket refusé
Démarre au point 7 : ...

Enchaînements d’erreur
E1 : Retrait non autorisé
Démarre au point 2
Le Système d’autorisation interdit tout retrait.
Le GAB éjecte la carte ; le CU se termine en échec.
E2 : Carte non reprise ...
E3 : Billets non pris ...
E4 : Annulation de la transaction
Démarre entre points 2 et 8 : ...

ACOO 50
DIAG. DE CAS D’UTILISATION
Description textuelle : CU « S’authentifier »

Scénario nominal du CU factorisé

2. Le GAB vérifie que la carte est bien
1. Le Porteur de CB introduit sa carte une CB.
dans le lecteur du GAB. 3. Le GAB demande au Porteur de CB
de saisir son code d’identification.
4. Le Porteur de CB saisit son code. 5. Le GAB vérifie le code.

ACOO 51
DIAG. DE CAS D’UTILISATION
Description textuelle : CU « S’authentifier »
Enchaînements alternatifs
A1 : Code d’identification provisoirement erroné
Démarre au point 5
6. Le GAB indique au Porteur de CB que le code est erroné, pour la première ou
deuxième fois,
7. Le GAB enregistre l’échec sur la carte
Le scénario reprend au point 3.

Enchaînements d’erreur
E1 : Carte non-valide
Démarre au point 2
3. Le GAB indique au Porteur de CB que sa carte n’est
pas valide (illisible, périmée, etc.), la confisque. Le CU se termine en échec.
E2 : Code d’identification définitivement erroné
Démarre au point 5 :
6. Le GAB indique au Porteur de CB que le code est erroné, pour la troisième fois.
7. Le GAB confisque la carte.
8. Le Système d’autorisation est informé ; le cas d’utilisation se termine en échec.

ACOO 52
DIAG. DE CAS D’UTILISATION
Description CU : Diag. Séquence système

Référencer un CU factorisé

ACOO 53
DIAG. DE CAS D’UTILISATION
Description CU : Diag. Séquence système
Diag. de séquence système du fragment référencé

ACOO 54
DIAG. DE CAS D’UTILISATION
Vue d’ensemble

+
ACOO 55
DIAG. DE CAS D’UTILISATION
Eléments de méthodologie
Identifier les acteurs
► En délimitant les frontières du système
► En se posant la question sur qui va utiliser les fonctionnalités principales
du système => Acteurs principaux
► Et sur les autres systèmes connexes interagissant avec le système
(logiciels, périphériques, etc.) => Acteurs secondaires
► Identifier éventuellement les relations de généralisation entre acteurs

Identifier les cas d’utilisation

► En se demandant quels sont les services rendus par le système
► En cherchant par acteur quelles sont les intentions métiers avec
lesquelles il utilise le système
► Ne pas oublier celui qui maintient le système
► Se demander sur les évènements perçus par le système (externes,
temporels, changements d’états)
► Eviter d’abuser des relations entre CU (e.g., « include », « extend », etc.)
► Processus itératif et centré utilisateurs pour définir les cas d’utilisation

ACOO 56
DIAG. DE CAS D’UTILISATION
Exemple - SVL

ACOO 57
DIAG. DE CAS D’UTILISATION
Etude de cas : GAB

ACOO 58
DIAG. DE CAS D’UTILISATION
Etude de cas : GAB

Cahier des charges : l’étude de cas s’intéresse à un système

simplifié de gestion d’un Guichet Automatique Bancaire (GAB)
offrant les services suivants :

Le distributeur délivre de l’argent à tout porteur de carte. Pour les

porteurs de carte non client de la banque, le GAB fait appel à un
système d’autorisation

Pour les clients de la banque, le GAB permet en plus :

► la consultation du solde du compte. Cette consultation pourra
également être faite lors d’un retrait pour ajuster le montant à retirer
► le dépôt d’argent (chèque ou numéraire)
► l’impression d’un mini-relevé (historique des opérations)
► le virement vers un compte donné. Lors de cette opération,
l’utilisateur pourra enregistrer un nouveau bénéficiaire.

ACOO 59
DIAG. DE CAS D’UTILISATION
Etude de cas : GAB

Toute transaction est sécurisée et nécessite par conséquent une

authentification (vérification du code au niveau du GAB)

L’utilisateur du GAB pourra demander lors d’un retrait/dépôt

d’argent l’impression d’un ticket

Un opérateur de maintenance se charge de maintenir le GAB

opérationnel (récupérer une carte avalé, renouveler le ruban
papier, etc.). C’est la même personne également qui recharge le
distributeur

Les informations nécessaires aux opérations d’un porteur de carte

client de la banque sont détenues par le SI de la banque

ACOO 60
Diagramme de cas d’utilisation du GAB
61