Composants dans l’ingénierie des systèmes d’information : concepts clés et techniques de réutilisation Franck Barbier1, Corine Cauvet2, Mourad Oussalah3, Dominique Rieu4, Sondes Bennasri5, Carine Souveyet6 1

LIUPPA, [email protected] LSIS, Aix-Marseille, [email protected] 3 IRIN, Nantes, [email protected] 4 LSR-IMAG, Grenoble, [email protected] 5 CRI, Paris 1, [email protected] 6 CRI, Paris 1, [email protected] 2

Résumé. La complexité croissante des systèmes d’information et leur évolution de plus en plus rapide ont motivé un intérêt accru pour les modèles et méthodes de réutilisation. Dans cet article, la réutilisation est abordée selon une approche « composant » qui consiste à segmenter, rationaliser, encapsuler et plus généralement modulariser les systèmes d’information. Nous nous intéressons aux paradigmes de découpage structurel et fonctionnel qui nous amènent, sous le terme générique « composant », à étudier les composants métier et architecturaux, les patrons et finalement la démarche d’ingénierie dans laquelle ces éléments cohérents et autonomes de systèmes d’information peuvent être gérés. Nous mettons l’accent sur la classification, la formalisation, les techniques d’intégration et les processus de conception des différentes natures de composants analysés.

96

Actes des deuxièmes assises nationales du GdR I3

1 INTRODUCTION Réutiliser a de tout temps constitué une action clé de l’ingénierie des systèmes logiciels et des systèmes d’information. En 1968, McIlroy écrivait : « My thesis is that the software industry is weakly founded, in part because of the absence of a software components subindustry. … A components industry could be immensely successful » [27]. Cette industrie du composant n’a vraiment émergé que dans les années 90. En effet, le développement des logiciels à base de composants (Component-Based Software Engineering) est devenu une réalité avec l’évolution des technologies web et java qui ont facilité la distribution, la recherche, l’interopérabilité des composants sur internet et en particulier des COTS (Commercial Off The Shelf). De nombreuses technologies à base de composants sont aujourd’hui proposées : CORBA de l’OMG, Javabeans de SUN, ActiveX de Microsoft, etc. Le nombre et la diversité de ces propositions sont un signe de l’effervescence des travaux dans le domaine mais aussi de leur disparité. Malgré une réelle avancée, force est de reconnaître que les problèmes liés aux développements et à l’usage des composants ne sont pas encore complètement résolus. La principale raison est que tout produit qui émane d’un processus de développement, qu’il soit conceptuel (spécification) ou plus opérationnel (langage abstrait, code), est naturellement faiblement réutilisable. Rendre réutilisable un produit de développement nécessite de disposer de langages conceptuels et opérationnels permettant l’expression de solutions génériques, adaptables, intégrables, composables, etc. Des formes d’expression des systèmes d’information favorisant la production d’éléments plus modulaires, compréhensibles hors du contexte où ils sont amenés à s’associer à d’autres éléments, dotés de facultés d’intégration/connexion plus explicites ont émergé. La recherche dans le domaine de l’ingénierie des systèmes d’information s’est appliquée à mieux caractériser ces formes, et à en définir leur usage dans des démarches et processus idoines. Cet article balaie ces aspects et se veut un état de l’art actuel de la réutilisation, et son corollaire, la technologie composant, dans le monde des Systèmes d’Information (SI). L’accent est mis sur trois formes de composants facilitant la réutilisation dès les étapes de spécification des SI (analyse et conception) : les composants métiers (§2), les composants d’architecture (§3) et les patrons d’ingénierie (§4). Le paragraphe 5 constitue un bref état de l’art sur les démarches de développement des SI à base de composants.

Composants dans l’ingénierie des systèmes d’information

97

2 COMPOSANTS METIER L’approche à base de composants est aujourd’hui considérée comme un nouveau paradigme de développement des systèmes d’information. Comme dans le passé en ingénierie des systèmes d’information, les activités de programmation ont été les premières concernées par ce nouveau paradigme. Des propositions d’approches à base de composants commencent à apparaître pour répondre à des problèmes d’ingénierie de besoins, de spécification et de modélisation de systèmes. L’approche « composant métier » s’inscrit dans cette orientation.

2.1 Historique Le concept de composant métier résulte de celui d’objet métier ou « business object » en anglo-américain [37]. Avec l’effervescence autour de la technologie objet vers la fin des années 80 et le début des années 90, est apparu le besoin de réutiliser des connaissances nouvelles, différentes de celles représentées dans les simples objets techniques : des piles, des files, des objets graphiques, des objets fichiers, des objets processus… Des recherches sur l’identification et la représentation d’objets invariants à travers toutes les applications d’un même domaine ont commencé dans des domaines comme la santé, le transport, les sciences de la vie, l’énergie ou encore la finance et la banque. Par ailleurs, les limites de l’approche objet en terme de granularité pour la réutilisation de connaissances de domaine sont rapidement apparues. Ces limites et l’arrivée de la technologie composant logiciel ont fait émerger une nouvelle forme d’unité réutilisable : les composants métier. Cette forme de composant manque de maturité et il n’existe pas de normalisation de cette notion. Cependant les expériences et les pratiques dans la communauté de l’ingénierie des systèmes d’information permettent d’affirmer que la réutilisation des connaissances de domaine constitue une approche puissante pour le développement des systèmes d’information. Une étude récente [5] confirme que le problème de réutilisation doit impérativement se poser sous cet angle « métier »: « To date, the success of component technology in satisfying the demand for software generated by the IT revolution hinges largely on the ability of components to support domain-specific software reuse. » Les propositions de modèles de composants métier sont nombreuses et répondent à des besoins très différents. Le paragraphe suivant propose quelques définitions pour illustrer cette variété et montrer les différences avec les approches de type composant logiciel.

98

Actes des deuxièmes assises nationales du GdR I3

2.2 Définitions Différentes définitions existent. Carey et al. dans [23] écrivent : « A business component is a software component that provides functions in a business domain. (…) for example, an order management application is part of the Enterprise Resource Planning (ERP) business domain. » Une autre définition est présentée dans [4] : « A business component models and implements business logic, rules and constraints that are typical, recurrent and comprehensive notions characterizing a domain or business area. Within software engineering, business components are key abstractions that are captured during the domain engineering activity. They are software artifacts in the sense that they are not part of reality but embody and represent recurrent invariants relevant to requirements, particularly at the earliest phases of development. » Un composant métier est un composant, c’est-à-dire une entité encapsulée, et donc possédant une partie publique et une partie privée. De plus c’est une entité autonome de déploiement [38]. Il doit ainsi se comprendre et pouvoir être appréhendé de façon individuelle en occultant temporairement au moins, l’environnement où il sera amené à collaborer avec d’autres composants pour fournir une application. Une différence significative des composants métier par rapport à des composants logiciels réside dans la prise en compte explicite d’un domaine d’application. Une particularité qui résulte de la précédente concerne leur contexte de réutilisation. Les composants métier sont réutilisables uniquement au sein d’un même domaine d’application. Ils sont souvent nommés composants verticaux par opposition à des composants réutilisables dans différents domaines qui sont eux appelés composants horizontaux. L’étude des différentes approches en matière de composants métier fait apparaître deux grandes tendances : - celle dans laquelle un composant métier fournit le processus et les produits de développement qui sont nécessaires pour représenter, concevoir, implémenter et déployer un concept de domaine dans un système logiciel. Dans cette approche un composant métier est le plus souvent implanté au moyen des technologies composants distribués de type COM/DCOM, CORBA ou EJB. Cette forme de composant métier est proposée par l’OMG [24] et par IBM dans son architecture SanFransisco [7]. - celle dans laquelle un composant métier est une unité de réutilisation de connaissance de domaine. Cette approche met l’accent sur la connaissance de domaine et sur sa représentation. Dans cette approche,

Composants dans l’ingénierie des systèmes d’information

99

on cherche d’une part à représenter le domaine à un niveau générique et d’autre part à expliciter toute sa variabilité. Cette approche est suivie par les méthodes d’ingénierie de domaine [39] et [40] et les méthodes d’ingénierie de lignes de produit [33].

2.3 Classification Une classification à laquelle sont soumis les composants métier est celle des domaines. Wartik et Prieto-Diaz dans [39] donnent les fondements de la réutilisation de connaissances de domaine, c’est-à-dire la capture et la caractérisation d’artefacts récurrents : un compte bancaire en finance avec tout un ensemble d’états et d’opérations type constituant son interface. Spécifier une fois pour toute ce genre de composant, le rendre flexible et générique pour des usages non forcément prévus a priori, déterminer une méthode sûre pour l’intégrer aisément dans des modèles à grande échelle… sont des défis parmi d’autres difficiles à relever. De manière plus générale, identifier, classifier et segmenter des domaines est une discipline à part entière qui influe grandement sur le paradigme même de composant métier. L’OMG propose à ce jour une classification en domaines et sous-domaines : le contrôle de trafic aérien par exemple comme sous-domaine du transport. Dans chaque domaine, l’OMG propose aussi une classification des composants métier en trois types : - les composants « processus métier » représentent les activités de gestion du domaine,

Process

InvoiceManager, PaymentManager

Business Process managers

CreditChecker, Reconciliation

Support Process Managers

Invoice

Customer, Vendor

Entity

Utility

Contracts Trading partners

Price, Tax, Cost

Concepts

CashBook, Account

Materials

Calendar, CurrencyBook, AddressBook

Books

Notes, NumberGenerator, Codes

Support Utilities

FIG. 1 ─ Classes et sous-classes de composants métier

100

Actes des deuxièmes assises nationales du GdR I3

- les composants « entité métier » représentent les concepts du domaine sur lesquels les processus métier sont mis en œuvre, - les composants « utilitaires » sont utilisés par les deux autres types de composants. La figure 1 illustre cette classification pour le domaine de la finance [24]. La figure 2 fournit un essai de typologie des composants métier du plus universel (« cross-domain ») au plus spécifique à un domaine. L’échelle des abscisses montre la variabilité des composants métier en fonction de leur personnalisation pour des besoins particuliers. Le composant « Observations and Measurements » [16] illustre cet aspect domaine universel. Il concerne tous les domaines où l’on fait des mesures et des observations. Le composant « Time Service » est lui aussi quasi universel mais s’il supporte une précision à la nano-seconde, il devient spécifique à des domaines comme la supervision et le pilotage de procédés physiques nucléaires par exemple (bas de figure, droite : voir l’interface « nanosecond configuration interface »). De façon Application requirement customization and parameterization Time Service

Timer Event Service interface

Air Traffic Control

Currency

Transportation

General Ledger

Finance

Observations and Measurements

Time Service

Provided interface

Time Service

Nanosecond configuration interface Provided interface

Subdomaincompliance

Universality Business-generic

Business-specific

FIG. 2 ─ Echelle d’expression des composants métier

Composants dans l’ingénierie des systèmes d’information

101

orthogonale, « Time Service » doit pouvoir se personnaliser pour des besoins applicatifs non caractéristiques d’un domaine (interface « Timer Event Service » en haut à gauche) comme les aspects temps réel.

2.4 Représentation Il n’existe pas de modèle de représentation standard des composants métier. Les composants métier sont de nature conceptuelle, c’est-à-dire qu’ils sont des parties de spécification isolées en tant que telles pour être intégrables dans des modèles distincts relatifs à des applications différentes. Un formalisme adéquat pour les exprimer au niveau conceptuel est par exemple fondé sur les Class Diagrams d’UML, ou encore les Statechart Diagrams, ou les Activity Diagrams sous un angle plus dynamique. Des formalismes plus opérationnels (sans aller jusqu’à l’implémentation proprement dite) peuvent être utilisés pour définir des composants métier, typiquement le langage IDL ou encore les Component Diagrams d’UML. Les modèles de composants métier utilisent donc des langages de représentation qui peuvent être conceptuels ou opérationnels. Par exemple dans l’approche de l’ODMG, chaque composant métier est décrit au moyen de quatre couches fonctionnelles appelées : couche utilisateur, couche espace de travail, couche entreprise et couche ressource. Chaque couche utilise des technologies de programmation objet ou composant. Au contraire les approches à base de « patterns » utilisent des langages semi-structurés ou la notation UML.

2.5 Intégration, composition, assemblage Le problème d’association des composants ou composabilité reste un problème des plus délicats en technologie composant. Un composant métier n’est pas une partie quelconque d’une spécification ou d’un système logiciel. C’est une partie qui a des qualités remarquables par le fait qu’elle s’intègre à moindre coût et aisément dans une architecture de composants. La collaboration des composants a souvent été posée en termes syntaxiques alors que les véritables enjeux sont l’interopérabilité sémantique. Heiler le confirme ainsi [22] : « Interoperability among components of large-scale distributed systems is the ability to exchange services and data with another. (…) Semantic interoperability ensures that these exchanges make sense – that the requester and the provider have a common understanding of “the meanings” of the requested services and data. ». Ainsi les mécanismes techniques de gestion de

102

Actes des deuxièmes assises nationales du GdR I3

conflits de noms ou de composant distribués doivent être complétés par des mécanismes nouveaux de gestion de conflits sémantiques (niveau domaine). Ces mécanismes sont intégrés dans des « frameworks » pour fournir des services aux composants métier. Par exemple dans l’approche SanFransisco les CBO (Common Business Objects) supportent ces services généraux d’intégration. La figure 3 montre l’architecture générale d’une application qui utilise les composants métier de SanFransisco (Core Business Objects) et les Common Business objects. Individuellement, les composants peuvent être parfaitement spécifiés. Assemblés, la prédiction du comportement global achoppe sur des

Business Applications Core Business Processes Order Management

Warehouse Management

Common Business Objects Foundations and Utilities Java Virtual Machine

FIG. 3 ─ Architecture générale d’une application construite selon l’approche SanFransisco

incompatibilités sémantiques. Par exemple, le composant métier « devise monétaire » présenté dans [31] est sujet à des protocoles d’utilisation codifiés par des Sequence Diagrams UML (i.e. des scénarios). Toute requête de mise en œuvre d’opération de conversion de devise suppose par exemple l’enregistrement de différentes informations relatives à la devise, dans un dictionnaire (e.g. le mnémonique : « US$ », « € », « AUS $ »…). Vu son interface décrite en IDL dans [31], le composant « devise monétaire » n’offre pas cette compréhension directe, et de manière plus générale, son intégration est soumise à des nombreuses contraintes qui ne sont pas tangibles.

Composants dans l’ingénierie des systèmes d’information

103

3 COMPOSANTS ARCHITECTURAUX 3.1 Historique et motivation L’engouement récent pour les architectures logicielles a donné naissance au développement d’une nouvelle génération de langages de spécification et de conception connus sous le nom de ADLs (Architecture Description Languages). La plupart d’entre eux sont issus de laboratoires de recherche (Carnegie Mellon University, Stanford University, Università dell’ Aquilla,…) et sont encore au stade expérimental. Cependant, force est de constater qu’il s’agit d’un courant de recherche très actif et prometteur, qui a été à l’origine des modèles académiques de composants [28] dans le début des années quatre vint dix, et qui concentre aujourd’hui l’essentiel de son activité à fournir des langages et des outils de spécifications architecturales explicites favorisant le développement de systèmes à base de composants (CBD : ComponentBased Development [2]). Actuellement, l’approche CBD est plébiscitée aussi bien par les consommateurs que les producteurs de composants compte tenu des avantages évidents qu’elle procure : diminution drastique du temps de développement, facilité de réutilisation des composants produits, diminution du coût de production, augmentation de la fiabilité, etc.. Les ADLs sont également utilisés comme des méta-modèles pour guider le développement de systèmes et garantir certaines de leurs propriétés. Ils permettent notamment la spécification d’architectures à grandes échelles et fournissent des processus de leur raffinement et de leur évolution. Ils augmentent la réutilisation non seulement des composants mais aussi des architectures. Tous ces aspects sont d’autant plus pertinents lorsqu’on traite des systèmes distribués ouverts dont les architectures évoluent dynamiquement et que leur consistance (compatibilité entre composants) doit être garantie pour chaque changement substantiel les affectant.

3.2 Classification Les ADLS se distinguent essentiellement par leur niveau d’expressivité, leur capacité à prendre en compte la modélisation de la structure et du comportement d’un système et enfin leur maturité. Parmi les plus représentatifs, nous pouvons citer ACME [20], dont le but est de fournir un langage pour faciliter le partage de composants architecturaux

104

Actes des deuxièmes assises nationales du GdR I3

issus d’autres ADLs et d’intégrer des outils d’analyse. RAPIDE [26] fournit un ADL exécutable basé sur un modèle d’exécution de règles d’événement et destiné au prototypage, à la simulation et à l’analyse de systèmes logiciels. UNICON [36] supporte des constructions architecturales basées sur des « styles » en interconnectant des composants architecturaux prédéfinis. METAH [39] spécifie les aspects temps réel d’un système logiciel ou matériel et fournit un support pour l’analyse des propriétés fonctionnelles ou non-fonctionnelles d’un système. Enfin, WRIGHT [36] propose un formalisme centré sur différents types de connecteurs explicites. Pour une étude détaillée des ADLs, le lecteur peut se référer aux travaux de synthèse de Medvidovic [28] qui constituent, à notre connaissance et à l’heure actuelle, une des tentatives de classification et de comparaison des ADLs la plus aboutie. Au regard des travaux existants, il ressort qu’un composant d’une architecture ADL doit refléter trois dimensions : - son niveau d’abstraction, - son point de vue architectural, - son domaine. La première dimension ou niveau d’abstraction permet d’exprimer les degrés de raffinement d’un composant et ce depuis sa spécification, considérée comme étant le plus haut niveau d’abstraction, à son code source représentant le plus bas niveau. La deuxième dimension ou point de vue architectural permet de décrire les différents modèles de représentation d’un composant (représentation textuelle, graphique, flot de données,…, implémentation). La description d’un composant architectural doit être simple, compréhensible avec une sémantique claire, pas nécessairement formelle. En effet, les participants à l’élaboration de composants architecturaux (concepteurs, développeurs, utilisateurs, managers…) peuvent requérir à différents points de vue d’une architecture. Les utilisateurs peuvent se contenter par exemple d’une description graphique de haut niveau (type boîtes et flèches), les développeurs voudront détailler par exemple les modèles de connecteurs et de composants, alors que les managers seront plus intéressés par une vue du processus de développement. La troisième dimension ou Domaine reflète les différents domaines structurés en couches et sur lesquels repose un système donné. Cette structuration permet à un composant appartenant à une couche domaine particulière de ne pouvoir interagir qu’avec seulement les composants de la même couche ou de la couche adjacente. Les composants du « Tout Domaine » constituent la couche de plus bas niveau et sont indépendants

Composants dans l’ingénierie des systèmes d’information

105

du domaine d’application, c’est le cas par exemple de systèmes d’exploitation, de compilateurs, de systèmes de bases de données... Au niveau plus haut « Domaine connexe », on trouve des composants appartenant à des domaines connexes à l’application en cours de construction, par exemple des interfaces utilisateurs, des simulateurs, … et enfin en haut de la hiérarchie les composants de « Mon Domaine » spécifiques au domaine choisi et relatifs à l’application courante, par exemple les composants de circuits intégrés. Il est clair que le nombre de couches de domaines n’est pas figé et dépend de la maturité des domaines d’applications.

3.3 Concepts clés Depuis les dix dernières années de nombreux langages ont été développés pour prendre en compte les descriptions de haut-niveau de systèmes logiciels complexes, exhibant leur structure brute comme une collection de composants en interactions et permettant à des ingénieurs de raisonner sur des propriétés de systèmes à un haut niveau d’abstraction. Ces propriétés incluent entre autres les protocoles d’interaction, la conformité aux architectures standards, la dimension de l’évolution… Aujourd’hui, au sein de la communauté de recherche en architecture logicielle, un consensus général concernant plusieurs aspects des fondements pour les représentations et analyses architecturales a émergé conduisant au développement de langages génériques ADLs de seconde génération. Bien qu’il existe une diversité considérable dans les possibilités et les propositions d’ADLs, tous partagent une base conceptuelle similaire qu’on peut qualifier d’ontologie, et qui peut être considérée comme un fondement commun de concepts pour la description d’architectures logicielles. Les éléments principaux de cette ontologie sont les suivants. L’architecture : est une spécification explicite des composants d’un système et de leurs interactions. La motivation pour définir une architecture est de fournir un plan précis (ou méta-modèle) approprié pour prédire le comportement d’un système avant de le construire et pour guider son développement. Les composants : sont définis comme des unités de composition qui décrivent et/ou assurent des fonctions spécifiques, possèdent des interfaces de besoins et des interfaces de services et des contextes particuliers d’exécution. Ils peuvent être déployés indépendamment et

106

Actes des deuxièmes assises nationales du GdR I3

composés avec d’autres composants. Ils sont préfabriqués, prétestés, s’auto-contiennent, et disposent de documentations appropriées et d’un statut de réutilisation bien défini. Les clients, serveurs, blackboard, base de données sont des exemples types de composants (souvent considérés comme composants lourds par opposition à des composants de plus faible granularité). Les connecteurs : représentent les interactions entre composants. Les formes simples d’interaction, comme les pipes, les appels de procédure, les évènements, etc. en sont des exemples. Cependant, les connecteurs peuvent aussi représenter des interactions plus complexes, telles qu’un protocole client-serveur ou un lien SQL entre une base de donnée et une application. Les connecteurs ont aussi des interfaces qui définissent les rôles joués par les divers participants à l’interaction. Dans les ADLs, la composition de composants repose sur les connecteurs et les contraintes qui leur sont associées. Les systèmes : représentent les configurations (graphes) de composants et de connecteurs. Dans les ADL actuels, une propriété clé de description de système consiste à définir la topologie d’un système indépendamment des composants et des connecteurs qui composent le système (ceci est en contradiction avec la plupart des langages de programmation où les dépendances sont attachées au sein des composants via des clauses d’importation). Les systèmes peuvent aussi être hiérarchiques : les composants et les connecteurs peuvent représenter des sous-systèmes qui possèdent des architectures internes. Les propriétés : représentent les informations sémantiques d’un système, de ses composants et de ses connecteurs. Elles servent également à documenter les détails d’une architecture. Les contraintes : considérées comme un type de propriétés spécifiques, elles permettent à un modèle d’architecture de rester valide même s’il évolue dans le temps. Elles peuvent inclure des restrictions sur les valeurs permises de propriétés, sur la topologie, sur le vocabulaire du modèle. Les styles : représentent des familles de composants ou systèmes reliés. Un style définit un vocabulaire de conception de types de composants et les règles pour les composer. Les pipe & filter, les machines abstraites hiérarchisées, les clients-serveurs, sont des exemples types de « Styles ». Les représentations multiples : Pour autoriser les descriptions hiérarchiques d’une architecture, certains ADLs permettent à n’importe

Composants dans l’ingénierie des systèmes d’information

107

quel composant ou connecteur d’être représenté par une ou plusieurs descriptions (représentations) de bas niveau.

4 PATRONS D’INGENIERIE 4.1 Historique Le terme patron de conception (design pattern) a été introduit dans le domaine de l’architecture des bâtiments par C. Alexander [1]. Un patron d’architecture tout comme un patron de couture capitalise un savoir faire permettant de résoudre un problème récurrent du domaine (l’architecture ou la couture). L’un des patrons le plus fréquemment cité, "a place to wait", propose des solutions architecturales au problème de l’attente (salle d’attente d’un médecin, embarquement dans un avion, rendez-vous d’affaires, etc.) dans une pièce. Dans le domaine de l’informatique, les premiers patrons orientés objets ont été présentés par K. Beck et W. Cunninghan lors de la conférence OOPSLA de 1987. Un premier catalogue plus spécifiquement destiné à la conception orientée objet a été élaboré par E. Gamma en 1991 à Zurich lors des travaux de son Ph.D. Ces travaux ont été suivis en 1995 d’un premier ouvrage collectif [19]. Depuis, de nombreux ouvrages et articles ont été publiés par G. Booch, R. Helm, E. Gamma, P. Coad, J.O. Coplien, F. Buschmann, M. Fowler, C. Larman. etc. La première conférence internationale dédiée à la notion de patrons de conception date de 1994 (PLoP), la première conférence européenne de 1996 (EuroPLoP).

4.2 Définition Nous partageons complètement la définition de patron de conception d’Alexander qui assimile le patron à un savoir-faire formalisé : « Chaque patron décrit à la fois un problème qui se produit très fréquemment dans votre environnement et l’architecture de la solution à ce problème de telle façon que vous puissiez utiliser cette solution des millions de fois sans jamais l’adapter deux fois de la même manière ». Dans le domaine de l’ingénierie des systèmes d’information les patrons sont des composants réutilisables : - alliant problème et solution, - offrant des solutions conceptuelles (spécifications réutilisables),

108

Actes des deuxièmes assises nationales du GdR I3

- correspondant à des composants de type « boite blanche » , - dédiés à la réutilisation de micro-architectures (4 à 5 classes pour les patrons orientés objets, 4 à 5 tâches pour les patrons processus, etc.).

4.3 Classification Parmi les différents critères permettant de comparer les modèles de composants [11] [18], trois d’entre eux sont particulièrement intéressants pour classifier les patrons : - le type de connaissance. Il peut s’agir de capitaliser des spécifications ou des implantations de produit - un résultat à atteindre - ou de capitaliser des spécifications ou des implantations de processus - une démarche à suivre pour atteindre le résultat. - la couverture. Il peut s’agir de patrons généraux, domaine ou entreprise. - la portée. La portée est évaluée en fonction de l’étape d’ingénierie (analyse, conception, implantation) à laquelle le composant s’adresse. Les systèmes de patrons les plus connus, par exemple ceux de P. Coad [13] et d’E. Gamma [19], concernent des patrons produit généraux dédiés à une et une seule étape du processus de développement (analyse pour ceux de P. Coad, conception pour ceux d’E. Gamma). Les patrons de S.W. Ambler [3] sont par contre des patrons processus généraux couvrant l’ensemble du cycle de développement des logiciels. Ils fournissent des collections de démarches, d’actions et/ou de tâches à suivre pour le développement des logiciels. Les patrons proposés par L. Gzara [21] sont spécifiques d’un domaine (les Systèmes d’Information Produit –SIP- ou Product Data Management). Ils couvrent les étapes d’analyse et de conception des SIP en combinant patrons produit et patrons processus.

4.4 Représentation et organisation Les patrons sont décrits par des formalismes [32] dont les rubriques, en particulier celles destinées à la compréhension et à la sélection des patrons, sont souvent décrites en langue naturelle sous la forme de textes non structurés. Seules les rubriques exprimant les solutions ont fait l’objet de formalisation (diagrammes OMT, UML, etc.). Force est également de constater que la plupart du temps, les systèmes de patrons sont peu ou mal organisés. Un système de patrons (certains auteurs

Composants dans l’ingénierie des systèmes d’information

109

préfèrent le terme de catalogue ou encore de langage) offre une collection structurée de patrons construits l’un sur l’autre ou l’un avec l’autre, pour transformer les besoins et les contraintes dans une architecture [1]. Cette définition sous-tend que dans un même système, les patrons se coordonnent pour résoudre un problème complexe. Cette coordination peut être plus ou moins rigide et plus ou moins explicite. Elle peut être exprimée sous la forme de relations inter-patrons (la plupart du temps des relations d’utilisation) ou par des patrons processus intégrant une démarche de développement réglementant l’usage et la coordination des patrons. De nombreuse recherches portent actuellement sur : - l’uniformisation des patrons produits et processus [21] de manière à permettre leur cohabitation au sein d’un même système de patrons, - la formalisation des rubriques de sélection [6], - l’expression des relations inter-patrons [16]. Citons par exemple le formalisme P-SIGMA [14] constitué de trois parties : Interface, Réalisation et Relation. La partie « Interface » contient tous les éléments permettant la sélection d’un patron. La partie « Réalisation » exprime la solution d’un patron en terme de solution modèle et/ou de solution démarche. Enfin, la partie « Relation » permet d’expliciter les relations entre patrons (relations d’utilisation, de raffinement, d’alternative, etc.). Chaque partie offre un certain nombre de rubriques composées de champs typés (texte, diagramme UML, expression logique de mots clés, etc.).

4.5 Adaptation, intégration L’adaptation (ou application) des patrons est étroitement liée aux modèles proposés. C’est ainsi que pour les patrons dédiés à l’ingénierie des systèmes orientés objet, l’adaptation peut correspondre à une simple imitation de la solution (imitation = copier, coller, adapter librement) ou à une réelle instanciation [8], [29]. L’intégration de patron est également dépendante des modèles proposés. Pour les patrons orientés objets, l’opération d’intégration [18] consiste à réaliser l’union des rôles joués par des classes intervenant dans différentes adaptations de patrons. L’union des rôles peut être réalisée de différentes manières : regroupement des propriétés dans une même classe, définition d’une sous-classe commune à plusieurs classes modélisant des rôles différents, application d’un patron rôle [35]. La figure 4 illustre

110

Actes des deuxièmes assises nationales du GdR I3

Figure

FigureChangeListener Collègue concret

Sujet

Composant

Observateur Médiateur

Composite Observateur

Médiateur concret

FigureChangeEventMulticaster Observateur concret

Feuille

Sujet concret

Composite concret

AttributeFigure CompositeFigure StandardDrawing Gestionnaire concret

AbstractFigure

Gestionnaire concret

RectangleFigure

Gestionnaire concret Gestionnaire Client Chaîne de responsabilité

FIG. 4 ─ Re-conception du cadriciel JhotDraw

partiellement cette approche. Elle montre l’intégration d’imitations de différents patrons issus du catalogue d’E. Gamma. Cette intégration produit un modèle conceptuel du framework JHotdraw1. Chaque adaptation de patrons est représentée par une collaboration UML. Une classe peut participer à plusieurs adaptations. C’est ainsi que la classe FigureChangeListener joue deux rôles : celui de collègue dans une adaptation du patron Médiateur et celui d’observateur dans une adaptation du patron Observateur.

5 DEMARCHES D’INGENIERIE DE SYSTEMES A BASE DE COMPOSANTS Le terme « Développement à base de composants » est un terme très populaire de nos jours dans le domaine du génie logiciel. Les technologies supportant les composants telles que EJB, CORBA, COM/DCOM/.NET sont bien établies. Cependant, les méthodes pour le 1

http://jhotdraw.sourceforge.net/

Composants dans l’ingénierie des systèmes d’information

111

développement des systèmes à base de composants n’ont pas encore atteint le stade de maturité des technologies supportant les composants. Dans ce qui suit, nous présentons brièvement trois méthodes largement connues à savoir Catalysis [15], Rational Unified Process (RUP) [25] et Select Perspective [2]. Nous nous concentrons par la suite sur la prise en charge de la modélisation des composants dans les trois méthodes afin d’identifier les points faibles. La table 1 résume les caractéristiques générales de ces trois méthodes.

Catalysis

RUP

Select Perspective

Processus de Itératif développement incrémental

et Itératif incrémental

et Itératif incrémental

Notation

UML extensions

+ UML extensions

+ UML, diagramme entité relation, CSC Catalyst

Outils Case

Cool :Spex, Cool:Gen, etc.

Rational etc.

Complexité d’apprentissage

Très complexe

Moyennement complexe

Rose, Select Component Factory Moyennement complexe

TABLE 1 ─ Résumé des caractéristiques générales de quelques méthodes

Nous remarquons l’adoption par toutes les méthodes présentées d’un processus de développement itératif et incrémental. Ce type de processus permet d’avoir des applications de bonnes qualités grâce au contrôle du temps, des coûts et des risques. Les processus de développement proposés par Catalysis et RUP ont la particularité d’être flexibles afin de s’adapter aux besoins d’un projet spécifique ou d’une organisation.

et

112

Actes des deuxièmes assises nationales du GdR I3

C atalysis

RUP

S elect P ersp ective

Introductio n des N iveau logiq ue, N iveau lo gique, com posants d ans niveau N iveau le cycle de im plém entatio n im p lém entatio n dévelop pem ent

niveau lo giq ue, niveau im plém entation

R ègles d’identificatio n des co m p osants

P as d e règles

P as de règles

P as d e p récisions sur le niveau d e déco m p osition où il faut s’arrêter

P as de précisio ns sur le niveau de d écom po sition où il faut s’arrêter

P as d e règles

N iveau de P as de p récisio ns déco m positio n sur le niveau d e d’un co m p osant d écom po sition où il faut s’arrêter R eprésentatio n des co m p osants

N iveau logique : N iveau logique : N iveau logiq ue : p ackage de so us systèm e typ e services N iveau N iveau im plém entatio n : im p lém entatio n : N iveau diagram m e d e im plém entation : p ackage, d iagram m e de co m p osants com po sant com po sants

R igueur d ans la O ui grâce spécificatio n des l’utilisatio n com posants O C L [7 ] R éutilisatio n

F ram ew ork

à N on m entionné de Service package sans p récisions sur la m anière d’identification de co nstructio n

N on m entio nné

P ro cessus de gestion d’une librairie de com po sants

TABLE 2 ─ Evaluation de la prise en charge de la modélisation des composants

Par ailleurs, les méthodes se basent sur la notation UML (versions antérieures à UML2.0) à l’exception de Select perspective qui utilise des techniques supplémentaires de modélisation telles que les techniques de modélisation des processus métier de CSC Catalyst [10] et les diagrammes entité-relation. Puisque les versions antérieures de UML telles que la version 1.3 préconisent une vue d’un composant plutôt du niveau physique, la plupart des méthodes ont ajouté des extensions pour représenter les composants au niveau logique telles que les sous systèmes dans RUP, les packages de service dans Select Perspective et les Types dans Catalysis. Une dernière remarque concerne la complexité d’apprentissage d’une méthode qui influe considérablement sur son

Composants dans l’ingénierie des systèmes d’information

113

utilisation dans la pratique. Catalysis, bien qu’étant une méthode complète, est jugée très complexe à apprendre. C’est pourquoi plusieurs autres méthodes fortement inspirées par Catalysis et moins complexes sont proposées telles que la méthode de Daniel et Cheesman [12]. Les deux autres méthodes sont jugées moyennement complexes. Dans ce qui suit, nous nous concentrons sur la modélisation des composants. La table 2 résume les principaux points que nous jugeons pertinents pour une méthode de développement à base de composants. D’après la table 2, nous notons les faiblesses suivantes : (a) La première faiblesse concerne l’introduction tardive des composants dans le cycle de développement (aux niveaux logique ou implémentation). En effet, une méthode de développement à base de composants doit être centrée composants dans toutes les phases de développement, ainsi, il est possible de profiter des nombreux avantages des composants dès les premières phases de développement, notamment, la division du problème sous forme d’unités autonomes avec des dépendances bien définies et l’introduction de la réutilisation dès la phase de capture des besoins. Plusieurs méthodes ont introduit les composants dès la phase de capture des besoins telles que Business Component Approach [25]. (b) La deuxième faiblesse concerne le guidage du concepteur pour identifier des composants. Les méthodes se basent plutôt sur l’expertise du concepteur. Dans RUP par exemple, les composants sont identifiés à partir des sous systèmes sans donner plus d’information. Catalysis donne quelques directives à travers des patterns processus mais sa complexité la rend incompréhensible et par conséquent difficile à appliquer. (c) La troisième faiblesse est relative au partitionnement d’un problème sous forme de composants. L’approche suivie par les trois méthodes consiste à identifier des composants de grande granularité puis à les décomposer sous forme de composants de plus faible granularité jusqu’à obtenir la granularité appropriée. Le problème avec cette approche, comme signalé dans [25] est que le concepteur ne sait pas combien d’itérations il doit faire ni comment mettre sous forme de packages et déployer les agrégations de composants. La solution à ce problème consiste à définir des niveaux de granularité des composants et à préciser pour chacun de ces niveaux des caractéristiques telles que le rôle de chaque niveau de granularité dans le système d’information, ainsi que les règles de mise en package et de déploiement.

114

Actes des deuxièmes assises nationales du GdR I3

(d) Et enfin, une dernière faiblesse concerne la prise en charge partielle de la réutilisation qui est traitée dans les trois méthodes. Dans RUP, aucune indication n’est donnée concernant la construction de composants réutilisables et le processus de développement pour la réutilisation. Catalysis préconise la réutilisation des frameworks en étendant leur usage initialement proposé dans [18]. Cependant, aucun processus de développement pour la réutilisation n’est proposé. Select Perspective est la seule méthode parmi les trois étudiées à proposer un outil gérant une bibliothèque de composants mais sa documentation reste vague concernant l’identification et la construction de composants réutilisables.

6 CONCLUSION Dans cet article, il est fait état de concepts et techniques de réutilisation dans les étapes de spécification de systèmes d’information. Aujourd’hui, les démarches de développement ne prennent pas suffisamment en compte l’approche par réutilisation dans les étapes amont du développement des SI. Par contre les modèles de composant et de patron dédiés aux étapes d’analyse et de conception commencent à s’imposer : - Les approches composants métier se multiplient et apparaissent de plus en plus pertinentes dans le développement des systèmes d’information. Elles répondent peu à peu au besoin, d’une part, de disposer d’un niveau conceptuel de description des composants techniques et d’autre part, de raisonner « composant » dans les étapes amont du développement. La section de cet article consacrée aux composants métier a montré la très grande variété des approches. Il n’y a pas de consensus encore aujourd’hui sur la définition d’un composant métier et les modèles de composants métier proposés restent très hétérogènes tant au niveau des concepts que des langages de spécification. - Les approches composants architecturaux qui ont émergé au sein de la communauté de recherche « Architectures logicielles » ont permis notamment de prendre en compte les descriptions de haut-niveau de systèmes complexes, et de raisonner sur leurs propriétés à un haut niveau d’abstraction (protocole d’interaction, conformité avec d’autres architectures, évolution…). Aujourd’hui, les efforts de recherche se concentrent sur la formalisation de composants architecturaux et sur leur extension (description d’architectures paramétrables, définition de patterns structuraux…).

Composants dans l’ingénierie des systèmes d’information

115

- Quant à l’approche patron, elle peut être perçue de deux manières : (1) les patrons sont au même titre que les composants métiers ou les composants architecturaux des éléments conceptuels réutilisables, (2) l’approche patron offre des techniques de représentation applicables à toute forme de composant. Il est par exemple possible de documenter sous la forme de patrons des composants métier [17] [33] ou des styles d’architecture [9]. En ce sens l’approche patron constitue une avancée significative en permettant : - de représenter de manière uniforme des composants variés, - d’organiser les composants en fonction des problèmes à résoudre plutôt que des solutions offertes. La définition de modèles de composants et de démarches de développement basés sur l’approche par réutilisation constituent une problématique de recherche essentielle dont les solutions commencent seulement à émerger. La mise en pratique de cette approche dans l’industrie nécessite de poursuivre ces recherches et de les valider sur des applications « grandeur réelle » à base de composants.

7 REFERENCES [1] [2]

[3] [4] [5]

[6]

[7]

C. Alexander, The Timeless Way of Building, Oxford University Press, 1979. P. Allen and S. Frost, Component-Based Development for Entreprise Systems : Applying the select perspective, Cambridge University Press, Cambridge, UK, 1998. S.W. Ambler, Process Patterns building Large Scale Systems using Object technology, SIGS Books, Cambridge University Press, December 1998. F. Barbier, Business Component-Based Software Engineering, Kluwer, 2002. L. Bass, C. Buhman, S. Comella-Dorda, F. Long, J. Robert, R. Seacord, K. Wallnau, Volume I: Market Assessment of Component-Based Software Engineering, Carnegie Mellon University, Software Engineering Institute, TECHNICAL REPORT CMU/SEI-2000-TR-008, ESC-TR-2000-007, May 2000. C. Berrut, A. Front-Conte, Patterns retrieval system: first attempt, 5th International Conference on Applications of Natural Language to Information Systems (NLDB’2000), Versailles, June 2000. K.A. Bohrer, Architecture of the SanFransisco Framework, IBM Systems Journal, Vol 37, N° 2, 1998.

116 [8]

[9] [10] [11]

[12]

[13] [14] [15] [16]

[17] [18]

[19] [20]

[21]

[22] [23]

Actes des deuxièmes assises nationales du GdR I3 I. Borne, N. Revault, Comparaison d’outils de mise en oeuvre de design patterns, numéro spécial de la revue l’Objet « Object-Oriented Patterns », Vol5, num2, 1999. F. Buschmann, R. Meunier R., & al., Pattern-Oriented Software Architecture: A System of Patterns, Wiley & Sons, 1996. Catalyst Methodology, Computer Sciences Corporation, 1995. C. Cauvet, D. Rieu, P. Ramadour,, A.Front-Conte, Réutilisation dans l’ingénierie des systèmes d’information, Chapitre de l’ouvrage Ingénierie des systèmes d’information du Traité IC2 – Information – Commande – Communication, Hermès, février 2001 J. Cheesman, J.Daniels,, UML Components: A Simple Process for Specifying Component-Based Software, The Component Software Series, 2000. P. Coad, D. North, M. Mayfield, Object Models – Strategies, Patterns and Application, Yourdon Press Computing Series, 1995. A. Conte, M. Fredj, I. Hassine, J.P. Giraudin, D. Rieu, A tool and a formalism to design and apply patterns, OOIS, Montpellier, septembre 2002 D. D’Souza, A. Cameron Wills, Objects, Component and Frameworks with UML, The Catalysis Approach, Addison-Wesley, 1999. A.H. Eden, Precise Specification of Design Patterns and Tool Support in Their Application, PhD Thesis, Department of Computer Science, Tel Aviv University, 2000. M. Fowler, Analysis Patterns – Reusable Object Models, Addison-Wesley, 1997. A. Front-Conte, J.P. Giraudin, D. Rieu, C. Saint-Marcel, Réutilisation et patrons d’ingénierie, Chapitre de l’ouvrage Génie Objet: Analyse et Conception de l’Evolution, Editeur M. Oussalah, Hermès, 1999. E. Gamma, R. Helm, R.E. Johnson, J. Vlissides, Design patterns: Elements of Reusable Object-Oriented Software, Addison-Wesley, 1995. D. Garlan, R. Monroe, and D. Wile, « ACME : An Architecture Description Interchange Language », ProC, IBM Center for Advanced Studies Conference (CASCON), IBM Canada, Ltd., Toronto, ON, 1997, pp. 169183. L. Gzara, D. Rieu, M. Tollenaere, Pattern Approach To Product Information Systems Engineering, Requirements Engineering Journal, Editors: Peri Loucopoulos & Colin Potts, Springer- Verlag, London, LTD., 2000. S. Heiler, Semantic Interoperability, ACM Computing Surveys, ACM Press, 27(2), pp. 271-279, 1995. G. Heineman, W. Councill, Component-Based Software Engineering: Putting the Pieces Together, Addison-Wesley, 2001.

Composants dans l’ingénierie des systèmes d’information

117

[24] P. Herzum, O. Sims, Business Component Factory : a Comprehensive Overview of Component-Based Development for the Enterprise, Wiley Computer Publishing, 1999 [25] I. Jacobson, G. Booch, J. Rumbaugh, The Unified Software Development Process, Addisson-Wesley Object Technology Series, 1999 [26] D. Luckham and al., « Specification and Analysis of System Architecture Using Rapide », IEEE Transactions on Software Engineering, Vol. 21, No. 4, Apr., 1995, pp. 336-355. [27] M.D. McIlroy, Mass-Produced Software Components, Software Engineering Concepts and Techniques (1968 NATO Conference on Software Engineering), Van Nostrand Reinhold, 1976, pp. 88-98 [28] N. Medvidovic, « A Framework for classifying and comparing Architecture Description Languages », Proc., 6th European Software Engineering Conference (ESEC), LNCS, No. 1301, Springer-Verlag, Heidelberg, Germany, 1997, pp. 60-76. [29] T.D Meijler, S. Demeyer, R. Engel, Making design patterns explicit in face, in European Software Engineering Conference (ESEC/FSE 97), 1997. [30] Object Constraint Language, OMG, 1999. [31] Object Management Group, Currency Specification, Version 1.0, June 2000. [32] Portland: About the Portland Form, http://c2.com/ppr/about/portland.html, 1994. [33] Ph. Ramadour, C. Cauvet, Engineering and Reuse of Domain Components ", In Proceedings of OOIS’2001, Calgary, Canada, 2001 [34] D. Rieu, J.P. Giraudin, A. Conte, Pattern-Based Environments for Information Systems Development, International Conference, The Sciences of Design, 15-16 mars 2002, Lyon, France. [35] C. Saint-Marcel, Modélisation du comportement, une approche par les rôles", Congrès Inforsid, Montpellier, mai 1998 [36] M. Shaw and D. Garlan, « Software Architecture : Prespectives on an Emerging Discipline, Prentice Hall, 1997. [37] O. Sims, Business Objects – Delivering Cooperative Objects for ClientServer, McGraw-Hill, 1994. [38] C. Szyperski, Component Software – Beyond Object-Oriented Programming, Addison-Wesley, 1998. [39] S. Vestal, MetaH Programmer’s Manuel version 1.27, Honeywell, Inc., 1998. [40] S. Wartik, R. Prieto-Diaz, Criteria for Comparing Reuse-Oriented Domain Analysis Approaches, International Journal of Software Engineering and Knowledge Engineering, 2(3), pp. 403-431, 1992. [41] D. Weiss D.M., Lai C.T. R., Software Product-Line Engineering: a FamilyBased Software Development Process, Addison-Wesley, 1999.