STI211 : ALGORITHMIQUE ET STRUCTURES DE DONNEES 3

Termes clés

Processus logiciel : Un processus logiciel est un ensemble

d’activités et de résultats connexes. Lorsque ces activités
sont effectuées dans un ordre spécifique, conformément
aux contraintes, les résultats souhaités sont produits.

Processus de développement logiciel : Un processus de

développement logiciel est souvent décrit comme un
ensemble d’activités nécessaires pour transformer les
besoins d’un utilisateur en un système logiciel.

Approche structurée de développement logiciel :

L’approche structurée permet d’analyser le problème, puis

de concevoir un ensemble de fonctions qui peuvent
effectuer les tâches requises. Si ces fonctions sont trop
importantes, alors elles sont décomposées jusqu’à ce
qu’elles soient assez petites à manipuler et à comprendre.

Approche Orienté objet de développement logiciel : La

stratégie dans le développement de logiciel orienté objet
est de voir le monde comme un ensemble d’objets. Ces
objets interagissent et collaborent les uns avec les autres
pour fournir un comportement de niveau supérieur.

1
 Partie 1. Concepts de base et principes
de l’Orienté-Objet
Introduction

Cette partie vous présente les principes de l’orienté-objet : l’Abstraction, la modularité,

l’encapsulation et les concepts fondamentaux de l’orienté objet : objets, classes, héritage et
polymorphisme. La leçon met l’accent sur les associations et liens : l’association, la composition,
l’agrégation et la généralisation. Elle explique les notions de super classes, de sous classes, et de
multiplicité.

Objectifs

À la fin de cette partie, vous devriez être capable:

• De décrire les concepts fondamentaux de l’orienté-objet.

• D’expliquer les principes de l’orienté-objet.
• De montrer l’utilisation de ces concepts dans la vie courante.

Termes clés

Classe : Une classe est la description d’un ensemble

d’objets ayant une structure commune et disposant des
mêmes méthodes.

Objet : Toute entité identifiable, concrète ou abstraite.

Un objet réagit à certains messages qu’on lui envoie. Un
objet est une instance d’une classe.

L’encapsulation : c’est une technique permettant de

réunir des variables et des fonctions au sein d’une même
entité nommée classe.

L’héritage : cette technique permet de définir une

hiérarchie de classe. Chaque classe fille hérite des
méthodes et des données de ses « pères ».

Le polymorphisme : Par ce principe, deux objets héritant

une même méthode d’une classe parente, peuvent réagir
de façon différente à l’appel de cette méthode.

2
 Leçon 1 – Concepts de base de l’orienté-objet

Présentation

Cette leçon décrira les concepts de base de l’orienté-objet. Nous aborderons les termes
comme : les objets, les classes, l’héritage et le polymorphisme. Nous mettrons l’accent sur les
composantes d’une classe, comment créer une hiérarchie de classe, comment créer des
classes mères et des classes filles et comment donner plusieurs rôles à une même méthode.

1.1 Objets

Toute discussion portant sur l’ingénierie logicielle orientée objet doit commencer en
abordant l’expression « orienté-objet ». Qu’est-ce qu’un point de vue orienté objet ? Dans
quels cas une méthode est considérée comme orientée-objet ? Qu’est-ce qu’un objet ? Tel
que défini par Ojo et Estevez (2005), l’orientation objet porte sur la visualisation et la
modélisation du monde / système comme un ensemble d’objets liés et interagissant entre
eux. Les caractéristiques de l’approche OO sont:
• L’univers est composé d’objets qui interagissent

• Décrire et concevoir des systèmes contenant des objets.

Les objets sont les entités d’exécution de base dans un système orienté objet. Ils peuvent
représenter une personne, un lieu, un compte, une base de données ou un objet que le
programme doit gérer. Ils peuvent également représenter des données définies par
l’utilisateur telles que les vecteurs, le temps et les listes. Un problème de programmation est
analysé en termes d’objets et cette analyse prend en compte la nature de la communication
entre ces objets. Les objets dans un programme doivent être choisis de telle sorte qu’ils
correspondent étroitement avec les objets du monde réel comme le montre la figure 1.5 (Ojo
et Estevez, 2005).

1.5: Exemples d’objets du monde réel (Source : Ojo et Estevez, 2005)

Lorsqu’un programme est exécuté, les objets interagissent en envoyant des messages les uns aux
autres. Par exemple, si « étudiant » et « enseignant » sont deux objets dans un programme, alors
l’objet « étudiant » peut envoyer un message à l’objet « enseignant » pour demander ses notes à un
contrôle. Chaque objet contient des données et des instructions (code) pour manipuler les données.
Les objets peuvent interagir sans connaitre les détails des données ou du code de l’autre.

3
Prenons un exemple d’un objet du monde réel. Chaise est un membre (le terme instance est également
utilisé) d’une plus grande classe d’objets que nous appelons mobilier. Un ensemble d’attributs
génériques peuvent être associés à chaque objet dans la classe mobilier (Par exemple, tout mobilier a
un coût, les dimensions, le poids, l’emplacement et la couleur, parmi beaucoup d’attributs possibles).
Ceci s’applique quand nous parlions d’une table, d’une chaise ou d’un canapé. Etant donné que chaise
est un membre/instance de mobilier, chaise hérite tous les attributs définis pour la classe comme le
montre la figure 1.8. Une fois que la classe a été définie, les attributs peuvent être réutilisés lorsque de
nouvelles instances (objets) de la classe sont créées.

Figure 1.6: Les objets chaise et table sont des mobiliers

Dans le monde réel les objets peuvent être caractérisés par deux choses : leur état et les
traitements qu’ils peuvent subir. Chaque objet du monde réel possède des données et des
comportements. Les données pour un objet sont généralement appelés les attributs de l’objet. Les
différents comportements d’un objet sont appelées les méthodes (ou traitements) de l’objet.

L’état d’un objet est l’ensemble des informations stockées dans l’objet. Il peut changer au fil du
temps. Il change aussi à la suite d’un traitement exécuté sur l’objet. Il ne peut pas changer
spontanément. L’état est encapsulé dans l’objet et n’est pas directement visible. Les différentes
composantes de l’état sont parfois appelés les attributs de l’objet. Un traitement est une procédure

4
 qui, à partir de l’état de l’objet et éventuellement de certains arguments peut changer cet état et /
ou retourner une ou plusieurs valeurs. Les objets permettent certains traitements et pas d’autres.

1.2 Classes

Une classe est un modèle pour la création d’un objet. Une classe est une description d’un ensemble
d’objets connexes qui partagent les mêmes attributs, traitements. Une classe décrit les attributs et
méthodes qui existeront pour toutes les instances de la classe. Une classe est simplement une
description ; elle n’existe pas vraiment en tant que telle jusqu’à ce que vous déclarez une instance de la
classe.

Les objets contiennent des données et du code pour manipuler ces données. L’ensemble des données et le
code d’un objet peut devenir un type de données défini par l’utilisateur lorsqu’il est représenté sous la
forme d’une classe. En fait, les objets sont des variables de type classe. Une fois qu’une classe a été définie,
nous pouvons créer un certain nombre d’objets appartenant à cette classe. Les objets sont créés en utilisant
la définition de la classe comme modèle. Lorsqu’un objet est d’une classe donnée, il est associé aux données
de cette classe. Une classe est donc une collection d’objets du même type. Graphiquement, une classe est
assimilée à un rectangle. Voici un concept important à retenir - la classe que vous créez ne peut rien faire
jusqu’à ce que vous l’utilisiez.

Un nom de classe doit être unique dans son empaquetage. Chaque classe doit avoir un nom qui distingue des
autres classes. Un nom de classe est une chaîne de texte. Ce nom est appelé un nom simple ; un nom de chemin est le
nom de la classe préfixé par le nom du paquet dans lequel évolue cette classe. Une classe peut être représentée ne
montrant que son nom comme le montre la figure 1.7 à titre d’exemples.

Figure 1.7: Exemples de noms de classe

Un attribut est une propriété nommée d’une classe qui décrit une plage de valeurs que les occurrences
de la propriété peuvent détenir. Une classe peut avoir un nombre quelconque d’attributs ou pas
d’attribut du tout. Un attribut représente une propriété de la chose que vous modélisez qui est
partagée par tous les objets de cette classe. Un nom d’attribut peut être du texte. Dans la pratique, un
nom d’attribut est un nom court ou un nom nominal qui représente une propriété de sa classe
englobante. En général, la première lettre de chaque mot dans un nom d’attribut est en majuscule, sauf
la première lettre, comme dans nom ou porte-Bagage

Un traitement est l’implémentation d’un service qui peut faire l’objet d’une requête provenant de
n’importe quel objet de la classe en vue de modifier le comportement de l’objet. En d’autres termes, un
traitement est une abstraction de quelque chose que vous pouvez faire à un objet et qui est commun à

5
 tous les objets de cette classe. Une classe peut avoir un nombre quelconque de traitements ou pas de
traitements du tout. Un nom de traitements peut être du texte. Dans la pratique, un nom de
traitements est un verbe qui représente un comportement de sa classe englobante. En général, la
première lettre de chaque mot dans un nom de traitements est en majuscule, sauf la première lettre,
comme dans déplacer ou estVide. Figure 1.8 montre un exemple d’une classe et d’objets liés.

Figure 1.8: La classe imprimante avec sa liste d’objets (Source: Ojo et Estevez, 2005)

1.3 Héritage

L’héritage est un des concepts clés qui différencient les systèmes conventionnels (structuré) et l’OO.
Une sous-classe Y hérite de tous les attributs et les opérations associées à sa superclasse, X. Cela signifie
que toutes les structures de données et algorithmes à l’origine conçus et mis en œuvre pour X sont
immédiatement disponibles pour Y sans qu’aucune action supplémentaire ne soit requise. Les
structures de données et algorithmes peuvent être réutilisés automatiquement. Toute modification des
données ou des opérations contenues dans une superclasse est immédiatement héritée par toutes les
sous-classes qui ont héritées de la superclasse. Par conséquent, la hiérarchie des classes devient un
mécanisme à partir duquel les modifications (à des niveaux élevés) peuvent être immédiatement
propagées à travers un système.

L’héritage est le processus par lequel les objets d’une classe acquièrent les propriétés des objets d’une
autre classe. Il prend en charge le concept de classification hiérarchique. Par exemple, le petit-fils est
une partie de la classe parent qui est encore une partie de la classe grand-parent. En programmation
orientée objet, le concept d’héritage entraîne l’idée de réutilisation. Cela signifie que nous pouvons
ajouter des fonctionnalités supplémentaires à une classe existante sans la modifier. Ceci est possible en
obtenant une nouvelle classe à partir de celle qui existe.

En C ++, la classe d’origine est appelée une classe de base et la classe qui a acquis les caractéristiques
de la classe de base est appelée classe dérivée. La nouvelle classe aura les caractéristiques combinées
des deux classes. La puissance du mécanisme d’héritage est qu’il permet au programmeur de
réutiliser une classe. Ce qui signifie que l’héritage favorise le partage et la réutilisation des
informations de conception et du code du programme.

1.4 Polymorphisme

Le polymorphisme est un autre concept important de la POO. C’est la capacité pour un objet à prendre

plus d’une forme. Par exemple, un traitement peut avoir un résultat différent selon les cas. Le

6
résultat dépend des types de données utilisés dans le traitement. Par exemple, considérons

l’opération d’addition.

Pour deux nombres, ce traitement va générer une somme si les opérandes sont des chaînes, le traitement
produira une troisième chaîne par concaténation. Cela signifie qu’un seul nom de la fonction peut être
utilisé pour gérer un nombre différent et différents types d’arguments. Ceci est quelque chose de
semblable à un mot particulier ayant plusieurs significations différentes selon le contexte. Les classes
dérivées peuvent redéfinir la mise en œuvre d’une méthode.

Exemple :

Considérez une classe “Transport”

Une méthode appelée déplacer() par exemple, doit être contenue dans la classe Transport parce que
tous les objets de la classe Transport doivent être en mesure de se déplacer

Si nous voulons créer un bateau et une classe de voitures, nous voudrions certainement hériter de la
classe transport, comme tous les bateaux peuvent se déplacer et toutes les voitures peuvent se
déplacer, même si c’est de différentes façons.

Evaluation 1

1. Répondre par Vrai ou faux. Pour celles qui sont fausses, expliquer pourquoi.

2. Stagiaire est un exemple de classe.

3. Dora Cheong est un exemple de classe.

4. createJob est un exemple d’objet.

- Faux : create est un verbe d’action, qui est utilisé pour les opérations

5. deleteFile est un exemple d’opération

- Vrai

6. prénom est un attribut

7. Supposons que nous voulons modéliser une demande de délivrance de certificats

d’enregistrement d’affaires Identifiées :

8. Définir trois classes pour le modèle.

9. Définir au moins trois attributs pour chaque classe

1.5 Associations et liens

Une classe n’a pas d’utilité en elle-même. Un logiciel avec de nombreuses fonctionnalités peut avoir des
milliers de classes. Les objets des différentes classes doivent être liés les uns aux autres, interagir et de
collaborer pour mener à bien les processus. Les relations entre les objets (connus sous le nom des
associations) sont représentées par des lignes reliant les objets.
L’association exprime les relations entre les classes et définit les liens entre les instances de la classe
(objets). Un lien exprime une relation entre les objets. Il existe quatre types de relations entre les
classes: Association, Agrégation, Composition, Généralisation.
7
 1.5.1 Association
C’est la relation la plus simple entre les classes. C’est une relation d’égal à égal. C’est une relation
structurelle décrivant un ensemble de liens. Les liens sont des connexions entre les objets. Les liens
sont implémentés dans les objets en utilisant des références. Une association est une relation entre
deux ou plusieurs classes et implique une connexion entre les instances. Les associations entre les
classes A et B peuvent être :

1. A est une partie physique ou logique de B

A est semblable à B

2. A est contenue dans B

3. A est une description de B

4. A est un élément de B

5. A est une sous-unité B

6. A utilise ou gère B

7. A communique avec B

8. A suit B

9. A appartient à B

Exemple: Personne travaille pour Société

1.5.2 Agrégation

Une agrégation est une association qui représente une relation d’inclusion structurelle ou
comportementale d’un élément dans un ensemble. Les objets sont rassemblés pour créer un objet plus
complexe. Ce rassemblement peut être physique ou logique. L’agrégation définit un point de contrôle
unique pour les objets qui y participent. L’objet issu de l’agrégation gère les différents objets qui
composent l’agrégation. L’agrégation est représentée comme un diamant creux, pointant à la classe qui
est utilisée.

Exemple 1: Un processeur fait partie d’un ordinateur. CPU, périphériques, moniteur et le clavier sont
assemblés pour créer un ordinateur

Figure 1.9: Liens d’agréation entre un ordinateur est ses composantes ou périphériques

Exemple 2 : Un moteur fait partie d’une voiture

Figure 1.10: Liens d’agréation entre un moteur est un

véhicule
 1.5.3 Composition

La composition est une agrégation composite. La durée de vie des objets individuels dépend de la durée de
vie de l’objet global. Aucune partie de la composition ne peut exister par elle-même. Une classe composite
est construite à partir d’autres classes. La classe a besoin d’une ou de plusieurs autres classes pour exister.
La composition est représentée par un diamant solide

Exemple:

Un mot ne peut pas exister si il ne fait pas partie d’une ligne. Si un paragraphe est supprimé, toutes les
lignes de l’alinéa sont supprimées, et tous les mots appartenant à ces lignes sont supprimés. Si un
document est supprimé, tous les paragraphes le composant disparaissent.

Figure 1.11: Liens d’agréation de composition

1.5.4 Héritage ou Généralisation

La généralisation est aussi appelé relation “d’héritage”. Une généralisation est la relation entre une
classe générale et une ou des classes plus spécialisées. Dans une relation de généralisation, les
spécialisations sont appelées sous-classe et la classe généralisée est appelée la superclasse. Une
généralisation permet l’héritage des attributs et des opérations d’une superclasse par ses sous-classes.

C’est équivalent à une relation : « genre de » or « type de ».

L’héritage ou la généralisation est décrite comme une relation parent / enfant, où une classe enfant
hérite de tous les attributs et méthodes d’une classe, et ajoute ses propres attributs et méthodes pour
créer un nouveau comportement. L’héritage est représenté comme une flèche triangulaire creuse,
dirigée vers la classe parente.

1.5.5 Super classe et Sous classe

Une super-classe est une classe qui contient les caractéristiques communes à deux ou plusieurs classes. Une
super classe est similaire à un sur-ensemble, par exemple, personnel-agence. Une sous-classe est une classe

9
qui contient au moins les attributs et méthodes de sa (ses) superclasse(s). Une classe peut être une sous-
classe et une super classe en même temps.

Figure 1.10: Exemple de lien d’héritage

1.5.6 Multiplicité

La multiplicité montre le nombre d’objets d’une classe pouvant être associés à un objet d’une autre
classe. Exemple: Un citoyen peut demander une ou plusieurs licences, et une licence est requise par un
citoyen.

Figure 1.11: Exemple de super classe et sous classe

Figure 1.12: Exemple de multiplicité entre deux classes

Figure 1.12: Exemple de la multiplicité

Conclusion

Comme l’a déclaré Liu, (2001), le but d’une association et d’un lien entre deux objets est d’établir
diverses sortes de relation, et donc des classes peuvent avoir toutes sortes d’associations dans un
domaine d’étude. Les objectifs que doit remplir toute association sont les suivants :
• Une association entre deux classes doit fournir des connexions physiques ou
conceptuelles entre les objets de ces classes.

10
 • Seuls les objets qui sont associés entre eux peuvent collaborer les uns avec les autres à
travers les liens.

• Booch décrit le rôle d’une liaison entre les objets de la manière suivante :

• “Un lien représente l’association spécifique par lequel un objet (le client) applique les
services d’un autre objet (le fournisseur), ou par lequel un objet peut accéder à un
autre”.

Evaluation 2

1. Ces affirmations sont-elles vraies ou fausses ? Pour celles qui sont fausses, expliquer
pourquoi.

i. Il existe une association entre Stagiaire et Cours

ii. Il y a une composition entre Cours et Professeur.
iii. Il existe une agrégation entre Cours et Lieu
- Faux

2. Supposons que nous voulons modéliser une application e-service pour un organisme
gouvernemental. Est-ce que ce schéma modélise raisonnablement la relation entre les entités
Utilisateur, Employé, EmployéServiceClientèle, EmployéServiceAdministratif, et Demandeur?
Si non, proposez un modèle plus approprié.

3. Ajouter une généralisation pour les classes définies dans l’évaluation 1.3.6 (2)

i. Identifier la super-classe et une sous-classe.

ii. Y a-t-il une classe abstraite ? Justifier.
iii. Quel facteur d’élimination est utilisé dans votre hiérarchie de généralisation ?
- Notion d’héritage

4. Considérons la hiérarchie de généralisation prévue dans l’évaluation 3 ci-dessus.

i. Ajouter une opération à la super classe qui pourrait être implémentée de différentes
manières par ses sous-classes.

ii. Donner un exemple de polymorphisme. Expliquez.

11
 Leçon 2 : Principes de l’orienté-objet

Présentation

Cette leçon décrit les principes fondamentaux de l’orientée- objet que vous devez comprendre et qui
serviront de tremplin pour le reste de l’unité.

1. Séparation des responsabilités (modularité)

Le principe de séparation des responsabilités (separation of concerns) vise à organiser un logiciel en plusieurs
sous-parties, chacune ayant une responsabilité bien définie.
C'est sans doute le principe de conception le plus essentiel. Ainsi construite de manière modulaire,
l'application sera plus facile à comprendre et à faire évoluer. Au moment où un nouveau besoin se fera sentir,
il suffira d'intervenir sur la ou les sous-partie(s) concernée(s). Le reste de l'application sera inchangée : cela
limite les tests à effectuer et le risque d'erreur. Une construction modulaire encourage également la
réutilisation de certaines parties de l'application.

En d’autres termes, la modularité porte sur le processus de décomposition des systèmes complexes en de
petits morceaux, plus autonomes qui peuvent être gérés facilement. La modularité peut être effectuée en:
• Décomposant le problème en de plus petits sous-problèmes

• Essayant de résoudre chaque sous-problème séparément. Chaque solution est un

composant séparé qui comprend :

- Une Interface : types et opérations accessibles de l’extérieur

- Une Spécification : fonctionnement et propriété bien définis de l’interface

- Une implémentation : structures de données et fonctions cachées de l’extérieur

La figure ci-après est un exemple de modularité.

Figure : Système de traitement de commandes

2. Couplage faible
La définition du couplage est la suivante : "une entité (sous-partie, composant, classe, méthode) est couplée à
une autre si elle dépend d'elle", autrement dit, si elle a besoin d'elle pour fonctionner. Plus une classe ou une
méthode utilise d'autres classes comme classes de base, attributs, paramètres ou variables locales, plus son
couplage avec ces classes augmente.

12
Au sein d'une application, un couplage fort tisse entre ses éléments des liens puissants qui la rend plus rigide à
toute modification (on parle de "code spaghetti"). A l'inverse, un couplage faible permet une grande souplesse de
mise à jour. Un élément peut être modifié (exemple : changement de la signature d'une méthode publique) en
limitant ses impacts.
Le couplage peut également désigner une dépendance envers une technologie ou un élément extérieur
spécifique : un SGBD, un composant logiciel, etc.
Le principe de responsabilité unique permet de limiter le couplage au sein de l'application : chaque sous-partie a
un rôle précis et n'a que des interactions limitées avec les autres sous-parties. Pour aller plus loin, il faut limiter le
nombre de paramètres des méthodes et utiliser des classes abstraites ou des interfaces plutôt que des
implémentations spécifiques ("Program to interfaces, not to implementations").

3. Cohésion forte
Ce principe recommande de placer ensemble des éléments (composants, classes, méthodes) ayant des rôles
similaires ou dédiés à une même problématique. Inversement, il déconseille de rassembler des éléments ayant
des rôles différents.
Exemple : ajouter une méthode de calcul métier au sein d'un composant lié aux données (ou à la présentation)
est contraire au principe de cohésion forte.

4. Abstraction

L’abstraction est un modèle qui prend en compte les aspects les plus importants d’un système donné,
tout en ignorant les détails les moins importants. L’abstraction implique un savoir-faire qui consiste à
prendre en compte l’essentiel et à ignorer ce qui ne l’est pas. L’orienté objet est une bonne abstraction
du monde réel ; cela signifie que si le problème change (à savoir les exigences changent, comme c’est
presque toujours le cas), la solution devrait être plus facile à modifier. Ojo and Estevez, (2005) indique
que l’abstraction est le processus permettant de se concentrer sur les aspects les plus importants, tout
en ignorant les détails moins importants. Elle permet la gestion de la complexité, en se concentrant sur
les caractéristiques essentielles qui font qu’une entité diffère des autres. La figure 1.1 montre un
exemple d’abstraction du traitement de commandes.

Figure 1.1: Exemple d’abstraction du traitement de

commandes (Source: Ojo et Estevez, 2005)

5. Encapsulation
L’encapsulation permet de définir des niveaux de visibilité des éléments de la classe. Ces niveaux de visibilité
définissent les droits d'accès aux données selon que l'on y accède par une méthode de la classe elle-même, d'une
classe héritière, ou bien d'une classe quelconque. Il existe trois niveaux de visibilité:
 Publique: les fonctions de toutes les classes peuvent accéder aux données ou aux méthodes
d'une classe définie avec le niveau de visibilité public. Il s'agit du plus bas niveau de protection des
données
 protégée: l'accès aux données est réservé aux fonctions des classes héritières, c'est-à-dire par
les fonctions membres de la classe ainsi que des classes dérivées
 Privée: l'accès aux données est limité aux méthodes de la classe elle-même. Il s'agit du niveau
de protection des données le plus élevé.

13
Il est recommandé d’avoir une encapsulation forte c’est à dire de n'exposer au reste de l'application que le strict
nécessaire pour que la sous-partie joue son rôle. Au niveau d'une classe, cela consiste à ne donner le niveau
d'accessibilité publique qu'à un nombre minimal de membres, qui seront le plus souvent des méthodes. Au
niveau d'une sous-partie d'application composée de plusieurs classes, cela consiste à rendre certaines classes
privées afin d'interdire leur utilisation par le reste de l'application.
En d’autre terme, l’encapsulation, autorise uniquement l’instance qui possède un membre donné à le modifier
ou à y accéder. L’objet chaise (et tous les objets en général) encapsule les données (les valeurs d’attributs qui
définissent la chaise), les opérations (les actions qui sont chargées de modifier les attributs de la chaise), d’autres
objets (des objets composites peuvent être définis), les constantes (valeurs fixes), et d’autres renseignements
connexes. L’encapsulation signifie que l’ensemble de ces informations est empaqueté sous un nom et peut être
réutilisé comme une spécification ou un composant d’un programme. En d’autres termes, l’encapsulation cache
l’implémentation aux utilisateurs et aux clients (Ojo and Estevez, 2005). Les Clients dépendent des interfaces
comme le montre la figure 1.2 par exemple.

Figure 1.2: Exemples d’interfaces Client (Source: Ojo et Estevez, 2005)

Les exigences de l’encapsulation impliquent :

• D’exposer le but d’un objet

• D’exposer les interfaces d’un objet

• De masquer l’implémentation qui définit le fonctionnement de l’objet en rendant

accessible seulement les interfaces

• De masquer les données appartenant à un objet qui définissent sa structure et son

comportement

• De masquer les données appartenant à un objet et qui permettent de suivre l’état de

l’objet. Les avantages de l’encapsulation sont :

• Faciliter la séparation d’une interface de son implémentation, de sorte qu’une seule

interface puisse avoir plusieurs implémentations.

• Faire en sorte que les données contenues dans un objet ne puissent pas être altérées par
d’autres objets.

6. Hiérarchie

La hiérarchie est un arrangement des classes dans une structure arborescente. Dans cette hiérarchie,
un système complexe est composé de sous-systèmes interdépendants qui ont à leur tour leurs
propres sous-systèmes, et ainsi de suite, jusqu’à ce que le plus bas niveau de composants

14
 élémentaires soit atteint. Figure 1.4 montre un exemple du principe de la hiérarchie dans la
programmation orienté objet.

Figure 1.4: Exemple de la Hiérarchie

7. La méthode de conception OOD simplifiée

La méthode O.O.D (object oriented design) de G.Booch propose 5 étapes dans l’établissement
d’une conception orientée objet. Ces étapes n’ont pas obligatoirement à être enchaînées dans
l’ordre dans lequel nous les citons dans le paragraphe suivant. C’est cette souplesse qui nous a
fait choisir la démarche de G.Booch, car cette méthode est fondamentalement incrémentale et
n’impose pas un cadre trop précis et trop rigide dans son application. Cette démarche se révèle
être utile pour un débutant et lui permettra de fabriquer en particulier des prototypes avec efficacité
sans trop surcharger sa mémoire.

Identifier les objets et leurs attributs :

On cherchera à identifier les objets du monde réel que l’on voudra réaliser.

Conseil : Il faut identifier les propriétés caractéristiques de l’objet (par l’expérience,

l’intuition, ...). On pourra s’aider d’une description textuelle (en langage naturel) du
problème. La lecture de cette prose aidera à déduire les bons candidats pour les
noms à utiliser dans cette description ainsi que les propriétés des adjectifs et des
autres qualifiants.

Identifier les opérations :

On cherchera ensuite à identifier les actions que l’objet subit de la part de son
environnement et qu’il provoque sur son environnement.

Conseil : Les verbes utilisés dans la description informelle (textuelle) fournissent de

bons indices pour l’identification des opérations. Si nécessaire, c’est à cette étape
que l’on pourra définir les conditions d’ordonnancement temporel des opérations (les
événements ayant lieu).

Etablir la visibilité :

L’objet étant maintenant identifié par ses caractéristiques et ses opérations, on

définira ses relations avec les autres objets.

15
 Conseil : On établira quels objets le voient et quels objets sont vus par lui (les
spécialistes disent alors qu’on insère l’objet dans la topologie du projet). Il faudra
prendre bien soin de définir ce qui est visible ou non, quitte à y revenir plus tard si un
choix s’est révélé ne pas être judicieux.

Etablir l’interface :

Dès que la visibilité est acquise, on définit l’interface précise de l’objet avec le monde
extérieur.

Conseil : Cette interface définit exactement quelles fonctionnalités sont accessibles

et sous quelles formes.

Implémenter les objets :

La dernière étape consiste à implanter les objets en écrivant le code dans un langage
de votre choix.

Conseil : Cette étape peut donner lieu à la création de nouvelles classes

correspondant par exemple à des nécessités d’implantation. Lors de cette étape, on
identifiera éventuellement de nouveaux objets de plus bas niveau d’abstraction qui ne
pouvaient pas être analysés en première lecture (ceci provoquant l’itération de la
méthode à ces niveaux plus bas).

Conclusion

Cette leçon a mis l’accent sur les principes fondamentaux de l’orientée-objet. Ces principes concernent
l’abstraction, l’encapsulation, la modularité et la hiérarchie.

Evaluation

1. Quelle est la différence entre un objet et une classe ?

2. Quels sont les quatre principes de base l’orienté objet ? Fournir une brève description de
chaque principe.

Résumé de la partie

Un objet est toute abstraction qui modélise quelque chose dans l’univers ayant des propriétés et des
comportements. Une classe est une abstraction d’un ensemble d’objets liés logiquement ayant des
caractéristiques semblables. Les classes peuvent être liées par les types de relations suivantes :
association, agrégation, composition, héritage ou généralisation. Les concepts de l’orienté objet

16
comprennent : les objets, les classes, l’héritage et le polymorphisme. La POO est caractérisée par
quatre principes fondamentaux : l’abstraction, encapsulation, la modularité et la hiérarchie. Cela peut
être considéré comme un critère pour déterminer si deux objets doivent être liés. La maîtrise de ces
concepts et principes permet de se doter d’outils méthodologiques rationalisant l’effort de production
du logiciel, sans que leur lourdeur rebute l’étudiant non professionnel et masque ainsi l’intérêt de leur
utilisation.

Évaluation de la partie 1

1. Définissez les termes suivants:

- Abstraction (1 point)
- Polymorphisme (1 point)
- Instanciation : (1 point)

2. - Expliquer l’importance de la modélisation dans le développement de systèmes logiciels

OO.
* Séparer le travail en plusieurs parties
* visualiser le système avant son implémentation
- Donnez des exemples concrets si nécessaire (3 points)

3. La modularité est un aspect important dans le développement de logiciels. Il permet le

partitionnement de la conception de logiciels en morceaux qui sont regroupés ou séparés.
Pourquoi est-il important d’adopter une approche modulaire pour le développement de
logiciels ? (2 points)
-

4. Le masquage d’information exprime l’idée qu’un module cache certains aspects de son
fonctionnement interne à d’autres modules. (2 points)
5. Quel autre terme (unique) désigne le masquage d’information
 Encapsulation (critiquée)
6. Pourquoi le masquage d’information est-il important ?

Lectures et autres ressources

• Ariadne Training (2001), “UML Applied Object Oriented Analysis and Design Using the
UML”, Ariadne Training Limited

• Liu Z., (2001), “Object-Oriented Software Development Using UML”, The United Nations
University, UNU-IIST International Institute for Software Technology, Tech Report 229.

• Ojo A. and Estevez E., (2005), “Object-Oriented Analysis and Design with UML”, Training
Course, The United Nations University, UNU-IIST International Institute for Software
Technology, e-Macao Report 19, Version 1.0, October.

• Pascal Roques, UML 2 par la pratique: Etudes de cas et exercices corrigés,

5ème édition, Eyrolles

17
• Fien Van der Heyde, Laurent Debrauwer, UML 2 : Initiation, exemples et exercices
corrigés, Eni.

• Benoît Charroux, Aomar Osmani, Yann Thierry-Mieg, “UML 2”, collection Synthex
, Pearson Education , 3ème édition, 2010

• Sommerville Ian (2000), “Software Engineering (6th Edition)”. Addison-Wesley, Boston

USA

18