Académique Documents
Professionnel Documents
Culture Documents
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.
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.
5
M.GBOLOVI Support C.O.O-P.O.O
PARTIE 1 : GENIE LOGICIEL
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)
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.
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.
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.
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
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 :
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.
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.
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.
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.
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.
Classe « nomDeLaclasse »
Debut
16
M.GBOLOVI Support C.O.O-P.O.O
Signature des methodes
Fin
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 :
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.
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()
Exemple :Cpte.creer(“0123123891“,175000)
Cpte.Debiter(50000)
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
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
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 :
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
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.
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
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.
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
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.
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
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
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.
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).
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
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.
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
Rayonr
Fin
Fonction Cercle ::surface() :reel
Var surf :reel
Debut
surf3.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
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)
Surf0
F[0]C
F[1]R
Pour i de 1 à 2 faire
Surfsurf+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.
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.
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.
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.
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
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.
Composition(Agrégation forte)
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.
Dans certains langages orienté objet comme le C++ les tableaux d’objet sont définis comme
les tableaux de types primitifs.
F[1].surface() ;
Syntaxe de déclaration
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.
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
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
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.
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
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 :
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.
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.
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.
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 :
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.
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
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.
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.
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).
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 :
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.
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
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.
Exemple imprimante
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.
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.
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.
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
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...
60
M.GBOLOVI Support C.O.O-P.O.O
Exemple de guichet
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.
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.
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.
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.
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
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.
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)
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.
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.
Destiné pour des applications réseaux, la sécurité dans Java est un aspect primordial.
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.
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.
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.
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.
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.
Les étapes nécessaires pour l’exécuter dans une fenêtre DOS sans outils de développement
visuel (uniquement avec le JDK) sont:
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 :
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 Constante2() {
this.constante = 10;
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.
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…
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
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 ;
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 ;
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.
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.
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 ;
}
}
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.
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] ;
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 ;
...
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.
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 :
t1[1] = 5 ;
System.out.println (t2[1]) ;
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.
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) ;
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
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
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 :
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();
}
}
Nous voulons pouvoir stocker des chiens et des chats dans un tableau :
84
M.GBOLOVI Support C.O.O-P.O.O
CHAPITRE 10: LES PACKAGES, LES
INTERFACES ET LES EXCEPTIONS
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
Date String
event Button
Thread
ActionEvent List
ActionEvent
Dans cet exemple :
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.
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.
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
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.
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:
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() ) ;
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() ;
}
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.
void print() ;}
void print() { …
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.
Pour chaque classe nous n'aborderons donc que quelques exemples d'utilisation montrant les
méthodes les plus importantes à connaître.
Compte tenu des possibilités de compatibilité exposées précédemment, une variable de type
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
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.
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).
System.out.println( p1 ) ;
// Affiche : Classe : Personne Objet : Jean Dupond
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" ;
int nombre = 3 ;
String message = "Mon nombre est " + 3 ; // Ici le nombre est converti automatiquement en String
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
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 :
94
M.GBOLOVI Support C.O.O-P.O.O
int capacity() : qui retourne la taille actuelle du tableau interne
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() ;
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 :
96
M.GBOLOVI Support C.O.O-P.O.O
// Soit le conteneur :
Vector vec = new Vector() ;
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
❖ Le type E est définit au moment de la déclaration d’un objet de la classe Pile, exemple
❖ 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
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
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
❖ 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 */
v1.add(elem);
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
• 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)
100
M.GBOLOVI Support C.O.O-P.O.O
III. Communication entre composants
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)
101
M.GBOLOVI Support C.O.O-P.O.O