I. Introduction :
D’une manière générale, la construction d’un logiciel est une suite d’itération du genre
« division - réunion ». Il faut « décomposer – diviser » pour comprendre et il faut
« composer - réunir » pour construire. Cela conduit à une situation paradoxale : il faut
diviser pour réunir. Face à ce paradoxe, le processus de décomposition a été dirigé
traditionnellement par un critère fonctionnel. Les fonctions du système sont identifiées,
puis décomposées en sous-fonctions et cela récursivement jusqu’à l’obtention
d’éléments simples directement représentables dans les langages de programmations
(par les fonctions et les procédures).
Fonction
Principale
Sous - Sous -
...
fonction 1 fonction 2
... ...
L’architecture logicielle est alors le reflet des fonctions du système. Cette démarche, apporte
des résultats satisfaisants lorsque les fonctions sont bien identifiées et lorsqu’elles sont bien
stable dans le temps. Toutefois, étant donné que la fonction induit la structure, les évolutions
fonctionnelles peuvent impliquer des modifications structurelles lourdes du fait du couplage
statique entre architecture et fonctions.
L’approche objet considère un système comme une totalité organisée, dont les éléments
solidaires ne peuvent être définis que les uns par rapport aux autres. Elle propose une méthode
de décomposition non pas basée uniquement sur ce que le système fait, mais plutôt sur
l’intégration de ce que le système est et fait.
L’approche objet est basé sur l’utilisation de l’objet en tant qu’abstraction du monde réel. Elle
a pour but une modélisation des propriétés statiques et dynamiques de l’environnement dans
lequel sont définis les besoins. Les fonctions se représentent alors par des formes de
collaboration entre les objets qui composent le système. Le couplage devient dynamique et les
évolutions fonctionnelles ne remettent plus en cause la structure statique du logiciel.
En Conclusion : l’approche objet tire sa force de sa capacité à regrouper ce qui a été séparé, à
construire le complexe à partir de l’élémentaire et surtout à intégrer statiquement et
dynamiquement les constituant d’un système.
Figure 3 - chaque objet contient un état interne qui lui est propre et un comportement accessible aux autres objets
En UML un objet se représente sous la forme d’un rectangle. Le nom de l’objet est souligné.
Remarque : Parfois deux points précèdent le nom inscrit dans le rectangle de l’objet pour
préciser qu’il s’agit d’un objet anonyme.
1.a L’état :
Figure 7- L'état regroupe les valeurs des différents attributs qui caractérisent un objet
Figure 8 – L’état d'un objet à un moment donné est la conséquence des comportements passés
1.b Le comportement :
1.c L’identité :
En plus de son état, un objet possède une identité qui caractérise son existence propre.
L’identité permet de distinguer tout objet de façon non ambiguë et cela indépendamment de
son état. Cela permet de distinguer deux objets dont toutes les valeurs d’attributs sont
identiques.
Figure 10 - Des identités différentes pour des objets ayant des valeurs d'attributs identiques
Lors de l’exécution d’un programme, les objets contribuent solidairement au bon déroulement
de l’application informatique. Le comportement global d’une application repose donc sur la
communication entre les objets qui la composent. L’unité de communication entre les objets
est le message. Les messages sont représentés par des flèches étiquetées, placées le long des
liens qui unissent les objets.
3. Les classes :
Les attributs d’une classe correspondent aux propriétés de la classe. Ils sont définis par
un nom, un type et éventuellement une valeur initiale. Chaque objet, instance d’une
classe donne des valeurs particulières à tous les attributs définis dans sa classe et fixe
par la même son état.
La spécification du comportement d’un objet est définie par les opérations décrites dans sa
classe. Il existe 4 principales catégories d’opérations :
• Le niveau le plus fort appelé niveau « privé ». La partie privée de la classe est
alors totalement opaque et seuls les amis peuvent accéder aux attributs placés
dans la partie privée.
• Certains attributs sont placés dans la partie protégée de la classe ces attributs sont
alors visibles à la fois par les amis et les classes dérivées. Pour toutes les autres
classes les attributs restent invisibles.
• Le niveau le plus faible est obtenu en plaçant les attributs dans la partie publique
de la classe. Dans ce cas les attributs sont visibles pour toutes les classes.
Figure 14 - Précision des niveaux de visibilité dans les représentations graphiques des classes
Exemple :
Les liens entre les universités et les étudiants sont tous instances entre la classe « Université »
et la classe « Etudiant ».