Les paradigmes de représentation que nous venons d'exposer, permettent de conduire la démarche de développement de façon différente et de pallier dans une large mesure les inconvénients des méthodes classiques.
• La communication entre informaticiens et non-informaticiens est meilleure dans la mesure ou le concept d'objet est plus intuitif. D'autre part, les langages objets sont plus proches des schémas de représentation et permettent de mettre facilement en oeuvre les concepts de l'analyse objet. En d'autres termes, les modèles utilisés pour la description du problème sont très proches des sèmes de programmation.
• L'encapsulation permet de progresser dans la résolution de l'incompatibilité entre structuration des traitements et structuration des données puisqu'un objet en constitue une synthèse. L'approche orientée objet permet de substituer à la dualité données et procédures une structure unique. Toutefois, les schémas de représentation de type données et ceux de type traitements sont toujours utilisés dans les phase d'analyse et de conception. Cependant, le premier souci de l'analyste n'est plus de trouver les fonctionnalités du système, mais d'identifier les objets. Il faut ensuite attribuer les procédures à ceux-ci. Les priorités sont radicalement différentes : On s'appuie sur la structure sous-jacente du domaine d'application plutôt que sur des besoins fonctionnels liés à un seul problème.
• Les phases d'études préliminaires sont raccourcies et la conception se fait par un cycle en spirale au lieu d'un cycle en V. En effet, l'héritage permet de tester facilement un objet avant même de le définir complètement. Pour reprendre l'exemple de la "Peugeot 205", il n'est pas nécessaire de la définir pour modéliser un embouteillage puisque la super-classe 'voiture' suffit. Le temps global consommé par les activités de développement n'est par contre pas plus court en objet : les gains se font par la suite lors des phases de maintenance. D'ailleurs la réversibilité des choix est aisée par l'introduction de nouveaux objets ou l'ajout d'attributs ou de services. Finalement la nature décentralisée de l'architecture objet permet de répartir les décisions tout le long du cycle de développement. Il s'agit plus d'un travail par raffinages successifs qu'un effort de conversion d'une représentation à une autre. On peut parler à ce sujet de processus 'sans rupture'.
Cycle de conception en spirale
Le processus de développement devient itératif plutôt que séquentiel.
On peut comparer ainsi les méthodes de développement classiques et objet.
|
Méthodes classiques |
Méthodes objet |
|
Approche globale |
Approche locale |
|
Cycle de conception en cascade séquentiel |
Cycle de conception en spirale itératif |
|
Problème décomposé en sous-problèmes |
Problème réparti entre un réseau objets |
|
Sous-programmes partageant des données |
Encapsulation, communication par messages |
|
Séparation des données et des traitements |
Pas de séparation |
|
Décisions importantes prises au début du développement |
Décisions réparties au cours du cycle de développement |
