Motivations

Bien avant d’écrire un programme, il faut en définir les composantes et les fonctionnalités. Cette définition passe par plusieurs phases, qui existent aussi bien dans un paradigme orienté objets que dans un paradigme conventionnel. En revanche, les deux philosophies considèrent les choses sous un angle radicalement différent. Alors que dans un cadre conventionnel, on analyse un sous-système par rapport à un ensemble de fonctions, et que l’on définit des algorithmes auxquels on appliquera ultérieurement les données, dans un environnement orienté objets, on définit le catalogue d’objets que comprend le système. Une fois ce catalogue défini, on examine quelles relations doivent exister entre les objets, et quels services doivent offrir chacun de ces objets.
Gardons à l’esprit qu’une conception orientée objets correspond bien plus étroitement à la réalité que les conceptions de type traditionnel : un objet a un cycle de vie “naturel”, il va donc naître, vivre, – et au cours de sa vie, entretenir des relations diverses avec d’autres objets -, puis mourir. La modélisation objets tend à décrire aussi précisément que possible ce cycle de vie.

Aspects de la modélisation

On définit en principe trois aspects dans une modélisation orientée objets :
• Statique : c’est un aspect orienté vers les objets dans le système, et leurs relations mutuelles. Cet aspect peut être décrit à l’aide d’un diagramme d’objets, où les noeuds sont les objets, et les liaisons entre noeuds les relations entre les objets.
• Fonctionnel : il s’agit de la description de l’évolution des données au travers du programme. Un modèle fonctionnel est défini généralement par un diagramme de flux de données.
• Dynamique : C’est la description des aspects du système qui se modifient au cours du temps. Le modèle dynamique contient des diagrammes d’état, dans lequel les noeuds sont des états, et les liaisons des transitions d’un état vers un autre. Les transitions sont induites par des évènements.
Ces divers aspects peuvent se traduire en vues différentes; un même aspect peut aussi donner naissance à des vues différentes dans certains cas.

Quelques règles de base

Quelle que soit la méthode utilisée lors de la définition du modèle, il y a certaines règles de base communes à tout design qu’il est nécessaire de respecter. La première est la définition des relations entre les objets. Ces relations peuvent être de plusieurs types, à la base :
• La contenance , un objet contient un autre objet. Par exemple, une fenêtre affichant un message informatif dans un système à multi-fenêtrage (Open Look, MOTIF, Mac, Windows) contient des boutons Help, Ok, Cancel, etc… Ce type de relation est également appelé relation de type  » has a ». La relation inverse est souvent notée ”is part of”. Ce type de relation est aussi appelé aggrégation.
• L’héritage d’implémentation. On exprime par là que l’objet descendant (qui hérite le comportement) est implémenté sous forme de l’objet ancêtre. Il ne s’agit que d’une relation d’implémentation. Ainsi, une liste de personnes peut être implémentée à l’aide d’un tableau de dimension variable, d’une liste, voire même à l’aide d’ensembles. Il s’agit d’un détail d’implémentation. Le fait que ma liste soit implémentée d’une manière ou d’une autre n’a pas d’incidences sur le contenu informatif et fonctionnel de ma liste. Par contre, le choix peut s’avérer important dans l’optique de la réutilisation de code, ou de facilité de l’implémentation de certaines fonctionnalités (p. ex. accès direct aux personnes par hachage, par recherche binaire, etc…) Ce type de relation est souvent appelé relation de type “is implemented in terms of”. De nombreux auteurs déconseillent l’utilisation de ce type de relation, préférant lui substituer la contenance; il est toutefois possible que certains détails d’implémentation du langage utilisé imposent l’utilisation de l’héritage d’implémentation dans un problème donné (utilisation de membres protégés en C++, par exemple). Certains langages ne permettent pas de définir une telle forme d’héritage (par exemple Java).

Généralisation

Dans un design orienté objets, le premier jet est en général inapproprié. Cela ne signifie pas que le premier jet est faux, mais qu’il ne correspond pas à un modèle optimal. Un modèle optimal est celui qui tire parti au maximum des potentialités du paradigme “orienté objets”.
Ce modèle conduira à une implémentation qui permettra de réutiliser un maximum de composantes au cours de projets futurs.
Si je désire fabriquer une liste d’amis, je peux établir un modèle où figurent, dans chaque objets, les éléments qui m’intéressent, comme adresse privée, numéro de téléphone, nom des enfants, anniversaire, informations sur l’épouse, etc… Si plus tard je veux me fabriquer une liste de relations d’affaires, je ne peux pas, ou malaisément réutiliser le modèle défini précédemment, parce qu’il contient une pléthore d’informations inutiles. Il eût mieux valu définir tout d’abord un modèle de personne générique, et ensuite le spécialiser pour qu’il corresponde à mes besoins. Vraisemblablement, l’implémentation de ma liste d’amis eût été plus complexe, et eut nécessité plus de temps; mais lors de la phase suivante, le gain de temps eût largement compensé la perte initiale.

……..