UML

Langage Unifié pour la

Modélisation Objet
M.TARIK BOUHASSE

1
Plan
• Présentation d’UML

• Modèle Fonctionnel (étude de cas)

• Modèles Statiques (étude de cas)

• Modèles Dynamiques (étude de cas)

• UML et les méthodologies de développement logiciel

• Conception centrée sur l ’architecture

2
Présentation d’UML
• Références
• Historique
• Principes généraux
• Axes de modélisation d ’un système
• Listes des Diagrammes
• Exemples : Quelques diagrammes
• Vocabulaire
• Paquetage
• Dépendance entre paquetages
• Stéréotypes :Mécanismes d ’extension
• Le processus : Principes
• Processus : rôle des cas d ’utilisation 3
Références

Livres : Grady Booch 1981, ADA, « Object Oriented Development »

James Rumbaugh 1991, OMT, JOOP (Journal of OO programming)
Ivar Jacobson, OOSE
sept 97, UML 1.1.
UML 2 par la Pratique (EYROLLS, Pascal Roques)
Références : http://www.omg.org
http://uml.free.fr/ site en français

Outils : Rational ROSE, http://www.rational.com

4
 Historique (1/2)
UML 2.0

OMG Acceptance, Nov 1997

UML 1.3
Final submission to OMG, Sep ‘97 UML 1.1
First submission to OMG, Jan ´97
public
feedback
UML partners UML 1.0

Web - June ´96 UML 0.9

OOPSLA ´95 Unified Method 0.8

Booch method OMT

Other methods OOSE
5
 Historique (2/2)
Harel
Meyer Gamma, et al
Statecharts
Before and after Frameworks and patterns,
conditions
HP Fusion
Booch
Operation descriptions and
Booch method message numbering

Embley
Rumbaugh
Singleton classes and
OMT
high-level view

Jacobson Wirfs-Brock
OOSE
Responsibilities

Shlaer - Mellor Odell

Object lifecycles Classification

6
Principes généraux (1/4)
 L ’orientation Objet
 Langage (Concepts, sémantique, méta-modèle, Notation)
 Indépendante d ’un processus
 Généricité de l ’approche
 Indépendante d ’un langage de programmation
 Indépendante d ’un type d ’architecture
 Indépendante d ’une classe de système
 Une capitalisation des bonnes pratiques de la C.O.O.

7
Principes généraux (2/4)
 Un langage de modélisation des systèmes
 systèmes logiciels (SI, télécomm..) ou autre
 Objectifs du langage
 pour documenter les besoins, les architectures, la conception, le
code...
 pour visualiser
 pour spécifier
 pour construire
 Un langage visuel
 Génération de 13 diagrammes

8
Principes généraux (3/4)
 Un langage unifiant les concepts et les notations du niveau métier et
informatique
 Objets de l’espace du problème et objets de l ’espace de la solution

 La description d’un système organisé selon une architecture 3tiers :

 les objets de l ’interface

 Les objets du serveur d ’application

 Les objets du serveurs de données

 Utilisation des concepts objet mais pas seulement

 Un noyau et des mécanismes d’extension

9
Principes généraux (4/4)
 Un système peut être modélisé selon différents points de vue
 Le point de vue des utilisateurs (spécification fonctionnelles)
 Le point de vue de l ’analyste (structurel, logique)
 Le point de vue constructeur (déploiement, matériel)
 Avec les facteurs de qualité nécessaires pour chaque point de vue

 Le résultat de la modélisation selon un certain point de vue est un ou plusieurs

modèles

 Un modèle est un ensemble de diagrammes

 La définition des vues (Quelles vues ?) et des modèles (quels diagrammes ?)

n’est pas figée

10
Axes de modélisation d ’un système
Statique (ce que le système EST)
Dynamique
(comment le système EVOLUE)
 diagramme de séquence
 diagramme de collaboration (d.Comm)
 diagramme d’états-transitions
 diagramme d’activités
 diagramme de classes
 diagramme d’objets
 diagramme de package
 diagramme de composants
 diagramme de déploiement
Fonctionnel
(ce que le système FAIT)
 diagramme de cas d’utilisation
 diagramme de collaboration (d.Comm)
diagramme d’activités
11
Liste des Diagrammes
Diagrammes structurels ou diagrammes
statiques (UML Structure)
D. de classes (Class diagram)
D. d’objets (Object diagram)
D. de composants (Component diagram)
D. de déploiement (Deployment
diagram)
D. de paquetages (Package diagram)
D. de structures composites (Composite
structure diagram)
Diagrammes comportementaux ou
diagrammes dynamiques (UML Behavior)
D.de cas d’utilisation (Use case diagram)
D. d’activités (Activity diagram)
D. d’états-transitions (State machine
diagram)
Diagrammes d’interaction (Interaction
diagram)
D. de séquence (Sequence diagram)
D. de communication (Communication
diagram)
D. global d’interaction (Interaction
overview diagram)
D. de temps (Timing diagram)
12
 Exemples : Quelques diagrammes
cas d'utilisation
Cas d’utilisation
une fonctionnalité attendue du système par les
différents acteurs.
Diagramme de Classes
objet 1
lien exprimant que "objet 2 est une sorte de objet 1"
lien exprimant que "objet 2
objet 2 a une relation avec objet 4"
lien expri mant que
"obj et 2 est
composé de objet 3"
objet 3
Système
: acteur ( intéragissant
avec le Système
message
message
message
message
Diagramme de séquence
A chaque cas d'utilisation, on peut associer un scénario,
objet 4 décrit par un diagramme de séquence.
Un diagramme de séquences montre les interactions
entre les acteurs et le système selon un point de vue
temporel pour accomplir une fonctionnalité attendue du
système (un cas d ’utilisation). C’est un ensemble de
messages échangés entre les acteurs et le système,
ordonnés chronologiquement. 13
Vocabulaire
UML Constituants

Constituants de base
Relations
Annotation Dépendances
note Associations
Généralisation
Diagrammes
Structure Groupement
Cas d ’utilisation Package D. Cas d ’utilisation
D. de classe
Classe Comportement. Modèle
Classe Active Sous-système D. d ’objet
Interface Interaction Framework D. de séquence
Composant Machine d ’état D. de collaboration
Collaboration D. d ’état/transition
Noeud D. d ’activité
D. de composant
D. de déploiement

14
Paquetage
 Définition
 Groupement d ’éléments de modélisation.

 Il correspond à un sous ensemble de modèle. Il

contient selon le modèle, des classes, des objets,
des composants
 Exemple
Client

Commandes
Client
passer

Ligne de Commande
commande Ligne de commande
Article
Commande Article

Commander

15
Dépendance entre paquetages
 Une association sémantique entre 2 (ou plus) éléments
de modèle (classes, paquetages, etc....)

 Cette dépendance indique une situation dans laquelle

un changement sur l’élément cible peut exiger un
changement sur l’élément source de la dépendance

Statistiques ventes Commandes

Catégorie article dépend de Client
Chiffre d’affaire Commande
etc... Ligne de commande
Article

16
Stéréotypes : Mécanismes d ’extension
 Le stéréotype permet d’étendre l’ensemble de base des éléments
de modélisation. Ceci facilite la documentation des particularités
spécifiques à un projet ou un processus.
 Plusieurs stéréotypes sont fournis par les AGL (Rational Rose par
exemple), néanmoins l’utilisateur a la possibilité d ’en ajouter
d ’autres spécifiques à ses besoins
 Exemple : 3 stéréotypes prédéfinis pour l’analyse: interface, entité,
contrôleur
<<entité>>
Commande

Commande
« interface »
Interface distributeur

Interface distributeur
<<entité>> >
Superviseur

Superviseur

17
Le processus : Principes
Processus : ensemble d’étapes, destinées à livrer et dans les délais (et le budget) une
application qui correspond aux besoins du client et des utilisateurs.

Cas
Architecture
d’utilisation

« piloté par » « centré sur»

Langage « basé sur » Processus Itératif et

UML configurable « se déroule » incrémental

UML est un langage de

modélisation (de notation)
indépendant des processus.

Processus A Processus B

18
Processus : rôle des cas d ’utilisation
Modèle
des cas
d’utilisation

spécialisé par
Modèle élaboré par
d’Analyse
Modèle de distribué par
Conception
réalisé par
Modèle de
Déploiement vérifié par
Modèle
d ’implantation
Modèle de
Test

19
Plan
• Présentation d’UML

• Modèle Fonctionnel

• Modèles Statiques

• Modèles Dynamiques

• UML et les méthodologies de développement logiciel

• Conception centrée sur l ’architecture

20
Modèle Fonctionnel

• Les cas d’utilisations

• Exemple d’Application

• Le virage vers l’objet

• En conclusion

21
Modèle Fonctionnel / Les cas d’utilisation

• Définitions

• Intérêt des cas d’utilisations

• Diagramme de cas d’utilisation

• Les acteurs

• Détermination des cas d’utilisations

• Relations entre cas d ’utilisations

22
Définitions
 Formalisés par Ivar Jacobson : Object-Oriented Software
Engineering (Addison-Wesley, 1992)
 Expression du comportement du système (actions et de réactions),
selon le point de vue de l’utilisateur
 Un cas d’utilisation est une manière spécifique d’utiliser un système.
 C’est l’image d’une fonctionnalité du système, déclenchée en
réponse à la stimulation d’un acteur externe

23
Intérêt des cas d’utilisation(1/2)

 Constituent un moyen pour déterminer les besoins

d’un système

 Utilisés par les utilisateurs finaux pour exprimer leur

attentes et leur besoins

 Permettent d’impliquer les utilisateurs dès les

premiers stades du développement

 Constituent une base pour les tests fonctionnels

24
Intérêt des cas d’utilisation (2/2)
Utilisateur C

Ensemble des besoins

Utilisateur A Utilisateur B

Les cas d’utilisation partitionnent Cahier des charges

l’ensemble des besoins d’un
système
25
 Diagramme de cas d’utilisation
• Un Diagramme de cas d ’utilisation représente les fonctions
du système de point de vue de l ’utilisateur.
Ceci est un cas
relation d’utilisation

Acteur Cas d ’utilisation

Ceci est Ceci est
un acteur une relation

Eléments du diagramme :
 acteur : un rôle joué par une personne, un service, etc.
qui interagit avec le système étudié
 cas d’utilisation : manière spécifique d ’utiliser un
système. Image d’une fonctionnalité attendue, déclenchée
en réponse à la stimulation d’un acteur
 relations entre cas d’utilisations et acteurs
26
 Les acteurs(1/3)
 Un acteur est une personne ou un système qui interagit
avec un système, en échangeant de l’information (en entrée
et en sortie)

 On trouve les acteurs en observant les utilisateurs directs du

système, ceux qui sont responsable pour sa maintenance,
ainsi que les autres systèmes qui interagissent avec le
système
Acteur humain : il s ’agit ici d ’un rôle et non d ’un acteur identifié.

Acteur non humain : exemple un logiciel de comptabilité

ou d’ERP avec lequel le système interagit

27
 Les acteurs(2/3)

 Un acteur Principal: celui pour qui le cas d’utilisation

produit un résultat observable.
 Un acteur Secondaire: celui qui peut juste consulter ou
informer le système lors de l’exécution du cas d’utilisation

28
Les acteurs(3/3)
Exemple
Conçoit les schémas
et nomenclatures Récupère les
schémas

Gestion des schémas Récupère les

Développeur contraintes

Définit les contraintes

mécaniques
Gestion des contraintes Responsable
CFAO

Responsable Gestion des jobs Gère la création et

BE les révisions d ’un job
<<dépend>>
Gère la création
et les révisions
des dossiers variantes
Gestion des dossiers

29
Détermination des cas d’utilisations
 Quelles sont les tâches de l’acteur ?

 Quelles informations l’acteur doit-il créer, sauvegarder,

modifier, détruire ou simplement lire ?

 L’acteur devra-t-il informer le système de changements

externes ?

 Le système devra-t-il informer l’acteur de conditions

internes au système ?

30
Les relations dans un diagramme cas
d’utilisation
 La relation de communication
 La relation de généralisation
 La relation d’inclusion
 La relation d’extension

<<include>>

Virement Identification
Client distant <<extend>>

montant > 500

Virement par Internet Vérification solde compte

31
[PAM-00 p156]
La relation d’inclusion
La relation d’inclusion a un caractère obligatoire, la
source spécifiant à quel endroit le cas d’utilisation cible doit
être inclus.
<<include>>

Virement Identification
Client distant <<extend>>

montant > 500

Virement par Internet Vérification solde compte

32
[PAM-00 p156]
La relation d’extension
Dans une relation d’extension entre cas d’utilisation, le
cas d’utilisation source ajoute son comportement au cas
d’utilisation destination (cible). L’extension peut être
soumise à une condition.
<<include>>

Virement Identification
Client distant <<extend>>

montant > 500

Virement par Internet Vérification solde compte

33
[PAM-00 p156]
Modèle Fonctionnel / Exemple d’Application

• Existant

• Définition du problème

• Phase d'Initialisation

• Diagramme des Cas d’Utilisation

34
Existant
• L ’exemple d ’application est intitulé « Cas
Scolarité »
• Les étudiants remplissent des imprimés et les
envoient au service d'inscription.
• Des employés saisissent les sélections des
étudiants dans une base de données, et fournissent
les emplois du temps pour les étudiants.
• L'université décide d'utiliser un système
d'inscription en temps réel.
• Ce système doit être utilisé par :
– Les professeurs pour leur indiquer les cours qu'ils
doivent assurer, par les étudiants pour choisir leurs
cours 35
Définition du problème (1/2)
• Au début de chaque semestre les étudiants doivent
obtenir un catalogue des cours proposés : contenu du
cours, professeur, département, et pré-requis.
• Le nouveau système doit permettre aux étudiants de
sélectionner leurs cours pour le semestre.
• En plus, chaque étudiant doit indiquer un choix
alternatif pour chaque cours choisi, au cas où ce
cours serait supprimé.
• Aucun cours ne doit avoir plus de vingt étudiants. Un
cours auquel moins de dix étudiants sont inscrit doit
être supprimé. 36
 Définition du problème (2/2)
• Une fois que le processus d'inscription par l'étudiant
est terminé, le système fournit les droits d'inscription
à percevoir pour le semestre.
• Les professeurs doivent pouvoir renseigner le
système sur les cours qu'ils assurent. Ils doivent aussi
savoir quels étudiants se sont enregistrés à leurs
cours.
• Lors de chaque début de semestre, il est défini une
période de temps où les étudiants peuvent modifier
leurs choix.
• Les étudiants doivent pouvoir accéder au système
pour modifier leurs choix. 37
 Phase d'Initialisation

• Définition des risques

– Le risque principal est constitué par l'interface IHM
(bonne acceptation par les étudiants et professeurs)

• Identifier les acteurs

– Étudiant
– Professeur
– Employé du service enregistrement
– Système de facturation des droits d'inscription (externe)

38
Diagramme des Cas d’Utilisation (1/2)

SYSTEME

Inscription
Système aux cours Interrogation étudiants
Facturation inscrits aux cours
Professeur

Préparation
Étudiant Sélection cours catalogue cours

Employé
Inscription

Màj des informations

professeurs Màj des informations
étudiants Màj des listes
de cours

39
Diagramme des Cas d’Utilisation (2/2)
Un cas d'utilisation peut c ontenir des diagrammes de cas d'utilisation, formant ainsi une arboresc ence.

En pratique, l'arborescence des cas d'utilisations correspondra à l'arborescenc e du menu de l'application.

Les fonc tionnalités élémentaires classiques (ajouter un item, modifier un item, supprimer un item) correspondront aux scénarii contenus dans un c as d'utilisation

40
Modèle Fonctionnel / Le virage vers l’objet

• Principe de la collaboration

• Du Cas d’utilisation à la décomposition structurée

• Du Cas d’utilisation à la décomposition Objet

• Cas d’utilisation et scénarios

• Description Textuelle d’un Use Case

41
 Principe de la collaboration
• Le passage à l’approche objet s’effectue en associant une ou
plusieurs collaboration à chaque cas d ’utilisation.
• Collaboration : description des objets d ’un domaine , les
connexions entre ces objets et les messages échangés par les objets.

42
Du Cas d’utilisation à la décomposition
structurée

C as 1
<<U tilise>> Une approche structurée réalise
un cas d ’utilisation au moyen
d’une décomposition
C as 2 Cas 3
fonctionnelle

43
Du Cas d’utilisation à la décomposition objet

C as 1
<<U tilise>>

Une approche objet réalise

C as 2 Cas 3 un cas d ’utilisation au
moyen d ’une collaboration
entre objets

44
Cas d’utilisation et scénarios
 Les cas d’utilisation doivent être vus comme une
machine de production de différents scénarios.
 Chaque fois qu’un acteur interagit avec le système, le
cas d’utilisation instantie un scénario.
 Un scénario correspond au flot de messages
échangés par les objets durant l’interaction
particulière qui correspond au scénario.

45
[PAM-00 p155]
Cas d’utilisation et2 scénarios
Scénario 1 Scénario Scénario 3

Cas
d’utilisation

Un cas d’utilisation décrit, de manière abstraite,

une famille de scénarios.

46
Description Textuelle d’un Use Case

1. Sommaire d’identification
 Titre
 Résumé
 Acteurs
 Date de création
 Version
 Responsables

1. Description des enchaînements

 Préconditions
 Scénario nominal
 Enchainements alternatifs
 Enchainements d’erreur
 Postconditions

47
Description Textuelle d’un Use
Case(Complément)

Exigences non fonctionnelles:

Contraintes Descriptif
Temps de réponse
Concurrence
Disponibilité
Sécurité/Intégrité
Confidentialité
Traçabilité

Besoins d’IHM
48
En conclusion

 Les cas d'utilisation recentrent l'expression des besoins sur les

utilisateurs
 Outil d ’aide à l ’identification et à la structuration des besoins.
On structure la démarche par rapport aux interactions d'une seule
catégorie d'utilisateurs à la fois.
 Outil d ’aide à l’analyse et à la conception objet. On s ’intéresse
à un ensemble de classes qui collaborent dans un certain contexte
(celui du cas d ’utilisation)
 Description de la structure de la collaboration
 Description du comportement de la collaboration
 Outil de communication

49
Plan
• Présentation d’UML

• Modèle Fonctionnel

• Modèles Statiques

• Modèles Dynamiques

• UML et les méthodologies de développement logiciel

• Conception centrée sur l ’architecture

50
Modèle Statique

• Diagramme d ’objets

• Diagramme de classes

• Diagramme des composants

• Diagramme de déploiement

• Exemple d’application

51
 Diagramme d’Objets

• Structure statique d’un système, en termes d’objets et de liens

entre ces objets.
• Ces objets et ces liens possèdent des attributs qui possèdent des
valeurs.
Nom de l’objet : Classe

Attributs = valeurs
Ahmed : personne Personne collaborateur
âge = 35 âge : entier *
patron
patron 1
collaborateur
emploie>
Ali : personne
âge = 25
Diagramme de classes
Diagramme d ’objets

Un objet est une instance de classe et un lien est une instance d’association.
52
Modèle Statique / Diagramme des Classes
• Définitions
• Relations entre classes
• Associations
• Nommage des associations
• Multiplicité des associations
• Arité des associations
• Placement des attributs et des associations
• Contraintes
• Agrégation
• Composition
• Cardinalité des compositions
• Exemple de diagramme de classes
• La hiérarchie des classes
• Paquetage de classe 53
 Définitions / Exemple
Structure statique d’un système, en termes de classes et de relations entre
ces classes.
Voiture
Couleur
Nom de classe
Cylindrée
Attributs exemple :
Vitesse max
Opérations ()
Démarrer ()
Accélérer ()

Syntaxe: Freiner ()

• nom_attribut : type_attribut = valeur initiale

• nom_opération (nom_argument : type_argument = valeur_par_défaut, …) : type_retourné

Visibilité : trois niveaux de visibilité pour les attributs et les opérations:

• public (+) : élément visible à tous les clients de la classe
• protégé ( #) : élément visible aux sous-classes de la classe
• privé (-) : élément visible à la classe seule
54
 Relations entre classes

A chaque famille de liens entre objets correspond une relation entre

les classes de ces mêmes objets.

1 1..* 1 1..*
classe 2 constructeur véhicule moteur

spécialisation
n

généralisation
i atio
oc
ass
classe 1

classe 3
voiture camion avion
agrégation

classe 4

Agrégation Association Généralisation

55
Association
• L’association exprime une connexion sémantique
bidirectionnelle entre classes.

• Une association est une abstraction des liens qui existent

entre les objets instances des classes associées.

• Les associations se représentent de la même manière que

les liens.

56
Association

Rôle
• Il est possible de préciser le rôle d’une classe au sein d’une
association: un nom de rôle peut être spécifié de part et d’autre
de l’association.

57
Nommage des associations

constructeur véhicule
Construire> produit
fabricant <construit par

passager <Transporte véhicule

personne véhicule
conducteur Conduit> véhicule

propriétaire Possède> véhicule

employé <Emploie employeur

personne entreprise
directeur Dirige> société

actionnaire Possède> société

58
Multiplicité des associations
• Les rôles portent également une information de multiplicité qui
précise le nombre d’instances qui participent à la relation

1 Un et un seul (obligatoire)
0 .. 1 Zéro ou un (optionnel)
m .. n De m à n (entiers)
* ou 0 .. * quelconque

1 .. * Au moins 1

Personne 0..* Employeur Société

Employé 1

59
Arité des associations

Association d’arité 3

Salle

lieu
Etudiant Cours Enseignant

Début
Fin

60
Placement des attributs et des associations

1 Etudiant Réalise > Travail

0..* 0..*

0..* 1
Diplôme Note
Mention

0..1
Chambre
Numéro

61
Contraintes
personne Est_titulaire> compte
0 .. *
1
{Ordonnée}

0 .. *
personne classe
Parent d ’élève
{Sous ensemble}
0 .. *
Délégués

0 .. *
personne université
Enseignants
{Ou-exclusif}
0 .. *
Etudiants

62
Exemple de diagramme de classes

• Un client peut exister sans avoir de lien avec une commande. Par contre,
une commande n’a pas de sens sans lien vers son « parent » le client.
→ Notion d’agrégat
• Une ligne de commande n’est en aucun cas partageable entre plusieurs
commandes; la suppression d’une commande implique nécessairement la
suppression de toutes ses lignes.
→ Notion de composition
63
 Agrégation (1/2)

• L’association représente un couplage faible, les classes associées

restent relativement indépendantes l’une de l’autre.
• L’agrégation est une forme particulière d’association qui exprime
un couplage plus fort entre classes.
• Une des classes joue un rôle plus important que l’autre dans la
relation.
• L’agrégation permet de représenter des relations de type maître et
esclaves, tout et parties ou composés et composants

64
 Agrégation (2/2)
Livre Chapitre
1 .. *

1
{Ordonnée}

{Ordonnée}
Agrégation 1 .. *

• transitive : si voiture est composée de moteur et si moteur est Paragraphe

composé de courroie alors voiture est composée de courroie
• non symétrique : si voiture est composée de moteur, moteur ne
peut pas être composé de voiture
• Éventuellement réflexive : une fonction peut être composée
d’autres fonctions

65
Composition (1/2)

Homme 1 1 Tête

Composition

La composition traduit une dépendance existentielle forte.

66
Composition (2/2)

• La composition est une forme d’agrégation avec un couplage

plus important.

• Ce couplage de composition indique que les composants ne

sont pas partageables et que la destruction de l’agrégat entraîne

la destruction des composants agrégés.

• La valeur maximale de multiplicité du côté du conteneur ne

doit pas excéder 1 puisque les objets, instances de la classe des

composants, doivent tous appartenir au même objet conteneur.

67
Cardinalité des compositions /Composants

• Une galerie peut exister sans être

0..1
installée sur une voiture: Agrégat

• Une galerie ne peut exister que comme 1

partie d’une voiture : Composition

• Physiquement impossible! Un composant

ne peut être partie de plus d’un
composite. 0..*
• Une galerie ne peut être installée,
simultanément, sur plus d’une voiture.

68
Cardinalité des compositions /
Composite

• Une voiture n’est pas

obligatoirement équipée d’une
0..1 galerie.
• La galerie peut être assimilée à
un attribut optionnel.
• Toute voiture est équipée d’une
1 galerie.
• La galerie peut être assimilée à
un attribut obligatoire.

0..* • Une voiture peut être équipée de

plusieurs galeries.

69
Les hiérarchies de classes
Les hiérarchies de classes ou classifications permettent de
gérer la complexité en ordonnant les objets au sein
d’arborescences de classes d’abstraction croissante.
La généralisation: il s’agit de prendre des classes existantes
(déjà mises en évidence) et de créer de nouvelles classes qui
regroupent leurs parties communes; il faut aller du plus
spécifique vers le plus général.
La spécialisation: il s’agit de sélectionner des classes
existantes (déjà identifiées) et d’en dériver de nouvelles classes
plus spécialisées, en spécifiant simplement les différences.
70
Les hiérarchies de classes / Généralisation

La généralisation consiste à factoriser les éléments communs

d’un ensemble de classes dans une classe plus générale
appelée super-classe.
Les classes sont ordonnées selon une hiérarchie; une super-
classe est une abstraction de ses sous-classes.
La généralisation est une démarche assez difficile car elle
demande une bonne capacité d’abstraction. La mise au point
d’une hiérarchie est délicate et itérative.
Les arbres de classes ne poussent pas à partir de leur racine.
Au contraire, ils se déterminent en partant des feuilles car les
feuilles appartiennent au monde réel alors que les niveaux
supérieurs sont des abstractions construites pour ordonner et
71
comprendre.
Les hiérarchies de classes / Généralisation

Abstractions
plus générales

 Il y a généralisation car on s’intéresse d’abord aux voitures, motos,

avions et hélicoptères et ensuite seulement on les classe en
véhicules.
 L’itération de la démarche se justifie pour opérer un classement
plus fin sous forme de véhicules terrestres et de véhicules aériens.
72
Les hiérarchies de classes /
Généralisation

Extension par spécialisation

 Il y a spécialisation car on a classé les transmissions par

technologies différentes et ensuite seulement on s’intéresse aux
réalisations techniques: variateur, dérailleur ou boîte de
vitesses.
73
Les hiérarchies de classes / Règles de
Généralisation
Généralisation

noit asil ai cé p S
 La généralisation ne porte aucun nom particulier; elle signifie toujours: est
un ou est une sorte de.
 La généralisation ne concerne que les classes, elle n’est pas instantiable en
liens et, de fait, ne porte aucune indication de multiplicité.

74
Les hiérarchies de classes /
L’héritage
 L’héritage est une technique offerte par les langages de
programmation pour construire une classe à partir d’une ou
de plusieurs autres classes, en partageant des attributs,
des opérations et parfois des contraintes au sein d’une
hiérarchie de classes.
 Les classes enfants héritent des caractéristiques de leurs
classes parents.
 Les attributs et les opérations déclarés dans la classe
parent, sont accessibles dans la classe enfant, comme s’ils
avaient été déclarés localement.

75
[PAM-00 p57]
Les hiérarchies de classes / Héritage
multiple (1)
 La généralisation - sous sa forme dite multiple – existe
également entre arbres de classes disjoints.

76
Les hiérarchies de classes / Héritage
multiple (2)
 Pour que l’héritage multiple puisse être mise en œuvre, il
faut qu’il puisse être supporté par les langages de
programmation « objets » .
 Dans l’exemple, comment le compilateur peut-il garantir, lors
de l’implémentation de la classe Z, qu’il n’y ait pas de conflit
entre les propriétés A héritée de la classe X et A héritée de
la classe Y?
 Par exemple, JAVA ne supporte pas l’héritage multiple.

77
Les hiérarchies de classes / Classe
abstraite (1)
 Une classe abstraite ne donne pas directement des objets.

 Elle sert en fait de spécification plus abstraite pour des objets

instances de ses sous-classes.

 Le principal intérêt de cette démarche est de réduire le niveau de

détails dans les descriptions des sous-classes.

 Le nom d’une classe abstraite est en italique dans les diagrammes

de classes.

78
Les hiérarchies de classes / Classe
abstraite (2) Exemple
Classes
abstraites

Classes
concrètes

les classes Transmission, Continue et Discrète ne servent qu’à classer les

objets réels que sont les variateurs, les dérailleurs et les boîtes de vitesses.
79
Les hiérarchies de classes / Le
polymorphisme (1)
 Le terme polymorphisme décrit la caractéristique d’un

élément qui peut prendre plusieurs formes, comme l’eau

qui se trouve à l’état solide, liquide ou gazeux.

 En informatique, le polymorphisme désigne un concept de

la théorie des types, selon lequel une méthode peut

s ’appliquer à des de classes différentes issues d’une

même arborescence.

80
Les hiérarchies de classes / Le
polymorphismeExemple
(2)

• La classe Animal est un exemple de classe abstraite

• L’opération dormir() de la classe Animal est abstraite; elle est polymorphe et réalisée
par chacune des sous-classes Lion, Tigre et Ours.
• la classe Animal comporte:
¬ Une propriété privée Nom
¬ Une opération protégée tonNom() qui permet à chacune des sous-classes de récupérer le nom
de l’animal. 81
Les hiérarchies de classes / Le
polymorphismeExemple
(3) (suite)

• Ce diagramme ne contient pas d’objets de la classe Animal.

• La classe Animal étant abstraite, la représentation des animaux ne peut se faire que
par les sous-classes, Lion, Trigre et Ours qui permettent l’instantiation d’objets.
82