Les composants logiques : vers une ingénierie à base de composants

remplacés par des modules logiciels pré-existants. L'objectif de cet ... La notion de composant logique est exploitable dans les démarches d'ingénierie de.
404KB taille 5 téléchargements 165 vues
Les composants logiques : vers une ingénierie à base de composants Emmanuel RENAUX Laboratoire TRIGONE Université de Lille 1 59655 VILLENEUVE D’ASCQ cedex [email protected] Chercheur/Industriel RÉSUMÉ. Les systèmes d’information sont de plus en plus vastes au fur et à mesure de l’ajout de nouvelles fonctionnalités, comme récemment, l’ouverture du système d’information sur Internet. Il est important d’étudier l’unité de partitionnement et de réutilisation la plus pertinente dans le cadre d’analyse de systèmes d’information basée sur les besoins, tout en capitalisant sur les efforts d’analyse et de développement. L’origine de la difficulté éprouvée lors du passage de l’analyse au développement d’applications d’un système d’information est sans nul doute l’identification trop tardive des composants. Cette identification doit garantir que ces composants puissent être réutilisables dans des développements futurs ou être remplacés par des modules logiciels pré-existants. L’objectif de cet article est de prouver que les composants doivent être identifiés suffisamment tôt. Nous proposons la notion de composant logique qui, pendant l’analyse, permet de découper un système d’information le plus tôt possible et de conserver ce découpage dans tout le cycle de développement logiciel. ABSTRACT.

Information systems are growing and become more and more complex, progressivly adding new functionnalities, like internet interaction features. The study of a best partitionning and reusing is paramount to deals with capitalization of analysis and development works. Component identification is made classically to late, so the flow from analysis to development is difficult. A component could be reused or replaced by prefabricated components if it is detected early. The goal of this article is to claim that component must be identify earlier, and to provide the notion of logical component that allow to cut out information system earlier, and to conserve this cutting from requirements to deployment, during the whole software development process. : composant logique, cas d’utilisation, partitionnement, cycle de développement, processus d’ingénierie, collaborations.

MOTS-CLÉS

KEYWORDS:

logical component, use case, partitioning, development cycle, ingineering process, collaborations.

1.

Introduction

C’est un fait, la complexité des systèmes d’information des entreprises augmente. Au sein des projets d’ingénierie informatiques actuels, les investissements sont risqués car les technologies et les méthodologies évoluent sans cesse tout en étant mal maîtrisées pour les plus récentes. La recherche et développement pour traiter ce problème, abordent des problématiques à échelles multiples : de petits projets intranet, aux projets globaux de refonte de systèmes d'information, notamment pour des grands pontes des secteurs vastes et complexes tels que la vente par correspondance, la banque, l’assurance, la gestion du patrimoine, le secteur public, etc. Aujourd'hui, un moyen unanime pour gérer cette complexité croissante est l'adoption du paradigme composant [1] [16] . Le principe du paradigme composant est de diviser un système d’information en sous-systèmes de moindre complexité tout en étant suffisamment pertinents pour être réutilisables dans d’autres systèmes. La demande des entreprises dans cette discipline, est de capitaliser leurs investissements d’analyse et de développement par la réalisation de composants métiers et techniques qui puissent être réutilisés dans des développements futurs voire dans de nouvelles technologies. Cependant, l’amélioration de la productivité dépend de la mise à disposition de composants préfabriqués bien délimités, spécifiés, paramétrables et réutilisables. Les approches de type Processus Unifié [2] guident le développement d’application des entreprise. Ces approches n'intègrent pas clairement la notion de composant dans tout le cycle de développement. En effet, la recherche sur la notion de composant s’est d'abord portées sur les plates-formes technologiques, afin de répondre à un besoin de standard d'interopérabilité et de réutilisation des développements. Par exemple, les plates-formes logicielles telles que CORBA [19] , ont d’abord été objets avant d’être composants et les Enterprise Java Beans [25] sont conçus sur la librairie Java qui est objet. L’activité de conception du Processus Unifié consiste à transformer le modèle d’analyse orienté objet d’un système d’information, en composants de déploiement selon la technologie choisie. L’inconvénient identifié dans de telles approches pratiques, est que l’identification et la spécification des composants d’un système d’information sont mises en œuvre trop tardivement. L’intégration de composants existants est en conséquence plus coûteuse car elle nécessite des compromis entre l’analyse et les possibilités des plates-formes technologiques choisies. Pour réduire ce coût et améliorer la productivité, tout en garantissant un bon niveau de qualité, la notion de composant doit être identifiée et spécifiée suffisamment tôt et prise en compte tout au long du processus de développement logiciel. Comment réutiliser un composant, si on ne le détecte qu'à la fin du cycle de production d'une application ? Cet article présente les résultats d’une étude menée en partenariat avec une société de services, la société Norsys. L'observation, l’analyse et la critique de leurs méthodologies de conception de systèmes d’information dans le cadre de projets « nouvelles technologies » ont permis de proposer la notion de composants de modélisation, ou composants logiques, qui dispose de caractéristiques pertinentes en vue de participer à l’avènement d’une véritable industrie des composants logiciels.

La notion de composant logique est exploitable dans les démarches d’ingénierie de type Processus Unifié. Elle améliore l'identification, la réutilisation de composants préfabriqués et la spécification de nouveaux composants en vue de leur publication « sur l'étagère » (Components Off The Shelves) [10] . La section 2 donne une vue simpliste des démarches d’ingénierie logicielle actuellement pratiquées et montre que les limitations sont en partie dues à la non prise en compte de la notion de composant dans tout le cycle de production. La section 3 présente la notion de composant logique et la définit comme la bonne unité de réutilisation [17] [21] . La notion de composant logique est fondée sur les travaux de recherche concernant la modularité de cas d’utilisation [12] , les collaborations UML [2] et les cadres de conception [26] . La section 3 formalise le modèle de composants logiques et montre sa mise en œuvre et les limites d’application pour l’analyse des systèmes d’information.

2. Analyse des systèmes d’information

2.1 Les modèles d’un processus d’ingénierie Cette section présente les différents modèles de l’élaboration d’un système tels que préconisés par le Processus Unifié : le modèle de cas d'utilisation, le modèle d'analyse, le modèle de conception et le modèle de composants de déploiement. Ils sont présentés les uns après les autres dans cet article, mais leur élaboration se fait de manière itérative et simultanée. 2.1.1 Le modèle de cas d'utilisation Les cas d'utilisation servent à exprimer les besoins fonctionnels des utilisateurs d'un système. D'autres types d'exigences peuvent être joints aux descriptions de cas d'utilisation, notamment les exigences non fonctionnelles qui ne sont pas prises en compte volontairement. Le workflow « capture des besoins » correspond à l'identification des besoins qui, une fois implémentés, apportent une plus-value aux utilisateurs d'un système. Ils sont exprimés de façon compréhensible par les utilisateurs dans le modèle de cas d'utilisation. Le modèle de cas d'utilisation joue le rôle d'intermédiaire entre le langage naturel de l'utilisateur expliquant ce qu'il attend du système, et le langage des développeurs. Un système est utilisé par plusieurs types d'utilisateurs catégorisés en acteurs. Les interactions entre les acteurs et le système sont exprimées dans les cas d'utilisation [11] . L'ensemble des acteurs définit l'environnement du système. La figure 1 représente les acteurs et cas d’utilisation de l’étude de cas de l’article : ce système d’information d’une société de location de matériel. Le système gère la location et la restitution de matériel des clients de la société. Pour cela, il permet de consulter et modifier les informations sur les clients, de modifier le stock de matériel disponible. Pour la facturation, une partie du

système gère les prix des locations, ainsi que les recettes. Cette société dispose de plusieurs agences de location et d’un siège social.