Cours d’Ingénierie du Logiciel

Chapitre 3. Approche Orientée Objet et UML

3.1. Introduction

Deux types de motivation orientent actuellement les concepteurs dans le choix

des méthodes de conception : la possibilité de prendre en compte des
applications et des systèmes de plus en plus complexes et le souci de diminuer
les coûts de réalisation et de maintenance. Avec l’ère des nouvelles technologies,
des réseaux informatiques et systèmes répartis, les applications ont atteint elles
aussi un niveau de complexité croissant et de ce fait, elles nécessitent à l’heure
actuelle, des outils de programmation sophistiqués. On constate que les
applications dites technique, telles que la CAO, la cartographie, les systèmes de
contrôle temps réel, le CoDesign, représentent une activité croissante et
nécessitent une plus grande participation des personnes aussi bien pour l'effort
de conception et validation que de maintenance et d'évolution.

Ces constats ont mis en évidence la nécessité de promouvoir l’abstraction de

données, la modularité et la réutilisabilité des composants fabriqués.

Ainsi, beaucoup de méthodes ont vu le jour, chacune tentant à sa manière

d’apporter une solution satisfaisante et parmi elles, les méthodes objets
(orientées objet) et leurs techniques d’analyse et de conception appropriées.

Pourquoi parler de Programmation Orientée Objets (POO) ?

La complexité et la taille des projets nécessitent des outils de programmation
nombreux et perfectionnés pour mener à bien les applications dans les meilleurs
délais.

En fait, les langages à objets connaissent un succès grandissant, aussi bien dans
le domaine de l’Intelligence Artificielle (IA) que dans celui du Génie Logiciel ou

Elvis Noël IRAMBONA, MSc. 1

Cours d’Ingénierie du Logiciel

des BD, car ils constituent sans doute la solution la plus souple et offre plus de
perspectives pour répondre à ces différents besoins.

3.2. Les concepts de base

Un objet est une abstraction d'une donnée du monde réel caractérisée ainsi :

Objet = identité + état + comportement

L'identité d'un objet est représentée par un identifiant (object identifier ou OID)
unique et invariant qui permet de référencer l'objet indépendamment des
autres objets. L'état d'un objet est une valeur qui peut être simple, par exemple,
un littéral, ou structurée, par exemple, une liste. Dans le dernier cas, l’état peut
être composé de valeurs simples, de références à d'autres objets, ou de valeurs
elles-mêmes structurées. Le comportement d'un objet est défini par un
ensemble d'opérations applicables à l'objet et définies dans sa classe
d'appartenance. En résumé, nous avons la définition suivante :

Objet: abstraction d'une donnée caractérisée par un identifiant unique et

invariant, un état représenté par une valeur simple ou structurée, et une classe
d'appartenance.

L'identité et l'égalité de deux objets sont deux notions différentes. Deux objets
o1 et o2 sont identiques si leurs identifiants sont égaux (o1==o2). Deux objets
o1 et o2 sont égaux si leurs états sont égaux (o1=o2). Donc nous avons

(o1==o2)(o1=o2).

L’univers devient donc une structure composée d’ensemble d’objets.

Les types d'objets seront des classes, et les objets (instances) seront considérés
comme représentants de classes.

Elvis Noël IRAMBONA, MSc. 2

Cours d’Ingénierie du Logiciel

Exemple:

Figure : Exemple de représentation d'un objet d'une classe

Les principes énoncés plus haut offrent des qualités pour mettre en œuvre des
méthodes rigoureuses. Ainsi, on doit retrouver dans une approche objet au
moins 4 principes obligatoires : abstraction, encapsulation, modularité,
hiérarchie ; auxquels on peut ajouter 3 principes complémentaires : typage,
simultanéité, persistance.

Abstraction (définition d’une classe)

L’abstraction est le processus qui consiste à représenter des objets qui
appartiennent au monde réel dans le monde du programme que l’on écrit. Il
consiste essentiellement à extraire des variables pertinentes, attachées aux
objets que l’on souhaite manipuler, et à les placer dans un modèle informatique
convenable.

Encapsulation
La première étape du travail de conception a consisté à définir les données
intéressantes, et à les regrouper dans des structures qui ont un sens. La
deuxième étape consiste à définir les méthodes d’accès à ces données, et les
calculs qui seront effectués dessus. L’idée de la programmation objet est de

Elvis Noël IRAMBONA, MSc. 3

Cours d’Ingénierie du Logiciel

regrouper ces méthodes d’accès et de calcul dans la même structure que les
données.

Le regroupement des données et des méthodes est un des points importants des
langages objet, qui n’est absolument pas supporté dans des langages tels que le
C, Pascal ou Fortran. C’est cela que l’on appelle l’encapsulation.

Modularité
La modularité est la propriété d’un système décomposé en ensemble de
modules cohérents faiblement couplés.

La modularité suppose également la modificabilité : les objets sont faciles à

changer.

Hiérarchie (héritage)
L'héritage (en anglais inheritance) est un principe propre à la programmation
orientée objet, permettant de créer une nouvelle classe à partir d'une classe
existante. Le nom d'"héritage" (pouvant parfois être appelé dérivation de classe)
provient du fait que la classe dérivée (la classe nouvellement créée) contient les
attributs et les méthodes de sa superclasse (la classe dont elle dérive). L'intérêt
majeur de l'héritage est de pouvoir définir de nouveaux attributs et de nouvelles
méthodes pour la classe dérivée, qui viennent s'ajouter à ceux et celles héritées.

Par ce moyen on crée une hiérarchie de classes de plus en plus spécialisées. Cela
a comme avantage majeur de ne pas avoir à repartir de zéro lorsque l'on veut
spécialiser une classe existante.

Le typage
Dans la programmation par objets, chaque objet est typé. Le type définit la
syntaxe (« Comment l'appeler ? ») et la sémantique (« Que fait-il ? ») des
messages auxquels peut répondre un objet. Il correspond donc, à peu de chose

Elvis Noël IRAMBONA, MSc. 4

Cours d’Ingénierie du Logiciel

près, à l'interface de l'objet. Toutefois, la plupart des langages objets ne

proposent que la définition syntaxique d'un type (C++, Java, C#…) et rares sont
ceux qui fournissent aussi la possibilité de définir aussi sa sémantique (Eiffel).

Un objet peut appartenir à plus d'un type : c'est le polymorphisme ; cela permet
d'utiliser des objets de types différents là où est attendu un objet d'un certain
type. Une façon de réaliser le polymorphisme est le sous-typage (appelé aussi
héritage de type)

Simultanéité
Deux objets différents doivent pouvoir agir en même temps et à des endroits
différents (soit sur la même machine, soit sur des machines différentes,…).

Persistance
Ceci concerne la durée de vie d’un objet (important dans les BD, ou les données
sont disponibles pendant longtemps).

3.3. Cycle de vie

Le cycle de vie d’un logiciel est généralement proche de l’incrémental (par

opposition au cycle itératif classique). Les étapes de spécification sont :
- étude du vocabulaire du projet : noms, verbes, objets, …
- identification des objets physiques.
- Formalisation d’un modèle (liens, communication, …)

Figure : Cycle de vie spécifique

Elvis Noël IRAMBONA, MSc. 5

Cours d’Ingénierie du Logiciel

Rappel de quelques définitions

Analyse : Partant de la spécification du problème, l'analyste construit un modèle
du monde réel mettant en évidence les propriétés importantes. Le modèle
d'analyse est une abstraction précise et concise du but de l'application et non de
la façon dont elle sera bâtie.

Conception du système : Le concepteur du système prend des décisions de haut

niveau sur l'architecture d'ensemble du système. Pendant cette phase, le
système cible est découpé en sous-systèmes fondés à la fois sur la structure de
l'analyse et sur l'architecture proposée. Le concepteur du système doit décider
quelles sont les caractéristiques de performances du système à optimiser.

Conception des objets : Le modèle de conception objet s'appuie sur le modèle

d'analyse mais contient des détails d'implémentation.

Implémentation : Les classes d'objets et leurs relations développées durant la

phase de conception des objets sont finalement traduites dans un langage de
programmation.

3.4. Les « modèles »

Les langages de modélisation (à l’instar de UML) permettent de représenter une

conception orientée objet. Les modèles (« patterns ») s’intéressent quant à eux
aux résultats du processus et fournissent des exemples.
Dans plusieurs cas, les projets rencontrent des problèmes parce que leurs
responsables ne maîtrisent pas des méthodes bien connues des concepteurs
expérimentés.

Les modèles décrivent des façons de procéder courantes. Les modèles de

conception décrivent des techniques de conception. Ils sont recueillis par des

Elvis Noël IRAMBONA, MSc. 6

Cours d’Ingénierie du Logiciel

personnes qui repèrent les thèmes récurrents de la conception. Ces personnes

examinent chaque thème et le décrivent pour que d’autres puissent étudier le
modèle et voir comment l’appliquer.

3.5. Le langage UML

La première moitié des années 90 a vu fleurir une cinquantaine de méthodes

objets. L'examen des méthodes dominantes a permis de dégager un consensus
autour d'idées communes. Les grands traits des objets, repris par de nombreuses
méthodes, s'articulent autour des notions de classe, d'association (James
Rumbaugh), de partition en sous-systèmes (Grady Booch) et autour de
l'expression des besoins à partir de l'étude de l'interaction entre l'utilisateur et
le système (les use cases d'Ivar Jacobson). En 1994, on recensait plus de 50
méthodologies orientées objets. C’est dans le but de remédier à cette dispersion
que les « poids-lourds » de la méthodologie orientée objets ont entrepris de se
regrouper autour d’un standard. Partant de la constatation que les différences
entre les méthodes s'amenuisent et que la « guerre » des méthodes ne fait plus
progresser la technologie objet, en octobre 1994, Grady Booch et James
Rumbaugh se sont réunis au sein de la société RATIONAL dans le but de travailler
à l’élaboration d’une méthode commune qui intègre les avantages de l’ensemble
des méthodes reconnues, en corrigeant les défauts et en comblant les déficits.
Ils unifier leurs travaux au sein d'une méthode unique : la méthode unifiée (The
Unified Method). Une année plus tard, ils sont rejoints par Ivar Jacobson.

Ces trois chercheurs se sont fixé quatre objectifs :

 Représenter des systèmes entiers (au-delà du seul logiciel) par des
concepts objets

Elvis Noël IRAMBONA, MSc. 7

Cours d’Ingénierie du Logiciel

 Etablir un couplage explicite entre les concepts et les artefacts

(phénomène/structure virtuelle dont l’apparition est liée à une
expérience/un cas)
 Prendre en compte les facteurs d'échelle inhérents aux systèmes
complexes et critiques.
 Créer un langage de modélisation à la fois par les humains et les machines.

Depuis 1996, ces objectifs sont quasiment atteints. La méthode unifiée est
devenue plutôt le langage UML.

UML est un élément de base dans la stratégie de plusieurs entreprises. Un

ensemble de partenaires réunis au sein de l'OMG [Object Management Group]
(regroupant notamment IBM, Microsoft, Oracle, DEC, HP, Rational, Unisys, etc.),
travaille pour la description d'UML version améliorée.

UML n'est pas un standard de fait mais un standard « industriel » de l'OMG

(novembre 1997) au même titre que CORBA par exemple. Ceci étant, vu le succès
initial de ce langage, il commence à devenir un « standard de fait ».

Evolution des versions d’UML

Tableau : Historique de l’Evolution des versions d’UML

Elvis Noël IRAMBONA, MSc. 8

Cours d’Ingénierie du Logiciel

3.6. Conclusion

L'idée majeure qui préside dans le concept objet consiste à conserver la même
philosophie depuis l'analyse des besoins à partir du monde réel, la spécification
jusqu'à sa réalisation, en l'occurrence celle des objets.

Pour conclure ce chapitre, nous pouvons donner quelques recommandations,

qui s’avèrent nécessaires si l’on souhaite concevoir un système par objets :

 « Savoir revenir aux étapes précédentes », car il arrive rarement que les
classes principales soient trouvées avec exactitude, dès la première étape
du processus, surtout qu’à côté des classes principales, des classes
auxiliaires dues à la programmation, viennent se greffer. Ces classes
doivent être introduites naturellement en revenant à la première étape.
 « Prototyper rapidement avant de passer à une spécification complète
», car il faut passer très rapidement à une première ébauche du logiciel,
qui permettra de spécifier le logiciel. Mais attention à une
programmation sans spécification.
 « Penser abstrait », car la conception par objets permet de définir des
modèles du monde réel par abstraction des classes et des opérations
indépendantes de la nature des objets manipulés.
 Et enfin, « penser local », en ne cherchant pas à structurer globalement
l’ensemble du système, mais en définissant des opérations de portée
locale.

Elvis Noël IRAMBONA, MSc. 9