Vous êtes sur la page 1sur 225

METHODE D’ANALYSE

ORIENTEE OBJET

MIAGE L3

TRAORE Yaya
Institut Burkinabè des Arts Métiers (IBAM)
Université de Ouagadougou
1
Plan
¨ Introduction au génie logiciel et à la modélisation
¤ Cycle de vie d’un logiciel
¤ Approche classique versus approche par les objets

¨ Diagrammes UML
¤ Diagrammes des cas d'utilisation
¤ Diagrammes de classes

¤ Diagramme d’activités Diagramme d’états Diagramme de séquence


¤ Diagramme de collaboration
¤ Autres diagrammes
¨ Passage vers le code
¤ De UML vers Java
¤ UML et les bases de données

¨ Processus de développement

2
I
INTRODUCTION AU GÉNIE
LOGICIEL ET A LA
MODÉLISATION

3
4

1.
Cycle de vie d’un logiciel
Logiciel
¨ Définition : Ensemble de programmes qui permet à un
système informatique d’assurer une tâche ou une
fonction en particulier : Logiciel = programme +
utilisation
¨ Aspects importants du logiciel :
¤ Environnement : utilisateurs ,autres logiciels ,matériel
¤ Spécification : ce que doit faire le logiciel, ensemble de
critères que doivent satisfaire son fonctionnement interne et
ses interactions avec son environnement

5
Génie Logiciel
¨ Définition : Ensemble des méthodes, des techniques et
des outils dédiés à la conception, au développement
et à la maintenance des systèmes informatiques
¨ Objectif : Avoir des procédures systématiques pour
des logiciels de grande taille afin que
¤ la spécification corresponde aux besoins réels du client
¤ le logiciel respecte sa spécification

¤ les délais et les coûts alloués à la réalisation soient


respectés

6
Cycle de vie d’un logiciel
¨ Processus (ensemble d’activités) nécessaire au
développement et à la maintenance d’un logiciel
¨ Composé de plusieurs phases autonomes mais
dépendantes (interdépendantes).
¨ Chaque étape se termine par la remise de un ou
plusieurs documents validé conjointement par
l’utilisateur et le développeur.
¨ En pratique :
¤ Pas de processus idéal
¤ Choix du processus en fonction des contraintes (taille des équipes, temps, qualité...)
¤ Adaptation de « processus types » aux besoins réels
7
Cycle de vie d’un logiciel
Étapes nécessaires à la réalisation d’un logiciel:
¤ Analyse

¤ Conception

¤ Codage (Implémentation)

¤ Tests
¤ Livraison

¤ Maintenance

8
Cycle de vie d’un logiciel : Analyse
¨ Elle a pour but de dégager le problème à étudier.
¨ Le résultat de l'analyse est le cahier de charges (exprimé
dans une langue naturelle) contenant les besoins du futur
système.
¨ Cette spécification est informelle.
¨ 3 phases:(Faisabilité, Spécifications des besoins,
Organisation du projet)

9
Cycle de vie d’un logiciel : Faisabilité
¨ Première étape du cycle de vie d’un logiciel
¨ Répondre à deux questions :
¤ Est-ce que le logiciel est réalisable ?

¤ Est-ce que le développement proposé vaut la peine


d’être mis en œuvre ?
► Étudier le marché pour déterminer s’il existe un
marché potentiel pour le produit.

10
Cycle de vie d’un logiciel : Spécification
des besoins
¨ Permet de définir ce que doit faire le logiciel et non
comment il le fait
¨ Quatre types de spécifications
¤ Spécifications générales
¤ Spécifications fonctionnelles

¤ Spécifications d’interface

¤ Spécifications techniques

11
Cycle de vie d’un logiciel : Spécification
des besoins
La spécification générale consiste à identifier :
¨ Objectifs à atteindre

¨ Contraintes (utilisation du matériel et outils existants)

¨ Règles de gestion à respecter

Spécification fonctionnelles est la description des


fonctionnalités du futur logiciel de manière détaillée que
possible
Spécification d’interface décrit les interfaces du logiciel avec
le monde extérieur : homme (IHM), autres logiciel
(Middleware), machines
12
Cycle de vie d’un logiciel : Spécification
des besoins
Spécification technique :
¤ Moyens d’accès (local, distant, Internet, …)
¤ Temps de réponse acceptable

¤ Plateforme (Windows, Unix, …)

¤ Quantité d’informations à stocker (choix du SGBDR, …)

13
Cycle de vie d’un logiciel : Organisation
du projet
¨ Appelée aussi Planification et gestion de projet
¨ Permet de déterminer la manière de développer le
logiciel
¨ La phase de planification permet de :
¤ découper le projet en tâches
¤ décrire leur enchaînement dans le temps,

¤ affecter à chacune une durée et un effort

14
Cycle de vie d’un logiciel : Organisation
du projet
Plusieurs étapes :
¤ Analyse des coûts: estimation du prix du projet
¤ Planification: calendrier pour le développement (jours
ouvrables, jours fériés, nombre d’heures de travail par
jours, …)
¤ Répartition des tâches: distribuer les tâches et les sous
tâches (affectation des ressources aux tâches)

15
Cycle de vie d’un logiciel : Conception

¨ Permet de fournir une description fonctionnelle


(formelle) du système en utilisant une méthode.
¨ Les méthodes proposent des formalismes (dans la
plupart des temps graphiques) pour concevoir le
système.
¨ Deux types de conception :
¤ Conception générale
¤ Conception détaillée

16
Cycle de vie d’un logiciel : Conception
générale
¨ Appelée aussi : Conception architecturale
¨ Se focaliser sur l’architecture générale du système :

décomposition du système en sous système


Exemple, pour la gestion scolaire :
¤ GestionNote (étudiants, notes, prof, filières, …)
¤ GestionPersonnel (personnel administratif, …)

¤ GestionBibliothèque (Ouvrages, auteurs, adhérents, …)

17
Cycle de vie d’un logiciel : Conception
détaillée
¨ Produire une description detaillée de chacune des
procédures, fonctions et des structures de données
(conception classique)
¨ Produire de manière précise les contenus des objets
en terme de propriétés et de méthodes (conception
Orientée Objet)

18
Cycle de vie d’un logiciel :
implémentation (Réalisation)
¨ Des programmes seront élaborés afin de mettre en
œuvre des solutions techniques précédemment
retenues
¨ Plusieurs types langages sont utilisés:
¤ Langages classiques (C, Pascal, Fortran, …)
¤ Langages orientés objets (C++, Java, C#, …)

19
Cycle de vie d’un logiciel : Codage et
Tests
¤ Test unitaire: tester les parties du logiciel par les développeurs
¤ Test d’intégration: tester pendant l’intégration des modules
¤ Test système: tester dans un environnement proche à celui de
production
¤ Test alpha: tests faits par le client sur le site de développement
¤ Test bêta: tests faits par le client sur le site de production
¤ Test de régression: enregistrer les résultats des tests et les
comparer avec ceux des anciens versions pour déterminer si la
nouvelle n’a pas apporté de dégradation de performance.
¤ Test d'acceptation (recette) : fait par le client, validation
par rapport aux besoins initiaux

20
Cycle de vie d’un logiciel :
Livraison
¨ Fournir au client une solution logiciel qui fonctionne
correctement.
¨ Plusieurs tâches :
¤ Installation: rendre le logiciel opérationnel sur le site du
client
¤ Formation: enseigner aux utilisateurs à se servir de ce
logiciel
¤ Assistance: répondre aux questions de l’utilisateur

21
Cycle de vie d’un logiciel :
Maintenance
¨ Mettre à jour et améliorer le logiciel
¨ La maintenance comprend :
¤ Corrective : identifier et corriger des erreurs trouvées après la
livraison
¤ Adaptative : adapter le logiciel aux changements dans
l'environnement (format des données, environnement
d'exécution...)
¤ Évolutive ou Perfective : améliorer la performance, ajouter
des fonctionnalités, améliorer la maintenabilité du logiciel

22
Cycle de vie d’un logiciel : Répartition
de l'effort

23
Qualité du logiciel

¨ Critères de qualité
¤ Validité : réponse aux besoins des utilisateurs
¤ Facilité d'utilisation : prise en main et robustesse

¤ Performance : temps de réponse, débit, fluidité...

¤ Fiabilité : tolérance aux pannes

¤ Sécurité : intégrité des données et protection des accès

¤ Maintenabilité : facilité à corriger ou transformer le logiciel

¤ Portabilité : changement d'environnement matériel ou logiciel


Principes d'ingénierie pour le logiciel

¨ Rigueur : principale source d'erreurs humaine, s'assurer par tous les


moyens que ce qu'on écrit est bien ce qu'on veut dire et que ça
correspond à ce qu'on a promis (outils, revue de code...)
¨ Abstraction : extraire des concepts généraux sur lesquels raisonner,
puis instancier les solutions sur les cas particuliers
¨ Décomposition en sous-problèmes : traiter chaque aspect
séparément, chaque sous-problème plus simple que problème
global
¨ Modularité : partition du logiciel en modules interagissant,
remplissant une fonction et ayant une interface cachant
l'implantation aux autres modules
¨ Construction incrémentale : construction pas à pas, intégration
progressive
Principes d'ingénierie pour le logiciel

¨ Généricité : proposer des solutions plus générales que le problème


pour pouvoir les réutiliser et les adapter à d'autres cas
¨ Anticipation des évolutions : liée à la généricité et à la modularité,
prévoir les ajouts/modifications possibles de fonctionnalités
¨ Documentation : essentielle pour le suivi de projet et la
communication au sein de l'équipe de projet
¨ Standardisation/normalisation : aide à la communication pour le
développement, la maintenance et la réutilisation
27

2.
Les modèles de cycle de vie du
logiciel
Modèle : définition
28

q Un modèle est une représentation abstraite et


simplifiée d’une entité (phénomène, processus,
système, etc.) du monde réel en vue de le décrire, de
l’expliquer ou de le prévoir.
q Un modèle permet de réduire la complexité d’un

phénomène en éliminant les détails qui n’influencent


pas son comportement de manière significative.

q Trafic routier
Modélisation : définition
¨ La modélisation est la conception d'un modèle.
¨ Selon son objectif et les moyens utilisés, la
modélisation est dite : mathématique, Informatique,
...
¨ En génie logiciel :
¤ Modélisation = spécification + conception
¤ Aider la réalisation d'un logiciel à partir des besoins du
client
Pourquoi modéliser??
30

q Un modèle est un langage commun connu par tous les


membres de l’équipe et est donc un vecteur privilégié
pour communiquer.
q Cette communication est essentielle pour aboutir à une
compréhension commune aux différentes parties
prenantes (maitrise d’ouvrage et maitrise d’œuvre
informatique).
q Permet de mieux comprendre le fonctionnement d’un
système
q Permet de comprendre sa complexité
q D’assurer sa cohérence
q Etc.
Les modèles de cycle de vie du logiciel
¤ Modèle en tunnel :
n Absence de modèle de développement.
¤ Modèle en cascade :
n L’enchaînement des étapes est linéaire. Chaque étape ne commence
que lorsque l’étape précédente est terminée.
¤ Modèle en V :
n À chaque étape correspond une étape de test spécifique.
n Les tests peuvent être définis avant les phases de test.

¤ Modèle itératif :
n On commence par développer un sous-ensemble des fonctionnalités
(noyau du logiciel) de manière linéaire (en cascade).
n On itère un modèle linéaire pour développer incrémentalement de
plus en plus de fonctionnalités, jusqu’à achèvement du projet.
Modèle en CASCADE
Modèle en V
34

3.
Approches de modélisation
Approches de modélisation

¤ Approche fonctionnelle :
n Approche traditionnelle basée sur l’utilisation des
procédures et des fonctions.
n Les grands programmes sont décomposés en sous-
programmes.
¤ Approche orientée objets :
n On identifie les éléments du système et on en fait
des objets.
n On cherche à faire collaborer ces objets pour
qu’ils accomplissent la tâche voulue.
Modélisation : approche fonctionnelle
¤ La modélisation du système se base sur les fonctions,
et non pas sur les objets.
¤ On commence par déterminer la fonction globale
du système.
¤ Puis, on décompose la fonction globale du système
en plusieurs sous-fonctions jusqu’à obtenir des
fonctions élémentaires simples à programmer.
¤ Il s’agit d’une démarche descendante.
Modélisation : approche fonctionnelle
¤ Avantages :
n Adéquate pour les petits logiciels et les système
peu complexes.
n Démarche ordonnée et organisée.
¤ Inconvénients :
n Pose des problèmes de structuration de données,
car elle est orientée fonctions.
n Produit des logiciels non réutilisables.
n Produit des logiciels très difficile à les faire
évoluer ou corriger.
Modélisation : approche orientée objets
¤ Approche fondée sur les objets :
n Le modèle à produire est décrit en terme d’objets
et non pas en terme de fonctions.
n On peut partir des objets du domaine (briques de
base) et remonter vers le système global.
n On défini également les interactions et les
collaborations entre les objets du système.
n Il s’agit essentiellement d’une approche
ascendante.
Modélisation : approche orientée objets
¤ Avantages :
n Démarche naturelle et logique.
n Raisonnement par abstraction sur les objets du
domaine.
¤ Inconvénients :
n Parfois moins intuitive que l’approche fonctionnelle.
n Rien dans les concepts de base objets ne précise
comment modéliser la structure objet d’un système
de manière pertinente.
Historique OO
Début des années 1990
n les premiers processus de développement OO
apparaissent
n prolifération des méthodes et notations étaient la cause
de grande confusion :
n méthode OOD de Grady Booch (1991)
n méthode OMT de James Rumbaugh (1991)
n méthode OOSE de Ivar Jacobson (1991)
n méthode de Schlaer and Mellor (1992)
n Etc.

40
Historique OO
Fin 1994
¨ J. Rumbaugh rejoint G. Booch chez Rational Software

¨ OMT + OOD è Unified Method (oct 1995)

Fin 1995
¨ I. Jacobson les rejoint chez Rational Software

¨ Unified Method + OOSE è UML 0.9 (juin 1996)

Début 1997
¨ Partenaires divers : Microsoft, Oracle, IBM, HP et autres leaders
collaborent
¨ è UML 1.0 (jan 1997)
Fin 1997
¨ l’OMG (Object Management Group) retient UML 1.1 comme norme de
modélisation
41
Historique OO
Les versions se succèdent :
¨ Début 1998
¤ UML 1.2
¨ En 1998
¤ UML 1.3
¨ En 2001
¤ UML1.4
¨ En 2003
¤ UML 1.5
¨ En 2005
¤ UML 2.0
La dernière version diffusée par l'OMG est UML 2.5 bêta 2 depuis
septembre 2013

42
Méthodes objets de modélisation

Scrum
RUP
XUP
ASD
2TUP EssUP
Extreme Programming
AUP
EUP Crystal
UP DSDM

Méthodes unifiées Méthodes agiles


44

4.
UML :Unified Modeling Language
UML

OMT: Object Modeling Technique


OOD: Object Oriented Design
OOSE : Object Oriented Software Engineering 45
UML :Unified Modeling Language
¨ Langage :
n Syntaxe et règles d'écriture
n Notations graphiques normalisées

¨ … de modélisation :
n Abstraction du fonctionnement et de la structure du système
n Spécification et conception

¨ … unifié :
n Fusion de plusieurs notations antérieures : Booch, OMT, OOSE
n Standard défini par l'OMG (Object Management Group)

¨ En résumé : Langage graphique pour visualiser, spécifier, construire


et documenter un logiciel
UML :Unified Modeling Language
¨ UML est caractérisé par :
¤ un travail d'expert
¤ utilise l’approche orientée objet
¤ normalisé, riche
¤ Formel : sa notation limite les ambiguïté et les incompréhensions
¤ langage ouvert
n INDÉPENDANT du langage de programmation
n Domaine d'application : permet de modéliser n'importe quel
système
Attention :
UML est un langage (et non pas une méthode) qui :
¤ permet de représenter les modèles
47
¤ ne définit pas le processus d'élaboration des modèles.
UML :Unified Modeling Language

UML est supporté par plusieurs outils (AGL)


ü Rational Rose, http://www-306.ibm.com/software/rational/
ü WinDesign, http://www.win-design.com/
ü Objecteering/UML, http://www.objecteering.com/
ü Poseidon, http://www.gentleware.com/
ü ArgoUML, http://argouml.tigris.org/
ü EclipseUML, http://www.eclipsedownload.com/
Diagrammes d'UML 2
49
UML définit deux types de diagrammes, structurels (statiques) et comportementaux
(dynamiques)
¨ Diagrammes structurels : ¨ Diagrammes comportementaux :
¤ diagramme de classes ¤ diagramme de cas d'utilisation
¤ diagramme d’objets ¤ diagramme d’états-transitions
¤ diagramme de composants ¤ diagramme d’activités
¤ diagramme de déploiement ¤ Diagrammes d'interaction :
¤ diagramme de paquetages n diagramme de séquence
¤ diagramme de structure n diagramme de communication
composite n diagramme global
d'interaction
n diagramme de temps
Exemple d’utilisation des diagrammes
II :
LES DIAGRAMMES UML

51
52

1.
Diagrammes de cas d'utilisation
Définition du cas d'utilisation (use case)
¨ Les use cases permettent de structurer les besoins des
utilisateurs et les objectifs correspondants d'un système.
¨ Ils centrent l'expression des exigences du système sur ses
utilisateurs : ils partent du principe que les objectifs du
système sont tous motivés.
¨ La détermination et la compréhension des besoins sont
souvent difficiles car les intervenants sont noyés sous de trop
grandes quantités d'informations : il faut clarifier et
organiser les besoins des clients (les modéliser).
¨ Pour cela, les cas d’utilisation identifient les utilisateurs du
système (acteurs) et leurs interactions avec le système.
¨ Ils permettent de classer les acteurs et structurer les objectifs
du système.
Définition du cas d'utilisation (use case)

¨ Une fois identifiés et structurés, ces besoins :


¤ définissent le contour du système à modéliser (ils précisent
le but à atteindre),
¤ permettent d'identifier les fonctionnalités principales
(critiques) du système.
¨ Les use cases ne doivent donc en aucun cas décrire des
solutions d'implémentation.
¨ Leur but est justement d'éviter de tomber dans la dérive
d'une approche fonctionnelle, où l'on liste une litanie de
fonctions que le système doit réaliser.
Eléments de modélisation des cas d'utilisation
L’acteur

¨ Un acteur est un type stéréotypé représentant une


abstraction qui réside juste en dehors du système à
modéliser.
¨ Un acteur représente un rôle joué par une personne ou une
chose qui interagit avec le système. (la même personne
physique peut donc être représentée par plusieurs acteurs
en fonction des rôles qu’elle joue).
¨ Pour identifier les acteurs, il faut donc se concentrer sur les
rôles joués par les entités extérieures au périmètre du
système.
¨ Dans UML, il n’y a pas de notion d’acteur interne et externe.
Par définition, un acteur est externe au périmètre de l’étude,
qu’il appartienne ou pas à la société.
Eléments de modélisation des cas d'utilisation
L’acteur

¨ Enfin, un acteur n’est pas nécessairement une personne


physique : il peut être un service, une société, un système
informatique …
¨ Il existe 4 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.
Eléments de modélisation des cas d'utilisation
L’acteur

Peut être représenté de deux manières différentes :

¨ Petit personnage (stick man)

Nom Acteur
¨ Classe stéréotypée
<<Acteur>>
Nom Acteur

57
Eléments de modélisation des cas d'utilisation
Le cas d’utilisation

¨ Le cas d’utilisation (ou use case) correspond à un


objectif du système, motivé par un besoin d’un ou
plusieurs acteurs.
¨ L'ensemble des use cases décrit les objectifs (le but)
du système.

Nom du Cas Effectuer un


d’utilisation virement
Eléments de modélisation des cas d'utilisation
La relation

¨ Elle exprime l’interaction existant entre un acteur et un cas


d’utilisation.

Effectuer un
virement

Client
¨ Il existe 3 types de relations entre cas d’utilisation :
¤ la relation de généralisation
¤ la relation d’extension
¤ la relation d’inclusion
Eléments de modélisation des cas d'utilisation
La relation de généralisation

¨ Dans une relation de généralisation entre 2 cas


d’utilisation, le cas d’utilisation enfant est une
spécialisation du cas d’utilisation parent.
Virement
bancaire

Virement par
internet
Eléments de modélisation des cas d'utilisation
La relation d’inclusion

¨ Elle indique que le cas d’utilisation source contient


aussi le comportement décrit dans le cas d’utilisation
destination.
¨ L’inclusion a un caractère obligatoire, la source
spécifiant à quel endroit le cas d’utilisation cible
doit être inclus.
¨ Cette relation permet ainsi de décomposer des
comportements et de définir des comportements
partageables entre plusieurs cas d’utilisation.
Eléments de modélisation des cas d'utilisation
La relation d’inclusion

¨ Exemple :

Virement

<<include>>

Identification
Eléments de modélisation des cas d'utilisation
La relation d’extension

¨ A étend 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. Exécuter B peut éventuellement entraîner l’exécution de A
: contrairement à l’inclusion, l’extension est optionnelle.
¨ L’extension peut intervenir à un point précis du cas étendu.
Ce point s’appelle le point d’extension.
¨ Il porte un nom, qui figure dans un compartiment du cas
étendu sous la rubrique point d’extension, et est
éventuellement associé à une contrainte indiquant le moment
où l’extension intervient. Une extension est souvent soumise à
condition. Graphiquement, la condition est exprimée sous la
forme d’une note.
Eléments de modélisation des cas d'utilisation
La relation d’extension

¨ Exemple :

Effectuer un
virement

<<Extend>>
Condition: {si montant>2000fr}
Point d’extension : montant

Vérifier le
solde
Représentation d’un diagramme de cas
d’utilisation

¨ la frontière du système est représentée par un


cadre. Le nom du système figure à l’intérieur du
cadre, en haut.
¨ Les acteurs sont à l’extérieur et les cas d’utilisation à
l’intérieur.
Exemples de diagramme de use cases

[Rapport Stage Nasra Fall]


Exercice : distributeur automatique

¨ On considère un distributeur automatique de


produits courants (bonbons, boissons, etc.).
¨ Une fois qu’il a choisi les produits qu’il désire
acheter, le client doit ensuite payer ses achats, soit
en espèces, soit par carte bancaire.
¨ Lors de l’achat d’un produit alimentaire, le client
peut vérifier la date limite de consommation du
produit.
Correction : distributeur automatique

Distributeur automatique
choisir
produit

choisir autre choisir produit


produit alimentaire

<<include>>
Client
vérification
payer date limite

payer en payer
espèces par carte
Correction : distributeur automatique

Distributeur automatique
choisir
produit
<<extends>> Condition {Si produit =produit alimentaire}
Point d’extension : vérification_produit

vérification
date limite

Client
payer

payer en payer
espèces par carte
Description des cas d’utilisation
¨ Le diagramme de cas d’utilisation décrit les grandes
fonctions d’un système du point de vue des acteurs.
¨ Mais il n’expose pas de façon détaillée le dialogue
entre les acteurs et les cas d’utilisation.
¨ è nécessité de décrire ce dialogue

70
Description des cas d’utilisation
Deux façons sont couramment utilisées pour décrire les
cas d’utilisation :
¨ Description textuelle

¨ Description à l’aide d’un diagramme de séquence

71
Représentation textuelle d’un cas d’utilisation

• Pour documenter les use cases, la description textuelle


est indispensable afin de communiquer facilement avec
les utilisateurs.
• Rubriques habituelles obligatoires :
ü Nom : verbe à l’infinitif décrivant une intercation entre un
acteur et le système.
ü Résumé : brève description du CU.
ü Acteurs : liste des acteurs interagissant avec le CU.
ü Description (scenarios normals) : texte explicatant le CU.
Représentation textuelle d’un cas d’utilisation

• Rubriques habituelles optionnelles :


ü Pré-conditions : conditions nécessaires pour déclencher le
CU.
ü Post-conditions : conditions remplies après l’exécution du
CU (état du système après réalisation du CU).

ü Exceptions : décrit les éventuelles exceptions levées. (Un


CU décrit le comprtement du système lorsqu’il n’y a pas
d’exception.)
ü Scenarios alternatifs: decription des scénarios qui sont
pas normal et qui sont pas des exceptions
Représentation textuelle d’un cas d’utilisation
Exemple
Ø Use case “ Retrait en espèces “

• Nom : Retirer en espèces

• Acteurs : Guichetier

• Description :

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

v L’application vérifie la validité du numéro de compte et demande le


type d’opération au guichetier.

v Le guichetier sélectionne un retrait d’espèces d’un certain montant.

v L’application vérifie que le montant est disponible dans le compte. Si


oui, elle débite le compte et informe le guichetier qu’il peut donner la
somme au client.
Représentation textuelle d’un cas d’utilisation
Exemple
¨ Cas d’utilisation : « inscrire un étudiant »
¤ Nom : inscrire un étudiant
¤ Résumé : Ce cas d’utilisation permet au service pédagogique d’inscrire les nouveaux
orientés.
¤ Acteurs: Service pédagogique.
¤ Pré-condition : Authentification, liste d’une classe.
¤ Description :
n L’acteur s’authentifie d’abord.
n Il choisit l’étudiant qu’il doit inscrire
n Le système lui renvoie le formulaire d’inscription avec les informations de la scolarité.
n Il complète les informations manquantes à savoir le statut (passant ou doublant) et la
date d’inscription pédagogique.
n Le système vérifie si le statut a été saisi, enregistre les informations et affiche le
formulaire de choix des unités de valeurs.
n L’acteur choisit les unités de valeurs auxquelles doit s’inscrire l’étudiant.
¤ Exception : statut non renseigné.
¤ Post-condition : Affichage de la liste des inscrits.
[Rapport Stage N. Fall]
Intérêts des cas d’utilisation
Les CU obligent les utilisateurs à :
¨ Définir la manière dont ils voudraient interagir avec

le système
¨ Préciser quelles informations ils entendent échanger

avec le système
¨ Décrire ce qui doit être fait pour obtenir le résultat

escompté

76
Étapes de construction du diagramme
des cas d'utilisation
Pour modéliser le diagramme des cas d'utilisation, il faut :
¨ Identifier les acteurs qui entourent le système. Certains acteurs
utilisent le système pour accomplir des tâches (acteurs
principaux), d'autres effectuent des tâches de maintenance ou
d'administration (acteurs secondaires).
¨ Organiser les acteurs selon une hiérarchisation de
généralisation/spécialisation
¨ Intégrer les acteurs au diagramme en spécifiant les cas
d'utilisation auxquels ils se rapportent
¨ Structurer les cas d'utilisation pour faire apparaître les
comportement partagés (relation d'inclusion), les cas particuliers
(généralisation/spécialisation) ou options (relation d'extension)

77
Exercice
Dans un magasin, un commerçant dispose d’un système de
gestion de son stock d’articles, dont les fonctionnalités sont les
suivantes :
¤ Edition de la fiche d’un fournisseur

¤ Possibilité d’ajouter un nouvel article (dans ce cas, la fiche


fournisseur est automatiquement éditée. Si le fournisseur
n’existe pas, on peut alors le créer)
¤ Edition de l’inventaire. Depuis cet écran, on a le choix
d’imprimer l’inventaire,d’effacer un article ou d’éditer la
fiche d’un article).
Modéliser cette situation par un diagramme de cas d’utilisation
79
80

2.
Diagramme de collaboration (ou
communication)
diagrammes de collaboration
Objectifs du diagramme de collaboration

¨ Le diagramme de collaboration permet de mettre en


évidence les interactions entre les différents objets du
système.
¨ Dans le cadre de l’analyse, il sera utilisé
¤ pour préciser le contexte dans lequel chaque objet évolue
¤ pour mettre en évidence les dépendances entre les
différents objets impliqués dans l’exécution d’un processus
ou d’un cas d’utilisation.
¨ Un diagramme de collaboration fait apparaître les
interactions entre des objets et les messages qu’ils
échangent.
diagrammes de collaboration
Les interactions

¨ Une interaction définit la communication entre les


objets sous la forme d’un ensemble partiellement
ordonné de messages.
¨ L’objet émetteur envoie un message à l’objet
récepteur.
¨ Les objets représentés sont des instances d’entités ou
des acteurs que l’on pourra représenter.

nom de l’objet nom de l’objet : Classe : Classe :Personne


diagrammes de collaboration
Les interactions, exemple
diagrammes de collaboration
messages

¨ Les messages sont le seul moyen de communication


entre les objets.
¨ Ils sont décrits essentiellement par l’objet émetteur
et l’objet récepteur.
¨ Leur description peut être complétée par un nom,
une séquence, des arguments, un résultat attendu,
une synchronisation, une condition d’émission.
¨ La séquence permet de préciser l’ordre d’émission
des messages.
diagrammes de collaboration
messages

r c he prix
1 : demande devis : rec he
2 : Produit

4 : devis 3:
calc
:Client ul risto
:Commercial urn : Catégorie client
e

¨ Le message 1 peut avoir comme arguments l’intitulé


du produit souhaité, la quantité et la catégorie du
client.
diagrammes de collaboration
messages

r ec he rc he
1 : demande devis (nom 2: ro duit,
m p
produit, quantité, nom prix(no ntité)
catégorie) qua : Produit

3:
4 : devis (montant calc
ul r
i
:Client calculé) :Commercial caté stourn : Catégorie client
gor e
ie) (nom
diagrammes de collaboration
messages

¨ Certains messages peuvent solliciter un résultat.


Ce cas peut être modéliser de 2 façons :
¤ un message de demande et un message de
réponse
¤ indiquer sur le premier message le résultat
attendu (lorsque le message en retour est
attendu immédiatement).
¨ Ici, le message émis par le gérant implique la
restitution immédiate du résultat du calcul : la valeur
du stock.
diagrammes de collaboration
messages
diagrammes de collaboration
messages

¨ l’émission de message peut également être soumis à


une condition, qui s’exprime alors sur le texte du
message.

¨ demande de réapprovisionnement n’est envoyée au


magasinier que lorsque la quantité en stock est
inférieure au seuil de réapprovisionnement.
Exemple

6: Débit compte

4: Retrait liquide(220F)
:Guichetier :Système Central
7:
Au
dé tori
3: liv sat
De ran ion 5: Vérification solde
ce
d’ man compte
op d
ér e t
at yp
io
n e

1: Saisie compte 2: Validation compte


:Système Guichetier
91

3.
Diagramme de séquence
Diagramme de séquences
¨ Représenter les interactions entre objets en précisant la
chronologie des échanges de messages
¨ Représente une instance d’un cas d’utilisation (les scénarios
possible d’un cas d’utilisation donné)
¨ Montre sous forme de scénarios, la chronologie des
envoies de messages issus d’un cas d’utilisation
¨ Le diagramme de séquence fait ressortir :
¤ Les acteurs
¤ Les objets
¤ Les messages

92
Diagrammes de séquence
¨ Le diagramme de séquence est une variante du
diagramme de collaboration.
¨ Par opposition aux diagrammes de collaboration,
les diagrammes de séquence possèdent
intrinsèquement une dimension temporelle mais ne
représente pas explicitement les liens entre les
objets.
¨ Ils privilégient ainsi la représentation temporelle à
la représentation spatiale et sont plus aptes à
modéliser les aspects dynamiques du système.
Diagrammes de séquence
¨ En revanche, ils ne rendent pas compte du contexte des
objets de manière explicite, comme les diagrammes de
collaboration.
¨ Le diagramme de séquence permet de visualiser les
messages par une lecture de haut en bas. L’axe vertical
représente le temps, l’axe horizontal les objets qui
collaborent. Une ligne verticale en pointillé est attachée
à chaque objet et représente sa durée de vie.
¨ Les messages sont représentés comme dans le
diagramme de collaboration.
¨ (NB : un message de retour sera représenté avec des
traits en pointillés)
Diagramme de séquences
¨ Un objet est représenté par un rectangle et une ligne verticale
(ligne de vie de l’objet)
¨ Les objets communiquent en échangeant des messages
représentés par des flèches orientées de l’émetteur au récepteur
¨ Un message reçu par un objet déclenche l’exécution d’une
opération
¨ Un message envoyé par objet correspond :
¤ Demander un service d’un autre objet

¤ Renvoyer le résultat d’une opération

¨ L’ordonnancement verticale des messages indique la chronologie


95
Diagramme de séquences
Obj et_1 Obj et_2 Obj et_3

Message_1

Message_2

Li gne de vi e de
l 'obj et

96
La ligne de vie
¨ La ligne de vie des objets est représentée par une
ligne verticale en traits pointillés, placée sous le
symbole de l’objet concerné. Cette ligne de vie
précise l’existence de l’objet concerné durant un
certain laps de temps.
¨ En général, une ligne de vie est représentée sur
toute la hauteur du diagramme de séquence. Par
contre, elle peut débuter et s’interrompre à
l’intérieur du diagramme.
Diagramme de séquences :
Exemple

Le client demande un service (déposer de l’argent) à l’objet Compte


Le compte reçoit le message et déclenche l’opération de même nom
Le compte retourne le résultat (le solde actuel)
98
Exemple de diagrammes de séquence
Diagramme de séquences
Plusieurs concepts additionnels :
¨ Période d’activité

¨ Types de messages

¨ Création et destruction d’objets

¨ Structures de contrôles

100
Période d’activité
¨ Correspond au temps pendant lequel un objet fait
une action
¨ Représentée par une bande rectangulaire
superposée à la ligne de vie de l’objet

101
Messages
¨ Traduisent les interactions (échange d’informations)
entre objets
¨ Représentés par des flèches orientées de l’émetteur
au récepteur
¨ Plusieurs types :
¤ Message simple
¤ Message minuté (Timeout)
¤ Message synchrone
¤ Message asynchrone
¤ Message récursif

102
Message simple
Message pour lequel on ne spécifie aucune
information d’envoi ou de réception
Objet_1 Objet_2

Message_1

103
Message minuté (Timeout)
¨ Bloque l’expéditeur pendant un temps donné, en
attendant la prise en compte du message par le
récepteur
¨ Après le délai, l’expéditeur est libéré et peut
envoyer Objet_2 Objet_1

Message_1 (20 secondes)

104
Message minuté (Timeout) :
Exemple
La porte d’un ascenseur s’ouvre pendant un certain
délai avant d’être refermée.
Ascenseur Porte

ouvrir (2 secondes)

fermer

105
Message synchrone
¨ Le message synchrone est le plus fréquemment
utilisé. Son emploi signifie que l’expéditeur du
message attend que l’activation de la méthode
invoquée chez le destinataire soit terminée avant
de continuer son activité.
Message synchrone (appel de
procédure) : Exemple
Communication client serveur : Sockets
Client Serveur

Sollitation

Acceptation

RequÍ te

RÈponse

107
Message asynchrone
¨ Dans le cas du message asynchrone, expéditeur
n’attend pas la fin de l’activation de la méthode
invoquée chez le destinataire. Ceci se produit lors
de la modélisation d’un système où les objets
peuvent fonctionner en parallèle.
Les messages récursifs (ou réflexifs)
¨ Un objet peut s’envoyer un message.
¨ Cette situation se représente par une flèche qui
revient en boucle sur la ligne de vie de l’objet.
Message récursif : Exemple
Lorsque le client introduit sa carte de guichet, ce
dernier vérifie la validité de la carte avant de
demander le code d’accès
Client GAB

Introduire carte

VÈrification validitÈ

Demande code accËs

110
Annotations temporelles
¨ Des annotations temporelles concernant les
messages peuvent également être ajoutées.
¨ Exemple :
Création et destruction d’objet
¨ la création se représente en faisant pointer le
message de création sur le rectangle qui symbolise
l’objet créé.
¨ La destruction est indiquée par la fin de la ligne de
vie et par une croix (X), soit à la hauteur du
message qui cause la destruction, soit après le
dernier message envoyé par un objet qui se suicide.
Création et destruction d’objets
Un message peut créer ou détruire un objet
Objet_1 Objet_3

Message_1
Objet_2

Création d’objet
Message_2

Objet créé au cours de l’exécution du scénario Destruction d’objet

Objet détruit dans un scénario

113
Création et destruction d’objet
Exemple

: Système guichet : Système central


: Guichetier

Saisie compte
Validation compte
Demande type d’opération

Retrait liquide(220F)

Vérification solde compte

Autorisation délivrance Débit compte


temps
Traduction des messages
¨ Envoyer un message c’est demander un service d’un
autre objet (sauf le cas d’un message de retour).
¨ Les messages sont traduits par des opérations dans
la classe de l’objet ayant reçu le message

116
Traduction des messages
class Voiture{
Public void demarrer(){}
}
class Conducteur{
private Voiture voiture;
public void conduire(){
voiture.demarrer();
}
}
… main(String[] arg){
conducteur.conduire();
}

117
Structures de contrôle
Le diagramme de séquences peut inclure un certain
nombre de structures
¨ Branchements (tests)

¨ Répétitions (itérations, boucles)

118
Les test (branchements)
La condition précéde le message et elle est délimitée
par des crochets
Objet_1 Objet_2 Objet_3

[condition]: Message

119
Les test (branchements) : Exemple
Pour accéder au centre de recherche, l’utilisateur doit
présenter son badge. S’il a droit d’accès, un voyant
vert est allumé et la porte s’ouvre
Utilisteur SystËme

PrÈsente son badge

VÈrifier droit d'accËs


[OK]voyant vert

ouvrir porte

120
Les cadres d’interaction
¨ Un cadre d’interaction est une partie du diagramme
de séquence associé à une étiquette. Elle contient un
opérateur qui en détermine la modalité d’exécution.
Les principales modalités sont le branchement
conditionnel et la boucle.
L’alternatif
¨ L’alternatif s’obtient en utilisant l’opérateur apt suivi
d’une condition de test.
¨ Si la condition est vérifiée, le contenu du cadre est
exécuté.

apt[condition]
La boucle
¨ La boucle est réalisée par l’opérateur loop suivi des
paramètre min, max et d’une condition de test.
¨ Le contenu du cadre est exécuté min fois , puis tant
que la condition de test est vérifiée et tant que le
nombre maximal d’exécutions de la boucle ne
dépasse pas max. chaque paramètre est optionnel.
loop[min, max, condition]
Exemple de cadre
Tant que x>0 faire

Si x>0 alors

Si x<0 alors

124
Utilisation des cadres d’interaction

: Vecteur : Tableau

somme=0

loop
get (index)

Valeur retour
[index=0,
index<tailleTableau-1]
somme=somme+valeur
126
127

4.
Diagrammes de CLASSES
Notion de classe
¨ Définition : une classe est une description abstraite
(condensée) d’un ensemble d’objets du domaine de
l’application : elle définit leur structure, leur comportement et
leurs relations.
Diagramme de classes
¨ Le diagramme de classes exprime la structure statique du
système en termes de classes et de relations entre ces
classes.
¨ L’intérêt du diagramme de classe est de modéliser les
entités du système d’information.
¨ Le diagramme de classe permet de représenter
l’ensemble des informations finalisées qui sont gérées par
le domaine.
¨ Ces informations sont structurées, c’est-à-dire qu’elles sont
regroupées dans des classes. Le diagramme met en
évidence d’éventuelles relations entre ces classes.
Représentation d’une classe
¨ Une classe est représentée par un rectangle séparé en 3
parties :
¨ La 1ière partie contient le nom de la classe

¨ La 2e partie contient les attributs de la classe

¨ La 3e partie contient les méthodes (ou opération) de la

classe
¨ Pour des raisons de lisibilité, on peut masquer ou non une de
ces parties
Nom Classe
attribut1 : type
attribut2 : type = valeur
methode1(args)
methode2():type
Représentation d’une classe

¨ Les compartiments d’une classe peuvent être


supprimés (en totalité ou en partie) lorsque leur
contenu n’est pas pertinent dans le contexte d’un
diagramme.
¨ La suppression des compartiments reste purement
visuelle : elle ne signifie pas qu’il n’y a pas
d’attribut ou d’opération.
Notion d’attribut
¨ Définition : Une classe correspond à un concept global
d’information et se compose d’un ensemble
d’informations élémentaires, appelées attributs de
classe.
¨ Un attribut représente la modélisation d’une information
élémentaire représentée par son nom et son format.
Notion d’opération

¨ Définition : l’opération représente un élément de


comportement des objets, défini de manière
globale dans la classe.
¨ Une opération est une fonctionnalité assurée par
une classe. La description des opérations peut
préciser les paramètres d’entrée et de sortie ainsi
que les actions élémentaires à exécuter.
L’encapsulation
¨ UML définit 4 niveaux de visibilité pour les
éléments:
¤ 1- public (+) : l’élément est visible pour tous les clients
de la classe
¤ 2- protégé (#) : l’élément est visible pour les sous-
classes de la classe
¤ 3- privé (-) : l’élément n’est visible que par les objets
de la classe dans laquelle il est déclaré.
¤ 4- paquetage (~) : l’élément est visible seulement dans
les classes du même paquetage.
Forme complète de représentation
des classes
¨ La représentation complète des classes fait apparaître
les attributs avec leur caractéristique d’encapsulation,
leur type et les méthodes avec leur signature complète
¨ Il est possible également de donner des valeurs par
défaut aux attributs et aux paramètres d’une méthode.

Nom Classe
+ nomAttribut1 : typeAttribut1=valeurDéfaut
# nomAttribut2 : typeAttribut2=valeurDéfaut
+ nomAttribut3 : typeAttribut3=valeurDéfaut

+ nomMethode1( param1:typeParam1= valeurDéfaut , param2:typeParam2) : typeRetour


# nomMethode2( param:typeParam= valeurDéfaut ) : typeRetour
Notion de relation

¨ S’il existe des liens entre objets, cela se traduit


nécessairement par des relations qui existent entre
leurs classes respectives.
¨ Les liens entre les objets doivent être considérés
comme des instances de relations entre classes.
¨ Il existe plusieurs types de relations entre classes :
¤ l’association
¤ la généralisation/spécialisation

¤ la dépendance
Association

¨ L’association est la relation la plus courante et la


plus riche du point de vue sémantique.
¨ Une association est une relation statique n-aire (le
plus souvent : elle est binaire) : c’est-à dire qu’elle
relie plusieurs classes entre elles.
¨ Une association n-aire possède n rôles qui sont les
points terminaux de l’association ou terminaisons.
¨ Chaque classe qui participe à l’association joue un
rôle.
Cardinalité des associations

¨ elle définit le nombre d’instances de l’association


pour une instance de la classe. La multiplicité est
définie par un nombre entier ou un intervalle de
valeurs. La multiplicité est notée sur le rôle (elle est
notée à l’envers de la notation MERISE).
Associations
Remarques
¨ une association fonctionne (généralement) dans les

2 sens (bidirectionnelle)
¨ termes associés : Nom, Sens de lecture, degré

(arité), Multiplicité, Rôle, navigabilité et le


qualificateur

139
Associations
Nom et sens de lecture
¨ Décrit la nature (signification) de l’association
¨ Montre la direction de lecture de l’association

140
Associations
Rôle d’une association
Décrit le rôle d’une classe dans une association

141
Associations
Rôle d’une association
Utile surtout dans deux cas :
¤ Lorsqu’on a plusieurs associations entre deux classes
avec des rôles différents
¤ une relation réflexive : relation entre deux instances
d’une même classe
Pilote Personne Personne
Avion 0..4
femme

Passager
0..1
mari

142
Associations
Classe association
Une association peut avoir des attributs = classe-association

143
Associations
Classe association
¨ Les classes association sont utiles quand il y a des
attributs qui sont pertinents à l’association, mais à
aucune des classes impliquées.

Personne Entreprise
1..*
0..1

Emploi
- PÈriode : int
- Salaire : float

144
Associations

n degré d’une association = nombre de classes participantes


§Association unaire : relie 2 instances d'une classe
§association binaire : relie 2 classes
§ association ternaire : relie 3 classes
§ association n-aire : relie n classes

145
Associations

Multiplicité = nombre de participations d’une classe dans une


association
§ indiquée à chaque extrémité d’une association
§ sous la forme min..max
§ min, max = 0, 1, *
n Exemple général

n Exemple concret

146
Associations

n Exemple ternaire

§ Pour un couple d’instances de la classe A et de la classe B,


il y a au min. r1 instances de la classe C et au max. r2 instances,
§…
§…
147
Associations

Notation abrégée des multiplicités :

1 Û 1..1 (exactement 1)
* Û 0..* (0 ou plusieurs)
n Û n .. n (exactement n)
1..* Û 1 ou plusieurs (1 ou plus)
0..1 Û 0 ou 1 (au plus un)
1..100 Û entre 1 et 100
2,4,5 Û 2, 4 ou 5

148
Association
Navigabilité
¨ Une association est par défaut bidirectionnelle.
Commandes Clients
1..*
1

¨ Cependant, il peut être utile de se limiter à une


seule direction è association navigable

149
Association
Navigabilité (Exemple)
¨ Spécification : on doit être en mesure de savoir le client
qui a fait la commande et non toutes les commandes d’un
client
¨ Conception :
Commandes Clients
1..*
1

¨ Implémentation : la classe commande doit avoir un champ


faisant référence à la classe client

150
Qualification d'une association
¨ La qualification d’une association permet de
restreindre la multiplicité d’une association.
¨ La qualification se représente par un rectangle
placé au niveau de la classe source du qualificatif.

151
Qualification d'une association
Exemple : une banque contient plusieurs comptes, d'où
le diagramme :
Banque Compte
1 1..*

Par contre, si on connaît le N°Compte, il y a un


et un seul compte, on obtient alors :

Compte
Banque NCompte
1 1

152
Composition/Agrégation

¨ Dans UML, l’agrégation et la composition ne sont


pas des types de relation mais des variantes de
l’association.
¨ Elles représentent une association non symétrique
dans laquelle une des extrémités joue un rôle
prédominant par rapport à l’autre extrémité.
¨ Elles ne peuvent concerner qu’un seul rôle d’une
association.
Agrégation
Type particulier d’association dans laquelle :
n Classe agrégat (composé), classes agrégée (composant)
n Entre les deux, il existe une relation de type « est
composé de »

Agrégat Agrégée

154
Agrégation
¨ Les parties (les composants) sont séparables de
L’agrégat (le tout)
¨ La suppression d’une équipe n’implique pas la
suppression des personnes qui la composent

155
Agrégation
Titre

Un agrégat (composé) peut être multiple.


0..1

1..1

Destinataire E-Mail Fichier


1..* 0..*
* 0..*

Ici, on exprime qu'un fichier peut être attaché à un email (ou a


1..1 plusieurs, ou même à aucun) et qu'un email peut (ou non)
attacher (contenir une copie) une ou plusieurs fichiers.

0..1

Texte

156
Composition
¨ La composition est un cas particulier d’une
agrégation dans laquelle la vie des composants
(élément) est liée à celle de l’agrégat (composé) : si
l’agrégat est détruit (ou déplacé), ses composants le
sont aussi.
¨ D’un autre côté, et contrairement à l’agrégation,
une instance de composant ne peut être liée qu’a un
seul agrégat.
¨ La composition se représente par un losange noir
(plein).

157
Composition

n la suppression d’un objet agrégat entraîne la suppression des


objets agrégés

158
Composition
¨ Un document est composé de plusieurs
paragraphes, qui, à son tour, est composé de
plusieurs phrases
¨ Remarquer la propagation des opérations (copie,
suppression,…)

159
Généralisation / Spécialisation et
héritage
¨ La généralisation est la relation entre une classe et
une ou plusieurs de ses versions raffinées.
¨ On appelle la classe dont on tire les précisions la
super-classe et les autres classes les sous-classes.
¨ C’est une relation de type « est un (is a) » ou « est
une sorte de ».
¨ La notation utilisée pour la généralisation est le
triangle

160
Généralisation / Spécialisation et héritage

n généraliser = mettre en facteur des classes ® « super-classe »


n spécialiser = décrire de nouveaux détails ® « sous-classes »

n comparable à une association de type « est un, is a, kind of »


n une sous-classe hérite des attributs et opérations de sa super-classe
161
(classe mère)
Généralisation / Spécialisation et
héritage
La classe spécialisée (sous-classe)
¨ hérite les méthodes et les attributs de la classe

générale (super-classe)
¨ peut ajouter ses propres attributs et méthodes.

¨ peut redéfinir le comportement d’une méthode.

162
Généralisation / Spécialisation et
héritage
Compte
- N°Compte : String
- Solde : float
+ <<Constructor>> Compte ()
+ Déposer (float Somme) : void
+ Retirer (float Somme) : float
+ AvoirSolde () : String

CompteEpargne
- Taux : float
+ AvoirSolde () : String

163
Généralisation / Spécialisation et
héritage
Remarques
¨ La généralisation et la spécialisation sont deux

façons pour voir la même relation, top-down


(spécialisation) ou bottom-up (généralisation).
¨ L'héritage est l’implémentation de la relation de la

généralisation/spécialisation.
¨ Une classe peut hériter de plusieurs classes, on

parle alors d’un héritage multiple.

164
Généralisation / Spécialisation et
héritage
Personnes
- Code : int
- Nom : String
+ <<Constructor>> Personnes (int Code, String Nom)
+ getNom () : String
+ getInf () : String

Spécialisation Super classe, classe mère


Généralisation
Etudiants
- Salaire : float
+ <<Constructor>> Etudiants (int Code, String Nom, float Salaire)
+ getInf () : String
+ getSalaire () : float

Employes
Sous classes - Filiere : String
Classes filles + <<Constructor>> Employes (int Code, String Nom, String Filiere)
Classes dérivées + getInf () : String
+ getFiliere () 165 : String
Généralisation / Spécialisation

n une classe peut hériter de plusieurs super-classes


= héritage multiple

166
Généralisation / Spécialisation

n polymorphisme = opérations de même nom, polymorphisme


= comportement spécifique

167
Exercice
¨ Soient les phrases suivantes :
¨ Un répertoire contient des fichiers

¨ Une pièce contient des murs

¨ Les modems et claviers sont des périphériques d’entrée

/ sortie
¨ Un compte bancaire peut appartenir à une personne

physique ou morale
Elaborez les diagrammes de classe correspondants à chaque
phrase en choisissant le type de relation approprié
Contraintes sur les associations
¨ Concepts avancés des associations
¨ Permettent d’imposer des règles à respecter lors du
passage à l’implémentation
¨ Il est possible d’attribuer toutes sortes de
contraintes à une association
¨ Les contraintes sont représentées entre accolades et
peuvent être exprimées dans n’importe quel
langage (y compris OCL)

169
Contraintes sur les associations
Les contraintes (prédéfinies) souvent utilisées :
¤ {ordonné}
¤ {sous ensemble}

¤ {xor}

¤ {addOnly}

¤ {frozen}

170
Contraintes sur les associations
contrainte {ordonné}
Indique que les objets seront ordonnés à chaque
opération de création, modification, suppression, …

Personne Compte
1 0..*
{OrdonnÈ}

Les comptes d’une personne sont ordonnés

171
Contraintes sur les associations
contrainte {sous-ensemble}
¨ Indique qu’une collection est incluse dans une autre
¨ Nécessite la présence d’au moins deux relations

Ecole Parent d’élève Personnes


1..*
{sous-ensemble}
Délégué
1..*

Les personnes qui jouent le rôle de délégué font partie des personnes
qui jouent le rôle de parents d’élèves

172
Contraintes sur les associations
contrainte {xor}
Indique que parmi un groupe d’associations, une seule
est valide à la fois
Batterie

PC Portable 1
{xor}
Un PC Portable est alimenté soit à partir
1
d’une batterie, soit à partir d’un secteur

1 Secteur

173
Contraintes sur les associations
contrainte {addOnly}
La contrainte prédéfinie {addOnly} autorise l’ajout de
nouveaux objets, mais pas leur suppression ni leur
mise à jour.
Personne Liste
1..*
1

0..*
{addOnly}

Enfants

174
Contraintes sur les associations
contrainte {frozen}
La contrainte prédéfinie {frozen} interdit l’ajout, la
suppression ou la mise à jour des liens d’un objet
vers les objets de la classe associée, après
l’initialisation du premier.
Personne
{frozen} 0..*
enfant
2
parent

175
Exemple de diagramme de classes
(Distributeur Automatique de Banque : DAB)

176
Classe « Interface »
¨ Une interface définit le comportement visible d’une
classe. Ce comportement est défini par une liste
d’opérations ayant une visibilité « public ». Aucun
attribut ou association n’est défini pour une interface.
¨ Une interface est une classe spéciale dont toutes les
méthodes sont abstraites
Classe « Interface »
¨ Une interface est une classe spéciale dont toutes les
méthodes sont abstraites

Forme

178
Etapes pour établir un diagramme de
classe

A partir d’une description du système :

1. Identifier un premier ensemble de classes candidates


2. Identifier les associations et les attributs
3. Identifier les généralisations
4. Lister les traitements, choisir les opérations
5. Vérifier le modèle obtenu

a. Supprimer les transitivités


b. S’assurer que le schéma répond à la demande
6. Itérer jusqu’à satisfaction …

179
Règles d’élaboration

¨ Les règles de normalisation des modèles entité-


relation, issues de l’algèbre relationnelle, peuvent
être utilement appliquées à un modèle de classes
UML, même si UML ne contient aucune préconisation
sur ces règles.
¨ Ces règles aident à conduire les travaux de
modélisation en évitant le plus possible la
redondance de l’information, tout en restant fidèle
aux règles de gestion.
Diagramme de classe: Exercice
Créer le diagramme de classe d’un système de gestion des livres de la
bibliothèque de l’IBAM qui respectera les règles de gestion suivantes :
¨ Pour chaque livre, on doit connaître le titre, l'année de parution, un résumé
et le type (roman, poésie, science fiction, ...).
¨ Un livre peut être rédigé par aucun (dans le cas d'une œuvre anonyme), un
ou plusieurs auteurs dont on connaît le nom, le prénom, la date de
naissance et le pays d'origine.
¨ Chaque exemplaire d'un livre est identifié par une référence composée de
lettres et de chiffres et ne peut être paru que dans une et une seule édition.
¨ Un inscrit est identifié par un numéro et on doit mémoriser son nom, prénom,
adresse, téléphone et adresse e-mail.
¨ Un inscrit peut faire zéro, un ou plusieurs emprunts qui concernent chacun un
et un seul exemplaire. Pour chaque emprunt, on connaît la date et le délai
accordé (en nombre de jours).
Cas pratique: Réservation de vols

Soit le cas ’’Réservation de vols dans une agence de voyage’’


1° Des compagnies aériennes proposent différents vols.
2° Un vol est ouvert à la réservation et fermé sur ordre de la compagnie.
3° Un client peut réserver un ou plusieurs vols, pour des passagers différents.
4° Une réservation concerne un seul vol, et un seul passager.
5° Une réservation peut être annulée ou confirmée.
6° Un vol a un aéroport de départ et un aéroport d’arrivée.
7° Un vol a un jour et une heure de départ et un jour et une heure d’arrivée.
8° Un vol peut comporter des escales dans des aéroports
9° Une escale a une heure d’arrivée et une heure de départ.
10° Chaque aéroport dessert une ou plusieurs villes

REF : O. BOUSSAID
Cas pratique: Réservation de vols
Ø Modélisation de la phrase :
1° Des compagnies aériennes proposent différents vols.

CompagnieAerienne et Vols sont 2 objets métiers : 2 classes

CompagnieAerinne Propose Vol


1..*

• Un vol est réalisé par une seule compagnie mais partagé par plusieurs affréteurs

CompagnieAerinne Propose Vol


1..* 1..*
affréteur

REF : O. BOUSSAID
Cas pratique: Réservation de vols
Ø Modélisation de la phrase :
2° Un vol est ouvert à la réservation et fermé sur ordre de la compagnie.
CompagnieAerinne Propose Vol
1..* 1..*
état (ouvert, fermé)
affréteur

Ø Tout objet peut avoir un état (diagramme d’états).


Ø Dans un diagramme de classes tout concept dynamique est modélisé en opération.

Ø Il faut représenter la 2° phrase par 2 opérations : ouvrirVol( ) et fermerVol( )


Ø Dans quelle classe ?

CompagnieAerinne Propose Vol


1..* 1..*
affréteur
ouvrirVol( )
fermerVol( )

Ø Les opérations sont déclarées dans l’objet dans lequel elles doivent s’exécuter
Ø Les autres pourront déclencher ces opérations par envoi de messages
Ø Le classe CompagnieAerienne a une association avec la classe vol.
REF : O. BOUSSAID
Cas pratique: Réservation de vols
Ø Modélisation des phrases :
7° Un vol a un jour et une heure de départ et un jour et une heure d’arrivée.
Ø Les dates et les heures de départ et d’arrivée ne représentent que des valeurs : attributs.

CompagnieAerinne Propose Vol


1..* 1..*
dateDepart
affréteur heureDepart
dateArrivee
heureArrivee

ouvrirVol( )
fermerVol( )

Ø Pour savoir si un élément doit être représenté en attribut ou en objet :


Ø S’il n’ y a que sa valeur qui est intéressante : c’est plutôt un attribut.
Ø Si plusieurs questions peuvent concerner l’élément, alors il faut le représenter en objet.

REF : O. BOUSSAID
Cas pratique: Réservation de vols
Ø Modélisation des phrases :
6° Un vol a un aéroport de départ et un aéroport d’arrivée.
Ø Par quoi peut-on représenter l’élément ‘’Aéroport’’ ?
3 réponses sont envisageables :

1. Soit avec une classe et une association de multiplicité 2

Vol
dateDepart Aéroport
heureDepart 2
dateArrivee nom
heureArrivee
aeroportDepart
aeroportArivvee

ouvrirVol( )
fermerVol( )

F Modélisation peu parlante.


REF : O. BOUSSAID
Cas pratique: Réservation de vols
Ø Modélisation des phrases :
6° Un vol a un aéroport de départ et un aéroport d’arrivée.

2. Soit avec 2 classes

Vols
dateDepart 1 AeroportDepart
heureDepart
dateArrivee Aéroport
heureArrivee
nom
aeroportDepartr 1
aeroportArivvee AeroportArrivee

ouvrirVol( )
fermerVol( )

F Modélisation non correcte. Tout aéroport peut être de départ et d’arrivée.

REF : O. BOUSSAID
Cas pratique: Réservation de vols
Ø Modélisation des phrases :
6° Un vol a un aéroport de départ et un aéroport d’arrivée.

2. Soit avec 2 associations

Vol
dateDepart Départ
Aéroport
heureDepart
dateArrivee 1 Nom
heureArrivee …
Arrivée

1
ouvrirVol( )
fermerVol( )

F Le rôle de chaque association précise son sens.


REF : O. BOUSSAID
Cas pratique: Réservation de vols

Ø Modélisation des phrases :


10° Chaque aéroport dessert une ou plusieurs villes

Ø On ne peut pas savoir la multiplicité de ‘’Aéroport’’

Aéroport dessert Ville

0..* 1..*

Ø Si on considère que desservir une ville signifie l’aéroport le plus proche, il n’ en y a qu’un :
la multiplicité est de 1
Ø Si on considère que desservir une ville signifie les aéroports dans un rayon de 35 km :
la multiplicité est de 0..*

REF : O. BOUSSAID
Cas pratique: Réservation de vols
Ø Modélisation des phrases :
8° Un vol peut comporter des escales dans des aéroports
9° Une escale a une heure d’arrivée et une heure de départ.

Ø Une escale a les propriétés heure d’arrivée et heure de départ, c’est donc un objet.

Vol
dateDepart Depart Aéroport
heureDepart
dateArrivee 0..* 1 nom
heureArrivee
Arrivee
ouvrirVol( )
fermerVol( ) 0..* 1
1
1..*

Ø Quelles sont alors les multiplicités entre Escale


‘’Vols’’ et ‘’Escale’’, entre ‘’Escale’’ et heureArrivee
‘’Aeroport’’ et entre ‘’Aeroport’’ et ’Vols’’ ? heureDepart
0..* 0..*

REF : O. BOUSSAID
Cas pratique: Réservation de vols
Ø Modélisation des phrases :
8° Un vol peut comporter des escales dans des aéroports
9° Une escale a une heure d’arrivée et une heure de départ.
Ø ‘’Escale’’ a peu d’informations propres. Elle n’est qu’une partie de ’’Vol’’ .
Ø On peut la représenter comme une spécialisation de ’’Aéroport’’ . Mais elle n’est pas totalement un aéropor
Ø La meilleure solution serait de la modéliser comme une classe d’association entre et ’Vols’’ et ‘’Aéroport’’.
Vol Départ
dateDepart Aéroport
0..* 1
heureDepart
Arrivée nom
dateArrivee
heureArrivee
0..* 1
ouvrirVol( )
Escale
fermerVol( )
0..* 0..*

Escale

heureArrivee
heureDepart

REF : O. BOUSSAID
Cas pratique: Réservation de vols
Ø Modélisation des phrases :
4° Une réservation concerne un seul vol, et un seul passager.
5° Une réservation peut être annulée ou confirmée.

Ø La réservation et le passager sont 2 concepts métier : 2 classes d’objets


Ø Un réservation concerne un seul vol et un seul passager: donc 2 associations entre ‘’Vol’’ et
’’Réservation’’ et entre ’’Réservation’’ et ‘’Passager’’.
Ø La 5° phrase se traduit par l’ajout de 2 opérations annuler( ) et confirmer( ) dans ‘’Reservation’’.
Réservation Vol
concerne dateDepart
heureDepart
Annuler( ) 1 dateArrivee
Confirmer( )
heureArrivee
ouvrirVol( )
fermerVol( )
concerne

Passager

REF : O. BOUSSAID
Cas pratique: Réservation de vols

Ø Modélisation des phrases :


3° Un client peut réserver un ou plusieurs vols, pour des passagers différents.

Ø Il faut discerner un client d’un passager

Réservation
Client 1 a effectué 0..*
concerne Vol
Annuler( ) 0..* 1
Confirmer( )

0..*
concerne

1
Passager

REF : O. BOUSSAID
Cas pratique: Réservation de vols
Client
nom Prénom CompagnieAerinne
adresse nom
téléphone
e-mail 1..*
Propose
REF : O. BOUSSAID
1
a effectué
0..* 1..*
départ
Réservation Vol Aéroport
dateDepart 0..* 1
date concerne heureDepart nom
arrivée
numéro dateArrivee
0..* 1
Annuler( ) heureArrivee 0..* 1
Confirmer( )
ouvrirVol( ) escale
0..* fermerVol( )
0..* 0..*
concerne

1 InfosEscale
Passager heureArrivee Ville
heureDepart nom
nom Prénom
Cas pratique: Réservation de vols
Client
nom Prénom CompagnieAerinne
adresse nom
tél
e-mail
numéro
1..* REF : O. BOUSSAID
1 Propose
a effectué
0..* 0..1
départ
Réservation Vol Aéroport
dateDepart 0..* 1
date concerne heureDepart nom
arrivée
numéro dateArrivee
0..* 1
heureArrivee 0..* 1
Annuler( )
Confirmer( ) ouvrirVol( ) escale
0..* fermerVol( )
0..* 0..*
concerne

1 InfosEscale
Passager heureArrivee Ville
heureDepart nom
nom Prénom
197

5.
Diagrammes d’OBJETS
Définition

¨ Un diagramme d’objets est une instance d’un


diagramme de classes et illustre l’état d’un système
à un moment donné.
¨ Les diagrammes d’objets s’utilisent principalement :
¤ pour montrer un contexte
¤ pour faciliter la compréhension des structures de
données complexes
Définition (suite)

¨ Un diagramme d’objets est composé :


¤ d’objets (instances de classes),
¤ de liens (instances d’associations).
¨ La notation des diagrammes de collaboration ou de
communication est dérivée de la notation des
diagrammes d’objets.

nom de l’objet nom de l’objet : Classe : Classe :Personne


Objet

¨ L’état d’un objet est déterminé par les valeurs de


ses attributs :
¤ il est possible de nommer un état afin d’indiquer
clairement dans quel état se trouve un objet.
¨ Les représentations des objets peuvent contenir des
attributs significatifs.

:Ordinateur [calcule] :Voiture

vitesse = 100
Représentation de l’état d’un objet
couleur = rouge

Représentation des attributs significatifs


Objet

¨ Possibilité de modéliser les changements d’états des


objets :
<<devient>>
:Télévision [allumée] :Télévision [éteinte]

¨ Possibilité d’utiliser des liens stéréotypés (exemple :


la copie d’objets)
<<copie>>
A : Fichier Copie de A : Fichier
Diagramme d’objets
¨ Le nom d’un objet est souligné
¤ Nom : Classe
¤ Nom

¤ :Classe

202
Diagramme d’objets : exemple
Exemple :
¨ Une entreprise emploie au moins deux personnes

¨ Une personne travaille dans au plus deux entreprises

Entreprise
:Entreprise e1:Entreprise

0..2

2..*

Personne
:Personne p1:Personne p2:Personne p3:Personne p4:Personne

203
Objet : objet composite

¨ Représentation UML:
Lien

¨ Les objets sont reliés par des instances


d’associations : les liens.
¨ Un lien représente une relation entre objets à un
instant donné.
¨ ATTENTION : la multiplicité des extrémités des liens
est toujours de 1.
¨ Exemple : représentation de la structure générale
d’une voiture
Lien

¨ Les rôles des associations peuvent être représentés


explicitement :
Diagramme des classes (exemple)
Diagramme d’objets (exercice )

¨ Le système gère un seul bâtiment contenant trois


portes.
¨ Le système peut être géré par une personne
nommée Tolkien.
¨ Deux utilisateurs peuvent accéder au bâtiment :
¤ Gandalf a accès à la première (8h-18h) et seconde porte
(12h-24h)
¤ Bilbon a accès à la troisième porte toute la journée.
Diagramme d’objets (suite)
210

6.
Diagramme de packages
Diagramme de packages

¨ Un package est un ensemble de classes, de


composants, de cas d’utilisation et d'autres
packages, etc.
¨ C'est l'adaptation du concept de librairie ou

de bibliothèque.
¨ Servent à structurer l’ensemble des classes et

interfaces.
¨ Permet de structurer un système en plusieurs

parties, chacune représentée par un package .


Package
¨ Un package est représenté par un rectangle
possédant un onglet dans lequel est inscrit le nom
du package

212
Import des packages
¨ La relation d’import permet à une classe d’un
package d’utiliser les classes d’un autre package.
¨ La relation est monodirectionnelle : elle comporte un
package source et un package cible.

213
Import de packages
¨ La relation d’import s’exprime avec une flèche en
pointillé
¨ Dans l’exemple, la classe ‘Afficheur’ a besoin des
classes du package ‘Dessin’

214
Cas pratique: Réservation de vols
Client
nom Prénom CompagnieAerinne
adresse nom
téléphone
e-mail 1..*
Propose
REF : O. BOUSSAID
1
a effectué
0..* 1..*
départ
Réservation Vol Aéroport
dateDepart 0..* 1
date concerne heureDepart nom
arrivée
numéro dateArrivee
0..* 1
Annuler( ) heureArrivee 0..* 1
Confirmer( )
ouvrirVol( ) escale
0..* fermerVol( )
0..* 0..*
concerne

1 InfosEscale
Passager heureArrivee Ville
heureDepart nom
nom Prénom
Cas pratique: Réservation de vols
Client
nom Prénom CompagnieAerinne
adresse nom
téléphone
e-mail 1..*
Propose
REF : O. BOUSSAID
1
a effectué
0..* 1..*
départ
Réservation Vol Aéroport
dateDepart 0..* 1
date concerne heureDepart nom
arrivée
numéro dateArrivee
0..* 1
Annuler( ) heureArrivee 0..* 1
Confirmer( )
ouvrirVol( ) escale
0..* fermerVol( )
0..* 0..*
concerne

1 InfosEscale
Passager heureArrivee Ville
heureDepart nom
nom Prénom
Cas pratique: Réservation de vols

Réservations Vol

Réservation Vol
date dateDepart
numéro concerne dateArrivee
Annuler( ) 0..* 1
Confirmer( ) ouvrirVol( )
fermerVol( )

Ø Réduire la dépendance mutuelle afin d’augmenter la modularité


et l’évolutivité d’une application

REF : O. BOUSSAID
Cas pratique: Réservation de vols
Réservations Vol

Client CompagnieAerinne
nom Prénom nom
REF : O. BOUSSAID
adresse
téléphone 1..*
e-mail Propose

{frozen} 1
a effectué 1..*
0..* départ
Vol Aéroport
Réservation concerne dateDepart 0..* 1
date heureDepart arrivée nom
dateArrivee
numéro 0..* 1
heureArrivee 0..* 1
Annuler( )
Confirmer( ) ouvrirVol( ) escale
fermerVol( )
0..* 0..* 0..*
concerne

1 InfosEscale
Passager heureArrivee Ville
nom Prénom heureDepart nom
Cas pratique: Réservation de vols
REF : O. BOUSSAID
Généralisation et réutilisation
Ø On veut élargir ce domaine aux voyages par bus que des transporteurs assurent.
Ø Un voyage en bus à une ville de départ et un ville d’arrivée avec des dates et
des heures associées.
Ø Un trajet peut comporter des arrêts dans des villes intermédiaires.
Ø Un client peut réserver un ou plusieurs voyages pour un ou plusieurs passagers
ReservationsBus
VoyagesBus

ReservationBus
VoyageEnBus
date
concerne dateDepart
numéro
dateArrivee
0..* 1
Annuler( )
Confirmer( ) OuvrirVoyage( )
fermerVoyage( )
Cas pratique: Réservation de vols
ReservationsBus VoyagesBus
Client
nom Prénom Voyagiste
adresse nom
téléphone
e-mail

1 1
Propose
a effectué 0..1
0..*
VoyageEnBus départ
ReservationBus concerne
dateDepart 0..* 1 Ville
date heureDepart arrivée
{frozen}
numéro dateArrivee nom
heureArrivee 0..* 1
Annuler( )
/durée
Confirmer( ) ouvrirVoyage( ) arrêt
0..* fermerVoyage( ) 0..* 0..*
concerne

1..* InfosArret
Passager heureArrivee
heureDepart
nom Prénom
REF : O. BOUSSAID
Cas pratique: Réservation de vols
Fusion des 2 modèles

1. Il faut isoler les classes communes dans des packages


2. Il faut factoriser les propriétés communes

ΠAVION BUS

ReservationBus
ReservationVols

Vols VoyagesBus

Lieux
REF : O. BOUSSAID
Cas pratique: Réservation de vols

 Il faut isoler les classes communes dans des packages

Réservations
Classe
abstraite

Client Réservation concerne


nom Prénom a effectué Passager
date 0..* 1
adresse 1 0..* numéro nom Prénom
tél
Annuler( )
e-mail {frozen} Confirmer( )

ReservationVol ReservationBus
(from ReservationsVols)
(from ReservationsBus)

concerne concerne
1 {frozen} 1 {frozen}
Vol VoyageEnBus
(from Vols) (from VoyagesBus)
REF : O. BOUSSAID
Cas pratique: Réservation de vols

Package généralisé
Réservations

Packages spécialisés

ReservationsBus ReservationsVols

VoyagesBus Vols

Package réutilisable Lieux


REF : O. BOUSSAID
Exercice

Concevoir le diagramme de classe d’une application de gestion d’hôtel. Voici ce que vous
devez modéliser :

Un hôtel est constitué d'un certain nombre de chambres. Un responsable de l'hôtel gère la
location des chambres. Chaque chambre se loue à un prix donné.

L'accès aux salles de bain est compris dans le prix de la location d'une chambre. Certaines
chambres comportent une salle de bain, mais pas toutes. Les hôtes de chambres sans salle de
bain peuvent utiliser une salle de bain sur le palier. Ces dernières peuvent être utilisées par
plusieurs hôtes.

Les pièces de l'hôtel qui ne sont ni des chambres, ni des salles de bain (hall d'accueil,
cuisine...) ne font pas partie de l'étude (hors sujet).

Des personnes peuvent louer une ou plusieurs chambres de l'hôtel, afin d'y résider. En d'autre
termes : l'hôtel héberge un certain nombre de personnes, ses hôtes (il s'agit des personnes qui
louent au moins une chambre de l'hôtel...).
UML : DIAGRAMME D’ETATS-
TRANSITIONS
Exemple DAB: Encaissement d’argent

do: augmenter le montant


égler
) /r
ntant Article sélectionné
o
s (m [article vide]
e
ns éré [montant < prix article]
En i
èc es t
attente Pi ntan
mo Test d’article

do: tester articler et calculer la


monnaie à rendre
[montant = prix
article] [montant > prix article]

Distribution Encaissement
do: distribuer article do: rendre monnaie
Références
¨ Livre UML 2: UML 2 en action, de l’analyse des besoins à la conception
J2EE, Pascal Roques et Franck Vallée.
¨ Livre UML 2: Initiation, exemples et exercices Corrigés de Laurrent
Debrauwer et Fien Van der Heyde.
¨ Livre UML 2: Entraînez-vous à la modélisation de Laurrent Debrauwer et
Naouel Karam.
¨ Livre MERISE et UML, pour la modélisation des systèmes d’information de
Joseph Gabay.
¨ Livre Base de données objet & relationnel de George Gardarin
¨ Cours UML 2.0, Pr. Moussa LO, Université Gaston Berger de Saint-Louis.
¨ [Rapport Stage N. Fall], Conception et réalisation d’une application pour la
gestion pédagogique de l’UFR SAT, soutenue en 2010.
¨ [O. BOUSSAID] étude de cas : Réservation de vols dans une agence de
voyage, Diagramme des classes. Disponible sur Internet 2011.

Vous aimerez peut-être aussi