| Réf : H3228 v1

Processus de développement
Méthodes de développements d’applications à objets

Auteur(s) : Philippe LAUBLET

Date de publication : 10 août 1998

Pour explorer cet article
Télécharger l'extrait gratuit

Vous êtes déjà abonné ?Connectez-vous !

Sommaire

Présentation

Auteur(s)

  • Philippe LAUBLET : Maître de conférences à l’université de Paris-Sorbonne (Paris IV) - Ancien maître de recherches à l’Office national d’études et de recherches aérospatiales (ONERA)

Lire cet article issu d'une ressource documentaire complète, actualisée et validée par des comités scientifiques.

Lire l’article

INTRODUCTION

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.

Nota :

pour de plus amples détails sur les travaux des auteurs cités dans cette introduction, on pourra se reporter aux références .

Cet article est réservé aux abonnés.
Il vous reste 95% à découvrir.

Pour explorer cet article
Téléchargez l'extrait gratuit

Vous êtes déjà abonné ?Connectez-vous !


L'expertise technique et scientifique de référence

La plus importante ressource documentaire technique et scientifique en langue française, avec + de 1 200 auteurs et 100 conseillers scientifiques.
+ de 10 000 articles et 1 000 fiches pratiques opérationnelles, + de 800 articles nouveaux ou mis à jours chaque année.
De la conception au prototypage, jusqu'à l'industrialisation, la référence pour sécuriser le développement de vos projets industriels.

DOI (Digital Object Identifier)

https://doi.org/10.51257/a-v1-h3228


Cet article fait partie de l’offre

Technologies logicielles Architectures des systèmes

(233 articles en ce moment)

Cette offre vous donne accès à :

Une base complète d’articles

Actualisée et enrichie d’articles validés par nos comités scientifiques

Des services

Un ensemble d'outils exclusifs en complément des ressources

Un Parcours Pratique

Opérationnel et didactique, pour garantir l'acquisition des compétences transverses

Doc & Quiz

Des articles interactifs avec des quiz, pour une lecture constructive

ABONNEZ-VOUS

Lecture en cours
Présentation

3. Processus de développement

3.1 Produits et processus

Le choix ou l’élaboration d’un processus de développement, pour une entreprise donnée, a pour but d’aider celle-ci à produire des systèmes logiciels de qualité dans des délais et à des coûts acceptables. Même si on se limite à la production d’applications à objets, il doit être clair qu’il n’est pas possible de définir un processus unique pour toutes les entreprises et tous les systèmes de celles-ci. Il doit être possible de choisir entre différents processus, chacun étant d’ailleurs plutôt un cadre instantiable pour un secteur d’activité, une entreprise ou un projet donné, suivant la nature plus ou moins standardisable des différents systèmes informatiques produits et le niveau de maturité atteint par l’entreprise.

Un processus de développement doit inclure la définition des produits, résultats de chaque activité, et des dépendances entre ces produits. Celles-ci vont permettre de définir les différentes étapes du processus et les différents éléments de la conduite du projet : organisation du travail, prévision des coûts, gestion des risques, prévision des livraisons, vérification de l’état d’avancement du projet, etc. Ces différents produits ne se limitent pas aux résultats de l’analyse et de la conception. Le centre pour les technologies à objets d’IBM en distingue de nombreux. Nous ne citerons ici que ceux considérés, par les auteurs, comme essentiels pour tout projet. Ils peuvent être regroupés par macroactivités (traduction par nous) pour :

  • l’analyse des besoins : l’énoncé du problème, les cas d’utilisation, les besoins non fonctionnels et l’étude de marché si nécessaire ;

  • la gestion de projets : le plan des différents produits, l’analyse des ressources nécessaires, particulièrement humaines, la planification du projet, la planification des tests ;

  • l’analyse : le diagramme de classes, les...

Cet article est réservé aux abonnés.
Il vous reste 94% à découvrir.

Pour explorer cet article
Téléchargez l'extrait gratuit

Vous êtes déjà abonné ?Connectez-vous !


L'expertise technique et scientifique de référence

La plus importante ressource documentaire technique et scientifique en langue française, avec + de 1 200 auteurs et 100 conseillers scientifiques.
+ de 10 000 articles et 1 000 fiches pratiques opérationnelles, + de 800 articles nouveaux ou mis à jours chaque année.
De la conception au prototypage, jusqu'à l'industrialisation, la référence pour sécuriser le développement de vos projets industriels.

Cet article fait partie de l’offre

Technologies logicielles Architectures des systèmes

(233 articles en ce moment)

Cette offre vous donne accès à :

Une base complète d’articles

Actualisée et enrichie d’articles validés par nos comités scientifiques

Des services

Un ensemble d'outils exclusifs en complément des ressources

Un Parcours Pratique

Opérationnel et didactique, pour garantir l'acquisition des compétences transverses

Doc & Quiz

Des articles interactifs avec des quiz, pour une lecture constructive

ABONNEZ-VOUS

Lecture en cours
Processus de développement
Sommaire
Sommaire

BIBLIOGRAPHIE

  • (1) - MEYER (B.) -   Object-oriented software construction,  -  1988, Prentice Hall. (Traduction : Conception et programmation par objets, 1990, InterÉditions).

  • (2) - SILVESTRE (P.), VERLHAC (D.) -   Stratégie de conception des systèmes d’information.  -  H5 170. Les Techniques de l’Ingénieur, traité Informatique, p. 1-21 (1994).

  • (3) - LINSTER (M.) -   L’ingénierie de la connaissance : une symbiose de deux perspectives sur le développement de modèles.  -  in Aussenac (N.), Laublet (P.), Reynaud (C.) (éds), Acquisition et ingénierie des connaissances, tendances actuelles, Cépadues, p. 151-166 (1996).

  • (4) - Groupe Technologie Objet de l’AFCET -   La technologie à objets. Domaines et utilisations,  -  Ingénierie des systèmes à objets, vol. 3 (6) Éd. Hermès (1996).

  • (5) - PERROT (J.-F) -   Langages à objets,  -  H2 510. Les Techniques de l’Ingénieur, traité Informatique, p. 1-17 (1995).

  • ...

Cet article est réservé aux abonnés.
Il vous reste 92% à découvrir.

Pour explorer cet article
Téléchargez l'extrait gratuit

Vous êtes déjà abonné ?Connectez-vous !


L'expertise technique et scientifique de référence

La plus importante ressource documentaire technique et scientifique en langue française, avec + de 1 200 auteurs et 100 conseillers scientifiques.
+ de 10 000 articles et 1 000 fiches pratiques opérationnelles, + de 800 articles nouveaux ou mis à jours chaque année.
De la conception au prototypage, jusqu'à l'industrialisation, la référence pour sécuriser le développement de vos projets industriels.

Cet article fait partie de l’offre

Technologies logicielles Architectures des systèmes

(233 articles en ce moment)

Cette offre vous donne accès à :

Une base complète d’articles

Actualisée et enrichie d’articles validés par nos comités scientifiques

Des services

Un ensemble d'outils exclusifs en complément des ressources

Un Parcours Pratique

Opérationnel et didactique, pour garantir l'acquisition des compétences transverses

Doc & Quiz

Des articles interactifs avec des quiz, pour une lecture constructive

ABONNEZ-VOUS