Vous êtes sur la page 1sur 101

TECHNIQUES DE CONCEPTION ET DE PROGRAMMATION ORIENTEE OBJET ...........................................................

5
INTRODUCTION......................................................................................................................................................................................... 5
PARTIE 1 : GENIE LOGICIEL.................................................................................................................................................................6
CHAPITRE 1 : GENIE LOGICIEL .......................................................................................................................................................... 6
I. Définition ..........................................................................................................................................................................................6
II. Objectifs ............................................................................................................................................................................................. 6
III. Caractéristiques ........................................................................................................................................................................7
IV. Principes fondamentaux ........................................................................................................................................................ 8
V. Les design Patterns (Patron de conception) ..................................................................................................................... 9
1) Description ............................................................................................................................................................................. 9
2) Le Modèle Vue Controleur ............................................................................................................................................ 10
PARTIE 2 : LES CONCEPTS OBJET .................................................................................................................................................. 12
Chapitre 2 : PRESENTATION DE LA NOTION OBJET ............................................................................................................. 12
I. Définitions d’un objet........................................................................................................................................................... 12
II. LES OBJETS, ATTRIBUTS ET METHODES .............................................................................................................. 13
a) La notion d’objet.......................................................................................................................................................... 13
b) La notion de classe ..................................................................................................................................................... 13
c) Attributs .......................................................................................................................................................................... 13
d) Méthodes ........................................................................................................................................................................ 14
e) Message ........................................................................................................................................................................... 14
III. Création d’un objet .......................................................................................................................................................... 14
IV. Le principe d’encapsulation ........................................................................................................................................ 14
V. Attribut d’instance, attribut de classe, méthode d’instance, méthode de classe.................................. 15
Remarque ............................................................................................................................................................................................ 16
VI. La création d’une classe................................................................................................................................................. 16
a) La déclaration d’une classe ............................................................................................................................................... 16
Remarque : .......................................................................................................................................................................................... 17
VII. Déclaration et création d’une instance d’une classe ......................................................................................... 17
a) La déclaration de l’instance .................................................................................................................................... 17
b) La création effective de l’instance ....................................................................................................................... 18
VIII. Accès aux éléments de la classe ............................................................................................................................ 18
IX. Représentation algorithmique de la classe compte .......................................................................................... 18
X. Constructeur et destructeur ........................................................................................................................................ 19
XI. Les accesseurs et les mutateurs................................................................................................................................. 20
XII. Attribut et méthode statique ....................................................................................................................................... 21
XIII. La référence sur l'objet courant : this ................................................................................................................ 22
Chapitre 3 : HERITAGE et POLYMORPHISME ........................................................................................................................... 23
I. L’HERITAGE .................................................................................................................................................................................. 23
1) Définitions ........................................................................................................................................................................... 23
2) Graphe d’héritage ............................................................................................................................................................. 23
3) Ecriture déclarative ......................................................................................................................................................... 24
4) Héritage multiple.............................................................................................................................................................. 25
5) Les méthodes virtuelles (redéfinition des méthodes) ..................................................................................... 25
6) La référence à la classe mère : super ....................................................................................................................... 26
II. LE POLYMORPHISME .............................................................................................................................................................. 27
1) Définition ............................................................................................................................................................................. 27
2) La redefinition ................................................................................................................................................................... 27
3) Une forme faible de polymorphisme : la surcharge .......................................................................................... 28
Chapitre 4 : LES CLASSES ABSTRAITES, LIEN ET AGREGATION ..................................................................................... 30
I. LES CLASSES ABSTRAITES ................................................................................................................................................ 30
1) Définition ............................................................................................................................................................................. 30
2) Le but des classes abstraites ....................................................................................................................................... 30
II. LIEN ET AGREGATION ................................................................................................................................................... 32
1) L'instanciation (Lien : 'instance de') ........................................................................................................................ 32

1
M.GBOLOVI Support C.O.O-P.O.O
2) L'héritage (Lien : 'est-un') ............................................................................................................................................ 32
3) Les objets complexes (Lien : 'référence-à' et 'composé-de') ........................................................................ 33
4) Agrégation et composition ........................................................................................................................................... 34
Chapitre 5 : LES TABLEAUX, LES CLASSSES TECHNIQUES, CLASSE METIER ET CLASSE COLLECTIONS ... 35
I. LES TABLEAUX............................................................................................................................................................................ 35
1. Déclaration simple de tableau d’objet .............................................................................................................................. 35
2. Tableau comme Objet .............................................................................................................................................................. 35
II. CLASSE METIER /CLASSE TECHNIQUE ........................................................................................................................... 35
III. Les vecteurs (collections) .................................................................................................................................................. 36
PARTIE 3 : UML....................................................................................................................................................................................... 38
Chapitre 6 : UML ..................................................................................................................................................................................... 38
INTRODUCTION...................................................................................................................................................................................... 38
I. GENERALITE ................................................................................................................................................................................ 38
1) Les principes de l’approche objet ............................................................................................................................. 38
a) Abstraction .................................................................................................................................................................... 38
b) Encapsulation ............................................................................................................................................................... 38
c) Héritage ........................................................................................................................................................................... 38
d) Communication des messages (Méthode membre) .................................................................................... 38
e) Polymorphisme............................................................................................................................................................ 38
2) Présentation de UML ...................................................................................................................................................... 38
3) Les 13 diagrammes.......................................................................................................................................................... 39
II. DIAGRAMME DES CAS D’UTILISATION ........................................................................................................................... 39
1) Présentation ....................................................................................................................................................................... 39
2) Les éléments du diagramme ....................................................................................................................................... 39
a) Système : ......................................................................................................................................................................... 39
b) Acteur :............................................................................................................................................................................. 39
c) Cas d’utilisation : ......................................................................................................................................................... 40
d) Association ..................................................................................................................................................................... 40
e) Représentation graphique ...................................................................................................................................... 40
f) Dépendance ................................................................................................................................................................... 40
g) Généralisation .............................................................................................................................................................. 40
h) Résumé des étapes à suivre.................................................................................................................................... 40
3) Description du cas d’utilisation ................................................................................................................................. 42
4) Scénario ................................................................................................................................................................................ 44
III. DIAGRAMME DE CLASSE.................................................................................................................................................... 44
1) Présentation ....................................................................................................................................................................... 44
2) Les éléments du diagramme ....................................................................................................................................... 44
a) Classe ................................................................................................................................................................................ 44
b) Visibilité d'une caractéristique ............................................................................................................................. 44
c) Opération ........................................................................................................................................................................ 45
d) Multiplicité ..................................................................................................................................................................... 45
e) Les classes abstraites ................................................................................................................................................ 45
f) Les interfaces ................................................................................................................................................................ 45
3) Les relations entre classes ........................................................................................................................................... 46
a) L'association.................................................................................................................................................................. 46
b) La dépendance ............................................................................................................................................................. 46
c) La généralisation ......................................................................................................................................................... 46
d) L'implémentation........................................................................................................................................................ 47
e) L'agrégation ................................................................................................................................................................... 47
f) La composition ............................................................................................................................................................. 47
g) Classe association : ..................................................................................................................................................... 48
h) Association réflexive : ............................................................................................................................................... 48
4) Résumé des éléments du diagramme de classes ................................................................................................ 48
IV. Diagramme d’états ................................................................................................................................................................ 50
1) Présentation ....................................................................................................................................................................... 50
2) Les éléments du diagramme ....................................................................................................................................... 50
a) Etat .................................................................................................................................................................................... 50

2
M.GBOLOVI Support C.O.O-P.O.O
b) Evénement : ................................................................................................................................................................... 51
c) Transition ....................................................................................................................................................................... 51
d) Action ............................................................................................................................................................................... 52
e) Etat composé ou super-etat ................................................................................................................................... 52
3) Le diagramme .................................................................................................................................................................... 52
4) Résumé des éléments du diagramme d’états....................................................................................................... 53
V. Diagramme de séquence ......................................................................................................................................................... 55
1) Présentation ....................................................................................................................................................................... 55
2) Les éléments du diagramme ....................................................................................................................................... 56
a) Interactions: .................................................................................................................................................................. 56
b) Un objet et sa ligne de vie ........................................................................................................................................ 56
c) Agencement des messages ..................................................................................................................................... 56
d) Activations d'un objet de manière simple et par l'intermédiaire d'un autre objet ....................... 57
e) Rôle du diagramme séquence .............................................................................................................................. 58
3) Résumé des éléments du diagramme d’états....................................................................................................... 58
4) DIAGRAMME DE SEQUENCE SYSTEME.................................................................................................................. 60
VI. DIAGRAMME DES COMPOSANTS ................................................................................................................................... 61
1) Les éléments du diagramme ....................................................................................................................................... 61
a) Composant ..................................................................................................................................................................... 61
b) Interfaces d'un composant: .................................................................................................................................... 61
c) Diagramme de composants: ................................................................................................................................... 62
e) Relation de dépendance : ........................................................................................................................................ 62
VII. DIAGRAMME DE DEPLOIEMENT ................................................................................................................................... 63
VIII. Les autres diagrammes .................................................................................................................................................. 64
1) Diagramme d'objets ........................................................................................................................................................ 64
1) Diagramme d'activité ..................................................................................................................................................... 64
2) Diagramme de communication (collaboration) ................................................................................................. 65
3) Diagramme de packages ............................................................................................................................................... 66
4) Diagramme de structure composite ........................................................................................................................ 66
5) Diagramme global d'interaction ................................................................................................................................ 66
6) Diagramme de temps ...................................................................................................................................................... 66
PARTIE 4 : LA PRATIQUE EN LANGAGE JAVA(TP) ................................................................................................................. 67
Chapitre 7 : Présentation du langage ............................................................................................................................................ 67
1) Origines du langage ......................................................................................................................................................... 67
2) Le langage Java est simple, familier et orienté objet ........................................................................................ 67
3) Le langage Java est distribué ....................................................................................................................................... 67
4) Le langage Java est robuste et sûr............................................................................................................................. 67
5) Le langage Java est portable et indépendant des plates-formes :............................................................... 67
6) Le langage Java est dynamique et multithread ................................................................................................... 68
7) La plate-forme de développement JAVA ................................................................................................................ 68
8) Java et la programmation événementielle ............................................................................................................ 68
a) Les programmes à interface console (ou en ligne de commande)........................................................ 68
b) Les programmes à interface graphique (G.U.I.)............................................................................................. 68
c) La gestion des interfaces graphiques est intégrée dans Java .................................................................. 69
d) Applications et applets ............................................................................................................................................. 69
9) Le programme « Hello World » .................................................................................................................................. 69
CHAPITRE 8 : LA PROGRAMMATION OBJET ............................................................................................................................. 70
1) Les classes ........................................................................................................................................................................... 70
a. Définition ........................................................................................................................................................................ 70
b. Déclaration et instanciation des classes ........................................................................................................... 70
c. Les attributs (les champs) ................................................................................................................................................. 71
d. Les méthodes ........................................................................................................................................................................... 72
e. Les constructeurs........................................................................................................................................................ 74
2) La référence sur l'objet courant : this ..................................................................................................................... 75
3) Droit d’acces (Encapsulation) ..................................................................................................................................... 75

3
M.GBOLOVI Support C.O.O-P.O.O
4) Les accesseurs et les mutateurs................................................................................................................................. 76
5) La référence vide : null................................................................................................................................................... 77
6) Les tableaux ........................................................................................................................................................................ 77
a) Création et utilisation d’un tableau..................................................................................................................... 78
b) Affectation de tableaux ............................................................................................................................................. 79
c) La taille d’un tableau : length................................................................................................................................. 80
d) Exemple de tableau d’objets .................................................................................................................................. 80
CHAPITRE 9 : L’HERITAGE ................................................................................................................................................................ 81
1) Principes généraux, le mot clé extends .................................................................................................................. 81
2) Accès à la super-classe d'une classe : super(…) .................................................................................................. 81
3) Le Polymorphisme ........................................................................................................................................................... 82
4) Méthodes et classes abstraites : abstract .............................................................................................................. 84
a) Les classes abstraites ................................................................................................................................................ 84
b) Les méthodes abstraites .......................................................................................................................................... 84
CHAPITRE 10: LES PACKAGES, LES INTERFACES ET LES EXCEPTIONS ...................................................................... 85
I. LES PACKAGES ET L’ENCAPSULATION ........................................................................................................................... 85
1) Les packages ....................................................................................................................................................................... 85
2) La structure de stockage des classes et des packages ..................................................................................... 86
3) Les principaux packages du JDK ................................................................................................................................ 86
4) Paquetages et droits d’accès........................................................................................................................................ 87
II. LES INTERFACES........................................................................................................................................................................ 88
1) Définitions, les mots clés interface et implements. ........................................................................................... 88
2) Interfaces et héritage ...................................................................................................................................................... 88
III. LES EXCEPTIONS ................................................................................................................................................................... 89
CHAPITRE 11 : LES CLASSES DE BASE ........................................................................................................................................ 92
1) La classe Object ................................................................................................................................................................. 92
2) Les chaînes de caractères ............................................................................................................................................. 93
a) La classe java.lang.String ......................................................................................................................................... 93
b) La classe java.lang.StringBuffer ............................................................................................................................ 94
3) Les conteneurs................................................................................................................................................................... 95
a) La classe java.util.Vector .......................................................................................................................................... 95
b) L'interface java.util.Enumeration ........................................................................................................................ 96
c) la généricité en Java ................................................................................................................................................... 97
d) Collection ........................................................................................................................................................................ 97
e) Listes ................................................................................................................................................................................. 98
PARTIE 5 : LA PROGRAMMATION A GRANDE ECHELLE .................................................................................................. 100
CHAPITRE 12: LA PROGRAMMATION A GRANDE ECHELLE .......................................................................................... 100
I. Gestion d’une équipe ......................................................................................................................................................... 100
II. Méthodologie de développement........................................................................................................................... 100
III. Communication entre composants ....................................................................................................................... 101

4
M.GBOLOVI Support C.O.O-P.O.O
TECHNIQUES DE CONCEPTION ET DE
PROGRAMMATION ORIENTEE OBJET

INTRODUCTION
La programmation classique telle qu’étudiée au travers des langages procéduraux comme le
C, le Pascal… définie un programme comme étant un ensemble de données sur lesquelles
agissent des procédures et des fonctions. Les données constituent la partie passive du
programme. Les procédures et les fonctions constituent la partie active.

Dans cette approche données et procédures sont traitées indépendamment les unes des autres
sans tenir compte des relations étroites qui les unissent.

Les langages objets sont nés pour améliorer la conception et le développement des logiciels.
Ils sont fondés sur la connaissance d’une seule catégorie d’entités informatiques : les objets.

Un objet incorpore des aspects statiques et dynamiques au sein d’une même notion. La
Programmation Orientée Objet(POO) est une méthode d’implémentation dans laquelle les
programmes sont organisés sous formes de collections coopératives d’objets, dont chacun
représente une instance d’une classe quelconque et dont toutes les classes sont membres d’une
hiérarchie de classes unis à travers des relations d’héritage.

Ainsi dans l’approche orienté objet un algorithme sera essentiellement vu comme un


ensemble d’objets auxquels l’utilisateur envoie des messages et qui s’en envoient pendant le
fonctionnement.

Il y a des langages de modélisation Orienté Objet dont l’UML qui couvre tout le processus
depuis la spécification des besoins jusqu’au déploiement du logiciel.

De façon simple, la programmation par objet facilite le développement de programmes


complexes, facilite leur maintenance, et améliore la réutilisabilité du code. Par-dessus cela et
afin de programmer par objet on a des méthodologies de développement logiciel.

5
M.GBOLOVI Support C.O.O-P.O.O
PARTIE 1 : GENIE LOGICIEL

CHAPITRE 1 : GENIE LOGICIEL

Du point de vue du génie logiciel, la programmation orientée objets a de nombreux avantages


qui résident principalement en 3 mots-clés : fiabilité, maintenabilité et réutilisabilité.
En particulier, on a :
– l’encapsulation des données (protection entre composants)
– une abstraction entre implantation et utilisation
– une meilleure compréhension du logiciel (vision modulaire)
– une réutilisation aisée (directe ou par héritage)
– un code réduit (héritage, liaison retardée)
– une propagation des modifications longitudinales (par héritage)

un projet est donc un ensemble cohérent d’activités (appelées "phases"), entreprises pour
atteindre un objectif défini, à savoir la mise à disposition de produits intermédiaires (des
"livrables") conduisant à la réalisation d’un produit unique satisfaisant un besoin particulier.
I. Définition
Le Génie logiciel (‘Software Engineering’ en anglais), GL, est un domaine des ‘sciences de
l’ingénieur’ dont la finalité est la conception, la fabrication et la maintenance de systèmes
logiciels complexes, sûrs et de qualité. Aujourd’hui, les économies de tous les pays
développés sont dépendantes des systèmes logiciels. Par conséquent, l’ingénierie du logiciel a
une place importante et une lourde responsabilité dans le bon fonctionnement des
équipements et des institutions. Par exemple, la réservation de billets de train est impossible,
la faute est imputée au logiciel. Les avions ne peuvent plus atterrir, la faute est imputée au
logiciel de commande des radars... et on peut multiplier ainsi les exemples. Les fautes du
logiciel ont de plus en plus de conséquences visibles même pour le grand public.
Le GL se définit souvent par opposition à la ‘programmation’, c’est-à-dire la production d’un
programme par un individu unique, considérée comme ‘facile’. Dans le cas du GL, il s’agit de
la fabrication collective d’un système complexe, concrétisée par un ensemble de documents de
conception, de programmes et de jeux de tests avec souvent de multiples versions, et
considérée comme ‘difficile’.
II. Objectifs
Le GL se préoccupe des procédés de fabrication des logiciels de façon à s’assurer que les
quatre critères suivants soient satisfaits.
 Le système qui est fabriqué répond aux besoins (exigences) des utilisateurs (correction
fonctionnelle).
 La qualité correspond au contrat de service initial. La qualité du logiciel est une notion
multiforme qui recouvre notamment :
 la validité : aptitude d’un logiciel à réaliser exactement les tâches définies par sa
spécification,
 la fiabilité : aptitude d’un logiciel à assurer de manière continue le service attendu,
 la robustesse : aptitude d’un logiciel à fonctionner même dans des conditions
anormales,
 l’extensibilité : facilité d’adaptation d’un logiciel aux changements de spécification,

6
M.GBOLOVI Support C.O.O-P.O.O
la réutilisabilité : aptitude d’un logiciel à être réutilisé en tout ou partie,
la compatibilité : aptitude des logiciels à pouvoir être combinés les uns aux autres,
l’efficacité : aptitude d’un logiciel à bien utiliser les ressources matérielles (mémoire,
CPU...),
 la portabilité : facilité à être porté sur de nouveaux environnements matériels et/ou
logiciels,
 la traçabilité : capacité à identifier et/ou suivre un élément du cahier des charges lié à
un composant d’un logiciel,
 la vérifiabilité : facilité de préparation des procédures de recette et de certification,
 l’intégrité : aptitude d’un logiciel à protéger ses différents composants contre des
accès ou des modifications non autorisés,
 la facilité d’utilisation, d’entretien, etc.
 Les coûts restent dans les limites prévues au départ.
 Les délais restent dans les limites prévues au départ.
Ces qualités sont parfois contradictoires. Il faut les pondérer selon les types d’utilisation. Il
faut aussi distinguer les systèmes sur mesure et les produits logiciels de grande diffusion.

III. Caractéristiques
Le GL est en forte relation avec presque tous les autres domaines de l’informatique : langages
de programmation (modularité, orientation objet, parallélisme...), bases de données
(modélisation des données, accès aux données...), informatique théorique (automates, réseaux
de Petri, types abstraits...), etc.
Le GL est aussi en relation avec d’autres disciplines de l’ingénieur : ingénierie des systèmes
et gestion de projets, sûreté et fiabilité des systèmes, etc. Les principales branches du GL
couvrent :
 la conception,
 la validation/vérification,
 la gestion de projet et l’assurance qualité,
 les aspects socio-économiques.
Dans sa partie technique, le GL présente un spectre très large depuis des approches très
formelles (Spécifications formelles, approches transformationnelles, preuves de programmes)
jusqu’à des démarches absolument empiriques. Cette variété reflète la variété des types de
systèmes à produire :
 gros systèmes de gestion (ou systèmes d’information) ; le plus souvent des systèmes
transactionnels construits autour d’une base de données;
 systèmes temps réel, qui doivent répondre à des événements dans des limites de temps
prédéfinies et strictes ;
 systèmes distribués sur un réseau de machines (distribution des données et/ou des
traitements), architectures liées surtout à Internet ;
 systèmes embarqués et systèmes critiques, interfacés avec un système à contrôler (ex:
aéronautique, centrales nucléaires...).
Le GL est difficile à étudier car très vaste, pas toujours très précis (beaucoup de discours
généraux), foisonnant dans les concepts et le vocabulaire, sensible aux effets de modes. Les
aspects techniques nécessitent une bonne maîtrise des outils fondamentaux de l’informatique
(programmation, BD, système/réseau...). Dans les sections suivantes, nous allons passer en
revue les principes généraux, les techniques spécialisées, les méthodes et outils pour le GL.

7
M.GBOLOVI Support C.O.O-P.O.O
IV. Principes fondamentaux
Cette section liste sept principes fondamentaux (proposés par Carlo Ghezzi):
 rigueur,
 séparation des problèmes,
 modularité,
 abstraction,
 généricité,
 construction incrémentale,
 anticipation du changement.
Rigueur. La production de logiciel est une activité créative, mais qui doit se conduire avec
une certaine rigueur. Le niveau maximum de rigueur est la formalité, c’est-à-dire le cas où les
descriptions et les validations s’appuient sur des notations et lois mathématiques. Il n’est pas
possible d’être formel tout le temps : il faut bien construire la première description formelle à
partir de connaissances non formalisées !
Mais dans certaines circonstances les techniques formelles sont utiles.
Séparation des problèmes. C’est une règle de bon sens qui consiste à considérer séparément
différents aspects d’un problème afin d’en maîtriser la complexité. C’est un aspect de la
stratégie générale du « diviser pour régner ». Elle prend une multitude de formes :
 séparation dans le temps (les différents aspects sont abordés successivement),
 séparation des qualités que l’on cherche à optimiser à un stade donné (ex : assurer la
correction avant de se préoccuper de l’efficacité),
 séparations des vues que l’on peut avoir d’un système (ex : se concentrer sur l’aspect
données avant de considérer l’aspect traitements),
 -séparation du système en parties (sous-systèmes),…
Modularité. Un système est modulaire s’il est composé de sous-systèmes plus simples, ou
modules. La modularité est une propriété importante de tous les procédés et produits
industriels (cf. l’industrie automobile où le produit et le procédé sont très structurés et
modulaires). La modularité permet de considérer séparément le contenu du module et les
relations entre modules (ce qui rejoint l’idée de séparation des questions). Elle facilite
également la réutilisation de composants bien délimités. Un bon découpage modulaire se
caractérise par une forte cohésion interne des modules (ex : fonctionnelle, temporelle,
logique...) et un faible couplage entre les modules (relations inter modulaires en nombre
limité et clairement décrites). Toute l’évolution des langages de programmation (orientés
objets notamment) vise à rendre plus facile une programmation modulaire, appelée
aujourd’hui ‘programmation par composants’.
Abstraction. L’abstraction consiste à ne considérer que les aspects jugés importants d’un
système à un moment donné, en faisant abstraction des autres aspects (c’est encore un
exemple de séparation des problèmes). Une même réalité peut souvent être décrite à différents
niveaux d’abstraction. L’abstraction permet une meilleure maîtrise de la complexité.
Généricité. Il est parfois avantageux de remplacer la résolution d’un problème spécifique par
la résolution d’un problème plus général. Cette solution générique (paramétrable ou
adaptable) pourra être réutilisée plus facilement. Exemple : plutôt que d’écrire une
identification spécifique à un écran particulier, écrire (ou réutiliser) un module générique
d’authentification (saisie d’une identification - éventuellement dans une liste - et
éventuellement d’un mot de passe).
Construction incrémentale. Un procédé incrémental atteint son but par étapes en s’en
approchant de plus en plus ; chaque résultat est construit en étendant le précédent. On peut par
exemple réaliser d’abord un noyau des fonctions essentielles et ajouter progressivement les

8
M.GBOLOVI Support C.O.O-P.O.O
aspects plus secondaires. Ou encore, construire une série de prototypes ‘simulant’ plus ou
moins complètement le système envisagé.
Anticipation du changement. La caractéristique essentielle du logiciel, par rapport à d’autres
produits, est qu’il est presque toujours soumis à des changements continuels (corrections
d’imperfections et évolutions en fonction des besoins qui changent). Ceci requiert des efforts
particuliers pour prévoir, faciliter et gérer ces évolutions inévitables. Il faut, par exemple,
faire en sorte que les changements soient les plus localisés possibles (bonne modularité), ou
encore être capable de gérer les multiples versions des modules et configurations des versions
des modules, constituant des versions du produit complet.
Il faut noter que les principes ci-dessus sont très abstraits et ne sont pas utilisables
directement. Mais ils font partie du vocabulaire de base du génie logiciel. Ces principes ont un
impact réel sur beaucoup d’aspects et constituent le type de connaissances le plus stable, dans
un domaine où les outils, les méthodes et les techniques évoluent très vite.
V. Les design Patterns (Patron de conception)

En développement logiciel, un patron de conception (en anglais : « design pattern ») est un


arrangement caractéristique de modules, reconnu comme bonne pratique en réponse à un
problème de conception d'un logiciel. Ils sont un recueil de bonnes pratiques de conception
pour éviter un certain nombre de problèmes récurrents en programmation orientée objet. Il
décrit une solution standard, utilisable dans la conception de différents logiciels.

Un patron de conception est issu de l'expérience des concepteurs de logiciels. Il décrit sous
forme de diagrammes un arrangement récurrent de rôles et d'actions joués par des modules
d'un logiciel, et le nom du patron sert de vocabulaire commun entre le concepteur et le
programmeur. D'une manière analogue à un patron de couture, le patron de conception décrit
les grandes lignes d'une solution, qui peuvent ensuite être modifiées et adaptées en fonction
des besoins.

Les patrons de conception décrivent des procédés de conception généraux et permettent en


conséquence de capitaliser l'expérience appliquée à la conception de logiciel. Ils ont une
influence sur l'architecture logicielle d'un système informatique.

1)Description

Les patrons servent à documenter des bonnes pratiques basées sur l'expérience. Ils sont le
résultat d'une synthèse de l'expérience acquise par les ingénieurs. Les patrons spécifient des
solutions à des problèmes qui ne peuvent pas être résolus par un composant isolé: La
description de la plupart des patrons implique plusieurs rôles qui peuvent être joués par
plusieurs composants d'un logiciel. Par exemple le patron Observer implique deux rôles qui
sont le sujet et l’observateur.

Les patrons apportent un vocabulaire commun entre l'architecte et le programmeur: Si le


programmeur connait le patron de conception Observer, alors l'architecte n'aura pas besoin de
lui donner de longues explications et le dialogue se limitera à « ici j'ai utilisé un Observer »

En programmation informatique, les patrons de conception peuvent être utilisés avant,


pendant, ou après le travail de programmation: Utilisé avant, le programmeur utilisera le

9
M.GBOLOVI Support C.O.O-P.O.O
patron comme guide lors de l'écriture du code source. Utilisé après il servira comme exemple
pour relier différents modules de code source déjà écrits, ce qui implique d'écrire le code
source nécessaire à leur liaison, et le code qui les fera correspondre au patron de conception.
Utilisé pendant le travail de programmation, le programmeur constatera que le code qui vient
d'être écrit a des points communs avec un patron existant et effectuera les modifications
nécessaires pour que le code corresponde au patron.

2) Le Modèle Vue Controleur


Introduction
L'architecture Modèle Vue Contrôleur (MVC) est un motif de conception pour le
développement d'applications logicielles qui sépare le modèle de données, l'interface
utilisateur et la logique de contrôle.
Ce motif a été mis au point en 1979 par Trygve Reenskaug, qui travaillait alors sur Smalltalk
dans les laboratoires de recherche Xerox PARC.
Présentation
Ce modèle d'architecture impose la séparation entre les données, les traitements et la
présentation, ce qui donne trois parties fondamentales dans l'application finale : le modèle, la
vue et le contrôleur.
 Le Modèle représente le comportement de l'application : traitements des données,
interactions avec la base de données, etc. Il décrit les données manipulées par l'application
et définit les méthodes d'accès.
 La Vue correspond à l'interface avec laquelle l'utilisateur interagit. Les résultats renvoyés
par le modèle sont dénués de toute présentation mais sont présentés par les vues. Plusieurs
vues peuvent afficher les informations d'un même modèle. Elle peut être conçue en html,
ou tout autre langage de présentation. La vue n'effectue aucun traitement, elle se contente
d'afficher les résultats des traitements effectués par le modèle, et de permettre à
l'utilisateur d'interagir avec elles.
 Le Contrôleur prend en charge la gestion des événements de synchronisation pour mettre à
jour la vue ou le modèle. Il n'effectue aucun traitement, ne modifie aucune donnée, il
analyse la requête du client et se contente d'appeler le modèle adéquat et de renvoyer la
vue correspondant à la demande.
En résumé, lorsqu'un client envoie une requête à l'application, celle-ci est analysée par le
contrôleur, qui demande au modèle approprié d'effectuer les traitements, puis renvoie la vue
adaptée au navigateur, si le modèle ne l'a pas déjà fait.
Un avantage apporté par ce modèle est la clarté de l'architecture qu'il impose. Cela simplifie la
tâche du développeur qui tenterait d'effectuer une maintenance ou une amélioration sur le
projet. En effet, la modification des traitements ne change en rien la vue. Par exemple on peut
passer d'une base de données de type SQL à XML en changeant simplement les traitements
d'interaction avec la base, et les vues ne s'en trouvent pas affectées. Le MVC montre ses
limites dans le cadre des applications utilisant les technologies du web, bâties à partir de
serveurs d'applications. Des couches supplémentaires sont alors introduites ainsi que les
mécanismes d'inversion de contrôle et d'injection de dépendance.
Relations structurelles
Il est important de noter que la vue et le contrôleur dépendent tous deux du modèle. En
revanche, le modèle ne dépend ni de la vue ni du contrôleur. C'est l'un des principaux
avantages de la séparation. Cette séparation des tâches permet de créer et de tester le modèle
indépendamment de la représentation visuelle.

10
M.GBOLOVI Support C.O.O-P.O.O
La séparation entre la vue et le contrôleur est secondaire dans la plupart des applications
clientes riches et, en effet, de nombreuses infrastructures d'interface utilisateur implémentent
les rôles comme un seul objet. Dans les applications Web, a contrario, la séparation entre la
vue (le navigateur) et le contrôleur (les composants côté serveur gérant les requêtes HTTP) est
clairement définie.

11
M.GBOLOVI Support C.O.O-P.O.O
PARTIE 2 : LES CONCEPTS OBJET

Chapitre 2 : PRESENTATION DE LA NOTION OBJET


Le monde dans lequel nous vivons est constitué d'objets. Les méthodes actuelles de
développement informatique permettent de manipuler le concept d'objets. La Programmation
Orientée Objet(POO) consiste à modéliser un ensemble d’éléments du monde réel en un
ensemble d’entités informatiques appelés objet. Cela est plus proche du monde réel, dans
lequel tous les objets disposent d’attributs auxquels sont associés des activités.

I. Définitions d’un objet


Un objet est une entité cohérente rassemblant des données et du code travaillant sur ses
données. Une classe peut être considérée comme un moule à partir duquel on peut créer des
objets. En fait, on considère plus souvent que les classes sont les descriptions des objets,
lesquels sont des instances de leur classe.

Pourquoi ce vocabulaire ? Une classe décrit la structure interne d'un objet : les données qu'il
regroupe, les actions qu'il est capable d'assurer sur ses données. Un objet est un état de sa
classe. Considérons par exemple la modélisation d'un véhicule telle que présentée par la
figure suivante :

Légende :
# : Protégé
- : Privé
+ : public Figure 1.1 Représentation de la classe Véhicule
La classe Vehicule possède les attributs NombreDeVehicules, Marque puissance fiscale,
vitesse maximale, vitessecourante et des methodes creerUnvehicule(), detriureUnVehicule(),
demarrer(), accelerer(), avancer() et reculer().

12
M.GBOLOVI Support C.O.O-P.O.O
II. LES OBJETS, ATTRIBUTS ET METHODES

La principale difficulté d’un algorithme par objet sera dans la détermination des bons objets.
Ceci constitue l’objectif de l’étape d’analyse et conception qui précède la mise en place d’une
application informatique.

a) La notion d’objet
L'informaticien et le non informaticien peuvent avoir un langage commun basé sur ce
concept. Un objet au sens informatique du terme permet de désigner une représentation
"abstraite" d'une chose concrète du monde réel ou virtuel. Un objet présente les
caractéristiques suivantes :

Objet = État + Comportement

L'état d'un objet définit la valeur des données (ou attributs), par exemple dans le cas d'un
objet Moto, celui-ci pourrait être caractérisé par les attributs suivants : la marque, la couleur,
le poids, la puissance, la quantité d'essence... Ce que l'on représente graphiquement par :

L'état de l'objet peut être amené à changer durant son cycle de vie. Par exemple, la quantité
d'essence et le poids de la moto varient en permanence lorsque celle-ci roule.

• Le comportement d'un objet indique toutes les compétences de celui-ci et décrit les actions
et les réactions qu'il peut avoir. Chaque élément de base du comportement est appelé
opération. Les opérations d'un objet sont déclenchées suite à une stimulation externe de
l'utilisateur qui appuie sur un bouton ou du programmeur qui appelle une opération. Il existe
un lien très étroit entre le comportement d'un objet et son état.

b) La notion de classe
On appelle classe la structure d'un objet, c'est-à-dire la déclaration de l'ensemble des entités
qui composeront un objet.

Une classe est composée de deux parties:

 Les attributs ou données membres: données représentant l'état de l'objet,


 Les méthodes ou fonctions membres: opérations applicables aux objets.

c) Attributs
Les attributs d’un objet sont l’ensemble des informations se présentant sous forme de variable
et permettant de représenter l’état de l’objet.

13
M.GBOLOVI Support C.O.O-P.O.O
d) Méthodes
Une méthode est une fonction ou procédure liée à un objet qui est déclenchée à la réception
d’un message particulier : la méthode déclenchée correspond strictement au message reçu. La
liste des méthodes définies au sein d’un objet constitue l’interface de l’objet pour l’utilisateur.

e) Message
Un message est une demande d’activation d’une méthode envoyé à un objet. Les messages
auquel l’objet peut répondre sont en fait les intitulés des méthodes qu’il peut déclencher : les
identificateurs et le type des paramètres nécessaires.

III. Création d’un objet


La figure suivante montre l'opération d'instanciation de la classe en 2 objets différents :

Figure 1.2 Instanciation d’une classe en deux objets

IV. Le principe d’encapsulation


Ce principe prône les idées suivantes :
 Un objet rassemble en lui-même ses données (les attributs) et le code capable d'agir
dessus (les méthodes),
 Abstraction de données : la structure d'un objet n'est pas visible à l'extérieur, son
interface est constituée de messages invocables par un utilisateur. La réception d'un
message déclenche l'exécution de méthodes.
 Abstraction procédurale : du point de vue de l'extérieur l'invocation d'un message est
une opération atomique. L'utilisateur n'a aucun élément d'information sur la mécanique

14
M.GBOLOVI Support C.O.O-P.O.O
interne mise en œuvre. Par exemple, il ne sait pas si le traitement requis a demandé
l’intervention de plusieurs méthodes ou même la création d’objets temporaires ...
Dans les versions canoniques du paradigme objet, les services d'un objet ne sont invocables
qu’au travers de messages (méthode), lesquels sont individuellement composés de:
 Un nom,
 Une liste de paramètres en entrée,
 Une liste de paramètres en sortie.

On précise trois modes d’accès aux attributs et méthodes d’un objet :


- Le mode public avec lequel les éléments seront accessibles directement par l’objet lui-même
ou par d’autres objets. Il s’agit du niveau le plus bas de protection.
- Le mode privé avec lequel les éléments de l’objet seront inaccessibles à partir d’autres
objets : seules les méthodes de l’objet pourront y accéder. Il s’agit du niveau le plus fort de
protection.
- Le mode protégé : avec lequel les attributs de l’objet seront accessibles par les méthodes de
l’objet et les classes filles(Héritage).

V. Attribut d’instance, attribut de classe, méthode


d’instance, méthode de classe
Dans le modèle précédent, un véhicule est représenté par une chaîne de caractères (sa marque)
et trois entiers : la puissance fiscale, la vitesse maximale et la vitesse courante. Toutes ces
données sont représentatives d'un véhicule particulier, autrement dit, chaque objet véhicule
aura sa propre copie de ses données : on parle alors d'attribut d'instance. L'opération
d'instanciation qui permet de créer un objet à partir d'une classe consiste précisément à
fournir des valeurs particulières pour chacun des attributs d'instance.

En revanche, considérons l'attribut Nombre de véhicules chargé de compter le nombre de


véhicules présents à un moment donné dans la classe. Il est incrémenté par l'opération Créer
un véhicule et décrémenté par l'opération Détruire un véhicule. C'est un exemple typique
d'attribut partagé par l'ensemble des objets d'une même classe. Il est donc inutile et même
dangereux (penser aux opérations de mise à jour) que chaque objet possède sa copie propre de
cet attribut, il vaut mieux qu'ils partagent une copie unique située au niveau de la classe. On
parle donc d'attribut de classe.

Le même raisonnement s'applique directement aux méthodes. En effet, de la même manière


que nous avions établi une distinction entre attributs d'instance et attributs de classe, nous
allons différencier méthodes d'instances et méthodes de classe.

Prenons par exemple la méthode Démarrer. Il est clair qu'elle peut s'appliquer
individuellement à chaque véhicule pris comme entité séparée. En outre, cette méthode va
clairement utiliser les attributs d'instance de l'objet auquel elle va s'appliquer c'est donc une
méthode d'instance.

Considérons désormais le cas de la méthode Créer un véhicule. Son but est de créer un
nouveau véhicule, lequel aura, dans un second temps, le loisir de positionner des valeurs
initiales dans chacun de ces attributs d'instance. Si nous considérons en détail le processus
permettant de créer un objet, nous nous apercevons que la première étape consiste à allouer de

15
M.GBOLOVI Support C.O.O-P.O.O
la mémoire pour le nouvel objet. Hors cette étape n'est clairement pas du ressort d'un objet :
seule la classe possède suffisamment d'informations pour la mener à bien : la création d'un
objet est donc en partie une méthode de classe. Notons également qu'au cours de cette étape,
l'objet recevra des indications additionnelles, telles que, par exemple, une information lui
indiquant à quelle classe il appartient. En revanche, considérons la phase d'initialisation des
attributs. Celle-ci s'applique à un objet bien précis : celui en cours de création. L'initialisation
des attributs est donc une méthode d'instance.
Nous aboutissons finalement au constat suivant : la création d'un nouvel objet est constituée
de deux phases :
Une phase du ressort de la classe : allouer de la mémoire pour le nouvel objet et lui fournir
un contexte d'exécution minimaliste.
Une phase du ressort de l'objet : initialiser ses attributs d'instance.

Si ces deux phases sont clairement séparées dans un langage tel que l'objective C, elles ne le
sont plus en C++ ou en Java qui agglomèrent toute l'opération dans une méthode spéciale, ni
vraiment méthode d'instance, ni méthode de classe : le constructeur.

Remarque
La liste des messages auxquels est capable de répondre un objet constitue son interface : c'est
la partie publique d'un objet. Tout ce qui concerne son implémentation doit rester caché à
l'utilisateur final : c'est la partie privée de l'objet. Bien entendu, tous les objets d'une même
classe présentent la même interface.

VI. La création d’une classe

Une classe est un type de données abstrait caractérisé par des propriétés (attributs et
méthodes) communes à des objets et permettant de créer des objets possédant ces propriétés.

Les inscriptions précises permettent de créer les objets définis en deux temps :

 La création de la classe,
 La création effective et utilisable de l’objet comme instance au quelle on peut envoyer
des messages.

a) La déclaration d’une classe


La création de la classe contient la déclaration de la classe (des attributs et méthodes) et la
définition des méthodes.

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

Classe « nomDeLaclasse »

Debut

Déclaration des attributs

16
M.GBOLOVI Support C.O.O-P.O.O
Signature des methodes

Fin

Exemple de la classe Compte :

La déclaration de la classe compte revient à définir son numéro et son solde et à préciser
comment accéder à ces informations.

La classe compte possède les deux attributs numéro et solde et quatre méthodes :

 La méthode créer(chaine,réel), qui permet de donner des valeurs aux attributs,


 La méthode debiter (montant :réel), qui diminue le solde,
 La méthode crediter(montant :réel) qui augmente le solde,
 La méthode SoldeCourant() qui récupère le solde courant d’un compte.
Syntaxe de la classe Compte :

Classe Compte
DEBUT
Privé :
Numero :chaine de caracteres
Solde :réel
Public :esiba2017
Procedure Créer(chaine,réel)
Procedure Debiter(montant :réel)
Procedure Crediter(montant :réel)
Fonction Solde_courant() :réel
FIN

Remarque :
La précision d’une méthode notamment le type de ses arguments et du type de données de
retour s’appelle sa signature.

VII. Déclaration et création d’une instance d’une classe


Pour utiliser un objet d’une classe dans un programme on doit créer une instance de la classe
c’est à dire une variable du type de la classe. Les instances indiquent qu’un identifiant est un
objet de la classe et à ce titre se réfère à la classe et possède ses attributs et méthodes. La
création d’une instance de classe se fait en deux étapes :

 La déclaration de l’instance,
 La création effective de l’instance.

a) La déclaration de l’instance
nomInstance :nomClasse

Exemple :

Cpte :Compte

17
M.GBOLOVI Support C.O.O-P.O.O
b) La création effective de l’instance
La création effective de l’instance est effectuée grâce à la méthode de construction appelée
Constructeur et à l’utilisation de new.

Dans l’exemple de la classe Compte c’est la méthode créer () qui remplace le constructeur.

Cpte=new Compte()

VIII. Accès aux éléments de la classe


Une fois qu’un objet est crée on peut accéder aux éléments de la classe par

nomObjet.nomMethode() pour une méthode

nomObjet.attribut pour un attribut

Exemple :Cpte.creer(“0123123891“,175000)

Cpte.Debiter(50000)

IX. Représentation algorithmique de la classe compte


La création de la classe constitue la déclaration de la classe et la rédaction des corps des
méthodes.

Exemple de la classe Compte :

 Déclaration de la classe

Classe Compte
DEBUT
Privé :
Numero :chaine de caracteres
Solde :réel
Public :
Procedure Créer(chaine,réel)
Procedure Debiter(montant :réel)
Procedure Crediter(montant :réel)
Fonction SoldeCourant() :réel
FIN

 Rédaction des corps des méthodes (définition des méthodes)

Procedure Compte ::Créer(num :chaine,sol :réel)


Début
Numero<-num
solde<-sol
Fin
Procedure Compte ::debiter(mtant :réel)
Début
solde<-solde-mtant
Fin

18
M.GBOLOVI Support C.O.O-P.O.O
Procedure Compte ::crediter(mtant :réel)
Début
solde<-solde+mtant
Fin
Fonction Compte ::SoldeCourant() :réel
Début
Retourner solde
Fin

Exemple d’algorithme de manipulation


Algorithme manipCompte
Utilise Compte
Var cp :Compte
Debut
Cp=new Compte()
Cp.creer(“12112121212A “,150000) ;
Afficher“ le solde initial du compte est“,Cp.SoldeCourant()
Cp.crediter(40000)
Afficher“ le solde courant du compte est“,Cp.SoldeCourant()
Cp.debiter(20000) ;
Afficher“ le solde courant du compte est“,Cp.SoldeCourant()
FIN

X. Constructeur et destructeur
Un constructeur est une méthode particulière d’une classe qui permet, lors de la création
effective d’un objet, instance de la classe, d’initialiser ces attributs. Cette méthode porte le
nom de la classe et ne retourne pas de valeur.

Exemple :

Représentation de la classe Rectangle

Classe Rectangle
DEBUT
Privé

19
M.GBOLOVI Support C.O.O-P.O.O
Longueur :réel
Largeur :réel
Public
Rectangle (réel, réel)
Fonction surface () : réel
Fonction périmètre () : réel
Procédure affiche ()
FIN

Rectangle :: Rectangle(lo :réel,lar :réel)


DEBUT
Longueur<-lo
Largeur<-lar
FIN

Fonction Rectangle :: Surface() :réel


DEBUT
Retourner(longueur*largeur)
FIN

Fonction Rectangle :: périmetre() :réel


DEBUT
Retourner(2*(longueur+largeur))
FIN
Procédure Rectangle ::affiche ()
DEBUT
Afficher(“rectangle de longueur : “,longueur,“ et de largeur “,largeur)
FIN
Algorithme testRectangle
Var rect :rectangle
DEBUT
Rect=new Rectangle(12,5.6)
Afficher rect.surface()
Afficher rect.perimetre()
Rect.affiche()
FIN

Inversement, dans la plupart des langages une méthode est exécutée automatiquement quand
l'instance devient hors de portée. Cette méthode qui est appelée avant la libération de l'espace
mémoire associé à l'objet est appelée destructeur.

XI. Les accesseurs et les mutateurs


 La protection des données membres
Les données membres portant l'étiquette privé ne peuvent pas être manipulées directement par
les fonctions membres des autres classes. Ainsi, pour pouvoir manipuler ces données
membres, on doit prévoir des méthodes spéciales portant l'étiquette public, permettant de
manipuler ces données.
 Les fonctions membres permettant d'accéder aux données membres sont appelées
accesseurs, parfois getter (appellation d'origine anglophone).

20
M.GBOLOVI Support C.O.O-P.O.O
Les fonctions membres permettant de modifier les données membres sont appelées

mutateurs, parfois setter (appellation d'origine anglophone).
 La notion d'accesseur
Un accesseur est une fonction membre permettant de récupérer le contenu d'une donnée
membre. Un accesseur, pour accomplir sa fonction :
 doit avoir comme type de retour le type de la variable à renvoyer,
 ne doit pas nécessairement posséder d'arguments.
Une convention de nommage veut que l'on fasse commencer de façon préférentielle le
nom de l'accesseur par le préfixe Get :
Exemple :
Fonction Rectangle ::getLongueur() :réel
DEBUT
Retourner longueur
FIN
Fonction Rectangle ::getLargeur() :réel
DEBUT
Retourner largeur
FIN

 La notion de mutateur

Un mutateur est une méthode (procédure membre) permettant de modifier le contenu d'une
donnée membre. Un mutateur, pour accomplir sa fonction :
 doit avoir comme paramètre la valeur à assigner à la donnée membre. Le paramètre
doit donc être du type de la donnée membre,
 ne doit pas nécessairement renvoyer de valeur (procédure).
Une convention de nommage veut que l'on fasse commencer de façon préférentielle le nom du
mutateur par le préfixe Set.

Exemple
Procédure Rectangle ::setLongeur(l :réel)
DEBUT
Longueur<-l
FIN
Procédure Rectangle ::setLargeur(l :réel)
DEBUT
Largeur<-l
FIN

XII. Attribut et méthode statique


Le mot clé static, utilisé pour un attribut(ou une méthode), permet d'indiquer que cet attribut
(ou méthode) est commun à tous les objets de la classe concernée : il s'agit d'un attribut de la
classe elle-même, et si on modifie cet attribut pour un objet donné, il sera modifié pour tous
les objets de la classe (puisque c'est le même).

21
M.GBOLOVI Support C.O.O-P.O.O
classe Voiture
Debut
prive
static nombre = 0:entier ;
id:entier ;
public
Voiture(id:entier)
Static fonction getNombre():entier
Fin

Un attribut de classe peut être accédé par n'importe quel nom de référence associé à un objet
de cette classe, ou par le nom de la classe elle-même.

XIII. La référence sur l'objet courant : this


Ce mot désigne l’adresse de l’objet invoqué. Il est utilisable uniquement au sein d’une
méthode. Le mot clé this permet de désigner l'objet dans lequel on se trouve, c'est-à-dire que
lorsque l'on désire faire référence dans une méthode à l'objet dans lequel elle se trouve, on
utilise this. C’est une référence sur l'objet courant.
L'objet courant this est en réalité une variable système qui permet de désigner l'objet courant.
this peut être utile :

 Lorsqu'une variable locale (ou un paramètre) "cache", en portant le même nom, un


attribut de la classe.
 Pour déclencher un constructeur depuis un autre constructeur.

Procédure Rectangle ::setLargeur(largeur :réel)


DEBUT
This.largeur<-largeur
FIN

22
M.GBOLOVI Support C.O.O-P.O.O
Chapitre 3 : HERITAGE et POLYMORPHISME

I. L’HERITAGE
1)Définitions
L'héritage est le second des trois principes fondamentaux du paradigme orienté objet
(encapsulation, héritage, polymorphisme). Il est chargé de traduire le principe naturel de
Généralisation / Spécialisation.
En effet, la plupart des systèmes réels se prêtent à merveille à une classification hiérarchique
des éléments qui les composent. Le principe d'héritage est basé sur l'idée qu'un objet
spécialisé bénéficie ou hérite des caractéristiques de l'objet le plus général auquel il rajoute
ses éléments propres.
En termes de concepts objets cela se traduit de la manière suivante :
On associe une classe au concept le plus général, nous l'appellerons classe de base ou
classe mère ou super - classe.
Pour chaque concept spécialisé, on dérive une classe du concept de base. La nouvelle classe
est dite classe dérivée ou classe fille ou sous-classe
On parle également de relation est-un pour traduire le principe de l’héritage.
L'héritage est un mécanisme qui facilite la réutilisation du code et la gestion de son évolution.
Grâce à l'héritage, les objets d'une classe ont accès aux données et aux méthodes de la classe
parente et peuvent les étendre.

2) Graphe d’héritage
Le graphe d’héritage d’un ensemble de classes est la structure représentant la manière dont
ces classes sont liées les unes aux autres par héritage. Ce graphe constitue une hiérarchie.

23
M.GBOLOVI Support C.O.O-P.O.O
3)Ecriture déclarative
Classe Personne
Debut
Privé
Nom :chaine
Age :entier
Sexe :caractere
Public
Personne(chaine,entier,caractere)
Procedure Afficher()
Procedure grandir()
Fin

Classe Etudiant hérite de Personne


Début
Privé
Niveau :entier
Filiere :chaine
Public
Procedure reussir()
Procedure setNiveau()

24
M.GBOLOVI Support C.O.O-P.O.O
Procedure setFiliere()
Fonction getNiveau() :entier
Fonction getFiliere() :chaine
Fin
4)Héritage multiple
Certains langages comme le C++ permettent d’utiliser l’héritage multiple.
Il permet de créer des classes dérivées à partir de plusieurs classes de base.

5)Les méthodes virtuelles (redéfinition des


méthodes)
Il existe des cas ou le type de l’instance qui appelle une méthode n’est pas connu des la
compilation. Il ne sera déterminé qu’à l’exécution du programme. On peut souhaiter alors
redéfinir les méthodes à différents niveau de la hiérarchie de la classe pour que la méthode
effectivement mise en œuvre soit celle du type réel de l’instance au moment de l’exécution.
Dans ce cas on dit que les méthodes sont virtuelles. On parle aussi de la redéfinition des
méthodes dans les classes filles.

Il est donc possible de redéfinir dans une classe fille une méthode déjà définie dans la classe
mère.

Classe Personne
Debut
Privé
Nom :chaine
Age :entier
Sexe :caractere
Public
Personne(chaine,entier,caractere)
Procedure Afficher()
Procedure grandir()
Fin

Classe Etudiant hérite de Personne


Début
Privé :
Niveau :entier
Filiere :chaine
Public:
Etudiant(chaine,entire,caractere,entier,chaine)
Procedure afficher()
Procedure reussir()
Procedure setNiveau()
Procedure setFiliere()
Fonction getNiveu() :entier
Fonction getFiliere() :chaine
Fin
Etudiant ::Etudiant(n :chaine,a :entier,s :caractere,ni :entier,f chaine) :Personne(n,a,s)
DEBUT

25
M.GBOLOVI Support C.O.O-P.O.O
Niveau<-ni
Filiere<-f
FIN
Procedure Etudiant ::afficher()
DEBUT
Pesonne.afficher()
Afficher “est un etudiant de niveau“,niveau,“ et de la filiere“,filiere
FIN
Procedure Etudiant ::reussir()
DEBUT
Si niveau<5 alors niveau<-niveau+1
Finsi
FIN
Procedure Etudiant ::setNiveau(n :entier)
DEBUT
niveau<-n
FIN
Procedure Etudiant ::setFiliere(f:chaine)
DEBUT
filiere<-f
FIN
Fonction Etudiant ::getNiveau() : entier
DEBUT
Retourner niveau
FIN
Fonction Etudiant ::getFiliere() : chaine
DEBUT
Retourner filiere
FIN

6)La référence à la classe mère : super


Le mot clé super permet d'accéder à la version non redéfinie des attributs et méthodes de la
super-classe. Il permet aussi d'appeler un des constructeurs de la classe mère, avec ou sans
paramètres.

Etudiant ::Etudiant(n :chaine,a :entier,s :caractere,ni :entier,f chaine) :


DEBUT
super(n,a,s)
Niveau<-ni
Filiere<-f
FIN
Procedure Etudiant ::afficher()
DEBUT
super.afficher()
Afficher “est un etudiant de niveau“,niveau,“ et de la filiere“,filiere
FIN

26
M.GBOLOVI Support C.O.O-P.O.O
II. LE POLYMORPHISME
1)Définition
Le polymorphisme est le troisième des trois grands principes sur lequel repose le paradigme
objet. Comme son nom l'indique le polymorphisme permet à une méthode d'adopter plusieurs
formes sur des classes différentes. Selon les langages, le polymorphisme pourra s'exprimer sur
l'ensemble des classes d'un système alors que d'autres le confinent aux classes appartenant à
une même hiérarchie.

2)La redefinition
Grâce à la redéfinition, il est possible de redéfinir une méthode dans des classes héritant d’une
classe de base. Par ce mécanisme, une classe qui hérite des méthodes d’une classe de base
peut modifier le comportement de certaines méthodes héritées pour être adaptées aux besoins
de la classe fille
Nous allons démontrer la puissance du polymorphisme au travers de l'exemple classique des
classes d'objets graphiques. Un document dessin peut être vu comme une collection d'objets
graphiques qui va contenir des cercles, des rectangles, des lignes, ou toute autre sorte d'objet
graphique qui pourrait dériver de la classe ObjetGraphique. En effet, une référence sur
un objet d'une classe spécialisée peut toujours être affectée à une référence sur un objet d'une
classe généraliste.
Si nous voulons dessiner un dessin tout entier, il nous faudra appeler la méthode Afficher
pour chacun des objets contenus dans le dessin. Hors, nous avons pris soin de conserver la
même signature pour les différentes méthodes Afficher de tous les objets appartenant à la
hiérarchie d'ObjetGraphique : c'est la condition Sine Qua Non de l'utilisation du
polymorphisme.
Le polymorphisme de la méthode Afficher garantit que la bonne méthode sera appelée
sur chaque objet.

Classe ObjetGraphique
Début
Privé
Message :Chaine
Public
ObjetGraphique(m :chaine)
Procedure affiche()
finClasse
classe Ligne hérite de ObjetForme
Debut
Privé
Longueur :reel
public
Ligne(m :chaine,l :réel)
Procedure affiche()
finClasse
classe Rectangle herite de ObjetGraphique
Debut
Prive
Longueur :reel
Largeur :reel

27
M.GBOLOVI Support C.O.O-P.O.O
Public
Rectangle(m :chaine,long :réel,larg :reel)
Procedure affiche()
finClasse

Il est alors possible d'appeler la méthode d'un objet sans se soucier de son type intrinsèque : il
s'agit du polymorphisme d'héritage (la redéfinition).
Ceci permet de faire abstraction des détails des classes spécialisées d'une famille d'objet,
en les masquant par une interface commune (qui est la classe de base).
Imaginons un jeu d'échec comportant des objets
roi, reine, fou, cavalier, tour et pion, héritant chacun de l'objet piece.
La méthode mouvement() pourra, grâce au polymorphisme d'héritage, effectuer le
mouvement approprié en fonction de la classe de l'objet référencé au moment de
l'appel. Cela permettra notamment au programme de dire piece.mouvement sans
avoir à se préoccuper de la classe de la pièce.

3)Une forme faible de polymorphisme : la surcharge


La surcharge est un mécanisme fréquemment proposé par les langages de programmation
orientés objet et qui permet d’associer au même nom de méthode / fonction / procédure
différentes signatures.
Par exemple, on pourrait proposer deux signatures différentes pour la méthode
Afficher :
Pas d’argument si l’on désire utiliser le périphérique d’affichage par défaut
Spécification d’un périphérique en argument.

Le polymorphisme paramétrique rend ainsi possible le choix automatique de la


bonne méthode à adopter en fonction du type de donnée passée en paramètre.

La surcharge ou surdéfinition des méthodes consiste à définir des méthodes différentes portant
le même nom. Dans ce cas, il faut les différencier par le type et/ou le nombre des arguments.
La surcharge permet de définir des méthodes portant le même nom, mais acceptant des
paramètres de type différents et/ou en nombre différent. En fonction du type et du nombre des
paramètres passés lors de l'appel, c'est une version ou une autre de la méthode qui sera
effectivement appelée.

Attention : Le type de retour d'une méthode ne permet pas de différencier deux méthodes
portant le même nom (si c'est la seule différence).

Ainsi, on peut par exemple définir plusieurs


méthodes homonymes addition() effectuant une somme de valeurs.

 La méthode addition(entier, entier) :entier pourra retourner la somme de deux entiers


 La méthode addition(reel, reel) :reel pourra retourner la somme de deux flottants
 La méthode addition(chaine, chaine) : chaine pourra définir au gré de l'auteur la
somme de deux caractères

28
M.GBOLOVI Support C.O.O-P.O.O
Classe Calcul
Début
Public
Fonction static addition(entier,entier) :entier
Fonction static addition(reel,reel) :reel
Fonction static addition(chaine,chaine) :chaine
finClasse

Classe Rectangle
DEBUT
Privé
Longueur :réel
Largeur :réel
Public
Rectangle (réel, réel)
Rectangle ()
Fonction surface () : réel
Fonction périmètre () : réel
Procédure affiche () : vide
FIN

Rectangle :: Rectangle(lo :réel,lar :réel)


DEBUT
Longueur<-lo
Largeur<-lar
FIN
Rectangle :: Rectangle()
DEBUT
Longueur<-0
Largeur<-0
FIN

29
M.GBOLOVI Support C.O.O-P.O.O
Chapitre 4 : LES CLASSES ABSTRAITES, LIEN ET
AGREGATION
I. LES CLASSES ABSTRAITES

1)Définition
Une classe est dite abstraite si elle ne peut pas être directement instanciée, elle peut ne pas
fournir d'implémentation pour certaines de ces méthodes qui sont dites méthodes abstraites.
Bien entendu, étant incomplète, une classe abstraite ne peut avoir d'instance. Il appartient
donc à ces classes dérivées de définir du code pour chacune des méthodes abstraites. On
parlera alors de classes concrètes ; les classes concrètes étant les seules à même d’être
instanciées.

Une méthode est dite abstraite lorsqu’on connaît son entête mais pas la manière dont elle peut
être réalisée (c’est à dire on connaît sa signature (déclaration) mais pas sa définition).

On ne peut instancier une classe abstraite : elle est vouée à se spécialiser. Une classe abstraite
peut très bien contenir des méthodes concrètes.

Une classe abstraite pure ne comporte que des méthodes abstraites. En programmation orientée
objet, une telle classe est appelée une interface.

Pour indiquer qu’une classe est abstraite, il faut ajouter le mot-clef abstrait à son nom.

Il est possible de ne pas définir une méthode virtuelle dans une classe : elle devra alors
obligatoirement être définie dans les classes dérivées. On dit qu'une telle méthode est une
méthode virtuelle pure(ou une méthode abstraite). Lorsqu’une classe contient une méthode
abstraite, elle doit être déclarée classe abstraite.

2)Le but des classes abstraites


Le but des classes abstraites est de définir un cadre de travail pour les classes dérivées en
proposant un ensemble de méthodes que l'on retrouvera tout au long de l'arborescence. Ce
mécanisme est fondamental pour la mise en place du polymorphisme. En outre, si l'on
considère la classe Véhicule, il est tout à fait naturel qu'elle ne puisse avoir d'instance : un
véhicule ne correspond à aucun objet concret mais plutôt au concept d'un objet capable de
démarrer, ralentir, accélérer ou s'arrêter, que ce soit une voiture, un camion ou un avion.

Prenons l’exemple des formes géométriques. C’est un bon exemple, on peut imaginer un
programme où on veut calculer la somme des surfaces de plusieurs pièces de formes diverses.
Le parcours de cet ensemble peut se faire à l’aide d’une référence sur une classe Forme, à la
condition que toutes les classes décrivant des objets susceptibles d’apparaitre dans la collection
soient dérivées de Forme. Pour que le calcul de surface puisse être fait par l’intermédiaire d’une
référence sur Forme, il faut que cette classe dispose d’une méthode surface(). Toutefois le calcul
de la surface d’une forme n’a pas de sens: On sait calculer par exemple la surface d’un rectangle
ou d’un disque en fonction de leurs dimensions, mais la notion de forme est trop abstraite pour
permettre la définition du corps de la méthode surface. On peut donc définir la classe de base
ainsi :
classe abstraite Forme

30
M.GBOLOVI Support C.O.O-P.O.O
DEBUT
public :
fonction abstraite surface() :réel //une méthode abstraite
FIN
Bien que la classe Forme ne comporte qu’une seule méthode abstraite, elle n’est pas inutile
puisqu’elle va permettre de mettre en œuvre le polymorphisme.
On peut avoir des classes filles suivantes :
La classe Cercle,
classe Cercle hérite de Forme
Debut
protégé :
rayon :reel
public :
Cercle( r :reel)
Fonction surface():réel
Fin
Cercle ::Cercle(r :reel)
Debut
Rayonr
Fin
Fonction Cercle ::surface() :reel
Var surf :reel
Debut
surf3.14*rayon*rayon
retourner surf
Fin

La classe rectangle
classe Rectangle hérite de Forme
Début
Protégé :
Largeur :reel
Longueur :reel
public:
Rectangle( lg :reel, larg :reel)
Fonction surface():réel
Fin

Rectangle ::Rectangle( lg :reel, larg :reel)


Début
Longueurlg
Largeurlarg
Fin
Fonction Rectangle :: surface() :reel
Debut
retourner longueur*largeur
Fin
Dans un programme principal on pourra manipuler les objets de ces classes :

Programme test

31
M.GBOLOVI Support C.O.O-P.O.O
Var tableau F[0..1] :Forme
C :Cercle
R :Rectangle
Surf :reel
Debut
C=new Cercle(4.5)
R=new Rectangle(4,5)
Surf0
F[0]C
F[1]R
Pour i de 1 à 2 faire
Surfsurf+F[i].surface()
finPour
afficher"la somme des surfaces est ",surf
Fin

Ainsi le rapport entre ces deux classes Rectangle et Cercle est qu’elle dispose chacune de la
méthode surface avec la même signature. Elles sont toutes deux des redéfinitions de la
méthode abstraite déclarée dans la classe Forme dont héritent Cercle et Rectangle. La seule
raison d’être de la classe Forme est de permettre d’établir ce rapport syntaxique qui va par la
suite nous permettre d’appeler ces deux méthodes très différentes comme une seule et unique
méthode.
Le fait que Forme est une classe abstraite à deux avantages :
 il résout le problème du corps de la méthode Forme::surface() ,
 et indique clairement que forme n’existe que pour permettre l’utilisation du
polymorphisme.

II. LIEN ET AGREGATION

On regroupe sous cette notion les différents liens pouvant exister entre les objets au cours
d'une application: l'instanciation, l'héritage, la référence et la composition.

1)L'instanciation (Lien : 'instance de')


Dans le monde réel, les objets sont classés en catégories suivant leurs caractéristiques
(propriétés). Par exemple toutes les 'tasses de café' peuvent être caractérisée par une couleur,
une quantité de boisson et une température, de même que toutes les tasses peuvent être
remplies, vidées et lavées.

Ainsi avant de commencer à créer des objets, il est nécessaire de définir d'abord leurs classes
d'appartenances. La définition d'une classe consiste à lui donner un nom unique et à définir les
attributs et méthodes formant ses propriétés.

2)L'héritage (Lien : 'est-un')


Lorsqu'on déclare une nouvelle classe C, on a la possibilité de spécifier que cette nouvelle
classe doit hériter des propriétés d'une ou de plusieurs classes mères. Ainsi les nouvelles
propriétés définies, seront rajoutées à celles héritées pour former un nouveau concept plus

32
M.GBOLOVI Support C.O.O-P.O.O
spécifique que ceux déjà définis dans les classes mères. La classe C est alors une
spécialisation de ses classes mères. Ces dernières sont appelées les super-classes de C.

3)Les objets complexes (Lien : 'référence-à' et


'composé-de')
Quand on veut représenter un objet du monde réel, on est souvent confronté au problème de la
complexité du concept réel, car beaucoup d'objets courants, sont inter-dépendants et/ou
composés les uns par rapport aux autres. Par exemple un objet voiture est composé d'un grand
nombre d'objets d'autres types comme un moteur, des roues, une carrosserie, un système de
freinage, une boite à vitesse, etc ... Chacun de ces objets (par exemple le moteur) est lui-même
composé d'une multitude d'autres sous-objets (des pistons, des soupapes, des joints, des
boulons, ...). Ce type d'objet aussi complexe soit-il est manipulé de la même manière qu'un
objet simple (comme un entier ou une chaîne de caractères).Pour pouvoir modéliser des objets
complexes, on a la possibilité, lors de la déclaration d'une classe, de définir des attributs ayant
comme type une classe déjà définie. Cette manière de procéder permet d'établir des
associations (liens de référence ou de composition) entre plusieurs classes.

Un lien de composition peut exister par exemple entre la classe voiture et la classe moteur.
Alors qu'entre cette même classe voiture et la classe personne il y a un lien de référence, pour
indiquer qu'une voiture est conduite par une personne.

Un lien de composition est un lien de référence sémantiquement plus riche. Par exemple si v
est un objet de la classe voiture, composé du moteur m et conduite par la personne p.
L'existence de l'objet m dépend de l'objet v, car c'est un sous-objet ou encore un objet
composant. Par contre l'objet p ne fait pas partie de l'objet v, il ne fait pas partie de ses objets
composants. Donc si on décide de détruire l'objet v (par exemple la voiture en question ne fait
plus partie du parc automobile de l'entreprise) tous ses composants doivent aussi être détruits
(son moteur m) de la base de données, par contre son conducteur p reste non affecté par cette
opération (il conduira un autre véhicule par exemple).

33
M.GBOLOVI Support C.O.O-P.O.O
4)Agrégation et composition
Agrégation : A a B

quand : A contient un objet de type B en attribut et au moins un envoi de message.

Agrégation c’est comme une association, au niveau du code. C’est un cas particulier en fait,
ou conceptuellement B est agrégé à A, il y a une relation contenu / contenant, aggrégé /
aggrégeant, une idée de possession. La seule différence entre les deux c'est la sémantique du
lien. Un homme est associé à sa femme (association) et il possède un compte en banque
(aggrégation).

Il y a donc aussi une référence vers l’objet, car c’est une association, et toujours envois de
message.

Exemple : soient les classes Voiture et Roue, une voiture a besoin dans sa définition de
roues, mais ses roues peuvent être changées, et donc les roues ont une existence en dehors de
la voiture. La voiture possède des roues, si la voiture va à la casse on peut en récupérer les
roues pour les mettre sur une autre voiture.

Différence association / aggrégation : Un homme est associé à sa femme (association) et il


possède un compte en banque (aggrégation).

Composition(Agrégation forte)

quand : A contient un objet de type B en attribut et crée éventuellement un emplacement


mémoire pour cet objet (par un new).

Ce qui est important pour la composition ce n’est pas tellement qu’il créé l’objet, mais c’est
surtout que si l’objet de type A disparaît, celui de B disparaît aussi. L’objet B n’a plus
d’existence sans celui de A.

Donc, au niveau du code, il y aura en effet souvent (presque toujours même) A qui créera
l’objet de type B (mais ça peut également arriver pour une aggrégation, il faut bien créer les
objets à un moment ou un autre, par exemple lorsqu’on créé une voiture on va lui créer des
roues, mais c’est une aggrégation faible car on peut les changer par la suite, et les roues
peuvent exister sans la voiture). Ce qui est important donc, c’est que l’objet de type A est le
seul à posséder ce référent vers l’objet de type B, de telle sorte que s’il meurt, l’objet de type
B qui le compose meurt aussi.

Exemple : soient les classes Arbre et Feuille. Quand on créé un arbre, on en créé les feuilles,
l’arbre est composé d’un tronc, de racines,… et de feuilles. Si l’arbre meurt, on ne sait pas en
récupérer les feuilles pour les mettre sur un autre arbre -> elles meurent aussi.

34
M.GBOLOVI Support C.O.O-P.O.O
Chapitre 5 : LES TABLEAUX, LES CLASSSES
TECHNIQUES, CLASSE METIER ET CLASSE
COLLECTIONS

I. LES TABLEAUX
Un tableau est un objet ayant un nombre d'éléments fixe et pouvant contenir des objets ou des
types primitifs. Dans certains langages comme Java, un tableau est lui-même un objet.
Un tableau peut contenir des primitifs tous du même type : {1,2,3} ou {'a','b','c'}.
Un tableau peut également contenir des objets de mêmes types.

1. Déclaration simple de tableau d’objet

Dans certains langages orienté objet comme le C++ les tableaux d’objet sont définis comme
les tableaux de types primitifs.

lesPièces[1..100] : tableau de PièceNonAgréée ou

lesPièces[100] : tableau de PièceNonAgréée ou

tableau F[10] :Forme

et pour accéder aux éléments du tableau :

F[1].surface() ;

2. Tableau comme Objet


Dans certains langages Orienté Objet comme Java le tableau est un objet :

Syntaxe de déclaration

Tableau de 5 entiers primitifs :


entier[] monTableau=new entier[5];
ou
entier monTableau[]=new entier[5];

La première notation est de loin la meilleure car de cette façon, nous visualisons bien que
monTableau est de type tableau d'entiers primitifs. Dans la seconde notation, les crochets sont
mis à la fin de la référence pour assurer une continuité avec les normes du C.

II. CLASSE METIER /CLASSE TECHNIQUE


Il existe deux grandes catégories de classes. Vous avez eu l’occasion de les découvrir
lors des séquences précédentes. Certaines classes comportent des informations : elles

35
M.GBOLOVI Support C.O.O-P.O.O
Représentent une personne, un objet, un lieu… Ce sont les classes « métiers ». D’autres
classes apportent des outils pour faciliter certaines manipulations : elles permettent de
manipuler les curseurs, les dates… Ceux sont les classes « techniques ».
Classe métier : classe qui permet de décrire un objet qui a une vie propre.
Classe technique : classe « boite à outils » qui permet de faciliter certaines manipulations.

Exemple :

Classe Date
Attributs prives :
annee : Entier
mois : Entier
jour : Entier
Methode a portee classe :
fonction aujourdhui() : Date // renvoie la date du jour
// Exemple d’appel : an Date.aujourdhui().année()
// la variable entière an reçoit l’année de la date du jour
Methodes publiques :
fonction annee() : Entier // renvoie l’année
fonction mois() : Entier // renvoie le mois
fonction jour() : Entier // renvoie le jour
fonction difference(uneDate : Date ) : Entier

fin classe

III. Les vecteurs (collections)


Lorsque l'on crée un tableau, il faut spécifier sa taille qui est fixe. Certains langages
fournissent des objets très utilisé comme le vecteur (classe java.util.Vector en Java ) ou
collection. L'utilisation d'un vecteur (collection) plutôt qu'un tableau est souvent avantageuse
lorsque la taille finale du tableau n'est pas connue à l'avance. Un vecteur est un tableau
dynamique. La première cellule d'un vecteur peut avoir l'index zéro.
Une collection définit un groupe d'objets, sur lequel des opérations de lecture, insertion,
suppression, déplacement et remplacement peuvent être effectuées.
Parmi les classes techniques, il existe un ensemble de classes spécialement dédiées à la
manipulation d’un ensemble d’objets. Ces classes, appelées Collections, permettent de
manipuler des ensembles d’objets avec les caractéristiques suivantes :
• les objets ne sont pas placés de façon contiguë dans la mémoire ;
• le programmeur ne s’occupe pas de la façon dont sont mémorisés les objets ;
• la taille de la collection est variable et s’adapte au nombre d’objets qu’elle contient ;
• l’ajout et la suppression d’objets ne nécessitent aucun décalage ;
• l’accès à un objet peut se faire séquentiellement ou par indice, voire par une clé prédéfinie
(suivant le type de collection) ;
• certaines collections offrent des possibilités supplémentaires, comme la recherche,
le tri…
Pourquoi « classe générique » ?
Une classe « générique » est une classe qui manipule un type non défini à l’avance (donc
« générique ») et qui sera précisé au moment de l’instanciation de la classe.
Les collections sont génériques car effectivement elles permettent de manipuler un

36
M.GBOLOVI Support C.O.O-P.O.O
ensemble d’objets d’un type précis, mais qui ne sera défini qu’au moment de la création
de la collection (
Exemple :
Classe Collection
// Il s’agit d’une classe générique.

Méthodes publiques
fonction cardinal() : Entier
// retourne le nombre d’éléments de la collection
fonction existe(unObjet : Objet) : Booléen
// teste si unObjet fait partie de la collection
fonction index(unObjet : Objet) : Entier
// retourne l’index de l’objet passé en paramètre dans la collection,
// le premier objet de la collection a pour index 1
fonction donnerObjet(unIndex : Entier) : Objet
// retourne l’objet qui se trouve à l’index passé en paramètre
procédure ajouterObjet(unObjet : Objet)
// ajoute unObjet à la collection
procédure remplacerObjet(unIndex : Entier, unObjet : Objet)
// remplace, dans la collection, l’objet figurant à l’index passé en paramètre
// par l’objet passé en paramètre
procédure retirerObjet(unObjet : Objet)
// supprime de la collection l’objet passé en paramètre
procédure vider( )
// vide le contenu de la collection

Fin Classe Collection

// Pour instancier une collection


uneCollection : Collection de MaClasse // la collection instanciée contiendra des objets de
la //classe MaClasse

37
M.GBOLOVI Support C.O.O-P.O.O
PARTIE 3 : UML

Chapitre 6 : UML

INTRODUCTION
UML (Unified Modeling Language ou « langage de modélisation unifié ») est un langage de
modélisation graphique. Il s’impose depuis plusieurs années comme un standard dans le
domaine de la conception orientée objet.
Vous avez eu en Programmation Orientée Objet (POO) des classes qui sont souvent liées
entre elles. UML permet de visualiser graphiquement les classes et les liens entre les classes :
cette visualisation est une aide considérable pour optimiser l’organisation des informations.
Cependant UML ne permet pas que de modéliser des classes. En réalité, de nombreux
diagrammes permettent d’avoir une représentation visuelle de toutes les étapes du processus
de développement.
L’UML est un langage de modélisation Orienté Objet depuis la spécification des besoins
jusqu’au déploiement du logiciel.
C’est un langage de modélisation dont le vocabulaire et les règles sont centrés sur la
représentation conceptuel et physique d’un système.
C’est un langage pour visualiser, spécifier et documenter.
I. GENERALITE
1) Les principes de l’approche objet

a) Abstraction
C’est le principe qui consiste à ignorer des aspects d’un sujet qui ne se rapporte pas au propos
courant, dans le but de se concentrer pleinement sur ceux qui s’y rapportent.

b) Encapsulation
Permet de décrire une abstraction sous forme d’une partie visible appelée l’interface et une
partie cachée appelée implémentation.

c) Héritage
C’est une technique qui permet de spécifier les attributs et les services communs une fois, elle
permet de spécialiser ou d’étendre ces attributs et services à des cas spécifiques.

d) Communication des messages (Méthode membre)


C’est la transmission des commandes ou des demandes qui se fait par l’appel d’une méthode
par un objet.

e) Polymorphisme
Il s’agit de la redéfinition des méthodes ou de la surcharge des méthodes.

2) Présentation de UML
Elle a été développée en 1994 par le groupe Grady Booch, Ivar Jacobson et Jim Rumbaugh.
Elle est héritée de plusieurs autres méthodes telles que :

38
M.GBOLOVI Support C.O.O-P.O.O
 OMT (Object Modeling Technique) de Rumbaugh
 OOSE (Object Oriented Software Engineering) de Jacobson
 Booch 93 de Booch

L’UML est un langage de modélisation Orienté Objet depuis la spécification des besoins
jusqu’au déploiement du logiciel.
C’est un langage de modélisation dont le vocabulaire et les règles sont centrés sur la
représentation conceptuel et physique d’un système.
C’est un langage pour visualiser, spécifier et documenter.
3) Les 13 diagrammes
Comme Merise, UML propose plusieurs modèles, sous formes de diagrammes. Nous allons
faire le tour de l’ensemble des diagrammes, en s’arrêtant plus particulièrement sur le
diagramme des cas d’utilisation et le diagramme de classes.
Pourquoi insister sur le diagramme de classes ? Parce que c’est celui qui va le plus vous servir
puisqu’il permet de modéliser les classes nécessaires d’une application. Il est en quelque sorte
l’équivalent du MCD (Modèle Conceptuel de Données) de Merise. Cependant, il est
important que vous ayez une vision globale des autres diagrammes, certains étant très connus.
Au niveau du référentiel aucune méthode spécifique n’est imposée mais il est tout de même
spécifié que pour les données, le modèle conceptuel de la méthode Merise reste
incontournable, et pour les classes, c’est le diagramme de classes d’UML qui est préconisé.
Vous devez aussi avoir une connaissance assez large pour être capable de lire un schéma
existant, quelle que soit la méthode.
Nous allons aborder les 13 diagrammes d’UML 2 notamment le diagramme des cas
d’utilisation, de classes, d’états, de séquence, d’activités, de déploiement, de composants, de
packages, d’objet, de communication, de structure composite, global d’interaction et de temps
(UML 1.3 en comptait 9).
II. DIAGRAMME DES CAS D’UTILISATION
1)Présentation
C’est la technique utilisé par UML pour déterminer les besoins de l’utilisateur. Les cas
d’utilisation (‘use cases’) servent à exprimer le comportement du système en termes d’actions
et de réactions, selon le point de vue de chaque utilisateur (« approche centrée utilisateur »).

Les cas d’utilisation délimitent le système, ses fonctions (ses cas), et ses relations avec son
environnement. Ils constituent un moyen de déterminer les besoins du système. Ils permettent
d’impliquer les utilisateurs dès les premiers stades du développement pour exprimer leurs
attentes et leurs besoins (analyse des besoins).

Ils constituent un fil conducteur pour le projet et la base pour les tests fonctionnels

2)Les éléments du diagramme


a) Système :
C’est le contexte du domaine à étudier en précisant les différents acteurs qui l’utilisent.

b) Acteur :
Un acteur est une personne ou un système qui interagit avec le système étudié, en échangeant
de l’information (en entrée et en sortie). On trouve les acteurs en observant les utilisateurs

39
M.GBOLOVI Support C.O.O-P.O.O
directs du système, les responsables de sa maintenance, ainsi que les autres systèmes qui
interagissent avec lui. Un acteur représente un rôle joué par un utilisateur qui interagit avec le
système. La même personne physique peut jouer le rôle de plusieurs acteurs. D’autre part,
plusieurs personnes peuvent jouer le même rôle, et donc agir comme un même acteur. On
distingue 2 types d’acteurs :

 Acteur principal : déclencheur du cas d’utilisation


 Acteur secondaire : participe au cas d’utilisation sans le déclencher

c) Cas d’utilisation :
Il représente un service rendu par le système. Les cas d’utilisations représentent le dialogue
entre l’acteur et le système de manière abstraite.

d) Association
Elle indique que l’acteur communique avec le cas.

e) Représentation graphique

f) Dépendance
C’est une relation de communication entre 2 cas d’utilisation. On distingue l’inclusion et
l’exclusion

Lorsqu’un cas appelle toujours un autre pour l’aider dans une tache qu’il ne peut pas
accomplir seul, on utilise la notation <<include>> ou <<inclut>>.

Lorsqu’un cas peut avoir besoin de l’aide d’un autre en fonction d’une condition, on utilise la
notation <<extend>> ou <<etend>>.

g) Généralisation
Elle indique une relation de généralisation entre 2 cas d’utilisation. Le cas d’utilisation enfant
est une spécialisation du cas parent.

h) Résumé des étapes à suivre


Pour établir le diagramme des cas d’utilisation on peut suivre les étapes suivantes :

40
M.GBOLOVI Support C.O.O-P.O.O
 Définir le contexte du problème
 Identifier les acteurs
 Identifier les cas d’utilisation
 Définir les associations
 Evaluer les dépendances
 Evaluer les généralisations

Exemple
Un joueur se connecte au serveur. Une fois connecté, il choisit un personnage après avoir
éventuellement consulté le catalogue des personnages. Il saisit son pseudo. Il peut alors entrer
dans l’arène et jouer (se déplacer, attaquer les adversaires avec des boules). Il peut aussi,
pendant le jeu, dialoguer avec les autres joueurs (chat). À tout moment (connecté ou non), le
joueur peut consulter l’aide du jeu.

Analyse du schéma
Il faut se positionner sur l’acteur (joueur) qui va pouvoir interagir avec le système. Que peut-il
faire ?
• Il peut se connecter.
• Ce n’est qu’une fois connecté qu’il peut choisir un personnage (d’où l’include qui marque la
dépendance obligatoire d’une action par rapport à une autre)
• Le choix du personnage peut se faire optionnellement après avoir consulté le catalogue (d’où
l’extend qui marque la dépendance optionnelle d’une action par rapport à une autre).

41
M.GBOLOVI Support C.O.O-P.O.O
• L’entrée dans l’arène ne peut se faire qu’après le choix du personnage (d’où l’include).
• Une fois dans l’arène, il peut dialoguer ou jouer (ces 2 actions sont indépendantes l’une de
l’autre, mais dépendent toutes les 2 de l’entrée dans l’arène).
• Quand il joue, il peut soit se déplacer, soit attaquer (ces 2 actions sont des « sous actions »
de l’action jouer).
• Enfin, indépendamment de tout, le joueur peut à tout moment consulter l’aide.
En complément du schéma, chaque cas d’utilisation peut ensuite être détaillé de façon
textuelle dans un tableau.

Exercice

Vous devez créer un site commercial. Sur le site, un utilisateur peut sélectionner des produits
éventuellement après avoir lu la fiche technique de chaque produit. Il peut ensuite visualiser
son panier. S’il décide de valider son panier, il doit donner ses coordonnées et il peut alors
soit choisir de payer en ligne, soit de payer à la réception.

Dessiner le diagramme de cas d’utilisation correspondant.

3)Description du cas d’utilisation


La description détaillée porte sur les éléments suivants :

 Précondition : condition de déclenchement du cas d’utilisation


 Post-condition : condition pour que le cas se termine correctement.
 Flot d’événement principal : chemin qui correspond au déroulement normal
 Flot d’événement exceptionnel : alternatives et cas d’erreurs
 Contrainte non fonctionnel (technique)
Exemple : retrait d’argent au guichet d’une banque
 Description initial
 L’agent saisit le n° du compte du client
 L’agent demande le retrait de x francs Cfa
 Le système édite bulletin de retrait
 Description détaillée
 Début : l’arrivée du client
 Précondition : le système en service
Le guichet suffisamment approvisionné
 Fin : lorsque le client reçoit la somme souhaitée
 Post-condition : solde supérieur au montant à retirer
 Flots principal :
o L’agent saisit le N° du compte du client
o Le système valide le compte auprès du système central
o Le système demande le type de l’opération
o L’agent sélectionne un retrait de x francs cfa
o Le système va interroger le système central pour s’assurer que le
compte est suffisamment approvisionné
o Le système effectue le débit du compte

42
M.GBOLOVI Support C.O.O-P.O.O
o Le système notifie à l’agent qu’il peut délivrer le montant
demandé
o Le système édite le bulletin de retrait
o L’agent s’assure que le montant est disponible au niveau du
guichet
 Flots exceptionnels
o Le N° de compte est erroné : affichage d’un message d’erreur
Au bout de 3 tentatives le cas se termine
o Le guichet n’est pas suffisamment approvisionné
Message d’erreur et le cas se termine
o Le compte est bloqué
 Les contraintes non fonctionnelles
o Performance : le système doit réagir dans un délai bref, en
temps réel
o Résistance à la charge : le système doit pouvoir gérer un nombre
important de retrait par jour.
o Résistance au panne :le système doit être dans un état cohérent
après la panne.

Voici un exemple détaillant le cas d’utilisation « se connecter »

43
M.GBOLOVI Support C.O.O-P.O.O
4)Scénario
Le scenario est une instance du cas d’utilisation c'est-à-dire le cas d’utilisation est une
abstraction de plusieurs chemins d’exécution.

Exemple de scenario :

o L’agent Koffi saisit le numéro 123456789


o Le système accepte le numéro
o L’agent sélectionne un retrait de 50000 fcfa
o L’agent edite le bulletin de retrait

III. DIAGRAMME DE CLASSE


1)Présentation
Le diagramme de classes permet de modéliser les données et les traitements de l’application.
Il exprime de manière générale la structure statique d'un système, en termes de
classes et de relations entre ces classes.
Question : « Quelles sont les informations et traitements nécessaires ? »
Un diagramme de classes, est donc :
• un schéma représentant les liens entre les classes ;
• l’ensemble des données et traitements nécessaires ;
• une organisation détaillée de contenu de l’application.
2)Les éléments du diagramme
a) Classe
Elle est la représentation d'un ensemble d'éléments partageant les mêmes attributs,
les mêmes opérations, les mêmes relations et les mêmes sémantiques.
En programmation orientée objet, une classe définit une abstraction, un type abstrait
qui permettra d'instancier des objets. Graphiquement, une classe décrite en UML
peut être plus ou moins précise :

La première classe (classe1) est dite à visibilité réduite, tandis que les deux autres
(classe2 et classe3) sont dites à visibilités détaillées.

b) Visibilité d'une caractéristique


Elle détermine si d'autres éléments peuvent l'utiliser.
Trois niveaux de visibilité sont possibles pour les attributs et les opérations :
 « + » : visibilité public. La caractéristique peut être utilisée par n'importe quelle
classe ayant une visibilité sur les instances de la classe complète.

44
M.GBOLOVI Support C.O.O-P.O.O
 « - » : visibilité private : La caractéristique ne peut être utilisée que par la
classe elle-même (methode).
 « # » : visibilité protected : La caractéristique ne peut être utilisée que par la
classe elle-même ou bien par les descendants directs de cette classe.

c) Opération
C’est l’implémentation d’un service qui peut être demandé à tous les objets d’une même
classe dans le but de déclencher un comportement.

d) Multiplicité
 Nombre d’instance qu’une classe peut avoir
 Complete les associations entre classe
 Elle est notée sous forme de chiffre ou d’intervalle

Remarque importante sur les multiplicités :


Attention, les multiplicités fonctionnent à l’envers par rapport aux cardinalités de Merise.
Lisons par exemple les multiplicités sur le lien entre JeuServeur et Joueur :
• un JeuServeur peut avoir plusieurs joueurs (le * est du coté de Joueur !) ;
• un Joueur ne peut être rattaché qu’à un JeuServeur (le 1 est du côté de JeuServeur !)
Évitez de tout mélanger entre les 2 méthodes...
Noms sur les liens
Remarquez aussi que parfois, sur les branches des associations, il y a des noms : cela
correspond aux noms des propriétés (simples ou collections) qui sont incluses dans la classe
qui se trouve à l’opposé, et qui contiennent une ou plusieurs occurrences de la classe qui se
trouve du même côté.

e) Les classes abstraites


Classe abstraite: classe ne pouvant pas être instanciée directement. Une telle classe
sert de spécification pour des objets instances de ses sous-classes.

f) Les interfaces
Interface: décrit un contrat d'une classe ou d'un composant sans en imposer
l'implémentation.

Une interface ne décrit aucune structure ni aucune implémentation. Elle ne peut donc
pas contenir d'attributs, ni de méthodes fournies sous la forme d'une implémentation.

45
M.GBOLOVI Support C.O.O-P.O.O
3)Les relations entre classes
La relation permet de décrire comment les objets d’une classe interagissent avec les objets
d’une autre classe.

Il faut préciser le nom de la relation et le rôle que joue chaque objet dans la relation.

a) L'association
Relation d'association: relation structurelle précisant que les objets d'un élément sont
reliés aux objets d'un autre élément.

b) La dépendance
Relation de dépendance: relation sémantique entre deux éléments selon laquelle un
changement apporté à l'un peut affecter la sémantique de l'autre.

Les relations de dépendances les plus fréquents sont :

 La relation d’utilisation : un élément source sollicite la présence d’un élément cible


pour son bon fonctionnement (élève et stylo).
 La relation de permission : un élément source à accès à l’élément destination quelque
soit la spécification de visibilité de ce dernier. (exemple des fonctions friend).

c) La généralisation
+ Relation de généralisation: relation entre un élément général et un élément dérivé
de celui-ci, mais plus spécifique (désigné par sous-élément ou élément fils).
Le plus souvent, la relation de généralisation est utilisée pour représenter une
relation d'héritage.

46
M.GBOLOVI Support C.O.O-P.O.O
d) L'implémentation
+ Relation d'implémentation: relation entre une classe et une interface spécifiant que
la classe implémente les opérations définies par l'interface.

e) L'agrégation
+ Relation d'agrégation: relation «tout-partie» dans laquelle une classe représente un
élément plus grand (le «tout») composé d'éléments plus petits (les «parties»).
La relation d'agrégation est souvent implémentée en utilisant des membres privés.

f) La composition
+ Relation de composition: relation d'agrégation mettant en avant une notion de
propriété forte et de coïncidence des cycles de vie. Les «parties» sont créées et
détruites en même temps que le «tout».

47
M.GBOLOVI Support C.O.O-P.O.O
g) Classe association :
Elle encapsule les informations concernant une association.

h) Association réflexive :
Elle s’applique à des objets d’une même classe.

4)Résumé des éléments du diagramme de classes


Le diagramme de classes respecte les principales règles de représentation suivantes :

48
M.GBOLOVI Support C.O.O-P.O.O
Exemple : Réservation d’une agence de voyage
On considère un système de réservation pour une agence de voyage :
 Des compagnies aériennes proposent différents vols.
 Un vol est ouvert à la réservation
 Un client peut réserver un ou plusieurs vols pour des passagers différents
 Une réservation concerne un seul vol et un seul passager
 Un vol à un aéroport de départ et un aéroport d’arrivé
 Un vol peut comporter des escales dans les aéroports
 Chaque escale a une heure d’arrivée et une heure de départ
 Chaque aéroport dessert une ou plusieurs villes

49
M.GBOLOVI Support C.O.O-P.O.O
IV. Diagramme d’états
1)Présentation

Les diagrammes d'états-transitions permettent de décrire les changements d'états d'un objet ou
d'un composant, en réponse aux interactions avec d'autres objets/composants ou avec des
acteurs.
Le diagramme d’états permet de modéliser les étapes de vie d’une instance indépendamment
des autres.
Question : « Quelle est la vie d’un objet ? »
Un diagramme d’états, c’est :
• un schéma qui ne concerne qu’un objet précis ;
• une schématisation des différents états possibles de cet objet ;
• une intégration de la notion de temps (étape de vie de l'objet).

2)Les éléments du diagramme


a) Etat
C’est une situation stable au cours de la vie d’un objet pendant laquelle cet objet satisfait à
certaines conditions, exécute une activité ou attend un événement. Un état se caractérise par
sa durée et sa stabilité.

Il peut être caractérisé par :

 Un attribut particulier

50
M.GBOLOVI Support C.O.O-P.O.O
 L’ensemble des valeurs des attributs
Exemple : voiture
1-démarrer ,2-arrêté, 3-en panne
Représentation d’un état

Démarrer
On distingue deux états spéciaux :

Etat initial (état par défaut à la création)

Etat final (dernier état dans le cycle de vie)

b) Evénement :
C’est la spécification d’une occurrence d’un stimulus qui peut déclencher une transaction.
UML modélise 4 types d’événement :

 Signal
C’est un stimulus asynchrone .Exemple : les exceptions

 Appel
C’est le déclenchement d’une opération ou événement synchrone

 Ecoulement de temps
C’est un événement temporel qui représente un écoulement de temps.

Représentation : After (duree)

 Evénement de modification
Représente le fait de satisfaire une condition.

Représentation : when(condition)

c) Transition
C’est une relation entre deux états qui indique qu’un objet se trouvant dans un état entre dans
le deuxième état lorsqu’un événement déterminé se produit. Une transition représente le
passage instantané d'un état vers un autre. Elle est déclenchée par un événement.

51
M.GBOLOVI Support C.O.O-P.O.O
Transition automatique

Se déclenche à la fin d’une activité sans attendre un événement

Condition de garde : la transition n’est effectuée que lorsque la condition est vérifiée

d) Action
Traitement automatique exécuté par l’objet pendant une durée nulle lors d’une transition.

e) Etat composé ou super-etat


Un super-état est un élément de structuration des diagrammes d'états-transitions. C’est un état
qui contient des sous états.

Exemple imprimante

Le symbole de modélisation "historique", mémorise le dernier sous-état actif d'un super-état,


pour y revenir directement ultérieurement.
3)Le diagramme
Un diagramme d’état transition est représenté par un graphe dont les nœuds sont les
différents états possible de l’objet et les arcs sont les transitions entre les états.

52
M.GBOLOVI Support C.O.O-P.O.O
4)Résumé des éléments du diagramme d’états
Le diagramme d'états respecte les principales règles de présentation suivantes :

Exemple :
Le diagramme d'états-transitions ci-dessous, montre les différents états par lesquels passe une
machine à laver les voitures. En phase de lustrage ou de lavage, le client peut appuyer sur le
bouton d'arrêt d'urgence. S'il appuie sur ce bouton, la machine se met en attente. Il a alors
deux minutes pour reprendre le lavage ou le lustrage (la machine continue en phase de lavage
ou de lustrage, suivant l'état dans lequel elle a été interrompue), sans quoi la machine s'arrête.
En phase de séchage, le client peut aussi interrompre la machine. Mais dans ce cas, la
machine s'arrêtera définitivement (avant de reprendre un autre cycle entier).

53
M.GBOLOVI Support C.O.O-P.O.O
Exemple
Une fois le joueur créé, le choix du personnage va permettre de valoriser les propriétés
concernées. Le joueur entre dans l'arène et peut ainsi accéder aux méthodes qui vont lui
permettre de se déplacer et/ou d'attaquer. Le joueur peut aussi être touché ce qui va diminuer
sa vie. Si la vie arrive à 0, le joueur meurt. L'objet est détruit.

54
M.GBOLOVI Support C.O.O-P.O.O
Analyse du schéma
L'objet est créé à partir de l'état initial. Sa vie passe d'abord par le choix du personnage (le
sens des flèches montre les possibilités de l'évolution de la vie d'un objet). Sans détailler tout
le reste, on remarque que parfois les flèches bouclent sur un même état transitoire.
Effectivement, le joueur peut attaquer plusieurs fois. Certaines transitions (flèches) peuvent
aussi être faites sous condition (vie=0). Un objet a forcément une fin de vie : c'est l'état final.

V. Diagramme de séquence
1)Présentation
Il montre des interactions entre objets selon un point de vue temporel. Ce type de diagramme
sert à modéliser les aspects dynamiques des systèmes temps réels et des scénarios complexes
mettant en œuvre peu d'objets.
Dans ce type de diagrammes, l'accent est mis sur la chronologie des envois de messages. La
représentation se concentre sur l'expression des interactions et non pas sur l'état ou le contexte
des objets.

Ce type de diagramme est usuellement utilisé pour illustrer les diagrammes de cas
d'utilisation. Le diagramme de séquence permet de modéliser l'interaction des objets entre
eux. Il représente le scénario d'utilisation des objets.

Question : Quels messages circulent entre les objets ?


Un diagramme de séquence, c'est :
• la représentation temporelle des messages entre objets ;
• le cycle de vie d'un ensemble d'objets liés dans un cas d'utilisation ;
• un lien dynamique entre cas d'utilisation et classes.

55
M.GBOLOVI Support C.O.O-P.O.O
2)Les éléments du diagramme
a) Interactions:
Elles modélisent un comportement dynamique entre objets. Elles se traduisent par l'envoi de
messages entre objets. Un diagramme de séquence représente une interaction entre objets, en
insistant sur la chronologie des envois de messages.
Dans un diagramme de séquence, les objets sont associés à une ligne de vie. La dimension
verticale de celle-ci représente l'écoulement du temps (du haut vers le bas). Notons que la
disposition des objets sur l'axe horizontal n'est pas importante dans ce type de diagrammes.

b) Un objet et sa ligne de vie


Message: représentation d'une communication au cours de laquelle des informations
sont échangées.
Les messages sont représentés par des flèches et leur ordre est donné par leurs
positions sur la ligne de vie.
Ils représentent toute forme de communication entre objets : appels de procédures,
signaux, interruptions matérielles...

c) Agencement des messages


Période d'activation: correspond au temps pendant lequel un objet effectue une
action, soit directement, soit par l'intermédiaire d'un autre objet.

56
M.GBOLOVI Support C.O.O-P.O.O
d) Activations d'un objet de manière simple et par l'intermédiaire d'un
autre objet
Si l'on considère le second schéma de la Figure ci dessus, O1 active O2. La période
d'activation de O1 recouvre celle de O2. Dans le cas d'un appel de procédure, O1 est
bloqué jusqu'à ce que O2 lui redonne la main.
Notons que la période d'activation d'un objet n'a aucun rapport avec sa création ou
sa destruction. Un objet peut être actif plusieurs fois au cours de son existence.
Il existe deux catégories d'envoi de messages : Les flots de contrôle à plat et les flots
de contrôle emboités.

Flots de contrôle à plat: simple progression vers la prochaine étape d'une


séquence.

Un flot de contrôle à plat

Flots de contrôle emboité: la séquence emboitée doit se terminer pour que la


séquence englobante reprenne le contrôle. Ce type de flot est utilisé pour
représenter des appels de procédures avec un retour de valeur optionnel.

Un flot de contrôle emboité

57
M.GBOLOVI Support C.O.O-P.O.O
Les diagrammes suivants présentent quelques constructions communes : récursivité,
réflexion, création et destruction,...
La récursivité

Représentation de la récursivité

La réflexion

Représentation de la réflexion

Création et destruction d'objets

e) Rôle du diagramme séquence


Attribuer de bonnes responsabilités (opérations) aux bonnes classes

3)Résumé des éléments du diagramme d’états


Le diagramme de séquence respecte ces principales règles de présentation :

58
M.GBOLOVI Support C.O.O-P.O.O
Exemple : scénario pour un appel téléphonique, événements concernant l'objet Ligne
téléphonique.
1. l'appelant soulève le combiné
2. la tonalité est déclenchée
3. l'appelant tape un chiffre (5)
4. la tonalité s'arrête
5. l'appelant tape un chiffre (5)
6. l'appelant tape un chiffre (1)
7. l'appelant tape un chiffre (2)
8. le téléphone appelé commence à sonner
9. la tonalité de sonnerie commence dans appelant
10. l'appelé décroche
11. le téléphone de l'appelé cesse de sonner
12. la tonalité de sonnerie cesse dans appelant
13. les téléphones sont connectés

59
M.GBOLOVI Support C.O.O-P.O.O
Exemple
Quand l'utilisateur se connecte, la classe Joueur est instanciée puis l'instance est incluse dans
le jeu côté serveur. Si l'utilisateur utilise les flèches, l'objet joueur envoie un message au
serveur pour se déplacer. Le serveur retourne l'affichage de la nouvelle position.
Si l'utilisateur utilise la touche espace, l'objet joueur envoie un message au serveur pour
attaquer. Le serveur retourne l'affichage de la boule qui est lancée. Le serveur contrôle la vie
des joueurs et fait mourir ceux qui sont à 0.

Analyse du schéma
Ce schéma est incomplet mais donne déjà une vision de ce type de diagramme. Il représente
bien, dans une ligne de temps, les interactions entre l'utilisateur et les interfaces
(se connecter, utiliser les flèches, l'espace...). Les envois de messages entre objets sont aussi
modélisés : se déplacer, attaquer...

4)DIAGRAMME DE SEQUENCE SYSTEME


Un diagramme séquence est associé à un scenario.
Le diagramme de séquence système s’intéresse aux interactions entre les acteurs et le système
Les messages échanges se font avec l’interface publique du système

60
M.GBOLOVI Support C.O.O-P.O.O
Exemple de guichet

VI. DIAGRAMME DES COMPOSANTS


Il présente l'organisation des ressources au niveau physique.
C'est une représentation des unités (bases de données, fichiers, librairies...) dont l'assemblage
compose l'application.
1)Les éléments du diagramme

a) Composant
C’est l’élément physique qui représente une partie implémentée d'un système. Il peut
être du code, un script, un fichier de commandes, etc. Ils présentent un ensemble
d'interfaces.

b) Interfaces d'un composant:


C’est élément définissant le comportement offert à d'autres composants.

61
M.GBOLOVI Support C.O.O-P.O.O
c) Diagramme de composants:
Elle permet de décrire les composants et leurs dépendances dans leur
environnement d'implémentation.
Les composants peuvent être organisés en sous-systèmes de packages permettant
de masquer la complexité, par l'encapsulation des détails d'implémentation.

d) Nœud: Ressource matérielle du système étudié.


Les instances des composants résident dans des instances de nœuds :

Différents stéréotypes de composants :

< <document> > : un document quelconque ;


< <executable> > : un programme qui peut s'exécuter sur un nœud ;
< <fichier> > : un document contenant du code source ou des données ;
< <bibliothèque> > : une bibliothèque statique ou dynamique ;
< <table> > : une table d'une base de données relationnelles.
La majeure partie des relations existantes entre composants est constituée par des
contraintes de compilations et d'édition de liens.

e) Relation de dépendance :
Un composant nécessite la présence d’un autre composant pour son bon
fonctionnement.

Exemple

62
M.GBOLOVI Support C.O.O-P.O.O
Le diagramme des composants permet de décrire l’architecture physique et statique
d’un système. Il modifie l’interaction entre l’architecture logique du système et
l’environnement de développement.

VII. DIAGRAMME DE DEPLOIEMENT


Diagrammes de déploiement: permet de montrer la disposition physique des
matériels qui composent le système, ainsi que la répartition des composants sur ces
matériels représentés par des nœuds.
Ce type de diagramme est utilisé principalement pour la modélisation de trois types
de systèmes : les systèmes embarqués, les systèmes client/serveur et les systèmes
totalement répartis. Deux notations sont possibles pour montrer qu'un composant
réside sur un nœud :

63
M.GBOLOVI Support C.O.O-P.O.O
Représentation d'un composant à l'intérieur d'un nœud

La migration et la copie d'un composant d'un nœud vers un autre sont effectuées
respectivement en utilisant les stéréotypes < <devient> > et < <copie> >.
Un diagramme de déploiement permet également de représenter les relations entre
différents nœuds.

VIII. Les autres diagrammes


Les diagrammes ci-dessus sont les plus répandus. Ces diagrammes vous ont déjà donné une
idée de la philosophie d'UML. Il existe d'autres diagrammes. Nous allons juste les citer en
donnant leur rôle, pour votre culture générale.

1) Diagramme d'objets
Proche du diagramme de classes, il détaille les instances possibles et les liens entre
ces instances. Il permet de représenter les relations existant entre les différentes
instances des classes à un instant donné de la vie du système.
Dans les diagrammes d'objets, les instances peuvent être anonymes ou nommées.

1) Diagramme d'activité
Il présente les règles d'enchaînement des activités.
Il représente les activités de l'application ainsi que leur ordre logique et conditionnel.
Il est surtout utilisé lorsque toutes les transitions sont automatiques. Cependant on peut
utiliser le diagramme d’état et le diagramme d’activité à la fois.
Les diagrammes d’activité permettent de décrire des enchaînements de fonctionnalités. Ils
complètent donc bien les cas d’utilisation au niveau de l’analyse des besoins.

64
M.GBOLOVI Support C.O.O-P.O.O
Il décrit les différentes activités que l’objet exécute durant son cycle de vie.
Il sert aussi pour décrire une méthode ou algorithme d’un état.
Il est l’équivalent de la MCT de Merise.
Exemples

2) Diagramme de communication (collaboration)


Il présente la coopération entre objets.
C'est une autre représentation du diagramme de séquence. Il met en évidence des
interactions entre des objets qui peuvent être des instances de classes ou des
acteurs. Ils permettent de représenter le contexte d'une interaction, car on peut y
préciser les états des objets qui interagissent.
Il précise l’organisation structurelle de l’objet :
 Qui coopère avec qui
 Le rôle de chaque objet dans l’interaction.
Graphiquement : c’est un graphe dont les nœuds sont les objets et les arcs sont les
liens.
Il est donc caractérisé par :
 Les objets et les liens : partie statique
 Les messages : la partie dynamique

Exemple :contrôle de trafic aerien

65
M.GBOLOVI Support C.O.O-P.O.O
3) Diagramme de packages
Il présente les différents packages de l'application et les liens entre les packages.
On peut avoir une représentation du diagramme de classes et en même temps des packages
(regroupement de classes) et des liens entre eux.

4) Diagramme de structure composite


Il représente la description de la structure interne d'un objet pendant son exécution avec les
ports et connecteurs qui sont utilisés pour interagir avec d'autres instances ou avec l'extérieur.

5) Diagramme global d'interaction


Il associe les notations des diagrammes de séquence et d'activité.
Il permet, en phase d'analyse ou de conception, de décrire une méthode complexe.

6) Diagramme de temps
Pour les besoins en temps réel. Il modélise l'interaction entre plusieurs objets.

66
M.GBOLOVI Support C.O.O-P.O.O
PARTIE 4 : LA PRATIQUE EN LANGAGE JAVA(TP)

Chapitre 7 : Présentation du langage


1)Origines du langage
Java a été développée par SunSoft (branche de Sun MicroSystems) pour réaliser le
développement de systèmes embarqués.

La société Oracle a acquis en 2009 l'entreprise Sun Microsystems. On peut désormais voir
apparaître le logo Oracle dans les documentations de l'api Java.

Le langage est actuellement utilisé dans de nombreux domaines de l’informatique : Réseaux


/Internet (qui l’a rendu célèbre), applications clients/serveurs, systèmes embarqués (Voitures,
TV, Téléphones portables,… machines à laver),…

Java est un langage qui s’inspire de la syntaxe de C++ et de la gestion dynamique de la


mémoire de SmallTalk, deux langages orientés objets.

2)Le langage Java est simple, familier et orienté objet


Java est un langage simple car il n'utilise qu'un nombre restreint de nouveaux concepts. Sa
syntaxe est très proche du langage C, ce qui le rend familier aux programmeurs C et C++.
Java épure le C++ de toutes les faiblesses qui occupent une partie non négligeable du temps
de développement.

Java est un langage orienté objet : un programme Java est centré complètement sur les objets
et fournit un ensemble prédéfini de classes facilitant la manipulation des entrées-sorties, la
programmation réseau, système, graphique. Excepté les types de données fondamentaux, tout
est objet ! Seule l'héritage simple existe en Java.

3)Le langage Java est distribué


Conçu pour développer des applications en réseaux, les manipulations des objets distants ou
locaux se font de la même manière. La classe Socket permet la programmation d'applications
Client/Serveur de manière aisée.

4)Le langage Java est robuste et sûr


Le langage Java est fortement typé ; il élimine bien des erreurs d'incohérence de type à la
compilation. La suppression de la manipulation des pointeurs permet également de réduire de
manière importante les erreurs. Un glaneur de mémoire rendu libre permet de décharger le
programmeur d'une gestion fastidieuse de la mémoire.

Destiné pour des applications réseaux, la sécurité dans Java est un aspect primordial.

5)Le langage Java est portable et indépendant des


plates-formes :
Pour être portable, un programme Java n'est pas compilé en code machine ; il est transformé
en code intermédiaire interprété.

67
M.GBOLOVI Support C.O.O-P.O.O
Le code intermédiaire produit est indépendant des plates-formes : il pourra être exécuté sur
tous types de machines et systèmes pour peu qu'ils possèdent l'interpréteur de code Java
notamment la JVM (Java Virtual Machine). Même la programmation graphique, réseau et
système est totalement indépendant des machines et systèmes.

6)Le langage Java est dynamique et multithread


Le langage Java est dynamique et s'adapte à l'évolution du système sur lequel il s'exécute.

De nos jours, les applications possèdent un haut degré de parallélisme : il faut pouvoir écouter
une musique, tout en voyant une animation graphique etc. Java permet le mutlithreading de
manière simple.

7)La plate-forme de développement JAVA


Le JDK (Java Development Kit) est l’outil de base pour tout développement Java. Ce kit
contient tout le nécessaire pour développer des applications ou des applets Java : Le
compilateur (en ligne de commandes), une machine virtuelle, un ensemble complet de classes
de bases regroupées en packages.

Différents outils du commerce fournissent des interfaces graphiques permettant d’encapsuler


le JDK. Une partie des développements peut alors être réalisée de manière visuelle.

8) Java et la programmation événementielle


Actuellement, on peut distinguer deux grandes catégories de programmes, en se fondant sur
leur interface avec l’utilisateur:

 les programmes à interface console,


 les programmes à interface graphique.

a) Les programmes à interface console (ou en ligne de commande)


Historiquement, ce sont les plus anciens. Dans de tels programmes, on fournit des
informations à l’écran sous forme de lignes de texte s’affichant séquentiellement, c’est-à-dire
les unes à la suite des autres. Pour fournir des informations au programme, l’utilisateur frappe
des caractères au clavier (généralement un "écho" apparaît à l’écran).

Avec une interface console, c’est le programme qui décide de l’enchaînement des opérations :
l’utilisateur est sollicité au moment voulu pour fournir les informations demandées.

b) Les programmes à interface graphique (G.U.I.)


Dans ces programmes, la communication avec l’utilisateur se fait par l’intermédiaire de
composants tels que les menus déroulants, les menus surgissant, les barres d’outils ou les
boîtes de dialogue, ces dernières pouvant renfermer des composants aussi variés que les cases
à cocher, les boutons radio, les boîtes de saisie, les listes déroulantes...

L’utilisateur a l’impression de piloter le programme, qui semble répondre à n’importe laquelle


de ses demandes. D’ailleurs, on parle souvent dans ce cas de programmation événementielle,
expression qui traduit bien le fait que le programme réagit à des évènements provoqués par
l’utilisateur.

68
M.GBOLOVI Support C.O.O-P.O.O
Ce genre d’interface est désigné par le thème G.U.I. (Graphical User Interface).
Manifestement, il met en avant le fait que, pour permettre ce dialogue, on ne peut plus se
contenter d’échanger du texte et qu’il faut effectivement être capable de dessiner, donc
d’employer une interface graphique.

c) La gestion des interfaces graphiques est intégrée dans Java


Dans la plupart des langages, on dispose d’instructions ou de procédures standard permettant
de réaliser les entrées-sorties en mode console.

En revanche, les interfaces graphiques doivent être programmées en recourant à des


instructions ou à des bibliothèques spécifiques à chaque environnement.

L’un des grands mérites de Java est d’intégrer des outils (en fait des classes standard) de
gestion des interfaces graphiques. Non seulement on pourra utiliser le même code source pour
différents environnements mais, de plus, un programme déjà compilé (byte codes) pourra
s’exécuter sans modification sur différentes machines.

d) Applications et applets
À l’origine, Java a été conçu pour réaliser des applets s’exécutant dans des pages Web. En
fait, Java permet d’écrire des programmes indépendants du Web.

Les fonctionnalités graphiques à employer sont quasiment les mêmes pour les applets et les
applications.

Une applet est faite pour que son code (compilé) soit téléchargé dans une page Web.
Cependant, les environnements de développement disposent des outils pour visualiser
d’applets permettant d’exécuter une applet en dehors du Web.

9)Le programme « Hello World »


Avant d’aller plus en avant dans ce cours, voici l’exemple le plus simple de programmation Java :

public class Hello {


public static void main(String argv[])
{
System.out.println("Hello World") ;
}
}

Les étapes nécessaires pour l’exécuter dans une fenêtre DOS sans outils de développement
visuel (uniquement avec le JDK) sont:

C:> javac Hello.java <= Compilation : création de Hello.class


C:> java Hello <= Lancement du programme à partir de la machine virtuelle
Hello World
C:>

69
M.GBOLOVI Support C.O.O-P.O.O
CHAPITRE 8 : LA PROGRAMMATION
OBJET
JAVA est presque un pur langage de programmation Orienté Objet(POO), Tout est donc
objet sauf les types de base. Ce qui signifie que le niveau le plus externe de la structure des
données est l’objet. Dans Java, il n’y a pas de constantes, variables ou fonctions autonomes ;
l’accès se fait toujours par des classes et des objets.

1)Les classes
Tout d’abord, il faut faire la distinction entre les classes et les objets. Une classe est la
définition d’un type, alors que l’objet est une déclaration de variable.
Le processus de création d’un objet à partir d’une classe est appelé instanciation d’un objet ou
création d’une occurrence d’une classe.

a. Définition
La classe regroupe la définition des membres de classe, c’est-à-dire :

- des méthodes, les opérations que l’on peut effectuer ;


- des champs ou attribut, les variables que l’on peut traiter ;
- des constructeurs, qui sont des méthodes permettant de créer des objets ;

b. Déclaration et instanciation des classes


Une classe Java peut être très simple. Voici la définition d’une classe vide :
class MaClasse {

Evidemment, cette classe n’est pas encore utile, mais elle est correcte dans Java. Mais
commençons par étudier la syntaxe de l’instanciation d’une classe. Pour créer une occurrence
de cette classe, il faut créer une référence :
MaClasse monObjet;

Mais cette instruction n’affecte ni mémoire ni autres ressources à l’objet. Elle crée une
référence appelée monObjet, mais n’instancie pas l’objet. C’est le rôle de l’opérateur new.
monObjet = new MaClasse();

Après l’exécution de cette ligne de code, il est possible d’accéder aux variables et aux
méthodes membres de la classe avec l’opérateur “.”.

Une fois l’objet créé, vous n’avez pas à vous préoccuper de sa destruction. Dans Java, les
objets sont automatiquement éliminés par le Garbage collector. Dès que la référence à un
objet (c’est-à-dire la variable) sort de la portée, la machine virtuelle libère automatiquement
toutes les ressources affectées par l’opérateur new.

70
M.GBOLOVI Support C.O.O-P.O.O
c. Les attributs (les champs)
Les attributs (ou champs) sont les données contenues dans les objets d'une certaine classe.

 Déclaration et initialisation
Voici un exemple plus complexe de classe, décrivant des objets représentants des dates et
contenant trois attributs :

class Date {
int jour ; // Par défaut, un attribut est initialisé à zéro
int mois = 1 ;
int an = 2000 ;
final int MAX_MOIS = 12 ; // Ceci est une constante : elle doit être initialisée
Date(int _an) { an = _an; } // Ceci est un constructeur, méthode spéciale utilisée lors
// de la création d'objets. Nous verrons cette notion en
// détail plus tard.
void print() { System.out.println( jour + "/" + mois + "/" + an ); }
}

Date d = new Date(1998) ;// Création d'un nouvel objet de la classe Date, d est une référence
// sur cet objet. Nous reviendrons sur ces notions plus tard
// Invocation de la méthode print sur l'objet référencé par d
d.print() ; // => affiche : 0/1/1998
 Le mot clé : final
Le mot clé final, utilisé pour un attribut, permet de spécifier que cet attribut est une constante.
Une variable qualifiée de final signifie que la valeur de la variable ne peut plus être modifiée
une fois que celle-ci est initialisée.

public class Constante2 {

public final int constante;

public Constante2() {

this.constante = 10;

 Les attributs statiques


Le mot clé static, utilisé pour un attribut, permet d'indiquer que cet attribut est commun à tous
les objets de la classe concernée : il s'agit d'un attribut de la classe elle-même, et si on modifie
cet attribut pour un objet donné, il sera modifié pour tous les objets de la classe (puisque c'est
le même).

71
M.GBOLOVI Support C.O.O-P.O.O
class Voiture {
static int count = 0 ;
int id ;
Voiture() { id = count++ ; }
}

Voiture v1 = new Voiture() ;
Voiture v2 = new Voiture() ;
Un attribut de classe peut être accédé par n'importe quel nom de référence associé à un objet
de cette classe, ou par le nom de la classe elle-même.

d. Les méthodes
Une méthode peut être considérée comme une fonction qui est membre d'une certaine classe :
Les méthodes Java sont syntaxiquement très proches des fonctions C : elles ont un nom,
peuvent accepter des paramètres et retourner une valeur. Cependant lors de la définition des
méthodes, l’implémentation de la méthode figure juste sous la déclaration.

 Le passage des paramètres


Il est très important de comprendre la différence entre le comportement des types de base et
celui des objets lors du passage de paramètres.

 Les types de bases : passage de paramètres par valeur


Les types de base sont toujours passés par valeur : lors de l'appel d'une méthode, les variables
utilisées lors de l'appel ne sont donc pas modifiées par celui-ci.

class Point {
private int x, y ;
public void setXY(float newx, float newy) { x = newx++ ; y = newy++ ; }
}

int a = 0 , b = 0 ;
Point p = new Point() ;
p.setXY(a,b) ;
// a et b valent toujours zéro…

 Les objets : passage de paramètres par adresse


Lorsque l'on passe en paramètre un objet, c'est la référence sur cet objet qui est dupliqué. Il
n'y a donc pas duplication de l'objet lui-même. Si la méthode modifie l'objet, il sera donc
toujours modifié après l'appel à cette méthode.

72
M.GBOLOVI Support C.O.O-P.O.O
class PointValue {
public int x,y ;
}
class point {
private int x, y ;
public void setXY(PointValue nv) { x = nv.x++ ; y = nv.y++ ; }
}
… pv Objet référencé par pv

PointValue pv = new PointValue() ;


Point p = new Point() ; x: y:
pv.x = 0 ;
pv.y = 0 ;
p.setXY(pv) ; new
// pv.x et pv.y valent maintenant un…

 La surcharge des méthodes


La surcharge permet de définir des méthodes portant le même nom, mais acceptant des
paramètres de type différents et/ou en nombre différent. En fonction du type et du nombre des
paramètres passés lors de l'appel, c'est une version ou une autre de la méthode qui sera
effectivement appelée.

Attention : Le type de retour d'une méthode ne permet pas de différencier deux méthodes
portant le même nom (si c'est la seule différence).

class Test {
void print(int i) { … }
void print(float f) { … }
void print(int i, int j) { … }
}

Test t = new Test() ;
int i ;
t.print( i ) ; // => La première méthode est appelée

A l'appel, la machine virtuelle Java détermine quelle est la méthode dont la liste de paramètres
est la plus proche des paramètres effectivement envoyés. Dans le cas d'un appel de méthode
avec des types ne correspondants pas exactement, des conversions implicites peuvent être
effectuées.

short s ;
t.print( s ) ; // => La première méthode est appelée avec une conversion de s en int
 Les méthodes statiques
Il est possible de définir une méthode de type statique avec static. De même que pour les
attributs, cela signifie que les actions de cette méthode concernent la classe entière. Pour cette
raison, une méthode statique, ne peut accéder qu’aux attributs statiques de la classe.

On peut invoquer une méthode statique soit sur la classe elle-même, soit sur un objet de cette
classe. Dans tous les cas elle s'appliquera sur la classe entière.

L'utilisation d'une méthode statique ne nécessite pas la construction d'un objet appartenant à la
classe correspondante.

73
M.GBOLOVI Support C.O.O-P.O.O
class MathTool {
final static double PI = 3.14 ;

static double getPI() { return PI ; }


static double diametre( double rayon ) { return 2*PI*rayon ; }
static double power(double x) { return x * x ; }
}

class Test {
void methode1() {
double i = MathTool.power(6) ; /* invocation d'une méthode static sur une classe */
}
void methode2() {
MarhTool tool = new MathTool() ;
double i = tool.power(6) ; /* idem mais sur un objet. La première méthode est
plus logique */
}

Enfin, la première utilisation du mot clé static concerne la méthode main, dont une version
peut être définie pour chaque classe et qui sera la première méthode appelée, si et seulement si
on lance la Machine Virtuelle Java directement avec cette classe.

class Voiture {
// Méthode utilisée si cette classe est exécutée directement
public static void main(String args[]) {
Voiture v1 = Voiture.getVoiture(435)
v1.print() ;
}
// Gestion des objets de la classe
static ListeDeVoiture liste ;

static Voiture getVoiture( int numero ) {


… retourne l'objet voiture correspondant, à partir de la liste
}
static Voiture newVoiture(int numero) {
Voiture v = new Voiture(numero) ;
… insertion de v dans la liste
}
// Description du comportement de chaque objet Voiture
Voiture(int numero) { … }
void print() { … }

}

e. Les constructeurs
Un constructeur est une méthode particulière qui permet d'initialiser les objets de la classe
concernée. Chaque fois qu'un objet est construit avec l'opérateur new, un constructeur est
automatiquement appelé.

Un constructeur a le même nom que la classe, ne retourne jamais de valeur et peut prendre des
paramètres.

Lorsqu'une classe ne comporte pas de constructeur, le compilateur génère un constructeur par


défaut qui ne prend aucun paramètre, et qui initialise tous les attributs à zéro.

Il est possible de définir plusieurs constructeurs pour une même classe.

74
M.GBOLOVI Support C.O.O-P.O.O
class Date {
int _jour =1 ;
int _mois =1 ;
int _an =1990 ;
Date( ) { _an = 2000 ; }
Date( int an ) { _an = an ; }
Date( int jour, int mois, int an ) { _jour = jour ; _mois = mois ; _an = an ; }
}
La classe précédente contient trois constructeurs.

Le finaliseur

Comme nous l’avons déjà signalé, Java n’a pas de mécanisme destructeur, puisque ce langage
prend soin de libérer toutes les ressources pour vous. Cependant, certaines situations
nécessitent un nettoyage spécial que le Garbage collector ne peut pas effectuer quand la classe
disparaît. Par exemple, certains fichiers ont été ouverts pendant la durée de vie de l’objet et
vous voulez vérifier qu’ils sont correctement fermés quand l’objet est détruit. Un finaliseur est
appelé par le Garbage collector immédiatement avant la destruction de l’objet. Ainsi, si un
nettoyage spécial quelconque doit avoir lieu, le finaliseur peut le faire pour vous. Cependant,
le Garbage collector s’exécute dans la machine virtuelle sous forme de thread de faible
priorité, ce qui ne permet pas de savoir à quel moment il détruira réellement votre objet. Pour
créer un finaliseur, il faut redéfinir la méthode finalize() héritée de la classe Object.

2)La référence sur l'objet courant : this


Le mot-clé this représente une référence sur l'objet courant (celui qui est en train d'exécuter la
méthode dans laquelle se trouvent les instructions concernées).

this peut être utile :

 Lorsqu'une variable locale (ou un paramètre) "cache", en portant le même nom, un


attribut de la classe.
 Pour déclencher un constructeur depuis un autre constructeur.
class Date {
int jour =1 ;int mois =1 ;int an =1990 ;
Date( ) { an = 2000 ; } /* peut aussi s'écrire : this.an = 2000 */
Date( int an ) {
this.an = an ; } /* Le paramètre an cache l'attribut an */
Date( int jour, int mois, int an ) {
this.jour = jour ;
this.mois = mois ;
this(an) ; /* appel du deuxième constructeur */
}
}

3)Droit d’acces (Encapsulation)


L’encapsulation consiste à masquer l’accès à certains attributs et méthodes d’une classe.

Elle est réalisée à l’aide des mots clés :

75
M.GBOLOVI Support C.O.O-P.O.O
 private : les membres privés ne sont accessibles que par les fonctions membres de la
classe.
 protected : les membres protégés sont comme les membres privés. Mais ils sont aussi
accessibles par les fonctions membres des classes dérivées (voir l’héritage).
 public : les membres publics sont accessibles par tous. La partie publique est appelée
interface.
class Document{
private String titre ;
protected int nbrePage ;
public Document(String t,int np){
titre= t ;
nbrePage=np ;
}
}

4)Les accesseurs et les mutateurs


 La protection des données membres
L'un des aspects les plus essentiels du concept « orienté objet » est l'encapsulation, qui
consiste à définir des étiquettes pour les données membres et les fonctions membres afin de
préciser si celles-ci sont accessibles à partir d'autres classes ou non...
De cette manière, des données membres portant l'étiquette private ne peuvent pas être
manipulées directement par les fonctions membres des autres classes. Ainsi, pour pouvoir
manipuler ces données membres, on doit prévoir à cet effet des fonctions membres spéciales
portant l'étiquette public.
 Les fonctions membres permettant d'accéder aux données membres sont appelées
accesseurs, parfois getter (appellation d'origine anglophone)
 Les fonctions membres permettant de modifier les données membres sont appelées
mutateurs, parfois setter (appellation d'origine anglophone).
 La notion d'accesseur
Un accesseur est une méthode permettant de récupérer le contenu d’un attribut. Un accesseur,
pour accomplir sa fonction :
 doit avoir comme type de retour le type de l’attribut à renvoyer,
 ne doit pas nécessairement posséder d'arguments.
Une convention de nommage veut que l'on fasse commencer de façon préférentielle le nom de
l'accesseur par le préfixe get.
Exemple
class Document{
private String titre ;
protected int nbrePage ;
String getTitre(){
return titre ;
}
int getNbrePage(){ return nbrePage ;}
}
 La notion de mutateur
Un mutateur est une méthode permettant de modifier le contenu d’un attribut. Un mutateur,
pour accomplir sa fonction :

 doit avoir comme paramètre la valeur à assigner à la donnée membre. Le paramètre


doit donc être du type de l’attribut,

76
M.GBOLOVI Support C.O.O-P.O.O
 ne doit pas nécessairement renvoyer de valeur (il possède dans sa plus simple
expression le type void).
Une convention de nommage veut que l'on fasse commencer de façon préférentielle le nom du
mutateur par le préfix set.

Exemple complet

class Document{
private String titre ;
protected int nbrePage ;
public Document(String t,int np){
titre= t ;
nbrePage=np ;
}
public void affiche(){
System.out.println(“le titre est “+titre+“ le nombre de page est “+nbrePage) ;
}
String getTitre(){ return titre ;}
int getNbrePage(){ return nbrePage ;}
void setTitre(String t){ titre=t;}
void setNbrePage (int nb){ nbrePage=nb;}
}

L'intérêt principal d'un tel mécanisme est le contrôle de la validité des données membres qu'il
procure. En effet, il est possible (et même conseillé) de tester la valeur que l'on assigne à une
donnée membre, c'est-à-dire que l'on effectue un test de validité de la valeur de l'argument
avant de l'affecter à l’attribut.

5)La référence vide : null


Le mot clé null permet de représenter la référence qui ne référence rien. On peut assigner
cette valeur à n'importe quelle variable ou attribut contenant une référence.

class Test {
Voiture v1 ; /* Initialisée à null par défaut */
void methode() {

if ( v1 == null ) v1 = new Voiture("Volvo") ;

}
}

Attention : Si une méthode est invoquée sur une référence égale à null, cela déclenche une
erreur du type NullPointerException.

6)Les tableaux
En programmation, on parle de tableau pour désigner un ensemble d’éléments de même type
désignés par un nom unique, chaque élément étant repéré par un indice précisant sa position
au sein de l’ensemble.

77
M.GBOLOVI Support C.O.O-P.O.O
a) Création et utilisation d’un tableau
Un tableau dans Java est toujours un objet, même si les données de ce tableau appartiennent à
un type de base. La taille d'un tableau est fixée définitivement à sa création.

Un tableau étant un objet, il doit être alloué avec l'opérateur new, il est détruit
automatiquement par le Garbage Collector lorsqu'il n'est plus référencé et il est
systématiquement passé par référence lors de l'appel d'une méthode.

// tableau d'entiers
int tab [] = new int[10] ;

// Tableau de 5 références initialisées à null


Voiture tv[] = new Voiture[5] ;
Il existe deux syntaxes pour déclarer un tableau :

La syntaxe de C : int tab[] ;

La syntaxe pure Java : int[] tab ;

La syntaxe d'initialisation d'un tableau de type de base est la même que celle du langage C.

Lors de la déclaration d’une référence de tableau, on peut fournir une liste d’expressions entre
accolades, comme dans :

int n, p ;

...

int t[] = {1, n, n+p, 2*p, 12} ;

Cette instruction crée un tableau de 5 entiers ayant les valeurs des expressions mentionnées et
en place la référence dans t. Elle n’est valable que dans une déclaration.

Exemple d’utilisation d’un tableau :

public class Moyenne


{ public static void main (String args[])
{ int i, nbEl, nbElSupMoy ;
double somme ;
double moyenne ;
System.out.print ("Combien d’eleves ") ;
nbEl = Clavier.lireEntier();
double notes[] = new double[nbEl] ;
for (i=0 ; i<nbEl ; i++)
{ System.out.print ("donnez la note numero " + (i+1) + " : " ) ;
notes[i] = Clavier.lireDouble() ;
}
for (i=0, somme=0 ; i<nbEl ; i++) somme += notes[i] ;
moyenne = somme / nbEl ;
System.out.println ("\nmoyenne de la classe " + moyenne) ;
for (i=0, nbElSupMoy=0 ; i<nbEl ; i++ )

78
M.GBOLOVI Support C.O.O-P.O.O
if (notes[i] > moyenne) nbElSupMoy++ ;
System.out.println (nbElSupMoy + " eleves ont plus de cette moyenne") ;
}
}

b) Affectation de tableaux
Java permet aussi de manipuler globalement des tableaux, par le biais d’affectations de leurs
références.

Considérons ces instructions qui créent deux tableaux d’entiers en plaçant leurs références
dans t1 et t2 :

int [] t1 = new int[3] ;


for (int i=0 ; i<3 ; i++)
t1[i] = i ;
int [] t2 = new int[2] ;
for (int i=0 ; i<2 ; i++)
t2[i] = 10 + i ;
Exécutons maintenant l’affectation :

t1 = t2 ; // la reference contenue dans t2 est recopiee dans t1

Dorénavant, t1 et t2 désignent le même tableau. Ainsi, avec :

t1[1] = 5 ;

System.out.println (t2[1]) ;

on obtiendra l’affichage de la valeur 5, et non 11.

Il est très important de noter que l’affectation de références de tableaux n’entraîne aucune
recopie des valeurs des éléments du tableau. On retrouve exactement le même phénomène que
pour l’affectation d’objets.

 Il est possible d'utiliser des tableaux multidimensionnels (même syntaxe que le C)


int tab1[] = new int [3] ; /* syntaxes équivalentes */
int[] tab2 = new int [3] ;

int[] tab3 = {1, 2, 3 } ; /* initialisation */


int[][] tab4 = new int[3][8] ; /* multidimension */
 Il est possible pour une méthode de préciser un type de retour "tableau" :
int[] methode(…) { … } ou int methode(…) [] { … }

La syntaxe pour accéder un élément d'un tableau est la même que pour le langage C. En
particulier les indices d'un tableau vont de zéro à la taille du tableau moins un.

79
M.GBOLOVI Support C.O.O-P.O.O
int[] newTab(int dim) {
int[] tab = new int[dim] ;
for (int i ; i<dim ; i++ } tab[i] = i ;
return tab ;
}

int[] t = obj.newTab(15) ;

c) La taille d’un tableau : length


Tout tableau possède l'attribut length qui contient la dimension du tableau. De ce point de
vue un tableau multidimensionnel est considéré comme un tableau de tableaux, de tableaux.

void printTabDim1 (int[] tab) {


for (int i=0 ; i < tab.length ; i++ ) System.out.println(tab[i]) ;
}
void printTabDim2 (int[][] tab) {
for (int i=0 ; i < tab.length ; i++ )
for (int j=0 ; j < tab[i].length ; j++) System.out.println(tab[i][j]) ;
}

d) Exemple de tableau d’objets


Les éléments d’un tableau peuvent aussi être des objets.

class Point
{ public Point(int x, int y)
{ this.x = x ; this.y = y ;
}
public void affiche ()
{ System.out.println ("Point : " + x + ", " + y) ;
}
private int x, y ;
}
public class TabPoint
{ public static void main (String args[])
{ Point [] tp ;
A = new Point[3] ;
A[0] = new Point (1, 2) ;
A[1] = new Point (4, 5) ;
A[2] = new Point (8, 9) ;
for (int i=0 ; i<A.length ; i++)
A[i].affiche() ;
}
}

80
M.GBOLOVI Support C.O.O-P.O.O
CHAPITRE 9 : L’HERITAGE

En JAVA, il est possible de dériver une classe à partir d'une autre classe : la classe fille ainsi
créée (ou sous-classe, ou classe dérivée) hérite alors des caractéristiques de sa classe mère
(ou super-classe), tout en la spécialisant avec de nouvelles fonctionnalités.

Cette technique permet donc de développer de nouveaux outils en se fondant sur un certain
acquis, ce qui justifie le terme d’héritage. Comme on peut s’y attendre, il sera possible de
développer à partir d’une classe de base, autant de classes dérivées qu’on le désire. De même,
une classe dérivée pourra à son tour servir de classe de base pour une nouvelle classe dérivée

1)Principes généraux, le mot clé extends

 Toute classe dans Java est une sous classe de la classe Object (elle en hérite
directement ou indirectement et éventuellement implicitement).
 Une classe ne peut hériter directement que d'une seule classe : il n'y a pas d'héritage
multiple dans Java contrairement à C++. Cette caractéristique du langage permet de
supprimer de nombreux problèmes liés à l'héritage multiple et est compensée par la
notion d'interface que nous aborderons après. Une sous-classe peut redéfinir une ou
plusieurs des méthodes dont elle hérite. Bien entendu, elle peut aussi en définir de
nouvelles, ainsi que de nouveaux attributs.
 Le mot clé extends permet de décrire les relations d'héritage : pour créer une nouvelle
classe fille, il suffit de déclarer cette classe en faisant suivre son nom du mot clé extends
puis du nom de sa classe mère.
Voici un exemple classique de hiérarchie de classes.

class Felin {
boolean afaim = true ;
void parler() { }
void appeler() {
System.out.println("Le Félin est appelé") ;
if (afaim) parler() ;
}
}
final class Chat extends Felin {
String race ;
void parler() { System.out.println("miaou!"); }
}
final class Tigre extends Felin {
void parler() { System.out.println("Groar!"); }
void chasser() { … }
}

Tigre tigre = new Tigre() ;
tigre.chasser() ; // OK
tigre.appeler() ; // OK : méthode héritée de la classe Felin

2)Accès à la super-classe d'une classe : super(…)

81
M.GBOLOVI Support C.O.O-P.O.O
Le mot clé super permet d'accéder à la version non redéfinie des attributs et méthodes de la
super-classe. Il permet aussi, s'il est utilisé comme première instruction dans un constructeur,
d'appeler un des constructeurs de la classe mère, avec ou sans paramètres.

class Mere {
int attribut ;
Mere() { attribut = 1 ; }
Mere(int attribut) ( this.attribut = attribut ; }
void print() { System.out.println("base" + attribut) ; }
}
class fille extends Mere {
boolean flag ;
Fille( int a ) { super(a) ;
flag = true ;
}
void print() { super.print() ;
System.out.println("dérivée") ;
}
}

Fille f = new Fille(2) ;
Mere m = f ;
m.print() ;
// Affiche :
dérivée
base 2

3)Le Polymorphisme
Une méthode polymorphe est une méthode déclarée dans une super-classe et redéfinie par une
sous-classe. Dans Java, toute méthode est par défaut polymorphe.

Les méthodes final ne peuvent être redéfinies et ne sont donc pas polymorphes (définir une
méthode final est utile pour optimiser le byte code et pour des raisons de sécurité).

Il s’agit d’un concept extrêmement puissant en P.O.O., qui complète l’héritage. On peut
caractériser le polymorphisme en disant qu’il permet de manipuler des objets sans en
connaître (tout à fait) le type.

D’une manière générale, Java permet d’affecter à une variable objet non seulement la
référence à un objet du type correspondant, mais aussi une référence à un objet d’un type
dérivé. On peut dire qu’on est en présence d’une conversion implicite (légale) d’une référence
à un type classe T en une référence à un type ascendant de T ; on parle aussi de compatibilité
par affectation entre un type classe et un type ascendant.

class Zoo {
int MAX = 10 ;
Felin[] liste ;

82
M.GBOLOVI Support C.O.O-P.O.O
int compteur = 0 ;
Cirque( int taille ) { MAX = taille ; liste = new Felin[MAX] }
void addFelin( Felin newfelin) {
if (compteur < MAX) liste[compteur++] = newfelin ;
else /* traitement d'erreur */
}
final void appeler() { // cette méthode ne peut être redéfinie dans une sous-classe
for ( int i=0 ; i<compteur ; i++ ) liste[i].parler() ; // appel polymorphe
}
}....
Zoo zoo = new Zoo(10) ;
zoo.addFelin(new Tigre()) ;
zoo.addFelin(new Chat()) ;

zoo.appeler() ;

En résumé, le polymorphisme en Java se traduit par :

• la compatibilité par affectation entre un type classe et un type ascendant,

• la ligature dynamique des méthodes.

class Point
{ public Point (int x, int y)
{ this.x = x ; this.y = y ;
}
public void deplace (int dx, int dy)
{ x += dx ; y += dy ;
}
public void affiche ()
{ System.out.println ("Je suis en " + x + " " + y) ;
}
private int x, y ;
}
class Pointcol extends Point
{ public Pointcol (int x, int y, byte couleur)
{ super (x, y) ; // obligatoirement comme premiere instruction
this.couleur = couleur ;
}
public void affiche ()
{ super.affiche() ;
System.out.println (" et ma couleur est : " + couleur) ;
}
private byte couleur ;
}
public class Poly
{ public static void main (String args[])
{ Point p []= new Point[3] ;
p [0]= new Point (3, 5) ;
p [2]= new Point (4, 8) ;
p.affiche() ; // appelle affiche de Point
p [1]= new Pointcol (4, 8, (byte)2) ;

83
M.GBOLOVI Support C.O.O-P.O.O
for(int i=0 ;i<tab.length;i++) p[i].affiche();
}
}

4)Méthodes et classes abstraites : abstract

a) Les classes abstraites


abstract class Felin {
boolean afaim = true ;
abstract void parler( ) ;
void appeler() {
System.out.println("Le Félin est appelé") ;
if (afaim) parler() ; }
}
class Tigre extends Felin {
void parler() { System.out.println("Groar!"); }
}

b) Les méthodes abstraites


Une méthode abstraite est une méthode dont on donne le prototype, sans en décrire
l'implémentation (sans définir les instructions qui décrivent ses actions). Elle doit de plus être
précédée du mot clé abstract. Une méthode abstraite doit obligatoirement être redéfinie dans
une sous-classe pour pouvoir être utilisée (par polymorphisme).

Exemples de classes abstraites

Nous voulons pouvoir stocker des chiens et des chats dans un tableau :

public class MesAnimaux {


private Animal [] animaux = new Animal [5];
private int indiceSuivant = 0;
public void add ( Animal a) {
if ( indiceSuivant < animaux . length ) {
animaux [ indiceSuivant ] = a;
indiceSuivant ++;
}
}
}
public TestMesAnimaux {
public static void main ( String [] args ) {
MesAnimaux list = new MesAnimaux ();
Chien c = new Chien ();
Chat d = new Chat ();
list .add(c);
list .add(d);
}

84
M.GBOLOVI Support C.O.O-P.O.O
CHAPITRE 10: LES PACKAGES, LES
INTERFACES ET LES EXCEPTIONS

I. LES PACKAGES ET L’ENCAPSULATION


La notion de paquetage correspond à un regroupement logique sous un identificateur
commun d’un ensemble de classes. Elle facilite le développement et la cohabitation de
logiciels conséquents en permettant de répartir les classes correspondantes dans différents
paquetages. Le risque de créer deux classes de même nom se trouve alors limité aux seules
classes d’un même paquetage.

1)Les packages
Un package peut être considéré comme une bibliothèque de classes : Il permet de regrouper
un certain nombre de classes qui sont proches dans une seule famille et ainsi d'apporter un
niveau de hiérarchisation supplémentaire au langage.

Les packages sont eux-mêmes organisés hiérarchiquement. : on peut définir des sous-
packages, des sous-sous-packages, …
java

util lang awt

Date String
event Button
Thread
ActionEvent List

ActionEvent
Dans cet exemple :

 La classe Button appartient au package java.awt (sous-package du package java)


 La classe ActionEvent appartient au package java.awt.event
Il y a deux manières d'utiliser une classe stockée dans un package :

 En utilisant le nom du package suivi du nom de la classe


java.util.Date now = new java.util.Date() ;
System.out.println(now) ;

 En utilisant le mot clé import pour importer (inclure) le package auquel appartient la
classe
import java.util.Date ; // Doit être en tête du fichier !!
… // Ne permet d'importer que la classe Date de java.util
Date now = new Date() ;
System.out.println(now) ;

85
M.GBOLOVI Support C.O.O-P.O.O
import java.util.* ; // Permet d'importer toutes les classes de java.util

Date now = new Date() ;
System.out.println(now) ;

On peut généralement utiliser l'une ou l'autre de ces deux méthodes, mais il existe un cas ou
l'on doit obligatoirement utiliser la première : si deux classes portant le même nom sont
définies dans deux packages différents.

Java importe automatiquement le package java.lang qui permet d'utiliser des classes comme
Thread ou System.

Remarque : System est une classe de java.lang, out est une variable statique de cette classe (de
type PrintStream) et println est une méthode de la classe PrintStream.

2)La structure de stockage des classes et des packages


Les fichiers sources Java ont pour extension .java, les fichiers compilés (donc contenant du
byte code) ont pour extension .class.

Seules les classes public sont accessibles d'un autre package, ou d'un autre fichier (les autres
classes ne sont pas connues en dehors de leur fichier). Il ne peut y avoir qu'une et une seule
classe public dans un fichier et cette classe doit porter le même nom que le fichier (en
respectant la casse).

Les fichiers des classes qui font partie d'un package doivent être placés dans une hiérarchie de
répertoires correspondant à la hiérarchie des packages. L’attribution d’un nom de paquetage
se fait au niveau du fichier source ; toutes les classes d’un même fichier source appartiendront
donc toujours à un même paquetage Ils doivent obligatoirement commencer par une
déclaration précisant le nom de leur package, précédé du mot clé package.

// Fichier Classe1.java dans le répertoire test/util/


package test.util ;
public class Classe1 {
public void test() { … } }

// fichier Appli1.java dans le sous répertoire application/


// la déclaration de package est inutile, puisque cette classe n'est pas destinée à être utilisée par d'autres
import test.util.* ;
public class Appli1 {
public static void main(String args[]) {
Classe1 c = new Classe1() ;
c.test() ;} }

3)Les principaux packages du JDK


java.applet Classes de base pour les Applets
java.awt Interface Utilisateur
java.io Entrées/Sorties, fichiers, …

86
M.GBOLOVI Support C.O.O-P.O.O
java.lang Classes faisant partie du langage
java.math Utilitaires mathématiques
java.net Accès au réseau
java.security gestion de la sécurité
java.sql accès aux bases de données
java.util Conteneurs, dates, …
java.util.zip Pour compresser/décompresser

4) Paquetages et droits d’accès

D’une manière générale, chaque classe dispose de ce qu’on nomme un droit d’accès (on dit
aussi un modificateur d’accès). Il permet de décider quelles sont les autres classes qui peuvent
l’utiliser. Il est simplement défini par la présence ou l’absence du mot-clé public :

• avec le mot-clé public, la classe est accessible à toutes les autres classes (moyennant
éventuellement le recours à une instruction import) ;

• sans le mot-clé public, la classe n’est accessible qu’aux classes du même paquetage.

Tant que l’on travaille avec le paquetage par défaut, l’absence du mot public n’a guère
d’importance (il faut toutefois que la classe contenant main soit publique pour que la machine
virtuelle y ait accès).

En ce qui concerne les méthodes et les attributs, il existe 4 niveaux de visibilité qui permettent
de définir si telle méthode ou tel attribut est visible pour les classes du même package, pour
celles en dehors du package courant et pour les classes dérivées.

La visibilité friendly est celle prise par défaut.

méthodes de la classes dérivées classes du même classes dérivées classes des autres
Accessible aux : même classe dans le même package dans un autre packages
package package

public X X X X X

protected X X X X

friendly X X X

private X

Pour respecter les concepts de l'approche objet, il est nécessaire de respecter les règles de
conception suivantes:

 Les attributs doivent toujours être privés,


 Les attributs constants (final) peuvent être publics ou privés,
 Les méthodes à usage strictement interne doivent être privées,
 Si un attribut doit pouvoir être accessible de l'extérieur : définir des méthodes
publiques permettant d'y accéder.
Ces règles permettent de garantir le respect de l'encapsulation des objets: pour utiliser un
objet, peu importe de quoi il est fait, seul importe ce qu'il peut faire (les méthodes
publiques)…

87
M.GBOLOVI Support C.O.O-P.O.O
class Personne {
private String nom ;…
public Personne(String nom) { this.nom = nom ; }
public String getNom() { return nom ; }
} …
Personne moi = new Personne("Toto") ;
System.out.println( moi.getNom() ) ;

II. LES INTERFACES


Une interface est une déclaration permettant de décrire un ensemble de méthodes abstraites et
de constantes. On peut considérer une interface comme étant une classe abstraite ne contenant
que des méthodes abstraites et que des attributs final et static.

1)Définitions, les mots clés interface et implements.


Il est donc impossible d'instancier directement une interface. Par contre, une classe peut
implémenter une ou plusieurs interfaces, en utilisant le mot clé implements suivi du nom de
chaque interface concernée. Cette classe doit alors fournir une version pour chaque méthode
déclarée dans les interfaces implémentées.

On peut considérer l'implémentation des interfaces comme une forme d'héritage multiple
léger.

Une interface est définie de manière similaire à une classe, mais est caractérisée par le mot clé
interface.

interface Printable {
void print() ;
}

class Point extends Object implements Printable {


private double x,y ;…
void print() {
System.out.println( "(" + x + "," + ")" ) ; }}
Les attributs déclarés dans une interface sont obligatoirement des constantes statiques : les
mots clés static et final ne sont pas nécessaires pour le préciser. Ces attributs doivent donc
obligatoirement être initialisés.

interface Interval {
int MIN = 0 ;
int MAX = 1000 ;
} …
for (int i = Interval.MIN ; i < Interval.MAX ; i++ ) { … }

Par essence, les méthodes d’une interface sont abstraites et publiques. Néanmoins, il n’est pas
nécessaire de mentionner les mots-clés public et abstract .

2)Interfaces et héritage
Nous avons déjà dit qu'une classe peut implémenter plusieurs interfaces.

88
M.GBOLOVI Support C.O.O-P.O.O
Une interface peut aussi hériter d'une ou plusieurs interfaces : elle hérite alors de l'ensemble
des méthodes abstraites et constantes de ses ancêtres. Il ne s’agit en fait que d’emboîter
simplement des déclarations de méthodes.

Interface Printable { /* exprime le fait de pouvoir être imprimé */

void print() ;}

interface InputStream { /* exprime le fait de pouvoir être une source de caractères */


public int read() ;}

interface OutputStream { /* exprime le fait de pouvoir accepter des caractères */public


void write(int) ;

interface DataStream extends InputStream, OutputStream {

public double readDouble() ;

public void writeDouble(double) ;

class MonStream implements DataStream, Printable {

void print() { …

public int read() { …}

public void write(int) { …}

public double readDouble(){ …}

public void writeDouble(double) { …}

III. LES EXCEPTIONS


1)Pourquoi des exceptions ?

Lorsque l'on examine le code source d'un programme écrit en langage C, on peut observer
qu'une grande partie de ce code est constitué de lignes d'instructions concernant la détection et
la gestion d'erreurs ou de traitement de cas exceptionnels (division par zéro, impossible
d'ouvrir un fichier, mauvaise saisie de données,…). Ces portions de code sont toujours
fortement imbriquées dans le reste du code et le programmeur a souvent des difficultés à
déterminer ce qu'il doit faire dans tel ou tel cas. Cela a plusieurs conséquences négatives :
_ Le code est peu lisible, on ne distingue pas le traitement normal des traitements des

89
M.GBOLOVI Support C.O.O-P.O.O
cas exceptionnels (qui ont souvent une logique très différente)
_ Des traitements d'erreurs sont souvent oubliés par le programmeur.
_ Il est souvent difficile de traiter de manière cohérente l'ensemble des erreurs :
comment distinguer un résultat valide d'un cas d'erreur ? (Par exemple si le code retour
d'une fonction est utilisé pour transmettre le résultat, où doit-on passer le code d'erreur
?)
C'est pourquoi des langages comme C++ ou Java ont introduit la notion d'exception : un
mécanisme facilitant le traitement de tous les cas exceptionnels et permettant en particulier de
séparer ces traitements des traitements habituels du programme.
Un cas exceptionnel est représenté par un objet (une exception), qui contient la description du
cas exceptionnel, et qui peut être transmis de l'endroit où il a été déclenché jusqu'à celui où
l'on sait le traiter (un gestionnaire d'exception).
2)Représentation et déclenchement des exceptions :
classe Exception, opérateur throw
Une exception dans Java est un objet appartenant à une classe dérivée de la classe
java.lang.Exception.
Une exception est déclenchée avec le mot clé throw, après avoir créé le nouvel objet
Exception correspondant.
class MonException extends Exception { }

if ( erreurDétectée ) throw new MonException();

3)Propagation, Capture et traitement des exceptions
Gestionnaire des
Exceptions :


traitement de X
Traitement normal
:


Erreur X
Exception X
M. GBOLOVI 21 Cours JAVA Master 2
Lorsqu'une exception est déclenchée dans une méthode (soit directement avec throw, soit
parce qu’une méthode appelée dans cette méthode la déclenche et la propage) il y a deux
possibilités :
_ On ne traite pas l'exception localement et on la propage.
_ On traite l'exception localement.
a) Propagation des exceptions : le mot clé throws
Toute méthode susceptible de déclencher une exception qu’elle ne traite pas localement doit
mentionner son type dans une clause throws figurant dans son en-tête.
Ainsi toute exception pouvant être propagée par une méthode doit être signalée dans la
déclaration de celle-ci. Pour cela on utilise le mot clé throws suivi de la liste des exceptions.
class PasDeSolution extends Exception {}
class Equation { /* Equation du second degré ax2+bx+c */
private double a, b, c ;
public Equation(double a, double b, double c) { this.a = a ; this.b = b ; this.c = c ; }
public double resultat() throws PasDeSolution { // Cette méthode propage une exception

90
M.GBOLOVI Support C.O.O-P.O.O
double discriminent = b*b-4*a*c ;
if (discriminent < 0) throw new PasDeSolution() ;
return ( b + Math.sqrt(discriminent) ) / (2 * a) ;
}
}

void calcul() throws PasDeSolution {
Equation eq = new Equation(1,0,1) ;
Eq.resultat() ;
}
// Cette méthode doit déclarer la propagation de l'exception PasDeSolution que Eq.resultat()
peut
// déclencher, car elle ne la traite pas localement.
b) Capture des exceptions : catch, try et finally
Un gestionnaire d'exception est défini en :
_ Définissant quelles instructions sont surveillées par ce gestionnaire, en plaçant cellesci
dans un bloc d'instructions préfixé par le mot clé try.
_ Définissant un ou plusieurs blocs de traitement d'exception préfixés par le mot-clé
catch.
void calcul() {
try {
Equation eq = new Equation(1,0,1) ;
double resultat = Eq.resultat() ;
System.out.println("Resultat = " + resultat) ;
}
catch ( PasDeSolution e ) {
System.out.println("Pas de solutions") ;
}
}
Si l'appel à la méthode Eq.resultat() se passe mal, l'exécution du bloc try est immédiatement
arrêtée et le bloc catch correspondant est exécuté, puis on passe à la suite du programme.
Dans le cas contraire, les instructions du bloc catch ne seront jamais prises en compte.
Il est possible de capturer dans un seul bloc catch plusieurs exceptions, en capturant une
exception dont la classe est une classe mère de toutes les exceptions concernées :
try {

}
catch ( Exception e ) { /* permet de capturer tout type d'exception */

}
Il est aussi possible de mettre plusieurs bloc catch :
try { …
}
catch ( IOException e ) { /* permet de capturer tout type d'exception d'entrée/sorties */

}
catch ( PasDeSolution e ) {

}
Il est possible de définir un bloc finally qui, contrairement au catch, n'est pas obligatoire, et

91
M.GBOLOVI Support C.O.O-P.O.O
qui permet de spécifier du code qui sera exécuté dans tous les cas, qu'une exception survienne
ou pas. Ce code sera exécuté même si une instruction return est exécutée dans le catch ou le
try !
try { // Ouvrir un fichier
// Lire et écrire des données
}
catch ( IOException e ) { /* permet de capturer tout type d'exception d'entrée/sorties */
System.out.println(e) ;
return ;
}
finally {// Fermeture du fichier
} …// autres traitements sur les données lues…
Remarque : Nous constatons dans cet exemple qu'un objet Exception peut être directement
affiché avec la méthode System.out.println(). L'affichage consiste en une chaîne de caractères
expliquant la nature de cette exception.

CHAPITRE 11 : LES CLASSES DE BASE


Dans cette partie nous passerons en revue quelques classes indispensables à connaître, sans
trop entrer dans les détails : comme pour les bibliothèques de fonctions C, il est impossible et
inutile de tout vouloir apprendre sur les classes Java, il y en a trop et il sera toujours
indispensable de savoir utiliser le système d'aide et sa propre expérience pour trouver la
réponse à nos questions.

Pour chaque classe nous n'aborderons donc que quelques exemples d'utilisation montrant les
méthodes les plus importantes à connaître.

1)La classe Object


La classe Object est la classe mère de toutes les classes.

Compte tenu des possibilités de compatibilité exposées précédemment, une variable de type

Object peut être utilisée pour référencer un objet de type quelconque :

Point p = new Point (...) ;

Object o ;

o = p ; // OK

Cette particularité peut être utilisée pour manipuler des objets dont on ne connaît pas le type
exact (au moins à un certain moment).

Bien entendu, dès qu’on souhaitera appliquer une méthode précise à un objet référencé par
une variable de type Object, il faudra obligatoirement effectuer une conversion appropriée.

92
M.GBOLOVI Support C.O.O-P.O.O
o.deplace() ; // erreur de compilation

((Point)o).deplace() ; // OK en compilation (attention aux parenthèses)

Point p1 = (Point) o ; // OK : idem ci-dessus, avec création d’une référence

p1.deplace() ; // intermediaire dans p1

La classe Object contient 2 méthodes que la plupart des classes Java doivent redéfinir :

String toString() : qui retourne une description de l'objet. Elle est automatiquement appelée
en cas de besoin d’une conversion implicite en chaîne.

boolean equals(Object) : qui permet de tester l'égalité sémantique de deux objets.

On doit aussi noter l'existence de la méthode Class getClass() qui peut être utilisée sur tout
objet pour déterminer sa nature (nom de sa classe, nom de ses ancêtres, structure).

class Personne { // dérive de Object par défaut


private String nom ;
public Personne(String nom) { this.nom = nom ; }
public String toString() {
return "Classe : " + getClass().getName() + " Objet : " + nom ;
}
boolean equals(Personne p) { return p.nom.equals(nom) ; }
}

Personne p1 = new Personne("Jean Dupond") ;


Personne p2 = new Personne("Jean Dupond") ;

if ( p1 == p2 ) … // Faux, les références sont différentes


if (p1.equals(p2)) … // Vrai, comparaison sémantique

System.out.println( p1 ) ;
// Affiche : Classe : Personne Objet : Jean Dupond

Remarque : Lorsqu'on affiche un objet avec la méthode println(obj), c'est la méthode


toString() de cet objet qui est utilisée pour afficher son contenu.

2)Les chaînes de caractères


Elles peuvent être représentées par deux classes d'objets : String et StringBuffer

a) La classe java.lang.String
Cette classe décrit des objets qui contiennent une chaîne de caractères constante (cette chaîne
ne peut pas être modifiée).

C'est une classe particulière qui est reconnue par le compilateur : une constante de type chaîne
de caractères est reconnue par celui-ci comme étant un objet de la classe String.

93
M.GBOLOVI Support C.O.O-P.O.O
String Message = "Hello World" ;

C'est aussi la seule classe qui dispose d'opérateurs supplémentaires : + et += pour la


concaténation de chaînes de caractères.

int nombre = 3 ;
String message = "Mon nombre est " + 3 ; // Ici le nombre est converti automatiquement en String

System.out.println("Mon message est : " + message ) ;


// Affiche : Mon message est : message 3

La classe String possède de nombreuses méthodes, voici quelques exemples :

Boolean chercheMot( String texte, String atrouver, boolean ignoremajuscules) {


int ici = 0 ;

while ( ici < texte.length() ) {


int suivant = texte.indexOf( ',', ici ) ;
if ( suivant == -1 ) suivant = texte.length() ;
String mot = texte.substring( ici, suivant) ;
if ( ignoremajuscules ) { if ( mot.equalsIgnoreCase( atrouver ) ) return true ; }
else if ( mot.equals( atrouver ) ) return true ;
ici = next+1 ;
}
return false ;
}

Description rapide des méthodes utilisées :

int length() Retourne le nombre de caractères compris dans la chaîne.

int indexOf(char c, int i) Retourne la position du caractère c en partant de la position i

String substring(int i, int j) Retourne une chaîne extraite de la chaîne sur laquelle est
appliquée cette méthode, en partant de la position i à la position j

boolean equals(String s) comparaison sémantique des chaînes.

b) La classe java.lang.StringBuffer
La classe StringBuffer permet de représenter des chaînes de caractères de taille variable.

Contrairement à la classe String, il n'est pas possible d'utiliser l'opérateur + avec les objets de
cette classe.

Lorsqu'un objet du type StringBuffer est construit, un tableau de caractères est alloué dans
l'objet. Sa taille initiale est de 16, mais si l'on ajoute plus de 16 caractères dans l'objet, un
nouveau tableau, plus grand est alloué (les caractères sont recopiés de l'ancien tableau vers le
nouveau et l'ancien tableau est détruit).

Un objet de la classe StringBuffer se caractérise donc par deux tailles, qui sont retournées par
les méthodes :

int length() : qui retourne le nombre de caractères réellement contenus

94
M.GBOLOVI Support C.O.O-P.O.O
int capacity() : qui retourne la taille actuelle du tableau interne

Quelques méthodes supplémentaires:

StringBuffer append(StringBuffer p) : ajoute p en fin de chaîne (p est n'importe quel


type de base)

StringBuffer insert(int offset, StringBuffer p) : idem, mais en insérant p à l'emplacement


indiqué par offset

StringBuffer reverse() : inversion des caractères de la chaîne.

3)Les conteneurs
Les conteneurs sont des objets qui permettent de contenir d'autres objets.

Le premier conteneur que nous avons vu est le tableau, qui est un élément de base du langage
Java lui-même, et qui peut contenir des références à des objets ou des types de base.

Les conteneurs que nous allons voir dans ce chapitre permettent de contenir des références à
des objets dérivant de la classe Object, c'est à dire tout objet appartenant à une classe (mais
pas les types de base, sauf si l'on utilise un Wrapper).

Les méthodes proposées par les conteneurs (pour accéder à leur contenu) retournent des
références de type Object que l'on devra souvent convertir explicitement vers le type
approprié.

a) La classe java.util.Vector
Les objets de la classe Vector sont aux tableaux ce que les StringBuffer sont aux String : Ils
représentent des tableaux à taille variable. Le fonctionnement interne de ces deux classes est
d'ailleurs très similaire (redimensionnement automatique du tableau interne si cela est
nécessaire).

Les objets de la classe Vector étant à taille variable, il n'y a pas de limite au nombre d'objets
qu'ils peuvent contenir (la seule limite est la taille de la mémoire).

Exemple d'utilisation :

95
M.GBOLOVI Support C.O.O-P.O.O
Vector vec = new Vector() ;

for (int i=0 ; i<10 ; i++) {


Integer element = new Integer(i) ;
vec.addElement(element) ; // Ajout en fin de Vecteur
}
// => 0 1 2 3 4 5 6 7 8 9

Integer i = new Integer(15) ;
vec.insertElementAt(i,5) ; // Insertion à la position indiquée
// => 0 1 2 3 4 15 5 6 7 8 9

vec.removeElementAt(0) ; // Suppression de l'élément indiqué
// => 1 2 3 4 15 5 6 7 8 9

Integer j = (Integer)vec.elementAt(6) ;
// j contient une référence sur l'objet Integer contenant 5

vec.removeAllElements() ; // Suppression de tous les éléments
// =>

Autres méthodes disponibles :


Object elementAt(int index): retourne (sans retirer) l'élément à la position index
void setElementAt(Object obj): place l'objet à la position indiquée (remplacement)
boolean contains(Object obj) : retourne true si obj est dans le tableau
int indexOf(Object obj) : retourne la position de obj (-1 si obj n'est pas présent)
int size() : retourne la taille du tableau

b) L'interface java.util.Enumeration
Un objet implémentant l'interface Enumeration permet de parcourir les éléments d'un
conteneur (c'est un itérateur de conteneur).

Un tel objet ne contient pas de données mis à part une référence à un conteneur et une
"position courante" dans ce conteneur.

Enumeration est l'interface unique pour le parcours de tous les types de conteneurs définis
dans les classes de base de Java. Un objet implémentant cette interface permet de réaliser une
et une seule itération sur le conteneur qui lui est associé.

Pour les conteneurs de type Vector, la méthode elements() permet de récupérer un objet
implémentant l'interface Enumeration. Il est alors possible d'utiliser deux méthodes sur cet
objet :

boolean hasMoreElements() : Teste s'il reste des éléments à parcourir


Object nextElement() : Retourne l'élément courant et passe au suivant

96
M.GBOLOVI Support C.O.O-P.O.O
// Soit le conteneur :
Vector vec = new Vector() ;

for (int i=0 ; i<10 ; i++) {


Integer element = new Integer(i) ;
vec.addElement(element) ;
}
// => 0 1 2 3 4 5 6 7 8 9

// Exemple de parcours sans itérateur :


for (int i=0 ; i<vec.size() ; i++ ) System.out.println( vec.elementAt(i) ) ;

// Exemple de parcours avec itérateur :


for (Enumeration e = vec.elements() ; e.hasMoreElements() ; ) System.out.println(e.nextElement()) ;

c) la généricité en Java
A partir de JDK 5.0, les collections sont définies par le biais de classes génériques

❖ Une classe générique est une classe qui définit ses méthodes de manipulation de structure
de données sans préciser le type de ses éléments. Idée: un ensemble de X, une liste d’Y, …

❖ Par exemple, on pourrait définir une classe Pile<E> qui définit les

méthodes void empile(E e), E sommet(), void depile()

❖ Le type E est définit au moment de la déclaration d’un objet de la classe Pile, exemple

❖ Pile<int> p1 // une pile d’entiers

❖ Pile<String> p2 // une pile de chaîne de caractères

❖ Instanciation

❖ p1 = new Pile<int>;

❖ p2 = new Pile<String>;

d) Collection

Une collection de données est un conteneur d’éléments de même type qui possède un
protocole particulier pour l’ajout, le retrait et la recherche d’éléments. En Java, les
collections sont implantées dans le paquetage java.util

 Type ancêtre d'une collection : java.util.Collection (interface)


o Iterator<T> iterator() permet d'obtenir un itérateur sur la collection (pour
récupérer ses éléments un par un)
o int size() permet de connaître le nombre d'éléments de la collection
 Deux grandes familles de collections :
o List<T>, interface ancêtre des listes

97
M.GBOLOVI Support C.O.O-P.O.O
o Set<T>, interface ancêtre des ensembles (collection sans doublon avec test
rapide d'appartenance)
 Map<K,V> n'hérite pas de Collection ; permet de représenter des couples de clé-
valeur (dictionnaire)

e) Listes

Deux types de listes intéressantes sont disponibles en Java :

1. LinkedList<T>
o Liste chaînée avec un double maillage (précédent, suivant)
o Maintien d'une référence vers le premier et dernier maillon
o Ajouter ou supprimer un élément en tête ou fin de liste est en temps constant
 Structure utile pour l'implantation de file (FIFO) ou de pile (LIFO)
o Accéder à un élément d'indice i nécessite de parcourir depuis le début ou la fin
les maillons jusqu'à i
o Gourmande en mémoire (une référence précédent, une référence suivant et une
référence maillon pour chaque valeur)
o Dispersion en mémoire
o Liste chaînée = arbre unaire (arbre en forme de peigne)
2. ArrayList<T>
o Liste utilisant un tableau pour le stockage (références d'objets stockées)
o Les éléments sont contigüs en mémoire : itération optimisée
o Supprimer un élément en fin de liste est en temps constant
o Ajouter un élément en fin de liste
 Soit se fait simplement par affectation de la prochaine cellule libre
 Soit nécessite une réallocation d'un tableau plus grand (gérée par
ArrayList)
 Dans tous les cas, le temps d'ajout est considéré (par amortissement)
constant
o Ajouter/supprimer un élément vers le début de la liste
 Nécessite le décalage des éléments suivants
o Accéder à un élément d'indice i est instantané (ième cellule du tableau)

 Pour implanter une file (FIFO) ou une pile (LIFO), il est conseillé d'utiliser un
ArrayList <T> : permet d'ajouter/supprimer des éléments en tête/fin en temps amorti
constant
 Il est rare en pratique de devoir ajouter/supprimer des éléments au milieu d'une liste
o Exemple : pour filtrer une liste → on peut créer une nouvelle liste, parcourir
l'ancienne liste et y transférer les éléments gardés
❖ Dynamique = la taille (nombres d’éléments) du tableau n’est pas fixe et peut varier en
cours d’exécution

❖ L’accès à ses éléments est direct, comme dans un tableau

❖ L’opération d’ajout et de suppression est un peu complexe, car nécessitant éventuellement


un réarrangement des éléments pour qu’ils soient toujours contigus (comme dans un tableau).

❖ Déclaration / construction

98
M.GBOLOVI Support C.O.O-P.O.O
Pour utiliser une liste il faut la déclarer :

ArrayList <E> v1 = new ArrayList <E> (); // vecteur dynamique vide de type E

ou

ArrayList <E> v2 = new ArrayList <E> (c); /* vecteur dynamique contenant tous les éléments
de la collection c */

❖ Ajout d’un élément en fin de vecteur:

v1.add(elem);

❖ Accès au ième élément

e = v1.get( 3 ); // accès au 3ème élément du vecteur v1

❖ Suppression du ième élément du vecteur (avec retour dans e)

E e = v1.remove( 3 ); // suppression du 3ème élément

❖ Parcours: exemple, afficher tous les éléments

public static void affiche (ArrayList <E> v) {

for (E e : v) System.out.print ( e + « » );

System.out.println();

99
M.GBOLOVI Support C.O.O-P.O.O
PARTIE 5 : LA PROGRAMMATION A GRANDE
ECHELLE

CHAPITRE 12: LA PROGRAMMATION A GRANDE


ECHELLE
Par définition, la programmation à grande échelle (“in the large”) est la programmation par
une équipe. C’est ici que le génie logiciel (“software engineering”) devient très important.
Par définition, la programmation à petite échelle (“in the small”) est la programmation par une
seule personne. Il s’agit d’avoir une discipline qui permet de gérer des programmes dont
chacun ne connaît qu’une partie. La psychologie joue un grand rôle: garder une équipe
motivée, loyale, heureuse, etc. Cela fait partie d’un bon management. Mais il y a aussi
quelques règles plus techniques…

I. Gestion d’une équipe


La première chose est de s’assurer que l’équipe est bien coordonnée:
• la responsabilité de chaque personne doit être compartimentalisée (par exemple, limitée à un
composant ou un module),
• par contre, les connaissances doivent être échangées librement (pas d’informations secrètes!)
Les interfaces entre les composants doivent être soigneusement documentées. Une bonne
documentation est un pilier de stabilité.
Au-delà des compétences de gestionnaire et d'organisateur, le chef de projet informatique doit
être capable de dynamiser, motiver et animer son équipe autour d'un objectif commun.

II. Méthodologie de développement


On ne peut pas tout prévoir!

• Une méthodologie où on essaie de tout spécifier dès le début est vouée à l’échec!

Une méthodologie qui marche bien est le développement incrémental (aussi appelé
développement itératif)

• On fait pousser un programme comme un être vivant: on commence petit et on grandit

Un processus du logiciel est un ensemble d’activités participant à la production du logiciel. Il


y a quatre grands types d’activités formant les processus : activités de spécification du
logiciel, activités de développement du logiciel, activités de validation et activités d’évolution
du logiciel. Ces activités peuvent être organisées de différentes manières selon les besoins et
particularités des systèmes et des équipes participantes.

100
M.GBOLOVI Support C.O.O-P.O.O
III. Communication entre composants

Appel de procédure/fonction/objet: Le composant qui appelle l’autre s’arrête et attend une


réponse (par exemple, un client/serveur)

Coroutine: Quand il est appelé, chaque composant continue là où il s’était arrêté la dernière
fois (par exemple, deux joueurs d’échecs)

Concurrent et synchrone: Chaque composant exécute de façon indépendante des autres.


Quand un composant appelle un autre, il attend le résultat. (Deux joueurs d’échecs qui
réfléchissent tout le temps)

Concurrent et asynchrone: Chaque composant exécute de façon indépendante des autres. Un


composant peut envoyer un message à un autre sans attendre le résultat. (Une équipe de
football)

Boîte à courrier (variante de concurrent asynchrone): Un composant dépose un message dans


la boîte d’un autre. L’autre peut lire uniquement les messages qui l’intéressent (choisis avec
pattern matching).

Modèle de coordination (variante de concurrent asynchrone): Un composant dépose un


message dans un ensemble commun. Un autre le prend. Les deux composants ne se
connaissent pas. (Par exemple, un groupe d’imprimantes).

101
M.GBOLOVI Support C.O.O-P.O.O