Introduction à la programmation

Orienteé Object

Ecole Nationale Supérieure Polytechnique

Niveau -2
Année Académique : 2017/2018

Enseignant : Kaladzavi Guidedi, PhD

Email : kaladzavi@univ-maroua.cm

1
Plan

• Module 1: Modélisation Orientée Objet : langages et concepts

• Module 2: Introduction le language Java

2
Chapitre 1: Modélisation Orientée
Objet : langages et concepts

3
Lien Informatique et Information

L'informatique s'occupe
• du traitement (par machine),
• de l'enregistrement,
• de la transmission et
• de la représentation de l'information.

• elle vise la représentation schématique et formalisée de l'information.

4
Information et sa structuration

Plusieurs mots en traitement de l'information :

code, signe, signal, symbole,
donnée, information, savoir, connaissance etc…

In the beginning was the Word…

Gospel of John
Au commencement était le Verbe (la Parole)…
Evangile selon Jean

Au commencement était le Signe

Signe = code ! Symbole (sémantique)

Signe : son, geste, pictogramme, …

5
Information et sa structuration

Plusieurs mots en traitement de l'information :

Code, signe, signal, symbole,
donnée, information, savoir, connaissance etc…

Savoir, information et donnée vont ensemble

• Une information est un savoir sur des faits et processus qui ont une
signification dans un certain contexte.
• Les données sont des signes ou des fonctions continues qui représentent
l'information dans le but d'un traitement.
• Dans un autre contexte plus physique, les données constituent des
impulsions enregistrées (signaux)

6
Structures de Données

Savoir, information et donnée vont ensemble

● La donnée elle-même n'est pas de l'information.

● Les informations sont représentées dans l'ordinateur sous forme de données.

● Le gain d'information à partir des données s'appelle abstraction.

• Deux concepts :
– Représentation types de données
– Abstraction structures de données

7
Objectifs primordiaux

L'informatique couvre les questions

● d'analyse,
● de modélisation
• des données,
• des structures et
• des rapports entre différents éléments dans plusieurs domaines d'application.

8
Objectifs primordiaux

La tâche d'informaticien

■ l'élaboration des solutions à des problèmes relatifs au traitement de l'information

pour des automates
■ l'organisation et le fonctionnement des systèmes de calcul par une machine.

9
Modélisation

Définition : La modélisation est la représentation des faits exempts des

détails encombrants

La modélisation est nécessaire pour se soustraire à la complexité de la réalité.

Un modèle est une abstraction du monde réel

Problème

Modélisation

Solution informatique

10
 Modèle…pourquoi ?

Les principales motivations sont (Vernadat, 2000) :

• comprendre et analyser la structure et le fonctionnement de l’entreprise

;
• prévoir (de manière fiable) le comportement et les performances des
processus opérationnels avant leur implantation ;
• identifier les risques d'implantation à gérer ;
• justifier les choix d'implantation sur des critères liés aux ressources et
aux coûts (méthodes de comptabilité par activités, par exemple) ;
• bâtir une vision commune du fonctionnement de l’entreprise et la
communiquer facilement au plus grand ensemble possible du
personnel.

11
Modélisation et monde réel
Un bon modèle doit refléter les propriétés du monde réel qu'il représente.

Concept Réalité
Traduit dans la réalité
Fondement

Morceau
de la
Traduction de la réalité
réalité
Modèle

12
Modèle et Système

La réalité est constituée des choses, des personnes, des processus, des
relations entre ces choses (faits…).

Le modèle quant à lui est la notion de ces choses (réelles ou pensées), des
personnes, des relations entre ces personnes (faits logiquement possibles),
…

13
 Méthodologie…pourquoi ?

● Formalisation claire et complète du problème informationnel.

● Maîtrise de la résolution du problème par l’utilisation de critères objectifs pour
évaluer les solutions.
● Construction de SI pertinents, complets, cohérents, fiables flexibles et adaptatifs.
● Évaluation du SI à tout moment de son cycle de vie.
● Rigueur dans l’élaboration de la solution.
● Réduire les coûts et les délais.

14
 Cycle de vie du logiciel
Modèle en cascade pour le développement logiciel

Analyse

Conception

Implémentation

Test

Maintenance

4 / 40
 Cycle de vie du logiciel

Modèle en cascade pour le développement logiciel

Analyse

…, MERISE, OMT, UML, E/A, DFD…

Conception

Fortran, Cobol, C, SmallTalk,

Implémentation
Ada, C++, Java, …

Test

Maintenance

4 / 40
Modélisation et philosophie

Langages procéduraux et fonctionnels

Langages Orientés-Objet
 Modélisation et philosophie

Langages procéduraux et fonctionnels

▸ Un programme est composé de plusieurs

procédures (ou fonctions) : Données
▸ qui effectuent un traitement sur des
données (procédure)
qui retournent une valeur après leur
▸
invocation (fonction) Traitement 1

▸ Certains langages ne distinguent pas

procédures et fonctions. Traitement 2
Exemples de langages procéduraux ou
▸
fonctionnels : Fortran, Lisp, C, …
Traitement 3

18
 Modélisation et philosophie
Déroulement du cours Introduction Concepts Java Remarques

Langages Orientés-Objet

▸ Un programme est composé de plusieurs

objets qui contiennent
▸
des données ”internes”
▸ des traitements manipulant ces données
internes ou d’autres données

▸ Les données d’un objet sont appelés ses

attributs et ses traitements sont ses
méthodes (ou opérations).
Exemples de langages orientés-objet :
▸ Objective C, SmallTalk, C++, Python, Ruby,
Java, …

Langage et Concepts de Programmation Orientée-Objet 19

Exemples des modèles
Exemple 1: Modélisation d'une entreprise
 Exemple 1: Modélisation d'une entreprise
3 composantes : fournisseurs, entreprise, clients.

Client
Fournisseur Entreprise
Performance

XX
Input

Output
Achat Expédition

Production

Entrée Sortie
Traitement

ETS 22
 Exemple 1: Modélisation d'une entreprise

Client Article Fournisseur Magasin Tours Client Client

Commande Réception Commande expédition

Approvision Approvi
. Expédition
Client commande recue terminée
nement terminée

-approvision
-
Expédition nement Expédition

23
Exemple 1: Modélisation Approvisionnement
d'une entreprise
Fournisseur3270
Magasin L7

Lettre numérisée
Monsieur Y
Liste ToDo
1. Liefe -
Commandes ranten -
Client auswahl
2. Preisver -
handlung

Client 4711 Monsieur X Client 4711

ArticleXY Article XY Monsieur Z
Tour 25

Réception des commandes Expédition

24
Exemple 2: Modélisation des phénomènes
naturels

25
Exemple 2 : Modèle de croissance
• Une population est un groupe d'organismes qui vivent ensemble et se reproduisent.
• Quatre facteurs peuvent réguler la taille d'une population : naissances B, morts D,
Immigration I et Emigration E.
• Une population de taille N change donc selon la formule suivante
dN
----- = B – D + I - E
dt
Les modèles simples considèrent une population fermée, avec plus de ressources
accessibles à elle qu'elle ne peut utiliser

dN
----- = B - D = rbN – rdN = (rb-rd)N = sN

dt
st, N
avec comme solution N = N0e 0, population initiale

26
Langages procéduraux et fonctionnels

▸ Un programme est composé de plusieurs

procédures (ou fonctions) : Données
▸ qui effectuent un traitement sur des
données (procédure)
qui retournent une valeur après leur
▸
invocation (fonction) Traitement 1

▸ Certains langages ne distinguent pas

procédures et fonctions. Traitement 2
Exemples de langages procéduraux ou
▸
fonctionnels : Fortran, Lisp, C, …
Traitement 3

Langage et Concepts de Programmation Orientée-Objet 27

Exemple 1 : Réseau de Pétri
Un exemple de moyen de modélisation : Réseau de Petri

Carl Adam Petri

Mathématicien et informaticien allemand

12 juillet 1926 - 2 juillet 2010

29
Définition

Moyens graphiques pour

• modéliser,
• simuler et
• analyser les systèmes dynamiques et discrets à structure non
variables et pour en
• dériver le fonctionnement des processus

Objectif : Description du parallélisme et de la synchronisation des

processus qui fonctionnent d'une manière centrale ou alors sont
distribués.

30
 Réseau de Petri: Producteur-Consommateur
Un producteur met des biens dans le magasin et le consommateur les
prend de là.

producteur consommateur

inactif T3 inactif
T1 Marché

actif actif
T4
T2

31
Exemple 2 : Le diagramme de Flux de données

32
 Exemple2: Modélisation d'une entreprise
3 composantes : fournisseurs, entreprise, clients.

Client
Fournisseur Entreprise
Performance

XX
Input

Output
Achat Expédition

Production

Entrée Sortie
Traitement

ETS 33
 Exemple2: Modélisation d'une entreprise

Client Article Fournisseur Magasin Tours Client Client

Commande Réception Commande expédition

Approvision Approvi
. Expédition
Client commande recue terminée
nement terminée

-approvision
-
Expédition nement Expédition

34
Exemple2: Modélisation Approvisionnement
d'une entreprise
Fournisseur3270
Magasin L7

Lettre numérisée
Monsieur Y
Liste ToDo
1. Liefe -
Commandes ranten -
Client auswahl
2. Preisver -
handlung

Client 4711 Monsieur X Client 4711

ArticleXY Article XY Monsieur Z
Tour 25

Réception des commandes Expédition

35
Exemple3 : Modèle Entité -Association
Modèle E-A dans les bases de données

• Il existe plusieurs outils nécessaires à la modélisation. Le plus

utilisé est le modèle d’entité association.

• Le modèle méta très répandu du Extended Entity Relationship

Model (Chen 1976) sert à la modélisation des choses et de leurs
relations.
Bases de données

• Des entités
● Des associations

● Les attributs ont des noms uniques et qualifient les entités ou les associations

• Les valeurs des attributs sont atomiques

• proie a un nom (élan de derby), zone d’appartenance (savane), etc..
Modèle E-A dans les bases de données

• Entité : Objet réel ou imaginaire qui appartient à un type d’entité.

– Exemple : Monsieur X (entité) loue une voiture (entité).
Le symbole de représentation est un rectangle. La description se fait au
singulier.

• Association : Relation entre plusieurs entités

– Exemple : Monsieur X est chef (association)de monsieur Y.
– Pour la notation l’on utilise le singulier
– Le symbole de représentation est le losange.
 Modèle E-A dans les bases de données

• Complexité ou cardinalité d’une relation. Elle donne le rapport que les entités
entretiennent entre elles,
– soit unique (1 :1),
– un à plusieurs (1 :m) ou
– complexe (n :m).

– Elle donne combien d’entités A sont en relation avec une entité B.

– Elle est toujours collée à l’entité en question.
– La cardinalité doit reflèter les faits réels entre les entités.

– Par exemple, une voiture de location peut être louée par personne ou par un seul
client. Mais un client peut louer une ou plusieurs voitures.
 Bases de données

• Le fondement théorique du calcul relationnel est la logique des prédicats selon

Codd 1970.
• Les propriétés sont les suivantes :
• Les relations sont des tables bidimensionnelles (lignes et des colonnes)
• Les colonnes d’une table sont des attributs
• Les relations sont invariantes par rapport à l’échange des colonnes
• Les attributs ont des noms uniques
• Les valeurs des attributs sont atomiques
• Les lignes d’une table se nomment tuplets
• Les relations sont invariantes par rapport à l’échange des lignes.
 Bases de données

• Une agence de voyage installée dans les environs de Maroua loue des véhicules à des touristes
pour des randonnées sahéliennes. Les prix dépendent de la durée de la location et du type de
véhicule.

• L'on veut modéliser cette agence de location de véhicules.

• Les entités sont les clients et les voitures qui sont reliés par une association « louer ».
 Bases de données

Le fondement théorique du calcul relationnel est la logique des prédicats selon

Codd 1970. Les propriétés sont les suivantes :

• Les relations sont des tables bidimensionnelles

• Les colonnes d’une table sont des attributs
• Les relations sont invariantes par rapport à l’échange des colonnes
• Les attributs ont des noms uniques
• Les valeurs des attributs sont atomiques
• Les lignes d’une table se nomment tuplets
• Les relations sont invariantes par rapport à l’échange des lignes.
Bases de données
 Bases de données
Client NrClient Nom Lieu Téléphone

C001 Baba Tignère 22 25 21 31

C002 Fdam Dziguilao 22 29 29 99

C003 Bapetel Ngong 22 27 00 00

C004 Djao Loum 77 77 77 77

Voiture Immatriculation Marque Couleur

LT 1222 Q Opel Rouge

ES 1400 T Mercedes Rose

NO 2244 P Audi Blanche

AD 4444 T BMW Rouge

AD 4433 Q Mercedes Rouge

CE 3300 Z Toyota Verte

Bases de données
Client NrClient Nom Lieu Téléphone
C001 Baba Tignère 22 25 21 31

C002 Fdam Dziguilao 22 29 29 99

C003 Bapetel Ngong 22 27 00 00

Voiture Immatriculation
C004 Marque
Djao Couleur
Loum 77 77 77 77
LT 1222 Q Opel Rouge

ES 1400 T Mercedes Rose

NO 2244 P Audi Blanche

AD 4444 T BMW Rouge

Location NrClient NrImmatriculation Durée
AD 4433 Q Mercedes Rouge
C001 CE 3300 Z 20
CE 3300 Z Toyota Verte
C001 ES 1400 T 3

C003 NO 2244 T 1

C004 AD 4433 Q 4

C004 AD 4444 T 12

C003 CE 3300 Z 5
Bases de données
Client NrClient Nom Lieu Téléphone
C001 Baba Tignère 22 25 21 31
C002 Fdam Dziguilao 22 29 29 99
C003 Bapetel Ngong 22 27 00 00
C004 Djao Loum 77 77 77 77
Voiture Immatriculation Marque Couleur

LT 1222 Q Opel Rouge

ES 1400 T Mercedes Rose
NO 2244 P Audi Blanche
AD 4444 T BMW Rouge
AD 4433Location
Q NrClient
Mercedes NrImmatriculatio
Rouge Durée
n
CE 3300 Z Toyota
C001 CEVerte
3300 Z 20
C001 ES 1400 T 3
C003 NO 2244 T 1
 Bases de données : Requêtes

• R1 : Donner le parc des véhicules en location (nombre total).

• R2 : Donner le nombre total de clients
• R3 : Donner les couleurs des véhicules en location
• R4 : Donner les noms des meilleurs clients (location de durée
supérieure ou égale à 10 jours)
• R5 : Quelle est la couleur du véhicule loué par Djao ?
• R6 : Donner la marque du véhicule loué pendant 20 jours.
• R7. Donner le nom et le numéro de téléphone du client qui a loué la
voiture immatriculée à l'Est.
• R9. Donner le nom du locataire et la durée de location de la BMW.
Langages Orientés-Objet
Langages Orientés-Objet

▸ Un programme est composé de plusieurs

objets qui contiennent
▸
des données ”internes”
▸ des traitements manipulant ces données
internes ou d’autres données

▸ Les données d’un objet sont appelés ses

attributs et ses traitements sont ses
méthodes (ou opérations).
Exemples de langages orientés-objet :
▸ Objective C, SmallTalk, C++, Python, Ruby,
Java, …
Modélisation Orientée Objet UML
• Diagramme de cas d’utilisation
• Diagramme de classes
Les concepts de l’OO
La modélisation devient la référence
• Pourquoi la modélisation?
• La conception OO est entièrement bâtie sur une modélisation des objets intervenant dans
le problème
• Avant de programmer quoi que ce soit, il faut donc modéliser les classes et leurs relations
au minimum
• Comment?
• Sur base d’UML (Unified Modeling Language)
1. Notation standardisée pour toute le développement OO de la conception au déploiement
• Définition de 9 diagrammes
1. Identifier les classes
➔ Attributs, comportements, polymorphisme
2. Déterminer les relations entre les classes
Associations / Dépendance / Hériage
Construire les modèles
 Introduction

Système réel

Analyse
Modèle Conception
Modèle de Réalisation
Modèle de Déploiement
Modèle de
d’Analyse Conception Réalisation Déploiement

BOOCH, OMT, OOSE,…

UML (Unified Modeling Language)

 Introduction

Juin 1999 UML 1.3

Janvier 1997 UML 1.0

UML 0.9

Octobre 1995 Méthode unifiée 0.8

Booch’93 OMT-2

Autres méthodes Booch’91 OMT-1

OOSE Partenaires
 Introduction

Résumé
• UML est une notation, pas une méthode
• UML est un langage de modélisation objet
• UML convient pour toutes les méthodes objet
• UML est dans le domaine public

Programmation Orientée Objet

modéliser informatiquement des éléments d'une partie du monde réel en un ensemble
d'entités informatiques (objets)

Intérêt d'une méthode objet

• définir le problème à haut niveau sans rentrer dans les spécificités du
langage
• définir un problème de façon graphique
• utiliser les services offertes par l’objet sans rentrer dans le détail de
programmation (Encapsulation)
• Réutilisation du code
 Modélisation objet

Notion de Classe
• Structure d'un objet, c.-à-d. une déclaration de l'ensemble des entités qui
composeront l’objet
• Un objet est donc "issu" d'une classe, c'est le produit qui sort d'un moule

Notation
un objet est une instanciation (occurrence) d'une classe

Une classe est composée: Nom_de_la_classe

➢ attributs attribut1 : Type
données dont les valeurs représentent attribut2 : Type
l'état de l'objet …
➢ méthodes méthode1 ()
opérations applicables aux objets méthode2 ()
…
 Modélisation objet

Visibilité des attributs

définissent les droits d'accès aux données (pour la classe elle-même,
d'une classe héritière, ou bien d'une classe quelconque)

➢Publique (+)
les classes peuvent accéder aux données et
Nom_de_la_classe
méthodes d'une classe définie avec le niveau
de visibilité public # Attribut1 : Type
- Attribut2 : Type
…
➢Protégée (#): l'accès aux données est + méthode1 ()
réservé aux fonctions des classes héritières Méthode2 ()
…

➢Privée (-): l'accès aux données est limité

aux méthodes de la classe elle-même
Diagramme des cas d’utilisation
UML : DIAGRAMME DE CAS D’UTILISATION
UML : DIAGRAMME DE CAS D’UTILISATION

GENERALITES :

• Le système existe pour servir ses utilisateurs

• Cas d’utilisation = Use cases
• Idée : description du comportement du système du point de vue de
son utilisateur (facilite l’expression des besoins)

• Comportement = {Actions} + {Réactions}

UML : DIAGRAMME DE CAS D’UTILISATION

DEFINITION :

• Le système existe pour servir ses utilisateurs

• Cas d’utilisation = Use cases
• Idée : description du comportement du système du point de vue de
son utilisateur (facilite l’expression des besoins)

• Comportement = {Actions} + {Réactions}

• Attention : diagramme qui manque de specif

UML : DIAGRAMME DE CAS D’UTILISATION

GENERALITES :
• On part d’un scénario (ex : un client achète un objet et paie sur internet)
• Mais il peut y avoir des scénarios liés ex
• échec lors du paiement
• Il s’agit d’un client régulier
• Mais ces scénarios ont le même but : acheter un objet

Un cas d’utilisation est un ensemble de scénarios liés ensemble par un but

commun d’un utilisateur.

• Acteur = entité externe qui agit sur le système

UML : DIAGRAMME DE CAS D’UTILISATION

REPRESENTATION :

Cas d’utilisation

Acteur
UML : DIAGRAMME DE CAS D’UTILISATION

ACTEURS vs UTILISATEURS :

Ne pas confondre acteur et personne utilisant le système :

• Une même personne peut jouer plusieurs rôles
• Plusieurs personne peuvent jouer un même rôle
• Un acteur n’est pas forcément une personne physique.

Types d’acteurs :
• Utilisateurs principaux
• Utilisateurs secondaires
• Périphériques externes
• Systèmes externes
UML : DIAGRAMME DE CAS D’UTILISATION

DEFINITION DES ACTEURS :

Pour chaque acteur :

Un guichetier est • choix d’un identificateur
un employé de la • brêve description (facultatif)
banque jouant un
rôle d’interface • Acteur principaux : utilisent le système
entre le système • Acteur secondaires : administrent le système
informatique et les
clients qu’il reçoit
au comptoir.
Guichetier
UML : DIAGRAMME DE CAS D’UTILISATION

CAS D’UTILISATION : DEFINITIONS

Ensemble des actions réalisées par le système en réponse à une action d’un
acteur

Les cas d’utilisation ne doivent pas se chevaucher

CU1

CUn

CU2
Acteur
UML : DIAGRAMME DE CAS D’UTILISATION

CAS D’UTILISATION
Système Cas d’utilisation

Acteur Principal

Association

CU1

CUn

CU2
Acteur
UML : DIAGRAMME DE CAS D’UTILISATION

EXEMPLE

Créer un
compte
Consulter
un compte

Client
Déposer Retirer de
de l’argent au
l’argent distributeur

Guichetier
Retirer Gérer les
de prêts
l’argent

Directeur
UML : DIAGRAMME DE CAS D’UTILISATION

RELATIONS ENTRE CAS D’UTILISATIONS :

• Généralisation (generalize)

• Inclusion (include)

• Extension (extend)
UML : DIAGRAMME DE CAS D’UTILISATION

RELATION GENERALIZE

<< generalize >>

Virement par
minitel Virement
UML : DIAGRAMME DE CAS D’UTILISATION

RELATION INCLUDE :

<<include>> Consulter un
compte

Imprimer Solde
Compte

<<include>> Imprimer un
Ticket
UML : DIAGRAMME DE CAS D’UTILISATION

RELATION EXTEND :
<<extend>>

Commander
Commander du vin
Nourriture

Client
<<extend>>
Manger
Nourriture
Boire du vin
UML : DIAGRAMME DE CAS D’UTILISATION

EN RESUME :
• Système = ensemble de cas d’utilisation
• Le système possède les cas d’utilisation mais pas les acteurs

• Un cas d’utilisation = ensemble de « chemins d’exécution » possibles

• Un scénario = un chemin particulier d’exécution

• Un scénario = Instance de cas d’utilisation

• Une instance d’acteur crée un scénario

UML : DIAGRAMME DE CAS D’UTILISATION

QUAND L’UTILISER ?
• Outil appréciable pour aider à comprendre les requis fonctionnels d’un
système.
• Utile dans les premières phases d’un projet
• Précède les spécifications détaillées

ASTUCES :
• S’aider des flux & des acteurs identifiés dans le diagramme de
communication
• Regrouper ces flux identifiés
• Ne pas descendre trop bas dans la description
UML : DIAGRAMME DE CAS D’UTILISATION

ASTUCES :
• Impossible de décrire tous les scénarios
• Sélection des scénarios optimaux : interaction la plus fréquente
• Sélection des scénarios dérivés : certaines alternatives intéressantes

• Commencer par les diagrammes CU qui présentent :

• Le plus d’enjeux / risque
• Les plus importants
UML : DIAGRAMME DE CAS D’UTILISATION

EXERCICES
Diagrammes de Classes e
d’objets
 Introduction
• La construction du diagramme de classes constitue l’objectif de toute démarche de
modélisation « objet »

• Le diagramme de cas d’utilisation montre un système du point de vue des acteurs,

•Le diagramme de classes en montre la structure interne du système.

•Il fournit une représentation abstraite des objets du système qui vont interagir pour
réaliser les cas d’utilisation.

• Le diagramme de classes modélise les concepts du domaine d’application ainsi que les
concepts internes créés dans le cadre de l’implémentation d’une application.
 Classe et instance de classe
● Une instance est une réalisation concrète d’un concept abstrait.
Par exemple :
- le téléphone de Jules est une instance du concept abstrait Téléphone
- l’amitié qui lie Jean et Marie est une instance du concept abstrait Amitié
-
● Une classe est un concept abstrait représentant des éléments variés comme :

- des éléments concrets (ex : des avions),

- des éléments abstraits ( ex : des commandes de marchandises ou services),
- des composants d’une application (ex : les boutons des boîtes de dialogue),
- des structures informatiques (ex : des tables de hachage),
-
•Tout système orienté objet est organisé autour des classes.
Une classe est la description formelle d’un ensemble d’objets ayant en commun:
- une sémantique (sens)
- des caractéristiques (propriétés et comportements).
 Objet: instance de classe
-
-
▪ Un objet est une instance d’une classe. C’est une entité discrète dotée :
● d’une identité

● d’un état

● d’un comportement

Les objets sont des éléments individuels d’un système en cours d’exécution.
Caractéristiques d’une classe
● État d’un objet
● Comportement d’un objet
 État d’un objet

• Attributs et Terminaisons d’associations décrivent l’état d’un objet.

• Les attributs reçoivent des données dépourvues de sémantique
• Les associations sont utilisées pour connecter les classes
• La terminaison de l’association (du côté de la classe cible) est
une propriété de la classe
• Les attributs prennent des valeurs lorsque la classe est instanciée.
• L’instance d’une association est appelée un lien.
Caractéristiques d’une classe
● État d’un objet
• Comportement d’un objet
 Comportement d’un objet

• Les opérations décrivent les éléments individuels d’un comportement que l’on
peut invoquer. Ce sont des fonctions qui peuvent:
• prendre des valeurs en entrée
• modifier les attributs
● produire des résultats
• Une opération est la spécification (i.e. déclaration) d’une méthode. Par abus
de langage (impérialisme Java!) les opérations sont parfois appelées méthodes.
Il y a donc une ambiguïté sur le terme méthode.

• Les attributs, les terminaisons d’associations et les opérations constituent donc les
caractéristiques d’une classe (et de ses instances).
 Représentation graphique
Une classe est un « classificateur ». Elle est représentée par un rectangle divisé
en trois à cinq compartiments:

• Le premier indique le nom de la classe

• Le deuxième ses attributs
• Le troisième ses opérations
•
Avec éventuellement:
• Un compartiment des responsabilités pour énumérer l’ensemble de tâches devant
être assurées par la classe mais pour lesquelles on ne dispose pas encore assez
d’informations.
• Un compartiment des exceptions pour énumérer les situations exceptionnelles
devant être gérées par la classe.
Représentation graphique

Représentation UML d’une classe

 Encapsulation visibilité interface
L’encapsulation: mécanisme consistant à rassembler les données et les
opérations au sein d’une structure en cachant l’implémentation de l’objet,

Interdit l’accès aux données par un autre moyen que les services proposés.
Les services accessibles (offerts) aux utilisateurs de l’objet définissent l’interface
de l’objet (sa vue externe).

• permet donc de garantir l’intégrité des données contenues dans l’objet.

• permet de définir des niveaux de visibilité des éléments d’un conteneur.

La visibilité déclare la possibilité pour un élément de modélisation de

référencer un élément qui se trouve dans un espace de noms différents de celui
de l’élément qui établit la référence.
Elle fait partie de la relation entre un élément et le conteneur qui l’héberge,
ce dernier pouvant être un paquetage, une classe ou un autre espace de noms.
Il existe quatre visibilités prédéfinies.
 Visibilité
● Public ou + :
tout élément qui peut voir le conteneur peut également voir l’élément indiqué.
● Protected ou # :
seul un élément situé dans le conteneur ou un de ses descendants peut voir
l’élément indiqué.
● Private ou - :
seul un élément situé dans le conteneur peut voir l’élément.
● Package ou ∼ ou rien :
seul un élément déclaré dans le même paquetage peut voir l’élément.
Visibilité
Relations de visibilité
 Nom d’une classe
• Le nom de la classe doit évoquer le concept décrit par la classe.
• Il commence par une majuscule.
● On peut ajouter des informations comme:
• le nom de l’auteur de la modélisation,
• la date,
● etc.
Pour indiquer qu’une classe est abstraite, il faut ajouter le stéréotype
<<abstract>>.

La syntaxe de base de la déclaration d’un nom d’une classe est la suivante :

[ <Nom_du_paquetage_1>:: ... ::<Nom_du_paquetage_N> ]

<Nom_de_la_classe>
[ { [abstract], [<auteur>], [<date>], ... } ]
 Les attributs
• Chaque instance d’une classe possède sa propre copie des attributs de la classe.
Les valeurs des attributs peuvent donc différer d’un objet à un autre.
• Il est parfois nécessaire de définir un attribut de classe (static en
Java ou en C++) qui garde une valeur unique et partagée par toutes les
instances de la classe.
• Les instances ont accès à cet attribut mais n’en possèdent pas une copie.
• Un attribut de classe n’est donc pas une propriété d’une instance mais une propriété
de la classe
• Graphiquement, un attribut de classe est souligné.
Les attributs
 Attributs dérivés
• Les attributs dérivés peuvent être calculés à partir d’autres attributs et de formules
de calcul.
• Lors de la conception, un attribut dérivé peut être utilisé comme marqueur pour
déterminer les règles à lui appliquer.
• Les attributs dérivés sont symbolisés par l’ajout d’un « / » devant leur nom.
 Les opérations
• Dans une classe, une opération (même nom et même types de paramètres)
doit être unique.
• Quand le nom d’une opération apparaît plusieurs fois avec des paramètres
différents, on dit que l’opération est surchargée.
• La déclaration d’une opération contient les types des paramètres et le type
de la valeur de retour, sa syntaxe est la suivante :

<visibilité> <nom_opération> ([<paramètre_1>, ... , <paramètre_N>]) :

[<type_renvoyé>] [{<propriétés>}]
 Paramètre d’opération
La syntaxe de définition d’un paramètre (<paramètre>) est la suivante :

[<direction>] <nom_paramètre>:<type> ['['<multiplicité>']'] [=<valeur_par_défaut>]

La direction peut prendre l’une des valeurs suivante :

in
: Paramètre d’entrée passé par valeur. Les modifications du paramètre ne sont
pas disponibles pour l’appelant. C’est le comportement par défaut.
out
: Paramètre de sortie uniquement. Il n’y a pas de valeur d’entrée et la valeur
finale est disponible pour l’appelant.
inout
: Paramètre d’entrée/sortie. La valeur finale est disponible pour l’appelant.

Le type du paramètre (<type>) peut être

• un nom de classe,
• un nom d’interface,
• un type de donné prédéfini.
 Opération de classe

• Comme pour les attributs de classe, il est possible de déclarer des opérations
de classe.
• Une opération de classe ne peut manipuler que des attributs de classe et
ses propres paramètres.
• Cette méthode n’a pas accès aux autres attributs
• Graphiquement, une opération de classe est soulignée.
 Classe active
• Une classe est passive par défaut, elle sauvegarde les données et offre
des services aux autres.

• Une classe active initie et contrôle le flux d’activités.

• Graphiquement, une classe active est représentée comme une classe standard
dont les lignes verticales du cadre, sur les côtés droit et gauche, sont doublées.
 Notion d’association
• Une association est une relation entre deux classes (association binaire) ou plus
(association n-aire), qui décrit les connexions structurelles entre leurs instances.
• Une association indique donc qu’il peut y avoir des liens entre des instances des
classes associées.
 Notion d’association
(remarque)

Deux modélisations de la notion d’association

La question de savoir s’il faut modéliser les associations en tant que tel a longtemps
fait débat. UML a tranché pour la première version car elle se situe plus à un niveau
conceptuel (par opposition au niveau d’implémentation)
 Terminaison d’association
Propriétaire d’une terminaison d’association

La possession d’une terminaison d’association par le classeur situé à l’autre

extrémité de l’association peut être spécifié graphiquement par l’adjonction
d’un petit cercle plein (point) entre la terminaison d’association et la classe
Il n’est pas indispensable de préciser la possession des terminaisons
d’associations.
 Terminaison d’association = propriété
Dans le cas d’une classe, les propriétés sont constituées par les attributs et les
éventuelles terminaisons d’association que possède la classe.
Dans le cas d’une association, les propriétés sont constituées par les terminaisons
d’association que possède l’association.
Une propriété peut être paramétrée par les éléments suivant :
nom :
Comme un attribut, une terminaison d’association peut être nommée. Le nom est
situé à proximité de la terminaison.
Le nom d’une terminaison d’association est appelée nom du rôle.
visibilité :
Comme un attribut, une terminaison d’association possède une visibilité.
multiplicité :
Comme un attribut, une terminaison d’association peut posséder une multiplicité.
Elle est mentionnée à proximité de la terminaison.
navigabilité :
Pour un attribut, la navigabilité est implicite, navigable, et toujours depuis la
classe vers l’attribut.
Pour une terminaison d’association, la navigabilité peut être précisée
 Association binaire et n-aire
• Une association binaire est matérialisée par un trait plein entre les classes
● Associées.
• Elle peut être ornée d’un nom, avec éventuellement un sens de lecture (▸ ou ◂).
• Quand les deux extrémités de l’association pointent vers la même classe,
● l’association est dite réflexive.
 Association binaire et n-aire
• Une association n-aire lie plus de deux classes.
• La ligne pointillé d’une classe-association peut être reliée au losange par une
● ligne discontinue pour représenter une association n-aire dotée d’attributs,
● d’opérations ou d’associations.
• On représente une association n-aire par un grand losange avec un chemin
● partant vers chaque classe participante

• Le nom de l’association, le cas échéant, apparaît à proximité du losange.

 Multiplicité ou cardinalité
• La multiplicité associée à une terminaison d’association déclare le nombre d’objets
● susceptibles d’occuper la position définie par la terminaison d’association.
• Dans une association binaire la multiplicité sur la terminaison cible contraint
● le nombre d’objets de la classe cible pouvant être associés à un seul objet donné
● de la classe source (la classe de l’autre terminaison de l’association).
• Dans une association n-aire, la multiplicité apparaissant sur le lien de chaque
● classe s’applique sur une instance de chacune des classes.
● (ambiguité des associations ternaires!)
● Quelques exemples de multiplicités:
 Navigabilité
• La navigabilité indique s’il est possible de traverser une association.
• On représente graphiquement la navigabilité par une flèche du côté de la
● terminaison navigable et on empêche la navigabilité par une croix du côté de
● la terminaison non navigable.
• Par défaut, une association est navigable dans les deux sens.
 Navigabilité
● Deux modélisations équivalentes.

● Une classe UML est-elle toujours en Première Forme Normale?

 Qualification
• Quand une classe est liée à une autre classe par une association, on peut
restreindre la portée de l’association à quelques éléments ciblés de la classe.
• Ces éléments ciblés (un ou plusieurs attributs) sont appelés un qualificatif.
• Un qualificatif permet donc de sélectionner un spécifique dans l’ensemble des
objets candidats e l’association.
• L’objet sélectionné par la valeur du qualificatif est appelé objet cible.
• L’association est appelée association qualifiée.
• Un qualificatif agit toujours sur une association dont la multiplicité est plusieurs
du côté cible.
 Classe-association
• Parfois, une association doit posséder des propriétés.
• Les associations ne pouvant posséder de propriété, il faut introduire un nouveau
● concept pour modéliser cette situation : la classe-association.
• Une classe-association possède les caractéristiques des associations et
● des classes.
• Elle se connecte à deux ou plusieurs classes et possède également des attributs
● et des opérations.
• Une classe-association est caractérisée par un trait discontinu entre la classe
● et l’association qu’elle représente
Classe-association
● Exemple d’auto-association sur classe-association.
 Agrégation et composition
● Une association simple entre deux classes représente une relation structurelle
● entre deux classes de même niveau conceptuel : aucune des deux n’est plus
● importante que l’autre.
●

● Agrégation
● Une agrégation est une association qui représente une relation d’inclusion

● structurelle ou comportementale d’un élément dans un ensemble.

● Lorsque l’on souhaite modéliser une relation tout/partie où une classe constitue

● un élément plus grand (tout) composé d’éléments plus petit (partie), il faut utiliser

● une agrégation.
● Graphiquement, on ajoute un losange vide (♦) du côté de l’agrégat. Contrairement

● à une association simple, l’agrégation est transitive.

 Agrégation
● Objet, Fichier, Texte sont agrégés à la classe Email
 Composition
● Composition
● La composition, également appelée agrégation composite, décrit une contenance

● structurelle entre instances.

● La destruction de l’objet composite implique la destruction de ses composants.

● Une instance de la partie appartient toujours à au plus une instance de l’élément

● Composite.

● La multiplicité du côté composite ne doit pas être supérieure à 1 (i.e. 1 ou 0..1).

● Graphiquement, on ajoute un losange plein du côté de l’agrégat.

 Composition
● Un Email est (obligatoirement) composé de Destinataires
 Généralisation et Héritage
● La généralisation décrit une relation entre :
• une classe générale (classe de base ou classe parent)
• une (ou des) classe spécialisée (sous-classe).

La classe spécialisée est intégralement cohérente avec la classe de base,

mais comporte des informations supplémentaires (attributs, opérations, associations).

● Dans le langage UML, cette relation de généralisation se traduit par le concept

● d’héritage. On parle également de relation d’héritage.
●

● L’héritage permet la classification des objets (taxinomie).

● Le symbole utilisé pour la relation d’héritage ou de généralisation est une flèche
● avec un trait plein dont la pointe est un triangle fermé désignant le cas le plus
● général
Généralisation et Héritage
 Généralisation / Spécialisation

Spécialisation
Démarche descendante, qui consiste à capturer les particularités
d'un ensemble d'objets, non discriminés par les classes déjà identifiées.
La Spécialisation consiste à étendre les propriétés d'une classe,
sous forme de sous-classes, plus spécifiques.

Généralisation
Démarche ascendante, qui consiste à capturer les particularités
communes d'un ensemble d'objets, issus de classes différentes.
La Généralisation consiste à factoriser les propriétés d'un ensemble
de classes, sous forme d'une super-classe, plus abstraite.
 Principe de substitution de Liksow
• L'héritage permet la classification des objets.
• Une bonne classification est stable dans le temps et extensible
• Parfois, les critères de classification sont subjectifs.
• Le principe de substitution de Liksow, (1987) permet de déterminer
si une relation d'héritage est bien employée pour la classification :

Si Y hérite de X, cela signifie que "Y est une sorte de X "

 Propriétés principales de
l’héritage
• La classe enfant possède toutes les caractéristiques des ses classes parents,
● mais elle ne peut accéder aux caractéristiques privées de cette dernière.

• Une classe enfant peut redéfinir (même signature) une ou plusieurs opérations
● de la classe parent.

• Sauf indication contraire, un objet utilise les opérations les plus spécialisées
● dans la hiérarchie des classes.

• Toutes les associations de la classe parent s’appliquent aux classes dérivées.

● Une instance d’une classe peut être utilisée partout où une instance de sa classe
● parent est attendue.
●

• Une classe peut avoir plusieurs parents, on parle alors d’héritage multiple
• Le langage C++ est un des langages objet permettant son implémentation
● effective, le langage Java ne le permet pas.
 Héritage multiple
● Une classe peut avoir plusieurs parents, on parle alors d’héritage multiple
●

● (Le langage C++ est un des langages objet permettant son implémentation effective, le langage Java
● ne le permet pas.)
●

● En UML, la relation d’héritage n’est pas propre aux classes. Elle s’applique à d’autre éléments du langage
● comme les paquetages, les acteurs ou les cas d’utilisation.
 Dépendance
• C’est une relation unidirectionnelle exprimant une dépendance sémantique entre
● des éléments du modèle.

• Elle est représentée par un trait discontinu orienté.

• Elle indique que la modification de la cible peut impliquer une modification
● de la source.
● La dépendance est souvent stéréotypée pour mieux expliciter le lien sémantique
● entre les éléments du modèle
• On utilise souvent une dépendance quand une classe en utilise une autre comme
● argument dans la signature d’une opération.
 Interfaces
● Une interface est représentée comme une classe excepté l’absence du mot-clef
● abstract et l’ajout du stéréotype << interface >>
● Elle est réalisée par au moins une classe (peut l’être par plusieurs).
● Graphiquement, elle est représentée par un trait discontinu terminé par une
flèche
● triangulaire et le stéréotype « realize » ou le stéréotype <<use>>.
 Présentation
• Un diagramme d’objets représente des objets (i.e. instances de classes) et leurs
liens (i.e. instances de relations) pour donner une vue de l’état d’un système à un
instant donné.

● Un diagramme d’objets peut être utilisé pour :

● illustrer le modèle de classes par un exemple qui explique le modèle ;
● préciser certains aspects du système en mettant en évidence des détails
imperceptibles dans le diagramme de classes ;
● exprimer une exception en modélisant des cas particuliers ou des
connaissances non modélisables dans un diagramme de classe (OCL);
● prendre une image d’un système à un moment donné.

● Le diagramme de classes modélise les règles et le diagramme d’objets modélise des faits.
 Représentation
• Graphiquement, un objet se représente comme une classe.
• Le compartiment des opérations n’est pas utile.
• Le nom de la classe dont l’objet est une instance est précédé d’un << : >>
● et est souligné.
• Pour différencier les objets d’une même classe, leur nom peut être ajouté
devant le nom de la classe.
• Les attributs reçoivent des valeurs.
 Représentation
● Dans un diagrammes d’objets, les relations du diagramme de classes deviennent des liens.
• La relation de généralisation ne possède pas d’instance, elle n’est donc jamais
● représentée dans un diagramme d’objets.
● Graphiquement, un lien se représente comme une relation, mais, s’il y a un nom, il est souligné.
• On ne représente pas les multiplicités.
Dépendance d’instanciation

● Extrait du Méta Modèle UML

 Dépendance d’instanciation
● La relation de dépendance d’instanciation (stéréotypée << instanceof >>) décrit
● la relation entre un classeur et ses instances. Elle relie, en particulier, les liens
● aux associations et les objets aux classes.
 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...).
Solution