Conclusion
Méthodes de développements d’applications à objets

Ayant dépassé l’âge de la majorité, les technologies à objets sont largement sorties des laboratoires de recherche. Confrontés aux besoins multiples des développements en entreprise, les langages de programmation — Smalltalk, C++, Eiffel, plus récemment Java — se sont étoffés et diversifiés. Ils se sont transformés en des environnements de développement puissants, au risque parfois de faire oublier la simplicité des principes sous-jacents. Ces outils, et de nouveaux provenant de la pénétration des objets dans les technologies client-serveur, sont non seulement particulièrement efficients pour la construction d’applications interactives, mais permettent de répondre à la plupart des besoins des applications informatiques. De plus, ils savent aujourd’hui dialoguer avec l’informatique existante, particulièrement avec les bases de données relationnelles déjà déployées qui, de leur côté, évoluent vers la prise en compte de types de données complexes proches des objets.

Ces offres technologiques multiples proposent des solutions pour une informatique sans cesse plus hétérogène et plus distribuée dans des réseaux locaux ou globaux. Elles s’appuient sur la métaphore des objets actifs communiquant entre eux et ouvrent des perspectives pour une large (ré)utilisation de composants logiciels. Les bénéfices attendus sont des logiciels de meilleure qualité : correction, robustesse, fiabilité, efficacité, portabilité et extensibilité comme notées par B. Meyer. Ces logiciels sont plus modulaires, présentent un taux plus élevé d’utilisation de modules déjà codés, et disposent avant tout de meilleures capacités d’évolutivité. Celle-ci peut être définie, dans ce contexte, comme la capacité de modifier, de raffiner et d’étendre un ensemble existant de classes en réponse aux changements des besoins utilisateurs ou des contraintes opérationnelles.

Ces nouveaux moyens techniques, aujourd’hui d’un bon niveau de maturité, ne sauraient pourtant suffire à eux seuls pour satisfaire toutes les attentes mises sur les approches à objets. Un système informatique est un artefact, résultat d’une réelle activité constructive. Se pose alors la question des méthodes et des outils permettant de mener à bien et de maîtriser les processus de conception adaptés aux développements à objets.

Comme pour la conception de tout système complexe, apparaît la nécessité de modèles préalables sous forme de schémas et de descriptions allant d’esquisses abstraites à des plans complets. Ces modèles sont les produits des activités prônées dans les méthodes dites d’analyse et de conception objet. L’objectif est d’aider à combler l’écart entre les besoins des utilisateurs du futur système, besoins exprimés sous forme textuelle, et les expressions codées des programmes opérationnels.

Plus récentes que les langages, puisque introduites au milieu des années 1980, les méthodes de développement à objets, du moins les anglo-saxonnes, ont repris la distinction analyse, conception, implémentation, empruntée à différents travaux de génie logiciel qui visaient pourtant une informatique procédurale. L’analyse est, dans cette tradition, concernée principalement par la compréhension du problème à résoudre et par l’élaboration des spécifications fonctionnelles. La conception a pour but de produire les documents d’architecture et les spécifications détaillées du futur système informatique.

Mais, pour l’adapter aux concepts objets, les méthodes à objets amendent cette distinction selon plusieurs points de vue. D’une part, elles voient généralement ces différentes étapes comme des macroactivités n’imposant pas un cycle de vie particulier (cycle en V, W, spirale, etc.), mais pouvant relever de processus variés. Ceux-ci doivent être adaptés aux spécificités de l’application et de l’entreprise concernées. Ces méthodes rejoignent par là les réflexions les plus avancées en génie logiciel. D’autre part, nous verrons que la proposition d’utiliser les concepts objets pour chaque phase (« cycle de vie tout-objet ») implique de repenser aussi bien le contenu de chacune, particulièrement l’analyse, que les processus de transformations entre les différentes étapes. L’utilisation de représentations similaires ou uniformes durant tout le cycle est proposée par presque toutes ces méthodes. Les avantages provenant de cette uniformité sont certains : simplicité, compréhensibilité, réutilisation des prototypes développés, etc. Ils ne doivent néanmoins pas être surestimés au point d’entretenir l’illusion d’un processus linéaire qui relèverait uniquement de règles de transformation automatiques ou, mieux, complètement automatisables. D’autant que le passage progressif à une informatique à base de composants ne peut pas manquer d’avoir des conséquences importantes sur les processus de développement à objets.

Quoi qu’il en soit, de nombreuses méthodes de génie logiciel adaptées aux objets ont été proposées. Elles connaissent encore à cette date des évolutions et des convergences, même si les processus de standardisation sont en bonne voie. Ces méthodes doivent être considérées suivant plusieurs dimensions. D’abord on s’intéressera à l’ensemble des concepts et notations utilisés. Ensuite, ces méthodes doivent proposer un processus pour leur mise en œuvre qui doit inclure l’ensemble de tâches à effectuer avec les produits de chaque étape ainsi que les dépendances entre ces tâches et les différents éléments constituant les modèles produits. Enfin ces méthodes décrivent les aspects organisationnels à considérer pour l’obtention de logiciels de qualité. Malgré certaines lacunes, elles montrent, dans leur diversité, que l’impact des concepts objets dépasse les langages et que c’est l’ensemble du cycle de développement qui est transformé par ces nouvelles approches.

Qu’ils soient formalisés ou non, les résultats des différentes activités des méthodes à objets sont différents modèles construits en vue d’objectifs spécifiques. Dans les phases amont, ces modèles sont plus descriptifs et plus abstraits, avec comme point d’appui une modélisation d’un domaine externe. Dans les phases aval, ils doivent être prescriptifs et opérationnalisables, modèles du système informatique en construction. Les modèles produits doivent être situés par rapport à ces deux nécessités ; suivant l’expression de Marc Linster, on pourra parler de « modélisation pour conférer du sens et de modélisation pour construire un système opérationnel ». Par rapport à ces deux objectifs, les qualités majeures attendues sont différentes. Pour le premier, la compréhensibilité et la capacité de rendre compte du domaine sont prioritaires. Pour le second, la facilité de la transposition en machine est fondamentale. L’ambition des approches objets est de répondre à ces différentes nécessités à partir du même ensemble de concepts, les qualités des phases amont devenant les atouts principaux des phases aval.