Cours d’Analyse et

Conception logicielle

Chapitre 2:
Modélisation des besoins
Rappel

2
 Introduction
Processus de développement de logiciel

Etapes principales du cycle de vie de logiciel (CVL):

➢ Analyse et spécification des besoins

➢ Conception architecturale et détaillée
➢ Programmation
➢ Intégration
➢ Maintenance
➢ validation et vérification

3
 Introduction
Les approches de modélisation
Approches objet (troisième génération)

•Évolution de l'approche systémique vers une plus grande cohérence

entre les objets et leurs comportements

•Vision du SI comme un ensemble d'objets avec leurs opérations

•Méthodes: OMT, OOD, OOSE, …

4
 Introduction
Les approches de modélisation
Approches objet (troisième génération)

• Points forts:
– capacité à modéliser des objets complexes
– réduire les distorsions entre système informatique et monde réel
– intégration des traitements aux données
– Encapsulation

• Points faibles
– aspect fonctionnel mal représenté
– aspect procédural des opérations

5
 Introduction
Concepts et notions de base de l’approche orientée objet

•Objet & classe

•Abstraction: Permet de s’attacher aux aspects essentiels sans entrer dans les détails, autrement dit

de se concentrer sur ce que représente l’objet et sur son comportement avant de décider de la façon de
l’implémenter.

•Encapsulation :Sépare les aspects externes d’un objet, accessibles aux autres objets, des détails
d’implémentation internes, qui leur sont cachés.

•Héritage: basé sur la généralisation, permet aux sous-classes d'hériter, c'est à dire, d'avoir
les mêmes attributs, opérations et associations que la super-classe

•Polymorphisme: Le polymorphisme décrit la caractéristique d’un élément qui peut prendre

plusieurs formes. 6
La Modélisation

7
 La Modélisation
Définition

UML ?

• Est une notation, pas une méthode

• Est un langage de modélisation objet
• Convient à tous les langages objets
– C++ (Héritage multiple, Template)
– Java (Interface)
– SmallTalk

8
 La Modélisation
A quoi sert la modélisation?

Un modèle permet de :

– mieux comprendre le système à développer,

– visualiser le système comme il est ou comme il devrait
l'être,
– valider le modèle vis à vis des clients,
– spécifier les structures de données et le comportement
du système,
– fournir un guide pour la construction du système,
– documenter le système et les décisions prises.

9
 La Modélisation
A quoi sert la modélisation?

Qu’apporte la modélisation objet?

• plus grande indépendance du modèle par rapport

aux fonctionnalités demandées

• des fonctionnalités peuvent être rajoutées ou

modifiées sans que le modèle objet change

• plus proche du monde réel

10
 La Modélisation
Objectifs d’UML

Pourquoi UML?

•Représenter des systèmes entiers,

•Créer un langage de modélisation utilisable à la fois par les

humains et les machines,

•Rechercher un langage commun qui est utilisable par toutes

les méthodes et adapté à toutes les phases du développement

11
 La Modélisation
UML ?

✓UML n’est pas une méthode

✓UML est un langage de modélisation objet
✓UML est adopté par toutes les méthodes objet
✓UML est une norme dans le domaine public

Utilisé Utilisé
•S.I des entreprises
•visualiser •Banques et les services financiers
•spécifier pour dans •Télécommunications
•construire •Transport
•documenter •Défense et aérospatiale
•Scientifique
•Applications distribuées par le WEB
12
 La Modélisation
Architecture 4+1

• Vue des cas d'utilisation (utilisateur): c'est la description du

modèle « vue » par les acteurs du système. Elle correspond aux
besoins attendus par chaque acteur (c'est le QUOI et le QUI).
13
 La Modélisation
Architecture 4+1

•Vue logique : c'est la définition du système vu de l'intérieur. Elle

explique comment satisfaire les besoins des acteurs (c'est le
COMMENT).

•Vue d'implémentation : cette vue définit les dépendances entre

les modules.

•Vue des processus (comportement) : c'est la vue temporelle et

technique, qui met en œuvre les notions de tâches concurrentes,
stimuli, contrôle, synchronisation, etc.

•Vue de déploiement : cette vue décrit la position géographique

et l'architecture physique de chaque élément du système (c'est le
OÙ).
14
 La Modélisation
Cycle de Développement

Axes de Modélisation avec UML

Statiques
Diagramme de Classes
Diagramme d’Objets
Diagramme de Composants
Diagramme de Déploiement
Diagramme de paquetages
Diagramme de structure composite (UML 2.x)

Fonctionnels
Diagramme de Use Case
Dynamiques
Diagramme de Séquence
Diagramme de communication (UML 2.x)
Diagramme global d’interaction (UML 2.x)
Diagramme de temps (UML 2.x)
Diagramme d'Etats-Transitions 15
Diagramme d'Activité
 La Modélisation
Modélisation fonctionnelle

• Diagramme des cas d'utilisation (use-cases) (Use Case

Diagram) : il permet d'identifier les possibilités d'interaction
entre le système et les acteurs (intervenants extérieurs au
système), c'est-à-dire toutes les fonctionnalités que doit fournir le
système.

16
 UML
Formalisme et différentes vues

Objets du Objets du Objets du

monde réel logiciel langage

De quoi parle-t-on? Comment (logique)? Comment (physique)?

Analyse Conception Code

17
 UML
Notation semi-formelle

⧫ Spécification informelle :
- Le problème est décrit en langage naturel.
- La description conserve éventuellement quelques
imprécisions, ambiguïtés
- La spécification est souvent incomplète

⧫ Spécification semi-formelle :
- basée sur des concepts (classe, entité, …)(UML, …)

⧫ Spécifications formelles
- exprimée dans un langage dont le vocabulaire, la syntaxe et
la sémantique sont définis de manière formelle.

UML est un langage de modélisation semi-formel

18
Les Diagrammes UML

Diagramme de cas d’utilisation

(Use case)

19
 Les diagrammes UML
Le diagramme des cas d’utilisation (Use case)

Permet d’élaborer le cahier des charges ou le document

de spécifications des besoins du logiciel

 permet de structurer les besoins des utilisateurs,

les objectifs correspondants d'un système

 On recense, l'ensemble des fonctionnalités d'un

système en examinant les besoins fonctionnels de
chaque acteur.
20
 Les diagrammes UML
Le diagramme des cas d’utilisation (Use case)

✓ Besoins (Exigences) fonctionnels:

▪ à quoi sert le système

▪ ce que doit faire le système, les fonctions utiles

✓ Besoins (Exigences) non fonctionnels :

▪ performance, sûreté, confidentialité, portabilité, etc.

▪ chercher des critères mesurables

21
 Les diagrammes UML
Le diagramme des cas d’utilisation (Use case)

Diagramme de cas d’utilisation répond aux questions

suivantes:
▪ Quelles sont les tâches principales réalisées par les
acteurs (entités matériels ou logiciels externe au
logiciel qui entrent en interaction)?
✓ Les informations manipulées par les acteurs ?
✓ Les informations manipulées par le logiciel?

▪ Le diagramme contient les acteurs, les cas d’utilisation

(services) et les applications.
22
 Les diagrammes UML
Le diagramme des cas d’utilisation (Use case)

Eléments de base

Acteur Cas d’utilisation Système

23
 Les diagrammes UML
Le diagramme des cas d’utilisation (Use case)

✓ Entre l’acteur et le CU une ligne simple est suffisante et moins

ambigüe. 24
 Les diagrammes UML
Le diagramme des cas d’utilisation (Use case)

Modèle des cas d’utilisation

➢ Diagramme de cas d’utilisation

➢ Modèle des cas d’utilisation :

✓ Diagrammes des cas d’utilisation

✓ Description textuelle
✓ Diagramme de séquence
✓ …
25
 La Modélisation des besoins en UML
Le diagramme des cas d’utilisation (Use case)

1. Acteur : entité ((humain ou machine) externe qui agit sur le système

(opérateur, composant interne…) :
•permettant d’en déterminer les limites
•jouant un rôle par rapport à lui
•déclenchant un stimulus initial entraînant une réaction du système

•Un acteur est décrit précisément

en quelques lignes :

26
 La Modélisation des besoins en UML
Le diagramme des cas d’utilisation
1. Acteur
4 catégories d’acteurs :
•acteurs principaux : personnes utilisant les fonctions principales du
système. Dans le cas d'un distributeur de billets, il s'agit des clients.

•acteurs secondaires : personnes qui effectuent des tâches administratives ou

de maintenance. Dans le cas d'un distributeur de billets, il s'agit de la
personne qui recharge la caisse du distributeur.

•matériel externe : dispositifs matériels autres que les ordinateurs comme les
périphériques. Dans le cas d'un distributeur de billets, il s'agit de
l'imprimante, du lecteur de carte, de la trieuse de billets.

•autres systèmes : les systèmes avec lesquels le système interagit. Dans le

cas d'un distributeur de billets, il s'agit du groupement bancaire qui gère
l'ordinateur central qui relie tous les distributeurs.
27
 La Modélisation des besoins en UML
Le diagramme des cas d’utilisation
Acteurs vs. Utilisateurs

Ne pas confondre la notion d'Acteur et de personne utilisant le système.

➢ Une même personne peut jouer plusieurs rôle

ex: Ahmed est directeur mais peut jouer le rôle de guichetier

➢ Plusieurs personnes peuvent jouer un même rôle

ex: Ahmed et Youssef sont deux clients

➢ Un rôle par rapport au système plutôt que position dans l'organisation

ex: PorteurDeCarte plutôt que médecin,

➢ Un acteur n’est pas forcément un être humain

Ex : un système de contrôle
28
 La Modélisation des besoins en UML
Le diagramme des cas d’utilisation (Use case)

2. Use case : ensemble d’actions réalisées par le système, en

réponse à une action d’un acteur. L’ensemble des uses cases décrit
les objectifs (le but) du système.
Exemple. identification, retrait de liquide.

• Scénarios d’un CU

Séquence particulière de messages dans le CU pendant une interaction

particulière (“chemin” dans le cas d’utilisation),

29
 La Modélisation des besoins en UML
Le diagramme des cas d’utilisation (Use case)

30
 La Modélisation des besoins en UML
Le diagramme des cas d’utilisation (Use case)

✓Documentation d’un scénario

Elle se fait à l’aide d’une fiche textuelle, avec des champs de description :
nom, pré-conditions… décrivant

• un scénario nominal : suite d’étapes avec des objectifs de l’acteur bien

identifiés et menés à bien,

• des points d’extension et des étapes d’extensions,

• des points d’échec,

• des liens vers d’autres scénarios s’il y a plusieurs étapes.

31
 La Modélisation des besoins en UML
Le diagramme des cas d’utilisation (Use case)

32
 La Modélisation des besoins en UML
Le diagramme des cas d’utilisation (Use case)

33
 La Modélisation des besoins en UML
Le diagramme des cas d’utilisation (Use case)

34
 La Modélisation des besoins en UML
Le diagramme des cas d’utilisation (Use case)

•Format de haut niveau

35
 La Modélisation des besoins en UML
Le diagramme des cas d’utilisation (Use case)

•Format étendu

36
 La Modélisation des besoins en UML
Le diagramme des cas d’utilisation (Use case)

•Cas d’utilisation étendu

37
 La Modélisation des besoins en UML
Le diagramme des cas d’utilisation (Use case)

•Scénario en colonnes

38
 La Modélisation des besoins en UML
Le diagramme des cas d’utilisation (Use case)

•Déroulement alternatif

39
 La Modélisation des besoins en UML
Le diagramme des cas d’utilisation (Use case)

•Description détaillée d’un C.U. Retirer argent

Contraintes non fonctionnelles :

Performance : le système doit réagir dans un délai

inférieur à 4 secondes, quelque soit l’action de l’utilisateur.

Résistance aux pannes : si une coupure de courant ou

une autre défaillance survient au cours du cas d’utilisation,
la transaction sera annulée, l’argent ne sera pas distribué.
Le système doit pouvoir redémarrer automatiquement
dans un état cohérent et sans intervention humaine.

40
 La Modélisation des besoins en UML
Le diagramme des cas d’utilisation (Use case)

•Relations entre les cas d’utilisation

-« utilise» ou « include »: définit le fait qu’un use case contient le
comportement défini dans un autre use case.
<< Utilise >>

Cas d'utilisation A Cas d'utilisation B

S’authentifier

« include »

Retirer argent

client
 La Modélisation des besoins en UML
Le diagramme des cas d’utilisation (Use case)

•Relations entre les cas d’utilisation

-« étend » ou « extend »: définit le fait qu’une instance d’un use case peut
être augmentée avec un comportement quelconque défini dans un use case
étendu
<< Etend >>

Cas d'utilisation A Cas d'utilisation B

Vérifier solde
Condition : si
montant >200DT
« extend »

Effectuer un
virement
client
42
 La Modélisation des besoins en UML
Le diagramme des cas d’utilisation (Use case)

•Relations entre les cas d’utilisation

- « généralisation » Un cas A est une généralisation d’un cas B si B

est un cas particulier de A.

Rechercher
documents

client

Rechercher Rechercher
documents par documents par
mots clés critères

43
 La Modélisation des besoins en UML
Le diagramme des cas d’utilisation (Use case)

•Relations entre les cas d’utilisation

44
 La Modélisation des besoins en UML
Le diagramme des cas d’utilisation (Use case)

•Relation d’héritage (généralisation) entre les acteurs

Consulter fiche
patient
Consulter fiche secrétaire
patient
secrétaire créer fiche
patient
créer fiche patient

Remplir fiche
médecin consultation
Remplir fiche
médecin consultation

45
 La Modélisation des besoins en UML
Le diagramme des cas d’utilisation (Relations)

➢ Relation de communication entre l’acteur et le cas d’utilisation

Consulter fiche
patient
secrétaire

✓ Association acteur/CU vu comme un canal de communication

✓ Décrit le comportement du système vu de extérieur
✓ Echange de message

Consulter fiche
patient
secrétaire
 La Modélisation des besoins en UML
Le diagramme des cas d’utilisation (Relations)

➢ Description de la Relation de communication entre l’acteur et

le cas d’utilisation
Consulter fiche
patient
secrétaire

Description par des

diagrammes de
séquences « système »
 La Modélisation des besoins en UML

Problèmes récurrents

➢ Les problèmes soulevés dans cette partie correspondent

à des questions récurrentes en pratique.

➢ Problèmes éventuellement sans réponse dans la norme

➢ Interprétations et solutions parfois différentes dans les

livres

➢ Problèmes récurrents souvent implicites

 La Modélisation des besoins en UML
Problèmes récurrents

Cas d'utilisation "essentiels"

➢ Décrire les buts et les besoins des acteurs, les

interactions mais pas l'interface (concrète)

➢ Le POURQUOI, POUR QUI, pas le COMMENT

 La Modélisation des besoins en UML
Problèmes récurrents

Cas d'utilisation "essentiels"

Retirer de l’argent Se concentrer

client sur l’essentiel
Consulter solde

Cas d’utilisation
essentiels
Retirer cartes
technicien avalées
 La Modélisation des besoins en UML
Problèmes récurrents

Cas d'utilisation "essentiels"

❑ Ne pas décrire l'interface concrète

❑ Décrire

➢ les objectifs et les intentions de l'acteur

➢ les responsabilités du système
➢ les "interactions abstraites"
 La Modélisation des besoins en UML
Problèmes récurrents

Cas d'utilisation "essentiels"

❑ Ne pas décrire l'interface concrète Retirer de l’argent

-le client insère sa carte bancaire dans le distributeur

-le système demande le code pour l’identifier
-le client tape le montant du retrait sur le clavier
-le système vérifie qu’il y a suffisamment d’argent
-le système affiche un message de confirmation
 La Modélisation des besoins en UML
Problèmes récurrents

Cas d'utilisation "essentiels"

❑ Réécriture dans un style essentiel

-le client insère sa carte bancaire dans le distributeur

-le système demande le code pour l’identifier
-le client tape le montant du retrait sur le clavier
-le système vérifie qu’il y a suffisamment d’argent
-le système affiche un message de confirmation
Extraction de l’essentiel
-le client s'identifie
-le système vérifie l'identification
-le client indique le montant du retrait
-le système vérifie qu’il y a suffisamment d’argent
 La Modélisation des besoins en UML
Problèmes récurrents

Se concentrer sur l’essentiel

➢ Eviter les décisions trop rapides

➢ Séparation des métiers

modèle de cas
✓analyse des besoins
d'utilisation (UML)

✓conception des interfaces modèle de tâches ou

Personne-système Autre (pas dans UML)
 La Modélisation des besoins en UML
Problèmes récurrents

Cas d'utilisation "but" vs.

Cas d'utilisation « interaction »
Pb. d’intermédiaire